درون CauterRule؛ تضاد میان تطابق توکنی و درک معنایی در ارزیابی AI

امتیاز ۰.۰۸؛ این بود نتیجهٔ فاجعه‌باری که یک معیار تطابق توکنی در ۱۳ سپتامبر ۲۰۲۶ به یک مدل با عملکرد بالا اختصاص داد. این خطای اندازه‌گیری تقریباً توسعه‌دهندگان CauterRule را متقاعد کرده بود که مدل‌های آن‌ها در استخراج قوانین پایه شکست خورده‌اند؛ کشفی که هم‌زمان با انتشار نسخه ۰.۳.۱ این چارچوب افشا شد.

این اتفاق در حالی رخ می‌دهد که توسعه‌دهندگان برای انتقال عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیارهای دیجیتالی که می‌توانند به‌جای فقط حرف زدن، کارهای واقعی را انجام دهند — از پرامپت‌های شکننده به قوانین دائمی و ثابت تلاش می‌کنند. اکثر سامانه‌های عامل‌محور شکست می‌خورند چون نمی‌توانند یک خطای خاص را به یک دستورالعمل قابل استفاده تبدیل کنند. این چالش‌ها با برخی باگ‌های بحرانی در اتصال به API که پیش‌تر بررسی کردیم، هم‌سو است و نشان می‌دهد که شکاف میان دستور و اجرا کجاست. CauterRule تلاش می‌کند با استخراج درس‌ها از مسیرهای شکست، آزمایش آن‌ها از طریق بازپخش و ارتقای آن‌ها به بسته‌های قانونی دائمی، این مشکل را حل کند. این چارچوب اکنون در GitHub و PyPI در دسترس است و کاربران می‌توانند با دستور pip install cauterule به رابط خط فرمان (CLI)، آداپتورهای چارچوب، چرخه حیات قوانین و بسته‌های قانونی رسمی دسترسی یابند.

تصور کنید می‌خواهید برگهٔ دانش‌آموزی را تصحیح کنید که نوشته است «زمین یک کره است»، اما در کلید پاسخ نوشته شده «زمین گرد است». یک تصحیح‌کنندهٔ سخت‌گیر (Literal) آن را غلط می‌گیرد، اما یک تصحیح‌کنندهٔ معنایی (Semantic) آن را درست می‌داند. تیم CauterRule دریافت که برای منعطف‌ترین بخش خروجی هوش مصنوعی، از یک تصحیح‌کنندهٔ سخت‌گیر استفاده می‌کردند.

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

کالبدشکافی «خط‌کش شکسته»

طبق گزارش تیم توسعه، آن‌ها دو مدل ابری را روی ۴۰ مجموعه داده (Corpora) و ۴۷۴۲ اجرای مسیر (Trajectory-runs) ارزیابی کردند. برای سنجش موفقیت، از فیلد expected_rule یا همان داده مرجع (Ground Truth) استفاده شد که قانون مورد انتظاری است که یک مسیر باید تولید کند. این فیلد در چهار مجموعه داده خاص وجود داشت:

• golden: ۶۰ مسیر (که با سناریوهای نویسنده در شماره ۷۳۵ تکمیل شده بود).
• failures/positive: ۲۳ مسیر.
• reference-expansion: ۳۰۳ مسیر.
• paraphrase-diversity: بخشی شامل ۱۵ مسیر.

نتیجهٔ اولیه ۰.۰۸ بود که نشان می‌داد مدل تقریباً هیچ توانایی در استخراج دستورات ندارد. اما با بررسی دقیق‌تر، تیم دریافت که شکست در معیار بود، نه در مدل. آن‌ها امتیاز نهایی توافق را بر اساس «دستور» (Directive) — یعنی بخشی از قانون که به عامل می‌گوید چه کاری انجام دهد — محدود کرده بودند.

به‌عنوان مثال، دستوری مثل «قبل از Push کردن، آخرین تغییرات را Pull کن» یک عبارت کوتاه است. اگر مدل این را به «ابتدا یک rebase یا fetch-merge اجرا کن» تغییر دهد، تقریباً هیچ توکن (Token) — تکه‌های کوچکی از متن، شبیه برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — مشترکی با داده مرجع ندارد و امتیاز حدود ۰.۲۲ می‌گیرد. وقتی این مقدار به عنوان دروازهٔ امتیاز ترکیبی استفاده شد، توافق کلی در مجموعه golden به بازه ۰.۰۸ تا ۰.۱۰ سقوط کرد. تیم این وضعیت را «یک مقایسه‌گر لغوی که لباس اعتبارسنجی پوشیده است» توصیف کرد.

راهکار J6: جداسازی ماشه

