هزینهٔ مسیر به‌عنوان ورودی زمان‌بندی

مشکل جمع‌های کل

بیشتر پلتفرم‌های agent هزینه را همان‌طور گزارش می‌کنند که تیم مالی هزینهٔ ابری را گزارش می‌کند: یک جمع کل، منتسب به یک اجرا، که پس از پایان اجرا تحویل داده می‌شود. آن جمع کل برای حسابداری مفید است و برای کنترل بی‌فایده. تا زمانی که عدد وجود داشته باشد، هر تصمیمی که آن را تولید کرده، پیش‌تر گرفته شده است.

یک وظیفهٔ پژوهشی متمرکز بر retrieval را در نظر بگیرید. agent پرس‌وجو را حل می‌کند، به یک ابزار جست‌وجو شاخه می‌زند، چند سند بیرون می‌کشد، و پیش از آنکه حتی یک پاسخ نامزد تولید کند، بخش عمدهٔ بودجه‌اش را صرف مونتاژ context می‌کند. در گام سوم، مسیر بیشتر سهمیهٔ خود را مصرف کرده است. در گام سی‌ام، جایی که agent باید بررسی کند آیا پاسخش واقعاً پشتیبانی می‌شود، چیزی برای خرج کردن باقی نمانده است. اجرا با صدای بلند شکست نمی‌خورد. پاسخی مطمئن و بدون راستی‌آزمایی برمی‌گرداند، و گزارش هزینه یک اجرای راحت و درون‌بودجه را نشان می‌دهد.

این شکست اصلی برخورد با هزینه به‌عنوان گزارش، به‌جای سیگنال است. هزینهٔ یک اجرا یک عدد اسکالر نیست که در پس‌زمینه انباشته شود؛ یک منحنی با شکل است، و شکل آن به شما می‌گوید agent به‌زودی چه چیزی را نمی‌تواند بخرد.

چرا سقف‌های هر اجرا مشکل را حل نمی‌کنند

راه‌حل بدیهی یک سقف است: وقتی هزینه از آستانه گذشت، اجرا را متوقف کن. سقف‌ها به دو دلیل ابزاری کند هستند.

نخست، دیر فعال می‌شوند. سقف محدودیتی بر جمع کل است، نه قیدی بر اقدام بعدی. agentی که سهمیه‌اش را صرف retrieval کرده، در مرحلهٔ راستی‌آزمایی به سقف می‌خورد، که دقیقاً همان گامی است که کمترین تمایل را به کوتاه کردنش دارید. سقف یک مسئلهٔ بودجه را به یک مسئلهٔ درستی تبدیل می‌کند.

دوم، بودجه را بی‌استفاده می‌گذارند. اجرایی که زیر سقفش تمام می‌شود، هیچ سازوکاری ندارد که باقی‌مانده را جایی خرج کند که مفید باشد — روی یک دور راستی‌آزمایی اضافی، یک زاویهٔ retrieval دوم، یا بازخوانی یک دستور مبهم. سقف هم‌زمان بیش‌ازحد سخت‌گیرانه و بیش‌ازحد سهل‌گیرانه است، چون کمیت اشتباهی را کنترل می‌کند.

کمیتی که اهمیت دارد، هزینهٔ نهایی به‌ازای افزایش موردانتظار هر گام است: اقدام نامزد بعدی چقدر هزینه دارد، و انتظار می‌رود چقدر مسیر را بهبود دهد. این سیگنال فقط در حین اجرا وجود دارد، یعنی باید توسط runtime تولید شود، نه پس از آن بازسازی شود.

تبدیل هزینه به متغیر درجه‌یک زمان‌بندی

A scenic view of a bustling town square in Luxembourg city, showcasing classic European architecture.

پیش‌نیاز این است که هر گام قیمتی داشته باشد. نه برآوردی در پایان اجرا، بلکه هزینه‌ای قابل‌محاسبه که در لحظه‌ای که هماهنگ‌کننده آن گام را در نظر می‌گیرد، به آن گام پیوست شده باشد. در عمل این یعنی برچسب‌زدن هر گام با حداقل چهار ویژگی:

