Destek temsilcisi, bir kullanıcının iki faktörlü kimlik doğrulamayı sıfırlama talebine, aslında var olmayan adımlarla yanıt verdi. Yanıt güven verici görünüyordu, HTTP isteği 200 OK döndürdü, gecikme süresi normaldi ve tüm izleme grafikleri yeşil kaldı.

Yapay zeka destekli bir destek temsilcisi, hatayı yakalaması gereken dahili kontroller hiç çalışmadığı için halüsinasyon gördü. Mühendislerin güvendiği paneller kusursuz bir çalışma raporlarken, temsilci sessizce uydurma bir çözüm sundu.

Geleneksel paneller yapay zeka halüsinasyonlarını neden kaçırıyor?

Çoğu gözlemlenebilirlik yığını (observability stack), bir yapay zeka temsilcisini diğer tüm mikro hizmetler gibi ele alır: tek bir gelen istek ve tek bir giden yanıt. HTTP durum kodunu, yanıt süresini ve hata sayısını günlüğe kaydederler. Ancak isteğin içindeki gizli adımları —harici belgelerin getirilmesi, büyük dil modellerine yapılan çağrılar, yardımcı araçların kullanımı ve çıktıyı doğrulayan herhangi bir koruma mekanizması (guard-rail) mantığını— günlüğe kaydetmezler.

Bir veri getirme (retrieval) adımı boş bir sonuç döndürdüğünde, model genellikle bu boşluğu kulağa mantıklı gelen metinlerle "doldurur". İzleme sisteminin bakış açısına göre çağrı başarılıdır, çünkü hiçbir şey çökmemiştir ve durum kodu 200 olarak kalmıştır. Halüsinasyon görünmez kalır ve tek belirti, kullanıcıya ulaşan yanlış bir cevaptır.

Bir kara kutuyu okunabilir bir ağaca dönüştürmek

Güvenilir hata ayıklamanın (debugging) ilk adımı, temsilciyi monolitik bir çağrı olarak görmeyi bırakmak ve her dahili işlemi bir izleme tablosunda (trace table) kendi satırı olarak görselleştirmeye başlamaktır. Tipik bir çalışma şu adımlara ayrılır:

  • En üst düzey temsilci çağrısı
  • İlgili belgeleri çeken veri getirme (retrieval) adımı
  • Çekilen verileri işleyen her bir dil modeli çıkarımı (inference)
  • Her bir araç çağrısı (örneğin, veritabanı sorgusu, API isteği)
  • Gerçekliği veya politika uyumluluğunu zorunlu kılan koruma mekanizması (guard-rail) kontrolleri

Her satır zaman damgasını, başarı bayrağını ve o adımda iletilen veri yükünü (payload) kaydeder. Bu yapı sayesinde yürütme süreci, nihai çıktıdan tahmin yürütmek yerine satır satır incelenebilen bir ağaca dönüşür.

Gözden kaçan hata

Hatalı destek etkileşiminde izleme (trace) şu şekilde görünüyordu:

  1. Veri getirme çalıştı ancak belge döndürmedi.
  2. Bir sonraki adım, modele boş bir bağlam (context) aktararak yine de devam etti.
  3. Model, eksik bilgileri uydurma adımlarla dolduran bir yanıt oluşturdu.
  4. Sistem 200 döndürdü çünkü işlem hattı (pipeline) bir hata (exception) ile karşılaşmadı.

Halüsinasyon dil modelinin kendisindeki bir kusur değildi; veri getirme ve oluşturma aşamaları arasında eksik olan bir koruma mekanizmasıydı (guard-rail). Temsilci, yanıtını dayandırabileceği hiçbir veri olmasa bile cevap verdi.

Halüsinasyonları durduran basit koruma mekanizmaları (guard-rails)

İki somut değişiklik sorunu ortadan kaldırdı:

  • Boş veri getirmede işlemi durdur – eğer belge deposu hiçbir şey döndürmezse, temsilci oluşturma aşamasına geçmek yerine "İhtiyacınız olan bilgiyi bulamadım" şeklinde yanıt vermelidir.
  • Dayanak kontrolü (Grounding check) – model bir yanıt ürettikten sonra, her bir olgusal iddianın çekilen içerikte yer aldığını doğrulayın. Kontrol başarısız olursa yanıtı reddedin ve "cevap verilemiyor" yanıtına geri dönün.

Daha hızlı hata ayıklama için pratik bir iş akışı

  1. Her dahili çağrıyı izleyin – her veri getirme, model çıkarımı ve araç kullanımının kalıcı bir günlüğe satır yazması için temsilciyi ölçümleme araçlarıyla donatın (instrument).
  2. Hatalı çalışmaları saklayın – kullanıcının yanlış olarak bildirdiği her etkileşimin tam izini (trace) saklayın. Depolama alanından tasarruf etmek için bunları silmek, gerilemeleri (regressions) bulmak için gereken verileri gizler.
  3. Çalışmaları sürüm bilgisiyle etiketleyin – her izleme satırına sürüm tanımlayıcısını ve herhangi bir özellik bayrağı (feature-flag) durumunu dahil edin. Bu, yeni bir hatayı yakın zamanda yapılan bir kod değişikliğiyle ilişkilendirmenizi sağlar.
  4. Sadece hızı değil, kaliteyi de puanlayın – yanıtın talimatları ne kadar iyi izlediğini ve çekilen içeriğe ne kadar sadık kaldığını ölçen metrikler ekleyin. Yanıtlar yanlışsa, yüksek işlem hacminin (throughput) pek bir anlamı yoktur.
  5. Hataları günlük olarak inceleyin – saklanan hataların kısa ve düzenli bir incelemesi, hatalar birçok kullanıcıyı etkilemeden önce genellikle belirli kalıpları (örneğin, belirli bir sorgu türünün sürekli boş sonuç döndürmesi gibi) ortaya çıkarır.

Ekipler "yeşil" olanı "doğrulanmış" hale getirerek halüsinasyonları erkenden yakalayabilir ve kullanıcı deneyiminin güvenilir kalmasını sağlayabilir.

Dahili hataları görmezden gelmenin maliyeti

Paneller yalnızca HTTP katmanında başarı raporladığında, kuruluşlar güvenilir görünen ancak düzenli olarak yanlış yönlendirmeler yapan temsilciler yayına almış olurlar.

Sırada ne var?

Bunlar yaygınlaşana kadar, en güvenli yaklaşım her dahili işlemi gözlemlenebilir olarak ele almak ve kanıt eksik olduğunda hızlıca hata vermektir.

Özetle: Yeşil bir panel size altyapının çalıştığını söyler; ancak cevabın doğru olduğunu garanti etmez. Her bir veri getirme, model çağrısı ve guardrail kontrolünü izleyerek, gizli halüsinasyonları kullanıcıya ulaşmadan önce düzeltilebilecek görünür hatalara dönüştürürsünüz.