تصور کنید سامانهی هوش مصنوعی شما به اشتباه یک دستور حذف کل پایگاهداده را اجرا کند، فقط چون یک دستور متنی را نادیده گرفته است. یا سناریویی را در نظر بگیرید که در آن سیستم شما هرگز نباید یک دستور SQL تخریبی را اجرا کند یا باید همیشه یک توالی سختگیرانه را دنبال کند؛ در چنین شرایطی، تکیه بر یک دستورالعمل خوشساخت، یک ریسک سیستمی است؛ زیرا پرامپت در واقع یک درخواست است، نه یک قانون الزامآور.
این تمایز، یکی از ستونهای اصلی اهداف آزمون CCAR-F است؛ جایی که بسیاری از داوطلبان به دلیل اشتباه گرفتن مهندسی پرامپت (Prompt Engineering) — که شبیه هنر سؤال درست پرسیدن از یک مشاور باتجربه است — با ارکستراسیون سیستمی، شکست میخورند. در محیطهای عملیاتی، هزینهٔ شکست تعیین میکند که آیا شما به «صحت» مدل نیاز دارید یا به «تضمین» سیستم.
برای درک بهتر، یک طبقهبندیکننده را در نظر بگیرید که باید فقط دستههایی از یک فهرست ثابت را برگرداند. شما میتوانید به مدل بگویید «فقط از این پنج کلمه استفاده کن»، اما این تنها یک درخواست برای صحت است. اگر کدهای بعدی برنامه برای اجرا به دقیقاً همان کلمات وابسته باشند، حتی یک ویرگول توهمآمیز میتواند باعث کرش کردن کل سیستم شود. در اینجا است که خطا از فضای گفتگو خارج شده و مستقیماً به کد عملیاتی ضربه میزند. این چالشها نشان میدهد چرا برای تبدیل مدلهای احتمالی به ابزارهای صنعتی، باید قوانین مهندسی سختگیرانهای را برای افزایش قابلیت اعتماد عاملها پیادهسازی کرد.
چارچوب تضمین در برابر صحت
به نقل از راهنمای فنی منتشر شده در dev.to در ۱۰ سپتامبر ۲۰۲۶، انتخاب بین پرامپت و زیرساخت به این بستگی دارد که پیامد شکست کجا رخ میدهد:
- الزامات صحت: اینها مسائل مربوط به پرامپت هستند. اگر هدف این است که خروجی سازگار، با فرمت مناسب یا باکیفیت باشد، از نمونههای Few-shot و دستورات شفاف استفاده میکنید. هزینه شکست در اینجا صرفاً یک «خروجی بد» است. در این سطح، تلاش برای حذف توهمات از طریق استراتژیهای مسدود کردن ادعاهای بیپشتوانه میتواند کیفیت خروجی را بهبود بخشد اما تضمین اجرایی ایجاد نکند.
- الزامات تضمین: اینها مسائل زیرساختی هستند. اگر تخطی از قانون منجر به شکست تجاری یا امنیتی شود — مانند حذف غیرقابلبازگشت دادهها از دیتابیس — باید از مکانیزمهای قطعی (Deterministic) استفاده کنید.
زمینه: جایگاه این مفاهیم در ارزیابیها
بسیاری از داوطلبان به اشتباه این مسائل را زیرمجموعه مهندسی پرامپت و خروجیهای ساختاریافته قرار میدهند. در حالی که بحثهای مربوط به طرحواره (Schema) و واژگان اعتبارسنجی در آن بخشها تدریس میشوند، اما آزمون این سؤالات را به شکل متفاوتی توزیع میکند.
در بانک سؤالات منبع، مواردی که پاسخ صحیح آنها در سطح کد است و گزینههای مربوط به پرامپت نقش «پاسخ گمراهکننده» دارند، به شدت در دستهی معماری عاملمحور (Agentic Architecture) و ارکستراسیون متمرکز شدهاند. در این دستهبندی، ۱۲ مورد مربوط به کنترل کد است در حالی که تنها ۵ مورد به مهندسی پرامپت بازمیگردد.
در مقابل، برای مواردی که پاسخ سطح پرامپت درست است و گزینه سطح کد غلط است، دو-سوم آنها در بخش مهندسی پرامپت قرار دارند. بنابراین، تکیه صرف به قاعده کلی «همیشه در کد اجرا کن» منجر به خطا در این بخشهای خاص خواهد شد.
جزئیات: عبارات شرطی راهنما
بر اساس مستندات این راهنما، تأکید بر این نیست که اجرای کد به طور کلی بهتر است، بلکه از زبان شرطی بر اساس نوع نیاز استفاده میکند:
- پایبندی قطعی: از Hookها و Gateها زمانی استفاده میشود که «پایبندی قطعی مورد نیاز باشد» یا «قوانین کسبوکار، تضمین اجرا را بخواهند».
- خروجی ساختاریافته: این روش به عنوان قابلاعتمادترین رویکرد برای «تضمین خروجی مطابق با طرحواره (Schema)» توصیف شده است.
- راهکارهای سطح پرامپت: راهنما صراحتاً برای نیازهای دیگر، پاسخهای سطح پرامپت را نام میبرد. قوانین نرمالسازی در کنار طرحواره در پرامپت قرار میگیرند و نمونههای Few-shot مؤثرترین تکنیک برای سازگاری فرمت ذکر شدهاند.
- انتخاب ابزار: توصیفات ابزار به عنوان مکانیزم اصلی برای انتخاب ابزار معرفی شدهاند، نه یک لایه مسیریابی (Routing Layer) جداگانه.
مکانیزمهای اجرایی
وقتی پایبندی قطعی لازم است، راهنما الگوهای معماری خاصی را معرفی میکند که احتمالاتی بودن مدل را دور میزنند:
- Hookها و Gateها: اینها مانند چکهای پیشنیاز عمل میکنند و از شروع یک مرحله جلوگیری میکنند تا زمانی که شرط خاصی برقرار شود.
- محدود کردن دامنه: محدود کردن ابزارهای در دسترس یک زیر-عامل تا بهصورت فیزیکی نتواند به توابع حساس دسترسی داشته باشد.
- مراحل اعتبارسنجی: بررسیهای سختافزاری که هر خروجی را که با یک طرحواره سختگیرانه مطابقت ندارد، قبل از رسیدن به بقیه سیستم رد میکنند.
تلههای رایج معماری
این راهنما نسبت به سه الگوی «گمراهکننده» هشدار میدهد که حتی توسعهدهندگان باسابقه را هم فریب میدهد:
۱. پرامپتهای تأکیدی: استفاده از کلماتی مثل «همیشه» (ALWAYS) یا «هرگز» (NEVER) در پرامپت سیستمی. این کار احتمال نتیجه را تغییر میدهد اما آن را به قطعیت تبدیل نمیکند. این رایجترین تله با اختلاف زیاد است.
۲. مکانیزمهای جابهجا: اجرای یک مکانیزم درست در جای اشتباه. مثالها عبارتند از:
* یک Hook روی رویدادی که بعد از وقوع خسارت فعال میشود.
* پس گرفتن ابزاری از یک زیر-عامل که در واقع به آن نیاز ندارد.
* یک انتخاب ابزار اجباری که نمیتواند فراخوانی دوم را توالی کند.
۳. ادعاهای رفتاری نادرست: توصیف درست یک مکانیزم اما ادعای رفتاری که در واقعیت ندارد؛ مثلاً Hookهایی که ادعای تلاش مجدد (Retry) دارند، Hookهایی که در مکان اشتباه پیکربندی شدهاند، یا یک طرحواره سختگیرانه که ادعا میکند فیلدهای گمشده را از سند منبع پر میکند.
افسانه دمای صفر (Temperature Zero)
بسیاری از متخصصان باسابقه توسط گزینههایی فریب میخورند که پیشنهاد میکنند تنظیم دما (Temperature) روی صفر یا تغییر مدل، جایگزینی برای تضمین است. هیچکدام از اینها احتمال را به قطعیت تبدیل نمیکنند. در حالی که دمای صفر پاسخ صحیح برای برخی سؤالات سازگاری است، اما جایگزینی ناکارآمد برای یک تضمین قطعی است.
تحلیل نقطه شکست
این تغییر دیدگاه، تمرکز توسعهدهنده را از «متن» (Stem) الزام به «پیامد» شکست منتقل میکند. اگر فقط به دنبال کلمات کلیدی مثل «باید» یا «همیشه» بگردید، احتمالاً شکست میخورید. در بانک سؤالات، کلمات تضمینی در حداکثر نیمی از مواردی که پاسخ کد صحیح است، ظاهر میشوند.
علاوه بر این، برخی موارد که پاسخ سطح پرامپت در آنها درست است، در واقع کلمه «همیشه» را داخل یک خط نقلشده از پرامپت سیستمی دارند. این یک تله است: کلمه در سناریو آمده چون بخشی از دستورالعملی است که مورد بررسی قرار گرفته است.
به جای آن باید بپرسید: «آیا این شکست داخل پنجره چت میماند یا بیرون از آن در محیط عملیاتی اثر میگذارد؟»
- داخل گفتگو: هزینه خروجی بد، صرفاً این است که خروجی بد است. شما به صحت نیاز دارید.
- خارج از گفتگو: اگر کدهای بعدی بر اساس دستهبندی تصمیم میگیرند، یک حذف در دیتابیس عملیاتی رخ میدهد، یا یک مرحله چیزی غیرقابلبازگشت را ثبت میکند، شما به تضمین نیاز دارید.
برای کسانی که گردشکارهای عاملمحور میسازند، این یعنی با مدل زبانی بزرگ (LLM) به عنوان یک موتور احتمالی و با لایه ارکستراسیون به عنوان نردههای ایمنی قطعی برخورد کنید. اگر شکست در محدوده گفتگو باشد، صحت کافی است. اگر شکست با محیط عملیاتی در تماس باشد، تنها تضمین کفایت میکند.
برای اعمال این دیدگاه هنگام مرور، سؤالات قبلاً پاسخدادهشده را بردارید و قبل از نگاه کردن به گزینهها، بنویسید که نقطه شکست کجاست. اگر در یک سؤال «صحت»، به سراغ زیرساخت بروید، یعنی بیش از حد اصلاح کردهاید. اگر در یک سؤال «تضمین»، به سراغ تغییر کلمات بروید، یعنی هنوز درونی نکردهاید که یک دستورالعمل صرفاً یک درخواست است.
گام بعدی شما
- در پروژههای خود، هر جایی که کلمه «همیشه» یا «هرگز» را در پرامپت نوشتهاید، بررسی کنید که آیا پیامد شکست آن در محیط عملیاتی است یا خیر.
- برای خروجیهایی که به کد متصل هستند، به جای تأکید در پرامپت، از لایههای اعتبارسنجی (Validation) سختگیرانه استفاده کنید.
- تفاوت بین «درخواست صحت» و «تضمین سیستم» را در مستندات معماری عاملهای خود شفاف کنید.
اما داستان سختافزاری این کنترلها حتی پیچیدهتر است — به تحلیل ما دربارهی بهینهسازی استنتاج در لایههای ارکستراسیون مراجعه کنید.
گفتگو