Bir modeli aramaya bağlamak, onun bir şeyler uydurmasını tek başına durdurmaz. Değiştirdiği şey modelin önündeki malzemedir; ayrıca yanıtı sonradan kontrol etmenize imkân verir. Kaynağa dayandırma (grounding), bu iki imkânı güvenilir bir davranışa çeviren disiplindir: doğru pasajları getirmek, yanıtı onlara bağlı kılmak, hangi pasajın hangi iddiayı desteklediğini göstermek, hiçbiri desteklemiyorsa reddetmek ve zincirin bütününün sağlam olduğunu test etmek. Bu yazı, bir ajana ya da yapay zekâ özelliğine arama ekleyen geliştiriciler için her adımı sırayla ele alıyor.
Arama neyi düzeltir, neyi düzeltmez
Arama olmadan model, eğitim verisindeki örüntülerden yanıt üretir. Soru yeni, dar bir alana ait ya da şirket içi bir konudaysa boşluğu kulağa doğru gelen bir metinle doldurur. Getirme (retrieval) üç somut fayda sağlar: modelin hiç görmediği bilgileri sunar, eski hâliyle gördüğü bilgilerin güncelini verir ve her iddiaya işaret edebileceği bir dayanak kazandırır.
Ama her şeyi çözmez. Şu yaygın hatalar aramaya rağmen yaşamaya devam eder:
- Bağlamı yok saymak. Getirilen pasaj başka bir şey söylediği hâlde model ezberinden yanıt verir.
- Aşırı sentez. İki pasaj bir iddianın yarısını destekler; model bunları hiçbir kaynağın söylemediği tek bir iddiada birleştirir.
- Yanlış atıf. Bilgi doğrudur ama atıf, o bilgiyi içermeyen bir pasajı gösterir.
- Kötü getirme. Arama eskimiş, düşük kaliteli ya da konu dışı bir sayfa döndürmüştür; model de onu sadakatle özetler.
- Sessizliği doldurmak. İlgili hiçbir şey gelmemiştir, model yine de yanıt verir.
Her birinin kendi önlemi var. Yazının geri kalanı bunları hattaki sıralarına göre ele alıyor.
Kaynağa dayandırma hattı
Kaynağa dayalı bir yanıt beş aşamadan geçer. Bunları kodda ayrı tutmak, her birini tek başına test etmeyi mümkün kılar.
1. getir bir arama kaynağını sorgula -> aday belgeler 2. seç pasajlara böl, soruyla ilgili olanları tut 3. yanıtla yalnızca seçilen pasajlardan üret; her pasajın bir kimliği olsun 4. atıf ver her olgusal cümleye pasaj kimliklerini ekle 5. doğrula her iddiayı atıf yaptığı pasajla karşılaştır; tutmayanı ele ya da işaretle
İlk aşamanın canlı bir web arama API'si, kendi belgelerinizin dizini ya da ikisi birden olması soruya bağlıdır. Güncel olaylar, fiyatlar ve yeni sürümler taze web sonuçları ister. Politikalar, sözleşmeler ve şirket içi kararlar ise kendi belge kümenizde durur; orada web düpedüz yanlış kaynaktır. Pek çok ekip ikisini de kurar ve soruyu türüne göre yönlendirir. Getirme tarafını canlı web verisiyle RAG yazısı ayrıntılı anlatıyor.
Sayfa değil, pasaj verin
Modele verdiğiniz birim önemlidir. Bütün bir sayfa, ilgili cümleyi menüler, bildirim şeritleri ve alakasız bölümler arasında kaybeder; atıfları da belirsizleştirir. Belgeleri birkaç cümleden birkaç paragrafa kadar uzanan pasajlara bölün, her birine kalıcı bir kimlik verin ve gözden geçirenin ihtiyaç duyacağı üst veriyi saklayın:
{
"id": "p-0412",
"source_url": "https://example.org/policy/returns",
"title": "İade politikası",
"retrieved_at": "ISO-8601 zaman damgası",
"text": "Ürünler, fişte yazan süre içinde iade edilebilir..."
}Getirme tarihi süs değildir. Getirildiği anda doğru olan bir pasaj bugün yanlış olabilir; gözden geçiren bunu ancak tarih iddiayla birlikte taşınırsa değerlendirebilir. Hızla karşılığını veren iki kural daha var. Bağlama aramanın döndürdüğü her şeyi değil, yalnızca belirli bir ilgi eşiğini geçen pasajları koyun. Hangi alan adlarının ya da koleksiyonların yanıt verebileceğine de önceden karar verin: kısa bir izin listesi, uzun bir sıralamadan iyidir. Bu seçimi bir soruyu hangi kaynakların yanıtlayabileceğine karar vermek notu ele alıyor.
Pasaj düzeyinde atıf yapın
Bir ana sayfayı ya da elli sayfalık bir PDF'i gösteren atıf, hiç atıf olmamasından pek farklı değildir; okuyucu onu makul bir sürede kontrol edemez. Atıfları pasaj düzeyinde ve destekledikleri cümleye bağlı olarak isteyin; modelin yapılandırılmış çıktı döndürmesini sağlayın ki kodunuz bunu doğrulayabilsin.
{
"answer": [
{"claim": "İadeler, fişte yazan süre içinde kabul edilir.",
"support": ["p-0412"]},
{"claim": "Açılmış yazılım iade edilemez.",
"support": ["p-0415"]}
],
"unsupported": ["Hediye kartlarının bedeli iade ediliyor mu"]
}Bu çıktı üzerinde hiçbir model kullanmadan üç kontrol çalıştırılabilir. Atıf yapılan her kimlik, sağladığınız bağlamda gerçekten var mı? Her olgusal iddianın en az bir kimliği var mı? Kısa bir destekleyici alıntı da istediyseniz, bu alıntı pasajda harfi harfine geçiyor mu? Bunlardan birini geçemeyen atıf, ne kadar düzgün görünürse görünsün kanıt değildir. Modeller hiç görmedikleri bir kaynak için makul görünen bir URL ya da şık bir dipnot üretebilir; bu yüzden atıflar doğru görünene göre değil, gerçekten getirilen malzemeye göre kontrol edilmelidir. Bir kaynağı incelenebilir kılan şeyleri sağlam atıflar yazısında daha ayrıntılı bulabilirsiniz.
Reddetmeyi olağan bir çıktı yapın
Yapabileceğiniz en yararlı değişikliklerden biri, modele “kaynaklar bu soruyu yanıtlamıyor” demesi için meşru bir yol açmaktır. Kabul edilen tek çıktı yanıtsa, yanıt alırsınız.
Pratikte bu şu anlama gelir:
- Uzun bir istemin içine gömülmüş bir talimat yerine, pasajların kapsamadığı sorular ya da alt sorular için ayrılmış bir alan (yukarıdaki
unsupportedgibi). - Kısmi yanıtlar: desteklenen yarıyı yanıtlayın, desteklenmeyen yarıyı listeleyin. Kullanıcılar bunu, sonradan yanlış çıkan kendinden emin bir bütüne göre daha kolay kabul eder.
- “Arandı, bir şey bulunamadı” ile “arama kullanılamadı” arasında net bir ayrım. Birincisi bir yanıttır. İkincisi bir hatadır; “böyle bir bilgi yok” cümlesine dönüştürülmemeli, yeniden denenmeli ya da raporlanmalıdır.
- Reddi bir sonuç olarak gösteren arayüz metinleri. Ürün boş bir yanıtı başarısızlık gibi gösterirse, er geç biri istemi retler kaybolana kadar ayarlar.
Bunun ürün tarafını ret de bir sonuçtur notu tartışıyor.
Yanıt kalitesini değil, iddia desteğini test edin
Yanıtın iyi görünüp görünmediğini sormak yanlış testtir. Kaynağa dayandırma iddia iddia test edilir: her cümle, atıf yaptığı pasaj tarafından destekleniyor mu? Küçük bir değerlendirme kümesi kurun ve her istem, model ya da getirme değişikliğinde çalıştırın.
- Soruları toplayın: gerçek kullanımdan, doğru yanıtı “kaynaklarda yok” olanlar da dâhil.
- Bağlamı dondurun: her soru için bağlamı sabitleyin ki hatalar değişen arama sonuçlarına değil, üretime bağlanabilsin. Getirmeyi ayrıca test edin.
- Yanıtları atomik iddialara bölün: her iddiada tek bir olgu.
- Her iddiayı etiketleyin: atıf yaptığı pasaja göre “destekleniyor”, “çelişiyor” ya da “pasajda yok”. İlk etiketlemeyi ikinci bir model yapabilir; bir örneklemi ve her anlaşmazlığı bir insan gözden geçirmelidir.
- Zaman içinde üç sayıyı izleyin: desteklenmeyen iddialar, yanlış atıflar ve beklenen çıktı ret iken yanıtlanan sorular.
Örnek bir test vakası şöyle görünür:
Soru: “Açılmış yazılım iade edilebilir mi?” Bağlam: iade politikasından p-0412 ile p-0418 arasındaki pasajlar. Beklenen: açılmış yazılımın iade edilemeyeceğini söyleyen ve p-0415'e atıf yapan bir iddia. Yanıt bu iddia için başka bir pasaja atıf yaparsa, pasajın söylemediği bir koşul eklerse ya da iddiayı atıfsız bırakırsa test başarısız sayılır.
Ret vakalarını kümede kalıcı olarak tutun. Biri sistemi daha “yardımsever” yapmaya çalıştığında ilk bozulanlar onlardır.
Yönetilen bir çalışma alanında kaynağa dayandırma
GoCux aynı ilkeleri açık web yerine ekibin kendi malzemesine uygular. Bir web arama API'si değildir ve açık webi okumaz. Bilgi arama, tek bir projenin belgeleriyle sınırlı bir soruyu yanıtlar ve pasajları atıflarıyla birlikte döndürür; boş bir sonuç başarısızlık değil, geçerli bir yanıt sayılır. Web sayfaları bir projeye yalnızca yetkili bir tarayıcı oturumu ya da dışa aktarma adımıyla girer; içe aktarıldıktan sonra da özgün sayfa referansını ve getirildiği tarihi korur.
Araştırma işlerinde bir alıntıyla desteklenen bulgu, hiçbir kaynağın yanıtlayamadığı sorudan ayrı tutulur; böylece boşluklar örtülmek yerine görünür kalır. Bu ayrımın neden önemli olduğunu eksik kanıt açık bir sorudur notu anlatıyor. Oradaki bir atıf da yine okunmalıdır: nereye bakılacağını gösterir, pasajın iddiada söylenen şeyi gerçekten söyleyip söylemediğine ise gözden geçiren karar verir.
Kaynağa dayalı bir özellik için kontrol listesi
- Getirme; kalıcı kimlikleri, kaynak URL'leri ve getirme tarihleri olan pasajlar döndürüyor.
- Modele yalnızca ilgi eşiğini geçen ve izinli kaynaklardan gelen pasajlar ulaşıyor.
- Her olgusal cümle en az bir pasaj kimliği taşıyor; kod, bağlamda olmayan kimlikleri reddediyor.
- Çıktı biçiminde desteklenmeyen sorular için bir yer var ve arayüz bunu açıkça gösteriyor.
- “Bir şey bulunamadı” ile “kaynak kullanılamıyor” kodda ve arayüzde ayrı durumlar.
- Ret vakaları dâhil, bağlamı dondurulmuş bir değerlendirme kümesi her değişiklikte çalışıyor.
- Yalnızca otomatik puana değil, etiketlenmiş iddiaların bir örneklemine de bir insan bakıyor.
Bu iş akışını çalışma alanınıza taşıyın.
Kapsamı belirleyin. Kanıtları inceleyin. Gereken adımları onaylayın.