تصور کنید یک عامل هوش مصنوعی به شما گزارش می‌دهد که میز رستوران با موفقیت رزرو شده است، اما در واقعیت، پذیرنده فقط گفته بود «بعداً با شما تماس می‌گیرم». این یک شکست در منطق است، نه در زبان؛ شکافی که می‌تواند مشتری را بدون میز در مقابل درِ رستوران رها کند.
Oathra — یک محیط اجرای متن‌باز (Open-source Runtime) برای عامل‌های تلفنی — با سلب قدرت تصمیم‌گیری از مدل زبانی بزرگ (LLM) درباره‌ی موفقیت تماس، این مشکل را حل کرده است. در این سیستم، یک قطعه کد مجزا، متن مکالمه را تحلیل می‌کند تا بررسی کند آیا واقعاً تعهدی صورت گرفته است یا خیر. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت و قابلیت اطمینان مدل‌های عامل‌محور اشاره کردیم، تکیه بر تفسیر درونی مدل‌ها برای عملیات حساس، ریسک بالایی دارد. این رویکرد جداسازی لایه‌ها یادآور معماری LangGraph است که با تفکیک منبع داده از استدلال، دقت عامل‌های فروش را افزایش داد.
بسیاری از عامل‌های فعلی، شبیه به کسی هستند که فقط به کلمات کلیدی گوش می‌دهد و جزئیات را نادیده می‌گیرد. اگر پذیرنده بگوید «حتماً، شما را در لیست می‌گذارم»، یک مدل ساده کلمه «حتماً» را می‌بیند و تسک را تکمیل‌شده علامت می‌زند. اما در واقعیت، رزرو نهایی نشده است چون پذیرنده هنوز روی آن زمان خاص تعهد نداده است. این فاصله بین توافق زبانی و تأیید عملیاتی، جایی است که اکثر شکست‌های عامل‌های هوشمند رخ می‌دهد.
زمینه و بستر شکست
برای درک بهتر این مشکل، درخواستی را در نظر بگیرید: «آیا می‌توانم یک میز برای دو نفر در تاریخ ۲۵ سپتامبر ساعت ۷:۳۰ عصر رزرو کنم؟ نام من تاناکا است». در یک آزمایش که پنج پاسخ مختلف به این درخواست یکسان بررسی شد، تنها یکی از آن‌ها یک رزرو واقعی بود. با این حال، اگر از یک مدل پرسیده شود «آیا این تماس موفق بود؟»، به حداقل چهار مورد از آن‌ها پاسخ مثبت می‌دهد؛ زیرا هر پنج پاسخ از نظر یک مدل زبانی، شبیه به «بله» به نظر می‌رسند.
این اتفاق به این دلیل می‌افتد که بررسی‌های تکمیل (Completion Check) معمولاً فقط تعداد فیلدهای پر شده — مانند تاریخ، ساعت و تعداد نفرات — را می‌شمارند و تا زمانی که این اعداد در متن حضور داشته باشند، عملیات را موفق می‌دانند. این روش نمی‌تواند تفاوت بین یک «پیشنهاد»، یک «رزرو موقت» و یک «تعهد نهایی» را تشخیص دهد. در واقع، پیچیدگی‌های پیکربندی دستی برای جلوگیری از این خطاها، همان چیزی است که در بحث «مالیات انتخاب» و جایگزینی عامل‌های بدون پیکربندی به آن پرداختیم.
طبق گزارش فنی منتشر شده در ۲۲ سپتامبر ۲۰۲۶ در وب‌سایت dev.to، پنج تله زبانی اصلی وجود دارد که باعث «تکمیل کاذب» (False Completion) می‌شود:
تله‌های زبانی
- ثبت موقت (The Pencil-In): پذیرنده می‌گوید «حتماً، شما را برای ۲۵ سپتامبر ساعت ۷:۳۰ عصر یادداشت می‌کنم و بعداً برای تأیید تماس می‌گیرم». عامل به دلیل دیدن تاریخ و ساعت صحیح، به اشتباه گزارش موفقیت می‌دهد. در اینجا کلمه «حتماً» نشان‌دهنده موافقت است، اما رزرو واقعی هنوز انجام نشده است.
- نگهداری صریح (The Explicit Hold): وقتی پذیرنده می‌گوید «می‌توانیم ۲۵ سپتامبر ساعت ۷:۳۰ را فعلاً نگه داریم، اما هنوز تأیید نشده است». استخراج‌کننده‌های ساده اغلب ساعت (مثلاً ۱۹:۳۰) را ثبت می‌کنند اما نفی را نادیده می‌گیرند. اگر مقادیر به جای هر بند (Clause)، بر اساس هر گفته (Utterance) استخراج شوند، عبارت «هنوز تأیید نشده» و «ساعت ۷:۳۰» در متغیرهای متفاوتی قرار می‌گیرند و معنای نفی از بین می‌رود.
- پیشنهاد متقابل (The Counter-Offer): پذیرنده زمان دیگری را پیشنهاد می‌دهد: «تنها چیزی که برای آن شب باقی مانده ساعت ۹ شب است. مناسب است؟». اگر نوبت بعدی عامل پاسخ «ساعت ۹ مناسب است، ممنونم» باشد، یک استخراج‌کننده ساده ساعت ۲۱:۰۰ را از نوبت پذیرنده برمی‌دارد و یک رزرو کامل را ثبت می‌کند، در حالی که هیچ‌کس هنوز بر سر آن توافق نکرده است. نوبت پذیرنده باید به عنوان یک «پیشنهاد» باقی بماند تا زمانی که تماس‌گیرنده آن را بپذیرد و پذیرنده نیز آن پذیرش را تأیید کند.
- پس گرفتن تأیید (The Retraction): پذیرنده ابتدا یک زمان را تأیید می‌کند («بله، شما را برای دو نفر در ۲۵ سپتامبر ساعت ۷:۳۰ ثبت کردیم») اما بلافاصله می‌گوید «ببخشید، انگار آن روز کاملاً پر است». بسیاری از سیستم‌ها نمی‌توانند تأیید اولیه را لغو کنند، مگر اینکه پذیرنده از کلمات صریحی مانند «لغو شد» یا «نمی‌توانیم رزرو را بپذیریم» استفاده کند.
- پارادوکس «همه چیز ردیف است» (The All Set Paradox): عباراتی مثل «برای ۲۵ سپتامبر ساعت ۷:۳۰، دو نفر، همه چیز ردیف است» برای انسان‌ها تأییدات واضحی هستند. با این حال، این جملات ممکن است توسط موتورهایی که «موافقت با یک مقدار پیشنهادی» را از «تأیید نهایی رزرو» جدا می‌کنند، نادیده گرفته شوند. اگر تأیید به مقادیر تثبیت‌شده وابسته باشد و هیچ مقداری قبلاً تثبیت نشده باشد، این تأیید به عنوان داده‌ای قدیمی تلقی شده و حذف می‌شود.
مکانیسم‌های فنی برای دقت
برای حل مشکل «پس گرفتن تأیید»، Oathra در به‌روزرسانی PR #37 یک راهکار دقیق پیاده کرد. این سیستم اکنون از مجموعه‌ای محدود از «کلمات در دسترس بودن» — مانند «پر» (full)، «رزرو خصوصی» (private hire)، «بسته» (closed) یا «کاملاً پر» (fully booked) — استفاده می‌کند تا هرگونه تأیید قبلی که دقیقاً در مراحل earlier (قبل‌تر) تماس بیان شده است را لغو کند.
این دقت به‌صورت عمدی طراحی شده است. برای مثال، یک رد کلی مانند «ما کارت بانکی قبول نمی‌کنیم»، یک نکته مربوط به پرداخت است و نباید باعث لغو رزرو شود. همچنین، ردی که قبل از رزرو اتفاق می‌افتد (مثلاً «ساعت ۷ پر است اما ۷:۳۰ خالی است») باعث لغو نمی‌شود، زیرا بعد از یک تأیید صورت نگرفته است.
این رویکرد، معیار موفقیت عامل‌های هوش مصنوعی را از «روانی کلام» (Fluency) به «داده مرجع» (Ground Truth) تغییر می‌دهد. در دنیای عامل‌های خودکار، یک «منفی کاذب» (گزارش عدم رزرو در حالی که رزرو شده) فقط یک مزاحمت کوچک است و کاربر صرفاً یک بار دیگر تماس می‌گیرد. اما یک «مثبت کاذب» منجر به این می‌شود که مشتری بدون میز در مقابل درِ رستوران بایستد.
تضمین قابلیت اطمینان
توسعه‌دهنده این پروژه برای حفظ قابلیت اطمینان، در هر نسخه ۱۰,۰۰۰ دیالوگ خصمانه (Adversarial Dialogues) را اجرا می‌کند. این تست‌ها شامل پنج حالت ذکر شده در بالا و موارد زیر است:
- پیام‌گیرهای صوتی (Voicemails)
- انتقال تماس‌ها (Call transfers)
- توالی‌های «انتظار و سپس پاسخ» (Hold-then-reply)
- تأییدات با لهجه‌های مختلف (Dialect confirmations)
- بازگویی‌های اشتباه (Wrong restatements)
قانون سخت‌گیرانه این پروژه این است: برای انتشار هر نسخه، نرخ تکمیل کاذب در تمام ۱۰,۰۰۰ اجرا باید «صفر» باشد. تکمیل کاذب زمانی رخ می‌دهد که محیط اجرا گزارش «تکمیل شده» بدهد، اما داده مرجعِ طرف مقابل تماس نشان دهد که هیچ تعهدی صورت نگرفته است. عدد صفر تنها عدد پذیرفته شده برای عبور از تست است.
این متدولوژی یک نقطه کور بزرگ در توسعه هوش مصنوعی را آشکار می‌کند: زبانی که تست نمی‌کنید، همان زبانی است که خراب است. توسعه‌دهنده اشاره کرد که در حالی که بخش ژاپنی سیستم به‌خوبی کار می‌کرد، بخش انگلیسی در تأییدات ساده‌ای مثل «All set» شکست می‌خورد تا زمانی که به‌طور صریح تست و اصلاح شد.
اکنون توسعه‌دهندگان می‌توانند لاگ‌های تماس خود را در ابزار عمومی forifor.github.io/oathra/en/check.html بررسی کنند تا بفهمند آیا عامل‌هایشان در حال توهم (Hallucination) — شبیه به دوستی که خاطره‌ای را اشتباه تعریف می‌کند — درباره موفقیت هستند یا خیر. این ابزار نیاز دارد که هر نوبت مکالمه در یک خط باشد و گوینده مشخص شود (مثلاً «AI: [text]» و «Them: [text]»). این مخزن تحت لایسنس Apache-2.0 در GitHub در مسیر FORIFOR/oathra در دسترس است.
گام بعدی شما
- اگر از عامل‌های صوتی استفاده می‌کنید، لاگ‌های تماس خود را با ابزار بررسی Oathra تطبیق دهید تا نرخ مثبت کاذب را بسنجید.
- در طراحی سیستم‌های عامل‌محور، لایه تصمیم‌گیری درباره «موفقیت عملیاتی» را از لایه «تولید متن» جدا کنید.
- برای هر زبان هدف، مجموعه‌ای از دیالوگ‌های خصمانه (Adversarial) طراحی کنید تا نقاط کور زبانی مدل را بیابید.
اما داستان سخت‌افزاری اجرای این مدل‌ها در مقیاس وسیع حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو