خطای بصری در مدل‌های زبانی؛ وقتی اطمینان بالا ماسکی برای توهم است

تصور کنید یک حسابرس مالی عددی را کاملاً اشتباه بخواند، اما با اطمینان ۱۰۰ درصد ادعا کند که درست دیده است؛ او حدس نمی‌زند، بلکه صرفاً دچار خطای ادراکی شده است. این دقیقاً همان نقطه‌ضعفی است که مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — هنگام مواجهه با اسناد پیچیده PDF از خود نشان می‌دهند. در واقع، یک امتیاز اطمینان (Confidence Score) بالا از سوی یک LLM، تضمینی برای دقت نیست، بلکه اغلب نقابی است برای پوشاندن یک توهم (Hallucination).

بسیاری از توسعه‌دهندگان از امتیاز اطمینان مدل به عنوان یک فیلتر ایمنی استفاده می‌کنند و گمان می‌کنند اگر مدل در مورد یک رقم تردید داشته باشد، آن را با «اطمینان پایین» علامت‌گذاری می‌کند. اما طبق گزارش فنی مفصلی که در ۲۰ اوت ۲۰۲۶ منتشر شد، وقتی مدل یک مقدار غلط را کاملاً خوانا می‌بیند، شکافی خطرناک میان «دقت ادراک‌شده» و «دقت واقعی» ایجاد می‌شود. این واقعیت توسط توسعه‌دهنده‌ای که در جریان رقابت All Things Agentic Hackathon در حال ساخت یک عامل (Agent) بود، به طور عملی به اثبات رسید؛ او نشان داد که مدل‌ها نمی‌توانند خطاهای خوانش خود را هنگام پردازش PDFهای پیچیده به طور قابل اعتمادی تشخیص دهند. این چالش با رویکردهای جدید برای ارزیابی پایداری عامل‌های هوشمند که بر تزریق خطا برای سنجش قابلیت اطمینان تمرکز دارند، همسو است.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی توهمات مدل‌های چندوجهی اشاره کردیم، مشکل اینجاست که مدل‌ها نمی‌توانند خطاهای بصری خود را تشخیص دهند. برای اثبات این موضوع، این توسعه‌دهنده نسخه‌های تخریب‌شده‌ای از لیست‌های پرداخت انجمن‌های مسکن رومانی را طراحی کرد. این اسناد معمولاً شامل ۲۸ آپارتمان، ۱۵ ستون داده و ۸ کلید تخصیص مختلف هستند. طبق قانون، ساکنان تنها ۱۰ روز برای اعتراض به محاسبات فرصت دارند، اما تعداد کمی این کار را انجام می‌دهند زیرا این امر مستلزم شناخت همزمان قوانین قانونی و محاسبات ریاضی است.

برای اینکه مدل را مجبور کنند به جای لایه‌های متنی (Text Layers)، پیکسل‌ها را بخواند، توسعه‌دهنده از یک مولد برای تولید نمونه‌های تخریب‌شده استفاده کرد. این اسناد با ویژگی‌های زیر بازسازی شدند:

• تبدیل به تصویر (Rasterized) با کیفیت ۱۵۰ dpi
• کج کردن (Skew) تا ۱.۵ درجه
• تزریق نویز گوسی (Gaussian Noise)
• تنظیم کیفیت JPEG روی ۷۵ درصد
• بسته‌بندی مجدد به عنوان PDF بدون لایه متنی (به گونه‌ای که دستور pdftotext تنها سه بایت خروجی برگرداند)

نتایج تکان‌دهنده بود. استخراج‌کننده (Extractor) صراحتاً منع شده بود که هرگونه محاسبه‌ای انجام دهد و با حروف بزرگ به او دستور داده شده بود که مقادیر نامشخص را در بخش low_confidence_fields قرار دهد. با وجود این، مدل در شناسایی خطاها شکست خورد. به نقل از مستندات این پروژه، در یک مورد، مدل هزینه آب گرم ۴۱.۸۰ لئی را به دلیل کج بودن صفحه، از ردیف آپارتمان ۵ خواند و عدد ۳۴.۲۰ را ثبت کرد. مدل حدس نزد؛ بلکه صرفاً مقدار را از ردیف اشتباه برداشت.

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

