Agent iş akışları · 2026-09-16

Motif 3'te HTTP 200 dönen üç sessiz hata ve çözümleri

Motif 3 modelinde tool_choice none, stop dizisi ve reasoning_effort alanları hata döndürmeden çalışmaz görünür. Üçünün de ölçülmüş davranışını, neden 200 döndüklerini ve ajan kodunuzda nasıl önleyeceğinizi okuyun.

Sessiz hata nedir ve neden en pahalı hata türüdür?

Bir istek 400 dönerse kodunuz bunu görür, loglar, yeniden dener veya alarm üretir. Asıl sorun, isteğin 200 dönüp işe yaramaz bir cevap vermesidir: durum kodu başarılı, bitiş nedeni normal, ama elinizdeki veri kullanılamaz.

Bu tür hatalar izlemede görünmez. Hata oranı grafiğiniz düz kalır, gecikme grafiğiniz normaldir ve sorun ancak kullanıcı şikayetiyle veya aşağıdaki katmanda bir ayrıştırma hatasıyla ortaya çıkar. Ajan döngülerinde etkisi katlanır, çünkü boş bir cevap bir sonraki adıma girdi olur.

Motif 3 üzerinde ölçülen üç somut örnek var. Üçü de yaygın parametrelerle tetikleniyor ve üçünün de çözümü basit, yeter ki bilinsin.

Bir: tool_choice none araç çağrısını bastırmıyor

Beklenen davranış açıktır: isteğe araç tanımları eklediniz ama bu turda kullanılmasını istemiyorsanız tool_choice değerini none yaparsınız ve model düz metin yanıt verir.

Bu satırda olan farklı. Sağlayıcı çağrıyı bastırmak yerine ham araç çağrısı şablonunu yanıt metninin içine yazıyor ve isteği normal biçimde bitiriyor. Üç denemenin üçünde aynı sonuç alındı.

LLMTR bu isteği sağlayıcıya göndermeden durdurur ve ne yapmanız gerektiğini söyleyen bir 400 döndürür. Bunun tercih edilme sebebi ölçümün kendisidir: bir doküman uyarısı yetmez, çünkü ajan çerçeveleri isteği model kartından okudukları desteklenen parametrelere bakarak kurar, insanın okuduğu uyarıyı görmezler.

Doğru çözüm tek cümle: araçların kullanılmasını istemiyorsanız isteğe tools alanını hiç eklemeyin. tools yokken tool_choice none zararsızdır ve reddedilmez. Araç kullanımını yönlendirmek istiyorsanız auto, required veya adlandırılmış fonksiyon biçimlerini kullanın; üçü de çalışıyor.

tool_choice none ile ölçülen yanıt — LLMTR üzerinden ölçüldü, 16 Eylül 2026

request : tool_choice = "none", tools = [get_weather]
response: HTTP 200
          finish_reason = "stop"
          tool_calls    = []
          content       = "<tool_call>{\"name\": \"get_weather\", ...}</tool_call>"

İki: stop dizisi yanıtı tamamen boşaltabiliyor

Bu, üçünün içinde fark edilmesi en zor olanıdır, çünkü stop alanı gerçekten uygulanıyor. Sorun neyin üzerinde uygulandığı.

Model her yanıttan önce düşünür ve akıl yürütme metni görünen cevaptan önce üretilir. stop dizisi bu gizli metinle eşleşirse üretim orada durur ve görünen cevap hiç başlamaz. Sonuç: HTTP 200, normal bitiş nedeni ve boş bir içerik alanı.

Ölçüm bunu doğrudan gösteriyor. Bire ondan saymasını isteyen bir istemde, modelin düşünürken kullandığı bir kelime stop dizisi olarak verildiğinde cevap boş geliyor; modelin düşünürken kullanmayacağı uydurma bir dizi verildiğinde cevap bozulmadan geliyor.

Pratik kural: bu modelde stop kullanmayın. Kullanmanız gerekiyorsa modelin düşünürken kullanmayacağından emin olabileceğiniz bir dizi seçin, ki doğal dildeki hiçbir kelime için bundan emin olamazsınız. Yanıtı kısaltmak istiyorsanız max_tokens alanını kullanın veya çıktıyı şemaya bağlayın.

stop dizisi davranışı — LLMTR üzerinden ölçüldü, 16 Eylül 2026

prompt: "count from one to ten"

no stop sequence   -> "one two three ... ten"
stop: ["five"]     -> content: ""   finish_reason: "stop"   HTTP 200
stop: ["seven"]    -> content: ""   finish_reason: "stop"   HTTP 200
stop: ["ZZQQ"]     -> "one two three ... ten"

Üç: reasoning_effort ve akıl yürütme kapatma alanları kabul edilip yok sayılıyor

Bu vakayı özellikle sinsi yapan şey, alanın doğrulanıyor olmasıdır. Sağlayıcı none, minimal, xhigh ve max değerlerini 400 ile reddediyor, yani alan gerçek bir ölçek gibi davranıyor. Kabul ettiği üç değer ise birbirinden ayrışmıyor: low, high değerinden yaklaşık iki kat daha uzun düşünüyor ve aralıklar üst üste biniyor.

