هزینه از مدل نمی‌آید
مجموع توکن یک خروجی است، نه یک علت. وقتی دو اجرای عامل از یک کار به اندازه یک مرتبه بزرگی در فراخوانی ابزار تفاوت دارند، این تفاوت به‌ندرت از مدل است. تفاوت از تجزیه است: تعداد زیرکارهایی که برنامه‌ریز ایجاد کرده، اینکه هر کدام چقدر باریک محدوده‌بندی شده‌اند، و اینکه به هر گره گفته شده چقدر زمینه را دوباره بخواند. برنامه‌ای که یک کار بازیابی را به پنج زیرکار همپوشان تقسیم می‌کند، هزینه یک سند را پنج بار می‌پردازد. برنامه‌ای که آن را به یک گره با محدوده‌بندی مناسب تقسیم می‌کند، یک بار می‌پردازد.
حالت‌های شکست خوشه‌بندی می‌شوند. تلاش‌های مجدد روی زیرکارهایی متمرکز می‌شوند که شرط موفقیتشان هرگز بیان نشده است. بازخوانی‌های زمینه روی گره‌هایی متمرکز می‌شوند که سطح ابزار بیش از حد گسترده‌ای به آن‌ها داده شده و مجبور شده‌اند آنچه را قبلاً می‌دانستند دوباره استخراج کنند. مراحل تأیید تکراری وقتی ظاهر می‌شوند که برنامه‌ریز نمی‌تواند تصمیم بگیرد آیا یک زیرکار کامل است، پس یک گره بررسی‌کننده اضافه می‌کند که کار را تکرار می‌کند. هیچ‌کدام از این‌ها در مجموع هر اجرا دیده نمی‌شود. مجموع هزینه را به مدل نسبت می‌دهد، چون مدل همان چیزی است که خط صورت‌حساب نام می‌برد. برنامه همان چیزی است که واقعاً پول را خرج کرده است.
حسابداری گره‌های برنامه
مکانیزم ساده است: به هر گره برنامه یک شناسه پایدار بدهید، و هر فراخوانی مدل و فراخوانی ابزار را به گره‌ای که آن را صادر کرده نسبت دهید. شناسه گره یک نام span نیست. این واحد کار خود برنامه‌ریز است که در طول اجرا به‌عنوان یک فیلد روی هر درخواست خروجی حمل می‌شود.
plan_node_id: "retrieve_policy_clauses"
parent_node: "assemble_compliance_answer"
model_calls: [...]
tool_calls: [...]
status: "retried"
در طول اجراها تجمیع کنید، و هر گره یک توزیع پیدا می‌کند: هزینه، تأخیر، نرخ تلاش مجدد، نرخ شکست. توزیع نکته اصلی است. میانگین هزینه هر گره به شما می‌گوید یک گره معمولاً چقدر هزینه دارد. دنباله راست بلند به شما می‌گوید کدام گره گاهی منفجر می‌شود. این‌ها مسائل مهندسی متفاوتی هستند. اولی یک سؤال بودجه‌بندی است. دومی یک نقص تجزیه است.
اینجاست که بیشتر قابلیت مشاهده عامل متوقف می‌شود. ردیابی‌ها جمع‌آوری می‌شوند، spanها رندر می‌شوند، و نمای هزینه یک مجموع هر اجرا با تفکیک بر اساس مدل است. آن تفکیک به سؤالی پاسخ می‌دهد که هیچ‌کس نپرسیده: کدام مدل توکن‌ها را خرج کرده است. سؤالی که مهم است این است که کدام بخش برنامه کار را تولید کرده است. یک نمای سطح گره به آن پاسخ می‌دهد، و در طول اجراها پاسخ می‌دهد، که تنها راه جدا کردن یک برنامه بد از یک روز بد است.
توزیع چه چیزی را آشکار می‌کند
سه الگو تکرار می‌شوند.
یک گره با میانگین هزینه پایین و دنباله سنگین معمولاً گرهی است با شرط موفقیت کم‌مشخص. بیشتر اوقات موفق می‌شود و گاهی حلقه می‌زند. راه‌حل یک مدل ارزان‌تر نیست. راه‌حل یک قرارداد محکم‌تر روی گره است: چه چیزی باید برگرداند، و چه چیزی به‌عنوان انجام‌شده حساب می‌شود.
یک گره با میانگین هزینه بالا و واریانس پایین کار واقعی انجام می‌دهد. کاندیدی برای سطح ابزار باریک‌تر یا مدل ارزان‌تر است، چون رفتارش به‌قدر کافی قابل پیش‌بینی است که بدون به خطر انداختن اجرا بهینه شود.
یک گره با نرخ تلاش مجدد بالا و هزینه ثابت گرهی است که همیشه به یک شکل شکست می‌خورد و توسط برنامه‌ریزی که گزینه بهتری ندارد دوباره تلاش می‌شود. افزودن بودجه در اینجا شکست را گران‌تر می‌کند. بازنویسی گره آن را حذف می‌کند.
هیچ‌کدام از این تمایزها در تجمیع به یک مجموع اجرا باقی نمی‌مانند. آن‌ها گره را به‌عنوان واحد حساب نیاز دارند.
تبدیل آن به ورودی زمان‌بندی
وقتی هزینه به گره‌ها نسبت داده شود، اجرا می‌تواند به گره متصل شود نه به اجرا. یک سقف هر اجرا ابزاری کند است: وقتی فعال می‌شود، کل مسیر می‌میرد، از جمله گره‌هایی که درست رفتار می‌کردند. یک سقف هر گره اجازه می‌دهد یک زیرکار سرکش متوقف شود، به‌عنوان شکست‌خورده علامت‌گذاری شود، و به برنامه‌ریز گزارش داده شود، که سپس می‌تواند حول آن دوباره برنامه‌ریزی کند. بقیه اجرا ادامه می‌یابد.
این کار برنامه‌ریز را تغییر می‌دهد. برنامه‌ریزی که بازخورد هزینه سطح گره دریافت می‌کند می‌تواند تجزیه‌ها را بر اساس هزینه مورد انتظار انتخاب کند، نه فقط درستی مورد انتظار. گره‌های با واریانس بالا سطح ابزار باریک‌تری می‌گیرند، چون سطح کوچک‌تر فضای کارهایی که گره می‌تواند اشتباه انجام دهد را کاهش می‌دهد. گره‌هایی که همیشه دوباره تلاش می‌کنند قبل از گرفتن بودجه بیشتر بازنویسی می‌شوند، چون بودجه محدودیت نیست. گره‌هایی که ارزان و قابل اعتماد هستند می‌توانند آزادی عمل بیش
اجرای بودجه به یک ورودی زمان‌بندی تبدیل می‌شود. به‌جای یک غافلگیری ماهانه، محدودیت در زمان برنامه و در هر مرز گره در دسترس است. برنامه‌ریز حدس نمی‌زند که آیا می‌تواند یک تجزیه را بپردازد؛ یک پیشین روی هزینه‌های گره از اجراهای قبلی دارد.
مبادله واقعی است. حسابداری سطح گره نیاز دارد که برنامه‌ریز شناسه‌های گره پایدار صادر کند، که یعنی تجزیه برنامه‌ریز باید قابل مشاهده و قابل بازتولید باشد. برنامه‌ریزهایی که در هر اجرا تجزیه آزاد تولید می‌کنند شناسه‌هایی تولید می‌کنند که تجمیع نمی‌شوند. ابزارگذاری یک انتخاب را تحمیل می‌کند: یا تجزیه به‌قدر کافی پایدار است که اندازه‌گیری شود، یا نیست، و هزینه غیرقابل انتساب می‌ماند. تیم‌هایی که نوع دوم برنامه‌ریز را می‌خواهند — کاملاً آزاد، حداکثر سازگار — با رها کردن حلقه کنترل هزینه آن را می‌پردازند. این یک انتخاب مشروع است. رایگان نیست.
این چه چیزی را جایگزین می‌کند
داشبوردهای هزینه پس‌ازواقع یک مصنوع گزارش‌دهی هستند. آن‌ها به شما می‌گویند ماه گذشته چه اتفاقی افتاد، به‌صورت تجمیعی، بعد از اینکه پول خرج شد. برای مالی مفید و برای مهندسی بی‌فایده هستند، چون تا زمانی که عدد قابل مشاهده شود اجرا تمام شده و برنامه‌ای که آن را ایجاد کرده رفته است.
حسابداری گره‌های برنامه یک حلقه کنترل است. در واحدی اندازه‌گیری می‌کند که برنامه‌ریز واقعاً کنترل می‌کند، در طول اجراها تجمیع می‌کند تا واریانس قابل مشاهده باشد، و به تجزیه بعدی بازخورد می‌دهد. تفاوت در دانه‌بندی نمودار نیست. این است که آیا اندازه‌گیری می‌تواند اجرای بعدی را تغییر دهد.
شکل عملی
یک پیاده‌سازی حداقلی چهار بخش دارد.
- برنامه‌ریز شناسه‌های گره را به‌عنوان بخشی از تجزیه خود صادر می‌کند، و زمان اجرا آن‌ها را روی هر فراخوانی مدل و ابزار حمل می‌کند.
- یک جمع‌آور هزینه، تأخیر، تعداد تلاش مجدد و وضعیت شکست را به‌ازای هر گره در طول اجراها تجمیع می‌کند.
- یک لایه سیاست توزیع هر گره را می‌خواند و سقف‌ها، انتخاب مدل و محدودیت‌های سطح ابزار را در مرز گره اعمال می‌کند.
- برنامه‌ریز پیشین‌های لایه سیاست را هنگام انتخاب تجزیه بعدی مصرف می‌کند.
بخش سخت لوله‌کشی نیست. پذیرش این است که تجزیه یک مصنوع مهندسی با امضای هزینه است، و اندازه‌گیری آن تنها راه تبدیل بودجه‌بندی به یک تصمیم طراحی به‌جای یک رویداد حسابداری است.