اگر امروز برای تولید مستندات فنی یا وبلاگهای تخصصی به هوش مصنوعی تکیه میکنید، احتمالاً با متونی روبرو هستید که با اعتمادبهنفس کامل، دروغ میگویند. طبق یک بازرسی جامع که در ۲۷ اوت ۲۰۲۶ منتشر شد، ۸۶٪ از مقالات فنی تولیدشده توسط هوش مصنوعی حاوی حداقل یک ادعای اولشخص ساختگی هستند.
این مطالعه روی ۵۸ مقاله انجام شد و ۱۳۵ مورد جعل تاییدشده در ۵۰ مقاله شناسایی کرد. این نتایج ثابت میکند که مدلهای زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — برای اینکه متقاعدکنندهتر به نظر برسند، جزئیات فنی را از خود ابداع میکنند.
این کشف در حالی رخ میدهد که توسعهدهندگان بیشتری برای خودکارسازی وبلاگنویسی فنی و مستندسازی از هوش مصنوعی استفاده میکنند. در حالی که AI در روایتهای کلی موفق است، اما در مواجهه با «دادههای مرجع» (Ground Truth) یک کدبیس خاص شکست میخورد. برای بسیاری، خطر اصلی فرسایش تدریجی اعتماد است؛ خواننده شاید متوجه یک برچسب زمانی جعلی نشود، اما وقتی متوجه شود اتوماسیونی که مدل ادعا کرده اصلاً وجود ندارد، اعتمادش را از دست میدهد. این چالش با یافتههای اخیر دربارهی اتلاف زمان در بازبینی محتوای AI همسو است که نشان میدهد بهرهوری ظاهری این ابزارها اغلب با نیاز به بازبینیهای گسترده خنثی میشود.
بستر بررسی و فرآیند بازرسی
این بازرسی روی یک خط لوله انتشار متمرکز بود که برای سه سایت دایرکتوری یعنی aiappdex.com، findgameslike.com و openalternativeto.com استفاده میشد. این سامانه مقالاتی را با لحن اولشخص تولید میکرد تا تصمیمات واقعی توسعه را توصیف کند.
مشکل زمانی شروع شد که «توصیف تصمیمات واقعی» با «توصیف آنچه واقعاً رخ داده» فاصله گرفت. همانطور که در تحلیلهای قبلی ما دربارهی توهمات مدلهای زبانی اشاره کردیم، جعلها در روایتهای کلی نبودند، بلکه در جزئیات ریز — مانند آستانههای دقیق یا ابزارهای خاص اتوماسیون که یک مشکل را شناسایی کردهاند — رخ میدادند تا داستان معتبرتر به نظر برسد.
این گزارش در واقع کالبدشکافی یک شکست است، نه یک داستان موفقیت. بازرسی که در ۲۶ اوت ۲۰۲۶ انجام شد، نشان داد مدل بهجای تکیه بر دادههای واقعی، در حال تقلید از الگوهای رایج در ژانر مقالات فنی است. این اتفاق باعث ایجاد محتوایی شد که «ضخامت» و ظاهر حرفهای داشت اما اساساً متقلبانه بود. این نوع تولید محتوای توخالی، دقیقاً همان چیزی است که برخی منتقدان آن را به عنوان «محتوای بیارزش» یا Slop تعریف میکنند، هرچند بحث بر سر مرز بین کمک AI و تنبلی فکری همچنان ادامه دارد.
کالبدشکافی جعلهای هوش مصنوعی
به نقل از این گزارش، جعلها تصادفی نبودند. مدل روی «شکافهای ساختاری» هدف گرفته بود که از میلیونها پست فنی یاد گرفته بود. مدل میداند یک داستان فنی باکیفیت معمولاً شامل بیان مشکل، روش کشف (اغلب از طریق اتوماسیون)، راهکار، اندازهگیری و بازتاب است.
وقتی مدل جزئیات یک پروژه خاص را ندارد، این جای خالی را با ابداعات محتمل پر میکند. مدل نمیداند که یک خط لوله خاص، مانیتورینگ ساعت ۳ صبح ندارد؛ فقط میداند مقالات «خوب» معمولاً چنین چیزی دارند. بازرسی چهار دسته اصلی از جعلها را شناسایی کرد:
- اتوماسیون ابداعی: ادعاهایی مثل «مانیتورینگ ساعت ۳ صبح خطا را گرفت»، در حالی که در واقعیت، نویسنده اغلب روزها بعد و بهصورت دستی از طریق خواندن مستقیم لاگها متوجه مشکل شده بود.
- تاریخچه نسخههای جعلی: جملاتی که ادعا میکردند «در نسخههای قبلی از X استفاده میکردم تا اینکه به Y تغییرش دادم». این ادعاها با استفاده از دستور
git log -S Xرد شدند تا ثابت شود آن تکنولوژی هرگز در مخزن کد وجود نداشته است. - اعداد متورم: ابداع ارقامی دقیق، مانند ادعای «کاهش ۴۰ درصدی نرخ خطا» بدون داشتن هیچ منبع اندازهگیری قابل تایید.
- آستانههای ساختگی: ذکر محدودیتهای فنی خاص، مثل «زیر آستانه ۵۰ میلیثانیه»، که هرگز در کد تعریف یا پیادهسازی نشده بود.
چرخه اصلاح و چالشهای همگامسازی
اصلاح این خطاها پیچیدهتر از یک جایگزینی ساده بود. فرآیند پاکسازی در سه مرحله انجام شد تا مجموعه دادهها کاملاً تمیز شوند. مرحله اول شامل ۱۳۵ ویرایش در ۵۰ فایل markdown بود که با کامیت 096462b ثبت شد. اگرچه ابزار Codex در یک بررسی مستقل اینها را شناس کرد، اما نویسنده مجبور شد هر مورد را با لاگهای git یا کد واقعی تطبیق دهد.
با این حال، یک شکاف همگامسازی وجود داشت. اصلاح مخزن محلی بهطور خودکار پلتفرمهای زنده را بهروز نمیکرد. هر خوانندهای که مقالات را در Dev.to بین زمان انتشار و زمان کامیت میخواند، ادعاهای جعلی را میدید. برای حل این مشکل، اسکریپت scripts/devto-sync-corrections.mjs نوشته شد. این اسکریپت مقالات منتشر شده را صفحهبندی میکند، یک نقشه از URL به ID میسازد، لینکهای داخلی نسبی را به URLهای مطلق تبدیل میکند و متنهای اصلاحشده را از طریق متد PUT ارسال میکند.
سپس مشکلات درجه دوم ظاهر شدند. پنج اصلاح در دور اول، باعث ایجاد نادقتیهای جدید شدند (کامیت 79cc029). در واقع هنگام اعمال ۱۳۵ تغییر، برخی بازنویسیها با بخشهای دیگر همان مقاله در تضاد قرار گرفتند. در نهایت، مشکل درجه سوم (کامیت cd8364d) رخ داد که در آن اصلاحات باعث ایجاد برچسبهای زمانی غیرممکن و یک بخش FAQ شد که با متن اصلاحشدهی بدنه مقاله در تضاد بود.
پیادهسازی «دروازه حقیقت»
برای جلوگیری از جعلهای آینده، در ۲۶ اوت ۲۰۲۶ سیستمی به نام «دروازه حقیقت» (Truth Gate) در مشخصات تولید محتوا پیاده شد. این سامانه الزام میکند هر ادعای اولشخص — مانند «من X را ساختم/اجرا کردم/اندازهگیری کردم/اصلاح کردم»، «این روی یک cron اجرا میشود» یا «مانیتورینگ آن را گرفت» — باید قبل از نوشته شدن، با مخزن کد تایید شود.
این تایید از طریق قرارداد کیفیت quality_contract v2 اجرا میشود که دو فیلد اجباری به متادیتای مقاله اضافه میکند:
۱. verified_at: برچسب زمانی که ثابت میکند تایید واقعاً انجام شده است، نه اینکه فقط قصد انجام آن بوده باشد.
۲. original_evidence: ارجاع به فایل، کامیت یا مجموعه دادهای خاص که هر ادعا را تولید کرده است.
اگر ادعایی توسط کامیت یا لاگ پشتیبانی نشود، حذف میشود. همچنین یک مرحله خودارزیابی نهایی اضافه شد: نویسنده باید تمام ادعاهای واقعی پیشنویس را لیست کرده و دوباره تایید کند. این فرآیند سرعت تولید را بهشدت کاهش میدهد — یک مقاله ۱۵۰۰ کلمهای با ۸ ادعا اکنون به ۸ مرحله تایید مجزا نیاز دارد — اما توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی میگوید که اصلاً وجود ندارد، مثل دوستی که خاطرهای را اشتباه تعریف میکند — ساختاری را حذف میکند.
نقاط کور باقیمانده
با وجود دروازه حقیقت، سه شکاف همچنان باقی است. اول، ادعاهای مربوط به رفتار آینده (مثلاً «این هر شب اجرا خواهد شد» یا «نسخه بعدی شامل X خواهد بود») در زمان نوشتن قابل رد کردن نیستند و از دروازه عبور میکنند.
دوم، ادعاهای مبهم و محتاطانه مثل «متوجه شدم عملکرد به نظر میرسد بهبود یافته است» چون عدد مشخصی ندارند، از فیلتر رد میشوند. اینها باعث ایجاد یک اعتمادبهنفس کلی و کاذب میشوند که شناساییاش سختتر از یک عدد جعلی است.
در نهایت، محتوای قدیمی همچنان ریسک است. در حالی که ۵۰ مقاله بازرسیشده اصلاح شدند، محتوای منتشر شده قبل از ژوئن ۲۰۲۶ بهطور سیستماتیک بازرسی نشده است. همچنین بهدلیل تفاوت در معناشناسی بهروزرسانی در APIهای Hashnode، نسخههای این پلتفرم هنوز متنهای پیش از اصلاح را نمایش میدهند.
تحلیل تعاملات و نتیجهگیری
نکته جالب این است که دادههای تعامل نشان داد مقالاتی که بیشترین کامنت را داشتند، آنهایی بودند که جزئیاتشان دقیق و قابل تایید بود، نه مقالاتی با روایتهای دراماتیک و جعلی از اتوماسیون. این الگو حتی قبل از شروع بازرسی نیز برقرار بود.
این تغییر در رفتار کاربران نشان میدهد که «لحن مقتدرانه» هوش مصنوعی اغلب ماسکی برای دادههای مفقود است. مدل بخشهایی از روایت را هدف قرار میدهد که سیگنال تخصص میفرستند تا نوشته حرفهای به نظر برسد. برای توسعهدهندگان درس روشن است: هرچه یک ادعای فنی تولیدشده با AI دقیقتر به نظر برسد، احتمال توهم ساختاری آن بیشتر است، مگر اینکه به یک کامیت در git متصل باشد.
گام بعدی شما
- هر ادعای عددی یا فنی در متون تولیدشده توسط AI را با دستور
git logیا بررسی مستقیم کد تایید کنید. - برای تولید مستندات، از مدلها بخواهید بهجای ابداع جزئیات، جای خالی (Placeholder) بگذارند تا شما داده واقعی را جایگزین کنید.
- در صورت استفاده از AI برای وبلاگنویسی، یک چکلیست تاییدیه (Verification Log) برای هر مقاله ایجاد کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو