Decisions API, halüsinasyon dedektörleri ve ajan belleği: AI karar veriyor, insan onaylıyor

OpenAI, Decisions API'yi genel kullanıma açtı: sınırlı seçenekli sorulara hızlı yanıt, evet ya da hayır, listeden biri, ölçekte puan. IBM aynı türden kararları sohbet ve konuşma tanımayla birlikte tek modelde topladı. n8n ise iki günde modelin uydurmalarını nasıl yakalayacağınıza ve belleğini nerede tutacağınıza dair üç inceleme yayımladı. İşletme sahibi için tek soru var: hangi kararlar modele emanet edilebilir, hangilerini çalışan onaylamalı.

Ne çıktı

OpenAI 22 Ekim'de Decisions API'nin betadan çıktığını duyurdu. Geliştirici soruyu ve kabul edilebilir yanıtları belirliyor, metin, görsel veya JSON gönderiyor ve üç yanıt türünden birini alıyor: 0 ile 1 arasında olasılık, güven değeriyle listeden seçim veya ölçekte puan. OpenAI yanıtın aynı GPT-6 Luna modelinin sıradan Responses API üzerinden verdiğine göre 10 kata kadar hızlı geldiğini yazıyor. Box belgeleri sınıflandırıp yönlendiriyor: 30 sigorta sertifikasında rota aynı doğrulukla yaklaşık 5 kat hızlı seçildi, düşük güvenli belgeler insan kontrolüne gidiyor. Sierra müşteriyle canlı konuşmada sonraki adımı 280 ms'den kısa sürede seçiyor ve çağrı başına %90 daha az ödüyor.

IBM 15 Ekim'de Hugging Face blogunda 8B ve 30B parametreli Granite Switch 4.1'i gösterdi. Fikir farklı. Ayrı bir servis yerine tek temel modelin üzerine adaptörler: karar adaptörü, zarar kontrolü için Guardian adaptörü ve gömülü Turbo CTC konuşma modeli GPU'da yaklaşık olarak temel modelin tek başına kapladığı kadar bellek kaplıyor. Adaptörler KV önbelleğini paylaşıyor, bu yüzden model yanıtından sonraki karar neredeyse bedavaya geliyor. Modeli kendinde tutanlar için bu, Decisions API'ye doğrudan bir yanıt.

n8n 22 Ekim'de ajan süreçlerinde halüsinasyon tespit yöntemlerini inceledi. Dört hata türü var: uydurulmuş olgu, verilen bağlamın dışında yanıt, tamamlanmış ayrıntılar ve kendisiyle çelişme. Bunları yakalamanın da beş yolu var, bağlama dayanma kontrolünden insana devretmeli güven eşiklerine kadar. Benim için ana cümle: eşik, hatanın bedelini yansıtmalı. İç özet bir yanlışlığı kaldırır, müşteri kaydının değiştirilmesi kaldırmaz.

Aynı gün n8n ajanlarda stateful ve stateless yaklaşımı karşılaştırdı: model istekler arasında kendi başına hiçbir şey hatırlamıyor, bu yüzden durum dışarıda, veritabanında veya önbellekte yaşıyor, istek işleyiciler ise durumsuz kalıyor. Ertesi gün, 23 Ekim'de, Cognee'den Veljko Kovač'ın ajan belleği üzerine konuk incelemesi çıktı: kısa süreli bellek geçerli oturumda, uzun süreli bellek ayrı bir depoda. RAG okur, geri yazmaz; ajan belleği, ajanın yazdığı yerde başlar.

İşletme için ne anlama geliyor

Araç kiralamayı ele alalım. E-postaya fotoğraflı bir mesaj geliyor: “işte araç, yolculuktan sonra”. İlk kararlar küçük: bu bir iade mi, şikayet mi, ödeme sorusu mu; fotoğrafta görünür hasar var mı; çizikten göçüğe uzanan ölçekte ne kadar ciddi. Decisions API ve benzeri modeller tam da böyle sorular için yapılmış: yanıt ucuz ve hızlı, hemen talebin alanına yazılabilir. Ama sonraki karar, müşterinin depozitosundan kesinti yapılıp yapılmayacağı, paraya ve ilişkiye mal olur. Onu çalışan onaylar. Model talebi hazırlar, insan düğmeye basar.

