اگر برای استقرار مدل‌های هوش مصنوعی تنها به اعداد بنچمارک تکیه می‌کنید، احتمالاً در محیط عملیاتی با رفتارهای غیرقابل‌پیش‌بینی روبه‌رو خواهید شد. یک ارزیابی دقیق در ۳ اکتبر ۲۰۲۶ نشان داد که دو مدل تصمیم‌گیرنده با امتیازات کاملاً یکسان، در واقع به شکل‌های متضادی شکست می‌خورند. در این بررسی، مدل‌های span-01-lite و mercury-decide هر دو امتیاز F1 یکسان ۰.۹۳ را به دست آوردند، اما این امتیاز تضمین‌کننده عملکرد مشابه در محیط تولید (Production) نیست.
این مدل‌ها برخلاف مدل‌های زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری هستند که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — متن تولید نمی‌کنند، بلکه یک احتمال یا پاسخ بله/خیر برمی‌گردانند. در این مورد خاص، هدف شناسایی کلمات انگلیسی در میان متن ژاپنی است تا موتورهای تبدیل متن به گفتار (TTS) آن‌ها را با تلفظ اشتباه و ناشیانه نخوانند. این تلاش برای بهبود کیفیت خروجی‌های صوتی، در راستای پیشرفت‌های اخیر در پردازش صوت است؛ برای مثال، کاهش نرخ خطای تبدیل گفتار در محیط‌های نویزی توسط Sarvam AI گامی مهم در جهت افزایش دقت سیستم‌های صوتی بوده است. این آزمایش در ادامه تست‌های قبلی انجام شد که در آن الگوهای ساده regex با مدل‌های مبتنی بر پرامپت مقایسه شدند تا مشخص شود آیا هوش مصنوعی می‌تواند جایگزین فیلترهای سنتی کد-محور شود یا خیر.
زمینه و پیشینه مدل‌ها
طبق گزارش منتشر شده، این ارزیابی بین دو مدل خاص انجام شد: span-01-lite از شرکت Respan (که یک روتر هوش مصنوعی با قابلیت مشاهده داخلی است) و mercury-decide از شرکت Inception. شرکت Inception از فناوری مدل انتشار (Diffusion Model) برای توسعه dLLMها استفاده می‌کند و مدعی است این مدل‌ها سریع‌تر و کارآمدتر از مدل‌های خودبازگشتی (Autoregressive) سنتی هستند.
فرآیند تست بسیار سخت‌گیرانه بود. این ارزیابی شامل یک مجموعه مرزی ۲۳ موردی، یک مجموعه داده (Corpus) واقعی از روایت‌های صوتی و بررسی‌های گسترده روی نحوه نگارش دستورالعمل‌ها بود. برای اطمینان از صحت داده‌ها، یک فایل AUDIT.md تهیه شد که ثبت می‌کند پنج مدل مستقل، تمام اعداد را پیش از انتشار بازبینی کرده‌اند تا هیچ خطای انسانی در گزارش نباشد.
جزئیات تنظیمات بنچمارک
برای تست مدل‌ها، از یک مجموعه مرزی ۲۳ موردی استفاده شد که موارد خاص زبانی زیر را پوشش می‌داد:
- کلمات تک‌واژه‌ای انگلیسی و جملات کامل انگلیسی
- کلمات کاتاکانا، نام‌های برند و نام‌های شخصی
- URLها، کلمات اختصاری (Acronyms)، قطعات کد و اسم‌های نقش (Role Nouns)
بر اساس مستندات این پروژه، تست‌ها در سه فاز زمانی اجرا شدند:
- ۱ اکتبر: ۲ مدل × یک دستورالعمل (در مجموع ۴۶ فراخوانی).
- ۲ اکتبر: ۲ مدل × دو نوع نگارش دستورالعمل، برای مقایسه پرامپت‌های کوتاه در برابر دستورات مفصل و کامل (در مجموع ۹۲ فراخوانی).
- ۳ اکتبر: اجرای مجدد کامل خط لوله (Pipeline) برای تأیید اینکه آیا نتایج قبلی تکرارپذیر هستند یا خیر.
الگوهای متضاد در شکست مدل‌ها
یافته‌ها نشان داد که با وجود امتیاز F1 یکسان یعنی ۰.۹۳، هر مدل موارد متفاوتی را نادیده گرفت. مدل mercury-decide نتوانست یک جمله کامل انگلیسی را شناسایی کند؛ برای مثال جمله "Hello everyone, welcome back to my channel" را با احتمال بسیار پایین ۰.۰۰۲ شناسایی کرد (یعنی آن را منفی دانست). در مقابل، span-01-lite یک کلمه انگلیسی تک‌واژه یعنی "compartments" را با احتمال ۰.۲۴ از دست داد.
به دلیل مکمل بودن این خطاها، اجرای موازی هر دو مدل توانست تمام ۲۳ مورد را به‌درستی شناسایی کند. این موضوع پیشنهاد می‌کند که یک معماری «دروازه دوگانه» (Dual-gate) بهینه است؛ به این معنا که اگر هر یک از دو مدل نتیجه مثبت برگرداند، سیستم متوجه نیاز به اصلاح متن شود.
توزیع احتمالات و آستانه‌ها
این دو مدل اعتماد خود را به شکل متفاوتی مدیریت می‌کنند. مدل mercury-decide تقریباً سیاه و سفید عمل می‌کند؛ در موارد منفی، احتمال خروجی آن به‌ندرت از ۰.۰۳ فراتر می‌رود. این ویژگی باعث می‌شود مدل در بازه گسترده‌ای از آستانه‌ها (Thresholds) پایدار باشد و در تمام آستانه‌های بین ۰.۱۵ تا ۰.۸۵ امتیاز یکسانی کسب کند.
اما span-01-lite دامنه نوسان بیشتری دارد و در موارد منفی تا ۰.۳۶ پیش می‌رود. این امر باعث می‌شود مدل به شدت به آستانه انتخابی حساس باشد؛ کاهش آستانه به ۰.۱۵ باعث افزایش مثبت‌های کاذب (False Positives) می‌شود و افزایش آن به ۰.۸۵ منجر به افزایش موارد از دست رفته (Misses) می‌گردد.
حساسیت به دستورالعمل‌ها
وقتی دستورالعمل‌ها از پرامپت‌های کوتاه به مشخصات مفصل تبدیل شدند، هر دو مدل بهبود یافتند، اما منطق تغییر آن‌ها متفاوت بود:
- span-01-lite بهبود خطی داشت. امتیاز F1 آن از ۰.۶۷ (در حالت کوتاه) به ۰.۹۳ (در حالت مفصل) رسید، زیرا صرفاً مثبت‌های کاذب را حذف کرد. تمام چهار حکمی که تغییر کرد، در جهت بهبود بود.
- mercury-decide نوسان بیشتری نشان داد. امتیاز آن از ۰.۶۷ به ۰.۸۰ رسید، اما ۹ مورد از نتایجش تغییر کرد. در یک مورد، با طولانی‌تر شدن دستورالعمل، مدل شروع به نادیده گرفتن یک مورد مثبت کرد. به نظر می‌رسد فهرست کردن شرایط استثنا باعث شد مدل مواردی را که صریحاً در لیست نبودند، به اشتباه منفی تشخیص دهد.
شکاف پایداری (Stability Gap)
بحرانی‌ترین یافته در طول تست‌های چندروزه ظاهر شد. مدل span-01-lite کاملاً قطعی (Deterministic) باقی ماند و در چهار روز مختلف (۲۷ سپتامبر، ۱ اکتبر، ۲ اکتبر و ۳ اکتبر) دقیقاً همان احکام را برگرداند.
اما mercury-decide در برابر متن یکسان، از یک روز به روز دیگر نظرش را تغییر داد. در ۲ مورد از ۲۳ تست، پاسخ مدل عوض شد و همین موضوع باعث شد امتیاز F1 آن از ۰.۹۳ به ۰.۸۰ سقوط کند. برای مثال، یک کلمه کاتاکانا که یک روز منفی تشخیص داده شده بود، روز بعد مثبت (۰.۹۲) شد. همچنین یک اسم نقش که قبلاً شناسایی شده بود، روز بعد به احتمال ۰.۰۰۴ سقوط کرد. اگرچه مدل در یک روز واحد قطعی است (که با سه بار فراخوانی تکراری تأیید شد)، اما رفتار آن در یک پنجره ۲۴ ساعته تغییر کرد.
محدودیت‌های صادقانه
باید توجه داشت که این مطالعه محدودیت‌هایی دارد؛ خط‌کش ۲۳ موردی نمونه کوچکی است و لزوماً بازتاب‌دهنده دقت در اسکریپت‌های کامل دنیای واقعی نیست. همچنین تغییرات روزانه تنها در دو مورد رخ داد، بنابراین نمی‌توان احتمال یک «اتفاق تصادفی تک‌روزه» را کاملاً رد کرد. علاوه بر این، دستورالعمل‌ها از مقاله قبلی بازیافت شده بودند و به‌طور خاص برای مدل mercury تنظیم نشده بودند و برچسب‌های مرجع (Ground-truth) بر اساس قضاوت شخصی نویسنده بوده‌اند.
این نتایج نشان می‌دهد برای محیط‌های عملیاتی که ثبات در آن‌ها حیاتی است، پایداری مدل به اندازه امتیاز دقت آن اهمیت دارد. تکیه صرف به یک عدد F1 می‌تواند منجر به رفتارهای غیرقابل‌پیش‌بینی در خط لوله‌های زنده شود.
برای توسعه‌دهندگان، نتیجه روشن است: اگر مجبور به انتخاب یک مدل هستید، span-01-lite را به دلیل پایداری و با دستورالعمل‌های مفصل انتخاب کنید. اگر هزینه یک خطای شناسایی (Miss) بالا است، پیاده‌سازی یک دروازه دو-مدلی که در آن هر مدل بتواند هشدار دهد، امن‌ترین معماری است.
برای تأیید این یافته‌ها، می‌توانید مجموعه داده کامل و خط‌کش ۲۳ موردی را در مخزن گیت‌هاب پروژه به آدرس github.com/sunnydachs/span01-eval بررسی کنید.
گام بعدی شما
- اگر به دنبال پایداری هستید، از span-01-lite همراه با دستورالعمل‌های مفصل استفاده کنید.
- برای کاهش ریسک خطا در سیستم‌های حساس، معماری «دروازه دوگانه» (Dual-gate) را پیاده کنید تا هر دو مدل موازی عمل کنند.
- هرگز به یک عدد تک‌بعدی مثل F1 برای تایید نهایی مدل در محیط Production اکتفا نکنید.
اما بررسی هزینه استنتاج این مدل‌ها در مقیاس بالا، ابعاد دیگری از این رقابت را روشن می‌کند — به تحلیل ما درباره بهینه‌سازی GPUها مراجعه کنید.
گفتگو