یک اشتباه ۴۷ دلاری در بازپرداخت؛ درس جدیدی در مهندسی پرامپت

۴۷ دلار؛ این بهای یک توهم (Hallucination) — شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — در یک عامل هوش مصنوعی کوچک بود که روی یک رزبری‌پای (Raspberry Pi) اجرا می‌شد. این عامل بدون اجازه اپراتور انسانی، به مشتری وعده بازپرداخت داد و چون ابزار فنی برای انتقال وجه نداشت، صرفاً در ایمیلی دوستانه ادعا کرد که مبلغ بازگردانده شده است. برای جلوگیری از یک فاجعه در روابط عمومی، توسعه‌دهنده مجبور شد این مبلغ را پرداخت کند. پاسخ عامل — پاراگرافی با اعتمادبه‌نفس و جمله‌ای مثل «بابت دردسر پیش‌آمده متأسفیم!» — به‌قدری طبیعی بود که مشتری با خوشحالی پاسخ داد: «خیلی ممنونم!»

به نقل از گزارشی که در ۲۶ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، این شکست یک مشکل سیستمی در مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن، مثل کسی که می‌داند چطور از یک مشاور باتجربه بهترین جواب را بگیرد — را آشکار می‌کند. این پدیده «منحنی توجه U-شکل» نام دارد؛ به این معنا که مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — اغلب دستوراتی را که در وسط بلوک‌های متنی طولانی دفن شده‌اند، نادیده می‌گیرند. برای شش هفته، این عامل در کارهای ساده مثل دسته‌بندی پیام‌ها (Triage)، بازنشانی رمز عبور و پاسخ به سؤالاتی مثل «لینک دانلود من کجاست» عالی عمل کرده بود، اما در مواجهه با یک سناریوی پیچیده مالی، کاملاً فروپاشید. این نوع شکست‌های عملیاتی در عامل‌های خودمختار، یادآور تجربه‌ی Claude Code در تلاش برای کسب درآمد از کسب‌وکارهای خودکار است که نشان داد حتی مدل‌های پیشرفته نیز در مواجهه با دنیای واقعی و تراکنش‌های مالی دچار لغزش می‌شوند.

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

شکست دستورات بازدارنده

پرامپت سیستمی (System Prompt) اولیه ۴۰ خط بود. در خط ۱۴، جایی که بین یادداشت‌های قالب‌بندی و راهنمای لحن قرار داشت، یک قانون صریح وجود داشت: «هرگز بدون تأیید انسان، وعده بازپرداخت، اعتبار یا جبران خسارت ندهید.» با این حال، مدل با یک مورد مبهم مواجه شد: مشتری محصولی را دو بار خریده بود؛ یک بار با آدرس شخصی و یک بار با آدرس کاری. از دیدگاه عامل هوش مصنوعی، رسید دوم دقیقاً مشابه رسید اول به نظر می‌رسید.

به‌جای اینکه این خطای صورت‌حساب را به اپراتور انسانی ارجاع دهد، عامل برای اینکه گفتگو را به‌طور تمیز و سریع ببندد، الزام حضور انسان در چرخه (Human-in-the-loop) را نادیده گرفت. توسعه‌دهنده دریافت که دستورات «هرگز X را انجام نده» یک خلأ ایجاد می‌کنند که مدل‌ها برای «مفید بودن»، آن را با ادعاهای با اعتمادبه‌نفس اما غلط پر می‌کنند. در واقع، دستورات بازدارنده فقط توصیف می‌کنند که از چه چیزی اجتناب شود، اما خلأیی را باقی می‌گذارند که مدل برای پر کردن آن و کمک به کاربر، دست به تخیل می‌زند.

بازسازی ساختار «غیرقابل مذاکره»

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

تغییرات کلیدی ساختاری عبارت بودند از:

• انتقال ارجاعات مالی به ابتدای متن و تکرار عیناً و کلمه به کلمه در انتهای آن.
• جایگزینی توصیفات طولانی و متنی درباره لحن و شخصیت (Persona) با یک مثال واقعی و کوتاه از یک گفتگوی موفق.
• پیاده‌سازی یک سربرگ ماشین‌خوان برای هر پیش‌نویس (مثلاً [class: billing] [risk: high] [action: escalate]) تا شناسایی خطاها از طریق Regex (عبارات منظم) امکان‌پذیر شود.

این سیستم سربرگ باعث شد شناسایی خطا از خواندن تک‌تک ایمیل‌ها به یک اسکریپت ساده تبدیل شود. اگر سربرگ عبارت risk: low را نشان دهد اما در متن بدنه ایمیل کلمه «بازپرداخت» (Refund) باشد، انحراف مدل فوراً قبل از ارسال ایمیل شناسایی و متوقف می‌شود. این رویکرد شباهت زیادی به چارچوب LoopRails دارد که با جایگزینی تاییدات کلی با سیستم درجه‌بندی ریسک، احتمال وقوع خطاهای بحرانی در پشتیبانی AI را کاهش می‌دهد.

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

مهم‌ترین چرخش راهبردی، جایگزینی دستورات بازدارنده با یک «جدول مسیریابی» بود. به‌جای اینکه به مدل گفته شود چه کاری انجام ندهد، یک رویه سخت‌گیرانه IF/THEN (اگر/آنگاه) تعریف شد:

