فشرده‌سازی پرامپت؛ راهکاری ارزان‌تر از تعویض مدل برای کاهش هزینه‌های عامل‌ها

اگر امروز برای اجرای عامل‌های هوش مصنوعی هزینه پرداخت می‌کنید، احتمالاً بخش بزرگی از بودجه شما صرف داده‌هایی می‌شود که مدل اصلاً به آن‌ها نیاز ندارد. بسیاری از توسعه‌دهندگان برای کاهش هزینه‌ها به سراغ مدل‌های ارزان‌تر می‌روند، اما نشت واقعی سرمایه در «تورم بستر متنی» (Context Bloat) نهفته است. فشرده‌سازی پرامپت، تاثیرگذارترین اهرمی است که برای کاهش هزینه‌های عامل‌های هوش مصنوعی نادیده گرفته شده است و اغلب صرفه‌جویی‌های عمیق‌تری نسبت به تغییر مدل از یک نسخه پرمیوم به یک نسخه ارزان‌تر ایجاد می‌کند. در حالی که توسعه‌دهندگان به شدت روی قیمت‌گذاری مدل‌ها تمرکز می‌کنند، نشت مالی واقعی معمولاً در بستر متنی حجیمی پنهان شده است که با هر درخواست ارسال می‌شود. این رویکرد بهینه‌سازی، در واقع تکمله‌ای بر استراتژی‌های اندازه‌گیری‌محور برای کاهش هزینه‌های استنتاج است که پیش‌تر بررسی کردیم.

بیشتر گردش‌کارهای عامل‌محور (Agentic) امروزه بر پایه چارچوب‌هایی مثل n8n، Make، LangChain یا ورکر‌های سفارشی بنا شده‌اند. این سیستم‌ها اغلب حجم عظیمی از داده‌های تکراری را در هر مرحله، هر تلاش مجدد (Retry) و هر شاخه از تصمیم‌گیری جابه‌جا می‌کنند. این وضعیت شبیه به یک اثر بهره مرکب است؛ جایی که یک پرامپت بیش از حد بزرگ، ده‌ها بار تکرار می‌شود و به‌آرامی صورت‌حساب شما را متورم می‌کند. اگر یک پرامپت در ۲۰ مرحله، ۳ تلاش مجدد و ۲ شاخه مختلف تکرار شود، دیگر یک درخواست ساده نیست، بلکه به یک الگوی هزینه‌بر تبدیل می‌شود.

طبق یک راهنمای کاربردی که در ۱۶ سپتامبر ۲۰۲۶ در dev.to منتشر شد، بخش گران‌قیمت یک اتوماسیون به‌ندرت خودِ مدل است. در عوض، این «وزن‌های مرده» هستند — یعنی متن کامل گفتگوها، طرح‌های ابزاری غول‌آسا و محموله‌های تکراری سندها — که ارائه‌دهندگان آن‌ها را به عنوان بخشی از کل بستر رندر شده‌ی درخواست محاسبه و برای آن‌ها هزینه می‌گیرند.

درک درخواست رندر شده (Rendered Request)

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

• پیام‌های سیستمی (System) یا پیام‌های توسعه‌دهنده
• تعاریف ابزارها و طرح‌های JSON (JSON Schemas)
• حافظه و تاریخچه گفتگو
• اسناد بازیابی شده (Retrieved Documents)
• محموله‌های چندوجهی (Multimodal) مانند تصاویر یا سایر داده‌ها
• ورودی نهایی و واقعی کاربر

اگر یک مرحله از عامل فقط به دو ابزار search_tickets و update_crm_record نیاز دارد، اما سیستم ۱۲ طرح ابزار و تاریخچه کامل گفتگو را ارسال می‌کند، شما در حال پرداخت هزینه برای داده‌های بی‌فایده یا همان وزن‌های مرده هستید.

سه منبع اصلی تورم پرامپت

تورم پرامپت معمولاً در سه الگوی مشخص در گردش‌کارهای عامل‌محور ظاهر می‌شود:

۱. تاریخچه‌های کامل گفتگو: اکثر مراحل نیازی به کل تاریخچه گفتگو ندارند. معمولاً آن‌ها فقط به یک خلاصه وضعیت فشرده، آخرین دستور کاربر و شاید ۱ تا ۳ دور آخر گفتگو نیاز دارند. ارسال ۴۰ دور تاریخچه برای یک مرحله ساده‌ی انتخاب ابزار، در واقع به معنای «آتش زدن پول» است. برای مدیریت بهینه این حافظه و جلوگیری از حذف داده‌های کلیدی، می‌توان از سیستم‌های دسته‌بندی داده‌ها برای پیشگیری از فراموشی AI بهره برد.

۲. طرح‌های ابزاری بیش از حد بزرگ: چارچوب‌ها اغلب یک مجموعه ابزار بزرگ را یک بار ثبت می‌کنند و تعریف هر ابزار را با هر درخواست ارسال می‌کنند. برای مثال، ارسال لیستی شامل search_tickets ،update_crm_record ،send_email ،create_invoice ،sync_calendar ،fetch_slack_thread ،query_warehouse ،generate_contract ،log_incident ،create_jira_issue ،archive_conversation و notify_webhook در حالی که فقط به دو مورد از آن‌ها نیاز است، کاملاً ناکارآمد است.

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

واقعیت حافظه پنهان (Prompt Caching)

در حالی که ارائه‌دهندگان برای کاهش این هزینه‌ها قابلیت کشینگ (Caching) را ارائه می‌دهند، این ابزار یک استراتژی اصلی و قابل اعتماد نیست، زیرا کشینگ به «ثبات» پاداش می‌دهد، نه به «هرج‌ومرج».

OpenAI تخفیف‌هایی تا ۹۰٪ برای ورودی‌های کش‌شده ارائه می‌دهد، اما این کار مستلزم تطابق دقیق پیشوند رندر شده (Exact Rendered Prefix Match) است. اگر چیزی را در ابتدای پرامپت تغییر دهید، تعاریف ابزارها را تغییر دهید، ترتیب بستر متنی را عوض کنید یا حافظه را کمی متفاوت تزریق کنید، ممکن است کش را کاملاً از دست بدهید.

Anthropic حافظه پنهانی را فراهم می‌کند که برای حلقه‌های تکرار سریع (Tight Loops) بسیار مؤثر است، اما عمر پیش‌فرض این کش تنها ۵ دقیقه است. این موضوع باعث می‌شود برای اتوماسیون‌هایی که بین مراحل توقف دارند، بعداً تلاش مجدد می‌کنند، به‌صورت نامتقارن شاخه می‌زنند یا با تریگرهای تأخیری بیدار می‌شوند، کارایی کمتری داشته باشد.

Google Gemini به‌صورت پیش‌فرض در مدل‌های جدیدتر از کشینگ ضمنی (Implicit Caching) استفاده می‌کند، اما این درخواست‌ها همچنان باید از آستانه‌های توکنی مشخصی عبور کنند تا مزایای هزینه ظاهر شوند.

مقایسه قابلیت‌های کشینگ ارائه‌دهندگان

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

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

قبل (حجیم):

def build_prompt(state, tools, docs):
    return {
        "system": SYSTEM_PROMPT,
        "history": state.full_chat_history,
        "tools": tools.all_tools,
        "documents": docs.full_results,
        "input": state.current_task,
    }

بعد (فشرده):

def build_prompt(state, tools, docs):
    return {
        "system": SYSTEM_PROMPT,
        "history": state.summary + state.last_turns[-3:],
        "tools": tools.required_for_step,
        "documents": docs.top_k_chunks,
        "input": state.current_task,
    }

برای کاربران n8n، گره Chat Memory Manager دقیقاً برای بازرسی و کاهش حافظه پیش از رسیدن به گره Agent طراحی شده است. الگوی پیشنهادی n8n شامل جدا نگه داشتن حافظه کوتاه‌مدت از داده‌های دائمی اپلیکیشن، خلاصه‌سازی تاریخچه پیش از گره Agent و ذخیره یک خلاصه وضعیت فشرده به جای متن کامل گفتگو است.

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

اندازه‌گیری نشت داده

اگر اندازه محموله (Payload) را اندازه‌گیری نکنید، نمی‌توانید مشکل را حل کنید. یک راه ساده برای ممیزی این است که تعداد تقریبی کاراکترهای محموله JSON را پیش از هر فراخوانی مدل لاگ کنید.

مثال پایتون:

import json
def approx_chars(payload):
    return len(json.dumps(payload))

