پروتکل «کارت شواهد» توهمات عامل‌های پشتیبانی در مورد داده‌های حساب را متوقف

تصور کنید یک پیش‌نویس تهیه شده توسط یک عامل پشتیبانی هوش مصنوعی، لحنی بسیار مهربان و مودبانه دارد، اما برای مشتری، یک سطح اشتراک «Pro» را اختراع کرده است؛ در حالی که مشتری هرگز چنین چیزی را ذکر نکرده بود. درخواست بازگشت وجه دوازده ثانیه در صف انتظار مانده بود. عامل هوش مصنوعی پیش از آن نام پلن را تعیین کرده بود، اما در تمام طول تماس، هیچ‌کس کلمه «Pro» را به زبان نیاورده بود. این همان شکست خاموش عامل‌های هوش مصنوعی است: متنی صیقل‌خورده و حرفه‌ای که حقایقی ساختگی را در خود جای داده است. این نوع خطاها یادآور یک اشتباه ۴۷ دلاری در بازپرداخت است که درس‌های مهمی در مهندسی پرامپت به جای گذاشت. در ۹ سپتامبر ۲۰۲۶، یک پروتکل پژوهشی جدید در dev.to منتشر شد تا این مشکل را با پیاده‌سازی سیستمی به نام «کارت توقف» (Stop Card) حل کند؛ سیستمی که دکمه ارسال را تا زمان تأیید دقیق حقایق مربوط به حساب کاربر توسط انسان، منجمد می‌کند.

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

برای مقابله با این موضوع، این پروتکل یک جداسازی سخت‌گیرانه بین «شواهد» (Evidence) و «متن نهایی» (Copy) ایجاد می‌کند. به‌جای بررسی یک پنجره چت، بازبین انسانی ابتدا با یک «کارت شواهد» تعامل می‌کند. این کارت مانند یک رسید تحویل لباس در هتل عمل می‌کند؛ پیش‌نویس متن همان لباس است و شما نمی‌توانید لباس را تحویل دهید مگر اینکه شماره‌های رسید دقیقاً مطابقت داشته باشند. یک لباس زیبا هرگز جایگزین یک شماره گم‌شده نمی‌شود.

مکانیزم کارت شواهد

هسته این سیستم یک کارت شواهد مبتنی بر JSON است که «سلاتهای» (Slots) مشخصی را برای داده‌های حساس و اثرگذار تعریف می‌کند. در این ساختار، کارت در واقع رابط کاربری (Interface) است و متن تولیدشده صرفاً یک حدس پایین‌دستی است. برای یک پاسخ پشتیبانی، این سلاتها شامل موارد زیر است:

• plan_name: سطح دقیق اشتراک یا Billing Tier کاربر. این فیلد با ویژگی stop_if_empty: true علامت‌گذاری شده است.
• refund_amount: مبلغ دقیق دلاری که مورد بحث است. این فیلد نیز با ویژگی stop_if_empty: true علامت‌گذاری شده است.
• access_state: اینکه آیا کاربر در حال حاضر به یک قابلیت خاص دسترسی دارد یا خیر. این فیلد با ویژگی stop_if_empty: true علامت‌گذاری شده است.
• customer_goal: یک فیلد اختیاری که برای ایجاد همدلی در متن استفاده می‌شود. این فیلد با ویژگی stop_if_empty: false علامت‌گذاری شده است، زیرا نبودِ آن یک پلن یا مبلغ را اثبات یا رد نمی‌کند.

هر سلات با یک ویژگی stop_if_empty مشخص شده است. اگر هوش مصنوعی نتواند منبعی برای نام پلن در متن گفتگو (Transcript) پیدا کند، سلات خالی می‌ماند. طبق آموزش‌های dev.to، اگر هر یک از سلات‌های stop_if_empty مقدار null داشته باشند، سیستم باید به‌صورت برنامه‌ریزی‌شده عمل ارسال (Send) را مسدود کند. در اینجا، تصمیم‌گیرنده نهایی بازبین انسانی است و پیامد احتمالی، دادن یک وعده دروغین کتبی به مشتری است. نقطه بازگشت و اصلاح، قبل از ارسال است، نه بعد از تحویل پیام.

مرحله صفر: نام‌گذاری ارسال‌های حساس

قبل از ساخت کارت، این پروتکل تعریف دقیقی از ریسک را می‌طلبد که در فایلی به نام decision.txt مستند می‌شود. هدف این است که جملات «زشت و مشخص» باشند تا یک حقوق‌دان بتواند مستقیماً به فعل اشاره کند و مسئولیت را بسنجد.

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

فرآیند تمرین و اعتبارسنجی

برای پیاده‌سازی این سیستم بدون ریسک کردن ترافیک واقعی مشتریان، پروتکل پیشنهاد می‌کند از یک «اتاق تمرین» (Rehearsal Room) استفاده شود. نویسنده برای دسترسی رایگان به مدل‌ها و گزینه سرور رایگان جهت تست این گیت‌ها، از MonkeyCode استفاده کرده است. در این مدل، محصول از مسیر تصمیم‌گیری جدا شده است: سرور پیش‌نویس را می‌سازد، اما کارت تصمیم می‌گیرد. اگر این دو نتوانند از هم جدا شوند، این آزمایش نباید روی ترافیک مشتریان اجرا شود.

این فرآیند از یک اعتبارسنجی سخت‌گیرانه چند مرحله‌ای پیروی می‌کند:

• مرحله ۱: ساخت کارت شواهد: ایجاد ساختار JSON قبل از اینکه هر مدلی آن را ببیند. یک کارت غیرقابل خواندن، خود یک شرط توقف است. کارت رابط است و متن یک حدس پایین‌دستی.
• مرحله ۲: تست استاب (Stub Testing): استفاده از پرامپت‌هایی (مانند prompt-stub.txt) که صراحتاً هوش مصنوعی را از اختراع داده منع می‌کنند. پرامپت دستور می‌دهد: «نام پلن، مبلغ بازگشت وجه یا وضعیت دسترسی را اختراع نکن. اگر سلاتی خالی است، آن را در بلوک شواهد ابتدایی خالی نگه دار». اگر پیش‌نویسی حاوی کلماتی مثل «Pro»، «Team» یا یک مبلغ دلاری بدون منبع باشد، یعنی چاه مسموم شده و پیش‌نویس شکست می‌خورد. پیش‌نویسی که سه مارکر «EMPTY» برگرداند، پاس شده است؛ اما پیش‌نویسی با صفر مارکر خالی یعنی کارآموز سعی کرده رسید تحویل لباس را از خودش پر کند.
• مرحله ۳: تست استرس سناریو: اجرای سه صحنه خاص برای بررسی اینکه آیا بازبین هنوز نام پلن را چک می‌کند یا خیر. این‌ها نظرسنجی نیستند، بلکه تست‌های دقیقی هستند که در هر کدام، یک رشته گفتگو با یک حفره وجود دارد:
  • صحنه A: درخواست بازگشت وجه بدون ذکر مبلغ در متن گفتگو.
  • صحنه B: درخواست دسترسی بدون ذکر وضعیت فعلی دسترسی.
  • صحنه C: یک پیام تشکر که فقط روی لحن تمرکز دارد و تمام سلات‌ها در آن خالی هستند. این صحنه «تله» است، زیرا بی‌خطر به نظر می‌رسد اما همچنان نمی‌تواند نام یک پلن را ذکر کند.

رابط کاربری برای بازبین‌های انسانی

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

[آیتم صف] $ \rightarrow $ [کارت شواهد با سلات‌های خالی قابل مشاهده] $ \rightarrow $ [پیش‌نویس عامل در زیر کارت، هرگز بالای آن نه] $ \rightarrow $ [توقف در صورت خالی بودن هر یک از سلات‌های stop_if_empty] $ \rightarrow $ [بازبین انسانی حفره را نام می‌برد یا منبع را تأمین می‌کند] $ \rightarrow $ [ارسال] یا [بازگرداندن به عامل با ذکر نام حفره].

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

