تصور کنید یک عامل خرید هوشمند را برای یافتن ارزان‌ترین قیمت محصول به کار می‌گیرید، اما او به‌جای گفتن «قیمت موجود نیست»، قیمت قدیمی و خط‌خورده را به‌عنوان قیمت فعلی به شما تحویل می‌دهد. این دقیقاً همان نقطه‌ای است که مدل‌های زبانی بزرگ در مواجهه با داده‌های مفقود، دچار شکست سیستمی می‌شوند.
طبق گزارشی که در ۲۸ سپتامبر ۲۰۲۶ منتشر شد، مدل‌های هوش مصنوعی در ۷۰.۷٪ از موارد استخراج داده، فیلدهای خالی را جعل کرده‌اند. این آزمایش که در earnanhonestdollar.com/bench میزبانی می‌شود، یک نقص بحرانی را افشا می‌کند: مدل‌ها وقتی مقداری را نمی‌یابند، اعداد تصادفی نمی‌سازند، بلکه محتمل‌ترین «مقدار فریبنده» (Decoy) موجود در صفحه را برمی‌دارند.
این «کوری نسبت به فقدان»، یک ریسک سیستمی برای عامل‌های (Agents) خودمختار است. اگر یک عامل خرید نتواند هر پاسخ را تأیید کند، باید بداند که سرویس مقصد چه زمانی می‌گوید «نمی‌دانم» و چه زمانی یک جعل را به‌عنوان حقیقت ارائه می‌دهد. در فضای فعلی استخراج داده‌های نیمه‌ساختاریافته، خروجی یک جعل اغلب دقیقاً شبیه به یک استخراج درست است و هیچ سیگنال محلی برای تشخیص خطا توسط کاربر باقی نمی‌گذارد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی توهمات مدل‌های زبانی اشاره کردیم، تمایل مدل‌ها به «پُر کردن جاهای خالی» ریشه در ماهیت احتمالی آن‌ها دارد.
متدولوژی صفحات دوقلو
این محک (Benchmark) از طراحی «صفحات دوقلو» برای جداسازی جعل استفاده می‌کند. هر مورد آزمایشی شامل دو صفحه است که تنها در یک ردیف تفاوت دارند: یک صفحه حاوی پاسخ هدف است و دیگری آن را حذف کرده است. هر دو صفحه حاوی «فریبنده‌ها» هستند؛ اطلاعاتی که شبیه پاسخ به نظر می‌رسند اما از نظر زمینه‌ای غلط‌اند. این رویکرد برای مقابله با سوگیری‌های ارزیابی است، مشابه آنچه در بررسی نشت داده‌ها در مجموعه‌های ارزیابی مشاهده کردیم که در آن دسترسی مدل‌ها به داده‌های تست، نتایج را مخدوش می‌کرد.
مثال‌هایی از این فریبنده‌ها عبارتند از:
- یک قیمت خط‌خورده مانند «قیمت قبلی ۴۹۳ دلار بود» که نشان‌دهنده قیمت قدیمی است، نه قیمت فعلی.
- خطی که می‌گوید «بازبینی شده توسط عمر تام»، در حالی که او نویسنده اثر نیست.
- تاریخی مانند «آخرین به‌روزرسانی ۷ سپتامبر ۲۰۲۰»، که تاریخ انتشار واقعی مقاله نیست.
یک استخراج‌کننده صادق باید در صفحه اول مقدار درست و در صفحه دوم مقدار تهی (Null) را برگرداند. هر چیز دیگری «جعل» محسوب می‌شود. پژوهشگران ۴۲ جفت صفحه را در ۷ نوع مختلف و روی ۱۶ مدل آزمایش کردند و امتیازدهی را تنها برای صفحاتی انجام دادند که فیلد مورد نظر در آن‌ها مفقود بود.
به نقل از گزارش dev.to، نتایج در ۱۶ مدل بررسی‌شده تکان‌دهنده بود:
- بدون دستورات خاص، ۴۰۵ مورد از ۵۷۳ فیلد مفقود جعل شدند.
- با یک دستور ساده («برای هر فیلدی که مقدارش در صفحه نیست از null استفاده کن و حدس نزن»)، تعداد جعل‌ها به ۱۱۶ مورد از ۵۷۴ کاهش یافت.
- الگوی شکست ثابت بود: مدل‌ها تقریباً همیشه مقدار فریبنده را انتخاب می‌کردند تا اینکه بپذیرند قیمت فعلی مفقود است. در مورد فریبنده «قیمت قبلی ۴۹۳ دلار بود»، تمام ۱۶ مدل در نبود دستور، عدد ۴۹۳ را به‌عنوان قیمت اعلام کردند؛ اما با اضافه شدن دستور، تنها ۱ مدل این اشتباه را تکرار کرد.
عملکرد مدل‌ها و موارد استثنا
داده‌های کلی، تفاوت‌های شدیدی را در قابلیت اطمینان مدل‌ها نشان می‌دهد. برخی مدل‌ها به دستور «پذیرش نادانی» بسیار بهتر پاسخ دادند. هزینه هر اجرا نیز متغیر بود:
- Gemini 3.8 Flash: بدون دستور ۱۴ مورد از ۳۶ را جعل کرد و با دستور به ۱ مورد رسید (هزینه: ۰.۱۶۱۹ دلار).
- GLM 5.3: بدون دستور ۱۸ مورد و با دستور ۱ مورد از ۳۶ را جعل کرد (هزینه: ۰.۱۷۲۳ دلار).
- GPT-6 Luna: بدون دستور ۲۵ مورد و با دستور ۵ مورد از ۳۶ را جعل کرد (هزینه: ۰.۰۰۴۹ دلار).
- Sonnet 5: بدون دستور ۲۴ مورد و با دستور ۵ مورد از ۳۶ را جعل کرد (هزینه: ۰.۱۰۷۱ دلار).
- Gemma 4 31B: بدون دستور ۲۶ مورد و با دستور ۱۳ مورد از ۳۶ را جعل کرد (هزینه: ۰.۰۰۳۷ دلار).
Firecrawl (API پولی) یک استثنای منفی و قابل توجه بود. این ابزار حتی با وجود دستور، ۲۴ مورد از ۳۶ فیلد مفقود را جعل کرد و به‌طور مداوم مقدار فریبنده را کپی نمود. این محک اشاره می‌کند که فاصله عملکردی Firecrawl با سایرین از طریق بازه‌های ۹۵٪ غیرهم‌پوشان تأیید می‌شود. برای یک عامل خرید، API پولی که مقداری غلط اما موجود را برمی‌گرداند، خطرناک‌تر از مدلی است که فقدان داده را می‌پذیرد، زیرا این سطح از قابلیت اطمینان، پیش‌نیاز اساسی (Table-stakes) برای یک عامل خرید است.
محدودیت‌های محک
نویسنده محک درباره چندین محدودیت شفاف است که کاربران باید هنگام تفسیر داده‌ها در نظر بگیرند:
- هر شرکت تنها یک بار تست شده و هیچ تکراری در کار نبوده است.
- صفحات مورد استفاده مصنوعی (Synthetic) بودند و تله‌ها به‌طور خاص برای این تست نوشته شده بودند.
- APIهای پولی در لایه‌های رایگان و تنها با گنجاندن جمله پذیرش نادانی اجرا شدند.
- کاربران باید به‌جای ترتیب دقیق ردیف‌ها، به ابتدا و انتهای جدول نتایج نگاه کنند، زیرا ردیف‌هایی که بازه‌های ویلسون (Wilson intervals) آن‌ها هم‌پوشانی دارد، به‌طور واضح از هم جدا نشده‌اند.
معماری «بررسی‌کننده ارزان»
از آنجا که نرخ جعل ۲۰.۲٪ هنوز برای عامل‌های عملیاتی بسیار بالا است (یعنی از هر ۵ فیلد مفقود، یکی جعل می‌شود)، این محک یک معماری تأیید را پیشنهاد می‌کند. در یک طرح (Schema) با دوازده فیلد اختیاری، این نرخ باعث می‌شود در اکثر اسناد حداقل یک جعل رخ دهد. دستور پذیرش نادانی، احتمال پاسخ «نامعلوم» را بالا می‌برد، اما توانایی جدیدی برای تشخیص فقدان به مدل نمی‌دهد، زیرا این توانایی در وزن‌های (Weights) مدل برای این تسک وجود ندارد.
به‌جای اعتماد به استخراج‌کننده اصلی، سیستم از یک مدل دوم و ارزان‌تر برای تأیید استفاده می‌کند تا بررسی کند آیا صفحه واقعاً از مقدار بازگشتی پشتیبانی می‌کند یا خیر. دو بررسی‌کننده با بازدهی بالا تست شدند:
- GPT-6 Luna: ۳۸ مورد از ۴۹ جعل را شناسایی کرد و هیچ مقدار درستی را رد نکرد (۰ مورد از ۴۷ مقدار درست رد شد).
- Jev 1.13 (یک مدل تصمیم‌گیرنده): ۲۳ مورد از ۴۹ جعل را شناسایی کرد و هیچ مقدار درستی را رد نکرد.
هزینه این تأیید ناچیز است؛ برای ۱۲۶ جفت منحصر‌به‌فرد از صفحه و مقدار، هزینه برای Luna تنها ۰.۰۰۴۹ دلار و برای Jev ۰.۰۰۲۴ دلار بود. با این حال، بررسی‌کننده‌ها در موارد «معنای نزدیک» شکست خوردند؛ مثلاً وقتی «زمان استراحت» به‌جای «زمان پخت» یا «زمان کل» گزارش شده بود، هیچ‌کدام از ۶ خطای این‌چنینی را شناسایی نکردند.
این تفکیک یک درس طراحی کلیدی می‌دهد: یک بررسی ارزان که هرگز مقدار درست را رد نمی‌کند و اکثر جعل‌ها را می‌گیرد، ارزش اجرا روی هر خروجی را دارد. شکست‌ها در موارد معنای نزدیک صرفاً نشان می‌دهد که در کجا هنوز به انسان یا یک داور قدرتمندتر نیاز است.
پیامدها برای عامل‌های کدنویسی
این پدیده مستقیماً به کدهای تولیدشده توسط هوش مصنوعی تعمیم می‌یابد. عاملی که یک فراخوانی تابع را برای تابعی که وجود ندارد جعل می‌کند، دقیقاً همان خطای استخراج‌کننده داده را مرتکب شده است. خروجی محتمل به نظر می‌رسد و از نظر ساختاری درست است، به این معنی که یک بازبین از همان خانواده مدل، احتمالاً همان «شکل جعل» را به اشتراک می‌گذارد و خطا را تأیید می‌کند. این موضوع اهمیت تحلیل هزینه‌های واقعی اصلاح را دوچندان می‌کند، چرا که در رتبه‌بندی عامل‌های کدنویس دیدیم که نرخ موفقیت لزوماً با کارایی عملیاتی و هزینه نهایی اصلاح باگ‌ها همسو نیست.
این دقیقاً مشابه خطاهای بازبینی کد در خواندن سورس است: یک Diff که در آن یک شرط حفاظتی (Guard clause) به‌سادگی مفقود شده، یک پاسخ API که در آن فیلدی از طرح وعده داده شده اما ناپدید شده، یا مقدار پیکربندی که از فایلی خوانده می‌شود که اصلاً آن را تعریف نکرده است. عامل در هر صورت یک پاسخ مطمئن و خوش‌ساخت تولید می‌کند. باگ در «فضای منفی» زندگی می‌کند، و این دقیقاً جایی است که تولید با اعتمادبه‌نفس خطرناک‌ترین حالت است.
برای کاهش این ریسک، این مطالعه بر جداسازی تولیدکننده از بررسی‌کننده تأکید می‌کند. استفاده از یک مدل متمایز یا یک بازبین سلف-هاست مانند Kodus تضمین می‌کند که تأییدکننده، «دوقلوی» تولیدکننده نباشد. هدف ایجاد دروازه‌ای است که جعل‌های واضح را بگیرد بدون اینکه بلوک‌های اشتباهی ایجاد کند که باعث شود تیم‌های انسانی هشدارها را نادیده بگیرند.
برای کسانی که از بازبین‌های مبتنی بر قانون (Rule-based) استفاده می‌کنند، «تست قناری» برای اینکه آیا قوانین واقعاً بارگذاری می‌شوند یا خیر، حیاتی است. بررسی‌کننده‌ای که به‌طور بی‌صدا در اجرا شکست می‌خورد، در واقع بررسی‌کننده‌ای است که همه چیز را تأیید می‌کند.
نحوه تست سیستم خودتان
توسعه‌دهندگان برای تشخیص اینکه آیا عامل‌هایشان حدس می‌زنند یا خیر، نیازی به ابزار دقیق این محک ندارند، اما باید الگوی آن را پیاده کنند:
۱. ساخت موارد دوقلو: برای هر آیتمی که عامل استخراج می‌کند، یک ورودی بسازید که مقدار در آن موجود باشد و یکی که مقدار در آن حذف شده باشد.
۲. افزودن فریبنده‌ها: یک مقدار فریبنده محتمل اضافه کنید که یک خواننده تنبل آن را بردارد.
۳. تست خط پایه: تست را یک بار بدون دستور پذیرش نادانی و یک بار با آن اجرا کنید و تعداد جعل‌ها را ثبت کنید.
۴. تأیید بررسی‌کننده: ارزان‌ترین بررسی‌کننده موجود را روی خروجی‌ها اجرا کرده و به‌طور جداگانه تعداد جعل‌های شناسایی‌شده و رد‌های اشتباه را بشمارید.
بازتولید نتیجه «قیمت ۴۹۳ دلار» اولویت اصلی است؛ اگر مدلی قیمت خط‌خورده را به‌عنوان قیمت فعلی برگرداند، شکست مدل از پیش آشکار شده است. این تغییر، صنعت را از «اعتماد به خروجی» به سمت یک محصول تأییدیه درجه‌یک سوق می‌دهد. ابزاری که بپذیرد اشتباه می‌کند اما مکانیزمی برای بررسی آن‌ها ارائه ندهد، اساساً برای گردش‌کارهای عامل‌محور نامناسب است. اگرچه پذیرش نادانی تنها بخشی از تأیید است، اما این محک یکی از محورهای این مشکل را بهتر از اکثر کارت‌های امتیازدهی فروشندگان اندازه‌گیری می‌کند.
گام بعدی شما
- اگر از مدل‌های استخراج داده استفاده می‌کنید، فوراً دستور «استفاده از null برای مقادیر مفقود» را به پرامپت سیستمی اضافه کنید.
- یک مدل کوچک‌تر و ارزان‌تر (مانند GPT-4o-mini یا Gemini Flash) را به‌عنوان لایه تأیید (Verifier) برای خروجی‌های حساس تعریف کنید.
- برای داده‌های حیاتی، تست «صفحات دوقلو» را روی مجموعه‌ای از داده‌های واقعی خودتان اجرا کنید تا نرخ جعل را بسنجید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو