RAG'de asıl sorun modelin cevabı değil, ona verilen belge
- RAG
- Üretim
Şikayet hep aynı cümleyle geliyor: "model uyduruyor".
Bakınca çoğu zaman model uydurmuyor. Eline verilen belgeyi gayet doğru özetliyor. Belge yanlış.
Bu ayrım işin yarısı, çünkü iki sorunun çözümü bambaşka yerlerde. Model sorunu prompt ve model seçimiyle çözülüyor. Getirme sorunu indeks, parçalama ve sorgu tarafında.
recall@k neyi göstermiyor
Getirme kalitesini ölçerken ilk başvurulan metrik genelde recall@k: doğru belge ilk k sonuç arasında mı.
Bir şeyi ölçüyor, doğru. Üretimde önemli olan üç şeyi ölçmüyor.
Doğru belge geldi ama kaçıncı sırada geldi? Beşinci sıradaki doğru belge, bağlamda birinci sıradaki yanlış belgenin arkasında kalıyor. Doğru belgeyle beraber kaç yanlış belge geldi? Yedinin altısı alakasızsa model dikkatini bölüyor. Ve en önemlisi: cevap hiçbir belgede yoksa ne oluyor? Sistem "bilmiyorum" diyebiliyor mu, yoksa eldeki en yakın belgeden bir cevap mı uyduruyor.
Sonuncusu en çok zarar veren. Kurumsal bir bilgi tabanında sorular sürekli kapsam dışına çıkıyor ve orada doğru davranış cevap üretmemek.
Görmediğiniz şeyi düzeltemiyorsunuz
Getirmeyi iyileştirmenin önündeki asıl engel görünürlük eksikliğiydi. Cevap kötü geliyor, o cevabın hangi belgelerden çıktığı bilinmiyor, tartışma tahminle yürüyor.
En basit ve en faydalı değişikliğimiz buydu: her cevabın yanında getirilen belge kimliklerini ve skorlarını saklamak. Bir günlük iş, aylardır süren tartışmayı bitirdi.
Sonrasında kötü cevaplar iki kovaya ayrılabilir hale geldi. Doğru belge gelmiş ama cevap yine kötüyse sorun modelde veya prompt'ta - belge oradaydı, model kullanmadı ya da yanlış okudu. Doğru belge hiç gelmemişse sorun getirmede, model zaten elindekiyle yapabileceğini yapmış.
Bu ayrım olmadan yapılan her iyileştirme denemesi kör gidiyor.
Parçalama, gömme modelinden önce geliyor
Getirme kötüyken ilk akla gelen şey gömme modelini değiştirmek. Bizde etkisi, parçalamayı düzeltmenin yanında küçük kaldı.
Sabit uzunlukta parçalama anlamsal sınırları ortadan kesiyor. Bir prosedürün ortasından bölünmüş parça tek başına okunduğunda ne cevabı içeriyor ne bağlamını.
Parçalamayı belgenin kendi yapısına yasladık: başlık hiyerarşisi, madde sınırları, tablo bütünlüğü. Parçalar eşit boyutta değil ama her biri tek başına okunabiliyor.
İkinci kazanç beklenmedik yerden geldi. Her parçaya ait olduğu başlık zincirini eklemek - "Yedekleme > Haftalık plan > İstisnalar" bilgisinin parçanın içinde durması - hem getirmeyi hem model tarafını belirgin biçimde düzeltti.
Filtreleme aramadan sonra değil, önce
Kurumsal sorular neredeyse her zaman kapsamlı: belirli bir ortam, belirli bir müşteri, belirli bir tarih aralığı.
Bu kısıtları arama sonrasında uygulamak kötü sonuç veriyor. İlk k sonucun tamamı kapsam dışı çıkabiliyor ve elinizde hiçbir şey kalmıyor - üstelik uygun belge indekste dururken.
Metadata filtreleri sorgunun parçası olmalı, sonradan yapılan bir eleme değil.
RAG'de model tarafını iyileştirmek görünür bir iş. Getirmeyi iyileştirmek görünmez. Ama kötü cevapların çoğu oradan geliyor.
Bizde işleyen sıra: önce getirilen belgeleri kaydet, sonra kötü cevapları ikiye ayır, sonra parçalamaya bak. Gömme modeli tartışması bunların hepsinden sonra geliyor.