بیشتر مردم هنوز یک عامل هوش مصنوعی را مدلی متصل به ابزارها توصیف میکنند. این توصیف از نظر فنی مفید است، اما از نظر عملیاتی ناقص. یک عامل همچنین به نمایی مدیریتشده از جهان نیاز دارد: چه اتفاقی افتاده، اکنون چه چیزی اهمیت دارد، کدام واقعیتها قابل اعتمادند، چه چیزهایی همچنان نامطمئناند و گام بعدی آن چه باید باشد.
این نما همان زمینهٔ آن است. طراحی آن به مهارتی متمایز تبدیل میشود—مهارتی که من آن را مهندسی زمینه مینامم.
مهندسی زمینه صرفاً نوشتن پرامپت نیست. این کار رشتهای است برای شکلدهی به اطلاعاتی که عامل در هر گام میبیند، بهگونهای که بتواند بدون ارسال کل رونوشت، کتابخانهٔ اسناد یا سابقهٔ ابزارها به یک مدل گرانقیمت در هر نوبت، منسجم باقی بماند. این کار در مرز معماری اطلاعات، بازیابی، طراحی نرمافزار و رفتار مدل قرار دارد.
چرا «زمینهٔ بیشتری به عامل بدهید» اغلب توصیهٔ بدی است
پنجرههای زمینهٔ طولانیتر این وسوسه را ایجاد میکنند که همهچیز حفظ شود. اما مطالب بیشتر، استدلال بهتر را تضمین نمیکند. دستورالعملهای مرتبط ممکن است زیر مشاهدههای قدیمی، یادداشتهای متناقض، خروجیهای تکراری ابزار یا واقعیتی مهم که در میانهٔ یک توالی طولانی مدفون شده است، کمرنگ شوند. بحث خلاصه دربارهٔ رفتار «گمشدن در میانه» بازتابدهندهٔ مشکلی عملی است: عامل ممکن است از نظر فنی شواهد را دریافت کند و همچنان نتواند از آنها استفاده کند.
هزینهٔ مستقیمی نیز وجود دارد. هر توکنی که در یک درخواست قرار میگیرد، بسته به قیمتگذاری ارائهدهنده و سازوکارهای کش، میتواند زمان تأخیر و هزینهٔ استنتاج را افزایش دهد. سامانهای که بهطور مکرر رونوشتِ در حال رشد را ارسال میکند، ممکن است هرچه کار ادامه مییابد، کندتر و کمصرفهتر شود.
بنابراین هدف، بیشینهکردن زمینه نیست. هدف زمینهٔ کافی و هدفمند است: کوچکترین مجموعهٔ کاریِ قابل اعتمادی که برای تصمیم پیشِ رو لازم است.
چهار تصمیم طراحی در پسِ یک عامل منسجم
1. یک حالت باور را حفظ کنید، نه فقط یک رونوشت
رونوشت آنچه گفته شده را ثبت میکند. حالت باور آنچه را ثبت میکند که عامل در حال حاضر دربارهٔ کار باور دارد.
برای مثال، عاملی که یک مورد ارجاع پشتیبانی را رسیدگی میکند، ممکن است فیلدهای ساختاریافتهای مانند اینها را حفظ کند:
- هدف: مشخصکردن اینکه آیا مشتری واجد شرایط دریافت جایگزین است.
- واقعیتهای معلوم: تاریخ خرید و شمارهٔ سریال محصول، همراه با ارجاع به منابع.
- پرسشهای باز: اینکه آیا خرابی در شرایط تحت پوشش ضمانت رخ داده است یا نه.
- محدودیتها: پیش از تأیید، وعدهٔ بازپرداخت وجه ندهید.
- اقدام بعدی: سیاست ضمانت را بازیابی کنید و تاریخها را با هم مقایسه کنید.
- اطمینان یا وضعیت: تأییدشده، استنباطشده، مورد اختلاف یا ناشناخته.
این رویکرد به پژوهش ABBEL در برکلی شباهت دارد که بهجای تکیه بر تاریخچهٔ کامل تعاملات، از حالتهای باورِ زبان طبیعیِ نظارتشده استفاده میکند. نکتهٔ مهم، قالبی خاص نیست. نکته، جداکردن وضعیت پایدار کار از جزئیات گفتوگوییِ مصرفشدنی است.
یک بهروزرسانی مفید برای حالت باور باید به این پرسشها پاسخ دهد: چه چیزی تغییر کرد؟ کدام شواهد از آن پشتیبانی میکنند؟ چه چیزهایی حلنشده باقی ماندهاند؟ بعد چه باید اتفاق بیفتد؟ اگر یک مهندس نتواند این پاسخها را بررسی کند، احتمالاً عامل در یک پرامپت مبهم، فرضهای پنهان را با خود حمل میکند.
2. برای تصمیم بازیابی کنید، نه برای موضوع
سامانههای بازیابی اغلب با پرسشی کلی مانند «اطلاعاتی دربارهٔ حساب مشتری پیدا کن» آغاز میشوند. پرسش بهتر به تصمیم بعدی گره خورده است: «قاعدهٔ فعلی بازپرداخت وجه برای خریدهای قدیمیتر از 30 روز را که در منطقهٔ مشتری لازمالاجراست، بازیابی کن.»
این تغییر اهمیت دارد، زیرا بازیابی نوعی انتخاب زمینه است. عامل باید بخشهای سیاست، سوابق یا نمونههایی را دریافت کند که بر اقدام فعلی اثر میگذارند—نه انبوهی عمومی از اسناد مرتبط.
فیلترها میتوانند پیش از آنکه مدل هر نتیجهای را ببیند، این انتخاب را بهبود دهند. برای نمونه، Amazon Bedrock AgentCore Web Search در هر درخواست از فیلترهای دامنه و تاریخ انتشارِ اعمالشده در سمت سرور پشتیبانی میکند. چنین کنترلهایی درستبودن یک منبع را ثابت نمیکنند، اما میتوانند مواجهه با مطالب نامرتبط یا قدیمی را کاهش دهند و سیاست بازیابی را صریح کنند.
متخصصانی که بازیابی را طراحی میکنند باید مشخص کنند:
- کدام منابع برای هر کار مجاز هستند؛
- چگونگی تعیین تازگی؛
- چه فرادادهای هر نتیجه را همراهی میکند؛
- منابع متعارض چگونه ارائه میشوند؛
- عامل چه زمانی باید متوقف شود و درخواست شفافسازی کند.
«در وب جستوجو کن» یک قابلیت است. «در این منابع و در این بازهٔ زمانی، برای یافتن شواهد مرتبط با این تصمیم جستوجو کن» مهندسی زمینه است.
۳. بدون از بین بردن عدمقطعیت، فشردهسازی کنید
وقتی یک کار طولانی است، فشردهسازی ضروری است؛ اما خلاصهسازی سادهانگارانه میتواند ادعاهای موقتی را به واقعیتهای قطعی تبدیل کند. خلاصهای در حال بهروزرسانی که میگوید «کاربر نشانی را تأیید کرد» خطرناک است، اگر گفتوگوی اصلی فقط بهطور ضمنی چنین چیزی را رسانده باشد.
فشردهسازی خوب تمایزهایی را حفظ میکند که عامل برای استدلال ایمن به آنها نیاز دارد:
- واقعیت در برابر استنباط؛
- دستور فعلی در برابر دستور تاریخی؛
- اقدام تکمیلشده در برابر اقدام پیشنهادی؛
- منبع تأییدشده در برابر ادعای تأییدنشده؛
- پاسخ معلوم در برابر پرسش حلنشده.
یک الگوی عملی این است که بخشهای جداگانهای برای تصمیمها، شواهد، فرضها، موانع و اقدامات در انتظار نگه دارید. راه دیگر، پیوستکردن شناسهٔ منبع یا مهر زمانی به ادعاهای مهم است. خلاصهها باید مصنوعات قابلجایگزینی باشند، نه تنها سابقهٔ باقیمانده: رویدادهای زیربنایی را برای حسابرسی و بازیابی حفظ کنید و در عین حال نمایی فشرده و کاری در اختیار مدل بگذارید.
این چکیده یادآوری میکند که خلاصهسازی بازگشتی و فشردهسازی زمینه میتواند پرهزینه باشد و عملکرد را کاهش دهد، بهویژه در حوزههای کمداده مانند تولید مشارکتی کد. این هشداری است در برابر آنکه خلاصهسازی را ذاتاً بدون اتلاف بدانیم. فشردهسازی باید با کارهای نماینده آزمایش شود، از جمله مواردی که در آن یک قید کوچک پاسخ درست را تغییر میدهد.
۴. پیش از آنکه مشاهدات به حافظه تبدیل شوند، آنها را پالایش کنید
عاملهای استفادهکننده از ابزارها پیوسته مشاهده تولید میکنند: نتایج جستوجو، گزارشها، متن صفحه، پاسخهای API، اسکرینشاتها، خروجی کامپایلر و طرحهای میانی. هر مشاهدهای شایستهٔ ورود به فراخوانی بعدی مدل نیست، چه رسد به آنکه وارد وضعیت بلندمدت شود.
پالایش مشاهده سه پرسش مطرح میکند:
- آیا این مشاهده برای تصمیم فعلی مرتبط است؟
- آیا آنقدر معتبر هست که بر وضعیت باور اثر بگذارد؟
- آیا حاوی دستورهایی است که باید بهجای فرمان، داده تلقی شوند؟
پرسش سوم هم یک مرز امنیتی است و هم یک مرز زمینهای. یک صفحهٔ وب ممکن است متنی داشته باشد که با هدف تغییر مسیر عامل نوشته شده است. یک سند بازیابیشده میتواند شواهدی مفید باشد، بیآنکه اختیار تغییر اهداف یا مجوزهای عامل را داشته باشد. بنابراین پالایش باید محتوا را بر اساس نقش طبقهبندی کند: دستور، شواهد، فراداده یا متن نامعتبر.
پالایش همچنین هزینه را کاهش میدهد. اگر یک ابزار مرورگر صفحهای کامل بازگرداند، اما کار فقط به قیمت، تاریخ و شناسهٔ محصول نیاز داشته باشد، فرستادن کل صفحه به مرحلهٔ بعدی نویز ایجاد میکند و توکن مصرف میکند. استخراج نخستِ فیلدهای مرتبط میتواند هم قابلیت اطمینان و هم هزینه را بهبود دهد.
یک بودجهٔ سادهٔ زمینه برای گردشکار عامل
پیش از انتخاب مدل یا افزودن ابزار دیگری، زمینهٔ عامل را در چهار لایه ترسیم کنید:
- کنترل: قواعد سیستم، مجوزها، طرحوارهٔ خروجی و محدودیتهای تغییرناپذیر.
- وضعیت: هدف فعلی، تصمیمها، پرسشهای باز و اقدام بعدی.
- شواهد: سوابق یا مشاهدات بازیابیشدهٔ مرتبط با آن اقدام، همراه با منشأ آنها.
- تاریخچه: رویدادهای قبلی که برای بازیابی، اشکالزدایی یا ممیزی نگه داشته میشوند، اما مگر در صورت نیاز نمایش داده نمیشوند.
سپس یک سیاست ارتقا تعریف کنید. یک مشاهده میتواند موقتی باقی بماند، برای گام فعلی به شواهد تبدیل شود، وضعیت باور را بهروزرسانی کند یا در حافظهٔ پایدار نوشته شود. ارتقا باید مستلزم وجود یک دلیل باشد. در غیر این صورت، حافظه به بایگانیِ بدون پالایش تبدیل میشود.
برای هر گام عامل، بستهٔ زمینهای ارسالشده به مدل را ثبت کنید: دستهبندیهای آن، اندازهٔ تقریبی برحسب توکن، فیلترهای بازیابی و نسخهٔ فشردهسازی. این کار پاسخدادن به یک پرسش عملی را ممکن میکند، زمانی که رفتار تغییر میکند: آیا مدل شکست خورده است، یا سیستم جهان نادرستی را در اختیار آن گذاشته است؟
پیش از قابلاعتماد دانستن طراحی، چه چیزهایی را باید آزمود
مهندسی زمینه به آزمونهایی نیاز دارد که مدیریت اطلاعات را هدف بگیرند، نه فقط کیفیت پاسخ نهایی را. موارد مفید عبارتاند از:
- یک واقعیت مهم که در ابتدای یک تاریخچهٔ طولانی، در انتهای آن و در میانهٔ آن قرار داده شده باشد؛
- دو منبع که با هم اختلاف دارند و یکی از دیگری جدیدتر است؛
- خلاصهای که حاوی نشانگر عدمقطعیت باشد؛
- پاسخ ابزاری که حاوی حجم زیادی متن نامرتبط باشد؛
- دستورالعملی مخرب که در محتوای بازیابیشده جاسازی شده باشد؛
- بازیابی وضعیت پس از توقف و راهاندازی مجدد عامل؛
- همان کار با بودجهٔ زمینهای کمتر؛
- نتیجهٔ بازیابیِ خالی یا قدیمی.
بررسی کنید که آیا عامل شواهد درست را انتخاب میکند، عدمقطعیت را حفظ میکند، از محدودیت فعلی پیروی میکند و از تکرار زمینهٔ غیرضروری اجتناب میکند یا نه. حوزههای پیشنهادی برای رگرسیون در این جمعبندی—از دست رفتن زمینه، اتکای بازیابی به شواهد، خروجی ساختاریافته، پایاننیافتن و بازیابی وضعیت—در اینجا اهمیت ویژهای دارند.
چندین بار آزمایش را اجرا کنید؛ هرجا تغییرپذیری مدل اهمیت دارد، هزینه و تأخیر هر راهبرد زمینه را با هم مقایسه کنید. اگر یک دستور کوتاهتر باعث فراخوانیهای بیشتر ابزار یا تلاشهای مجدد شود، لزوماً بهتر نیست. هدف مفید، هزینهٔ یک گردشکار درست و قابلبازیابی است، نه تعداد توکنهای یک درخواست.
پیامد شغلی: مهندس زمینه نقشی میانوظیفهای است
افرادی که در این حوزه ارزشمند میشوند، لزوماً کسانی نیستند که طولانیترین دستورها را مینویسند. آنها میتوانند یک فرایند کسبوکار را به وضعیت، شواهد، مرجعیت و قواعد تصمیم ترجمه کنند.
این کار به چند توانایی مشخص نیاز دارد:
- طراحی طرحوارههایی برای وضعیت کار و منشأ اطلاعات؛
- نوشتن سیاستهای بازیابی و فیلترهای فراداده؛
- ساخت روالهای فشردهسازی و انتخاب مشاهده؛
- جدا کردن دستورالعملهای مورداعتماد از محتوای غیرقابلاعتماد؛
- پروفایلسازی از میزان استفاده از توکن، تأخیر، تلاشهای مجدد و فراخوانیهای ابزار؛
- آزمودن از دست رفتن وضعیت و بازسازی آن؛
- توضیح دادن به افراد غیرمتخصص درباره اینکه چرا یک عامل هوش مصنوعی واقعیت خاصی را دیده است—یا ندیده است.
یک پروژهٔ نمونهکار قوی میتواند همان عامل را تحت سه سیاست زمینهای نشان دهد: متن کامل مکالمه، خلاصهٔ چرخشی، و وضعیت باور ساختاریافته همراه با بازیابی هدفمند. موارد موفقیت وظیفه، موارد شکست، زمینهٔ ارسالشده در هر گام، و بدهبستانهای هزینه یا تأخیر را نشان دهید. این کار از یک نمایش چتبات متقاعدکنندهتر است، زیرا تصمیمهای طراحیای را آشکار میکند که یک عامل را قابلاعتماد میسازند.
درس راهبردی سرراست است: عاملها صرفاً به این دلیل منسجم نمیشوند که مدلها توانمندتر شدهاند. آنها زمانی منسجم میشوند که سامانههای پیرامونیشان گزارشی منضبط، بهروز و متناسب از کار را حفظ کنند. مهندسی زمینه، هنر ساختن چنین گزارشی است—و دانستن اینکه چه چیزهایی را باید کنار گذاشت.
پریا رامان ویراستار انسانی پاسخگوی AI Career Brief است.