• برچسب‌گذاری صریح: به‌جای دکمه مبهم «تأیید»، سیستم باید از نام‌های صادقانه‌ای مانند «ارسال با وجود خالی بودن نام پلن» استفاده کند. نام‌های صادقانه باعث کند شدن کلیک‌های اشتباه می‌شوند و این کند شدن دقیقاً هدف سیستم است.
• ترتیب تمرکز (Focus Order): دکمه «ارسال» نباید اولین نقطه تمرکز برای کاربر کیبورد باشد. اگر ارسال اول باشد، طراح در واقع یک تله ایجاد کرده است.
• وضوح بصری: کلمه «خالی» (Empty) باید یک کلمه واقعی باشد، نه یک جای‌گذار (Placeholder) کمرنگ؛ زیرا جای‌گذارها ناپدید می‌شوند و شواهد ناپدید شده، همان راهی است که کارآموز هوش مصنوعی پیروز می‌شود.

مدیریت «پرکردن‌های دور ریخته شده»

وقتی یک بازبین پاسخی را به‌دلیل اختراع حقیقت توسط هوش مصنوعی مسدود می‌کند، پروتکل توصیه می‌کند که متن توهم‌زده حذف نشود. به‌جای آن، داده‌های اختراعی به یک «چاه دورریز» (مانند فایل handback.json) منتقل می‌شوند. این فایل مواردی چون thread_id (شناسه رشته گفتگو)، named_holes (حفره‌های شناسایی شده) و discarded_agent_fill (مانند یادداشتی که می‌گوید «پر کردن اثبات نشده، به مشتری نمایش داده نشد») را ردیابی می‌کند.

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

معیارها و سنجش موفقیت

این رویکرد تعریف موفقیت را تغییر می‌دهد. موفقیت دیگر «پاراگراف زیباتر» یا «امتیاز احساسی بالاتر» نیست. موفقیت یعنی یک «حفره بیان شده» (Spoken Hole)؛ لحظه‌ای که یک انسان یک حقیقت گم‌شده را شناسایی کرده و ارسال را متوقف می‌کند. اسکریپت امتیازدهی (score.py) تصمیم را بر اساس سلات‌ها ارزیابی می‌کند:

• پاس (Pass): توقفی که مبلغ بازگشت وجه را به عنوان مورد گم‌شده نام می‌برد (named-stop).
• پاس (Pass): یک ارسال مستند شده (sourced-send) که در آن هیچ‌کدام از سلات‌های توقف خالی نیستند.
• شکست (Fail): ارسالی که یک بازگشت وجه ۴۹ دلاری را اختراع کرده است (invented-or-ignored-empty).
• شکست (Fail): تأخیر طولانی بدون نام بردن از حفره یا تصمیم نامشخص.

فیلدهای اضافی مانند customer_goal اختیاری می‌مانند. اگرچه آن‌ها به همدلی کمک می‌کنند، اما پلن را اثبات نمی‌کنند. اگر تیمی در حالی که plan_name خالی است، درباره متن همدلانه بحث کند، این ریتوال (آیین) از پیش شکست خورده است.

محدودیت‌ها و دامنه کاربرد

برای تیم‌هایی که بازبین انسانی در چرخه ندارند یا از کانال‌هایی استفاده می‌کنند که امکان بازگشت پیام (Reversibility) ندارند، این کارت پژوهشی کافی نیست. آن محیط‌ها به گیت‌های خودکار و سخت‌گیرانه‌تری نیاز دارند، زیرا هزینه یک «پر کردن خاموش» بسیار زیادتر از آن است که بتوان به توجه یک بازبین انسانی تکیه کرد.

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

گام بعدی شما

• اگر از عامل‌های پشتیبانی استفاده می‌کنید، لیست «ارسال‌های حساس» خود را در یک فایل متنی (مانند decision.txt) تعریف کنید.
• رابط کاربری بازبینی خود را تغییر دهید تا داده‌های استخراج‌شده (Evidence) حتماً بالای متن تولیدشده قرار بگیرند.
• یک «چاه دورریز» برای ثبت توهمات مدل ایجاد کنید تا الگوهای خطای عامل خود را تحلیل کنید.

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