پرش به محتوای اصلی
پرش به محتوای مقاله

توهم تیک سبز؛ چرا سیستم‌های اعتبارسنجی خودکار هوش مصنوعی شکست می‌خورند؟

·۳۱ شهریور ۱۴۰۵۸ دقیقه مطالعه
تحلیل
هر دروازه‌ای رد شد. شماره همچنان اشتباه بود.
هر دروازه‌ای رد شد. شماره همچنان اشتباه بود.
اشتراک‌گذاری
واقعاً چه چیز جدید است؟

معرفی تفکیک سه گانه اعتبارسنجی (منبع، همتا، خود) و اثبات اینکه برای داده‌های منطقی، کد قطعی تنها جایگزین معتبر برای استنتاج احتمالی است.

تصور کنید سناریویی را که در آن یک سیستم بررسی توهمات (Hallucination Checker) وضعیت را «PASS» (تایید) اعلام می‌کند و یک سیستم بررسی سازگاری (Consistency Checker) نیز در هشت سطح مختلف از خروجی، وضعیت را «PASS» برمی‌گرداند، اما با این حال، جمله‌ای که آن‌ها تایید کرده‌اند از نظر ریاضی کاملاً غلط است. این پارادوکس اعتبارسنجی خودکار در خطوط تولید هوش مصنوعی، محوریت گزارش تحلیلی است که در ۲۲ سپتامبر ۲۰۲۶ توسط Pi در پلتفرم dev.to منتشر شد.

داستان از این قرار است که در یک خط تولید ویدیو، هوش مصنوعی به بینندگان یاد می‌داد که سال ۱۹۹۰ به‌اضافه ۱۸ می‌شود ۲۰۰۹. اما در واقعیت، چنین نیست. این اشتباه در تمام بخش‌ها — از متن روی تصویر (Cover Copy) و اسلایدهای فرمول گرفته تا مقدمه، موخره و متادیتای ویدیو — تکرار شده بود. در مجموع، این خطا در هشت جای مختلف از یک قطعه محتوا وجود داشت و تنها دو روز تا زمان انتشار عمومی فاصله داشت. با وجود پنج لایه بررسی خودکار مجزا، این خطا تقریباً به دست مخاطب می‌رسید؛ زیرا هر لایه، معیار محدودی از «درست بودن» را می‌سنجید که هیچ ارتباطی با حقیقت واقعی ریاضی نداشت.

برای کسانی که در حال ساخت عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیارهای دیجیتالی که می‌توانند به‌طور مستقل کارهای پیچیده را مدیریت کنند — هستند، این اتفاق یک هشدار جدی درباره یک شکاف بحرانی است: تفاوت میان «وفاداری به منبع» (Faithfulness) و «صحت در دنیای واقعی» (Accuracy). اکثر سیستم‌های اعتبارسنجی فعلی بررسی نمی‌کنند که آیا یک ادعا در حقیقت درست است یا خیر، بلکه می‌سنجند که آیا این ادعا با یک نقطه مرجع (که احتمالاً خودش غلط است) سازگار است یا نه. این چالش با آمارهای تکان‌دهنده‌ای که نشان می‌دهد بیش از ۸۰٪ مقالات فنی تولیدشده با هوش مصنوعی حاوی ادعاهای ساختگی هستند، همسو است و عمق بحران توهمات را نشان می‌دهد. وقتی هیچ انسان دیگری برای بررسی وجود ندارد، تنها راه دانستن اینکه آیا خروجی واقعی است یا خیر، درک دقیق خط گزارش‌دهی و هدف مقایسه‌ای است.

شکست منشأ و سازگاری

اولین دروازه در این خط تولید، یک بررسی «مبنی‌سازی» (Grounding Check) بود. وظیفه این لایه این بود که مطمئن شود هر فکت موجود در روایت ویدیو، در مقاله منبعی که ویدیو بر اساس آن ساخته شده بود، وجود دارد. این بررسی وضعیت را «PASS» اعلام کرد، زیرا خود مقاله منبع حاوی همان خطا بود: در متن منبع صراحتاً ذکر شده بود «سال تولد + ۱۸».

