مهندسی زمینه هوش مصنوعی: معماری، امنیت و ارزیابی

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

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

راهنمای ۲۰۲۵ Anthropic درباره مهندسی مؤثر زمینه، زمینه را منبعی محدود می‌داند که توکن‌هایش باید بر اساس فایده انتخاب شوند. پژوهش هشدار روشن‌تری دارد: مطالعه گم‌شدن در میانه نشان داد عملکرد مدل‌های دارای زمینه بلند، وقتی اطلاعات مهم در میانه ورودی قرار می‌گیرد می‌تواند افت کند. پنجره بزرگ فقط ظرفیت است؛ تضمین نمی‌کند همه توکن‌ها به‌یکسان استفاده شوند.

این راهنما مهندسی زمینه را به معماری عملی تبدیل می‌کند: مانیفست نوع‌دار، خط لوله مونتاژ آگاه از اعتماد، بودجه توکن و تأخیر، مرز امنیت و ارزیابی‌هایی که خرابی زمینه را از خرابی مدل جدا می‌کنند.

از یک مانیفست نوع‌دار شروع کنید

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

پوش رکورد می‌تواند چنین فیلدهایی داشته باشد:

id, type, content, source, owner, trust_level, authority,
created_at, effective_at, expires_at, sensitivity,
allowed_uses, transformation_history, token_estimate

لازم نیست مدل همه فیلدها را کلمه‌به‌کلمه ببیند؛ سازنده زمینه به آن‌ها نیاز دارد. با این فراداده می‌توان ورودی را فیلتر، مرتب، توضیح، بی‌اعتبار و حسابرسی کرد و پرامپت نهایی را جعبه سیاه ندانست.

اختیار با اعتماد یکسان نیست

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

این ابعاد را جدا مدل کنید:

• اصالت منبع: می‌دانیم مورد از کجا آمده است؟
• یکپارچگی: پس از بازیابی تغییر نکرده است؟
• مرجعیت factual: این سامانه مالک حقیقت مورد نظر است؟
• اختیار دستوری: اجازه دارد رفتار را تعیین یا تغییر دهد؟
• مجوز عامل: هویت درخواست‌کننده حق استفاده دارد؟
• تازگی: برای زمان مورد نظر معتبر است؟
• اطمینان: استخراج یا استنباط چقدر قابل اتکاست؟

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

این جداسازی دفاع اصلی در برابر «زمینه تخت» است؛ حالتی که همه متن‌های طبیعی ظاهراً یک اندازه قدرت دستور دادن دارند.

زمینه را با خط لوله قطعی بسازید

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

۱. درخواست را نرمال کنید

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

۲. سیاست مرتبط را بارگذاری کنید

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

۳. وضعیت دامنه‌دار را برگردانید

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

۴. شواهد را بازیابی کنید

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

برای این لایه کیفیت دانش در RAG و برای اتصال ادعا به منبع اتوماسیون شواهد‌محور را ببینید.

۵. حافظه را انتخاب کنید

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

۶. ابزارها را ثبت کنید

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

۷. بودجه توکن اختصاص دهید

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

۸. رندر و اعتبارسنجی کنید

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

پیش از فشرده‌سازی، انتخاب کنید

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

1. حذف: محتوای نامرتبط، غیرمجاز، منقضی، تکراری یا کم‌اعتبار را کنار بگذارید.
2. استخراج: بند دقیق و فیلد ساختاری لازم برای کار را نگه دارید.
3. فشرده‌سازی: مواد بلند باقی‌مانده را خلاصه کنید، اما شناسه، اختلاف، عدد و قید را حفظ کنید.
4. جای‌گذاری: اطلاعات پراهمیت را جایی قرار دهید که استفاده شود و با داده نامطمئن اشتباه نشود.

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

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

زمینه بودجه توکن، تأخیر و پول دارد

هر جزء اضافه حداقل چهار هزینه دارد:

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

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

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

کش‌کردن پرامپت می‌تواند هزینه prefill بخش‌های ثابت را کم کند، اما خود یک تصمیم ذخیره‌سازی است. قواعد نگهداری ارائه‌دهندگان متفاوت‌اند. مثلاً مستند فعلی کنترل داده API در OpenAI می‌گوید کش توسعه‌یافته پیامد ذخیره‌سازی دارد و با گزینه Zero Data Retention آن سازگار نیست. این جزئیات مخصوص ارائه‌دهنده‌اند و پیش از استقرار باید دوباره بررسی شوند.

ابزار و MCP مرز زمینه را گسترش می‌دهند

یکپارچه‌سازی ابزار، هم قابلیت و هم منبع جدید زمینه می‌آورد. معماری رسمی Model Context Protocol سه جزء را جدا می‌کند:

