RAG Asistanınız Yanlış Politikayı Getir­di­ğinde Ne Yap­ma­lı­sı­nız?

Retrieval-augmented generation (RAG) kullanan bir asistan, doğruymuş gibi yanlış bir dokümana dayanarak yanıt verebilir. Model düzgün çalışıyor olabilir; sorun, erişim katmanının güncel olmayan bir politikayı, yanlış pazar sürümünü veya eksik bir bölümü bağlama eklemesidir.

Sorunu incelemek için asistanı baştan oluşturmanız gerekmez. Bu hafta, bilinen sorulardan oluşan küçük bir test seti hazırlayın, getirilen kaynakları inceleyin ve hatanın gerçekten oluştuğu noktaya kontroller ekleyin.

Yanlış yanıtı bir erişim olayı olarak ele alın

Bir müşterinin “Teslimattan sonra kişiye özel üretilmiş bir kanepeyi iade edebilir miyim?” diye sorduğunu düşünün. Asistanınız genel iade sayfasını getirir ve “Evet, 14 gün içinde” yanıtını verir. Oysa ayrı bir özel sipariş politikası, kişiye özel ürünlerin iade kapsamı dışında olduğunu belirtiyordur.

Sorun, LLM’in istisnayı anlayamaması olmayabilir. İstisna içeren bilgi, modelin bağlamına hiç ulaşmamış olabilir. Yanlış bölüm getiriliyorsa modele “daha doğru yanıt ver” demek temel sorunu çözmez.

Prompt’ları değiştirmeden önce hatayı sınıflandırın:

• Erişim hatası: Doğru doküman veya bölüm getirilmedi.
• Sıralama hatası: Doğru bölüm getirildi, ancak daha zayıf bir bölüm üst sırada gösterildi.
• Veri hatası: Kaynak güncel değil, eksik veya çelişkili.
• Üretim hatası: Doğru kanıt mevcut olduğu halde yanıt bunu dikkate almadı.
• Politika hatası: Asistan yanıt vermek yerine reddetmeli veya konuyu bir uzmana aktarmalıydı.

Bu sınıflandırma, maliyetli deneme yanılma sürecini önler. Hatalı her örnek için kullanıcının sorusunu, getirilen bölümleri, doküman metadata’sını ve nihai yanıtı kaydedin.

Gerçek sorulardan küçük bir değer­len­dirme seti oluşturun

Yüzlerce yapay test prompt’uyla başlamayın. Destek taleplerinden, web sitesi aramalarından, satış görüşmelerinden ve yanıtsız gelen mesajlardan pratik bir örneklem çıkarın. İstisnalar, bölgesel farklılıklar ve eksik bilgiler içeren sorulara mutlaka yer verin.

Örneğin Türkiye ve Körfez ülkelerine hizmet veren bir mağaza; teslimat bölgeleri, iadeler, garanti, ödeme yöntemleri, kurulum ve ürün bulunabilirliği konularını kapsayan 30 test sorusu hazırlayabilir. 30 sayısı yalnızca bir örnektir; asıl önemli olan, işletme açısından risk yaratan durumları test etmektir.

Her soru için beklenen dört sonucu kaydedin:

1. Yanıt: Hangi bilgiler mutlaka yer almalı?
2. Kaynak: Hangi doküman veya politika yetkili kaynak?
3. Kapsam: Hangi ülke, dil, ürün veya müşteri tipi geçerli?
4. Geri dönüş: Bilgi mevcut değilse ne olmalı?

Zor örnekleri özellikle ekleyin. “İade politikanız nedir?” sorusunun yanı sıra “Dubai’den satın alınan kişiye özel bir ürünü iade edebilir miyim?” sorusunu da test edin. Yalnızca genel sorularda iyi performans gösteren bir sistem, müşterilere açık kullanıma henüz hazır değildir.

Erişimi yanıt kali­te­sin­den ayrı puanlayın

Üç değerlendirme içeren basit bir kontrol formu kullanın:

• Kaynak bulundu mu: Yetkili bölüm getirildi mi?
• Kanıt kullanıldı mı: Yanıt bu bölümü doğru şekilde yansıttı mı?
• Eylem güvenli mi: Asistan desteklenmeyen bir taahhütte bulunmaktan kaçındı mı?

Bu yaklaşım, performansın nerede düştüğünü görmenizi sağlar. Hataların çoğunda kaynak bulunamıyorsa chunking, metadata veya arama yapısı üzerinde çalışın. Kaynak mevcut olduğu halde kullanılmıyorsa prompt’u, bağlamın biçimlendirilmesini ve model seçimini inceleyin.

Modeli değiş­tir­me­den önce doküman yapısını düzeltin

Birçok RAG sorununun nedeni, erişilmesi zor dokümanlardır. Teslimat, iade ve garanti kurallarını içeren uzun bir PDF insan tarafından okunabilir; ancak belirli bir soruyla eşleştirilmesi zor olabilir.

Önce kaynak materyali iyileştirin:

• Büyük politikaları, net başlıklarla anlamlı bölümlere ayırın.
• Her chunk’ı tek bir soru veya kural etrafında odaklayın.
• “BAE iade politikası” veya “Türkiye kurulum koşulları” gibi kapsam bilgilerini metinde tekrarlayın.
• Yürürlük ve gözden geçirme tarihlerini ekleyin.
• Geçerliliğini yitiren dokümanları aramaya açık bırakmak yerine pasif olarak işaretleyin.
• Ürün, pazar, dil ve müşteri tipi metadata’sını saklayın.
• İstisnaları, konuyla ilgisiz bir ekte tutmak yerine ana kuralla birlikte koruyun.

