مهندسی زمینه: کار قبل از اعلان

کلمه لحظه، در دنیای کوچک عوامل هوش مصنوعی، مهندسی زمینه است.

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

درد این است: مدل ها فقط به این دلیل که «فکر نمی کنند» شکست نمی خورند. آنها اغلب شکست می خورند زیرا ما آنها را با اتاق اشتباهی برای کار می فرستیم.

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

اعلان عبارتی است که به آن می گویید. زمینه دنیایی است که شما در اطراف آن آماده می کنید.

از مهندسی سریع تا مهندسی زمینه

مهندسی سریع اغلب به عنوان نوشتن در نظر گرفته می شد. کلمات مناسب را انتخاب کنید، به روش درست بپرسید، مثال اضافه کنید، قالب را مشخص کنید.

مهندسی زمینه به معماری نزدیکتر است.

شما فقط نمی‌پرسید "چگونه درخواست را تنظیم کنم؟" می پرسد:

• واقعاً چه اطلاعاتی لازم است؟
• نویز چیست؟
• چه چیزی باید در پرواز بازیابی شود؟
• چه چیزی را باید به خاطر بسپارید؟
• چه ابزارهایی باید در معرض دید قرار گیرند؟
• کدام دستورالعمل ها پایدار هستند و کدام به کار بستگی دارد؟
• چگونه به نماینده بفهمانم که چه چیزی معتبر است؟

این یک تغییر ظریف اما بزرگ است. زیرا وقتی با عامل ها کار می کنید، زمینه یک بلوک ثابت نیست. در هر مرحله تغییر می کند.

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

این مهندسی است.

بافت محل دفن زباله نیست

قالب‌هایی با پنجره‌های زمینه بزرگ به ما وسوسه می‌کردند: بیایید همه چیز را به داخل بیندازیم.

قابل درک است. اگر یک میلیون توکن دارم، چرا باید انتخاب کنم؟

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

زمینه خوب یک سلسله مراتب دارد:

1. دستورالعمل ها و سیاست های سیستم.
2. هدف خاص;
3. وضعیت فعلی.
4. داده های مربوطه.
5. محدودیت ها;
6. ابزار موجود.
7. تصمیماتی که قبلا گرفته شده را پیگیری کنید.

نیازی به درمان همه چیز در یک سطح نیست. یک دستور کاربر بیشتر از یک یادداشت قدیمی ارزش دارد. یک آزمون ناموفق اکنون ارزشی بیش از یک اولویت زیبایی شناختی از سه ماه پیش دارد. یک سیاست امنیتی بیشتر از یک میانبر تولید ارزش دارد.

مهندسی زمینه همچنین به معنای دادن وزن است، نه فقط داده.

حافظه: کمتر به خاطر بسپارید، بهتر به خاطر بسپارید

حافظه در عوامل یکی از لغزنده ترین موضوعات است.

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

یک حافظه مفید باید حداقل سه ویژگی داشته باشد:

• منشأ: این اطلاعات از کجا آمده است؟
• date: کی درست بود؟
• هدف: برای چه نوع کاری باید از آن استفاده کرد؟

بدون این سه چیز، حافظه تبدیل به خرافه می شود.

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

یک سیستم خوب باید این نگهداری را عادی کند. قهرمانانه نیست

بازیابی و ابزار یکسان نیستند

وقتی در مورد زمینه صحبت می کنیم، اغلب بلافاصله در RAG قرار می گیریم. جاسازی، پایگاه داده برداری، تکه تکه کردن، رتبه بندی مجدد.

همه مفید. اما بازیابی تنها یک راه برای آوردن اطلاعات به مدل است. او تنها نیست.

یک عامل می تواند با خواندن فایل ها، پرس و جو از یک API، فراخوانی یک سرور MCP، باز کردن یک مرورگر، اجرای آزمایش ها، جستجوی Slack، نگاه کردن به داشبورد، پرسش از انسان، زمینه را دریافت کند.

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

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

متن یک پایگاه داده نیست. این یک گردش کار است.

نماینده خوب هم می داند چگونه نادیده بگیرد

نشانه بلوغ در کارگزاران، توانایی گفتن: من به این اطلاعات نیازی ندارم.

پیش پا افتاده به نظر می رسد، اما بسیار دشوار است. بسیاری از سیستم های عاملی انباشته می شوند. هر تماس ابزار متنی را اضافه می کند. هر خطایی در بافر باقی می ماند. هر فایل خوانده شده به پشته اضافه می شود. در نهایت این مدل دارای تاریخچه بسیار طولانی و بدون نقشه است.

فشرده سازی مورد نیاز است. سنتز متوسط ​​مورد نیاز است. نیاز به ساختار دارد.

نه "این همه اتفاق افتاد"، بلکه:

• هدف هنوز معتبر است.
• فرضیه فعلی؛
• فایل ها قبلا بررسی شده اند.
• تصمیمات اتخاذ شده؛
• خطرات باز؛
• اقدام بعدی

این باعث می شود که نماینده کمتر نمایشی و مفیدتر باشد. نه به این دلیل که او باهوش تر به نظر می رسد، بلکه به این دلیل که با یک میز مرتب کار می کند.

مهندسی زمینه برای تیم ها، نه برای هنرمندان سریع

دلیل اینکه این موضوع برای من جالب است این است که مسئولیت را از فرد به سیستم منتقل می کند.

در مهندسی سریع، کسی که می تواند به بهترین شکل با مدل صحبت کند اغلب برنده می شود. در مهندسی زمینه، تیمی که به بهترین شکل کار خود را سازماندهی می کند برنده می شود: اسناد، قراردادها، مسائل، گزارش ها، آزمایش ها، مالکیت، نامگذاری، منابع.

یک مخزن تمیز به زمینه بهتری تبدیل می شود. یک موضوع خوب نوشته شده سوخت بهتری می شود. یک Runbook به روز شده، نشانه ها و اضطراب را ذخیره می کند. تغییرات واضح توهمات را کاهش می دهد.

این خبر خوب و تا حدودی ناراحت کننده است. زیبا است زیرا به اعمال خوب پاداش می دهد. ناخوشایند است زیرا نمی توانید همه چیز را با یک دستور هوشمندانه حل کنید.

عوامل بهداشت سیستمی را که پیدا می کنند تقویت می کنند.

چگونه فردا آن را اعمال کنم

اگر بخواهم مهندسی زمینه را در یک پروژه واقعی معرفی کنم، از چیزهای کوچک شروع می کنم:

• یک فایل دستورالعمل پروژه کوتاه و نگهداری شده؛
• نمونه های خوبی از خروجی مورد انتظار.
• فهرستی از ابزارهای موجود و مواردی که در آنها می توان از آنها استفاده کرد.
• تصمیمات معماری به شیوه ای قابل استناد نوشته شده است.
• موضوع با حداقل زمینه اجباری؛
• آسان برای بازیابی سیاهههای مربوط و آزمایش.
• حافظه پایدار قابل تغییر توسط انسان.

سپس من یک چیز ساده را اندازه می‌گیرم: نماینده چند بار باید توضیح بخواهد یا در جهت اشتباه برود؟

اگر اغلب اتفاق می افتد، من فوراً یک مدل بزرگتر اضافه نمی کنم. من به زمینه نگاه خواهم کرد.

خواندن من

مهندسی زمینه کمی کلمه پف کرده است، بله. اما مفهوم درست است.

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

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

جادوی کمتر اتاق تمیزتر نمایندگان به اندازه ما به آن نیاز دارند.

منابع

• [وبلاگ LangChain: ظهور مهندسی زمینه] (https://blog.langchain.com/the-rise-of-context-engineering/)
• Simon Willison: Context Engineering
• Model Context Protocol: Introduction
• [Anthropic: Building موثر عوامل] (https://www.anthropic.com/engineering/building-effective-agents)
• OpenAI: ابزارهای جدید برای عوامل ساخت