یک پاسخ درست می‌تواند یک پاسخ شکست‌خورده باشد. در مستنداتی که ۶ اکتبر ۲۰۲۶ در چالش بنچمارکینگ Kaggle منتشر شد، چارچوب ConstraintBench نشان می‌دهد که مدل‌های هوش مصنوعی اغلب تحت «فشار مشخصات» (Specification Pressure) فرو می‌پاشند و حتی وقتی استدلال زیربنایی آن‌ها بی‌نقص است، قوانین حیاتی قالب‌بندی یا ایمنی را نادیده می‌گیرند.
بیشتر محک‌های فعلی بر یک نتیجه دوتایی تمرکز دارند: آیا مدل جواب را درست داد؟ اما محیط‌های عملیاتی واقعی چیزی فراتر از دقت می‌خواهند. پرامپت‌های دنیای واقعی به‌ندرت شامل یک دستور ساده و تمیز هستند. یک عامل (Agent) — شبیه کارمندی که باید هم‌زمان چندین دستور متضاد رئیس را اجرا کند و هیچ‌کدام را فراموش نکند — ممکن است نیاز داشته باشد مسئله‌ای را حل کند، ساختاری دقیق برگرداند، اطلاعات مورد نیاز را بگنجاند، اطلاعات حساس را حذف کند، ترتیب و محدودیت‌های طول متن را رعایت کند، محاسبات را انجام دهد و از قوانین با اولویت بالاتر پیروی کند؛ همه این‌ها باید در یک پاسخ واحد رخ دهد.
اگر مدلی یک تراکنش مالی را به‌طور کامل محاسبه کند اما خروجی را در قالب JSON نامعتبر برگرداند، سیستم‌های پایین‌دستی کرش می‌کنند. در اینجا استدلال درست بود، اما جریان کاری (Workflow) شکست خورد. شکاف میان هوش خام و قابلیت اطمینان عملیاتی، جایی است که ConstraintBench وارد می‌شود. این ابزار، پیروی از دستورات چندگانه را تحت فشار مشخصات بررسی می‌کند تا بفهمد وقتی «درست جواب دادن» به تنهایی کافی نیست، چه اتفاقی می‌افتد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تفاوت میان عملکرد آزمایشگاهی و استقرار واقعی اغلب در همین جزئیات کوچک نهفته است. این چالش‌ها به‌ویژه در محیط‌های برنامه‌نویسی مشهود است، جایی که برخی دستیارهای AI برای دستیابی به سرعت بیشتر، دقت را فدای پاسخ‌های سریع می‌کنند و ریسک خطاهای ساختاری را افزایش می‌دهند.
مکانیزم ارزیابی قطعی
برخلاف محک‌هایی که از مدل‌های زبانی دیگر (LLM-as-a-judge) به‌عنوان داور استفاده می‌کنند، این سامانه از بررسی‌های قطعی (Deterministic) بهره می‌برد. این رویکرد، ذهنیت سوبژکتیو «داوری AI توسط AI» را حذف می‌کند و بازتولید و تفسیر خطاها را ساده‌تر می‌سازد. منطق ارزیابی در اینجا کاملاً دوتایی است:
- یک کلید مورد نیاز وجود دارد یا ندارد.
- یک مقدار ممنوعه ظاهر شده است یا خیر.
- یک شرط عددی برآورده شده است یا نه.
- یک ساختار درخواستی معتبر است یا نامعتبر.
این رویکرد سخت‌گیرانه به بنچ‌مارک اجازه می‌دهد تا به یک پرسش مرکزی پاسخ دهد: وقتی مدل دستورات زیادی دارد که نباید آن‌ها را فراموش کند، ابتدا کدام‌یک را فراموش می‌کند?
چهار ستون فشار محدودیت
ConstraintBench مدل‌ها را در ۲۴ مورد قطعی می‌سنجد. این موارد به چهار خانواده متمایز تقسیم شده‌اند و در هر خانواده ۶ مورد وجود دارد. هر خانواده شامل مواردی با فشار مشخصات افزایشی است که محدودیت‌هایی مانند تولید خروجی ساختاریافته معتبر، استفاده از تعداد دقیق آیتم‌ها و پیروی از دستورات شرطی را با هم ترکیب می‌کند.
- استخراج ساختاریافته (Structured Extraction): مدل‌ها باید اطلاعات را استخراج کنند و هم‌زمان الزاماتی مانند ساختار دقیق خروجی، فیلدهای اجباری، محتوای ممنوعه، ترتیب، قالب‌بندی و شرایط عددی را رعایت کنند. یک پاسخ می‌تواند تمام اطلاعات درست را داشته باشد اما اگر توسط سیستم دیگر به‌طور قابل‌اعتماد مصرف نشود، شکست‌خورده است.
- استدلال تحت محدودیت (Reasoning Under Constraints): این وظایف، مسائل استدلالی یا عددی را با الزامات خروجی اضافی ترکیب می‌کنند. مدل باید مسئله زیربنایی را حل کند و در عین حال مشخصات محیطی را حفظ نماید. این بخش تفاوت میان مدلی که «جواب را می‌دانست» و مدلی که «وظیفه را به پایان رساند» مشخص می‌کند.
- تبدیل و ویرایش (Transformation & Editing): این بخش جریان‌های کاری واقعی AI مانند خلاصه‌سازی، بازنویسی، پردازش اسناد، آماده‌سازی داده‌ها و محتوای تولید شده توسط عامل را شبیه‌سازی می‌کند. مدل باید دقیقاً همان چیزی را که از او خواسته شده تغییر دهد، بدون اینکه به‌طور تصادفی سایر اطلاعات ضروری را تغییر دهد یا حذف کند. چالش در اینجا صرفاً تولید متنی روان نیست.
- حفظ اولویت و ایمنی (Priority & Safety Preservation): این بخش تست می‌کند که آیا الزامات مهم هنگام رقابت با دستورات دیگر باقی می‌مانند یا خیر. این موارد شامل محدودیت‌های مربوط به حریم خصوصی، اطلاعات ممنوعه، رفتار شرطی و الزامات با اولویت بالاتر است. این موضوع حیاتی است زیرا حذف یک الزام قالب‌بندی تنها یک مزاحمت است، اما حذف یک الزام حریم خصوصی یا ایمنی می‌تواند بسیار جدی‌تر باشد.
عملکرد مدل‌ها و تنوع نتایج
برای اطمینان از اینکه بنچ‌مارک صرفاً مدل‌های پیشرو و نزدیک به هم را مقایسه نمی‌کند، سازنده آن طیف متنوعی از مدل‌ها از چندین خانواده مختلف را تست کرد. هدف این بود که مشخص شود آیا قدرت کلی مدل به‌طور خودکار به معنای قابلیت اطمینان در محدودیت‌هاست یا خیر. لیست مدل‌های تست شده شامل موارد زیر بود:
- Gemini: Gemini 3.7 Flash
- Gemma: Gemma 4 26B, A4B
- Grok: Grok 4.20 Reasoning
- Claude: Claude Haiku 4.5, Claude Sonnet 4.6, Claude Opus 4.6
- GPT: GPT-5.4
- GLM: GLM-5
- DeepSeek: DeepSeek-R1
- Qwen: Qwen 3 235B, A22B
یکی از تکان‌دهنده‌ترین یافته‌ها این است که «بزرگ‌تر بودن» لزوماً به معنای «قابل‌اعتمادتر بودن» نیست. یک مدل استدلالی عظیم ممکن است یک معمای منطقی پیچیده را حل کند اما یک شرط ظاهراً جزئی در خروجی را فراموش کند. در مقابل، یک مدل کوچک‌تر یا سریع‌تر ممکن است در پایبندی به ساختارها بسیار قابل‌اعتمادتر باشد. این نشان می‌دهد که مدل‌ها دارای یک «پروفایل قابلیت اطمینان در محدودیت‌ها» هستند، نه یک نمره هوش واحد. برای برنامه‌های عملیاتی، شکل این پروفایل ممکن است بسیار مهم‌تر از تفاوت اندک در نمره کلی یک بنچ‌مارک باشد. در همین راستا، برخی مدل‌ها مانند جمینای ۳.۱ پرو در آزمون‌های کدنویسی مسموم، پایداری بیشتری در برابر تقلب و خطاهای القایی نشان داده‌اند که نشان‌دهنده اهمیت معماری در حفظ ثبات است.
خطر شکست‌های ناپیوسته
توسعه‌دهندگان اغلب تصور می‌کنند اگر مدلی ۵ دستور را درست اجرا کند، احتمالاً ششمین دستور را هم اجرا خواهد کرد. ConstraintBench این فرض را به چالش می‌کشد. سازنده در ابتدا انتظار داشت که افت کیفیت به‌صورت نسبتاً نرم باشد، به‌طوری که با پیچیده‌تر شدن پرامپت‌ها، مدل‌ها به‌تدریج الزامات بیشتری را از دست بدهند.
اما نتایج نشان داد که شکست‌های محدودیت می‌توانند «ناپیوسته» (Discontinuous) باشند. یک مدل ممکن است در یک خانواده از وظایف کاملاً قابل‌اعتماد به نظر برسد و سپس وقتی نوع یا نحوه تعامل الزامات تغییر می‌کند، به‌طور شدید شکست بخورد. این نوسان برای عامل‌های خودمختاری که باید هم‌زمان از قوانین کسب‌وکار و طرح‌های API پیروی کنند، یک ریسک بزرگ است. این ثابت می‌کند که توسعه‌دهندگان نمی‌توانند برای پیش‌بینی قابلیت اطمینان تحت فشارهای جدید، به موفقیت‌های قبلی تکیه کنند.
چرا شکست‌های «جزئی» ریسک‌های بزرگی هستند؟
الزامات ساده‌ای مثل «دقیقاً سه مورد برگردان»، «این ترتیب را حفظ کن»، «این مقدار را حذف کن»، «از این فیلدهای دقیق استفاده کن» یا «این قانون شرطی را دنبال کن» در مقایسه با استدلال‌های پیچیده، پیش‌پاافتاده به نظر می‌رسند. اما در محیط تولید (Production)، همین دستورات هستند که قابلیت استفاده را تعیین می‌کنند.
اگر عاملی شرط حذف اطلاعات را نادیده بگیرد، اطلاعاتی که باید خصوصی می‌ماند ممکن است در پاسخ ظاهر شود. اگر مدل قرارداد رابط (Interface Contract) را نقض کند و پاسخ درست را در یک محموله (Payload) نامعتبر قرار دهد، سرویس پایین‌دستی آن را رد می‌کند. ConstraintBench این مشخصات را به‌عنوان اجزای اصلی «صحت»، نه جزئیات اختیاری نمایش، در نظر می‌گیرد.
تحلیل الگوهای شکست
این پروژه آشکار کرد که الگوهای شکست بسیار مفیدتر از رتبه‌بندی‌های کلی هستند. به‌جای پرسش «کدام مدل باهوش‌تر است؟»، این بنچ‌مارک توسعه‌دهندگان را تشویق می‌کند بپرسند:
- کدام خانواده از وظایف باعث شکست مدل شد؟
- آیا الزامات با اولویت بالا حفظ شدند؟
- آیا استدلال غلط بود، یا استدلال درست بود اما فرمت اشتباه؟
- آیا مدل چیزی را که لازم بود حذف کرد یا چیزی را که ممنوع بود اضافه کرد؟
- آیا شکست تنها زمانی ظاهر شد که چندین محدودیت با هم تداخل داشتند؟
این پرسش‌ها دقیقاً بازتاب‌دهنده تصمیماتی است که توسعه‌دهندگان هنگام انتخاب یک مدل برای یک برنامه واقعی می‌گیرند.
مسیر به‌سوی هوش مصنوعی آگاه به اولویت
برای آینده، سازنده این محک پیشنهاد می‌کند «اولویت صریح محدودیت‌ها» تست شود. این کار شامل برچسب‌گذاری الزامات به عنوان «حیاتی» (CRITICAL)، «بالا» (HIGH) یا «اختیاری» (OPTIONAL) است. هدف این است که ببینیم آیا مدل به‌طور هوشمندانه یک الزام قالب‌بندی اختیاری را فدا می‌کند تا یک الزام حریم خصوصی را نقض نکند. این امر، پیروی از محدودیت‌ها را از یک شمارش ساده شکست‌ها به مسئله‌ای در مورد «فدای هوشمندانه» تبدیل می‌کند.
مسیرهای تجربی آینده
برای درک عمیق‌تر قابلیت اطمینان مدل‌ها، حوزه‌های زیر مورد بررسی قرار خواهند گرفت:
- تراکم محدودیت‌ها (Constraint Density): مقایسه عملکرد در ۳، ۵، ۸ و بیش از ۱۰ الزام هم‌زمان.
- ترتیب پرامپت (Prompt Ordering): تست اینکه آیا الزامات در ابتدای پرامپت یا انتهای آن، با قابلیت اطمینان بیشتری حفظ می‌شوند.
- محدودیت‌های متضاد (Conflicting Constraints): تحلیل اینکه وقتی تمام دستورات را نمی‌توان برآورده کرد، مدل چه چیزی را فدا می‌کند.
- تکرار محدودیت‌ها (Repeated Constraints): تعیین اینکه آیا تکرار الزامات حیاتی واقعاً قابلیت اطمینان را بهبود می‌بخشد یا خیر.
- خود-اصلاحی (Self-Correction): تست اینکه آیا مدل‌ها می‌توانند تخلفات خود از محدودیت‌ها را شناسایی کنند.
- طرح‌ها در برابر زبان طبیعی (Schemas vs. Natural Language): ارزیابی اینکه آیا Schemaهای صریح در مقایسه با زبان طبیعی، پایبندی را بهبود می‌بخشند.
- حواس‌پرتی‌های خصمانه (Adversarial Distractions): بررسی اینکه آیا دستورات بی‌ربط باعث ناپدید شدن الزامات مهم می‌شوند.
- کارایی (Efficiency): سنجش اینکه آیا افزایش قابلیت اطمینان، ارزش تأخیر (Latency) و هزینه توکن اضافی را دارد.
برای توسعه‌دهندگان عامل‌ها، پیام روشن است: توانایی خام، جایگزینی برای قابلیت اطمینان نیست. یک عامل باید درخواست را بفهمد، درباره آن استدلال کند، از قوانین کسب‌وکار پیروی کند، از اطلاعات حساس محافظت کند، آرگومان‌های ابزار معتبر تولید کند و یک Schema API را برآورده سازد. یک پاسخ پیچیده که یک قرارداد را نقض می‌کند، کم‌فایده‌تر از یک پاسخ ساده است که آن را به‌طور کامل رعایت کرده باشد. یک مدل صرفاً به این دلیل قابل‌اعتماد نیست که جواب درست را می‌داند؛ بلکه باید هر آنچه را که به او گفته شده «اشتباه نکند» نیز به خاطر بسپارد.
گام بعدی شما
- در پرامپت‌های خود، الزامات ساختاری (مانند JSON) را از دستورات استدلالی جدا کنید و برای موارد حیاتی از کلمات کلیدی تأکیدی استفاده کنید. برای این منظور می‌توانید از الگوهای ساختاری خاصی که برای رفع خطاهای رایج خروجی AI طراحی شده‌اند بهره ببرید تا احتمال شکست مدل کاهش یابد.
- برای سیستم‌های حساس، به‌جای تکیه بر هوش مدل، از لایه‌های اعتبارسنجی قطعی (Deterministic Validation) در خروجی استفاده کنید.
- پروفایل قابلیت اطمینان مدل خود را با تست‌های لبه‌ای (Edge Cases) بسنجید، نه فقط با میانگین نمرات بنچ‌مارک.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو