RAG mimarisinde üretime çıkmadan önce çözülmesi gereken beş sorun

Bir RAG (retrieval-augmented generation) prototipini bir haftada ayağa kaldırmak bugün zor değil. Zor olan, o prototipin altı ay sonra hâlâ doğru yanıt vermesi.

Son iki yılda üretime aldığımız RAG sistemlerinde tekrar tekrar aynı beş sorunla karşılaştık. Hepsi demo aşamasında görünmez; hepsi üretimde pahalıya patlar.

1. Değerlendirme seti olmadan başlamak

En yaygın hata bu. Ekip birkaç soru sorar, yanıtlar makul görünür, sistem "çalışıyor" sayılır. Sonra bir model sürümü değişir, bir belge güncellenir, chunk boyutu ayarlanır — ve kimse neyin bozulduğunu bilemez.

Bir RAG sistemi, ölçülemeyen bir sistemdir; ta ki bir değerlendirme seti yazılana kadar.

Bizim asgari eşiğimiz şu: en az 150 soru-cevap çifti, alan uzmanı tarafından doğrulanmış, aşağıdaki dağılımda:

• Doğrudan tek bir belgeden yanıtlanabilen sorular
• Birden fazla belgeyi birleştirmeyi gerektiren sorular
• Kurum verisinde yanıtı olmayan sorular
• Benzer ama farklı iki belgeyi karıştırmaya yatkın sorular

Son iki kategori en değerlisidir. Bir sistemin "bilmiyorum" diyebilmesi, doğru yanıt vermesi kadar önemlidir.

2. Chunk sınırlarının anlamı kesmesi

Sabit uzunlukta bölme (ör. her 500 token) uygulaması kolaydır ve çoğu zaman yanlıştır. Bir tablonun başlığı bir parçada, satırları başka bir parçada kalırsa, geri getirme aşaması hangi parçayı bulursa bulsun yanıt eksik olur.

Uyguladığımız yaklaşım:

• Belgeyi önce yapısına göre böl (başlık, bölüm, tablo, liste)
• Bölüm çok uzunsa cümle sınırında alt parçalara ayır
• Her parçaya, ait olduğu başlık zincirini metin olarak ekle
• Tabloları asla bölme; büyük tabloyu satır gruplarına ayırıp her gruba başlık satırını tekrarla

Bu tek değişiklik, bir müşterimizde doğru yanıt oranını %71'den %88'e çıkardı.

3. Yetkilendirmeyi geri getirme sonrasına bırakmak

Sık görülen bir tasarım hatası: önce en alakalı 20 parçayı getir, sonra kullanıcının göremeyeceklerini filtrele.

Bu yaklaşımın iki sorunu var. Birincisi, filtreleme sonrası elde iki parça kalabilir ve yanıt zayıflar. İkincisi ve daha ciddisi, sıralama skorları üzerinden bilgi sızabilir: kullanıcı, göremediği bir belgenin var olduğunu çıkarabilir.

Yetki filtresi arama sorgusunun içinde olmalıdır, sonrasında değil. Vektör veritabanınız meta veri filtrelemesini destekliyorsa bunu tek sorguda yapabilirsiniz.

results = client.search(
    collection_name="docs",
    query_vector=embedding,
    query_filter=Filter(
        must=[FieldCondition(key="acl", match=MatchAny(any=user.group_ids))]
    ),
    limit=8,
)

4. Dizinin belgelerden geri kalması

Kurumsal belgeler değişir. Bir prosedür güncellenir, bir fiyat listesi yenilenir, bir politika yürürlükten kalkar. Dizin bu değişiklikleri takip etmiyorsa sisteminiz kendinden emin biçimde yanlış yanıt vermeye başlar — ki bu, hiç yanıt vermemekten kötüdür.

Kurduğumuz asgari düzen:

| Bileşen | Görevi | | --- | --- | | Değişiklik dinleyicisi | Kaynak sistemdeki güncellemeyi yakalar | | Sıra | Yeniden gömme işlerini biriktirir ve hız sınırlar | | Sürüm etiketi | Her parçanın hangi belge sürümünden geldiğini tutar | | Temizleyici | Silinen belgelerin parçalarını dizinden kaldırır |

Son satır atlanan en yaygın adımdır. Silinmiş bir belgenin parçaları dizinde kalırsa sistem, artık var olmayan bir politikayı alıntılamayı sürdürür.

5. Maliyeti sonradan düşünmek

Token maliyeti prototipte görünmez çünkü trafik yoktur. Üretimde ise faturayı belirleyen şey genellikle model seçimi değil, bağlam uzunluğudur.

Uyguladığımız üç önlem:

1. Geri getirmeyi daralt. 20 parça yerine 6 iyi parça, çoğu durumda daha doğru ve daha ucuzdur.
2. Yanıtları önbelleğe al. Kurumsal ortamda soruların önemli bir kısmı tekrar eder. Normalize edilmiş soru üzerinden anlamsal önbellek, bir müşterimizde çağrıların %31'ini karşıladı.
3. Modeli göreve göre seç. Sınıflandırma ve yeniden sıralama için küçük model, nihai yanıt için büyük model.

Bu üçü birlikte, aynı müşteride aylık token maliyetini %43 düşürdü — doğruluk oranında ölçülebilir bir kayıp olmadan.

Özet

RAG'ı zorlaştıran şey model değil, çevresindeki mühendislik. Bir sistemi üretime almadan önce şu dört soruya yazılı yanıtınız olmalı:

• Doğruluğu neyle ölçüyoruz?
• Belge değiştiğinde dizin ne zaman güncellenir?
• Kullanıcı yetkisi hangi katmanda uygulanır?
• Trafik on katına çıkarsa fatura ne olur?

Bu sorulara yanıt veremiyorsanız, elinizde bir ürün değil, bir demo var.