Chunking, keyfi bir karakter sayısına değil, anlama göre yapılmalıdır. İade kuralı ve bu kuralın istisnaları genellikle birlikte kalmalıdır. Bir bölüm çok uzunsa konusuna göre ayırın; ancak her parçanın yorumlanması için gereken koşulları tekrarlayın.

Metadata’yı yalnızca etiket değil, filtre olarak kullanın

Metadata, erişimi filtrelediğinde daha değerli hale gelir. Kullanıcı BAE’deki bir sipariş hakkında soru soruyorsa, genel politika değerlendirilmeden önce BAE politikasına öncelik verilmeli veya yalnızca bu politika kullanılmalıdır. Soru belirli bir ürün kategorisiyle ilgiliyse, kategoriye özel bir kuralın üzerinde geçerli bir neden olmadan genel politikayı sıralamayın.

Konum çıkarımı konusunda dikkatli olun. Müşterinin dili her zaman hangi pazarda olduğunu göstermez. Pazar belirsizse ve yanıt ülkeye göre değişiyorsa tahmin yürütmek yerine açıklayıcı bir soru sorun.

Kaynak ve geri dönüş güvenlik kuralı ekleyin

Asistanınız, getirilen her bölümü yanıt verme izni olarak görmemelidir. Kanıt ve belirsizlik konusunda açık kurallar tanımlayın.

Pratik bir talimat, asistandan şunları isteyebilir:

• Politika sorularında yalnızca sağlanan kaynaklara dayanarak yanıt vermek.
• Yanıtı etkiliyorsa ilgili pazar veya ürün kapsamını belirtmek.
• Son tarih, fiyat, stok durumu veya uygunluk koşulu uydurmamak.
• Kaynaklar çelişiyorsa veya sorunun yanıtını içermiyorsa bunu açıkça söylemek.
• Müşterinin pazarı veya ürünü belirsizse bir açıklayıcı soru sormak.
• Hassas durumları bir ekip üyesine aktarmak.

Geri dönüş kuralı operasyonel olmalıdır; belirsiz ifadeler yeterli değildir. “Emin değilim” demek yerine “Kişiye özel ürünlerin iade kapsamında olup olmadığını doğrulayamıyorum. Destek ekibimizin sipariş koşullarını kontrol edebilmesi için lütfen sipariş numaranızı paylaşın” demek daha kullanışlıdır.

İade ödemeleri, hukuki şartlar, tıbbi iddialar veya finansal kararlar gibi yüksek riskli konularda belirsiz durumları bir uzmana yönlendirin. Biraz daha düşük otomasyon oranı, sonradan düzeltilmesi pahalı olacak desteklenmeyen bir taahhütten genellikle daha iyidir.

Doğruluğu artırırken maliyeti kontrol edin

Daha iyi erişim her zaman daha büyük veya pahalı bir model gerektirmez. Önce modele gönderilen ilgisiz bağlamı azaltın. Üç odaklı bölümün değerlendirilmesi, gevşek biçimde ilişkili 15 dokümanın değerlendirilmesinden genellikle daha kolaydır.

Görevleri ayrıca ayırabilirsiniz:

• Dil, pazar veya niyeti sınıflandırmak için hafif bir adım kullanın.
• Mümkün olduğunda anlamsal aramadan önce metadata filtrelerini uygulayın.
• Küçük bir aday kümesi getirin; sorunun belirsiz olduğu durumlarda yeniden sıralama yapın.
• Her mesajda değil, karmaşık veya eskalasyon gerektiren durumlarda daha güçlü bir model kullanın.
• Kalıcı yanıtları yalnızca dayandıkları politika değişmediği sürece önbelleğe alın.

Kaliteyle birlikte maliyeti de takip edin. Örneğin, bir asistan ayda 1.000 soruyu yanıtlıyorsa ortalama erişim ve model maliyetini, insanlara aktarılan talepler ve düzeltilen yanıtların sayısıyla karşılaştırabilirsiniz. Bunlar örnek ölçümlerdir; ekibiniz için önemli olan iş sonuçlarını seçin.

Uygu­la­na­bi­lir RAG düzeltme kontrol listesi

İlk incelemeniz için şu sırayı izleyin:

1. Riskli veya hatalı yanıtlar üreten 20–30 gerçek soruyu toplayın.
2. Her soru için getirilen bölümleri ve metadata’yı kaydedin.
3. Yetkili kaynağı ve beklenen geri dönüşü işaretleyin.
4. Güncel olmayan, yinelenen veya kötü yapılandırılmış dokümanları düzeltin.
5. Pazar, dil, ürün ve yürürlük tarihi metadata’sını ekleyin.
6. Modeli değiştirmeden önce filtreleri ve erişimi test edin.
7. Belirsizlik, çelişki ve eskalasyon kurallarını ekleyin.
8. Aynı soruları yeniden çalıştırın; kaynak, kanıt ve güvenlik puanlarını kaydedin.
9. Bu seti gelecekteki değişiklikler için regresyon testi olarak saklayın.

Asistan iyileştikten sonra hatalı örnekleri silmeyin. Elinizdeki en değerli testler bunlardır.

ADMOV nasıl yardımcı olabilir?

ADMOV, özel işletme verileriniz etrafında bir LLM sistemi kurmanıza ve entegre etmenize yardımcı olabilir. Bu kapsamda doküman hazırlama, RAG mimarisi, model seçimi, değerlendirme setleri, metadata filtreleri ve güvenlik kuralları üzerinde çalışabiliriz. Ayrıca asistanı mevcut web sitenize, CRM’inize veya şirket içi iş akışınıza bağlayarak belirsiz yanıtların sessiz hatalara dönüşmesi yerine doğru kişiye ulaşmasını sağlayabiliriz.

RAG kurulumunuzu değerlendirmek ve öncelikli erişim hatalarını belirlemek için ücretsiz bir görüşme ayırtın.