تلهٔ دقتِ ساختگی؛ چرا عامل‌های هوش مصنوعی نتایجِ غلط اما متقاعدکننده می‌سازند؟

تصور کنید یک تحلیلگر داده با نتایجی روبه‌رو شود که ۶ برابر دقیق‌تر از ماه‌ها کار دستی است، اما تمام این موفقیت تنها یک خطای کوچک در کد باشد. این کابوسِ هر پژوهشگری است که اکنون با گسترش عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیارهای هوشمندی که می‌توانند به‌طور مستقل برنامه‌ریزی کنند و ابزارها را اجرا کنند — به یک ریسک سیستمی تبدیل شده است.

به گزارش جنید شاهد (Junaid Shahid)، یک توسعه‌دهنده، او با پدیده‌ای مواجه شد که در آمار به آن «نتیجه ۵-سیگما» می‌گویند؛ یعنی یافته‌ای چنان قوی که معمولاً نشانه یک کشف بزرگ است. اما در مورد او، این موفقیت خیره‌کننده صرفاً یک باگ «نگاه به آینده» (lookahead bug) در عامل پژوهشی‌اش بود. شاهد با جزئیات شرح داد که چگونه هوش مصنوعی نتیجه‌ای را ارائه کرد که شش برابر قوی‌تر از ماه‌ها تلاش دستی بود، اما در نهایت مشخص شد که عامل به‌طور تصادفی در حال خواندن فیلدهای داده‌ای مربوط به آینده بوده است.

این نوع شکست با توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — متفاوت است. وقتی یک مدل API خیالی می‌سازد، کد بلافاصله کرش می‌کند و خطا در چند ثانیه لو می‌رود. اما در شکست‌های «دقیق»، خروجی‌ها از نظر ریاضی کاملاً درست به نظر می‌رسند. همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، خطر اصلی زمانی است که سیستم برای «شبیه بودن به حقیقت» بهینه شود، نه خودِ حقیقت. برای رهبران کسب‌وکار و پژوهشگران، این یک ریسک پنهان ایجاد می‌کند که در آن عامل‌های AI به‌جای حقیقت، برای بهینه‌سازی «شکلِ دقت» تلاش می‌کنند. این موضوع با الگوهای شکست خاموشی که در آن عامل‌ها به‌طور نامحسوس اطلاعات نادرست ارائه می‌دهند هم‌راستا است.

زمینه: ماهیت شکست‌های عامل‌های هوشمند

شاهد به‌طور روزانه با عامل‌های کدنویس کار می‌کند. او اشاره می‌کند که شکست‌های «آسان» زمانی رخ می‌دهند که عامل یک API ساختگی را توهم بزند؛ در این حالت کد اجرا نمی‌شود و خطا سریعاً شناسایی می‌شود. اما حالت خطرناک، دقیقاً نقطه مقابل این است: عامل چیزی تولید می‌کند که سخت‌گیرانه و دقیق به نظر می‌رسد اما در واقع نیست. این نوع خطا می‌تواند باعث شود یک توسعه‌دهنده هفته‌ها تلاش بیهوده انجام دهد. برای درک بهتر این چالش‌ها، می‌توان به راهکارهای شناسایی نقاط شکست در عامل‌های هوشمند رجوع کرد تا متوجه شویم چگونه می‌توان این انحرافات را ردیابی کرد.

تجربه شاهد شامل دو شکست متمایز بود. اولین مورد، نتیجه‌ای بود که «بیش از حد خوب به نظر می‌رسید». او یک عامل پژوهشی مستقل ساخته بود که فرضیاتی را پیشنهاد می‌کرد، آن‌ها را با داده‌های تاریخی تست می‌کرد و با آمارهای پیش‌ثبت‌شده به آن‌ها امتیاز می‌داد. وقتی سیستم یک نتیجه ۵-سیگما ارائه کرد، واکنش شاهد به‌جای هیجان، شک بود. مشخص شد که عامل به فیلدی از داده‌ها دسترسی داشت که در آن مرحله از حلقه پردازش نباید به آن دسترسی می‌داشت. به محض رفع این نشت داده‌ای، آن «مزیت» (edge) به سرعت ناپدید شد و به نویز تبدیل گشت.

جزئیات: شکست دوم و فریبنده