Buradan çıkan sonuç: kararları hatanın bedeline göre ayırın. Sınıflandırma ve yönlendirme güven eşiğiyle otomatik gider. Parayı, sözleşmeyi veya müşteri kaydını değiştiren her şey onaydan geçer.

Bende nasıl işliyor

ABD'deki PDR şirketi için yaptığım belge ayrıştırıcılarda buna pratikte vardım. Ayrıştırıcılar sigorta keşiflerini, tutanakları ve VIN'li fotoğrafları okuyor. Onları 2023'te yapmaya başladım, 2023 ortasından beri çalışıyorlar: o zaman belgelerin yaklaşık yarısı elle düzeltme olmadan geçiyordu. 2024'te yeni tanıma yöntemlerine geçtim, düzeltmesiz geçen oran yaklaşık %75 oldu. 2025'te yeni veriler ve hesaplamalar ekledim, oran yaklaşık %95'e çıktı. 2026'da AI doğrulayıcıları bağladım ve sürüm halini yayımladım: belgelerin yaklaşık %99,9'u elle düzeltme olmadan geçiyor.

Doğrulayıcı üç tane, Anthropic, OpenAI ve Gemini servislerinde, her biri kendi görevi için. Kontrolün içeride nasıl kurulduğunu açıklamıyorum. İlke n8n'in anlattığıyla aynı: tek bir puan yerine birkaç bağımsız kontrol, son söz ise sonucu gören ve onaylayan çalışanda. Ayrıştırıcılar haftada yaklaşık 60 saatlik el işini serbest bırakıyor. Decisions API'yi kendimde denemedim; onu gelen belgelerin yönlendirilmesinde denerdim, ana ayrıştırmadan önce “bu ne ve nereye” yanıtının gerektiği yerde.

Ben ne yapardım

Süreçteki bütün küçük kararları yazardım: belge türü, aciliyet, kime devredilecek. Her biri için kabul edilebilir yanıtları belirlerdim. Yanıtlar sayılamıyorsa bu, karar modeli için bir görev değildir.

Her karar için hatanın bedelini adlandırırdım. Ucuz hatalar otomatik gider, pahalılar onaydan geçer. Güven eşiğini bu bedele göre koyardım, ortalama kaliteye göre değil, ve her kararı girdisi ve güven değeriyle birlikte kayda geçirirdim. Bir ay sonra günlükten modelin nerede yanıldığı ve eşiğin nereye kaydırılacağı görünür.

Durumu modelin dışında tutardım: veritabanında, talep numarası ve adım geçmişiyle. O zaman çalışan modelin neye ve neden karar verdiğini görür.

Tek bir karar türüyle ve insan kontrolü için tek bir kuyrukla başlardım. Gerisini, ilk kuyruk şaşırtmayı bıraktığında bağlardım.

İlgili yazılar

Model sonucunun kontrolü hakkında: Veri işlemede AI: çıkarma ve doğrulama yazısı ve Sonucu doğrulanabilen süreçte AI sayfası. Ayrıştırıcılarla ilgili vaka: ABD'deki PDR şirketi haftada yaklaşık 60 saat kazanıyor. Aynı konudaki yazılardan: 2026'da belgelerden veri çıkarma, AI müşteri hakkında ne hatırladı ve veritabanınızın üstünde model. Daha önce AI ajanlarının güvenilirliği ve süreç kontrolü ile AI ajanı nasıl test edilir hakkında yazmıştım. Sürecinizde çalışanın şablona göre verdiği kararlar varsa, hangileri olduğunu anlatın. Görevi konuşalım.