Tek ajan adımı — 120.000 token: nereye gidiyorlar ve bunu nasıl düzelttik
Otonom bir ajan, ajan döngüsünün her adımında tam bağlamın tekrar tekrar gönderilmesi nedeniyle beklenenden çok daha fazla token tüketebilir. Makale, Uma Computer'ın gerçek nedenin diyalog geçmişi değil, sistem talimatlarının, araç şemalarının ve belleğin çoğaltılmış ek yükü olduğunu nasıl bulduğunu anlatıyor ve üç optimizasyon sunuyor: hacmi isteğe bağlı araçlara taşıma, açık kesme işaretleriyle karakter bütçesine geçme ve şeffaf hız beklentileri.
Uma Computer'ın geliştiricileri, web araması, medya üretimi ve video kırpma gibi görevleri yerine getiren otonom bir ajan olan sistemlerinde, bir kullanıcı talebinin neden beklenen üçte biri yerine 38 krediye mal olduğunu araştırdı. Faturalandırma, 119.208 prompt token ve yalnızca 1.018 completion token gösteriyordu; bu da modelin çoğunlukla yazmak yerine okuduğu anlamına geliyordu. İlk hipotez uzun bir diyalog geçmişiydi, ancak gerçek sorunlu diyaloğun toplam 530 karakterlik yalnızca iki mesajı vardı. Ölçümler, adım başına bağlamın 13.900 token olduğunu ve 9 adımla toplamın yaklaşık 120.000 tokena ulaştığını ortaya çıkardı; ek yük, ajan döngüsündeki adım sayısıyla çarpılıyordu. Ek olarak, sağlayıcı max_tokens değerini yüksek tutarak en kötü durum maliyetini ayırıyor ve bu da yeterli bakiye olsa bile HTTP 402 hatalarına neden oluyordu. Çözüm, önceden yüklenmiş bağlamı isteğe bağlı araçlara taşımayı, öncelikler ve açık kesme işaretçileri içeren bir karakter bütçesi kullanmayı ve hız beklentilerini şeffaf hale getirmeyi içeriyordu. Makale, bağlamın modelden asla sessizce gizlenmemesi gerektiğini ve optimizasyonların somut durumlar üzerinde doğrulanması gerektiğini, çünkü neredeyse geçmişin alakasız olduğu bir durum için optimize ettiklerini vurguluyor.
Kaynak: Habr — хаб ML —
orijinal