برای رفع این مشکل، تیم استراتژی اندازه‌گیری جدیدی به نام J6 را اجرا کرد. آن‌ها «ماشه» (Trigger) — بخشی از قانون که شکست را شناسایی می‌کند — را از «دستور» (Directive) — اقدامی که باید انجام شود — جدا کردند.

در سیستم جدید، توافق تنها بر اساس تطابق معناییِ ماشه است. دستور دیگر دروازهٔ امتیاز نهایی نیست؛ بلکه در کنار آن به عنوان directive_f1 گزارش می‌شود تا سیگنال حفظ شود بدون اینکه نتیجه نهایی را تعیین کند. برای دائمی کردن این منطق و جلوگیری از بازگشت خطا، تیم یک تست رگرسیون در مسیر tests/measurement/test_extraction_accuracy.py با نام test_agreement_is_trigger_only_directive_not_gated اضافه کرد. این رویکرد استفاده از تست‌های رگرسیون برای اعتبارسنجی حاکمیت مدل، مشابه سازوکار AIDDSkeleton در تبدیل دستورالعمل‌ها به کد است.

داده‌ها: معنایی در برابر لغوی

تغییر در اندازه‌گیری، روایت را کاملاً عوض کرد. اکنون تیم برای جلوگیری از «دروغ‌های ترکیبی»، چهار معیار مجزا را برای هر مجموعه داده محاسبه می‌کند:

• token_f1: تطابق لغوی توکن‌ها بین فرم‌های سطحی استخراج‌شده و مورد انتظار.
• semantic_f1: شباهت کسینوسی (Cosine Similarity) مدل MiniLM روی معنای کامل قانون.
• directive_f1: تطابق لغوی فقط روی بخش «انجام بده» (عبارت دستوری).
• agreement: تطابق معنایی فقط روی ماشه (امتیاز اصلی و سرتیتر).

بر اساس گزارش تست میدانی نسخه ۰.۳.۱، عملکرد مدل‌ها به این صورت بود:

• توافق (فقط ماشه): امتیازی بین ۰.۷۴ و ۰.۹۳؛ این ثابت کرد مدل‌ها دقیقاً می‌دانستند چه زمانی یک قانون لازم است.
• Token F1 (لغوی): امتیازی بین ۰.۴۲ و ۰.۶۵؛ که نشان داد عبارت‌بندی لغوی در سطح متوسطی است.
• Directive F1: امتیازی بین ۰.۲۰ و ۰.۳۹؛ که تأیید کرد بخش «انجام بده» جایی است که مقایسه لغوی شدیدترین شکست را دارد.

جزئیات استخراج‌شده از آرتیفکت‌های ثبت‌شده تفاوت‌ها را به‌وضوح نشان می‌دهد:

• golden (۶۰): مدل llama-3.1-8b به توافق ۰.۸۵ رسید (در مقابل ۰.۷۸۳ برای gpt-4o-mini)، اما تطابق توکنی آن تنها ۰.۳۶۷ بود (در مقابل ۰.۲۵۰ برای gpt-4o-mini). در معیار token_f1، مدل llama-3.1-8b به ۰.۴۸۴ و gpt-4o-mini به ۰.۴۱۹ رسید.
• failures/positive (۲۳): مدل llama-3.1-8b به توافق ۰.۷۸۳ با directive_f1 برابر ۰.۲۹۴ و token_f1 برابر ۰.۵۵۶ رسید. gpt-4o-mini امتیاز توافق ۰.۷۳۹ و token_f1 برابر ۰.۵۲۷ را ثبت کرد.
• reference-expansion (۳۰۳): هر دو مدل امتیاز توافق ۰.۹۱۷ گرفتند، هرچند llama-3.1-8b در token_f1 (۰.۶۵۴ در برابر ۰.۶۰۸) و token_agree (۰.۶۳۰ در برابر ۰.۵۴۸) برتر بود.
• paraphrase-diversity (۱۵): هر دو مدل به توافق ۰.۹۳۳ رسیدند، با وجود اینکه تطابق توکنی بسیار پایین بود (۰.۲۶۷ برای gpt-4o-mini و ۰.۲۰۰ برای llama-3.1-8b). مدل llama-3.1-8b مقدار directive_f1 بالاتری (۰.۳۸۸) نسبت به gpt-4o-mini (۰.۳۱۱) نشان داد.

اصلاحات برای صداقت ساختاری

علاوه بر معیار اصلی، دو اصلاح حیاتی دیگر برای جلوگیری از تفسیر اشتباه گزارش‌ها معرفی شد.

