Kurumsal Yapay Zekâ: RAG Kalitesi ve Yetki Testleri

RAG projesinin işini bir cümlede sınırlayın

RAG, yanıt üretilirken ilgili kaynaklardan bilgi getirilmesine dayanan bir yaklaşımdır. Kurumsal projede ilk soru hangi modelin seçileceği değil, sistemin hangi işi yapmaya yetkili olduğudur. Yalnızca prosedür açıklayan bir asistan ile müşteri hesabında işlem yapan bir asistanın riskleri farklıdır.

Varsayımsal örneğimizde üretici firmanın satış ekibi ürün dokümanları ve onaylı ticari kurallar hakkında soru soruyor. Asistan teklif taslağına yardımcı olabilir; fakat kendiliğinden indirim onaylamaz veya sipariş oluşturmaz. Bu sınır örnek tasarım kararıdır. Gerçek bir projede işlem yetkileri, şirket kuralları ve ilgili mevzuat ayrıca incelenmelidir.

Pilot için tek bir başarım cümlesi yazın: “Satış çalışanı, erişebildiği güncel ürün dokümanındaki bilgiyi dayanağıyla bulabilecek.” Bu ifade ölçülebilir bir işi tarif eder. “Bütün şirketi yapay zekâya bağlayacağız” ise veri kapsamını, sorumluluğu ve başarısızlık durumunu açıklamaz.

Belge getirme ile cevap üretmeyi ayrı ölçün

AWS’nin RAG değerlendirme dokümantasyonu yalnız getirme ile getirme ve üretme değerlendirmelerini ayırır. Bu ayrım, doğru belgenin bulunup bulunmadığı ile bulunan bilgiden uygun yanıt üretilip üretilmediğini ayrı incelemek için yararlıdır. [1]

Önerilen test kaydı soru, kullanıcı rolü, izinli kaynaklar, beklenen dayanak, kabul edilebilir cevap ve verilmemesi gereken bilgiyi içerir. Yanlış cevap çıktığında “model kötü” demeden önce bu zinciri inceleyin. Kaynak yoksa belge yönetimi, kaynak var ama bulunmuyorsa getirme, doğru kaynak kullanıldığı halde cevap yanlışsa üretim veya sunum aşaması araştırılabilir.

Bir modelin verdiği otomatik değerlendirme puanını nihai hakem saymayın. Özellikle kritik hatalar için alanı bilen bir kişinin incelemesini planlayın. Puanın neyi ölçtüğünü, hangi hata türünü kaçırabildiğini ve hangi örneklerin elle kontrol edildiğini rapora ekleyin. Böylece gösterişli bir yüzde, açıklanamayan güven duygusu üretmez.

Özgün bir değerlendirme setini nasıl kurabilirsiniz?

Aşağıdaki 120 soruluk dağılım, pilot tasarımı için bir örnektir; bilimsel yeterlilik eşiği veya bütün projelerde zorunlu sayı değildir. Gerçek dağılım belge yapısına, kullanıcı çeşitliliğine ve hata maliyetine göre belirlenmelidir.

Geliştirme sırasında kullanılan örneklerle son kabul örneklerini ayırın. Ekibin bütün cevapları ezberlediği bir liste, bilinmeyen sorulara genelleme hakkında sınırlı bilgi verir. Tarih, ürün kodu, kısaltma ve benzer isimli dokümanları da örneklere dahil edin. Hassas gerçek verileri kontrolsüz bir test dosyasına kopyalamak yerine uygun sentetik veya korunmuş test verisi kullanın.

Kaynak göstermek, doğru olmakla aynı şey değildir

Yanıtın altında bağlantı bulunması iyi bir başlangıçtır, fakat bağlantının iddiayı gerçekten desteklemesi gerekir. “Bu ürün dış mekâna uygundur” yanıtının bağlandığı doküman yalnızca ölçü bilgisini içeriyorsa, kaynak görünmesine rağmen dayanak eksiktir. Kabul formunda kaynak varlığı ve kaynak desteğini ayrı işaretleyin.

Doküman sürümü de görünür olmalıdır. Örneğin eski fiyat politikası ile yeni fiyat politikası aynı başlıkla duruyorsa, yalnız anlamsal benzerlik yeterli karar vermez. Yayın durumu, geçerlilik tarihi ve belge sahibi gibi bilgilerin nasıl kullanıldığını tanımlayın. Güncel olmayan fakat tarihsel soruyu yanıtlayan belgeyi tamamen silmek yerine kullanım amacını ayırabilirsiniz.

