مهندسی زمینه (context) جای مهندسی پرامپت را به‌عنوان مهارت مهم هوش مصنوعی می‌گیرد
مهندسی پرامپت هیچ‌وقت واقعاً درباره پیدا کردن کلمات جادویی نبود. موضوع این بود که به مدل اطلاعات کافی و مرتبط، در قالبی قابل‌استفاده، بدهیم تا پاسخ خوبی تولید کند. وقتی کار فقط یک پرسش‌وپاسخ ساده بود، این تفاوت کمتر اهمیت داشت. اما حالا که بیشتر سیستم‌های هوش مصنوعی در تولید واقعی، Agent هستند — حلقه‌هایی که ابزار صدا می‌زنند، نتیجه می‌خوانند، سند بازیابی می‌کنند و وضعیت را در ده‌ها مرحله حفظ می‌کنند — این تفاوت فوق‌العاده مهم شده است.
مهارتی که مشخص می‌کند این سیستم‌ها کار می‌کنند یا نه، دیگر نحوه چیدمان کلمات در پرامپت نیست. این مهندسی زمینه (context engineering) است — یعنی تعیین اینکه در هر مرحله چه چیزی وارد context window مدل شود، چگونه ساختاردهی شود و چه زمانی باید حذف شود. تیم‌هایی که این را فرعی در نظر می‌گیرند، Agentهایی می‌سازند که هزینه بالا، سرعت پایین و خطاهایی دارند که دیباگ‌کردنشان سخت است.
چرا مهندسی پرامپت دیگر کافی نیست
یک پرامپت خوب‌نوشته‌شده فرض می‌کند که مدل از قبل همه چیز لازم برای پاسخ را دارد. اما گردش‌کارهای Agent این‌طور کار نمی‌کنند. یک Agent که یک اختلال عملیاتی را بررسی می‌کند، ممکن است بخش‌هایی از لاگ، یک راهنمای عملیاتی، سه رشته گفتگوی Slack مرتبط و خروجی دو فراخوانی ابزار را جمع کند — همه این‌ها قبل از اینکه حتی یک کلمه از پاسخ واقعی خود را بنویسد. هیچ‌کدام از این‌ها «پرامپت» به معنای سال ۲۰۲۳ نیست. این یک بودجه زمینه‌ای است و هر توکن در آن یک تصمیم است.
context windowهای بزرگ‌تر، قبل از اینکه اوضاع را بهتر کنند، آن را بدتر کردند. وقتی مدل‌های دوران GPT-4 حداکثر حدود ۳۲ هزار توکن داشتند، تیم‌ها به‌ناچار باید انتخابگر می‌بودند. context windowهای میلیون‌توکنی این محدودیت را برداشتند، و پاسخ ساده‌لوحانه — ریختن همه چیز مرتبط و گذاشتن اینکه مدل خودش مرتب کند — در عمل باعث افت عملکرد شد. پژوهش‌ها روی بازیابی با context طولانی به‌طور مداوم نشان می‌دهند که مدل‌ها در یک زمینه بزرگ، توجه نامتوازنی دارند و معمولاً اطلاعات نزدیک به ابتدا یا انتهای زمینه را ترجیح می‌دهند و دقتشان روی واقعیت‌های دفن‌شده در وسط کاهش می‌یابد. توکن بیشتر، سیگنال بیشتر نیست. اغلب نویز بیشتر همراه با صورت‌حساب API بالاتر است.
چهار وظیفه مهندسی زمینه
در عمل، مهندسی زمینه به چهار مسئله مجزا تقسیم می‌شود و بیشتر خرابی‌های Agent به اشتباه در یکی از این‌ها برمی‌گردد.
انتخاب بازیابی
تعیین اینکه اصلاً چه چیزی وارد زمینه شود. این دقیقاً کاری است که پایپ‌لاین‌های RAG برای آن ساخته شدند، اما کیفیت انتخاب مهم‌تر از recall بازیابی است. برگرداندن ۲۰ قطعه با بیشترین شباهت معنایی، با برگرداندن ۵ قطعه‌ای که واقعاً به سؤال پاسخ می‌دهند یکسان نیست. تیم‌هایی که برای recall به‌جای دقت تنظیم می‌کنند، دوباره در همان تله «همه چیز را بریز» گیر می‌افتند، فقط این‌بار یک مدل embedding به‌جای انسان این کار را انجام می‌دهد.
فشرده‌سازی
خروجی‌های خام ابزار، فایل‌های لاگ و بخش‌های سند به‌ندرت در قالبی هستند که ارزش ارسال کامل داشته باشند. یک stack trace ۴۰۰ خطی معمولاً به سه خط مرتبط و یک خلاصه فشرده می‌شود، بدون اینکه چیزی که مدل به آن نیاز دارد از دست برود. بیشتر صرفه‌جویی در هزینه توکن در سیستم‌های Agent تولیدی از همین‌جا می‌آید، و همین‌جا هم خلاصه‌سازی ساده‌لوحانه می‌تواند بی‌صدا همان جزئیاتی را که اهمیت داشت حذف کند.
ساختار و ترتیب
جایی که اطلاعات در زمینه قرار می‌گیرد، روی این تأثیر می‌گذارد که آیا مدل آن را درست استفاده می‌کند یا نه. قرار دادن محدودیت‌ها و دستورالعمل‌ها بلافاصله قبل از مرحله تولید، به‌جای دفن‌کردن آن‌ها در بالای یک system prompt طولانی، پیروی از دستورالعمل را در تنظیمات context طولانی به‌طور قابل‌اندازه‌گیری بهبود می‌دهد. ترتیب تزئینی نیست — بار اصلی را روی دوش می‌کشد.
بازنویسی حافظه
Agentهایی که بیش از یک نوبت اجرا می‌شوند، به یک سیاست نیاز دارند که چه چیزی در حافظه پایدار نوشته شود و چه چیزی فقط در زمینه فعلی زودگذر باقی بماند. اگر همه چیز نوشته شود، حافظه به یک محل تخلیه دوم با همان مسئله نویز تبدیل می‌شود. اگر هیچ‌چیز نوشته نشود، Agent در هر نشست دوباره همان واقعیت‌ها را از نو استخراج می‌کند و توکن و تأخیر را صرف کشف دوباره می‌کند.
کجا تیم‌ها اشتباه می‌کنند
رایج‌ترین خطا این است که با زمینه مثل چیزی رایگان رفتار شود. این‌طور نیست. هر سند اضافه در پنجره، تأخیر و هزینه اضافه می‌کند و — بعد از یک تراکم معین — کاهش قابل‌اندازه‌گیری در کیفیت پاسخ ایجاد می‌کند که گاهی به آن context rot گفته می‌شود. دومین خطای رایج، چیدمان ثابت زمینه است: ساختن یک پایپ‌لاین واحد برای ساخت زمینه و استفاده از آن برای هر پرسش، بدون توجه به اینکه آن کار به سه سند نیاز دارد یا سی سند. سومین خطا، نادیده‌گرفتن کامل سیاست حذف است، به‌طوری‌که یک نشست Agent طولانی‌مدت خروجی ابزارها را انباشته می‌کند تا جایی که بیشتر context window فقط داربست مراحلی است که Agent دیگر به آن‌ها نیاز ندارد.
این در یک سیستم کارآمد چه شکلی دارد
تیم‌هایی که این را درست انجام می‌دهند معمولاً یک بودجه زمینه‌ای مشخص برای هر مرحله دارند: یک سقف توکن برای اسناد بازیابی‌شده، یک سقف جدا برای خروجی‌های ابزار، و یک سهم محفوظ برای دستورالعمل‌ها و نوبت‌های اخیر گفتگو که هیچ‌وقت جابه‌جا نمی‌شود. آن‌ها ثبت می‌کنند که وقتی یک Agent پاسخ بدی تولید کرده، چه چیزی در زمینه بوده، همان‌طور که یک stack trace را ثبت می‌کنند، زیرا ترکیب زمینه حالا یک سطح اصلی برای دیباگ‌کردن است، نه یک جزئیات پیاده‌سازی.
نتیجه‌گیری عملی
- بهینه‌سازی عبارت پرامپت به‌تنهایی را متوقف کنید. حسابرسی کنید که واقعاً چه چیزی در هر مرحله اجرای Agent وارد context window می‌شود و اندازه بگیرید که مدل چه مقدار از آن را واقعاً استفاده می‌کند.
- دقت بازیابی را مهم‌تر از recall بازیابی بدانید. برگرداندن نتایج کمتر و مرتبط‌تر بهتر از برگرداندن نتایج بیشتر و امید به فیلترکردن آن‌ها توسط مدل است.
- قبل از اینکه بررسی هزینه مصرف توکن را علامت‌گذاری کند، یک مرحله فشرده‌سازی برای خروجی ابزار و لاگ‌ها بسازید.
- دستورالعمل کار و محدودیت‌ها را نزدیک نقطه تولید قرار دهید، نه دفن‌شده در بالای یک system prompt طولانی، به‌خصوص وقتی زمینه از چند هزار توکن بیشتر شود.
- یک سیاست مشخص بازنویسی حافظه تعریف کنید، به‌جای پیش‌فرض‌گرفتن انباشت همه‌چیز یا حذف همه‌چیز بین نوبت‌ها.