AI halüsinasyonunu sıfırlamak değil, yönetmek gerekir

AI projelerinde en sık sorulan sorulardan biri şudur:

“Halüsinasyonu nasıl engelleyeceğiz?”

Bu soru haklıdır. Çünkü kurumsal ortamda yanlış ama kendinden emin bir cevap ciddi güven kaybı yaratabilir. Bir müşteri koşulu yanlış yorumlanabilir. Bir finansal veri hatalı açıklanabilir. Bir sözleşme maddesi olmayan bir anlamla özetlenebilir. Bir yönetim raporunda yanlış gerekçe yazılabilir.

Ama sorunun daha dürüst bir versiyonu gerekir.

“Halüsinasyonu tamamen sıfırlar mıyız?” değil.

“Halüsinasyon riskini nasıl görünür, sınırlı, ölçülebilir ve yönetilebilir hale getiririz?”

Çünkü AI sistemlerinde hatayı tamamen yok ettiğini iddia etmek gerçekçi değildir. Özellikle açık uçlu dil üretimi, doküman yorumlama, özetleme, araştırma ve karar hazırlığı gibi alanlarda belirsizlik her zaman vardır.

Kurumsal güven, “AI hiç hata yapmaz” iddiasıyla kurulmaz. AI hata yaptığında sistemin nasıl davrandığıyla kurulur.

Halüsinasyon tek tip hata değildir

Halüsinasyon kelimesi genellikle AI’ın tamamen uydurma cevap vermesi gibi düşünülür. Bu doğru olabilir, ama kurumsal sistemlerde hata türleri daha çeşitlidir.

Bir AI sistemi olmayan bir bilgiyi varmış gibi söyleyebilir. Eski bir dokümanı güncel sanabilir. İki kaynağı karıştırabilir. Bağlam dışı doğru bilgiyi yanlış yerde kullanabilir. Belirsiz bir sonucu kesin dille yazabilir. Kaynağı olan bir cevabı yanlış yorumlayabilir. Kullanıcı yetkisi olmayan bir bilgiyi dolaylı şekilde sızdırabilir.

Bu hataların hepsi aynı şekilde yönetilmez.

Bu yüzden ilk adım, halüsinasyonu genel bir korku başlığı olarak değil, hata tipleri olarak ele almaktır.

Örnek hata tipleri:

• Kaynaksız iddia
• Yanlış kaynak kullanımı
• Eski versiyona dayanma
• Eksik bağlamla fazla kesin cevap
• Çelişkili kaynakları fark etmeme
• Sayısal veri hatası
• Yetki dışı bilgi sızıntısı
• Riskli aksiyon önerisi
• Kullanıcı niyetini yanlış anlama

Her hata türünün risk seviyesi ve yönetim yöntemi farklıdır.

Kaynaklandırma güvenin temelidir

Kurumsal AI sistemlerinde kaynak göstermek çoğu kullanım alanında opsiyonel olmamalıdır.

Özellikle doküman cevabı, sözleşme yorumu, fiyat koşulu, KPI açıklaması, politika bilgisi veya finansal metinlerde kaynak görünmeden cevap güvenilir sayılmamalıdır.

Kaynaklandırma üç şey sağlar.

Birincisi, kullanıcı cevabı kontrol edebilir.
İkincisi, sistemin hangi bilgiye dayandığı görünür olur.
Üçüncüsü, hata olduğunda düzeltme yapılabilecek nokta belirlenir.

Ama kaynak göstermek sadece dosya linki vermek değildir. “Bu bilgi X dosyasında geçiyor” demek çoğu zaman yetersizdir. Mümkünse sayfa, madde, bölüm, tablo veya paragraf seviyesi gösterilmelidir.

Kaynaklandırma iyi tasarlanmadığında kullanıcı hâlâ cevaba körlemesine güvenmek zorunda kalır. Bu da kurumsal kullanım için zayıf bir zemindir.

“Bilmiyorum” diyebilmek sistem kalitesidir

İyi AI sistemi her soruya cevap veren sistem değildir.

İyi AI sistemi, hangi durumda cevap vermemesi gerektiğini bilen sistemdir.

Bu, özellikle kurumsal kullanımda kritiktir. Kullanıcı çoğu zaman güvenilirlik ister; akıcı cevap değil.

Sistem şu durumlarda net şekilde durabilmelidir:

• Kaynak bulunamadığında
• Kaynaklar çeliştiğinde
• Bilgi eski olduğunda
• Kullanıcının yetkisi sınırlı olduğunda
• Veri eksik olduğunda
• Sayısal hesap güvenilir olmadığında
• Karar etkisi yüksek olduğunda
• İnsan onayı gerektiğinde

Örneğin sistem “Bu konuda elimde güvenilir kaynak yok” diyebilmelidir. Ya da “Bu cevap iki farklı dokümanda farklı geçiyor; kesin yorum için ilgili ekip kontrolü gerekir” diyebilmelidir.

Bu cümleler zayıflık değildir. Güven mimarisidir.

Belirsizliği saklayan sistem daha etkileyici görünebilir. Ama belirsizliği gösteren sistem daha güvenilirdir.

RAG tek başına çözüm değildir

Birçok kurum halüsinasyon riskini azaltmak için retrieval augmented generation, yani RAG yaklaşımına yönelir. Basitçe, modelin cevap üretmeden önce ilgili dokümanlardan bilgi çekmesi hedeflenir.

Bu doğru bir adımdır. Ama tek başına yeterli değildir.

