برداشت نادرست
وقتی پنجره زمینه یک مدل بزرگ می‌شود، غریزه این است که محدودیت را حل‌شده فرض کنیم. پنجره به یک سطل تبدیل می‌شود: همه‌چیز را در آن بریز و بگذار مدل آن را مرتب کند. این برداشت نادرستی از هدف پنجره است. پنجره جایگزین نظم بازیابی نیست؛ بودجه‌ای با شکل متفاوت است.
توجه به تاریخچه نامرتبط خنثی نیست. هر توکنی که حاضر اما نامرتبط باشد برای وزن توجه رقابت می‌کند و کیفیت تصمیم مدل با کاهش نسبت سیگنال به نویز افت می‌کند. این اثر یک پرتگاه سخت نیست؛ یک شیب است. اجرایی که با زمینه فشرده درست می‌بود، وقتی همان پرس‌وجو با مصنوعات نامرتبط پر شود، قابل‌قبول به نظر می‌رسد اما غلط است. حالت شکست بی‌صدا است: مدل هنوز خروجی روان تولید می‌کند، بنابراین افت فقط زمانی قابل مشاهده است که خروجی با حقیقت مبنا بررسی شود.
زمان‌بندی زمینه
بازتعریف ساده است: مونتاژ زمینه یک مسئله زمان‌بندی است. پرسش این نیست که «چقدر می‌توانیم جا دهیم» بلکه «گام فعلی به چه چیزی نیاز دارد و چه زمانی به آن نیاز دارد». یک زمان‌بند تصمیم می‌گیرد چه چیزی بارگذاری شود، چه زمانی بارگذاری شود و چه چیزی حذف شود. وقتی به یک اجرای عامل اعمال شود، این یعنی اجرا را به فازهایی تقسیم کنیم که هر کدام یک قرارداد زمینه صریح دارند.
فقط آنچه گام فعلی نیاز دارد را بارگذاری کنید
یک گام باید مصنوعات مورد نیازش را دریافت کند و نه چیز دیگری. در عمل این یعنی سازنده زمینه یک الحاق‌کننده نیست؛ یک انتخاب‌گر با مانیفست است. هر گام ورودی‌هایش را اعلام می‌کند: یک طرح‌واره، یک پرس‌وجوی بازیابی، مجموعه‌ای از نتایج ابزار قبلی، برشی از برنامه. سازنده آن اعلان‌ها را در برابر مخزن حالت اجرا حل می‌کند و کوچک‌ترین زمینه‌ای را که قرارداد را برآورده می‌کند مونتاژ می‌کند.
یک مکانیزم مشخص: مانیفست زمینه به ازای هر گام با ورودی‌های نوع‌دار.
{
"step": "reconcile_invoice",
"requires": [
{"type": "artefact", "id": "invoice_4417", "max_tokens": 1200},
{"type": "tool_result", "id": "ledger_lookup", "freshness": "current"},
{"type": "policy", "id": "ap_policy_v3", "pinned": true}
],
"excludes": ["chat_history_older_than_phase", "raw_pdf_bytes"]
}
سازنده این مانیفست را حل می‌کند، مصنوعاتی که از بودجه‌شان فراتر می‌روند را کوتاه می‌کند و آنچه بارگذاری کرده را ثبت می‌کند. این ثبت چیزی است که اجرا را قابل حسابرسی می‌کند: وقتی یک گام پاسخ غلط تولید می‌کند، پرسش اول این است که آیا مصنوع مورد نیاز حاضر بوده، نه اینکه آیا مدل توانمند بوده است.
ارتقا و تنزل را صریح انجام دهید
اجراهای بلند تمایل دارند به‌طور پیش‌فرض زمینه جمع کنند. هر فاز خروجی‌اش را ضمیمه می‌کند و پنجره با تاریخچه خود اجرا پر می‌شود. جایگزین، ارتقا و تنزل صریح بین فازهاست. در مرز یک فاز، اجرا یک مصنوع خلاصه می‌نویسد و مواد خامی که خلاصه کرده را تنزل می‌دهد. فاز بعدی از خلاصه شروع می‌شود، نه از رونوشت.
این یک تصمیم زمان‌بندی با هزینه است. خلاصه‌ها جزئیات را از دست می‌دهند؛ ممکن است بعداً به مصنوع تنزل‌یافته نیاز باشد و واکشی مجدد آن یک فراخوانی ابزار و تأخیر هزینه دارد. این بده‌بستان واقعی است: تنزل تهاجمی زمینه را فشرده نگه می‌دارد اما خطر از دست دادن جزئیاتی که مهم بوده را دارد. راه کاهش این خطر نگه داشتن همه‌چیز نیست؛ قابل بازگشت کردن تنزل است. مصنوعات تنزل‌یافته در مخزن اجرا می‌مانند، نمایه‌سازی شده و قابل بازیابی، تا یک گام بعدی بتواند آن‌ها را در صورت نیاز دوباره ارتقا دهد. پنجره مجموعه کاری را نگه می‌دارد؛ مخزن آرشیو را نگه می‌دارد.
حالت را چک‌پوینت کنید تا یک اجرای بلند بتواند از سر گرفته شود
یک اجرای بلندمدت که نمی‌تواند از سر گرفته شود، اجرایی است که پس از هر وقفه باید کل تاریخچه‌اش را بازپخش کند. این بازپخش گران است و بدتر، همان نویزی را دوباره وارد می‌کند که زمان‌بند برای اجتناب از آن ساخته شده بود. چک‌پوینت کردن حالت در مرزهای فاز، مدت اجرا را از اندازه زمینه‌اش جدا می‌کند.
یک چک‌پوینت باید به اندازه کافی ثبت کند تا بدون رونوشت از سر گرفته شود: برنامه و موقعیت فعلی‌اش، مصنوعات تولیدشده تا کنون (با ارجاع، نه با مقدار)، نتایج ابزاری که هنوز معتبرند، و مانیفست آنچه هر گام تکمیل‌شده مصرف کرده است. در زمان از سرگیری، زمان‌بند زمینه گام فعلی را از چک‌پوینت به‌علاوه هر آنچه مانیفست گام نیاز دارد بازسازی می‌کند. تاریخچه اجرا برای حسابرسی در دسترس است
edia/server-rack-closeup-dark-d40599-0ca2dd.jpg)
اینجاست که چارچوب زمان‌بندی نتیجه می‌دهد. بدون چک‌پوینت‌ها، زمینه یک اجرای بلند تابعی از طول آن است. با چک‌پوینت‌ها، زمینه تابعی از قرارداد گام فعلی است و طول به ویژگی مخزن تبدیل می‌شود نه پنجره.
پیامد ارزیابی
اگر زمینه زمان‌بندی می‌شود، پس یک عدد موفقیت تجمیعی واحد واحد ارزیابی اشتباهی است. اجرایی که در افق ۵ موفق می‌شود و در افق ۵۰ شکست می‌خورد یک سیستم ۹۰٪ نیست؛ سیستمی با نمایه شکست وابسته به افق است. تجمیع شکل را پنهان می‌کند.
ارزیابی باید موفقیت را به‌عنوان تابعی از طول افق گزارش کند. به‌طور مشخص: افق را بر حسب گام‌ها یا فراخوانی‌های ابزار تعریف کنید، همان خانواده وظیفه را در افق‌های فزاینده اجرا کنید و منحنی را گزارش دهید. موفقیت کجا پایدار است، کجا خم می‌شود و در خم چه چیزی تغییر می‌کند؟ منحنی‌ای که صاف است و سپس در افق مشخصی سقوط می‌کند به یک شکست زمان‌بندی اشاره دارد: یک مرز فاز که در آن یک مصنوع مورد نیاز تنزل یافته، یک چک‌پوینت که فیلدی را حذف کرده، یک مانیفست که ورودی‌هایش را کم‌برآورد کرده است.
این همچنین بده‌بستان‌ها را قابل مشاهده می‌کند. یک سیاست تنزل تهاجمی‌تر ممکن است هزینه هر گام را بهبود بخشد در حالی که خم را زودتر می‌آورد. یک سیاست بارگذاری مجازتر ممکن است افق را گسترش دهد در حالی که هزینه را بالا می‌برد. هیچ‌کدام به‌تنهایی غلط نیستند؛ منحنی چیزی است که به شما می‌گوید کدام را دارید.
همین نظم در مورد مواد منبع هم اعمال می‌شود. ادعاها درباره توانایی بلندمدت باید به‌عنوان ادعاهایی درباره یک منحنی خوانده شوند، نه یک نقطه. سیستمی که یک عدد واحد برای یک وظیفه بلندمدت گزارش می‌کند، میانگین توزیعی را گزارش می‌کند که آن را مشخص نکرده است، و بخش جالب آن توزیع دنباله است.
این در عمل چه چیزی را تغییر می‌دهد
برخورد با زمینه به‌عنوان یک مسئله زمان‌بندی سه چیز را در یک پایگاه کد عامل تغییر می‌دهد. سازنده زمینه به یک انتخاب‌گر با مانیفست تبدیل می‌شود، نه یک الحاق‌کننده. مرزهای فاز به نقاط ارتقا و تنزل صریح تبدیل می‌شوند، با مخزنی که تنزل را قابل بازگشت می‌کند. حالت اجرا چک‌پوینت می‌شود، بنابراین از سرگیری به معنای بازپخش نیست.
هیچ‌کدام از این‌ها محدودیت زمینه را حذف نمی‌کند. آنچه محدودیت بر آن اعمال می‌شود را تغییر می‌دهد. به جای محدود کردن طول یک اجرا، محدود می‌کند که زمان‌بند چقدر خوب زمینه را با گام تطبیق می‌دهد. این مسئله‌ای قابل‌حل‌تر است و همان چیزی است که پردازش بلندمدت واقعاً مطرح می‌کند.