«بدون افت دقت»؛ استراتژی جدید برای بهینه‌سازی توکن‌های ورودی

تصور کنید با حذف ۴۵ ابزار غیرضروری از فهرست دستورات یک مدل، مصرف توکن‌های ورودی شما ۸۳.۷۹٪ کاهش یابد، اما دقت پاسخ‌ها حتی یک درصد هم افت نکند. این نتیجه نشان می‌دهد که تخصص‌بخش کردن مدل‌ها را می‌توان در مرز استنتاج (Inference) — یعنی همان لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه به آشپزی کردن پس از یادگیری دستور پخت — انجام داد، نه از طریق بازآموزی‌های گران‌قیمت و هزینه‌بر مدل.

بسیاری از توسعه‌ده‌دهندگان در حال حاضر با عامل‌های (Agents) هوش مصنوعی مانند یک «همه‌فن‌حریف» برخورد می‌کنند و تمام ابزارها، دستورالعمل‌ها و زمینه‌های ممکن را در یک پرامپت واحد می‌چپانند. این روش باعث حجیم شدن پنجره زمینه (Context Window) — که مثل میز کاری است و فقط جای چند ورق کاغذ دارد، نه کل کتابخانه — می‌شود و مدل را مجبور می‌کند میان گزینه‌های نامرتبط جست‌وجو و فیلتر کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی اینکه چگونه مدل‌های محلی می‌توانند با تضمین‌های بالا با پاسخ‌های LLMها برابری کنند اشاره کردیم، تمرکز اکنون از «اندازه مدل» به «نحوه بهره‌برداری از قابلیت‌های موجود» تغییر کرده است.

به عنوان مثال، یک دستیار برنامه‌نویس را در نظر بگیرید. به‌جای یک پرامپت عظیم شامل ابزارهای مخزن کد، APIهای تقویم و توابع جست‌وجو، سیستم از یک «پروفایل استنتاج» استفاده می‌کند. این پروفایل مانند یک قرارداد اجرایی عمل می‌کند که دقیقاً تعیین می‌کند مدل در هر مرحله از یک وظیفه، چه چیزی را ببیند و چه کاری انجام دهد.

معماری پروفایل‌های استنتاج

یک پروفایل استنتاج صرفاً یک پرامپت برای تعیین شخصیت نیست، بلکه واحد معماری پیرامون یک فراخوانی مدل است. طبق مستندات این رویکرد، یک پروفایل کامل باید سیاست‌های سخت‌گیرانه‌ای را تعریف کند:

• دستورالعمل‌ها: چه وظیفه‌ای باید در این مرحله تکمیل شود و چه مواردی صراحتاً خارج از مسئولیت این مرحله است؟
• سیاست زمینه: کدام پیام‌ها، فایل‌ها، حافظه‌ها و شواهد بازیابی‌شده باید در این درخواست باشند؟
• سیاست ابزار: کدام طرح‌واره‌ها (Schemas) در دسترس باشند و کدام عملیات‌ها اجازه اجرا دارند؟
• سیاست تولید: تنظیمات نمونه‌برداری (Sampling) و کنترل‌های استدلالی کدام باشند؟
• بودجه منابع: چه مقدار توکن ورودی/خروجی، زمان اجرا و تعداد تکرار مجاز است؟
• قرارداد خروجی: نتیجه باید به صورت متن، فراخوانی ابزار، یک وصله (Patch) یا داده‌های ساختاریافته باشد؟
• سیاست پذیرش: این نقش مجاز به ارسال چند درخواست است و در صورت فشار زیاد و سربار (Overload) چه اتفاقی می‌افتد؟

برای اثرگذاری، این پیکربندی باید به خودِ فراخوانی مدل برسد. اگر یک آداپتور لایه سازگارساز، محدودیت خروجی را به درخواست مدل منتقل نکند، تعریف آن بی‌فایده است. به همین ترتیب، یک لیست سفید (Allowlist) از ابزارها بی‌اثر است اگر مسیر دیگری در سیستم، فهرست جهانی ابزارها را پس از آن به درخواست متصل کند. سیستم باید پروفایل نهایی را پیش از ارسال resolve کند و نسخه آن، شامل مجموعه ابزارها، اندازه زمینه، محدودیت‌های تولید و زمان انتظار (Timeout) را در تشخیص‌های سطح درخواست ثبت نماید.

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

