تطابق شناسه‌ی مدل با خروجی ثابت نیست؛ شکافی خطرناک در حاکمیت هوش مصنوعی

تصور کنید برای یک سیستم حساس، قفلی سخت‌افزاری تعریف کرده‌اید تا مطمئن شوید هر بار یک نتیجه‌ی یکسان می‌گیرید، اما ناگهان متوجه می‌شوید قفل سر جای خود است ولی کلید درون آن تغییر شکل داده است. این دقیقاً همان بحرانی است که یک توسعه‌دهنده در چارچوب AIEOS با آن مواجه شد: شناسه‌ی مدل ثابت بود، اما رفتار مدل تغییر کرده بود.

به نقل از یک پست فنی مفصل در ۲۳ سپتامبر ۲۰۲۶، این توسعه‌دهنده فاش کرد که چگونه سه لایه بررسی سیستمی به‌طور هم‌زمان شکست خوردند؛ زیرا این سیستم‌ها به‌جای بررسی «تازگی» و «صحت» خروجی، صرفاً «هویت» مدل را تأیید می‌کردند. این اتفاق یک ریسک سیستمی را در محیط‌های عملیاتی آشکار می‌کند: این فرض غلط که یک رشته‌ی متنی ثابت برای نسخه‌ی مدل، به معنای خروجی ثابت است.

همان‌طور که در تحلیل قبلی ما درباره‌ی جایگزینی مدل‌های پرچم‌دار توسط مدل‌های سبک‌تر (مانند مورد DeepSeek) اشاره کردیم، صنعت اکنون با پدیده‌ای روبروست که در آن «هوش» زیربنایی یک مدل می‌تواند تغییر کند، حتی اگر برچسب API بدون تغییر باقی بماند.

شکست «قفل کالیبراسیون»

این توسعه‌دهنده از یک «قفل کالیبراسیون» استفاده می‌کرد تا مطمئن شود یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در نقش داور، همواره با داده‌های مرجع انسانی (Gold Set) سازگار باشد. این رویکرد تداعی‌کننده تلاش‌های اخیر برای ایجاد ساختارهای کنترلی است، مشابه آنچه در راهکار قفل هش اوراکل برای جلوگیری از تقلب عامل‌های هوش مصنوعی مشاهده کردیم تا از تغییرات غیرمنتظره در نتایج جلوگیری شود. این بررسی برای سرعت بالا و قطعیت (Determinism) طراحی شده بود و صرفاً از یک مقایسه‌ی رشته‌ای ساده بین هشِ پرامپت و شناسه‌ی مدل استفاده می‌کرد. این روش باعث می‌شد سیستم نیازی به دسترسی به شبکه یا انجام عملیات استنتاج (Inference) — یعنی همان لحظه‌ی آشپزی و تولید جواب توسط مدل — نداشته باشد و دقیقاً به هدف طراحی خود یعنی سرعت و قطعیت دست یابد.

طبق گزارش این توسعه‌دهنده، در ۱۶ اوت، نرخ توافق داور ۰.۸۳۹۳ بود، سه مورد «پاس کاذب» (False Pass) ثبت شد و مقدار کاپا (Kappa) برابر با ۰.۲۷۶ بود. اما تا ۳۰ اوت، با وجود استفاده از دقیقاً همان هش پرامپت (b9b8903)، همان شناسه‌ی مدل تثبیت‌شده و همان ۱۲ مورد داده‌ی مرجع، نتایج تغییر کرد: نرخ توافق به ۰.۸۶۳۱ رسید، تعداد پاس‌های کاذب به دو مورد کاهش یافت و مقدار کاپا به ۰.۳۵۳ افزایش یافت.

چون هش پرامپت و شناسه‌ی مدل تغییر نکرده بود، خط لوله‌ی CI/CD وضعیت را «پاس» اعلام کرد؛ سیستم بررسی می‌کرد که آیا قفل همان قفل قبلی است، نه اینکه آیا داورِ پشت قفل جابه‌جا شده است. همان‌طور که توسعه‌دهنده اشاره کرد، این «نابینایی» در واقع ناشی از شکل و ساختار خودِ این بررسی بود.

شواهد رانش در سمت سرور

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

• واریانس کوتاه‌مدت: دو اجرای یکسان که با فاصله ۳۴ دقیقه انجام شده بودند، دقیقاً در دو سلول (۱.۲٪ از ۱۶۸ سلول) با هم اختلاف داشتند. نکته‌ی حیاتی این بود که در هر بار تکرار، دقیقاً همان دو سلول بودند که خطا داشتند.
• واریانس بلندمدت: اختلاف بین ۱۶ اوت و ۳۰ اوت، حداقل سه برابر گسترده‌تر بود و حداقل ۲۲ مورد از ۵۰۴ مشاهده (بیش از ۴.۴٪) را تحت تأثیر قرار داده بود.

برای رد کردن سایر احتمالات، توسعه‌دهنده متغیرهای زیر را بازرسی (Audit) کرد:

