RAG nedir, sürümlü belgelerde neden tarih gerekir?
RAG (retrieval-augmented generation), yani bilgi getirmeyle güçlendirilmiş üretim, bir dil modelinin soruyu yanıtlarken dış kaynaklardan getirilen metni kullanmasıdır. Kurumsal bilgi asistanında bu kaynaklar politika, prosedür ve ürün kılavuzları olabilir. Belge sürümleme ise aynı belgenin zaman içinde değişen metinlerini ve hangi koşullarda geçerli olduklarını birlikte izlemektir. İkisini birleştirdiğinizde yalnız ilgili paragrafı bulmanız yetmez; paragrafın sorulan olay için geçerli olması gerekir. İyi yazılmış, gerçek kaynağa bağlanan bir yanıt yanlış sürüme dayanıyorsa iş kararını yine yanlış yönlendirir.
Örneğin güncel seyahat politikası ile geçen yıl yürürlükteki politika aynı sözcükleri kullanabilir. Anlamsal arama eski metni daha yakın bulduğunda güncel soruya eski sınırla cevap verebilir. Dosyanın yükleme zamanı, değiştirilme zamanı ve yürürlük tarihi birbirinden farklıdır. Ağustosta yüklenen dosya temmuzdan beri geçerli olabilir; bugünkü dosya geçmişteki olayı açıklamayabilir. Önce sorunun tarihini, bölgesini ve uygulanacak tarih türünü çözmelisiniz. Kullanıcının rolü bir kuralın kapsamını belirleyebilir; belgeyi görme yetkisi ise ayrıca kontrol edilir. Geçerliliği modelin tahminine veya dosya adındaki “son” ifadesine bırakmayın.
Yürürlük tarihine göre getirme kuralları
Her belge ailesi için aşağıdaki karar tablosunu doldurun. Güncel soruda hangi saat diliminin ve tarihin kullanıldığı açık olsun. Tarihsel soruda kullanıcıya en yeni metni göstermek yerine olay tarihinde geçerli sürümü arayın. Bir politika seyahat tarihi yerine bildirim tarihini esas alıyorsa bunu kaynakta doğrulayın. Tarih veya bölge yanıtı değiştiriyor, kullanıcı da bu bilgiyi vermiyorsa açıklama sorusu sorun. Tablo, anlamsal sıralamadan önce hangi belgelerin aday olabileceğini belirler.
| Soru durumu | Getirme kuralı | Beklenen davranış |
|---|---|---|
| Güncel kural | Bugün yürürlükte, kapsamı uygun sürüm | Kullanılan tarih ve sürümü göster |
| Belirli tarihteki olay | Olay tarihinde geçerli sürüm | Tarihsel metni koru |
| Olay ve bildirim tarihi farklı | Politikanın belirlediği tarih türü | Kural yoksa sahibine yönlendir |
| Başlangıç veya bitiş sınırı | Başlangıç dahil, bitiş hariç aralık | Tek sürüm seçildiğini doğrula |
| Çakışan geçerli sürümler | Onaylı öncelik veya istisna kuralı | Çözülemeyen çelişkiyi açıkla |
| Geçerlilik bilgisi eksik | Otomatik politika yanıtından çıkar | Belge sahibinden doğrulama iste |
Başlangıcı dahil, bitişi hariç tutmak bir uygulama tercihidir; kaynakta farklı bir kural varsa onu esas alın. Tercihin amacı, devir gününde iki sürümü yanlışlıkla birlikte geçerli saymamaktır. Yalnız dosya numarasına göre seçim yapmak bölgesel istisnaları veya gelecekte yürürlüğe girecek metni atlayabilir.
Yanıt arayüzünde çözülen tarihi görünür tutun. Kullanıcı “geçen ay” dediğinde hangi günün esas alındığını sorunun bağlamıyla belirleyin; ay boyunca politika değişmişse tek tarih seçmeyin. Tarih aralığını daraltan bir açıklama sorusu, birbirine karışmış iki sürümden kesin cevap üretmekten daha kullanışlıdır. Kullanıcının verdiği tarihi ve sistemin seçtiği tarihi kayıtta ayrı saklayın.
Belge ve pasaj verisi nasıl tutulur?
Her politika için kalıcı belge kimliği ve her metin sürümü için ayrı sürüm kimliği oluşturun. Özgün dosyayı, ayrıştırılmış metni ve içerik özet değerini saklayın. Böylece yanıtın gösterdiği sürümün sonradan aynı adrese yüklenen farklı bir dosya olmadığını kontrol edebilirsiniz. Bölge, ürün, ilgili rol, belge sahibi, onay durumu, yürürlük başlangıcı, yürürlük sonu ve yerine geçen sürüm ilişkisi açık alanlar olsun. Eksik bitiş tarihi “henüz sona ermemiş” anlamına gelebilir; eksik başlangıç tarihi ise otomatik olarak “her zaman geçerli” sayılmamalıdır.
Dosyayı parçaladığınızda bu alanları her pasaja taşıyın. Başlık, madde numarası, sayfa veya paragraf aralığı da korunsun. Dipnotun istisna getirdiği bir tabloyu, dipnotu başka parçada kaybolacak biçimde ayırmayın. Bir belge ailesine ait iki sürümün metnini tek pasajda birleştirmeyin. Değişiklik geçmişi ayrı tutulabilir; yanıt için kullanılan kural ile yalnız değişikliği anlatan açıklamayı ayırt edin. Atıf, genel belge ailesini değil seçilen sürümdeki tam maddeyi açabilsin.
Birden fazla kapsam varsa “daha yeni belge her zaman kazanır” gibi genel bir öncelik icat etmeyin. Belge sahibi ülke eki, birim istisnası ve ana politika arasındaki ilişkiyi onaylasın. Yalnız tarih aralığı yetmeyebilir: taslak, yayımlanmış ama henüz yürürlüğe girmemiş metin ve geri çekilmiş metin farklı durumlardır. İçe alma doğrulaması çakışan aralıkları, ters başlangıç/bitiş tarihlerini ve bulunamayan yerine geçme bağlantılarını raporlasın.
Arama, güncelleme ve önbellek nasıl bağlanır?
İstek sırasında geçerlilik tarihini, tarih türünü ve kapsamı yapılandırılmış alanlara dönüştürün. Sonra yetki filtresiyle birlikte geçerli aday kümesini belirleyin; anlamsal benzerlik bu küme içindeki ilgiyi sıralasın. Azure AI Search filtre belgeleri, meta veri alanlarının tam eşleşme ve koşullarla adayları sınırlamasını anlatır. Vektör aramasında da ürünün filtreleme aşamasını kontrol edin ve geçerli adaylar üzerinde arama yapacak yapılandırmayı seçin. Serbest kullanıcı metnini doğrudan filtre ifadesi olarak çalıştırmayın.
Yeni sürümü önce doğrulayın, pasajlarını oluşturun ve deneme sorgularıyla kontrol edin. Ardından eski sürümün aralığı ile yeni sürümün etkinleşmesini tutarlı bir geçişle uygulayın. İçe alma ve sorgu kayıtlarında ayrı zamanlar tutun. Microsoft'un dizinleyici sorun giderme rehberi, kaynakta bulunan belgelerin zamanlama, süre sınırı veya eşleme sorunları nedeniyle dizinde görünmeyebileceğini açıklar. Başarılı dosya yükleme, doğru sürümün aranabilir olduğunu kanıtlamaz.
Güncel yanıt önbelleği politika değişince geçersizleşsin. Tarihsel yanıt için de belge ailesi, seçilen sürüm, sorgu tarihi, kapsam ve yetki kümesi anahtara girsin. Yeni bilgi gecikiyorsa son doğrulanmış dizin zamanını gösterin; önemli yanıtta doğrulanmamış kuralı kesinleştirmeyin. Kayıtlar seçilen tarihi, uygulanan filtreyi, dönen sürüm kimliklerini ve atıfları içersin. Böylece eski metnin neden kullanıldığını sonradan anlayabilirsiniz.
Varsayımsal örnek: haziran seyahati, ağustos bildirimi
Varsayımsal bir şirketin seyahat politikası v3'ü, yurt içi konaklamada gecelik 4.000 TL üzeri için onay istesin. 1 Temmuz'da yürürlüğe giren v4 sınırı 5.000 TL'ye çıkarsın. Çalışan 20 Haziran'daki 4.500 TL konaklamayı 5 Ağustos'ta bildirsin. Belgede sınırın seyahat tarihine göre belirlendiği açıkça yazıyorsa doğru aday v3'tür; ağustosta sorulması v4'ü geçerli yapmaz. Yanıt, esas alınan tarihi ve maddeyi göstererek onay gerektiğini açıklamalıdır.
30 Haziran, 1 Temmuz ve 2 Temmuz için aynı tutarda üç test oluşturun. Önerilen yarı açık aralıkta v3 1 Temmuz'da sona erer, v4 aynı gün başlar; ilk olayda onay gerekir, diğer ikisinde bu tutar nedeniyle gerekmez. Başka koşulların ayrıca onay gerektirebileceğini koruyun. Politika bildirim tarihini esas alsaydı haziran olayı için de v4 seçilecekti. Hangi tarihin esas olduğu kaynakta yazmıyorsa iki maddeyi gösterip politika sahibinden açıklama isteyin. Bu rakamlar ve kurallar örnek içindir; gerçek şirket uygulaması veya hukuki gereklilik değildir.
Sürüm doğruluğu için test planı
- Sınır günlerini sınayın. Her devir için önceki gün, yürürlük günü ve sonraki gün soruları oluşturun. Beklenen belge ve sürüm kimliklerini ham sonuçlarda doğrulayın.
- Kapsamı değiştirin. Aynı soruyu farklı bölge, ürün ve rollerle sorun. Daha yüksek benzerlikteki yanlış kapsamlı pasaj aday kümeye girmemelidir.
- Belirsizliği sınayın. Eksik tarih, çakışan metin, taslak ve geri çekilmiş belge ekleyin. Beklenen açıklama sorusunu veya yanıt vermemeyi kabul ölçütüne yazın.
- Dayanağı ve geçerliliği ayırın. Ragas faithfulness ölçütü iddiaların getirilen bağlamla desteklenmesini kontrol eder. Buna ek olarak seçilen sürümün olay için geçerliliğini ayrı ölçün.
- Güncelleme gecikmesini ölçün. Onaydan doğru sürümün ilk doğrulanmış sorgusuna kadar süreyi kaydedin. Eski önbellek, yarım dizinleme ve erişim değişikliklerini de test edin.
Sık yapılan hatalar
- Dosya yükleme tarihini yürürlük tarihi kabul etmek ve sürüm alanlarını boş bırakmak.
- Yalnız en yeni metni tutarak tarihsel soruların doğru kaynağını silmek.
- Geçerliliği vektör benzerliğine bırakıp eski ama yakın pasajları kullanmak.
- Başlangıç ve bitiş günlerini farklı yorumlayıp iki sürümü birlikte seçmek.
- Yüksek faithfulness puanını güncel ve uygulanabilir yanıtın kanıtı saymak.
Hatson Tech bunu nasıl kuruyor?
Belge sahipleriyle tarih türünü, kapsamı ve sürüm geçişini belirleyerek başlıyoruz. Bu kuralları dizin şemasına ve kabul testlerine RAG ve anlamsal arama çözümlerimizde birlikte taşıyoruz. Belge kapsamını düşünmek için Türkçe hukuk verisiyle RAG yazımıza, erişim sınırını uygulamak için yetki duyarlı arama rehberimize bakabilirsiniz. Teknik pilotta güncel cevabın yanında geçmiş tarihteki doğru cevabı da doğruluyor, belirsiz politikanın sessizce kesin kurala dönüşmesini engelliyoruz.