Aynı şey akıl yürütmeyi kapatma denemeleri için de geçerli. Üç farklı yöntem denendi, her biri için beş örnek alındı ve on beş denemenin hiçbirinde boş bir akıl yürütme metni görülmedi. Üçü de kabul ediliyor, üçü de hiçbir şeyi değiştirmiyor.

Bunun faturaya yansıması var: gizli akıl yürütme token'ları çıktı olarak sayılır. Ücretli bir satırda bu, kullanıcıyı azalttığını sandığı token'lar için ödetmek demek olurdu. Ücretsiz bu satırda ise gecikme olarak geri döner.

LLMTR bu yüzden bu satırda akıl yürütme seviyesi sunmaz ve model kartında reasoning ile include_reasoning alanlarını desteklenen parametre olarak ilan etmez. Alanlar geçişlidir, yani yine de gönderirseniz sağlayıcıya ulaşır; ama size bir söz verilmiyor.

İki ek gözlem: seed ve logprobs

seed alanı kabul ediliyor ama tekrarlanabilirlik sağlamıyor. Aynı seed değeriyle gönderilen iki özdeş istek farklı yanıt döndürdü. Sıcaklık sıfırda bile arka arkaya üç çağrı üç farklı cevap verdi, yani bu modelde belirlenimcilik beklemeyin.

logprobs alanı dolu bir blok döndürüyor, ancak içindeki token'lar görünen yanıt değil akıl yürütme metni. Görünen cevabın token olasılıklarına bakmak için kullanamazsınız; bakarsanız yanlış metnin istatistiğine bakmış olursunuz.

Ölçülebilen iki parametre ise gerçekten çalışıyor: sıcaklık çıktıyı gözle görülür biçimde etkiliyor ve top_p, yüksek sıcaklıkta bozulan çıktıyı karşıtlık ölçümünde geri toparlıyor. Bu ikisi model kartında desteklenen parametre olarak ilan edilir; edilmeyenler hakkında bir iddiada bulunulmaz.

tool_choice none: tools alanını hiç göndermeyin.
stop: bu modelde kullanmayın, yerine max_tokens veya şema kullanın.
reasoning_effort: bu satırda desteklenmez, göndermeyin.
seed: tekrarlanabilirlik için güvenmeyin.
logprobs: dönen token'lar görünen yanıta ait değildir.

Ajan kodunuzda ne değişmeli?

Birincisi, sessiz hataları görünür kılın. Yanıtı kullanmadan önce boş içerik kontrolü koyun ve bitiş nedeni normalken içeriğin boş gelmesini bir hata olarak sayın. Bu tek kontrol, yukarıdaki üç vakadan ikisini anında yakalar.

İkincisi, araç kullanımını isteğin şekliyle yönetin, parametresiyle değil. Araç istemediğiniz turlarda tools alanını hiç göndermeyin; bu hem doğru davranıştır hem de gateway tarafında reddedilmeyen tek yoldur.

Üçüncüsü, çıktıyı şemaya bağlayın. Serbest metni ayrıştırmak yerine json_schema kullanmak, hem ayrıştırma hatalarını düşürür hem de boş veya bozuk bir cevabı ayrıştırma aşamasında değil doğrulama aşamasında yakalamanızı sağlar. Bu modelde şema, kendisini ihlal etmeye çalışan bir isteme karşı bile korundu.

Sık sorulan sorular

tool_choice none neden 400 dönüyor, oysa standart bir değer?

Standart olduğu için değil, bu satırda çalışmadığı için. Sağlayıcı çağrıyı bastırmak yerine ham araç çağrısı şablonunu yanıt metnine yazıyor ve 200 dönüyor. LLMTR isteği sağlayıcıya göndermeden durdurup ne yapmanız gerektiğini söyleyen bir 400 döndürür; araçları kapatmak için isteğe tools alanını hiç eklemeyin.

stop dizisi gönderdim ve boş cevap aldım, hata mı?

Hayır, ölçülmüş davranış. Model yanıttan önce düşünür ve stop dizisi bu gizli metinle eşleşirse üretim orada durur, görünen cevap hiç başlamaz. Bu modelde stop kullanmamak en güvenlisidir; yanıtı kısaltmak için max_tokens kullanın.

reasoning_effort değerini düşürüp maliyeti azaltabilir miyim?

Hayır, bu satırda alan desteklenmez. Kabul edilen üç değer ölçümde birbirinden ayrışmadı, hatta low değeri high değerinden daha uzun düşündü. LLMTR bu yüzden bu satırda akıl yürütme seviyesi sunmaz.

Reddedilen bu istekler ücretsiz kotamdan düşer mi?

Araçlarla birlikte gönderilen tool_choice none isteği kotaya hiç girmez, çünkü gateway onu kota ayrılmadan önce reddeder. Kabul edilip işlenen ve sonra hata dönen istekler ise hak tüketebilir.

Aynı istemin aynı cevabı vermesini nasıl sağlarım?

Bu modelde sağlayamazsınız. seed alanı tekrarlanabilirlik üretmedi ve sıcaklık sıfırda bile üç çağrı üç farklı cevap verdi. Kararlı bir sonuç istiyorsanız cevabı şemaya bağlayıp alan bazında doğrulayın, metni birebir karşılaştırmayın.