برای حل این بحران، توسعه‌دهنده به جای پرسیدن از مدل که «آیا مطمئن هستی؟»، سیستمی قطعی (Deterministic) به نام R0 را پیاده کرد. این سیستم بر پایه افزونگی ذاتی در اسناد مالی است؛ جایی که ردیف‌ها و ستون‌ها باید بدون توجه به دامنه (چه گرمایش باشد و چه سهم مالکیت)، با مجموع‌های خاصی برابر شوند.

• تایید ردیفی: مجموع هزینه‌ها + بدهی‌های معوقه + جریمه‌ها باید دقیقاً برابر با مبلغ کل چاپ‌شده در سند باشد.
• تایید ستونی: مجموع مقادیر در تمام آپارتمان‌ها باید با مجموع اعلام‌شده برای آن دسته‌بندی خاص مطابقت داشته باشد.

وقتی هر دو تاییدیه (ردیفی و ستونی) با یک مقدار یکسان خطا داشتند، سیستم می‌توانست سلول دقیق ایجادکننده خطا را مکان‌یابی کند. برای مثال، سیستم شناسایی کرد که تفکیک هزینه‌های آپارتمان ۷ (۸۹۱.۳۳) با مبلغ کل چاپ‌شده (۸۹۸.۹۳) مطابقت ندارد و اختلاف آن ۷.۶۰- لئی است. هم‌زمان، مجموع ستون «آب گرم خانگی» (۳۲۱۸.۶۰) نیز دقیقاً ۷.۶۰- لئی با مجموع اعلام‌شده (۳۲۲۶.۲۰) اختلاف داشت.

سپس عامل (Agent) یک بازخوانی هدفمند از همان سلول خاص با وضوح بالاتر (۳۰۰ dpi) انجام می‌دهد، در حالی که پاسخ مدل تنها به همان یک سلول محدود شده است. در مورد آپارتمان ۷، خوانش دوم مقدار صحیح ۴۱.۸۰ را برگرداند.

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

این رویکرد محافظه‌کارانه تضمین می‌کند که سیستم هیچ یافته‌ی غلطی (False Finding) در حسابرسی تولید نکند. با ایزوله کردن سلول نامطمئن، بقیه فرآیند حسابرسی می‌تواند بدون باطل شدن کل سند ادامه یابد. این دقت در سطح فیلد اجازه می‌دهد سیستم همچنان موارد زیر را تایید کند:

• آیا سهم‌های تفکیک‌نشده در مجموع ۱۰۰٪ می‌شوند؟
• آیا جریمه‌ها در محدوده سقف قانونی هستند؟
• آیا تعداد آپارتمان‌ها درست است؟

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

در ۵ بار اجرای هر سند، نتایج شکافی عمیق در توانایی‌ها را نشان داد:

• شناسایی (Identification): مدل خوب عمل کرد و به طور متوسط ۲.۸ از ۳ و ۳.۴ از ۴ مورد از خطاهای از پیش تعیین‌شده را یافت. همچنین در ۴ مورد از ۵ اجرا، مبالغ جریمه‌های غیرقانونی را به درستی نقل کرد.
• کمی‌سازی (Quantification): مدل بسیار ضعیف عمل کرد و تنها ۰.۲ از ۴ مورد را یافت. مدل مبلغ جریمه چاپ‌شده را گزارش می‌کرد اما تقریباً هرگز مبلغ اضافی نسبت به سقف قانونی را محاسبه نکرد؛ زیرا این کار مستلزم دانستن سقف قانونی، اعمال آن بر بدهی‌ها و تفریق است.

در یک تست روی سندی که هیچ خطای عمدی نداشت، مدل عدد ۳۴۷.۴ (شاخص کنتور) را ۳۴۷.۲ خواند. سپس محاسبات ریاضی بی‌نقصی را روی این عدد غلط انجام داد (۳۵۳.۰ - ۳۴۷.۲ = ۵.۸ متر مکعب) و نتیجه گرفت که انجمن مقدار خوانش را ۰.۲ متر مکعب کمتر گزارش کرده است. مدل بر اساس یک اشتباه در خوانش، یک خطای جعلی خلق کرد؛ این ثابت می‌کند که «استدلال» روی داده‌های استخراج‌شده‌ی غلط، فقط منجر به توهمات پیچیده‌تر و تشدید شکست می‌شود. این نوع خطاهای فنی در خروجی‌های AI، یادآور بررسی‌هایی است که نشان داد ۶۲٪ از کرنل‌های GPU تولیدشده توسط هوش مصنوعی حاوی اشتباهات ساختاری هستند.

برای جلوگیری از این اتفاق، معماری این سامانه با استفاده از Google ADK SequentialAgent و ۶ زیر-عامل طراحی شده است. یک مرز ساختاری سخت‌گیرانه تعریف شده تا فقط سه زیر-عامل با مدل در تماس باشند:

۱. تریاژ (Triage): خواندن صفحه اول برای تصمیم‌گیری درباره اینکه آیا سند ارزش اجرای خط لوله گران‌قیمت را دارد یا خیر.
۲. استخراج (Extraction): تبدیل تصاویر به مقادیر عددی.
۳. تدوین (Drafting): نوشتن نامه نهایی.

تمام بررسی‌های یکپارچگی و هفت قانون حسابرسی در پایتون معمولی نوشته شده‌اند. توسعه‌دهنده حتی تستی طراحی کرده که فایل reconciler.py را تجزیه (Parse) می‌کند تا مطمئن شود هیچ SDK مدل هوش مصنوعی در بخش Importهای آن وجود ندارد؛ یعنی ایجاد یک خط سخت بین AI احتمالی و منطق قطعی (Deterministic).

حتی نامه نهایی نیز اعتبارسنجی می‌شود. هر مبلغ در پیش‌نویس تولید شده باید دقیقاً به یک یافته‌ی محاسباتی از reconciler پایتون متصل باشد و هر پاراگراف باید به یکی از این یافته‌ها اشاره کند. اگر مدل عددی را اختراع کند یا از متن توضیحات reconciler به جای اعداد تاییدشده استفاده کند، اعتبارسنج (Validator) پیش‌نویس را رد می‌کند. در یک مورد، اعتبارسنج سه پیش‌نویس را رد کرد زیرا مدل اعدادی را از متن توضیحات استخراج کرده بود که در لیست مجاز نبودند. یک بررسی سخت‌گیرانه که در صورت شک، خروجی را رد می‌کند (Fail Closed)، نشان می‌دهد که کجا یک تعریف ناقص است، به جای اینکه اجازه دهد یک خروجی غلط عبور کند. این رویکرد سخت‌گیرانه برای جلوگیری از پیامدهای اشتباه در طبقه‌بندی ریسک‌های هوش مصنوعی و نادیده گرفتن وصله‌های حیاتی ضروری است.

اگرچه این عامل (Consilium) برای اسناد مسکن رومانی ساخته شده، اما معماری آن برای هر سند مالی که صادرکننده آن نفعی در اشتباه کردن به نفع خود داشته باشد و گیرنده مهلت قانونی برای اعتراض داشته باشد، قابل تعمیم است. این موارد شامل موارد زیر است:

• قبض‌های خدمات شهری و صورت‌حساب‌های پزشکی
• تسویه‌حساب‌های بیمه
• فاکتورهای تامین‌کنندگان برای کسب‌وکارهای کوچک

در حالی که طرح‌ها (Schemas) و شماره قوانین تغییر می‌کنند، اما بررسی R0 تغییر نمی‌کند، زیرا این بررسی هیچ دانش تخصصی از حوزه (Domain Knowledge) ندارد و تنها بر این الزام استوار است که اعداد باید با هم جمع شوند.

گام بعدی شما

• اگر از LLM برای استخراج داده‌های عددی استفاده می‌کنید، هرگز به امتیاز Confidence مدل اعتماد نکنید.
• برای داده‌های حساس، یک لایه تایید قطعی (Deterministic) با پایتون یا SQL طراحی کنید که مجموع‌ها را چک کند.
• در صورت بروز اختلاف بین دو بار خوانش مدل، داده را به جای انتخاب یکی، به عنوان «نامعتبر» علامت‌گذاری کنید.

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