RAG Halüsinasyonları Vektör Veritabanını Nasıl Zehirliyor
Bir RAG pipeline'ı kendi halüsinasyonlarıyla vektör veritabanını zehirledi; deterministik doğrulama sorunu nasıl çözdü, inceliyoruz.
Bir finans şirketi için kurulan RAG pipeline'ı, PDF'lerden metadata çıkaran LLM'in belirsiz bir alanı (fiscal_year) uydurup bu tahmini gömme vektörlerine gömmesiyle sessizce bozulmaya başladı. Sistem hatasız görünüyordu; retrieval hızlı ve doğru çalışıyordu, ama döndürdüğü içerik yanlıştı. Ekibin ikinci bir LLM'i doğrulayıcı olarak kullanması da işe yaramadı: iki olasılıksal model birbirini onaylayarak bir 'doğruluk konsensüsü' değil, bir 'sycophancy döngüsü' üretti. Prompt'u sıkılaştırmak (kesin talimatlarla) durumu daha da kötüleştirdi; doğrulayıcı aşırı temkinli hale geldi ve API maliyetleri arttı.
Çözüm, doğrulama mantığını modelden koda taşımaktı: fiscal_year alanı ham metinde regex ile fiilen doğrulanmadan kabul edilmiyor, company_entity sabit bir SQL tablosuyla fuzzy-match ediliyor ve hiçbir veri doğrudan vektör deposuna gitmiyor — önce PostgreSQL'de karantinaya alınıyor. Bu değişiklik veri zehirlenmesini durdurdu ve API maliyetlerini yaklaşık yarıya indirdi.
Bu olay, mühendislere şu dersi hatırlatıyor: olasılıksal sistemler (LLM'ler) deterministik sınırlara ihtiyaç duyar. LLM-as-a-judge yaklaşımı, çevrimdışı toplu değerlendirmede işe yarar ama üretim yazma yolunda tek başına bütünlük kapısı olarak kullanılmamalı. Bu, agent belleğine yazmadan önce doğrulama yapan benzer harness tasarımlarıyla aynı ilkeyi paylaşıyor: model önerir, kod karar verir.