ماه‌ها بعد، نتیجه دوم و متواضعانه‌تری ظاهر شد. این بار عدد کوچک و پذیرفتنی بود؛ از آن دست اعدادی که هر پژوهشگری در واقعیت باور می‌کرد. او برای تایید این نتیجه، سه بررسی مستقل را پیاده‌سازی کرد:

• کنترل جایگشت (Permutation Controls): جابه‌جایی برچسب‌ها برای اطمینان از اینکه اگر داده‌ها تصادفی شوند، نتیجه ناپدید می‌شود؛ که نتیجه واقعاً حذف شد.
• تفکیک داده‌های ذخیره (Holdout Split): استفاده از داده‌های کنار گذاشته شده‌ای که هرگز در طول فرآیند توسعه لمس نشده بودند؛ در اینجا نتیجه همچنان پابرجا بود.
• اعتبارسنجی سطح تیک (Tick-Level Validation): بازپخش داده‌ها در ریزترین سطح زمانی موجود (Tick) به‌جای اعتماد به کندل‌های کلی‌تر؛ نتیجه از این تست هم سربلند بیرون آمد.

با این حال، طبق اعلام شاهد، این نتیجه باز هم یک مصنوع (Artifact) و خطا بود. یک باگ خاص در حلقه اجرا وجود داشت: وقتی یک سفارش خرید با شکست مواجه می‌شد، حلقه به عقب برمی‌گشت و آن را در شرایطی دوباره امتحان می‌کرد که قبلاً فاش شده بود. هر معامله کمی خوش‌شانس‌تر از آنچه واقعیت اجازه می‌داد بود. این مقدار در هر معامله آن‌قدر کوچک بود که پذیرفتنی به نظر برسد، اما در طول هزاران معامله، آن‌قدر مداوم بود که شبیه به یک مزیت واقعی در بازار به نظر برسد.

تله‌ی اعتبارسنجی

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

شاهد خاطرنشان می‌کند که عامل‌های کدنویس در تولید کارهایی که ظاهرِ سخت‌گیرانه را تقلید می‌کنند، استثنایی هستند. آن‌ها تست‌هایی می‌سازند که پاس می‌شوند چون دقیقاً رفتار فعلی سیستم را تایید می‌کنند و بنچ‌مارک‌هایی می‌سازند که فقط چیزهای قابل اندازه‌گیری آسان را می‌سنجند. این به معنای عدم صداقت نیست؛ بلکه به این معناست که عامل در حال بهینه‌سازی برای هدفی است که کاربر به او داده است.

تغییرات عملیاتی برای توسعه هوش مصنوعی

برای مقابله با این وضعیت، شاهد سه تغییر عملیاتی را پیشنهاد می‌دهد:

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

در نهایت، او بر اهمیت انتشار «تکذیبیه‌های علمی» (Retractions) تاکید دارد. شاهد اخیراً نتیجه‌ای را منتشر کرد که عدد اصلی خودش را تضعیف می‌کرد و نشان داد که یک روش اکتشافی متاداده (Metadata Heuristic)، شکست‌ها را ۴ برابر بیشتر از تایید واقعی پیش‌بینی کرده است. او معتقد است این کار باعث می‌شود کارهای اصلی معتبرتر شوند، زیرا نشان می‌دهد که آن‌ها از یک حمله واقعی جان سالم در بر آمده‌اند.

او از آن زمان ابزارها و تکذیبیه‌های خود را در github.com/junaidshahid-dev به‌صورت متن‌باز منتشر کرده است تا نشان دهد چگونه ابزارهای حسابرسی نیز می‌توانند مثبت کاذب تولید کنند. این تغییر دیدگاه، پرسش حیاتی را از «آیا عامل درست عمل کرد؟» به این تغییر می‌دهد: «اگر این نتیجه غلط بود، چه شکلی می‌شد و آیا بررسی‌های من قادر به تشخیص آن بودند؟»

گام بعدی شما

• اگر از عامل‌های AI برای تحلیل داده استفاده می‌کنید، یک مسیر اعتبارسنجی (Validation Path) بسازید که هیچ دسترسی مشترکی با کد تولیدی عامل نداشته باشد.
• نتایج با دقت غیرعادی را ابتدا با متد «تخریب عمدی داده‌ها» تست کنید تا ببینید آیا نتیجه به طور غیرطبیعی پایدار است یا خیر.
• معیارهای موفقیت پروژه خود را پیش از اجرای مدل در یک سند ثابت ثبت کنید تا دچار سوگیری تایید نشوید.

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