Çoğu agent panosunda eksik olan sayı
Bir mühendislik ekibine bir agent görevinin ne kadara mal olduğunu sorduğunuzda, yanıt genellikle yayınlanmış bir oranla çarpılmış token sayısı olarak gelir. Bu rakamı üretmek kolaydır ve neredeyse hiçbir zaman işletmenin önemsediği şeyi tanımlamaz. Tamamlanmış tek bir görev, isteği ayrıştıran bir planner, araçları çağıran bir executor, sonucu kontrol eden bir verifier ve doğrulama başarısız olduğunda çalışan bir onarım döngüsü içerebilir. Bunların her biri ayrı bir model çağrısıdır; genellikle farklı bir modele, bazen hafifçe değiştirilmiş bir bağlamla aynı prompt'a yapılır. Token sayacı tüm bunları tek bir satır kaleminde toplar ve yapıyı ortadan kaldırır.
Bu yapı olmadan, benimseme kararları tahmine dayalı hale gelir. Bir ekip, yeniden deneme üst sınırını yükseltmenin tamamlanma oranlarını ekstra harcamayı haklı çıkaracak kadar iyileştirip iyileştirmediğini söyleyemez, çünkü ekstra harcama başlangıç çizgisinden ayrılmamıştır. Daha ucuz bir modelin bir alt görev sınıfını yönetip yönetmemesi gerektiğini söyleyemez, çünkü alt görev başına kalite veya maliyet sinyali yoktur. Önemli olan birim, başarılı görev başına maliyet ile birlikte hesaplanan terk edilen görev başına maliyettir ve oraya ulaşmanın tek yolu çalıştırmanın kendisini enstrümante etmektir.
Bir görev birçok çağrıdır
Çok adımlı bir agent, kontrol akışı çalışma zamanında belirlenen bir programdır. Planner beş adım veya on beş adım üretebilir. Executor bir arama aracını bir kez çağırabilir veya bir bütçe tükenene kadar döngüye girebilir. Verifier ilk denemede geçebilir veya iki onarımı tetikleyebilir. Token muhasebesi bu çağrıların toplamını görür; hangi rolün bunları ürettiğini, hangi göreve ait olduklarını veya görevin hiç bitip bitmediğini görmez. Bu nedenle toplam harcamadaki bir artış belirsizdir: daha fazla trafik, daha fazla yeniden deneme veya her çağrıda bağlamı şişiren bir prompt değişikliği olabilir.
Yeniden denemeler ve başarısız tool call'lar ücretlendirilir ama görünmez
Başarısız işler, başarılı işler gibi faturalandırılır. Model zaten uzun bir argüman yükü ürettikten sonra zaman aşımına uğrayan bir tool call token tüketmiş ve hiçbir şey üretmemiştir. Tam bir yeniden planlamayı tetikleyen bir verifier reddi, planner maliyetini ikiye katlar. Token başına raporlamada bunlar sıradan hacim olarak görünür. Görev başına defterde ise ayrı bir kategori olarak görünürler, bu da onları düzeltilebilir kılan şeydir.
Önbellekleme ve bağlam yeniden kullanımı efektif fiyatı değiştirir
Prompt önbellekleme ve bağlam yeniden kullanımı, bir çağrının efektif maliyetini büyük faktörlerle değiştirir ve bu faktörler sıralamaya, önek kararlılığına ve bağlamın roller arasında ne kadar paylaşıldığına bağlıdır. Kararlı bir sistem prompt'u tutan ve göreve özgü bağlam ekleyen bir sistem, görünür token sayıları benzer olsa bile, prompt'u her seferinde yeniden oluşturan bir sisteme göre çağrı başına önemli ölçüde daha az ödeyebilir. Önbellek davranışını göz ardı eden herhangi bir maliyet modeli, iki tasarımı birbirine karşı yanlış fiyatlandıracaktır. Pratik sonuç, prompt mimarisinin yalnızca bir kalite kararı değil, aynı zamanda bir maliyet kararı olduğudur.
Her çağrıyı bir görev tanımlayıcısı ve rol etiketiyle enstrümante edin
Temel, tüm çalıştırma boyunca hayatta kalan bir korelasyon tanımlayıcısıdır. Her model çağrısı, her tool çağrısı ve her sandbox başlatması, görev kimliği ve planner, executor, verifier veya repair gibi bir rol etiketiyle etiketlenir. Bu, agent döngüsüne uygulanan sıradan dağıtık izlemedir ve bir maliyet raporu ile bir maliyet modeli arasındaki farktır.
# Sözde kod: model çağrısı başına bir kayıt, daha sonra task_id ile birleştirilir
record = {
"task_id": task_id,
"role": "executor",
"model": model_name,
"input_tokens": prompt_tokens,
"cached_tokens": cached_prefix_tokens,
"output_tokens": completion_tokens,
"attempt": attempt_index,
"latency_ms": elapsed_ms,
"outcome": "ok" | "tool_error" | "verifier_reject",
}
outcome alanı, daha sonra bir ekibin işi yapma maliyetini iki kez yapma maliyetinden ayırmasını sağlayan şeydir. cached_tokens alanı, modelin efektif fiyat konusunda dürüst kalmasını sağlayan şeydir.
Tamamlanan görev başına maliyeti ve terk edilen görev başına maliyeti ayrı ayrı hesaplayın
Tüm görevler üzerinden ortalamalar, farklı ekonomilere sahip iki popülasyonu birleştirir. Tamamlanan bir görev bir varlıktır; terk edilen bir görev saf kayıptır ve genellikle ikisinden daha pahalıdır çünkü terk etme döngülerle ilişkilidir. Bunları birlikte raporlamak, terk etme yüksek olduğunda sistemi pohpohlayan bir sayı üretir, çünkü başarısız çalıştırmalar hiçbir şeye katkıda bulunmazken ortalamayı aşağı çeker.
Defteri ayırın:
- Tamamlanan görev başına maliyet — doğrulanmış bir terminal duruma ulaşan görevlere yapılan toplam harcama, sayılarına bölünür.
- Terk edilen görev başına maliyet — bir bütçeye, zaman aşımına veya kurtarılamaz bir hataya takılan görevlere yapılan toplam harcama, sayılarına bölünür.
- Terk etme oranı — iki popülasyon arasındaki oran, kaliteyle birlikte birinci sınıf bir metrik olarak izlenir.
Bir sistem, daha fazla zor görevi terk ederse, genel olarak kötüleşirken tamamlanan görev başına maliyetini iyileştirebilir. Yalnızca sayı çifti ve
Model çağrıları faturanın tamamı değildir. Tool çağrılarının kendi fiyatı vardır: harici API çağrıları, sandbox veya konteyner süresi, vektör deposu sorguları, artefaktlar için nesne depolama ve tool çıktısını ayrıştırma ve doğrulama için harcanan hesaplama. Bunlar, tool yoğun agent'lar için model harcamasından sıklıkla daha büyüktür ve neredeyse her zaman agent panolarında eksiktir. Bunları aynı görev kimliğine ve rol etiketine atfedin, böylece tek bir sorgu bir görevin uçtan uca gerçekte ne kadara mal olduğunu yanıtlayabilir.
Yararlı bir disiplin, küçük ve sabit bir boyut kümesine sahip bir maliyet şeması tutmaktır — görev kimliği, rol, kaynak sınıfı, sonuç — ve güvenilir bir şekilde doldurulamayan boyutlar eklemeyi reddetmektir. Boşlukları olan bir maliyet modeli, kaba olandan daha kötüdür çünkü yanlış kesinliğe davet eder.
Alt görevleri kalite farkının ölçüldüğü yere yönlendirin
Maliyet role göre atfedildiğinde, yönlendirme bir zevk meselesi olmaktan çıkıp ampirik bir soru haline gelir. Desen, dar ve iyi tanımlanmış alt görevleri daha küçük modellere göndermek ve daha büyük modelleri planlama, belirsiz sentez ve doğrulama için ayırmaktır. Kısıt, kalite farkının benchmark puanlarından varsayılmak yerine gerçek görev dağılımı üzerinde ölçülmesi gerektiğidir. Bir yönlendirme değişikliği bir hipotezdir: aynı görev kümesi, aynı verifier, önce ve sonra tamamlanma oranını ve tamamlanan görev başına maliyeti karşılaştırın.
Dürüst ödünleşim de burada yaşar. Agresif yönlendirme, çağrı başına maliyeti düşürür ve onarım döngülerinin sayısını artırır, çünkü daha zayıf modeller daha fazla verifier reddi üretir. Net etki her iki yönde de gidebilir ve yalnızca onarım maliyeti, ona neden olan yönlendirme kararına atfedildiğinde görünür olur. Ölçümü atlayan ekipler, anekdot temelinde iki konfigürasyon arasında salınma eğilimindedir.
Bütçe tükenmesini bir yönlendirme sinyali olarak ele alın
Görev başına bütçe, sert bir durdurma olarak değil, bir kontrol sinyali olarak daha faydalıdır. Bir görev bütçesini tükettiğinde, bu olay bilgi taşır: görev sınıfı varsayılandan daha zordur, planner aşırı ayrıştırıyordur veya executor asla kullanılabilir bir sonuç döndürmeyecek bir tool üzerinde döngüye giriyordur. Tükenmeyi, tükenme anındaki rol dökümüyle birlikte günlüğe kaydetmek, bir başarısızlığı bir yönlendirme girdisine dönüştürür. Bazı sistemler o sınıf için daha güçlü bir modele yükselterek yanıt verir; diğerleri planner'ın adım üst sınırını sıkılaştırarak yanıt verir. Her ikisi de meşrudur; hiçbiri defter olmadan keşfedilemez.
Maliyet regresyonlarını kalite regresyonlarının yanında raporlayın
Kalite ve maliyet birlikte hareket eder ve bunları ayrı ayrı incelemek, birinin diğeri pahasına optimize edilmesini garanti eder. Tamamlanma oranını birkaç puan yükseltirken onarım maliyetini üçe katlayan bir prompt değişikliği bir kazanç değil, bir ödünleşimdir ve bu şekilde sunulmalıdır. İnceleme artefaktı, sürüm başına küçük bir tablodur: tamamlanma oranı, terk etme oranı, tamamlanan görev başına maliyet, terk edilen görev başına maliyet ve herhangi bir değişikliğin rol düzeyinde dökümü. Her iki sütundaki regresyonlar sürümü engeller veya yazılı bir gerekçeyle açıkça kabul edilir.
Bu neyi değiştirir
Değişim, tüketimin muhasebesinden sonuçların muhasebesine geçiştir. Token harcaması faydalı bir girdi olmaya devam eder, ancak bir bileşendir, bir değer birimi değildir. Maliyet görev başına, rol başına ve sonuç başına atfedildiğinde, ekiplerin gerçekte yanıtlaması gereken sorular çözülebilir hale gelir: hangi görev sınıfları otomatikleştirmeye değer, daha küçük bir model nerede yeterince iyidir, hangi başarısızlık modları pahalıdır ve bir kalite iyileştirmesi kendi masrafını çıkardı mı. Bir agent dağıtımının bir bütçeyle temas ederken hayatta kalıp kalmayacağını belirleyen sorular bunlardır.