deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

Agent frameworkleri token limitine takılan yarım tool çağrılarını çalıştırıyor

Bir dev.to yazısı, modeller çıktı token limitine ulaştığında Langroid ve Heym'in kesilmiş tool çağrılarını kısmi ya da varsayılan argümanlarla çalıştırdığını belgeliyor. Her iki projede düzeltmeler birleştirildi.

Agent frameworkleri token limitine takılan yarım tool çağrılarını çalıştırıyor

Yarım yazılmış tool çağrıları yine de çalıştırılıyor

Büyük bir dil modeli bir tool çağrısını yazarken çıktı token limitine ulaştığında, ürettiği argümanlar ortasında kesiliyor. Yazarı, deneyleri kendi yürüten ve ortaya çıkan hata raporlarını kendi açan bir yapay zeka ajanı olarak tanımlanan bir dev.to yazısı, bazı agent frameworklerinin bu parçayı çöpe atmadığını belgeliyor. Bu parçayı kısmi argümanlarla ya da hiç argümansız çalıştırıyorlar ve çalıştırmayı başarılı olarak kaydediyorlar. Langroid ve Heym adlı iki açık kaynak projeden söz ediliyor ve ikisinde de düzeltmeler birleştirildi.

Aynı hataya giden iki yol

Yazıya göre Langroid (issue #1291) soruna hoşgörülü bir JSON parser üzerinden takıldı. 1000 iade etmesi istenen bir model, 10 rakamlarından hemen sonra kesildi ve geride geçersiz JSON bıraktı. json_repair adlı bir kütüphane bu parçayı geçerli bir nesneye kapattı; böylece tool 10.0 tutarıyla çalıştı ve 10 dolarlık bir iade raporladı. Streaming ve streaming olmayan yollar aynı şekilde davrandı.\n Aynı kurulumun üretime daha yakın bir varyantı da gösterildi. Bir konuşmanın başında, 512 token'lık bir çıktı bütçesiyle bir e-posta tool çağrısı bütün olarak gitti. Sonra, geçmiş büyüdükten ve framework o turun bütçesini 102 token'a düşürdükten sonra, model e-posta gövdesinin ortasında durdu — finish_reason length idi — ve mesaj yine de gönderildi, "If i" parçasında sonlandı. Framework'ün ayrıştırılamayan bir tool çağrısını düz metin olarak ele alan bir fallback'i vardı, ama onarım adımı yüzünden bu fallback hiç çalışmadı.

Heym (issue #902) aynı sonuca farklı bir yoldan ulaştı. Tool döngüsü JSONDecodeError'u yakaladı, boş bir argüman nesnesi koydu ve tool'u yine de çalıştırdı. Zorunlu parametreleri olan tool'larda bu, gürültülü ama yanıltıcı biçimde başarısız oluyor; modelin hiçbir şey göndermediğini ima eden bir argüman-eksik hatası veriyor. Parametrelerinin tümü isteğe bağlı olan tool'larda ise durum daha kötü: yazı, her müşteri için ticket'ları kapatan — boş bir müşteri kimliği ve sıfır günlük bir kesim noktasıyla varsayılanlarla çalışan — kesilmiş bir close_tickets çağrısı anlatıyor; çağrı boş argümanlarla başarı günlüyor ve agent'a "Done" diye yanıtlaması için komut veriyor. Yazının da işaret ettiği gibi, filtreler isteğe bağlıysa kesilmiş bir çağrı daha az değil, daha geniş biçimde hareket edebilir.

Okunmayan sinyal

Yazıya göre her sağlayıcı limit duruşunu farklı bir adla raporluyor: Chat Completions'ta finish_reason length, Anthropic'te stop_reason max_tokens, Gemini'de finishReason MAX_TOKENS ve OpenAI Responses API'de max_output_tokens gerekçeli status incomplete. Birden çok sağlayıcıyı destekleyen frameworkler bunları çoğunlukla tek bir alana normalize ediyor ve tool döngüsü o alanı hiç okumuyor.

İkinci bir tuzak daha var. Chat Completions'ta kesilmiş argümanlar en azından geçersiz JSON'dur, dolayısıyla bir ayrıştırma hatası sinyal verir. Anthropic, Gemini ve Responses taşıyıcılarında ise argümanlar zaten geçerli bir nesne olarak gelebilir ve kesiyi sadece duruş nedeni gösterir. Yalnızca JSONDecodeError'a dayanan bir düzeltme bu durumları kaçırır.

Düzeltme ve içindeki tuzaklar

Yazının önerdiği kural basit: bir tur çıktı limiti yüzünden sona erdiyse, o turun tool çağrılarının hiçbirini çalıştırma. Her çağrıya, modelden onu daha kısa yeniden göndermesini isteyen bir hatayla yanıt ver ve turup durmasını engellemek için yeniden deneme sayısını sınırla. Langroid'in bakımcısı kendi düzeltmesini #1292'de yazıp birleştirdi; yazının yazarı da Heym'in düzeltmesini #903'te yazdı ve o da birleştirildi.

Reddetme yolu bile kendi başına ayrı bir kod yolu çıktı. Heym'in otomatik kod incelemesi ilk düzeltmede iki sorun işaretledi; bunlar daha sonra #911'de çözüldü. Birincisi, reddedilen bir çağrının ham argümanlarını tek bir dize olarak saklamak, anahtar tabanlı maskelemeyi atlıyordu ve tam çağrılardaki gizli bilgilerin izlere ve kalıcı kayıtlara ulaşmasına izin veriyordu; takip edilen düzeltme argümanları ayrıştırılabildiğinde ayrıştırıyor, aksi halde yalnızca uzunluklarını kaydediyor. İkincisi, ilk düzeltmeden sonra insan onayı gerektiren bir tool'a yapılan bozuk bir çağrı yalnızca hata veriyordu ve aynı gruptaki geçerli bir kardeş çağrının onsuz çalışmasına izin veriyordu; takip edilen düzeltme o gruptaki tüm kardeşleri erteliyor.

Modelsiz test etme

Yazıya göre API anahtarı gerekmiyor. Sağlayıcının protokolünü konuşan küçük bir localhost sunucusu çalıştırın, bir tam ve bir kesilmiş tool çağrısı yanıtı betikleyin ve üç şeyi doğrulayın: tam çağrı doğru argümanlarla tool'a ulaşıyor, kesilmiş olan hiçbir zaman tool handler'a ulaşmıyor ve model bir hata sonucu alıyor. Sahte sunucunun max_tokens'a uymasını sağlamak, geçmiş büyüdükçe bütçelerin daraldığı geç-dönem konuşma durumunu da yeniden üretir.

Neden önemli

Kesilmiş çıktı olağanüstü bir durum değil, rutin bir durum; ve konuşma geçmişi tur başına bütçeleri yedikçe daha da olası hale geliyor. Hata sessiz: tool'lar kasıtlı olandan daha az ya da daha geniş argümanlarla çalışıyor ve başarı raporluyor; bunu üretim izleri kendi başına işaretlemeyecek. Bir agent inşa eden ya da çalıştıran herkes, tool'ları çalıştıran kod yolunun duruş nedenini hiç okuyup okumadığını kontrol etmeli, tool argümanlarını onarılacak bir metin değil bir eylem olarak ele almalı ve tümü isteğe bağlı parametreli bir tool'un varsayılan çağrısının gerçekte ne yaptığını sormalı.

  • #ai-agents
  • #llm
  • #open-source
  • #safety
  • #tool-calling

İlgili yazılar