رای‌گیری قطعی در برابر تصمیم‌گیری تک‌بعدی برای اصلاح خروجی‌های مدل

امتیاز اطمینان ۰.۹۷ می‌تواند دو روز کامل از زمان حیاتی یک تیم توسعه را به باد دهد. طبق گزارشی که در ۱۶ اوت ۲۰۲۶ در dev.to منتشر شد، یک سرویس C++ که هزاران گزارش کرش هفتگی را پردازش می‌کرد، به‌دلیل اعتماد مطلق به یک مدل هوش مصنوعی به‌جای منطق قطعی، دچار شکست شد.

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

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

مکانیسم شکست

این سامانه هر هفته هزاران گزارش کرش را در قالب فایل‌های JSONL پردازش می‌کرد. هر رکورد شامل یک backtrace، یادداشت sanitizer، تگ پلتفرم و رشته‌ی last_frame بود.

تیم توسعه از یک نقطه اتصال (Endpoint) رایگان از MonkeyCode در مرحله دسته‌بندی استفاده کرد. مدل، هشت فریم اول یک backtrace را می‌خواند و یک دسته‌بندی (Bucket) به‌همراه امتیاز اطمینان برمی‌گرداند. (لازم به ذکر است که این مقاله به‌عنوان بخشی از معرفی محصولات MonkeyCode تهیه شده است). در استفاده از این نقاط اتصال، باید به این نکته توجه داشت که پاسخ‌های موفق در APIهای رایگان لزوماً به معنای پردازش بهینه و موازی نیستند.

یک صبح سه‌شنبه، مدل با گزارشی از نوع ASan heap-use-after-free مواجه شد. با وجود شواهد صریح از فساد حافظه (Heap Corruption)، مدل با اطمینان ۰.۹۷ آن را به دسته‌ی stack_overflow فرستاد. چون سیستم مسیریابی فقط از یک عدد اطمینان پیروی می‌کرد، این گزارش دو روز در صف اشتباه ماند. این یک مشکل در مهندسی پرامپت نبود، بلکه یک نقص در طراحی تصمیم‌گیری بود.

معماری رای‌گیر (Voter)

برای حل این مشکل، تیم از طراحی «تک‌پاسخی» فاصله گرفت و یک سیستم رای‌گیری پیاده کرد. آن‌ها یک چارچوب سبک با C++17 ساختند که دو منبع مستقل را با هم مقایسه می‌کند: یک موتور قوانین محلی و مدل هوش مصنوعی. در این ساختار، مدل دیگر منبع حقیقت نیست و فقط به‌عنوان یک لایه رتبه‌بندی (Ranking Layer) عمل می‌کند. این رویکرد مشابه استراتژی‌های مدیریت خطا است که در معماری Infrai برای تسهیل جابجایی بین مدل‌های مختلف به کار گرفته می‌شود.

جزئیات پیاده‌سازی

این برنامه که در محیط تولید نیست، یک کد C++17 است که دو فایل TSV را می‌خواند:

• crash_reports.tsv: شامل شناسه‌ی گزارش، sanitizer، سیگنال و فریم صفر (frame0).
• model_rankings.tsv: شامل کاندیداهای برتر مدل برای هر گزارش و امتیازات مربوطه. فیلدها شامل id و bucket1|bucket2|bucket3 و score1|score2|score3 هستند.

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

موتور قوانین محلی

قوانین محلی به‌طور عمدی کوچک طراحی شدند تا دقت (Precision) — یعنی همان نرخ عدم خطا در تشخیص‌های مثبت — بر جامعیت (Recall) اولویت داشته باشد. این منطق بر اساس ترکیب رشته‌های sanitizer، سیگنال و فریم صفر کار می‌کرد. منطق بر اساس این تطبیق‌دهنده‌ها (Matchers) پیش می‌رفت:

• heap_corruption: فعال با عبارت‌های "heap-use-after-free" یا "double-free".
• stack_overflow: فعال با عبارت "stack-overflow".
• null_deref: فعال با "SEGV" یا "null".
• lock_order: فعال با "pthread" یا "deadlock".

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

منطق تصمیم‌گیری

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

طبق گزارش dev.to، ماتریس تصمیم‌گیری به این شکل است:

• محلی: نامعلوم | رتبه مدل: N/A | امتیاز >= ۰.۶۵ $\rightarrow$ مسیریابی خودکار (فقط مدل)
• محلی: نامعلوم | رتبه مدل: N/A | امتیاز < ۰.۶۵ $\rightarrow$ بررسی دستی
• محلی: تطبیق یافته | رتبه مدل: ۱ | امتیاز >= ۰.۶۰ $\rightarrow$ مسیریابی خودکار (توافق)
• محلی: تطبیق یافته | رتبه مدل: ۱ | امتیاز < ۰.۶۰ $\rightarrow$ بررسی دستی
• محلی: تطبیق یافته | رتبه مدل: ۲ یا پایین‌تر | هر امتیازی $\rightarrow$ بررسی دستی
• محلی: تطبیق یافته | رتبه مدل: موجود نیست | امتیاز >= ۰.۸۵ $\rightarrow$ بررسی دستی
• محلی: تطبیق یافته | رتبه مدل: موجود نیست | امتیاز < ۰.۸۵ $\rightarrow$ قرنطینه

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

چارچوب C++ بازتولیدپذیر

این برنامه کامل هر دو فایل TSV را می‌خواند، قانون محلی را اعمال می‌کند، رتبه‌بندی مدل را امتیازدهی کرده و برای هر گزارش یک تصمیم می‌نویسد. این کد از std::stod برای تجزیه امتیازات و std::getline برای پردازش TSV کار می‌کند.

برای کامپایل و اجرای این چارچوب:
g++ -std=c++17 -O2 crash_voter.cpp -o crash_voter
./crash_voter crash_reports.tsv model_rankings.tsv decisions.tsv

مثلاً اگر گزارش crash-03 یک مورد heap-use-after-free باشد (قانون محلی: heap_corruption) اما مدل با امتیاز ۰.۹۱ آن را در رتبه اول stack_overflow قرار دهد، سیستم آن را به دلیل عدم توافق، به «بررسی دستی» می‌فرستد.

چرا تنظیم پرامپت شکست خورد؟

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

مکانیزم رای‌گیری یک منبع حقیقت مستقل ایجاد می‌کند که بازرسی آن ارزان است و نیازی به بردار معنایی (Embedding)، مجموعه‌های آموزشی یا عملیات بازآموزی (Retraining) ندارد. این کار هوش مصنوعی را از یک «تصمیم‌گیرنده» به یک «لایه رتبه‌بندی» تبدیل می‌کند. این چارچوب به‌جای باور کورکورانه به امتیاز، مسیر عدم توافق را ثبت می‌کند.

محدودیت‌های عملیاتی

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

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

چه کسانی نباید از این روش استفاده کنند؟

این معماری برای همه مناسب نیست. اگر هیچ انسانی مسئولیت نظارت بر صف‌های بررسی دستی و قرنطینه را بر عهده ندارد، از این روش استفاده نکنید. همچنین نباید برای پاسخ‌های خودکار مانند ارسال هشدار (Paging)، رول‌بک یا اجرای خودکار پچ‌ها به کار رود. در نهایت، اگر شناسه‌های دسته‌بندی کرش به ابزاری متصل هستند که وضعیت سیستم (State) را تغییر می‌دهد، از مسیر مدل استفاده نکنید.

این تغییر رویکرد نشان می‌دهد که در زیرساخت‌های حساس، هدف نباید ساخت یک مدل «کامل»، بلکه ساخت سیستمی است که در آن یک قانون قطعی همیشه بتواند یک حدس احتمالی را وتو کند. اگر لایه رایگان یک مدل ارزان‌ترین راه برای تولید کاندیداهای رتبه‌بندی شده است، این چارچوب آن خروجی را به یک رای قابل بازرسی تبدیل می‌کند. این قانون محلی است که اجازه نمی‌دهد امتیاز ۰.۹۷ باعث شود کسی یک باگ حافظه (Heap Bug) را از دست بدهد.

گام بعدی شما

• اگر از AI برای اتوماسیون تصمیمات فنی استفاده می‌کنید، یک لایه «قوانین سخت» (Hard Rules) برای موارد بحرانی تعریف کنید.
• امتیاز اطمینان (Confidence Score) مدل‌ها را هرگز به‌عنوان تنها معیار صحت در نظر نگیرید.
• برای هر خروجی AI که منجر به تغییر وضعیت سیستم می‌شود، یک مرحله تایید انسانی (Human-in-the-loop) قرار دهید.

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