Belgede cevap yoksa sistemin ne söyleyeceğini baştan yazın. Önerilen davranış, eksik bilgiyi belirtmek, gerekiyorsa daraltıcı soru sormak ve yetkili kişiye yönlendirmektir. Her soru için uzun yanıt üretmek başarı değildir. Bazı sorularda kontrollü biçimde cevap vermemek doğru ürün davranışıdır.

Yetkiyi modelin iyi niyetine bırakmayın

Kullanıcının görmemesi gereken bir belgeyi önce modele gönderip sonra “bunu açıklama” demek, güvenilir bir erişim sınırı olarak kabul edilmemelidir. Önerilen tasarımda kaynak adayları kullanıcı ve kuruluş yetkisine göre sınırlandırılır; belge indirme ve sonraki işlem çağrılarında da uygulama yetkilendirmesi çalışır. OWASP’nin her istekte yetki doğrulama ilkesi bu sınırın uygulama tarafında kurulmasını destekler. [3]

Arama önbelleği, sohbet geçmişi ve rapor çıktıları için de aynı soruyu sorun. Bir yöneticinin yanıtı daha sonra standart çalışana gösteriliyor mu? Kullanıcı başka kuruluşa geçtiğinde önceki konuşmadaki bilgiler nasıl ele alınıyor? Yetki kaldırılmış belge, getirme dizini ve önbellekte hangi süreçle etkisizleşiyor? Bunlar yalnızca model seçimiyle çözülen sorunlar değildir.

Test senaryosunda aynı soruyu farklı rollerde sorun. Başarı ölçütü iki kullanıcıya aynı düzgün cümleyi vermek değil, her birine izinli bilgiyle doğru davranmaktır. Test sonucunda görülen örneklerin yanında, hiç incelenmemiş belge sınıflarını da açıkça listeleyin.

Harici belgedeki talimatı şirket kararı sanmayın

OWASP, web sayfası veya dosya gibi dış içeriklerden gelen dolaylı prompt injection riskini açıklar; RAG kullanmak bu riski tümüyle ortadan kaldırmaz. En az yetki ve yüksek riskli işlemlerde insan onayı, olası etkinin sınırlandırılmasına yönelik önlemler arasındadır. [2]

Önerilen tasarımda belge içeriği bilgi kaynağıdır, uygulamaya sınırsız yetki veren komut değildir. Asistanın bir işlem önermesi ile uygulamanın o işlemi yapması ayrı adımlar olsun. Kullanıcı, hedef kayıt ve işlem parametreleri sunucu tarafından doğrulansın. İndirim onayı, veri silme veya dışarı mesaj gönderme gibi işlemler için açık onay akışı değerlendirilsin.

Kontrollü testlerde yönlendirici belge içeriğinin işlem yetkilerini değiştiremediğini inceleyin. Amaç gerçek sistemlere saldırmak değil, size ait test ortamındaki sınırları doğrulamaktır. Kritik bir yetki ihlali, diğer sorulardaki iyi yanıt ortalamasıyla kapatılmamalıdır.

Pilottan canlı kullanıma geçişi nasıl tanımlamalı?

Tek bir toplam puan yerine hata sınıflarıyla rapor hazırlayın: yanlış kaynak, desteklenmeyen iddia, eski sürüm, yetki ihlali, cevap verilmesi gereken yerde ret ve gecikme. Bazı sınıflar için sıfır toleranslı kabul koşulu koyabilirsiniz; bu, testlerin bütün olası hataları dışladığı iddiası değildir. Kritik senaryolar geçmeden pilotu genişletmeyin.

Maliyet ve bekleme süresini de iş sonucu üzerinden değerlendirin. Bin başarılı cevabın maliyeti ile bin API çağrısının maliyeti aynı ölçü değildir; yeniden deneme ve insan kontrolü dahil olabilir. Düşük maliyetli fakat çok sayıda düzeltme gerektiren çözümün operasyon yükünü görünür tutun.

Daha büyük model seçmek bütün kalite sorunlarını çözer mi?

Hayır. Eksik veya yanlış yetkilendirilmiş kaynak, karışık doküman sürümü ve hatalı kabul ölçütü ayrı problemlerdir. Önce hangi aşamanın hatayı ürettiğini bulun; sonra model, getirme veya veri düzeni değişikliğini aynı test setiyle karşılaştırın.

Asistanı hemen otomatik işlem yapacak şekilde açmalı mıyız?

Pilotun işine göre karar verin. Önce okuma ve taslak önerme gibi sınırlı yetkiyle başlamak, gözlem için daha kontrollü bir seçenek olabilir. Sonraki her işlem yetkisi kendi kabul testiyle değerlendirilmelidir. Kurumsal yapay zekâda güçlü ürün, her şeyi yapan değil, yapabildiği işi ve sınırlarını güvenilir biçimde gösteren üründür.