model — کدام کلاس مدل را گام فراخوانی می‌کند، چون مسیریابی و تولید از نظر هزینه چند مرتبهٔ بزرگی تفاوت دارند؛
token class — توکن‌های ورودی، خروجی، ورودی کش‌شده و استدلالی قابل‌جانشینی نیستند و نباید در یک عدد جمع شوند؛
tool latency — زمان واقعی، چون یک ابزار کند بودجهٔ زمانی اجرا را مصرف می‌کند حتی وقتی از نظر توکن ارزان است؛
tool price — هزینهٔ خودِ فراخوانی خارجی، که اغلب در حسابداری توکن نامرئی است.

با این برچسب‌ها، هماهنگ‌کننده می‌تواند اقدام نامزد بعدی را پیش از تعهد به آن قیمت‌گذاری کند. یک گام دیگر یک فراخوانی تابع مبهم نیست؛ یک قلم هزینه با هزینهٔ پیش‌بینی‌شده و سود پیش‌بینی‌شده است.

# Sketch: pricing a candidate action before dispatch
def price(action, context):
    return {
        "model_cost": model_rates[action.model] * estimate_tokens(action, context),
        "tool_cost": tool_rates.get(action.tool, 0),
        "latency": tool_latency[action.tool] if action.tool else 0,
    }

def should_run(action, budget, context):
    cost = price(action, context)
    gain = expected_gain(action, context)  # from the same policy that ranks actions
    return cost["model_cost"] + cost["tool_cost"] <= budget.remaining_for(action.kind)

بخش مهم خط آخر است: بودجه یک استخر واحد نیست. بر اساس نوع گام تقسیم شده است، و این تقسیم یک تصمیم سیاستی است، نه خاصیتی برخاسته از ترتیب اجرا.

سیاست‌های هزینه برای هر کلاس وظیفه

یک سیاست بودجهٔ واحد برای همهٔ کلاس‌های وظیفه تضمین می‌کند که برخی کلاس‌ها بد خدمت ببینند. دو الگو بیشتر این فضا را پوشش می‌دهند.

وظایف متمرکز بر کاوش — پژوهش باز، کشف، جست‌وجوی سطح‌اول — بودجهٔ کاهشی می‌خواهند. گام‌های اولیه ارزان و پرشمارند؛ هماهنگ‌کننده باید آزادانه روی retrieval و تولید نامزد خرج کند، سپس کاهش دهد. همین کاهش است که بودجه را برای گام‌های بعدی که واقعاً انتخاب و ترکیب می‌کنند حفظ می‌کند.

وظایف متمرکز بر راستی‌آزمایی — استخراج، بررسی‌های انطباق، هر چیزی که در آن پاسخ اشتباه گران تمام می‌شود — دنبالهٔ رزروشده می‌خواهند. کسر ثابتی از سهمیهٔ اجرا کنار گذاشته می‌شود و برای گام‌های retrieval یا تولید قابل‌دسترسی نیست. agent نمی‌تواند بودجهٔ راستی‌آزمایی را صرف context بیشتر کند، هرچقدر هم که context وسوسه‌انگیز به نظر برسد.

این یک توازن است و باید صریح بیان شود: رزرو کردن یک دنباله، اجرا را در حین کاوش کم‌توان‌تر می‌کند. agentی با بودجهٔ راستی‌آزمایی رزروشده گاهی در یافتن سندی که راستی‌آزمایی را غیرضروری می‌کرد ناکام می‌ماند. این سیاست شرطی است بر اینکه راستی‌آزمایی هزینهٔ نهایی ارزشمندتری است، و برای برخی کلاس‌های وظیفه این شرط اشتباه است.

Close-up of stock market trading screen displaying financial growth and charts.

ارزان مسیریابی کن، عامدانه تشدید کن

زمان‌بندی آگاه از هزینه همچنین مسیریابی مدل را ایجاب می‌کند. طبقه‌بندی، تشخیص قصد، تصمیم‌های مسیریابی و نرمال‌سازی قالب نیازی به فراخوانی‌های frontier ندارند. آن‌ها باید روی یک توزیع باریک درست باشند، و مدل‌های کوچک‌تر معمولاً کافی‌اند. رزرو کردن فراخوانی‌های frontier برای گام‌هایی که مسیر واقعاً مبهم است — جایی که خروجی مدل ارزان کم‌اطمینان است یا اقدام‌های نامزد از نظر سود موردانتظار نزدیک‌اند — فراخوانی‌های گران را جایی متمرکز می‌کند که نتیجه را تغییر می‌دهند.