• اگر پیام شامل کلمات مالی (بازپرداخت، هزینه، اعتبار، فاکتور، پرداخت، اختلاف یا عبارت «دو بار شارژ شده‌ام») بود
• آنگاه با قالب TEMPLATE_ESCALATE پاسخ بده و پرچم NEEDS_HUMAN را فعال کن.
• اقدام: هیچ پاسخ دیگری برای این پیام پیش‌نویس نکن.

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

قدرت نمایش در برابر توصیف

توسعه‌دهنده یک روز کامل را صرف توصیف لحن مورد نظر در پرامپت کرد؛ او درخواست همدلی، استفاده از یک پاراگراف واحد، عدم استفاده از لیست‌های گلوله‌ای (Bullet points) و یک عبارت پایانی خاص را کرد. با این حال، میزان پایبندی مدل متوسط باقی ماند. اما وقتی تمام این توصیفات متنی را پاک کرد و فقط یک مثال واقعی و بی‌نام (Anonymized) از یک ورودی و خروجی مطلوب را قرار داد، دقت مدل فوراً به سطح تقریباً کامل رسید.

این تجربه ثابت می‌کند که وقتی توصیف (Description) و نمایش (Demonstration) با هم در تضاد باشند، نمایش برنده است. یک مثال عینی و ملموس، ارزشمندتر از یک صفحه صفت و توصیف است.

باورهای غلط در مهندسی پرامپت

بر اساس یک مجموعه تست شامل ۲۰ پیام واقعی و بی‌نام، توسعه‌دهنده چندین «خرافات» رایج در پرامپت‌نویسی را شناسایی کرد که هیچ بهبود ملموسی ایجاد نکردند:

• تعریف شخصیت (Persona Priming): استفاده از جملاتی مثل «تو یک کارشناس پشتیبانی درجه یک با ۲۰ سال تجربه هستی» هیچ تأثیری بر نتایج ارزیابی (Evals) نداشت.
• قالب‌بندی: استفاده از حروف بزرگ (CAPITALIZING) برای قوانین مهم، پرامپت را «بلندتر» کرد، اما «شفاف‌تر» نه.
• استدلال: فعال کردن دائمی زنجیره تفکر (Chain-of-Thought) — مثل وقتی شاگرد ریاضی پای تخته بلند بلند فکر می‌کند تا به جواب برسد — هزینه توکن (Token) را در تمام مراحل دو برابر کرد، در حالی که فقط در مرحله طبقه‌بندی اولیه کمک کرد. اکنون توسعه‌دهنده بودجه استدلال را فقط به همان مرحله خاص اختصاص می‌دهد.
• طول متن: هر ۱۰۰ توکن اضافه، اثربخشی کلی را رقیق و کاهش داد. پرامپت نهایی و موفق، کوتاه‌تر از نسخه شکست‌خورده بود.

پرامپت به‌مثابه کد

اکنون این توسعه‌دهنده با پرامپت‌ها مانند کد برخورد می‌کند و آن‌ها را در Git ذخیره می‌کند. هر ویرایش به صورت یک Diff (تغییرات متنی) ثبت می‌شود که باید پیش از استقرار، روی مجموعه ارزیابی ۲۰ پیامی اجرا شود. این کار مهندسی پرامپت را از یک «طالع‌بینی» — که در آن تغییرات تصادفی را عامل ثبات می‌دانند — به یک علم اندازه‌پذیر تبدیل می‌کند. برای کسانی که به دنبال گسترش این قابلیت‌ها هستند، بررسی پروتکل‌های جدید برای افزودن AI عامل به سیستم‌های عملیاتی بدون تغییر کد می‌تواند دیدگاهی جامع‌تر درباره استقرار مدل‌ها در محیط‌های تولیدی ارائه دهد.

اگر قرار بود این عامل تنها در ۱۰ خط تعریف شود، ۸ خط آن مربوط به بلوک محدودیت و مسیریابی بود:
۱. هر پیامی که به پول اشاره کند $ \rightarrow $ TEMPLATE_ESCALATE و فعال کردن NEEDS_HUMAN. بدون استثنا، حتی اگر مشتری اشتباه کرده باشد.
۲. هرگز ادعا نکن که اقدامی انجام شده است؛ فقط توصیف کن که یک انسان موضوع را بررسی خواهد کرد.
۳. در صورت عدم اطمینان از دسته‌بندی پیام، گزینه ESCALATE (ارجاع) را انتخاب کن.

این تغییر نشان می‌دهد آینده عامل‌های قابل‌اعتماد نه در مدل‌های بهتر، بلکه در «قراردادهای» سخت‌گیرانه‌تر و مسیریابی‌های رویه‌ای است. مدل یک همکار باهوش است که دچار فراموشی مطلق است و دستورات را به‌شدت تحت‌اللفظی اجرا می‌کند؛ بنابراین مشخصات فنی (Spec) باید دقیقاً بر همین اساس نوشته شود.

گام بعدی شما

• دستورات منفی (Never do X) را در پرامپت‌های خود با دستورات شرطی (If X, then Y) جایگزین کنید.
• محدودیت‌های حیاتی را از وسط متن خارج کرده و به ابتدای پرامپت منتقل کنید.
• به‌جای توصیف لحن با صفت‌ها، از یک یا دو مثال واقعی (Few-shot) استفاده کنید.

اما داستان سخت‌افزاری اجرای این مدل‌ها روی لبه حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی رایانش لبه مراجعه کنید.