Context engineering

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

تعریف رسمی‌شان این تفاوت را دقیق می‌گوید: prompt engineering یعنی نوشتن و سازمان‌دادنِ دستورها. اما context engineering یعنی انتخاب و نگه‌داشتنِ بهترین مجموعه‌ی اطلاعاتی که در طول کار جلوی مدل است — شاملِ هر چیزی که بیرون از خودِ prompt هم آنجا می‌نشیند.

و تفاوت کلیدی: prompt engineering درباره‌ی یک درخواست است؛ context engineering درباره‌ی کلِ وضعیتِ اطلاعاتی که در طول چند دور تغییر می‌کند.

یعنی این فصل ادامه‌ی مستقیم فصل ۱.۳ است: آنجا فهمیدی context چیست و چرا خراب می‌شود؛ اینجا یاد می‌گیری چطور مدیریتش کنی.

قاعده‌ی مرکزی این فصل، مستقیم از منبع رسمی:

کوچک‌ترین مجموعه‌ی ممکن از اطلاعاتِ پرسیگنال ← که احتمال رسیدن به نتیجه‌ی دلخواه را بیشترین کند

دو کلمه‌ی کلیدی: کوچک‌ترین و پرسیگنال. نه بیشترین، و نه هر چیزی که مرتبط به نظر می‌رسد.

دلیلش را در فصل ۱.۳ دیدی: مدل «بودجه‌ی توجه» محدودی دارد و با بزرگ‌شدن context کیفیتش افت می‌کند. پس هر تکه‌ی بی‌ربطی که اضافه می‌کنی، فقط جا نمی‌گیرد — توجه را از تکه‌های مهم می‌دزدد.

سه سؤال برای هر چیزی که می‌خواهی بدهی:

• اگر این را ندهم، جواب بدتر می‌شود؟ اگر مطمئن نیستی، نده. همیشه می‌شود بعداً اضافه کرد.
• آیا خودش می‌تواند پیدایش کند؟ ایجنت می‌تواند فایل‌ها را بخواند. لازم نیست محتوای فایل را در متن بچسبانی.
• آیا این داده حساس است؟ سؤالی که در ماژول ۵ جدی می‌شود، ولی از همین حالا باید بپرسی‌اش.

وقتی فایلی می‌دهی، در واقع داری کل محتوایش را وارد context می‌کنی — و تا آخر آن session آنجا می‌ماند.

سه راهبرد، به ترتیب اولویت:

• بگذار خودش بخواند، نه اینکه بچسبانی. اگر ایجنت به پوشه دسترسی دارد، بگو «فایل X را بخوان». آن‌وقت فقط چیزی که لازم است وارد می‌شود، نه کل متن در پیام تو.
• تکه بده، نه کل. اگر فقط سه ستون از یک فایل صدستونی را لازم داری، همان سه ستون را بده.
• نمونه بده، نه همه. برای فهمیدنِ ساختار یک فایل بزرگ، بیست ردیف اولش کافی است. کل فایل را وقتی بده که واقعاً باید رویش حساب کند.

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

در فصل ۱.۴ فایل قانون را دیدی: فایلی که در شروع هر session خودکار خوانده می‌شود. حالا از زاویه‌ی context نگاهش کن.

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

معیار ساده: اگر چیزی را در ۹ کار از ۱۰ کار لازم داری، در فایل قانون. اگر در ۲ کار از ۱۰، همان دو بار دستی بگو.

و این توضیح می‌دهد چرا توصیه‌ی رسمی کوتاه‌نگه‌داشتن آن است (فصل ۱.۴): فایل قانونِ بلند، هم جا می‌گیرد و هم — چون طولانی است — کمتر رعایت می‌شود.

اینجا سه فصل به هم می‌رسند. در ۲.۵ کار را شکستی تا بتوانی بازبینی کنی. حالا یک دلیل دوم: هر مرحله‌ی جدا، context تازه‌ای دارد.

مقایسه کن:

• یک‌جا: فایل خام + مراحل میانی + نتیجه‌ها، همه با هم در یک context که تا آخر کار بزرگ‌تر و شلوغ‌تر می‌شود.
• مرحله‌ای: مرحله‌ی ۱ فایل خام را می‌خواند و یک خروجی تمیز می‌دهد. مرحله‌ی ۲ فقط همان خروجی تمیز را می‌گیرد — نه فایل خام را.

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

نشانه‌های افت را در فصل ۱.۳ دیدی. اینجا نشانه‌هایی که مخصوصِ بد انتخاب‌کردن context‌اند:

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

و درمانِ هر چهارتا یکی است و برخلاف غریزه است: کمتر بده، نه بیشتر. session تازه، فقط با آن چیزی که واقعاً لازم است.