تصور کنید یک مدیر محصول برای بررسی وضعیت سیستم، از یک عامل هوش مصنوعی سؤال میپرسد و پاسخی دریافت میکند که دقیقاً با اعداد تیتر گزارشات همخوانی دارد، اما با واقعیتهای موجود در بدنهٔ متن در تضاد است. این دقیقاً همان نقطهای است که دقت سیستمهای خودکار در برابر جذابیتهای بصری تیترها شکست میخورد.
در ۱۰ سپتامبر ۲۰۲۶، شرکت Rulestack مجموعهای از هفت پاسخ تولیدشده توسط یک عامل (Agent) — شبیه به کارمندی دیجیتال که میتواند ابزارها را مدیریت کند و تصمیم بگیرد — را به یک بازبین مستقل ارسال کرد. نتیجه تکاندهنده بود: ۷۱٪ از این پاسخها حاوی خطاهای فاحش بودند. در واقع از هفت پیشنویس ارسال شده، پنج مورد دارای اشتباهات واقعی بودند. نکتهٔ بحرانی این بود که این توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی میگوید که اصلاً وجود ندارد، مثل دوستی که خاطرهای را اشتباه تعریف میکند — مربوط به دنیای بیرون نبود، بلکه عامل دربارهٔ مکانیسمهای داخلی خودِ Rulestack و معیارهای سنجش آن دروغ میگفت.
بسیاری از شرکتها تصور میکنند اگر یک مدل به مستندات داخلی دسترسی داشته باشد، تبدیل به منبع حقیقت میشود. اما طبق گزارش dev.to، این اتفاق یک نقطهٔ کور خطرناک را آشکار کرد: عاملها اغلب عبارات «بهیادماندنیتر» را که معمولاً در تیترها هستند، به دادههای دقیق بدنهٔ متن ترجیح میدهند. این وضعیت باعث ایجاد یک حلقه معیوب میشود که در آن هوش مصنوعی به جای دقت یک گزارش، گرد کردنها و بهینهسازیهای یک عنوان را به ارث میبرد. همانطور که در تحلیلهای قبلی ما دربارهٔ امنیت مدلهای بازمتن اشاره کردیم، تکیه بر دادههای بدون ساختار میتواند منجر به نتایج غیرقابلپیشبینی شود.
کالبدشکافی شکستها
بر اساس بررسیهای بازبین، خطاها در چندین حوزهٔ حیاتی رخ داده بود. هر هفت پیشنویس حداقل یک ادعای نادرست دربارهٔ سیستم داشتند؛ ادعاهایی که شامل موارد دقیقی مثل تعداد توکنهای اندازهگیری شده، میزان انحراف زمانبندی به ساعت یا جزئیات بررسی سلامت سیستم بود:
- توهمات عددی: عامل ادعا کرد انحراف زمانبندی ۷۶ ساعت است. در حالی که این عدد در تیتر ظاهر شده بود، بدنهٔ مقاله گزارش میداد که انحراف واقعی ۷۴ ساعت است. این چالش با یافتههای اخیر در مورد ابزارهای جستجوی هوش مصنوعی همسو است، جایی که بسیاری از ارجاعات عددی در سیستمهایی مانند Perplexity فاقد سندیت واقعی تشخیص داده شدند.
- خطاهای مکانیکی: عامل نحوهٔ بررسی سلامت سیستم را اشتباه توصیف کرد. او مدعی بود سیستم زمان برنامهریزی را با زمان پیشبینیشده برای پست کردن مقایسه میکند، در حالی که در واقعیت، مقایسه با ساعت جاری انجام میشد. (جالب است که Rulestack بعدها در همان جلسه، نسخهٔ دو-ساعته را ساخت چون یافتهٔ بازبین درست بود).
- تضادهای منطقی: یکی از پیشنویسها ادعا کرد یک عملیات زمانبندیشده کمتر از مقدار اعلامشده اجرا شده است، در حالی که مستندات داخلی صراحتاً تأیید میکرد اجرای عملیات در تمام روزها (به جز یک روز) کامل بوده است.
- انکار شواهد: عامل مدعی شد هیچ مدرکی برای بازرسیهای پس از اجرا وجود ندارد، در حالی که دو دایرکتوری کامل از دفاتر کل JSONL وجود داشت که در هر بار اجرا، دادههای جدید به آنها اضافه میشد.
- حذف زمینه: مدل عدد ۵۴,۱۵۴ توکن را برای هر زیر-عامل ذکر کرد، اما شرایط خاص اندازهگیری را حذف کرد: این عدد مربوط به پروبی بود که هیچ ابزاری را فراخوانی نمیکرد، هیچ فایلی را نمیخواند و بر روی مخزن آنها با فایلهای دستورالعمل آنها اجرا شده بود.
تلهٔ تیتر و شکست اولین راهکار
به نقل از گزارش فنی Rulestack، فریبدهندهترین خطا همان عدد «۷۶ ساعت» بود. تیتر مقاله میگفت: «۱۲ روز هیچ شکست سیستمی نداشتیم در حالی که زمانبندی ما ۷۶ ساعت جابهجا شد». این جمله در یک لحظهٔ خاص از زمان درست بود، اما بدنهٔ متن عدد نهایی را ۷۴ ساعت ثبت کرده بود. در واقع رکورد حادثه حاوی سه خوانش دیگر بود زیرا در سه لحظه مختلف نمونهبرداری شده بود.
تیترها اعداد را گرد میکنند و یک لحظه را بدون ذکر بازه زمانی منجمد میکنند. عامل هوش مصنوعی چون تیتر برجستهترین بخش متن بود، آن را به عنوان منبع اصلی پذیرفت، در حالی که این بخش کمترین مستندات پشتیبان را داشت. برای حل این مشکل، تیم Rulestack یک بررسی مکانیکی طراحی کرد: «آیا پیشنویس به عددی استناد میکند که در تیتر هست اما در بدنهٔ هیچ مقالهای نیست؟».
اما اولین نسخه این بررسی شکست خورد. سیستم خروجی {"checked":2,"violations":[]} را برگرداند. یعنی پیشنویسی را که قرار بود شناسایی کند، تایید کرد. دلیلش این بود که عدد ۷۶ بیش از ۱,۳۴۳ بار در ۴۶ دفتر کل (Ledger) مختلف ظاهر شده بود. اینها اعداد بیربطی بودند: تعداد بازدید صفحات، فاصله دنبالکنندگان، امتیازات تم، کسرهای میلیثانیه در برچسبهای زمانی ISO و زیررشتههای شناسههای هگزادسیمال کامنتها.
اصلاح دقت و پاکسازی دادهها
تیم فنی برای کاهش این «تطبیقهای تصادفی»، دو اقدام فوری انجام داد:
۱. حذف توکنهای مبهم: تمام URLها، URIها، شناسههای DID و رشتههای طولانی هگزادسیمال یا Base32 حذف شدند تا عددی که بخشی از یک کد شناسایی است، به عنوان یک مقدار اندازهگیری شمرده نشود.
۲. تطابق توکن کامل: از عبارتهای منظم (Regex) مانند (?<![\w.,])76(?![\w.,]) استفاده شد تا اعدادی مثل ۱,۷۶۰ یا ۷۶.۴ باعث فعال شدن هشدار برای عدد ۷۶ نشوند.
با این حال، سیستم باز هم خطاهای مثبت زیادی میداد. یک عدد ۷۶ در دفتر کل بازدیدها، هنوز یک عدد ۷۶ واقعی و کامل است، اما هیچ معنایی دربارهٔ انحراف زمانبندی ندارد. مشکل اصلی در «مجموعه داده» (Corpus) بود. با حذف کامل دفاتر کل (state ledgers) و باقی گذاشتن فقط تیترها و بدنهها، سیستم بالاخره درست کار کرد. تیم متوجه شد که دفاتر کل حاوی اندازهگیری هستند، اما حاوی «جملاتی» نیستند که بتوان بر اساس آنها تصمیم گرفت آیا یک ادعا پشتیبانی میشود یا خیر.
منطق مجموعه داده
دقت از مجموعه داده میآید، نه از ابزار تطبیق. وقتی یک سیستم خطای کمی دارد (Under-fire)، غریزه ما میگوید قوانین تطبیق را زیاد کنیم؛ و وقتی خطای زیاد دارد (Over-fire)، غریزه میگوید استثناها را افزایش دهیم. هر دو حس پیشرفت در ابزار تطبیق را میدهند، اما افزودن متن بیشتر به سیستم، همیشه احتمال تطبیقهای تصادفی را بالا میبرد. وقتی متن زیاد شود، یک تطبیق تصادفی از یک استناد واقعی غیرقابل تشخیص میشود. این موضوع یادآور این نکته است که بسیاری از بنچمارکهای رایج هوش مصنوعی ممکن است صرفاً گزارشِ شانس باشند و نه لزوماً نشاندهنده برتری الگوریتمی در درک دادهها.
برای حل این مسئله، Rulestack تعریف کرد که بررسی باید این جمله را تأیید کند: «هیچ متنی که ما نوشتهایم، این عدد را پشتیبانی نمیکند». بدنههای متن این تصمیم را میگیرند، تیترها متهم هستند و دفاتر کل اصلاً نمیتوانند در این مورد تصمیم بگیرند، چون ردیفهای یک دفتر کل، اندازهگیری یک چیز هستند و آن «چیز» در نام یک فیلد زندگی میکند، نه در جملهای که یک خواننده بتواند آن را بخواند.
به عنوان مثال، دو بدنه مقاله حاوی کاراکترهای «76» بودند اما در قالب یک برچسب زمانی که به .776Z ختم میشد، یک شناسه کامنت که با 6a976cb شروع میشد و یک نام فایل تصویر مانند czivjmmthia76yxgr8ku.png. اینها دقیقاً مواردی هستند که حذف توکنهای مبهم آنها را پاک میکند و اجازه میدهد بدنهها به درستی حاوی هیچ عدد ۷۶ (به معنای واقعی) نباشند.
دروازهٔ ایمنی جدید
این بررسی اکنون در تمام رابطهای خط فرمان (CLI) ارسال پاسخ، پیش از هرگونه تماس شبکهای، روی تمام برنامههای موجود در یک دسته (Batch) اجرا میشود. اگر حتی یک پیشنویس در یک دستهٔ هشتتایی حاوی عددی بدون پشتیبانی باشد، کل دسته دور ریخته میشود. این کار مانع از آن میشود که سیستم سه پاسخ را ارسال کند و پنج مورد دیگر را بدون هیچ رکوردی مسدود کند.
این مکانیسم مشابه سایر حفاظها (Guardrails) — مثل وضعیت تایید، حکم لحن (Tone Verdict) و تازگی رشتهٔ گفتگو — عمل میکند. همچنین این یک دستور مستقل است که اجازه میدهد پیشنویس در حین نوشته شدن بررسی شود. شناسایی خطا در لحظه ارسال، یک تور ایمنی است؛ اما شناسایی آن در لحظه پیشنویس، هدف اصلی است.
این سیستم تمام خطاها را نمیگیرد. مثلاً نمیتواند خطاهای مربوط به مکانیسمهای پیچیده (مثل خطای بررسی سلامت) را تشخیص دهد چون برای این کار نیاز به درک انسانی از پیادهسازی کد است. اما سادهترین و رایجترین حالت شکست را حذف میکند: تمایل عامل به تبدیل یک تیترِ بهینهشده برای بازاریابی به یک نقطهٔ دادهٔ واقعی.
برای صاحبان کسبوکاری که در حال استقرار عاملها هستند، یک درس حیاتی در اینجا وجود دارد: دقت از مجموعه داده میآید، نه از ابزار تطبیق. اگر تمام فایلهای لاگ و دفاتر کل خود را به خورد یک عامل بدهید، دقت آن را زیاد نمیکنید، بلکه احتمال تطبیقهای تصادفی را بالا میبرید که شبیه به حقیقت به نظر میرسند.
گام بعدی شما
- اگر از RAG برای عاملهای خود استفاده میکنید، دسترسی مدل به لاگهای خام را محدود کنید و فقط مستندات تاییدشده را به عنوان منبع حقیقت قرار دهید.
- یک لایه بررسی مکانیکی (Mechanical Check) برای تطبیق اعداد استخراجشده در پاسخ با بدنهٔ مستندات پیادهسازی کنید.
- در پرامپتهای سیستمی، صراحتاً دستور دهید که مدل در صورت تضاد بین تیتر و بدنه، اولویت را به بدنه بدهد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهٔ تراشههای Blackwell مراجعه کنید.
گفتگو