Context Engineering چیه و چرا از پرامپت‌نویسی بزرگ‌تره؟

چرا اسم کار عوض شد

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

Context Engineering تمام اطلاعاتی رو مدیریت می‌کنه که موقع تولید هر پاسخ جلوی چشم مدله. یعنی سؤال از «چطور بپرسم» تبدیل می‌شه به «در هر لحظه چه چیزی باید داخل پنجره باشه و چه چیزی نباید».

کانتکست از چی ساخته شده

قبل از اینکه بشه مدیریتش کرد، باید دید از چه اجزایی تشکیل شده. توی یه سیستم واقعی، پنجره‌ی کانتکست معمولاً این‌ها رو کنار هم داره:

• دستور سیستمی — نقش، محدودیت‌ها و قواعد ثابت. کم تغییر می‌کنه ولی در هر فراخوانی هزینه داره.
• تعریف ابزارها — اسم، توضیح و اسکیمای هر ابزاری که در دسترسه. ده ابزار یعنی ده تا توضیح در هر نوبت.
• تاریخچه‌ی گفت‌وگو — هر چی تا حالا گفته شده، شامل خروجی ابزارها. این بخش بی‌وقفه رشد می‌کنه.
• داده‌ی بازیابی‌شده — تکه‌های سند، نتیجه‌ی جست‌وجو، محتوای فایل.
• فرمت خروجی — قالبی که انتظار داری، مثل اسکیمای JSON یا ساختار گزارش.

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

دشمن اصلی: پر شدن پنجره

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

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

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

هزینه هم هست. تاریخچه‌ی بزرگ یعنی هر نوبت گران‌تر و کندتر، حتی وقتی هیچ‌کدوم از اون توکن‌ها به کار نمیان.

تکنیک اول: بازیابی به‌موقع به‌جای انبارکردن

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

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

تکنیک دوم: فشرده‌سازی تاریخچه

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

ولی خلاصه‌ی خوب، خلاصه‌ی کوتاه نیست؛ خلاصه‌ی انتخابی‌ست. چیزهایی که باید حتماً بمونن معمولاً این‌هان:

• تصمیم‌هایی که گرفته شده و دلیلشون — چون دوباره گرفتنشون یعنی دوباره بحث‌کردن.
• محدودیت‌هایی که کشف شده — مثل اینکه فلان API این فیلد رو نداره.
• کارهایی که امتحان شد و جواب نداد — وگرنه مدل همون بن‌بست رو دوباره می‌ره.
• وضعیت فعلی: چی تموم شده، چی نصفه‌ست، قدم بعدی چیه.

و چیزهایی که باید بریزن دور: خروجی خام ابزارها، کد کاملی که قبلاً نوشته و ذخیره شده، و هر رفت‌وبرگشتی که به نتیجه نرسید ولی نتیجه‌اش هم مهم نبود.

تکنیک سوم: تقسیم کار بین چند کانتکست

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

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

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

یک بازطراحی مرحله‌به‌مرحله

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

نسخه‌ی اول: همه‌چیز از اول

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

قدم یک: مستندات رو از دستور سیستمی دربیار

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

قدم دو: تاریخچه‌ی خرید رو شرطی کن

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

قدم سه: بعد از هر تیکت، پاک کن

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

هیچ‌کدوم از این سه قدم به مدل بهتر یا پنجره‌ی بزرگ‌تر نیاز نداشت. هر سه فقط تصمیم گرفتن که چه چیزی نباید اونجا باشه.

چطور بفهمی کانتکستت خرابه

وقتی پاسخ بد هست، فوراً پرامپت یا مدل رو مقصر ندون. اول این سه تا رو بررسی کن، به همین ترتیب:

1. آیا اطلاعات لازم اصلاً داخل کانتکست بوده؟ اگه نه، مسئله‌ی بازیابی‌ست، نه مدل.
2. آیا بوده ولی زیر انبوه چیزهای نامرتبط گم شده؟ اگه آره، مسئله‌ی حجمه.
3. آیا بوده و دیده شده ولی دستور مبهم بوده؟ فقط اینجاست که بازنویسی پرامپت جواب می‌ده.

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