• گفتگو (Chat): از زمینه کاربر و گفتگوهای مرتبط برای پاسخ مستقیم با استفاده از مجموعه کوچکی از قابلیت‌های روزمره استفاده می‌کند.
• استدلال (Reasoning): با استفاده از مسئله، محدودیت‌ها و شواهد منتخب، ابهامات باقی‌مانده را در یک بودجه مشخص حل می‌کند.
• کدنویسی (Code): از فایل‌های مرتبط، اینترفیس‌ها، خطاها و نتایج تست برای ارائه وصله یا تشخیص خطا از طریق عملیات محدودشده در مخزن کد و اجرای محیط ایزوله (Sandbox) استفاده می‌کند.
• میانجی (Mediator): با استفاده از یک پرسش پژوهشی محدود و محدودیت‌های منبع، شواهد ساختاریافته‌ای را برای مراحل بعدی جمع‌آوری می‌کند.

مسیریابی و اجرا

لایه مسیریابی تصمیم می‌گیرد کدام پروفایل فعال شود یا آن‌ها را در یک گراف وابستگی مرتب می‌کند تا مراحل مستقل به‌صورت موازی اجرا شوند. این لایه نیازی ندارد هر درخواست را از هر نقش عبور دهد. برای حفظ شفافیت، سه شناسه باید متمایز بمانند: نقطه ورود کاربر، مسئولیت عامل اجرایی و نقطه انتهایی (Endpoint) یا نام مستعار مدل.

به عنوان مثال، یک نقطه ورود «کدنویسی» ممکن است ابتدا به یک عامل پژوهش و سپس به یک عامل کدنویس نیاز داشته باشد. چندین عامل ممکن است یک Endpoint واحد را با پارامترهای متفاوت فراخوانی کنند. نام‌گذاری چهار نام مستعار (Alias) به تنهایی چهار رفتار متفاوت ایجاد نمی‌کند؛ بلکه این پروفایل است که رفتار را هدایت می‌کند.

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

نتایج آزمایشی انتخاب ابزار

برای تست این فرضیه، نویسنده ۴۰ درخواست را در چهار وضعیت مختلف با یک مدل مشترک اجرا کرد. این آزمون شامل ۱۰ درخواست ساختگی بود: ۵ مورد به زبان انگلیسی و ۵ مورد به زبان روسی. در این میان، ۶ درخواست یک ابزار واحد، ۲ درخواست هیچ ابزاری و ۲ درخواست دو عملیات مستقل را طلب کردند.

فهرست ابزارهای اصلی شامل ۵ قابلیت مربوط به مخزن کد بود: خواندن محتوای فایل فعلی، جست‌وجوی متن منبع، خواندن تاریخچه کامیت‌ها، اجرای یک هدف تست نام‌گذاری شده و لیست کردن فایل‌های زیر یک دایرکتوری. تمام ابزارها صرفاً در سطح طرح‌واره (Schema) بودند و هیچ مخزن واقعی خوانده یا تغییر نکرد.

شرایط آزمایش و داده‌ها

• وضعیت الف (۵ ابزار اصلی): مجموعاً ۶,۲۰۸ توکن ورودی مصرف کرد. میانه: ۶۱۹.۵
• وضعیت ب (۲۰ ابزار مربوط به مخزن): مجموعاً ۱۶,۹۲۸ توکن ورودی مصرف کرد. میانه: ۱,۶۹۱.۵. این وضعیت شامل خواندن فایل‌های تاریخی، جست‌وجوی پیام کامیت، جست‌وجوی مستندات و خواندن گزارش‌های تست موجود بود.
• وضعیت ج (۲۰ ابزار بین‌حوزه‌ای): مجموعاً ۱۷,۶۰۸ توکن ورودی مصرف کرد. میانه: ۱,۷۵۹.۵. این ابزارها حوزه‌هایی مانند آب‌وهوا، تقویم، موسیقی، موجودی کالا و سفر را پوشش می‌دادند.
• وضعیت د (۵۰ ابزار ترکیبی): مجموعاً ۳۸,۲۸۸ توکن ورودی مصرف کرد. میانه: ۳,۸۲۷.۵