چون روایت ویدیو با منبع مطابقت داشت، بررسی منشأ (Provenance Check) به طور کامل و بی‌نقص عمل کرد. این سیستم تایید کرد که ادعا نسبت به منبع «وفادار» است، اما نسبت به این حقیقت کور بود که منبع مذکور حدود شش هفته بود که با همان اشتباه در سایت منتشر شده بود. یک بررسی منشأ فقط می‌تواند ادعاهایی را پیدا کند که با منبع «ناهماهنگ» هستند؛ اگر ادعایی را به آن بدهید که با یک منبع غلط «سازگار» باشد، سیستم با اطمینان به شما یک ارجاع (Citation) می‌دهد.

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

لایه دوم، بررسی «سازگاری» (Consistency Check) بود. این ابزار تمام سطوح یک پروژه — از متادیتا و اسلایدها تا مقدمه و موخره — را اسکن می‌کند تا مطمئن شود یک عدد در همه جا به یک شکل ظاهر شده است. در این مورد خاص، عدد غلط (۱۸) در هر ۸ مکان ظاهر شده بود. خروجی سیستم دقیقاً این بود: «✅ add-N 단일(+18), 전 면 일관 (8곳)» (یعنی: عدد ۱۸ در هر ۸ نقطه به‌طور یکسان تکرار شده است).

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

حلقه مفقود: خود-ردیابی

آنچه در این سیستم گم شده بود، بررسی‌ای است که یک ادعا را با «خودش» مقایسه کند. خطای «۱۹۹۰ به‌اضافه ۱۸ می‌شود ۲۰۰۹» ذاتاً «خود-ردشونده» (Self-refuting) است؛ زیرا عمل‌وندهای ریاضی و نتیجه هر سه در خود جمله حضور دارند. برای اثبات غلط بودن این جمله، نیازی به دانش جهانی، زمینه (Context) یا منبع خارجی نیست. مقایسه در اینجا نه با یک منبع و نه با یک سطح همتا، بلکه با محاسبات ریاضیِ خودِ ادعا است.

برای حل این مشکل، نویسنده یک اسکریپت ۱۹۹ خطی پیاده‌سازی کرد که از سه عبارت منظم (Regex) برای شناسایی ریاضیات نوشتاری و یک تخفیف مدولار (Modulo Concession) برای حل نمادگذاری سال‌های تحصیلی دو رقمی در زبان‌های کره‌ای و ژاپنی استفاده می‌کرد. مکانیسم آن بسیار ساده است: if (a + n === b) return true;. این اسکریپت متادیتا و فایل‌های متنی را می‌خواند، هر سه-تایی (Triple) نوشتاری را استخراج می‌کند، جمع را با اعداد صحیح (Integers) دوباره محاسبه می‌کند و در صورت تایید خروجی ۰، در صورت خطا خروجی ۱ و در صورت نبودن مورد مورد نظر، خروجی ۲ می‌دهد.

در خط تولید نهایی، این اسکریپت برای هر زبان اجرا می‌شود. قرارداد ارکستراتور (Orchestrator) تنها چهار کلمه است: «هر خروجی غیرصفر، خطا می‌اندازد» (a nonzero exit throws). اگر امروز این دروازه را روی همان فایل خراب اجرا کنیم، این پیام چاپ می‌شود: 06-formula-18.text: 「1990足す18で2009」 → 기대 2008, 표기 2009 → FAIL: 산술 모순은 절대 통과 불가 (یعنی: انتظار ۲۰۰۸ بود، اما ۲۰۰۹ نوشته شده -> شکست: تناقض ریاضی هرگز قابل قبول نیست) و خروجی ۱ برمی‌گرداند.

نویسنده این اسکریپت را «زخمی با کد خروجی» می‌نامد. این ابزار از پیش‌بینی به دست نیامد، بلکه نتیجه یک شکست بود. در واقع، این خطا توسط انسانی شناسایی شد که دو روز پیش از انتشار، محاسبات را دستی بازبینی می‌کرد و اسکریپت تقریباً ۱۴ دقیقه بعد از رسیدن فایل اصلاح‌شده نوشته شد. اگر نویسنده ادعا می‌کرد که Regex چیزهایی را گرفت که مدل‌ها از دست دادند، داستان جذاب‌تری می‌شد، اما دروغ بود. Regex این مورد خاص را نجات نداد، بلکه کل این «دسته از خطاها» را نجات داد تا دیگر هرگز به صف انتشار نرسند.

