تصور کنید متنی را میخوانید که تمام اعدادش دقیق هستند، اما نتیجهگیریهایش شما را به مسیری کاملاً غلط میبرد. این دقیقاً همان تلهای است که نویسندگی فنی با هوش مصنوعی برای متخصصان میسازد.
بسیاری از کاربران وقتی متنی صیقلخورده و حرفهای میبینند، آن را محصول نهایی میپندارند. اما طبق گزارشی که در ۱۷ سپتامبر ۲۰۲۶ در dev.to منتشر شد، یک مرحله بازبینی انسانی توانست ۱۱ خطای مجزا را در مقالهای بیابد که توسط هوش مصنوعی و بدون هیچ ویرایش انسانی نوشته شده بود. این آزمایش ثابت میکند که صحتِ ظاهری مدلها، اغلب توهمی است که از تطبیق ادعاها با متنِ ورودی ایجاد میشود، نه تطبیق آنها با دنیای واقعی.
این وضعیت شبیه این است که شما به یک آشپز رباتیک چهار ماده اولیه بدهید و از او بخواهید دستور پخت بنویسد؛ ربات مواد را درست لیست میکند، اما در پایان ادعا میکند که این «راهنمای جامع تمام مواد ممکن برای این غذا» است. مواد درستاند، اما ادعای جامع بودن یک دروغ است. این دقیقاً همان نقطهای است که هوش مصنوعی در این آزمایش فنی شکست خورد. همانطور که در تحلیلهای قبلی ما دربارهی توهمات مدلهای زبانی اشاره کردیم، مدلها در مرز بین «آنچه میدانند» و «آنچه حدس میزنند» دچار لغزش میشوند.
جزئیات چیدمان آزمایش
مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — در این آزمایش با دادههای بسیار محدودی تغذیه شد. نویسنده پوشهای شامل سه فایل را در اختیار مدل قرار داد که مجموعاً ۵,۰۸۵ بایت حجم داشتند: یک یادداشت موضوعی (Topic Memo)، یک لاگ اندازهگیری خام (که شامل خروجی دستورات بود و هیچ تفسیری در آن نبود) و ۱۳ خط از کد منبعی که مقاله قرار بود درباره آن باشد. برای اطمینان از یکپارچگی دادهها، تمام این مواد هش (Hash) شده بودند.
دستورالعمل ارسالی به مدل تنها در یک جمله خلاصه شده بود: «یک مقاله فنی قابل انتشار بنویس که فقط از این مواد استفاده کند، موضوع و ساختار را مستقلانه انتخاب کن و هیچ عددی را که در مواد نیست، اختراع نکن.» مدل مسئولیت انتخاب موضوع، ساختار، طراحی نمودارها و حتی انجام بررسی نهایی پیش از انتشار را بر عهده داشت.
محیط آزمایش برای جلوگیری از هرگونه نشت دادهها (Leakage) کاملاً کنترل شده بود. مدل در یک دایرکتوری کاری تازه (Fresh Working Directory) فعالیت میکرد؛ به طوری که هیچ دستورالعمل پروژهای در درخت دایرکتوری، هیچ فایل دستورالعمل در سطح کاربر و هیچ منبع تنظیماتی در دسترس نبود. حتی پس از اتمام اجرا، دایرکتوری حافظه (Memory Directory) بررسی شد تا اطمینان حاصل شود که خالی است.
هدف نهایی این بود که دقیقاً اندازهگیری شود یک مرحله بازبینی انسانی استاندارد، چه چیزهایی را از یک خروجی «منجمد» هوش مصنوعی حذف میکند. نویسنده پیش از شروع تولید متن، یک چکلیست ششگانه و تعریفی از «خطاهای بزرگ» و «خطاهای کوچک» تدوین کرد، اما این چکلیست در اختیار مدل نویسنده قرار نگرفت تا نتایج واقعی باشد.
نتایج: ۱۱ مورد شکست
مدل در مدت ۱۲ دقیقه، مقاله، سه نمودار، اسکریپتهای تولید آن نمودارها و یک صفحه خودارزیابی تولید کرد. در مرحله خودارزیابی، مدل تکههای کد بازتولید مقاله را اجرا کرد، خروجیها را مقایسه نمود و به صورت ماشینی تایید کرد که نقلقولهای منبع، خطبهخط با مواد اولیه مطابقت دارند. حتی در میانه مسیر، مدل یکی از ادعاهای غلط خود را شناسایی کرد و آن را به درستی بازنویسی نمود.
مدل همچنین توانست موضوع را به صورت خودکار محدود کند. در یادداشت اولیه پنج مورد ذکر شده بود، اما تنها چهار مورد دارای مستندات واقعی بودند. چون در مواد صراحتاً ذکر شده بود که «برای مورد پنجم هیچ لاگ اجرایی وجود ندارد»، هوش مصنوعی آن را در بخش «آنچه پوشش ندادم» قرار داد و هیچ عددی برای آن منتشر نکرد.
با وجود این دقتهای ظاهری، بازبینی انسانی ۱۱ خطا را در ۶ دسته یافت:
- تعمیم بیش از حد اندازهگیریها (۳ مورد): مدل ادعا کرد نتایج در دامنهای گستردهتر از آنچه دادهها نشان میدادند صادق است. این شامل نتیجهگیریهایی بود که فراتر از محدوده بررسی شده بود.
- خلط مفاهیم مشخصات، مشاهدات و استنتاجات (۳ مورد): مدل یک حدس را به عنوان واقعیت ارائه داد؛ مثلاً بر اساس یک دستور grep که هیچ نتیجهای برنگردانده بود، درباره علت وقوع یک اتفاق اظهار نظر قطعی کرد.
- تناقضات داخلی (۲ مورد): بخشهای مختلف متن با یکدیگر در تضاد بودند و با هم نمیخواندند.
- ناهماهنگی در ارجاعات (۲ مورد): منبع ذکر شده از ادعای مطرح شده پشتیبانی نمیکرد یا در برخی موارد اصلاً ارجاعی داده نشده بود.
- خطای عددی یا واقعی (۱ مورد): در یک تحلیل، مجموع دستهبندیها ۹۷۱ شد، در حالی که مدل عدد کل را ۹۷۳ اعلام کرده بود؛ دلیلش این بود که مدل چهار دسته اول را به عنوان کل مجموعه معرفی کرده بود.
- شکست در بازتولید (۰ مورد): تمام تکههای کد به درستی اجرا شدند و خروجی دادند.
نکته تکاندهنده این است که تمام ۱۶ عددی که از منبع اصلی وارد متن شده بودند، ۱۰۰٪ درست بودند. تکههای کد بازتولید شده حتی تا سطح آفست کاراکترهای استثنا (Exception Character Offset) دقیق بودند و نقلقولها در ۱۰ مورد از ۱۰ مورد با فایل واقعی مطابقت داشتند. یعنی مدل دچار «توهم» (Hallucination) — وقتی مدل با اطمینان چیزی میگوید که اصلاً وجود ندارد — به معنای سنتی نشد، بلکه دچار «ناپایداری در تعمیم» یا «ناپایداری گسترشی» شد؛ یعنی داخل دادهها دقیق بود، اما در تفسیر مرزهای آنها لغزید.
باگ تولیدی «نامرئی»
بحرانیترین یافته، شناسایی یک باگ واقعی بود که چهار ماه در یک ابزار عملیاتی وجود داشت. مقاله درباره حفاظی (Guard) بحث میکرد که کاراکترهای نامرئی را Escape میکند تا یک خط JSON توسط خواننده (Reader) شکسته نشود. هوش مصنوعی به درستی اشاره کرد که این حفاظ دو کاراکتر را مدیریت میکند.
اما نه مدل و نه نویسنده در ابتدا نپرسیدند که «اصلاً چند کاراکتر باید مدیریت شوند؟». در واقعیت، این کلاس مجموعهای از تقاطعِ «آنچه خواننده روی آن خط را میشکند» و «آنچه رمزگذار به صورت خام رها میکند» است. برای متدهای str.splitlines() و json.dumps(ensure_ascii=False)، این تقاطع دارای سه عضو است.
کاراکتر سوم چهار ماه بدون حفاظ مانده بود در حالی که تمام تستهای خودکار سبز بودند. این خطا یک «عدد غلط» در متن نبود، بلکه یک وضعیت «مهر و موم شده، احتمالاً» بود. تنها راه یافتن آن، شمارش اعضای کلاس بود؛ کاری که خارج از محدوده کد حفاظ قرار داشت. نویسنده در نهایت ابزار را اصلاح کرد و برای هر سه کاراکتر (به صورت تکی و ترکیبی) تستهای شکست (Red tests) نوشت تا پرونده بسته شود. این تجربه یادآور موردی است که در آن دو عامل هوش مصنوعی در برابر یک باگ بحرانی شکست خوردند و تنها بازبینی انسانی توانست نقص را شناسایی کند.
شکست مدلهای داور (AI Reviewers)
نویسنده برای سنجش قدرت مدلهای داور، متن نسخه A را سه بار در جلسات مجزا به یک مدل هوش مصنوعی خارجی داد. هر جلسه از همان مستندات استفاده کرد اما دسترسی به جلسات قبلی یا نسخه اصلاح شده نداشت:
- دور اول: ۳ یافته درست جدید، ۱ یافته غلط.
- دور دوم: ۴ یافته درست جدید، ۱ یافته غلط.
- دور سوم: ۴ یافته درست جدید، ۲ یافته غلط.
تعداد یافتههای درست هرگز به صفر نرسید، به این معنی که آزمایش به نقطه اشباع نرسید. اما نگرانکنندهتر، یافتههای غلط بود. یک ادعای خاص — مبنی بر اینکه یک توالی Escape در کد بدشکل است و در زمان اجرا باعث شکست میشود — چهار بار در جلسات مختلف تکرار شد. در دو مورد، هوش مصنوعی این را به عنوان یک «خطای واضح و قابل بازتولید» توصیف کرد.
برای تایید، نویسنده خط مورد نظر را به صورت بایت (Bytes) استخراج و اجرا کرد. تعداد بکاسلشها درست بود، هیچ کاراکتر جداکننده خامی وجود نداشت و عبارت به طور کامل اجرا شد. هوش مصنوعی داشت یک حالت شکست واقعی را توصیف میکرد، اما برای کدی که اصلاً در مقاله نبود! این نشان میدهد که احتمالاً در نحوه خواندن فایل توسط هوش مصنوعی، یک مرحله Unescaping رخ داده است. این یعنی توافق بین جلسات مختلف هوش مصنوعی و لحن مطمئن در بیان، هرگز دلیلی بر حقیقت نیست. این نقص در فرآیند تایید، اهمیت ثبت ردپای تصمیمات در هوش مصنوعی را دوچندان میکند تا از تکرار خطاهای سیستماتیک جلوگیری شود.
شکافهای عملیاتی
فراتر از چکلیست واقعی، نویسنده چهار شکست عملیاتی (Operational) را شناسایی کرد. اینها به عنوان شکست مدل شمرده نشدند چون قوانین آنها در Prompt نبودند:
- پرچم انتشار (Publish Flag) فعال مانده بود.
- یک شناسه خصوصی (Private Identifier) دو بار در متن ظاهر شد.
- افشای استفاده از هوش مصنوعی (AI-use disclosure) وجود نداشت.
- لینکی به نسخه مرجع (Canonical Version) داده نشده بود.
نویسنده اشاره میکند که اینها «گرانترین» اشتباهات هستند، زیرا هزینه آنها پس از انتشار برای ناشر ایجاد میشود، نه قبل از آن. این موارد به عنوان «دروازه عملیات» ثبت شدند، نه شکست در قابلیتهای مدل.
نقطه کور انسانی
شگفتانگیزترین بخش این است که خود نویسنده در اولین بازبینی، هیچکدام از این ۱۱ خطا را ندید. او تایید کرد که تمام ۱۶ عدد با مواد اولیه مطابقت دارند، اما هرگز بررسی نکرد که آیا مجموع اجزا با عدد کل همخوانی دارد یا خیر، و عبارت «دو کاراکتر را Escape میکند» را خواند بدون اینکه بپرسد اصلاً چند کاراکتر در آن کلاس وجود دارد.
دلیلش ساختاری بود: او در حال «بررسی» (تطبیق ادعا با متن) بود، نه «جستوجو» (یافتن شکاف بین متن و واقعیت). این یک حلقه بازخورد خطرناک است؛ وقتی انسان خطایی نمیبیند، فرض میکند متن کامل است، در حالی که فقط از همان منطق ناقصِ مدل برای بررسی استفاده کرده است.
هزینه اصلاح
حتی عمل اصلاح مقاله نیز خطاهای جدیدی ایجاد کرد. پس از اعمال ۱۱ اصلاحیه برای ایجاد «نسخه B»، نویسنده دوباره چکلیست را اجرا کرد. چون یکی از بخشها در حین اصلاح جابهجا شده بود، دو ارجاع به وضعیت قدیمی باقی مانده بود. حالا مقاله در دو جای مختلف ادعا میکرد که کد همزمان هم «محصون» است و هم «محصون نیست».
در نهایت، تراز نهایی ۱۱ به ۰ نبود، بلکه اینگونه بود: ۱۱ مورد در نسخه A شناسایی شد، ۰ مورد در نسخه B باقی ماند و ۱ مورد جدید در اثر فرآیند ویرایش ایجاد شد. این ثابت میکند که اگر فقط موارد حذف شده را بشمارید، آمار به نفع ویرایشگر جلوه میکند اما واقعیت را نمیپوشاند.
برای کسانی که جریانهای کاری مبتنی بر هوش مصنوعی را پیاده میکنند، درس این است: توافق بین جلسات AI دلیلی بر حقیقت نیست. اعتماد به لحن بیان، جایگزینی برای اجرای کد نیست. تنها بازبینی معتبر، بازبینیای است که کد را اجرا کند و بایتهای منبع اصلی را چک کند. نبودِ هشدار، به معنای نبودِ خطا نیست.
گام بعدی شما
- در بازبینی متون فنی، از استراتژی «جستوجو برای شکاف» به جای «تطبیق با متن» استفاده کنید.
- هرگز به توافق دو یا سه مدل مختلف برای تایید صحت یک کد یا عدد تکیه نکنید.
- برای هر ادعای فنی، یک تست اجرایی (Execution) بنویسید تا واقعیت را جایگزین احتمال کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو