عددی که از بیشتر داشبوردهای agent غایب است
از یک تیم مهندسی بپرسید هزینهٔ یک وظیفهٔ agent چقدر است و پاسخ معمولاً به‌صورت تعداد توکن ضرب‌در نرخ منتشرشده می‌آید. تولید این رقم آسان است و تقریباً هرگز چیزی را که کسب‌وکار به آن اهمیت می‌دهد توصیف نمی‌کند. یک وظیفهٔ کامل ممکن است شامل یک planner باشد که درخواست را تجزیه می‌کند، یک executor که ابزارها را فراخوانی می‌کند، یک verifier که نتیجه را بررسی می‌کند، و یک حلقهٔ ترمیم که هنگام شکست verification اجرا می‌شود. هر یک از این‌ها یک فراخوانی جداگانهٔ مدل است، اغلب روی مدلی متفاوت، گاهی روی همان prompt با زمینه‌ای کمی تغییر‌یافته. کنتور توکن همهٔ این‌ها را در یک ردیف هزینه تجمیع می‌کند و ساختار را حذف می‌کند.
بدون این ساختار، تصمیم‌های پذیرش به حدس و گمان تبدیل می‌شوند. یک تیم نمی‌تواند بگوید آیا بالا بردن سقف retry نرخ تکمیل را به‌اندازهٔ کافی بهبود داده که هزینهٔ اضافی را توجیه کند، چون هزینهٔ اضافی از خط پایه جدا نشده است. نمی‌تواند بگوید آیا مدل ارزان‌تری باید یک کلاس زیروظیفه را بر عهده بگیرد، چون هیچ سیگنال کیفیت یا هزینهٔ به‌ازای‌زیروظیفه ندارد. واحدی که اهمیت دارد هزینه به ازای هر وظیفهٔ موفق است، که در کنار هزینه به ازای هر وظیفهٔ رهاشده محاسبه می‌شود، و تنها راه رسیدن به آن اندازه‌گیری خودِ اجراست.
یک وظیفه یعنی فراخوانی‌های بسیار
یک agent چندمرحله‌ای برنامه‌ای است که جریان کنترلش در زمان اجرا تعیین می‌شود. planner ممکن است پنج گام یا پانزده گام تولید کند. executor ممکن است یک ابزار جست‌وجو را یک بار فراخوانی کند یا تا تمام شدن بودجه حلقه بزند. verifier ممکن است در اولین تلاش قبول کند یا دو ترمیم را فعال کند. حسابداری توکن مجموع این فراخوانی‌ها را می‌بیند؛ نمی‌بیند کدام نقش آن‌ها را تولید کرده، به کدام وظیفه تعلق داشته‌اند، یا آیا وظیفه هرگز تمام شده است. بنابراین افزایش هزینهٔ کل مبهم است: می‌تواند ترافیک بیشتر باشد، retry بیشتر، یا تغییری در prompt که زمینه را در هر فراخوانی متورم کرده است.
retryها و tool callهای ناموفق صورت‌حساب می‌شوند اما نامرئی‌اند
کار ناموفق دقیقاً مانند کار موفق صورت‌حساب می‌شود. یک tool call که پس از تولید یک payload طولانی آرگومان توسط مدل، timeout می‌شود، توکن مصرف کرده و هیچ چیزی تولید نکرده است. رد شدن توسط verifier که یک re-plan کامل را فعال می‌کند، هزینهٔ planner را دو برابر می‌کند. در گزارش‌دهی به ازای توکن، این‌ها به‌صورت حجم عادی ظاهر می‌شوند. در دفتر کل به ازای وظیفه، به‌صورت یک دستهٔ متمایز ظاهر می‌شوند، و همین چیزی است که آن‌ها را قابل رفع می‌کند.
caching و بازاستفاده از زمینه قیمت مؤثر را جابه‌جا می‌کنند
prompt caching و بازاستفاده از زمینه، هزینهٔ مؤثر یک فراخوانی را با ضرایب بزرگی تغییر می‌دهند، و این ضرایب به ترتیب، پایداری prefix و میزان زمینهٔ مشترک میان نقش‌ها بستگی دارند. سیستمی که یک system prompt پایدار نگه می‌دارد و زمینهٔ مخصوص وظیفه را به آن می‌افزاید، می‌تواند به‌طور محسوسی کمتر از سیستمی که هر بار prompt را از نو می‌سازد، به ازای هر فراخوانی بپردازد، حتی وقتی تعداد توکن‌های قابل مشاهده مشابه است. هر مدل هزینه‌ای که رفتار cache را نادیده بگیرد، این دو طراحی را در برابر هم اشتباه قیمت‌گذاری می‌کند. پیامد عملی این است که معماری prompt یک تصمیم هزینه است، نه فقط یک تصمیم کیفیت.
هر فراخوانی را با شناسهٔ وظیفه و برچسب نقش اندازه‌گیری کنید
پایه، یک شناسهٔ همبستگی است که در کل اجرا باقی می‌ماند. هر فراخوانی مدل، هر فراخوانی ابزار و هر شروع sandbox با شناسهٔ وظیفه و یک برچسب نقش مانند planner، executor، verifier یا repair برچسب‌گذاری می‌شود. این همان distributed tracing معمولی است که به یک حلقهٔ agent اعمال شده، و تفاوت میان یک گزارش هزینه و یک مدل هزینه است.
# Pseudocode: one record per model call, joined later by task_id
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 همان چیزی است که بعداً به تیم اجازه می‌دهد هزینهٔ انجام کار را از هزینهٔ انجام دوبارهٔ آن جدا کند. فیلد cached_tokens همان چیزی است که مدل را دربارهٔ قیمت مؤثر صادق نگه می‌دارد.
هزینه به ازای هر وظیفهٔ تکمیل‌شده و هزینه به ازای هر وظیفهٔ رهاشده را جداگانه محاسبه کنید
میانگین‌گیری روی همهٔ وظایف دو جمعیت با اقتصاد متفاوت را با هم مخلوط می‌کند. یک وظیفهٔ تکمیل‌شده یک دارایی است؛ یک وظیفهٔ رهاشده ضرر محض است، و معمولاً گران‌تر از دومی است چون رهاشدن با حلقه‌ها همبستگی دارد. گزارش دادن آن‌ها با هم عددی تولید می‌کند که هرگاه رهاشدن بالا باشد سیستم را چاپلوسانه نشان می‌دهد، چون اجراهای ناموفق میانگین را پایین می‌کشند در حالی که هیچ چیزی مشارکت نمی‌کنند.
دفتر کل را تفکیک کنید:
- هزینه به ازای هر وظیفهٔ تکمیل‌شده — کل هزینهٔ وظایفی که به یک وضعیت پایانی تأییدشده رسیده‌اند، تقسیم بر تعدادشان.
- هزینه به ازای هر وظیفهٔ رهاشده — کل هزینهٔ وظایفی که به بودجه، timeout یا خطای غیرقابل‌بازیابی برخورده‌اند، تقسیم بر تعدادشان.
- نرخ رهاشدن — نسبت میان دو جمعیت، که به‌عنوان یک معیار درجه‌یک در کنار کیفیت پیگیری می‌شود.
یک سیستم می‌تواند هزینه به ازای هر وظیفهٔ تکمیل‌شده را بهبود دهد در حالی که در کل بدتر می‌شود، اگر وظایف سخت بیشتری را رها کند. تنها این جفت عدد، به‌همراه
فراخوانی‌های مدل تمام صورت‌حساب نیستند. فراخوانی ابزارها قیمت خودشان را دارند: فراخوانی‌های API خارجی، زمان sandbox یا container، پرس‌وجوهای vector store، ذخیره‌سازی شیء برای artefactها، و محاسبات صرف‌شده برای تجزیه و اعتبارسنجی خروجی ابزار. این‌ها اغلب برای agentهای ابزارمحور بزرگ‌تر از هزینهٔ مدل هستند، و تقریباً همیشه از داشبوردهای agent غایب‌اند. آن‌ها را به همان شناسهٔ وظیفه و برچسب نقش نسبت دهید تا یک پرس‌وجوی واحد بتواند پاسخ دهد که یک وظیفه در واقع از ابتدا تا انتها چقدر هزینه داشته است.
یک نظم مفید این است که یک schema هزینه با مجموعه‌ای کوچک و ثابت از ابعاد نگه دارید — شناسهٔ وظیفه، نقش، کلاس منبع، نتیجه — و از افزودن ابعادی که نمی‌توان آن‌ها را به‌طور قابل‌اعتماد پر کرد خودداری کنید. یک مدل هزینه با شکاف بدتر از یک مدل درشت است، چون دقت کاذب را دعوت می‌کند.
زیروظیفه‌ها را جایی مسیریابی کنید که دلتای کیفیت اندازه‌گیری شده است
وقتی هزینه بر اساس نقش نسبت داده شود، مسیریابی به یک پرسش تجربی تبدیل می‌شود نه موضوع سلیقه. الگو این است که زیروظیفه‌های باریک و به‌خوبی مشخص‌شده را به مدل‌های کوچک‌تر بفرستیم و مدل‌های بزرگ‌تر را برای planning، ترکیب مبهم و verification نگه داریم. محدودیت این است که دلتای کیفیت باید روی توزیع واقعی وظایف اندازه‌گیری شود، نه از نمرات benchmark فرض شود. تغییر مسیریابی یک فرضیه است: همان مجموعهٔ وظایف، همان verifier، مقایسهٔ نرخ تکمیل و هزینه به ازای هر وظیفهٔ تکمیل‌شده پیش و پس از آن.
اینجا همان جایی است که مبادلهٔ صادقانه زندگی می‌کند. مسیریابی تهاجمی هزینه به ازای هر فراخوانی را پایین می‌آورد و تعداد حلقه‌های ترمیم را بالا می‌برد، چون مدل‌های ضعیف‌تر ردهای verifier بیشتری تولید می‌کنند. اثر خالص می‌تواند به هر دو سو برود، و تنها زمانی قابل مشاهده است که هزینهٔ ترمیم به تصمیم مسیریابی‌ای که آن را ایجاد کرده نسبت داده شود. تیم‌هایی که اندازه‌گیری را نادیده می‌گیرند، تمایل دارند بر اساس حکایت‌های شفاهی میان دو پیکربندی نوسان کنند.
تمام شدن بودجه را به‌عنوان سیگنال مسیریابی در نظر بگیرید
یک بودجهٔ به ازای هر وظیفه به‌عنوان سیگنال کنترل مفیدتر از یک توقف سخت است. وقتی یک وظیفه بودجه‌اش را تمام می‌کند، آن رویداد اطلاعاتی حمل می‌کند: کلاس وظیفه سخت‌تر از فرض است، planner بیش از حد تجزیه می‌کند، یا executor روی ابزاری حلقه می‌زند که هرگز نتیجهٔ قابل‌استفاده‌ای برنمی‌گرداند. ثبت تمام شدن بودجه همراه با تفکیک نقش در لحظهٔ تمام شدن، یک شکست را به یک ورودی مسیریابی تبدیل می‌کند. برخی سیستم‌ها با ارتقا به یک مدل قوی‌تر برای آن کلاس پاسخ می‌دهند؛ برخی دیگر با سخت‌تر کردن سقف گام‌های planner. هر دو مشروع‌اند؛ هیچ‌کدام بدون دفتر کل قابل کشف نیست.
رگرسیون‌های هزینه را در کنار رگرسیون‌های کیفیت گزارش دهید
کیفیت و هزینه با هم حرکت می‌کنند، و بررسی جداگانهٔ آن‌ها تضمین می‌کند که یکی به قیمت دیگری بهینه شود. تغییری در prompt که نرخ تکمیل را چند امتیاز بالا می‌برد در حالی که هزینهٔ ترمیم را سه برابر می‌کند، یک مبادله است نه یک برد، و باید به‌عنوان یکی ارائه شود. مصنوع بررسی یک جدول کوچک به ازای هر انتشار است: نرخ تکمیل، نرخ رهاشدن، هزینه به ازای هر وظیفهٔ تکمیل‌شده، هزینه به ازای هر وظیفهٔ رهاشده، و تفکیک در سطح نقش از هر تغییر. رگرسیون در هر یک از دو ستون، انتشار را مسدود می‌کند یا به‌صراحت با دلیل مکتوب پذیرفته می‌شود.
این چه چیزی را تغییر می‌دهد
تغییر از حسابداری مصرف به حسابداری نتایج است. هزینهٔ توکن یک ورودی مفید باقی می‌ماند، اما یک مادهٔ اولیه است، نه یک واحد ارزش. وقتی هزینه به ازای هر وظیفه، هر نقش و هر نتیجه نسبت داده شود، پرسش‌هایی که تیم‌ها واقعاً باید پاسخ دهند قابل حل می‌شوند: کدام کلاس‌های وظیفه ارزش خودکارسازی دارند، کجا یک مدل کوچک‌تر به‌اندازهٔ کافی خوب است، کدام حالت‌های شکست گران‌اند، و آیا یک بهبود کیفیت هزینهٔ خودش را جبران کرده است. این‌ها همان پرسش‌هایی هستند که تعیین می‌کنند آیا یک استقرار agent در برخورد با یک بودجه دوام می‌آورد یا نه.