payload = build_prompt(state, tools, docs)
print(f"prompt_payload_chars={approx_chars(payload)}")

مثال Node.js:

function approxChars(payload) {
    return JSON.stringify(payload).length;
}
const payload = buildPrompt(state, tools, docs);
console.log(`prompt_payload_chars=${approxChars(payload)}`);

اگر یک مرحله از گردش‌کار ۱۰ برابر بیشتر از سایرین داده ارسال می‌کند، آن مرحله هدف اصلی برای پاک‌سازی است. برای کسانی که عامل‌ها را به عنوان سرویس اجرا می‌کنند، لاگ کردن اندازه درخواست و تعداد تلاش‌های مجدد با دستوری مانند grep "prompt_payload_chars\|retry_count\|workflow_step" app.log | tail -n 100 می‌تواند الگوهای هزینه را به‌سرعت آشکار کند.

چک‌لیست ممیزی گردش‌کار

پیش از بحث درباره انتخاب مدل، این سوالات را بپرسید:

• آیا این مرحله واقعاً به تاریخچه کامل گفتگو نیاز دارد؟
• آیا می‌توانم تاریخچه متن را با یک خلاصه متحرک به علاوه چند دور آخر جایگزین کنم؟
• آیا طرح‌های ابزارهای بدون استفاده همچنان ارسال می‌شوند؟
• آیا اسناد بازیابی شده فقط به تکه‌هایی محدود شده‌اند که همین حالا نیاز است؟
• آیا تلاش‌های مجدد، پیشوندهای غول‌آسایی را ارسال می‌کنند که فقط به اندازه کافی تغییر کرده‌اند تا کش را از دست بدهند؟
• آیا این اتوماسیون آنقدر تأخیر دارد که پنجره ۵ دقیقه‌ای کش Anthropic کمکی نکند؟
• آیا این درخواست Gemini به اندازه کافی بزرگ است که واجد شرایط کشینگ ضمنی باشد؟

چه زمانی انتخاب مدل واقعاً اهمیت دارد

مسیریابی مدل (Model Routing) — مانند استفاده از Gemini Flash برای دسته‌بندی، Llama یا Qwen برای شاخه‌های ارزان، یا مدل‌های باز کوچک‌تر برای استخراج داده — همچنان ارزشمند است. با این حال، این کار باید تنها پس از پاک‌سازی پرامپت‌ها انجام شود. تغییر مدل بدون فشرده‌سازی پرامپت‌ها، مانند «جابه‌جایی همان زباله‌ها با یک کامیون ارزان‌تر» توصیف شده است.

برای تیم‌هایی که عامل‌های با حجم بالا را اجرا می‌کنند، سرویس‌های استنتاج با نرخ ثابت (Flat-rate) مانند Standard Compute می‌توانند استرس قیمت‌گذاری توکن‌به-توکن را از بین ببرند. با ارائه یک قیمت ماهانه قابل پیش‌بینی و یک API سازگار با OpenAI که مدل‌هایی مانند GPT-5.4، Claude Opus 4.6 و Grok 4.20 را مسیریابی می‌کند، نیاز به نظارت لحظه‌ای بر هزینه توکن‌ها در هر تلاش مجدد یا گسترش گردش‌کار از بین می‌رود.

اگرچه این موضوع فشرده‌سازی را بی‌اهمیت نمی‌کند — زیرا پرامپت‌های کوچک‌تر همچنان باعث بهبود تأخیر (Latency)، کیفیت و نرخ پردازش می‌شوند — اما انگیزه مالی را تغییر می‌دهد. این تغییر تمرکز نشان می‌دهد که سریع‌ترین راه برای کاهش صورت‌حساب هوش مصنوعی، یافتن یک مدل ارزان‌تر نیست، بلکه آموزش دادن به گردش‌کار است تا «کمتر حرف بزند».

گام بعدی شما

• اندازه محموله JSON را در هر مرحله از گردش‌کار لاگ کنید تا نقاط تورم را شناسایی کنید.
• تاریخچه کامل گفتگو را با یک «خلاصه وضعیت» (State Summary) و ۳ پیام آخر جایگزین کنید.
• لیست ابزارها را فیلتر کنید تا در هر درخواست فقط ابزارهای مرتبط با آن گام ارسال شوند.

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