AI halüsinasyonlarını yakalama: 3 koruma katmanı

AI halüsinasyonu pratikte neye benziyor?

Halüsinasyon, modelin emin görünen ama yanlış bir cevap üretmesidir. B2B'de üç klasik şekilde karşımıza çıkar: (1) müşteri sorgusu için var olmayan bir sipariş numarası uydurma, (2) sözleşmeyi özetlerken kaynakta olmayan bir tarihten "alıntı" yapma, (3) fatura sınıflandırırken kategoriler dışında yeni bir tane icat etme.

Üçü de aynı kalıba sahip: model, gerçek bir dayanak bulamadığında boşluğu doldurur. Sorun, çıktının özgüvenli görünmesidir — yanlış olsa bile. "AI yanlış" demek yeterli değil; nerede ve niye yanlış olduğunu yakalamak gerekir. Aşağıdaki üç koruma katmanı bunu yapar.

Üç koruma katmanı: kaynak, kural, insan

Kaynak kontrolü: yanıtla birlikte belgeyi ve ilgili bölümü gösterin; yalnız kaynak kimliğinin varlığını değil, iddiayı gerçekten desteklediğini doğrulayın. Kaynak yoksa veya belgeler çelişiyorsa işlem incelemeye gitmelidir.

Kural kontrolü: siparişin gerçekten varlığını, kullanıcının yetkisini, tutarı ve izin verilen kategorileri uygulama tarafında denetleyin. Doğru biçim, doğru bilgi demek değildir.

İnsan onayı: ödeme, iade veya bağlayıcı mesajdan önce yetkili kişi kesin çıktıyı görmelidir; onaydan sonra değişen çıktı yeniden onay ister. Bu katmanların evrensel başarı yüzdesi yoktur. Doğru, yanlış ve eksik kaynak içeren örneklerle geçersiz çıktının durduğunu; inceleme kuyruğunun sorumlu kişiye ulaştığını sınayın.

Üretime çıkmadan önce: değerlendirme süreci kurmak

Halüsinasyon oranını çıktılara göz atarak yakalayamazsınız; bir test setine ihtiyacınız var. Bilinen doğru cevaplara sahip 50-200 gerçek örnekten oluşan bir "altın set" oluşturun — eksik veri, belirsiz sorgular, kapsam dışı istekler gibi uç durumları da içersin. Bu kümeyi yalnızca ilk yayından önce değil, her istem veya model değişikliğinden sonra, değişikliği yayımlamadan önce yeniden sınayın.

İki metriği ayrı takip edin: doğruluk (doğru cevabı verdi mi) ve çekimser kalma oranı (yanıt vermekten ne sıklıkla kaçındı). Hiç çekimser kalmayan bir model, yanıtlayamayacağı sorulara da yanıt verebilir; çok sık çekimser kalan bir modelin yararlılığı azalabilir. Güvenliği yalnız bu orana bakarak değerlendirmeyin. Uygun eşik, yanlış bir yanıt vermenin maliyeti ile hiç yanıt vermemenin maliyeti karşılaştırılarak belirlenmelidir.

Olağan durum testi kadar saldırgan (adversarial) test de önemlidir — modeli bilinçli olarak halüsinasyonu tetikleyecek sorgularla besleyin: var olmayan varlıklar hakkında sorular, iki kaydı karıştıran istekler, kaynağın ötesine ekstrapolasyon yapmasını isteyen istemler. Kontrollü bir testte hatasını güvenli biçimde yönetemiyorsa, canlı kullanımda da bunu başarması beklenemez.

Bunu tek seferlik bir kapı değil, yaşayan bir hat olarak ele alın. İstemi her değiştirdiğinizde, model değiştirdiğinizde veya yeni bir kaynak belge eklediğinizde, dağıtımdan önce değerlendirme setini yeniden çalıştırın ve yeni doğruluk/çekimser kalma sayılarını referans değerle karşılaştırın. Bu, geleneksel yazılımdaki regresyon testiyle aynı disiplindir — sadece mantık yerine muhakemeyi test eder.

Hangi görevler halüsinasyon riski taşır

Riski yalnız metnin serbest veya yapılandırılmış olmasına göre sıralamayın. Geçerli kategorideki yanlış bir muhasebe kaydı da zararlı olabilir. Etkiyi, geri alınabilirliği, verinin hassasiyetini ve çıktıyı kimin kullanacağını değerlendirin. Sadece taslak hazırlayan akış ile müşteriye mesaj gönderen veya para hareketi başlatan akış aynı yetkiye sahip olmamalıdır.