سه مرجع اعتبارسنجی

طبق گزارش Pi، هر حکم اعتبارسنجی در واقع ادعایی درباره یک مقایسه است. تنها سه چیز وجود دارد که یک بررسی خودکار می‌تواند یک ادعا را با آن‌ها مقایسه کند و هر کدام نقطه کور خاص خود را دارند:

  • مقایسه با منبع (Against a Source): آیا این مورد در چیزی که باید به آن وفادار باشیم وجود دارد؟ این بررسی «وفاداری» را می‌سنجد. ارزان و دقیق است و ابزاری درست برای شناسایی فکت‌های ساختگی (Invented Facts) است، اما نسبت به خطاهای موجود در خود منبع و مقادیر مشتق شده کور است.
  • مقایسه با همتایان (Against Siblings): آیا این مقدار با هر جای دیگری که ظاهر شده است، مطابقت دارد؟ این بررسی «توافق» (Agreement) را می‌سنجد. دقیق است و تغییرات پراکنده یا اصلاحات ناقص را می‌گیرد، اما هیچ چیزی درباره اینکه آیا مقدار مورد توافق «درست» است یا خیر، نمی‌گوید.
  • مقایسه با خود (Against Itself): آیا ادعا در صورت محاسبه مجدد، پابرجا می‌ماند؟ این بررسی «منطق داخلی» (مانند ریاضیات، تاریخ‌ها، واحدها و جمع کل) را می‌سنجد. این تنها بررسی غیرقابل‌بحث است زیرا به هیچ دانش جهانی نیاز ندارد، اما فقط برای بخش کوچکی از ادعاها که حاوی ابزار رد کردن خودشان هستند، کاربرد دارد.

محدودیت‌های منتقدان مدل (Model Critics)

بسیاری از توسعه‌دهندگان سعی می‌کنند از «منتقدان» مبتنی بر مدل‌های زبانی بزرگ (LLM) همراه با دستورالعمل‌هایی (Rubrics) برای بررسی لحن، تناسب با بازار یا بررسی اینکه آیا یک متن شبیه ترجمه است یا خیر، استفاده کنند. اما نویسنده اشاره می‌کند که این‌ها اغلب بیشتر «آرزو» هستند تا الگوریتم. در یک مورد، بررسی کیفیت ترجمه که در متن به صورت یک «آستانه شباهت مرتب» تعریف شده بود، در زمان پیاده‌سازی مشخص شد که اصلاً وجود خارجی ندارد. این عدم قطعیت در ابزارهای نظارتی، یادآور گزارشاتی است که نشان می‌دهد بیش از نیمی از گزارش‌های خطای هوش مصنوعی در بازرسی حفاظ‌ها مثبت کاذب بوده‌اند، که نشان می‌دهد تکیه بر مدل برای نظارت بر مدل، لزوماً به معنای دقت نیست.

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

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

شکاف حل‌نشده

با وجود تمام این دروازه‌ها، یک دسته از خطاها همچنان پوشش داده نشده‌اند: «آیا این قانون در مورد دنیای واقعی درست است؟». این سوال را نمی‌توان به یک خط لوله (Pipeline) سپرد، زیرا نیاز به تایید حقیقت خارجی دارد که فراتر از محدوده منشأ یا سازگاری است. هر بررسی خودکار در این خط لوله درست عمل کرد و یک خطا را با وفاداری بازتولید کرد، زیرا خطا از جایی وارد شده بود که قبل از تمام این بررسی‌ها قرار داشت.

در مثال سال تولد، قانون «+۱۸» در واقع برای افرادی که در ماه‌های اول سال به دنیا آمده بودند درست بود؛ ظرافت‌هایی که ویدیو بیش از حد فشرده بود تا بتواند آن‌ها را توضیح دهد. این یعنی حتی «اصلاح» هم کاملاً پاکیزه نیست؛ اکنون دروازه بررسی، یک پرچم (Flag) صریح را ارسال می‌کند تا اجازه دهد بیش از یک مقدار جمع وجود داشته باشد و ویدیوی اصلاح‌شده هنوز در برخی جاها عدد ۱۸ را آموزش می‌دهد.

