اگر حس میکنید مدلهای پیشرفتهای مثل Claude چند هفته پس از عرضه «احمقتر» شدهاند، حالا میتوانید این ادعا را با ریاضیات ثابت کنید. ابزار متنباز livenerf که در ۲۹ سپتامبر ۲۰۲۶ عرضه شد، به کاربران اجازه میدهد بهطور ریاضی ثابت کنند که آیا یک مدل پیشرو در حال «نرف شدن» (Nerfing) است یا خیر؛ یعنی آیا قابلیتهای آن پس از عرضه رسمی بهطور پنهانی کاهش یافته است.
سالهاست که جامعه هوش مصنوعی بحث میکند که آیا آزمایشگاهها برای کاهش هزینههای محاسباتی، از روشهایی مثل کوانتیزاسیون (Quantization) — شبیه به کاهش کیفیت یک عکس برای کم کردن حجم آن — یا تغییرات در مسیریابی (Routing) یا حتی جایگزینی مدلهای کوچکتر در پشت نامهای قدیمی استفاده میکنند یا خیر. احتمال دیگر این است که هیچ اتفاقی نیفتاده باشد و کاربران صرفاً در حال تطبیق الگوها روی نویزهای تصادفی باشند. تا پیش از این، تمام این استدلالها بر اساس «حس کاربر» (Vibes) بود، چون کاربران فاقد یک خط مبنای پاک و دقیق در روز صفر (Day-Zero Baseline) برای اندازهگیری بودند. livenerf با فعال کردن یک ساعت زمانسنج قطعی در لحظه انتشار مدل، این بازی را تغییر میدهد.
همانطور که در تحلیلهای قبلی ما دربارهی پایداری مدلهای زبانی اشاره کردیم، تغییر در خروجیها همیشه به معنای افت هوش نیست و گاهی ناشی از تغییرات زیرساختی است. اما اندازهگیری این تغییرات در مدلهای زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — بهشدت دشوار است، چون پارامترهای نمونهگیری اغلب مخفی هستند و فرآیندهای «تفکر» (Thinking) مدل را نمیتوان غیرفعال کرد.
نبرد با عدم قطعیت
برای حل این مشکل، livenerf تمام متغیرهای محیطی را منجمد میکند. طبق مستندات این پروژه، ابزار مذکور از نسخههای ثابت CLI، پرامپتهای تغییرناپذیر و ارزیابهای دقیق استفاده میکند تا مطمئن شود هر تغییر در خروجی، مستقیماً مربوط به خودِ مدل است، نه ابزار اندازهگیری (Harness).
این سامانه بر پایه Inspect (چارچوب ارزیابی متنباز مؤسسه امنیت هوش مصنوعی بریتانیا) ساخته شده است. همچنین برای تضمین دقت ریاضی، استانداردهای آماری مربوط به «نوارهای خطا» (Error Bars) را که توسط Anthropic در مقاله "Adding Error Bars to Evals" معرفی شده بود، پیادهسازی کرده است تا نتایج بهجای روشهای تجربی ساده، از نظر ریاضی دقیق باشند.
جزئیات پیادهسازی و ساختار
livenerf بهگونهای طراحی شده که یک بنچمارک کوچک، خستهکننده و «فقط-افزودنی» (Append-only) باشد. هدف آن تمرکز بر یک سؤال واحد است: آیا مدل پس از عرضه ضعیفتر میشود؟ برای دستیابی به این هدف، ابزار یک ساختار فراخوانی «هرمتیک» یا کاملاً ایزوله را پیاده میکند. هر درخواست از یک پرامپت سیستمی کوتاه و منجمد استفاده میکند که هیچ ابزاری (Tools)، هیچ سرور MCP، هیچ تنظیمات یا هوک (Hook)، هیچ فایل CLAUDE.md یا حافظهای ندارد و در یک دایرکتوری کاری خالی و ثابت اجرا میشود. اگر هر چیز دیگری بارگذاری شود، سیستم آن را به عنوان یک باگ تلقی میکند.
در وظایف مبتنی بر کد، ارزیابی کاملاً خارج از مدل انجام میشود. مدل کد را به صورت متن برمیگرداند و ابزار ارزیابی، تستهای مخفی را در یک محیط ایزوله (Sandbox) اجرا میکند. این یعنی مدل هرگز کد خود را اجرا نمیکند و یکی از منابع اصلی تغییرپذیری حذف میشود. همچنین، میزان «تلاش» (Effort) همیشه بهطور صریح به مدل پاس داده میشود و هرگز روی تنظیمات پیشفرض رها نمیشود.
زیرساخت فنی و کنترل محیط
برای حفظ این سطح از کنترل، ابزار به محیط خاصی نیاز دارد: پایتون ۳.۱۱ به بالا، ابزار uv و یک نصب Claude Code که وارد حساب کاربری شده باشد. در حالی که این ابزار حول محور اشتراک Max ساخته شده، با هر چیزی که بتواند دستور claude -p را اجرا کند سازگار است و روی لینوکس، مک و ویندوز کار میکند.
پروایدر یک فراخوانی هرمتیک claude -p را پوشش میدهد تا Inspect بتواند با اشتراک Max مانند یک API استاندارد مدل رفتار کند. برای جلوگیری از تغییر در ابزار اندازهگیری، کاربران باید بهروزرسانیهای خودکار را از طریق دستور export DISABLE_AUTOUPDATER=1 (و با افزودن آن به فایل ~/.claude/settings.json) غیرفعال کرده و نسخه CLI را پین کنند. اجراکننده (Runner) بهگونهای طراحی شده که اگر خروجی claude --version با فایل نسخه پینشده همخوانی نداشته باشد، از اجرا خودداری کند.
برای محافظت بیشتر از محیط، به کاربران توصیه شده است که یک کپی از باینری پینشده را در جایی نگه دارند که بهروزرسان به آن دسترسی نداشته باشد، مانند مسیر ~/.local/share/livenerf/. ابزار بهطور خودکار یا از طریق متغیر محیطی LIVENERF_CLAUDE_CLI از این کپی استفاده میکند.
مکانیزم عملکرد بنچمارک
livenerf توکنها را روی سؤالاتی که مدل همیشه درست یا همیشه غلط جواب میدهد، هدر نمیدهد. در عوض، از یک مرحله کالیبراسیون برای یافتن سؤالات «اطلاعاتبخش» استفاده میکند؛ یعنی سؤالاتی که مدل فقط در برخی موارد به آنها پاسخ درست میدهد. طبق یک مدل رایج «تغییر لوجیت» (Logit-shift)، سؤالی با نرخ موفقیت p، در هر نمونه مقدار p(1−p) اطلاعات جابهجا میکند.
پنل ارزیابی و انتخاب:
- پنل: برای اجرای فعلی روی Claude Opus 5.5، ابزار ۲۳۳۶ سؤال از منابع GPQA Diamond، MMLU-Pro، competition-math و AIME 2025–26 را غربال کرد. هر سؤال با ۴ نمونه تست شد.
- انتخاب: مدل Opus 5.5 حدود ۹۳٪ سؤالات را در تلاش اول درست جواب داد. ۹۷٪ سؤالات یا همیشه درست بودند یا همیشه غلط. ابزار ۷۸ سؤال را شناسایی کرد که «گاهی درست» بودند و اینها پنل کالیبره شده را تشکیل دادند.
- سوگیری انتخاب: پروژه سوگیری انتخاب را اندازهگیری کرد؛ سؤالاتی که به دلیل «گاهی درست بودن» انتخاب شده بودند، به نظر میرسید نرخ موفقیتشان نزدیک به ۵۰/۵۰ است، اما در نمونههای تازه، نرخ موفقیت آنها از ۵۴.۷٪ به ۶۲۰٪ افزایش یافت و محاسبات توان (Power Calculation) از این نرخهای تازه استفاده میکند.
- حسایت: یک حسابرسی گزارشمحور روی ۷۸ سؤال (به علاوه ۲ سؤال که بعداً حذف شدند) نشان داد که ۸ کلید پاسخ غلط و ۳۰ سؤال مبهم وجود دارد. هیچکدام حذف نشدند، اما یک تحلیل حساسیت پیشثبتشده، نتایج را بدون آنها مجدداً اجرا میکند.
زمانبندی و شناسایی افت کیفیت
- خط مبنا: دادههای ۱۰ روز اول به عنوان «خط مبنای هفته عرضه» در نظر گرفته میشوند.
- پنجرهها: پس از خط مبنا، دو پنجره ۱۰ روزه وجود دارد. یک تغییر تنها زمانی «تغییر» نامیده میشود که بازه اطمینان ۹۹٪ در دو پنجره ۱۰ روزه متوالی، عدد صفر را شامل نشود، اثر آن حداقل ۳ امتیاز باشد و بازوی کنترل (Control Arm) همان حرکت را نشان ندهد.
- جدول زمانی: روز اول ۲۴ سپتامبر ۲۰۲۶ ساعت ۲۲:۱۰ UTC بود (تقریباً ۲.۵ روز پس از عرضه ۲۲ سپتامبر). اولین امکان اعلام نتیجه حدود ۲۴ اکتبر ۲۰۲۶ است و اولین ردیف نتایج پس از روز بیستم ثبت میشود.
تفاوت «تلاش کمتر» و «هوش کمتر»
یکی از کلیدیترین بخشهای طراحی livenerf، تفکیک میان صحت پاسخ و میزان تلاش مدل است. این ابزار تعداد توکنهای خروجی را به عنوان سیگنال اصلی رصد میکند، زیرا مدلی که «کمتر فکر میکند»، اغلب پیش از آنکه دقتش واقعاً افت کند، کاهش توکنها را نشان میدهد.
طبق دادههای اعتبارسنجی پروژه، «تلاش کم» (Low Effort) به صورت کاهش ۶۲ درصدی در توکنهای خروجی و افت ۸.۳ ± ۴.۵ امتیازی در دقت ظاهر میشود. در مقابل، «تلاش متوسط» (Medium Effort) منجر به کاهش ۲۶ درصدی توکنها و افت ۴.۲ ± ۳.۹ امتیازی در دقت میشود.
حفاظهای سختگیرانه برای جلوگیری از خطای مثبت
برای جلوگیری از مثبت کاذب (False Positives)، livenerf از کنترلهای سختگیرانه زیر استفاده میکند:
- بازوی کنترل: مدل Claude Opus 5 هر روز با همان ساختار و با استفاده از سؤالات GPQA تست میشود. اگر هر دو مدل همزمان حرکت کنند، مشکل احتمالاً از پلتفرم یا ابزار اندازهگیری است، نه نرف شدن یک مدل خاص.
- پیشثبت (Pre-registration): برنامه اندازهگیری، قوانین تصمیمگیری و معیارها پیش از شروع جمعآوری دادهها با یک برچسب زمانی عمومی در گیتهاب ثبت شدهاند. این کار از «p-hacking» یا تغییر قوانین برای تطبیق با نتایج جلوگیری میکند. این مورد شامل رویه انتخاب آیتمها و لیست معیارهای ثانویه است.
- محافظ بودجه: برای جلوگیری از تداخل با استفاده عادی، ابزار درصد مصرف هفتگی و پنجساعته را از طریق
python -m livenerf.usageمیخواند. اگر مصرف هفتگی ≥ ۷۵٪ یا مصرف ۵ ساعته ≥ ۶۰٪ باشد، تلاش برای تست نادیده گرفته شده و هر ساعت مجدداً تلاش میکند تا اجرای روزانه کامل شود. - پین کردن CLI: کاربران باید بهروزرسانیهای خودکار را غیرفعال کنند (
export DISABLE_AUTOUPDATER=1) و نسخه CLI را پین کنند، زیرا تغییر در ابزار اندازهگیری دقیقاً شبیه به تغییر در مدل به نظر میرسد.
وضعیت فعلی و محدودیتها
تا ۲۹ سپتامبر ۲۰۲۶، این سری فعال است. ۶ روز از ۳۰ روز جمعآوری شده است (۶ روز از ۱۰ روز خط مبنا) و هیچ روزی از دست نرفته است. تمام ۶ روز، ۹۰ نمونه کامل را روی یک هش محیطی یکسان (461391b6fce64167) و نسخه پینشده CLI (2.1.280) اجرا کردند. روز پنجم نیاز به نادیده گرفتن محافظ بودجه داشت که در لاگ انحرافات ثبت شده است.
با این حال، ابزار محدودیتهایی دارد. تستهای اعتبارسنجی نشان داد که جایگزینی Opus 5.5 با Opus 5 در حجم نمونههای یک اعتبارسنجی واحد، از نظر آماری در سطح ۹۹٪ قابل تشخیص نبود (−۳.۸ ± ۶.۳ امتیاز، ۲۳٪- توکن). اگرچه یک پنجره ۱۰ روزه ۲.۵ برابر نمونه بیشتری دارد، اما هنوز ثابت نشده که برای شناسایی جایگزینی مدلهای همخانواده در این ابعاد کافی باشد.
معنای این ابزار برای صنعت هوش مصنوعی
برای صنعت هوش مصنوعی، livenerf توازن قدرت را از آزمایشگاهها به سمت کاربران میبرد. با تبدیل مدل به یک «جعبه سیاه» و اندازهگیری توزیع خروجیها، یک ردپای حسابرسی شفاف برای عملکرد مدل ایجاد میکند.
این رویکرد، شکایتهای تجربی را به شکایتهای «مستند» تبدیل میکند. حالا کاربر میتواند به جای گزارشهای نقلقولی از افت کیفیت، به یک بازه اطمینان ۹۹٪ و افت مشخص در میانگین توکنهای خروجی اشاره کند. این ابزار میتواند تغییر دقت حدود ۷.۵ امتیازی را در هر پنجره ۱۰ روزه شناسایی کند که تقریباً ۳.۶٪ از برنامه هفتگی را شامل میشود.
همچنین تفاوت میان API خام و مسیر سرویسدهی مبتنی بر اشتراک را برجسته میکند. livenerf دقیقاً مدلی را اندازه میگیرد که از طریق Claude Code در اشتراک Max ارائه میشود؛ جایی که اکثر گزارشهای «نرف» در واقع از آنجا منشأ میگیرند. خط مبنای هفته عرضه یک نقطه مرجع است، نه لزوماً حقیقت مطلق؛ زیرا هفته عرضه ممکن است به دلیل فشار روی ظرفیت یا باگهای زیرساختی (مشابه حوادث کیفی سال ۲۰۲۵)، بدترین هفته باشد.
اگر میخواهید پایداری مدل خود را رصد کنید، میتوانید livenerf را از طریق uv sync نصب کرده و نسخه CLI خود را پین کنید تا تغییرات ابزار با تغییرات مدل اشتباه گرفته نشود. این پروژه مستقل است و هیچ وابستگی به Anthropic ندارد.
گام بعدی شما
- اگر از اشتراک Max استفاده میکنید، livenerf را نصب کنید تا پایداری مدل خود را رصد کنید.
- نسخه CLI خود را پین کنید تا تغییرات ابزار با تغییرات مدل اشتباه گرفته نشود.
- در گزارشهای آینده، به نسبت «تعداد توکن خروجی به صحت پاسخ» دقت کنید تا متوجه شوید مدل در حال «تنبلی» است یا «ضعف».
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو