Deterministik Teslimat Bir Model Ayarı Değil, Mimari Bir Karardır

Yapay zeka ajanları geliştirirken karşılaşılan güvenilirlik sorunları genellikle yanlış kategoride ele alınır. Edumints öğrenme yolculuğunda Production'da Agent Güvenilirliği ve Agent Monitoring ve Debugging konularında da vurgulandığı üzere, sağlam sistemler kurmak sadece model parametreleriyle oynayarak değil, doğru yazılım mimarisiyle mümkündür.

1. Tartışma Yanlış Başlık Altında Yürütülüyor#

Ajan güvenilirliği üzerine yapılan tartışmaların çoğu birer "model problemi" olarak sınıflandırılır. Önerilen çözümler genellikle daha güçlü bir model seçmek, temperature değerini düşürmek, sistem istemini (system prompt) uzatmak, farklı bir çatı (framework) kullanmak veya daha fazla değerlendirme (eval) eklemektir. Bunların hepsi yardımcı olabilir; ancak hiçbiri kararın gerçekte nerede alındığını değiştirmez.

Güvenilirlik, modelin kendi özelliği değil, onu çevreleyen mimarinin bir özelliğidir. Hangi kararların modele bırakıldığı, hangilerinin standart kod tarafından verildiği ve sistemin sonradan bu ikisini ayırt edecek kadar kanıt tutup tutmadığı asıl belirleyicidir. Deterministik teslimat (deterministic delivery) olarak adlandırılan bu teknik yaklaşım, karar mekanizmasının sınırlarını netleştirmeyi hedefler.

2. Bu Yaklaşım Gerçekte Ne Söylüyor?#

Deterministik teslimat; mimari düzeyde kontrol edilebilirlik, denetlenebilirlik ve yedekleme (fallback) mekanizmalarının bulunmasıdır. Bu kavram kesinlikle modelin her zaman doğru yanıt vereceği iddiası değildir; belirsiz bir e-postayı okuyan model, kusursuz bir omurga içinde bile hata yapabilir. Bu kavramdan bahsedebilmek için üç temel koşulun sağlanması gerekir:

• İzlenebilir kayıtlar: Her karar düğümü; girdileri, çıktıları, gecikme süresini ve karşılaması gereken kabul kriterini içeren tekrar oynatılabilir (replayable) bir kayıt bırakmalıdır.
• Kural ve anlam ayrımı: Kural mantığı yapısı gereği deterministik kalırken (aynı girdi, aynı durum geçişi, aynı denetim kaydı), anlamsal düğümler olasılıksal kabul edilmeli ve varsayılmak yerine ölçülmelidir.
• Hata konumlandırma: Bir hata yalnızca yanlış bir nihai yanıt olarak gözlemlenmemeli, doğrudan ilgili düğüme (node) nokta atışı olarak konumlandırılabilmelidir.

Buradaki "deterministik" ifadesi modelin çıktısını değil, sistemin doğaçlama yapmasına izin verilmeyen kısımlarını tanımlar.

3. Yol Ayrımı ve Diğer Tarafın Haklı Olduğu Noktalar#

Bu yaklaşımın alternatifi olasılıksal bir kara kutudur: Her adım bir sonrakine karar verir, durum (state) metin içinde yaşar, yeniden deneme (retry) sadece modele yapılan yeni bir çağrıdır ve yetkilendirme istemdeki nazik bir ricadan ibarettir. Çıktı hatalı olduğunda elinizde hatanın konumu değil, sadece bir metin paragrafı kalır.

Tek seferlik betikler, kullan-at prototipler veya yanlış yanıtın maliyetsiz olduğu dahili keşif çalışmaları için model çağrılarını zincirlemek daha ucuz ve dürüst bir seçimdir. Ancak hataların kaynağının belirlenmesi gerektiğinde, çıktılar dış kullanıcılara ulaştığında, denetim izi (audit trail) önem kazandığında veya birden fazla geliştirici sistemi demo sonrasında da sürdürmek zorunda olduğunda deterministik bir omurga şarttır. Asıl sınır şudur: Hangi kararlar muhakeme (judgement), hangileri kod farkı (diff) gerektirir?

4. Üç Kısıtlama, Tek Özellik#

Deterministik teslimat tek bir bileşenle değil, her biri kontrol edilebilir kriterlere ve karakteristik hata modlarına sahip üç mühendislik kısıtlamasının bir araya gelmesiyle ortaya çıkar:

• C1 — Hibrit Orkestrasyon (Hybrid Orchestration): Deterministik bir omurga; durum yönetimini, yeniden denemeleri, yetkilendirmeyi, denetim izlerini ve geri alma (rollback) işlemlerini tamamen üstlenirken, model yalnızca anlamsal çıkarım gerektiren dar kapsamlı düğümlerde görev alır.
• Pratik Geliştirici Çıkarımı: Üretim ortamına çıkarken yetkilendirme, durum geçişi ve hata yönetimi gibi kritik akışları asla prompt içine gömmeyin; bunları deterministik kod katmanında tutarak LLM'i yalnızca muhakeme motoru olarak konumlandırın.