علاوه بر این، سیستم فاقد یک CI (یکپارچه‌سازی مداوم) برای اجبار به اجرای این دروازه‌ها است؛ آن‌ها را می‌توان در ارکستراتور خاموش کرد. تنها ادعای صادقانه این است که تنها مسیری که واقعاً یک ویدیو را ارسال می‌کند، این بررسی را اجرا می‌کند و هر خروجی غیرصفر، اجرا را متوقف می‌کند.

به عنوان یادآوری این شکست، نویسنده شناسه اسلاید اصلاح‌شده را همان 06-formula-18 نگه داشت، هرچند عدد به ۱۹ تغییر کرد. این یک فسیل از خطا است تا ثابت کند تیک سبز، صرفاً بیانی درباره یک مقایسه خاص است، نه بیانی درباره حقیقت.

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

گام بعدی شما

  • خط لوله‌های اعتبارسنجی خود را بررسی کنید و ببینید کدام یک از سه مرجع (منبع، همتا یا خود) را می‌سنجند.
  • برای هرگونه محاسبه ریاضی یا منطقی در خروجی‌های AI، لایه‌ی کد قطعی (Deterministic) جایگزین مدل‌های احتمالی کنید.
  • به جای پرسیدن «آیا این درست است؟» از مدل، از او بخواهید گام‌به‌گام منطق را بازنویسی کند و سپس آن را با یک اسکریپت ساده تطبیق دهید.

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

چرا این موضوع مهم است؟

این گزارش بر اساس تجربه عملی نشان می‌دهد که اتکای مطلق به مدل‌های داور (LLM-as-a-judge) می‌تواند منجر به انتشار گسترده اطلاعات غلط شود. اعتبار سیستم‌های خودکار تنها زمانی معنا دارد که مرجع مقایسه آن‌ها، حقیقتی خارج از فضای احتمالی مدل باشد.

تأثیر برای ایران

برای توسعه‌دهندگان ایرانی که در حال ساخت عامل‌های هوش مصنوعی برای کسب‌وکارها هستند، این هشدار یعنی نباید برای اعتبارسنجی خروجی‌ها صرفاً به APIهای مدل‌های دیگر تکیه کنند و باید لایه‌های کدنویسی سخت‌گیرانه اضافه کنند.

·نگاه ما
تحریریه دات‌هوش

اعتماد بیش از حد به لایه‌های نظارتی AI در واقع نوعی «امنیت کاذب» ایجاد می‌کند. مشکل اصلی این است که ما «سازگاری» (Consistency) را با «صحت» (Accuracy) اشتباه می‌گیریم. راهکار واقعی، بازگشت به کدنویسی سنتی و قطعی برای بخش‌های حساس منطقی است، نه افزودن لایه‌های بیشتر از همان مدل‌های احتمالی که خطا را تولید کرده‌اند.

منابع

این گزارش با خط‌لولهٔ خودکار دات‌هوش از منابع معتبر جهانی تدوین و زیر نظر تحریریه منتشر شده است. روش کار ما

گفتگو

پنج‌شنبه‌های هوش‌محور

بسته‌ی هفتگی دات‌هوش

۵ خبر، ۲ ابزار، ۱ پرامپت در هر شماره. به‌زودی راه‌اندازی می‌شود — هر پنج‌شنبه صبح.

خبر کلیدی
ابزار کاربردی
پرامپت حرفه‌ای
تحلیل پژوهش
به‌زودی
زاویه‌ی ایرانی
به‌زودی
تمرین این هفته
به‌زودی

راهنماهای دات‌هوش

راهنماهای کاربردیِ دات‌هوش برای کار با هوش مصنوعی — از همین‌جا شروع کنید:

دات‌هوش

راهنمای فارسی هوش مصنوعی — با نگاه به ایران

اخبار روزانه، معرفی ابزارها و مدل‌ها، و آموزشِ کار با هوش مصنوعی؛ همیشه با این پرسش که از ایران چه چیزی کار می‌کند و چه چیزی نه.