RAG sistemi yanlış dokümanı çekebilir. Doğru dokümanın eski versiyonunu kullanabilir. İlgili parçayı bulup yanlış yorumlayabilir. Çelişkili kaynakları birlikte değerlendiremeyebilir. Kullanıcı yetkisi olmayan kaynağı sisteme sokabilir. Kaynağı olsa bile cevabı fazla kesin kurabilir.

Bu yüzden RAG “halüsinasyonu bitiren teknoloji” gibi satılmamalıdır. RAG, doğru tasarlandığında halüsinasyon riskini azaltan bir mimari parçadır.

Yanına şunlar gerekir:

• Doküman envanteri
• Versiyon kontrolü
• Yetki yönetimi
• Kaynak gösterimi
• Belirsizlik kuralları
• Eval seti
• İnsan onayı
• Hata geri bildirim döngüsü

Tek başına retrieval, güven sistemi değildir.

Eval seti olmadan kalite yönetilemez

AI sistemlerinde kalite hissiyatla yönetilemez.

Bir demo sırasında sistem iyi cevap verebilir. Ama bu, sistemin gerçek kullanımda güvenilir olduğu anlamına gelmez.

Eval seti, sistemin düzenli olarak test edildiği örnekler kümesidir. Sadece başarılı örnekleri değil, zor ve riskli örnekleri de içermelidir.

İyi bir eval setinde şu örnekler bulunabilir:

• Kaynaklı doğru cevap beklenen sorular
• Kaynak bulunmaması gereken sorular
• Eski ve yeni versiyon çakışmaları
• Çelişkili dokümanlar
• Sayısal hesap gerektiren durumlar
• Yetki sınırı olan içerikler
• Riskli aksiyon önerileri
• İnsana eskale edilmesi gereken durumlar
• Kullanıcının belirsiz sorduğu sorular

Bu set olmadan her yeni model, prompt veya retrieval değişikliği sezgisel değerlendirilir. “Daha iyi gibi” görünür. Ama hangi hata türünün azaldığı, hangisinin arttığı bilinmez.

Eval seti, halüsinasyon yönetiminin ölçüm zemini olmalıdır.

İnsan onayı nerede gerekir?

Her AI çıktısı insan onayı gerektirmez. Ama bazı alanlarda onay sistemin parçası olmalıdır.

Özellikle şu durumlarda insan kontrolü gerekir:

• Dış müşteriye gidecek metin
• Ticari taahhüt içeren cevap
• Fiyat, iskonto veya marj etkisi olan öneri
• Hukuki veya finansal yorum
• Yönetim sunumuna girecek kritik açıklama
• Kaynağı çelişkili cevap
• Düşük güvenli ürün / doküman eşleşmesi
• Yüksek etkili karar hazırlığı

İnsan onayı sadece “yanlış çıkmasın” diye değil, sorumluluk netleşsin diye de gereklidir.

AI önerir, hazırlar veya özetler. Ama bazı kararların sahibi insan kalmalıdır.

Hata döngüsü tasarlanmalı

Kurumsal AI sisteminde hata olduğunda ne olacak?

Kullanıcı hatayı işaretleyebilecek mi? Hata tipi sınıflandırılacak mı? Teknik ekip mi görecek, iş sahibi mi? Aynı hata tekrar ederse sistem nasıl düzeltilecek? Hata doküman kaynaklı mı, retrieval kaynaklı mı, prompt kaynaklı mı, model kaynaklı mı?

Bu sorular net değilse hatalar bireysel şikâyet olarak kalır. Sistem öğrenmez.

İyi bir hata döngüsü şunları içerir:

• Kullanıcı feedback butonu
• Hata tipi sınıflandırması
• Öncelik seviyesi
• Sorumlu ekip
• Düzeltme aksiyonu
• Eval setine ekleme
• Versiyon sonrası tekrar test

Bu yapı olmadan halüsinasyon yönetimi reaktif kalır. Her hata ayrı olay gibi ele alınır. Oysa amaç, hata örüntülerini yakalamak ve sistemi düzenli iyileştirmektir.

Güven dili de önemlidir

AI sistemleri sadece doğru veya yanlış cevap üretmez. Aynı zamanda güven hissi üretir.

Cevabın dili bu yüzden önemlidir.

“Kesinlikle böyledir” dili ile “erişebildiğim kaynaklara göre” dili aynı değildir. “Bu karar alınmalıdır” dili ile “bu seçenek değerlendirilebilir” dili aynı değildir. “Veri bunu gösteriyor” dili ile “mevcut veri bu yorumu destekliyor, ancak şu sınırlara dikkat edilmeli” dili aynı değildir.

Kurumsal sistemlerde cevap dili şu ilkelere uymalıdır:

• Kaynağı olmayan yerde kesin konuşmamalı
• Tahmin ile bilgiyi ayırmalı
• Varsayımları açık etmeli
• Riskli öneriyi karar gibi sunmamalı
• Yetki ve onay ihtiyacını belirtmeli
• Belirsizliği saklamamalı

Bu ton, premium B2B kullanım için kritiktir. Çünkü güven sadece teknik doğrulukla değil, doğru dozda iddia ile oluşur.

Sonuç

AI halüsinasyonunu tamamen sıfırladığını iddia etmek güven verici değil, riskli bir dildir.

Daha olgun yaklaşım, halüsinasyon riskini yönetilebilir hale getirmektir. Bunun için kaynaklandırma, belirsizlik yönetimi, yetki kontrolü, eval seti, insan onayı, hata geri bildirimi ve doğru güven dili birlikte tasarlanmalıdır.

Kurumsal AI sistemlerinde güven, modelin hiç hata yapmayacağı varsayımına dayanamaz.

Güven, sistemin hata riskini nasıl sınırladığına, nasıl görünür kıldığına ve nasıl öğrendiğine dayanır.