در تمام تسک‌ها، دستورالعمل سیستمی و پرامپت کاربر یکسان بود. فراخوانی‌ها از یک Endpoint و Alias مدل یکسان، دمای صفر، انتخاب خودکار ابزار، محدودیت خروجی ۲۵۶ توکن و یک Seed ثابت استفاده کردند. قابلیت تفکر (Thinking) صراحتاً از طریق گزینه Template سرویس‌دهنده غیرفعال شد. ترتیب وضعیت‌ها و ترتیب طرح‌واره‌ها به‌صورت قطعی (Deterministic) جابجا شدند.

در تمامی موارد، مدل نام ابزارها و آرگومان‌های مورد انتظار را دقیقاً بازگرداند. وضعیت ۵۰ ابزاری، ۶.۱۷ برابر بیشتر از وضعیت ۵ ابزاری توکن مصرف کرد تا به همان نتیجه برسد. کاهش توکن‌ها از وضعیت ۵۰ ابزاری به ۵ ابزاری دقیقاً ۸۳.۷۹٪ بود.

مدیریت فضای عملیاتی

فرضیه اصلی این است که کوچک‌تر کردن فضای عملیاتی (Action Space)، ابهام را کاهش می‌دهد. وقتی مدل هم‌زمان ابزارهای جست‌وجوی فایل، جست‌وجوی تاریخچه کامیت و جست‌وجوی پایگاه دانش را می‌بیند، ممکن است در انتخاب بهترین گزینه دچار مشکل شود چون همه آن‌ها برای عبارت «پیدا کن این رفتار از کجا آمده» مرتبط به نظر می‌رسند.

با حذف ابزارهای نامرتبط — مثل APIهای آب‌وهوا، تقویم، موسیقی، موجودی یا سفر — تمرکز مدل محدود می‌شود. با این حال، نویسنده هشدار می‌دهد که تعداد کمتر ابزار لزوماً به معنای دقت بیشتر نیست. یک مسیریاب ضعیف ممکن است ابزار ضروری را حذف کند یا مجموعه‌ای کوچک همچنان حاوی توصیف‌های هم‌پوشان باشد که مدل را گیج کند. تعداد ابزارها تنها یک متغیر است؛ شباهت معنایی، طول طرح‌واره و کیفیت توصیفات نیز اهمیت دارند.

شواهد خارجی نیز این موضوع را تایید می‌کنند. به گزارش Anthropic، استفاده از جست‌وجوی ابزارها باعث کاهش مصرف زمینه از حدود ۷۷ هزار توکن به ۸.۷ هزار توکن شد و هم‌زمان دقت را در ارزیابی‌های داخلی MCP بهبود بخشید. پروژه MetaTool نیز تصمیم درباره اینکه آیا اصلاً از ابزار استفاده شود یا خیر را به عنوان یک مسئله ارزیابی می‌بیند و اشاره می‌کند که انتخاب یک ابزار معتبر کافی نیست، در حالی که اقدام درست این است که بدون ابزار پاسخ داده شود.

ظرافت‌های پیاده‌سازی

تفاوت مهمی بین «نقش‌های استاتیک» و «کشف به تعویق افتاده» (Deferred Discovery) وجود دارد. نقش‌های استاتیک زیرمجموعه‌ای شناخته‌شده را از ابتدا ارائه می‌دهند که برای مرزهای پایدار (مثلاً تشخیص خطای مخزن کد که معمولاً به ابزارهای مخزن نیاز دارد و نه API تقویم) ایده‌آل است. در مقابل، کشف به تعویق افتاده با یک رابط کوچک شروع شده و طرح‌واره‌ها را فقط هنگام نیاز بارگذاری می‌کند. این روش برای فهرست‌های بزرگتر مناسب است اما یک تصمیم اضافی برای یافتن قابلیت درست قبل از استفاده ایجاد می‌کند.

