«حذف توصیفات تکراری»؛ راهکار جدید برای افزایش تمرکز مدل‌های زبانی

اگر برای هر درخواستِ عامل هوش مصنوعی خود هزینه‌های استنتاج سنگینی می‌پردازید، احتمالاً با مشکل «تورم پرامپت» دست‌وپنجه نرم می‌کنید. حذف ۱۴٬۲۷۵ توکن از یک مجموعه ابزار، تنها باعث صرفه‌جویی مالی نمی‌شود، بلکه «منطقه هوشمند» مدل را برای حل مسائل پیچیده‌تر بازیابی می‌کند. به نقل از راهنمای دقیقی که در ۲۷ سپتامبر ۲۰۲۶ در dev.to منتشر شد، کاربران Pi Agent می‌توانند بدون از دست دادن حتی یک قابلیت، سربار پرامپت‌های ابزار را تا ۹۱٪ کاهش دهند.

اکثر عامل‌های هوش مصنوعی از تورم پرامپت رنج می‌برند؛ نویسندگان افزونه‌ها اغلب دستورالعمل‌های مفصل و سخت‌گیرانه‌ای می‌نویسند تا مدل‌های قدیمی‌تر دچار خطا نشوند. اما با ظهور مدل‌های توانمندتری مثل Claude Opus 4.5 و 4.6، این هشدار‌های طولانی — که پر از کلمات تأکیدی با حروف بزرگ مثل «باید» (MUST) و «هرگز» (NEVER) هستند — در واقع با اشغال بودجهٔ محدود توجه (Attention) مدل، عملکرد آن را تضعیف می‌کنند.

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

زمینه و ریشهٔ تورم پرامپت

Pi Agent به دلیل زمینهٔ (Context) پاکش شناخته می‌شود و پرامپت سیستمی پیش‌فرض آن تنها حدود ۲ هزار توکن است. این رقم در مقایسه با Codex (بیش از ۱۰ هزار) یا Claude Code (بیش از ۲۰ هزار) تفاوت چشمگیری دارد. با این حال، این مزیت با نصب افزونه‌ها از بین می‌رود. بسیاری از افزونه‌ها توصیفات طولانی ابزارها را دارند که در هر درخواست به‌طور کامل ارسال می‌شوند.

قبل از اینکه کاربر حتی اولین پیام را بفرستد، هزاران یا ده‌ها هزار توکن توسط این توصیفات مصرف می‌شود. این موضوع هم هزینه مالی دارد و هم تمرکز مدل را بی‌دلیل می‌بلعد. حتی مدل‌هایی با پنجره متنی یک میلیون توکنی، یک «منطقه هوشمند» محدود (حدود ۲۰۰ تا ۳۰۰ هزار توکن) دارند. وقتی توصیفات ابزار این فضا را اشغال می‌کنند، توجه مدل رقیق می‌شود. این تقصیر نویسندگان نیست؛ چند سال پیش مدل‌ها برای عملکرد درست به دستورات «باید» و دیکته کردن گام‌به‌گام نیاز داشتند، اما مدل‌های امروز به مهندسی کمتر و دقیق‌تر نیاز دارند.

علم بودجهٔ توجه

این تغییر رویکرد بر اساس تحقیقات Anthropic است. آن‌ها در مقاله Effective context engineering for AI agents توضیح می‌دهند که مدل‌ها یک «بودجه توجه» دارند و هر توکن در زمینه، بخشی از این بودجه را مصرف می‌کند. هدف این است که کوچک‌ترین مجموعه از توکن‌های «پرسیگنال» پیدا شوند که احتمال رسیدن به نتیجه مطلوب را به حداکثر برسانند.

طبق گزارش Anthropic در بخش Prompting best practices، مدل‌های Opus 4.5 و 4.6 پرامپت‌های سیستمی را دقیق‌تر از نسخه‌های قبلی دنبال می‌کنند. در نتیجه، زبان تهاجمی که برای جلوگیری از تنبلی مدل‌های قدیمی به کار می‌رفت، حالا باعث می‌شود مدل‌های جدید بیش از حد از ابزارها استفاده کنند. راهکار پیشنهادی، کاهش لحن تهاجمی است؛ به‌جای «بسیار حیاتی: باید از این ابزار استفاده کنی...»، عبارت سادهٔ «از این ابزار استفاده کن وقتی...» مؤثرتر است.

در Opus 5، مدل کارهای خود را بازبینی می‌کند. دستوراتی مثل «قبل از پایان، بررسی کن» اکنون زائد هستند و می‌توانند باعث شوند مدل در یک حلقهٔ بازبینی ابدی گیر کند و توکن‌ها و زمان را بسوزاند. توصیه ساده است: این دستورات را بازنویسی نکنید، فقط آن‌ها را حذف کنید.

هزینهٔ تکرار و داده‌های آماری

این راهنما تضاد شدیدی را بین افزونه‌های «بالادستی» و نسخه‌های «لین» (Lean) نشان می‌دهد. در یک مورد، افزونه pi-subagents از ۸٬۵۴۰ توکن به تنها ۲۶۸ توکن رسید. در مجموع پنج افزونه رایج، تعداد کل توکن‌ها از ۱۵٬۶۹۵ به ۱٬۴۲۰ کاهش یافت.

تفکیک کاهش توکن‌ها:

• pi-web-access-lean: از ۲٬۹۵۳ به ۱۵۲ (۹۴.۹٪ کاهش)
• rpiv-ask-user-question-lean: از ۱٬۲۵۸ به ۲۱۵ (۸۲.۹٪ کاهش)
• rpiv-todo-lean: از ۹۰۴ به ۲۴۸ (۷۲.۶٪ کاهش)
• pi-subagents-lean: از ۸٬۵۴۰ به ۲۶۸ (۹۶.۹٪ کاهش)
• pi-hashline-edit-pro-lean: از ۲٬۰۴۰ به ۵۳۷ (۷۳.۷٪ کاهش)

این کاهش با شناسایی سه نوع اتلاف حاصل شده است:

• تکرار: توضیح هدف یک پارامتر به‌طور هم‌زمان در توصیف ابزار، قوانین و طرحواره (Schema).
• یادداشت‌های انسان‌محور: گنجاندن جزئیات رابط کاربری (مثل استایل فونت یا عرض پنل‌ها) که برای توسعه‌دهنده انسان مفید است اما برای مدل زبانی بزرگ (LLM) بی‌معنی است.
• لحن بیش از حد دستوری: استفاده از زبان تهاجمی برای جلوگیری از «تنبلی»، که مدل‌های جدید آن را سیگنالی برای استفادهٔ بیش از حد از ابزارها می‌بینند.

متد اول: تراشیدن متن

در افزونه rpiv-todo (ساختهٔ juicesharp)، نسخه بالادستی وضعیت وظایف را سه بار توضیح می‌دهد: در توصیف ابزار، در قانون ۴ و در توصیف پارامتر وضعیت. نسخه لین این توضیحات متنی را کاملاً حذف می‌کند چون وضعیت قبلاً در طرحواره به عنوان یک 'enum' تعریف شده است. مدل گزینه‌های موجود را می‌شناسد و نیازی به پاراگراف توضیحی ندارد.

سایر موارد زائد در rpiv-todo شامل پارامتر activeForm بود که آن هم سه بار توضیح داده شده بود. نسخه لین همچنین لحن تهاجمی مثل دستور به ثبت وظایف «فوراً» (IMMEDIATELY) یا «قبل از» (BEFORE) با حروف بزرگ را حذف کرد. همچنین قوانین سخت‌افزاری، مثل الزام به استفاده از لیست وظایف برای بیش از ۳ مرحله، حذف شدند و این تصمیم به فایل AGENTS.md کاربر سپرده شد.

در نسخه لین rpiv-todo، مدل ساختاری ساده می‌بیند:

• توصیف ابزار: یک عبارت موجز «ردیاب وظایف» با اکشن‌های مورد نیاز (create|update|list|get|delete|clear). ذکر می‌کند که create به موضوع و update/get/delete به شناسه (ID) نیاز دارند.
• قوانین: تنها یک قانون: «برای وظایف چندمرحله‌ای استفاده شود». وابستگی‌ها و وضعیت‌ها در یک جمله ادغام شده‌اند: «update به فیلدهای تغییر یافته نیاز دارد؛ list وضعیت/شامل حذف شده‌ها را می‌پذیرد؛ clear همه را پاک می‌کند؛ create از blockedBy پشتیبانی می‌کند؛ update از addBlockedBy/removeBlockedBy پشتیبانی می‌کند؛ یک مورد in_progress نگه دار و وظایف را سریعاً کامل کن».
• طرحواره: نام فیلدهایی مثل subject و owner و includeDeleted زمینهٔ لازم را بدون نیاز به متن فراهم می‌کنند.

به همین ترتیب، ابزار rpiv-ask-user-question (همچنین ساخته juicesharp) صدها توکن را صرف توضیح این می‌کرد که رابط کاربری به‌طور خودکار ردیف «چیزی تایپ کنید» را اضافه می‌کند. حتی شامل یادداشت‌هایی بود که ردیف هنگام تایپ به عرض کامل گسترش می‌یابد — جزئیاتی که برای انسان است، نه مدل. همچنین محدودیت‌های طول (MAX 60 CHARACTERS) در متن نوشته شده بود، در حالی که طرحواره از طریق maxLength و minItems و maxItems این مورد را اجبار می‌کرد.

نسخه لین این ابزار، پرامپت را به یک توصیف ساده کاهش می‌دهد: «زمانی که تصمیم کاربر نامشخص است، ۱ تا ۴ سؤال ساختاریافته بپرس». فقط قوانین پرسیگنال حفظ شده‌اند:

• هر سؤال به ۲ تا ۴ گزینه نیاز دارد.
• توصیه‌ها باید اول بیایند و با عبارت (Recommended) مشخص شوند.
• هرگز گزینه‌های «سایر» یا «چیزی تایپ کنید» را به‌صورت دستی اضافه نکن.
• از multiSelect فقط برای انتخاب‌های غیرانحصاری استفاده کن.
• از preview فقط برای مقایسه‌های بصری تک‌انتخابی مفید استفاده کن.

متد دوم: ادغام و پنهان‌سازی پیچیدگی

پیچیدگی را نمی‌توان حذف کرد، بلکه فقط می‌توان آن را جابه‌جا کرد (قانون تسلر). این راهنما پیشنهاد می‌کند منطق را از پرامپت به کد منتقل کنید. اگر مدل یک پارامتر ضروری را فراموش کرد، کد باید آن را استنتاج کند، نه اینکه پرامپت مدام مدل را یادآوری کند. برای مثال، در ابزار todo لین، اگر شناسه و فیلدهای تغییر یافته حضور داشته باشند، کد به‌طور خودکار اکشن را «update» فرض می‌کند.

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

• pi-subagents: چهار ابزار (از جمله SubagentWorkflow با ۵٬۶۱۱ توکن) را در یک ابزار با پارامتر op (run, result, steer, workflow, help) ادغام کرد. پارامترهای رایج مثل task، label، نوع subagent و وضعیت اجرای پس‌زمینه در طرحواره هستند و گزینه‌های پیشرفته به‌صورت رشته JSON ارسال می‌شوند.
• pi-web-access: چهار ابزار (web_search, source_check, fetch_content, get_search_content) را در یک ابزار web_access با همان الگوی op ادغام کرد.

گزینه‌های پیشرفته و کم‌کاربرد به عملیات help منتقل شده‌اند. مدل تنها یک بار op: help را برای دریافت مستندات کامل بالادستی در صورت نیاز فراخوانی می‌کند و پرامپت اصلی برای ۹۹٪ درخواست‌ها لین باقی می‌ماند. این با توصیه Anthropic همسو است که ابزارهای زیاد یا هم‌پوشان می‌توانند عامل‌ها را از استراتژی‌های کارآمد منحرف کنند. اگر یک مهندس انسان نتواند به‌طور قطعی بگوید در یک موقعیت از کدام ابزار استفاده کند، نمی‌توان از یک عامل هوش مصنوعی انتظار عملکرد بهتر داشت.

متد سوم: محافظت از حافظهٔ موقت (Cache)

برخی توسعه‌دهندگان سعی می‌کنند با بارگذاری پویا (Dynamic) ابزارها در میانه جلسه، توکن‌ها را ذخیره کنند. برای مثال، نسخه ۰.۳۱ pi-web-access ابتدا یک ابزار کوچک web_enable را بارگذاری می‌کند که سپس چهار ابزار دیگر را فعال می‌کند. این راهنما به دلیل مکانیزم حافظه موقت پرامپت (Prompt Caching) نسبت به این کار هشدار می‌دهد.

اکثر ارائه‌دهندگان بر اساس تطبیق پیشوند (Prefix Match) حافظه را ذخیره می‌کنند. چون تعاریف ابزارها معمولاً در ابتدای درخواست هستند، تغییر لیست ابزارها در میانه گفتگو، پیشوند را می‌شکند. این اتفاق باعث می‌شود کل زمینهٔ ذخیره‌شده دوباره با قیمت کامل محاسبه شود. در Pi 0.87، تنها ارائه‌دهندگان خاصی از افزودن ابزارها پشتیبانی می‌کنند؛ در غیر این صورت، لیست بازنویسی می‌شود.

با نگه داشتن یک مجموعه ابزار کوچک و ادغام‌شده از ابتدا تا انتها، کاربران حافظه پایداری دارند و از جریمهٔ «خطای حافظه» (Cache-miss) جلوگیری می‌کنند. رویکرد مشابهی در pi-docs-slim (فورکی از نسخه اصلی Rob Zolkos) استفاده شده که بخش مستندات پیش‌فرض Pi را حذف کرده و تنها از طریق دستور /pi آن را بازمی‌گرداند بدون اینکه لیست ابزارها تغییر کند.

پیاده‌سازی برای توسعه‌دهندگان

برای ساخت نسخه لین، نویسنده پیشنهاد می‌کند افزونه بالادستی را در یک Proxy قرار دهید. این کار اجازه می‌دهد فراخوانی registerTool را رهگیری کرده و توصیفات اصلی را با نسخه‌های تراشیده جایگزین کنید، در حالی که منطق اجرای اصلی دست‌نخورده باقی می‌ماند. هیچ کدی از بالادست کپی نمی‌شود و node_modules تغییر نمی‌کند.

گردش‌کار توسعه لین:

• ممیزی: لیست تمام ابزارها، توصیفات و تعداد کاراکترهای طرحواره را استخراج کنید.
• تراشیدن: تکرارها، یادداشت‌های UI و لحن تهاجمی را حذف کنید. هر چیز را فقط یک بار بگویید.
• ادغام: ابزارهای کم‌کاربرد را در یک ابزار با پارامتر op ترکیب کنید. برای پارامترهای نادر از رشته JSON استفاده کنید.
• کد-محور کردن: محدودیت‌ها را به طرحواره منتقل کنید یا پارامترهای گم‌شده را از طریق استنتاج در کد مدیریت کنید. فقط زمانی حدس بزنید که احتمال خطا صفر باشد.
• اعتبارسنجی: از پیام‌های خطا به عنوان پرامپت‌های «به‌موقع» استفاده کنید. به‌جای یک قانون دائمی درباره طول برچسب، در پاسخ خطا بگویید: «برچسب بیش از ۶۰ کاراکتر است، آن را کوتاه کنید».

برای کسانی که از مدل‌های ضعیف‌تر یا محلی استفاده می‌کنند، راهنما اشاره می‌کند که مقداری راهنمایی هنوز لازم است. در مورد billion-context-pi (ساخته ranxianglei)، یک بسته پرامپت لین در نسخه رسمی ادغام شد، اما نویسنده قوانین howToCompress را برای جلوگیری از توهمات فشرده‌سازی حفظ کرد.

پیکربندی کامل لین

محیط کامل نویسنده، my-lean-pi-setup را مدیریت می‌کند:

• توصیفات ابزار: ۵ افزونه لین.
• ویرایش کد: pi-hashline-edit-pro-lean. این ابزار از ویرایش مبتنی بر لنگر (Anchor) استفاده می‌کند (لنگرهای ۴ حرفی برای هر خط) تا مدل مجبور نباشد کدهای قدیمی را قبل از کدهای جدید خروجی دهد. اگرچه توکن‌های ورودی کمی افزایش می‌یابد، اما توکن‌های خروجی — که گران‌تر هستند — به‌شدت کاهش می‌یابند. این ابزار شامل اعتبارسنجی لنگر است تا از ویرایش نقطه اشتباه در صورت تغییر فایل جلوگیری کند. نسخه لین این ابزار را از ۲٬۰۴۰ به ۵۳۷ توکن رساند و فقط هشدارهای حیاتی را حفظ کرد: لنگرها را از خروجی read کپی کنید (به جای ساختن آن‌ها) و برای replacement_lines از یک رشته در هر خط استفاده کنید (با [] برای حذف).
• پرامپت پایه: pi-docs-slim برای حذف مستندات پیش‌فرض.
• خروجی دستورات: RTK و pi-rtk-optimizer برای فیلتر کردن خروجی‌های طولانی ترمینال.
• زمینه فعلی: Headroom / noheadroom برای فشرده‌سازی خروجی زنده ابزارها.
• تاریخچه گفتگو: نسخه رسمی لین billion-context-pi برای خلاصه‌سازی تاریخچه قدیمی.
• مانیتورینگ: pi-context-view برای ردیابی مصرف توکن در هر بخش.

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

گام بعدی شما

• ممیزی توکن‌ها: لیست تمام ابزارهای فعال در عامل خود را استخراج کرده و توصیفاتی که در طرحواره (Schema) تکرار شده‌اند را حذف کنید.
• تغییر لحن: کلمات تأکیدی و تهاجمی (مثل MUST یا CRITICAL) را با جملات خبری ساده جایگزین کنید تا از استفادهٔ بیش از حد مدل از ابزارها جلوگیری شود.
• ادغام ابزارها: ابزارهایی که ورودی‌های مشابهی دارند را در یک ابزار با پارامتر op ادغام کنید تا سربار تعریف ابزار کاهش یابد.

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