Halüsinasyonu canlı yakaladım ve bir ürün kuralı oldu

Bir ticari ERP’nin üstüne, yöneticinin normal cümlelerle soru sorabildiği bir katman kuruyorduk. “Geçen ay en çok hangi ürün satıldı”, “şu müşterinin vadesi ne durumda” gibi. Ürünün adı READERP oldu.

Böyle bir üründe asıl iş modelde değil, entegrasyonda: API kapalı belgelenmiş, alan adları kısaltmalarla dolu, hangi ucun ne döndüğü ancak deneyerek anlaşılıyor.

Ürün reçetesi sorusu

Bir mamulün hangi hammaddelerden oluştuğunu okumak gerekiyordu. Modele sordum: bu ERP’de reçete verisi hangi uçtan alınır?

Cevap net, düzgün biçimlendirilmiş ve kendinden emindi:

GET /api/BillOfMaterials/{stokKodu}
→ { "items": [ { "componentCode": …, "quantity": … } ] }

Gayet makul. Bir ERP’de tam da böyle bir uç olmalı. İsimlendirme tutarlı, yanıt yapısı mantıklı.

Öyle bir uç yok.

Gerçeği bulmak

Doğrusunu bulmak için modele değil, kaynağa gittim — API’nin denetleyici dosyalarına:

IReceteAna                  ← gerçek arayüz adı
GET /BOM                       ← mamul özeti listesi
GET /BOM/{kod}                 ← detay, ayrı çağrı

Üstelik iki kademeli: liste yalnız mamul özetini veriyor, bileşenler için her mamul ayrı çağrılıyor. Modelin önerdiği tek çağrılık yapıdan tamamen farklı bir entegrasyon tasarımı gerektiriyor.

Doğrulamasaydım, üzerine bir haftalık iş kurup çalışmayan bir şey inşa edecektim.

Asıl tehlike yanlışlık değil

Beni asıl düşündüren kısım şuydu: yanlış cevap ile doğru cevap aynı görünüyordu.

Model “emin değilim” demedi. Tonunu değiştirmedi. Yanına bir uyarı koymadı. Doğrulanmış bir bilgiyle uydurulmuş bir bilgi, ekranda birbirinin aynısıydı.

Halüsinasyon yanlış cevap değildir. Doğrulanmamış ama doğru gibi duran cevaptır. Aradaki tek fark, kimsenin bakmamış olmasıdır.

Ürün kuralı buradan çıktı

Yönetici bir ekrana bakıp karar verecekse, o ekrandaki her sayının nereden geldiğini sistem bilmek zorunda.

Kural: her alan kaynağını taşır; kaynağı olmayan alan ekrana çıkmaz.

{
  "deger": 1284900,
  "kaynak": {
    "tablo": "TBLSTOKURM",
    "sorgu_id": "q7f3",
    "zaman": "2026-08-25T14:02:11+03:00"
  }
}

Model artık cevap üretmiyor; cevabın nereden alınacağını buluyor. Sayıyı veritabanı veriyor, modelin işi doğru sorguyu kurmak ve sonucu insanın anlayacağı cümleye çevirmek.

Bu ayrım küçük görünüyor ama ürünün tamamını belirliyor: model bir bilgi kaynağı değil, bir arayüz. Aynı ilkeyi ürün kataloğu aramasında da uygulamıştım.

Yan faydası: tartışma biter

Beklemediğim bir kazanç: yönetim raporlarında “bu sayı yanlış” tartışmaları bitti.

Eskiden bir rakam sorgulandığında kimse kaynağını hatırlamıyordu; hesap tablosunda bir formül vardı, kimin ne zaman yazdığı belirsizdi. Şimdi sayının yanında hangi veriden, ne zaman üretildiği duruyor.

Tartışma “bu sayı yanlış”tan “bu kaynak yanlış”a taşınıyor — ve ikincisi çözülebilir bir tartışma.

Ne öğrendim

AI’ı bir projede kullanırken sorulacak soru “ne kadar doğru?” değil. “Yanlış olduğunda bunu nasıl anlarım?”

Bu soruya cevabın varsa, modelin hata payı bir mühendislik parametresine dönüşüyor. Cevabın yoksa, ne kadar iyi olursa olsun üzerine bir şey kuramazsın.