• ابزار: تابعی را اجرا می‌کند.
• منبع: داده زمینه‌ای می‌دهد.
• پرامپت: الگوی قابل استفاده مجدد ارائه می‌کند.

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

نسخه نامزد انتشار ۲۸ ژوئیه ۲۰۲۶ MCP شامل هسته بدون حالت، extension، task، app و تقویت مجوز شد. تغییر سریع پروتکل یعنی pin کردن نسخه و مذاکره قابلیت نیز بخشی از مهندسی زمینه است. هویت سرور، نسخه پروتکل، قابلیت اعلامی، نسخه طرح‌واره ابزار، دامنه مجوز و منشأ پاسخ را در هر اجرا ثبت کنید.

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

تزریق پرامپت یک مشکل معماری زمینه است

راهنمای OWASP درباره تزریق پرامپت می‌گوید تزریق غیرمستقیم می‌تواند از وب‌سایت و فایل بیرونی برسد و RAG یا fine-tuning به‌تنهایی آن را حل نمی‌کند. کنترل‌های اصلی معماری‌اند:

• محتوای بیرونی را داده نامطمئن برچسب بزنید و جدا کنید.
• متن بازیابی‌شده نتواند مجوز بدهد یا ابزار اضافه کند.
• اختیار و قواعد کسب‌وکار را بیرون مدل اجرا کنید.
• هر کار فقط حداقل مجموعه ابزار لازم را بگیرد.
• اقدام پیشنهادی را با نیت اصلی کاربر بسنجید، نه آخرین متن بازیابی‌شده.
• برای اقدام پراثر یا برگشت‌ناپذیر تأیید صریح بگیرید.
• راز و اعتبارنامه را بیرون زمینه قابل مشاهده مدل نگه دارید.
• پیش از استفاده خروجی مدل در کد، SQL، نشانی یا فرمان، آن را اعتبارسنجی کنید.
• جزء زمینه مؤثر بر هر اقدام ابزار را ثبت کنید.
• دستور پنهان در HTML، PDF، تصویر، فراداده، پاسخ ابزار و خلاصه حافظه را آزمون خصمانه کنید.

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

جزئیات بیشتر در امنیت عامل مرورگر و طراحی مجوز ابزار آمده است.

سازنده زمینه را جدا از مدل ارزیابی کنید

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

ماتریس آزمون:

معیارها:

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

«پرامپت خوب»ی که فقط با یک ترتیب سند کار می‌کند، مهندسی زمینه آماده تولید نیست.

برنامه پیاده‌سازی مرجع

1. طرح‌واره جزء نوع‌دار و فهرست منابع مرجع را تعریف کنید.
2. اولویت سیاست، نیت کاربر، وضعیت، شاهد و حافظه را بنویسید.
3. فیلتر مجوز و تازگی را پیش از رتبه‌بندی بازیابی اجرا کنید.
4. حسابداری توکن را برای هر جزء و هر دسته اضافه کنید.
5. رندرری بسازید که مرزهای ساختاری پایدار و آزمون‌پذیر ایجاد کند.
6. مانیفست نهایی را پیش از هر فراخوانی مدل اعتبارسنجی کنید.
7. در trace شناسه اجزا را نگه دارید، نه فقط متن رندرشده را.
8. fixture طلایی را از کار واقعی، تعارض، رخداد و سند خصمانه بسازید.
9. با خط مبنای بدون بازیابی، بدون حافظه و زمینه کم‌شده مقایسه کنید.
10. drift تولید را بر اساس مدل، نسخه سازنده، منبع، زبان و ریسک پایش کنید.

پرسش‌های رایج

آیا مهندسی زمینه همان RAG است؟

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

آیا کل گفت‌وگو همیشه باید ارسال شود؟

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

آیا مدل بزرگ‌تر نیاز به طراحی زمینه را کم می‌کند؟

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

دستور غیرقابل مذاکره کجا قرار گیرد؟

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

منابع و تاریخ بازبینی

این مقاله در ۸ مرداد ۱۴۰۵ (۳۰ ژوئیه ۲۰۲۶) با منابع زیر به‌طور اساسی بازبینی شد:

• Lost in the Middle
• Anthropic: مهندسی مؤثر زمینه برای عامل‌های هوش مصنوعی
• معماری Model Context Protocol
• نامزد انتشار MCP نسخه ۲۰۲۶-۰۷-۲۸
• OWASP LLM01:2025 تزریق پرامپت
• برگه پیشگیری از تزریق پرامپت OWASP
• کنترل داده API در OpenAI

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