• تغییرات پرامپت (هش‌ها کاملاً یکسان بودند)
• اصلاحات کد (یک اصلاحیه ۱۹ دقیقه پیش از اولین اجرا ادغام شده بود)
• رانش در مشخصات، قالب‌ها یا فیکسچرها (که با استفاده از sha-pin در هنگام بارگذاری تأیید شده بودند)
• نسخه‌های SDK، شناسه‌ی مدل و تنظیمات دمای مدل (Temperature)

با رد شدن تمام این موارد، تنها توضیح منطقی باقی‌مانده، «حرکت در سمت سرور» (Server-side movement) تحت یک شناسه‌ی مدل تثبیت‌شده بود. اگرچه توسعه‌دهنده اشاره کرد که داور همچنان در حال کار بود — و شکست‌ها به یک نیاز ساختگی و یک خطای ارتفاع در پرامپت بازمی‌گشت — اما قفل کالیبراسیون قادر به شناسایی این تغییر زیربنایی نبود. این چالش در اعتبارسنجی خروجی‌ها، شباهت زیادی به پیچیدگی‌های مقایسه ژورنال‌ها برای شناسایی جعل در تست‌های ویژگی دارد که در آن جزئیات رفتاری بر شناسه‌های ظاهری اولویت می‌یابند.

توهمِ نقشه‌ی راه «فعال»

این الگوی «هویت در مقابل حقیقت» فراتر از کدها و به حاکمیت پروژه نیز سرایت کرده بود. در نقشه‌ی راه AIEOS، یک جدول وضعیت و یک فیلد «آخرین به‌روزرسانی» وجود داشت. در ۳۰ اوت، این فیلد ادعا می‌کرد که نقشه‌ی راه تا ۱۶ اوت به‌روز است. با این حال، جدول به‌طور عینی غلط بود: این جدول توسعه‌دهنده را به تعریف محدوده‌ی نسخه‌ای هدایت می‌کرد که هفت هفته پیش منتشر شده بود و یک مانع (Blocker) با اولویت بالا را لیست کرده بود که پیش از آن ابطال شده بود.

یک ابتکار خاص در جدول با برچسب «فعال» (Active) علامت‌گذاری شده بود. با وجود این برچسب و توصیفات مفصل از چهار مورد تکمیل‌شده — که آن‌قدر متقاعدکننده بودند که برای ماه‌ها باور شوند — جست‌وجو در ۴۱ مخزن کد نشان داد که هیچ اثر یا فایلی (Artifact) از این پروژه وجود ندارد.

شبح در ماشین

«مدرک» وجود این پروژه‌ی فعال، در واقع توهمی بود که توسط نتایج جست‌وجو ایجاد شده بود. شناسه‌ی پروژه (SAD-SEARCH-001) به یک شناسه‌ی نمونه در یک مجموعه‌ی تست و یک docstring برای فایلی تبدیل شده بود که هرگز وجود خارجی نداشت. دستور grep برای این شناسه، نتایجی برمی‌گرداند که شبیه به «نشانه حیات» بود، اما در واقع هیچ کامیت (Commit) واقعی پشت آن ردیف «فعال» وجود نداشت.

شکاف حاکمیتی و راهکارها

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

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

برای پر کردن این شکاف بین «پرسیدن درباره‌ی یکسانی» و «پرسیدن درباره‌ی حقیقت»، توسعه‌دهنده سه مکانیسم «ساده اما ضروری» پیشنهاد می‌کند:

• انقضای زمانی (Time-based Expiry): قفل‌های کالیبراسیون باید بعد از N روز به‌طور خودکار بسته شوند (Fail Closed) تا به‌جای تأیید بر اساس یک رشته‌ی متنی، بازبینی مجدد اجباری شود.
• بررسی‌های رانش ماشه‌ای (Triggered Drift Checks): پیاده‌سازی بررسی‌هایی که بر اساس یک محرک خاص اجرا شوند، نه اینکه صرفاً به قصد و اراده‌ی توسعه‌دهنده برای اجرای آن‌ها تکیه کنند.
• وضعیت متصل به کامیت (Commit-Linked Status): وضع قانونی که به‌طور خودکار هر ردیفی با وضعیت «فعال» را که فاقد کامیت‌های متناظر در مخزن است، علامت‌گذاری (Flag) کند.

در آینده باید منتظر ظهور ابزارهای CI/CD «آگاه به رانش» (Drift-aware) باشیم که از تثبیت نسخه‌ها فراتر رفته و به سمت اعتبارسنجی رفتاری مستمر حرکت کنند.

گام بعدی شما

• اگر از مدل‌های API با شناسه‌ی ثابت استفاده می‌کنید، یک تست دوره‌ای (Periodic Benchmark) برای خروجی‌ها تعریف کنید تا رانش مدل را شناسایی کنید.
• در سیستم‌های CI/CD خود، به‌جای تکیه بر Version String، از تست‌های رفتاری (Behavioral Tests) استفاده کنید.
• مستندات پروژه‌های AI خود را با کد واقعی تطبیق دهید تا از «پروژه‌های شبح» جلوگیری کنید.

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