پروژه‌هایی مانند AnyTool این موضوع را از طریق بازیابی سلسله‌مراتبی API، یک حل‌کننده (Solver) روی کاندیداهای منتخب و خود-بازتابی (Self-reflection) در صورت شکست راهکارهای اولیه بررسی می‌کنند. یک ترکیب کاربردی، داشتن یک مجموعه ابزار هسته کوچک به همراه یک مسیر کشف کنترل‌شده است. اگر تسکی به چیزی خارج از نقش فعلی نیاز داشت، عامل می‌تواند درخواست انتقال (Handoff) یا دسترسی به قابلیت‌های مجاز اضافی را بدهد. این حالت جایگزین (Fallback) باید در نتایج ارزیابی ثبت شود تا هزینه‌ها کمتر از حد واقعی تخمین زده نشوند.

علاوه بر این، گزارش تاکید می‌کند که «دیده شدن ابزار» به معنای «مجاز بودن» نیست. حتی اگر طرح‌واره‌ای برای بهینه‌سازی از پرامپت حذف شود، لایه اجرا باید به‌طور مستقل مجوزها را بررسی کند. نام ابزاری که توسط مدل تولید شده هرگز نباید بررسی‌های امنیتی را دور بزند.

نقش میانجی (Mediator)

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

پرسش پژوهشی $ \rightarrow $ انتخاب حوزه‌های مرتبط $ \rightarrow $ بازیابی منابع مجاز $ \rightarrow $ ارائه ابزارهای جمع‌آوری شواهد $ \rightarrow $ تولید و تایید طرح ساختاریافته $ \rightarrow $ اجرای عملیات مجاز $ \rightarrow $ بازگرداندن شواهد، شکاف‌ها و ارجاعات منبع.

پاسخ این پروفایل باید بین ادعاهای مستند و پرسش‌های حل‌نشده تمایز قائل شود. برای هر ادعا، باید شناسه منبع و شواهد کافی برای بررسی در مرحله بعد حفظ شود. استفاده از JSON با طرح‌واره محدود کمک می‌کند این ساختار حفظ شود، هرچند این موضوع ثابت نمی‌کند که ادعا حتماً درست است. اگر بازیابی چیزی پیدا نکرد، قرارداد باید اجازه عبارت «شواهد ناکافی» را بدهد تا مدل از توهم برای پر کردن شکاف‌ها استفاده نکند. میانجی‌ای که بیش از حد در توصیفات سخت‌گیرانه خلاصه می‌کند، ممکن است پاسخ‌های مراحل بعدی را سریع‌تر اما کمتر دقیق کند.

عملکرد و مقیاس‌پذیری

استفاده از یک نقطه بازرسی برای چندین نقش، هزینه حافظه بارگذاری وزن‌های مجزا را حذف می‌کند، اما یک «دامنه شکست مشترک» ایجاد می‌کند. توالی‌های فعال همچنان به وضعیت (State) نیاز دارند و پرامپت‌های بزرگ، فشار پیش‌پُرکردن (Prefill) ایجاد می‌کنند. یک موج پژوهشی می‌تواند صف انتظار را برای کاربران چت افزایش دهد چون هر دو برای ظرفیت شتاب‌دهنده رقابت می‌کنند.

برای کاهش این اثر، معماری به سقف‌های هم‌زمانی برای هر نقش، کنترل پذیرش، ضرب‌الاجل‌ها و محدود کردن Fan-out نیاز دارد. نویسنده اشاره می‌کند که در حالی که LLMCompiler بهبود تأخیر تا ۳.۷ برابر را از طریق اجرای موازی توابع برنامه‌ریزی شده نسبت به ReAct گزارش کرده، این دستاوردها به توانایی زیرساخت سرویس‌دهی در مدیریت درخواست‌های هم‌زمان بستگی دارد. نباید کد برنامه‌نویسی Asynchronous را با اجرای موازی مدل یکی دانست؛ ارسال‌های هم‌زمان همچنان به یک زمان‌بند مشترک می‌رسند که ممکن است آن‌ها را دسته‌بندی (Batch) یا در صف قرار دهد.

اندازه‌گیری موفقیت

این آزمون نشان می‌دهد «صحت انتخاب» (انتخاب ابزار درست) تنها گام اول است. به دلیل اثر سقفی (Ceiling Effect) در این تست که همه وضعیت‌ها نمره کامل گرفتند، نمی‌توان معادل بودن آن‌ها را در بارهای کاری گسترده‌تر و مبهم‌تر اثبات کرد. یک ارزیابی جامع باید این موارد را ردیابی کند:

۱. انتخاب: آیا مدل ابزار پذیرفته‌شده را انتخاب کرد یا به‌درستی از انتخاب خودداری کرد؟
۲. آرگومان‌ها: آیا فراخوانی، هم طرح‌واره و هم محدودیت‌های واقعی تسک را رعایت کرد؟
۳. اجرا: آیا عملیات مجاز در برابر یک محیط کنترل‌شده (Fixture) موفق بود؟
۴. پاسخ: آیا پاسخ نهایی با استفاده از شواهد بازگشتی، مشکل کاربر را حل کرد؟

این رویکرد چندسطحی، مشابه ارزیابی فراخوانی تابع برکلی (Berkeley Function Calling)، مانع از آن می‌شود که یک نمره بالای «نام ابزار» باعث پنهان شدن شکست در تکمیل واقعی تسک شود. توسعه‌دهندگان همچنین باید توکن‌های طرح‌واره، مجموع توکن‌های ورودی/خروجی در هر مرحله، تعداد تکرارها و زمان تا نخستین توکن (TTFT) را ثبت کنند.

اندازه‌گیری باید بین رفتار حافظه سرد و گرم تمایز قائل شود. در حالی که پرامپت‌های کوتاه‌تر فشار پیش‌پُرکردن را کم می‌کنند، پیشوندهای خاص هر نقش ممکن است اشتراک بین درخواست‌ها را کاهش دهد. بازاستفاده از حافظه پیشوند (Prefix-cache) به پیاده‌سازی سرویس‌دهی و ساختار پرامپت بستگی دارد، نه فقط تخصص‌بخش کردن. در نهایت، تمام نتایج باید همراه با مجموعه داده‌ها (Corpus)، طرح‌واره‌ها، Seedهای ترتیب و پاسخ‌های خام ذخیره شوند تا بازتولیدپذیری تضمین شود.

این چرخش به سمت تخصص در زمان استنتاج به این معناست که توسعه‌دهندگان می‌توانند به‌جای تعقیب پنجره‌های زمینه بزرگ‌تر، طراحی گردش‌کارهای عامل‌های فشرده‌تر و پیش‌بینی‌پذیرتر را آغاز کنند. این رویکرد با استراتژی‌هایی مانند مدیریت هزینه‌های عملیاتی از طریق کاتالوگ‌های مدل یکپارچه هم‌سو است که هدفشان بهینه‌سازی منابع در مقیاس تولید است. با تبدیل مرز پرامپت به یک قرارداد برنامه‌ریزی‌شده، می‌توانید هزینه‌ها و تأخیر را بدون قربانی کردن قدرت مدل‌های بزرگ کاهش دهید.

گام بعدی شما

• فهرست ابزارهای مدل خود را تحلیل کنید و ابزارهای هم‌پوشان یا کم‌کاربرد را در نقش‌های مجزا تقسیم کنید.
• برای هر مرحله از زنجیره عامل خود، یک «قرارداد خروجی» (مانند JSON سخت‌گیرانه) تعریف کنید تا خطای مراحل بعدی کاهش یابد.
• نرخ مصرف توکن‌های ورودی را در حالت «همه ابزارها» در برابر «ابزارهای منتخب» اندازه بگیرید تا نقطه بهینه دقت و هزینه را بیابید. این تحلیل به شما کمک می‌کند تا مشابه رویکرد مدل‌های گروهی در Oxlo.ai، تعادلی میان دقت بالا و مصرف بهینه توکن‌ها برقرار کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.