سازوکار یک دروازهٔ اطمینان است، نه یک قاعدهٔ ثابت. هماهنگ‌کننده توزیع خروجی مدل ارزان را با یک آستانه مقایسه می‌کند؛ پایین‌تر از آن، گام با خروجی مدل ارزان به‌عنوان context به یک مدل frontier دوباره ارسال می‌شود. خودِ دروازه یک تصمیم زمان‌بندی است و به همان شیء سیاستی تعلق دارد که بودجه.

حالت‌های شکستی که باید در برابرشان طراحی کرد

زمان‌بندی آگاه از هزینه حالت‌های شکست خودش را معرفی می‌کند، و آن‌ها ظریف نیستند.

قحطی راستی‌آزمایی. زمان‌بندی که هزینهٔ نهایی را کمینه می‌کند، کشف خواهد کرد که راستی‌آزمایی گران است و به‌ندرت پاسخ را تغییر می‌دهد. اگر بی‌مهار رها شود، راستی‌آزمایی را رد می‌کند، و اجرا خروجی راستی‌آزمایی‌نشده را ارزان برمی‌گرداند — تا زمانی که یکی از آن خروجی‌ها به‌شکلی اشتباه باشد که بسیار بیشتر از هزینهٔ راستی‌آزمایی تمام شود. دنبالهٔ رزروشده دقیقاً برای این وجود دارد که این شکست را به‌جای امید، از طریق سیاست ناممکن کند.

تورم نامرئی تلاش مجدد. تلاش‌های مجدد رایج‌ترین منبع انحراف هزینه‌اند، چون معمولاً به‌عنوان جریان کنترل پیاده‌سازی می‌شوند نه به‌عنوان گام. ابزاری که شکست می‌خورد و سه بار دوباره تلاش می‌شود، چهار گام اجرا کرده اما یکی را ثبت کرده است. اگر تلاش‌های مجدد گام‌های درجه‌یک با قلم‌های هزینهٔ خودشان نباشند، منحنی‌ای که زمان‌بند می‌بیند از منحنی‌ای که اجرا واقعاً تولید می‌کند واگرا می‌شود. تلاش‌های مجدد را صریح بشمارید، قیمت‌گذاری کنید و بگذارید سیاست بودجه آن‌ها را ببیند.

ضرب شاخه‌زنی. سیستم‌های چندعاملی منحنی را ضرب می‌کنند. سرپرستی که پنج کارگر را اعزام می‌کند، که هرکدام سه زیروظیفه را اعزام می‌کنند، پانزده مسیر ایجاد کرده که هزینه‌هایشان همبسته است — context مشترک دارند، retrieval را تکرار می‌کنند، و وقتی یک وابستگی مشترک کند است، با هم شکست می‌خورند. بودجهٔ هر کارگر یک بودجه نیست؛ پانزده بودجهٔ مستقل است که به چیزی جمع می‌شوند که هیچ‌کس انتخاب نکرده. محدودیت را در سطح ازدحام اعمال کنید، با سرپرستی که از یک استخر مشترک تخصیص می‌دهد و کارگرانی که در برابر آن پیشنهاد می‌دهند.

توازن به کجا تعلق دارد

استدلال این نیست که گزارش هزینه غیرضروری است. مالی به جمع‌های کل نیاز دارد، و تیم‌ها باید بفهمند سیستم‌هایشان چه مصرف می‌کنند. استدلال این است که گزارش، مصرف‌کنندهٔ پایین‌دستی سیگنالی است که باید بالادست، درون هماهنگ‌کننده، در لحظه‌ای که هر اقدام در نظر گرفته می‌شود، تولید شود.

وقتی یک اجرا منحنی هزینه داشته باشد، زمان‌بند می‌تواند کاری کند که یک داشبورد نمی‌تواند: در هر گام، عامدانه، تحت سیاستی که یک انسان انتخاب کرده، بین عمق و هزینه توازن برقرار کند. این یک مسئلهٔ زمان‌بندی است و به جایی تعلق دارد که زمان‌بندی رخ می‌دهد.

هزینهٔ مسیر، ورودی زمان‌بندی است، نه گزارشی پس‌ازواقع