J10: مشکل صفر در برابر تهی
پیش از این، مجموعه‌هایی که داده مرجع نداشتند (مانند raw/ci) به عنوان ۰.۰ گزارش می‌شدند. در علم داده، ۰.۰ یعنی اندازه‌گیری انجام شده و نتیجه صفر است؛ اما برای مجموعه‌ای بدون داده مرجع، این یک دروغ است و از شکست کامل غیرقابل تشخیص بود. اکنون تابع to_dict() در صورت نبود داده (n == 0) مقدار null برمی‌گرداند و اجراکننده مقدار None را صادر می‌کند تا گزارش‌ها بتوانند بین «غیرقابل اندازه‌گیری» و «صفر» تفاوت قائل شوند.

J13: برچسب‌گذاری بر اساس قصد
در مجموعه raw/opencode نرخ پذیرش ۰.۶۸ / ۰.۷۲ به عنوان «نرخ پذیرش نادرست» (false_accept_rate) برچسب خورده بود. چون این یک مجموعه ارتقا بود و نه رد، عدد بالا در واقع نشان می‌داد سیستم درست کار می‌کند. نامیدن آن به عنوان «پذیرش نادرست» باعث می‌شد یک نرخ موفقیت شبیه به یک نقض امنیتی به نظر برسد. حالا مجموعه‌های رد (مانند nearmiss و adversarial/*) مقدار false_accept_rate و مجموعه‌های سکوت و استخراج مقدار acceptance_rate را گزارش می‌کنند.

هزینه معیارهای بررسی‌نشده

تیم اشاره کرد که یک معیار در واقع کدی است که بارهای تصمیم‌گیری را تحمل می‌کند. آن‌ها دریافتند وقتی یک معیار جدید با روایت قدیمی در تضاد است، خودِ معیار اولین متهم است. داده‌ها بین خوانش ۰.۰۸ و ۰.۷۸ تغییر نکردند؛ فقط انتخاب مقایسه‌گر تغییر کرد.

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

ابهامات باقی‌مانده

با وجود اصلاحات، تیم برخی پرسش‌ها را باز گذاشته است:

• سخاوتمندی: آیا توافق فقط روی ماشه بیش از حد سخاوتمندانه است؟ اگر ماشه درست باشد اما دستور بی‌معنی باشد، سیستم باز هم استخراج را «خوب» می‌داند. تیم مقدار directive_f1 را گزارش می‌کند اما تصمیم‌گیری درباره آن را به تعویق انداخته است.
• مشکل n کوچک: در مجموعه‌هایی با تعداد کم (مثل ۱۵ مورد در paraphrase-diversity یا ۲۳ مورد در failures/positive)، توافق فقط یک جهت‌نما است، نه یک ادعای قطعی. بازه‌های اطمینان ویلسون (Wilson CIs) برای نرخ‌های پذیرش هنوز این اعداد استخراج را پوشش نمی‌دهند.
• بیش‌برازش (Overfitting): آیا توافق ۰.۹۱۷ در reference-expansion صرفاً به این معناست که مدل عبارت‌های موجود در ۳۰۳ مسیر مرجع را بازتولید می‌کند؟ مشخص نیست چه مقدار از این ۰.۹۱۷ به قوانینی منتقل می‌شود که هیچ‌کس در آن مجموعه ننوشته است.

برای توسعه‌دهندگان، این یعنی یک امتیاز ترکیبی واحد اغلب یک دروغ است. تنها راه تشخیص مدل، بررسی فاصله بین مقایسه‌گرهای مختلف (توکنی، معنایی و دستوری) است تا دقیقاً مشخص شود شکاف کجاست. ترکیب‌ها داده‌ها را فشرده می‌کنند، اما زیر-معیارها مشکل را مکان‌یابی می‌کنند.

اگر در حال ساخت یک خط لوله عامل‌محور هستید، باید ابزار ارزیابی خود را برای تله‌های تطابق توکنی بازرسی کنید. بررسی کنید که آیا معیارهای «شکست» شما در واقع در حال جریمه کردن بازنویسی‌های درست از داده‌های مرجع هستند یا خیر.

گام بعدی شما

• ارزیابی‌های فعلی خود را بررسی کنید تا مطمئن شوید از تطابق لغوی (Exact Match) برای خروجی‌های باز به‌جای تطابق معنایی استفاده نمی‌کنید.
• برای هر معیار ارزیابی، یک تست رگرسیون بنویسید تا مطمئن شوید تغییر در مدل باعث تغییر در منطقِ اندازه‌گیری نمی‌شود.
• به‌جای استفاده از یک امتیاز کلی (Composite Score)، داشبوردی بسازید که تفکیک بین صحتِ شناسایی مشکل (Trigger) و صحتِ ارائه راهکار (Directive) را نشان دهد.

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