تنظیم دقیق مدل Laya صحت طبقه‌بندی تیکت‌ها را از ۱۱٪ به ۸۵٪ رساند

اگر برای مدیریت تیکت‌های پشتیبانی به مدل‌های هوش مصنوعی متکی هستید، باید بدانید که تفاوت میان یک مدل آماده و یک مدل تنظیم‌شده می‌تواند نرخ خطای شما را از ۸۹٪ به ۱۴٪ کاهش دهد. این جهش خیره‌کننده در مدل Laya ثابت می‌کند که مدل‌های وزن‌باز (Open Weights) — یعنی مدل‌هایی که دستور پخت یا همان وزن‌هایشان علناً منتشر شده تا هر کسی بتواند آن‌ها را تغییر دهد — می‌توانند در تخصص‌های خاص با مدل‌های گران‌قیمت رقابت کنند و تقریباً به عملکرد مدل‌های اختصاصی سطح اول برسند.

این آزمایش در زمانی رخ می‌دهد که صنعت در حال تفکیک میان مدل‌های زبانی بزرگ (LLM) و «مدل‌های تصمیم‌گیر» است. مدل‌های زبانی بزرگ — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — برای تولید متن آزاد و باز هستند. اما مدل‌های تصمیم‌گیر، که شرکت TypeSafe آن‌ها را «مدل‌های سیستم یک» (System One Models) می‌نامد، برای امتیازدهی به مجموعه‌ای محدود از انتخاب‌ها طراحی شده‌اند تا تصمیماتی با نوع داده‌ای مشخص (Typed Decisions) برگردانند. این معماری باعث کاهش خطاهای تجزیه (Parsing) می‌شود و از بروز مقادیر «خارج از طرح» (Out-of-schema) که اغلب خروجی‌های JSON مدل‌های LLM را مختل می‌کند، جلوگیری می‌کند.

درک مدل‌های تصمیم‌گیر

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

شرکت TypeSafe از اصطلاح «مدل‌های سیستم یک» برای این دسته استفاده می‌کند، هرچند این یک ترمینولوژی شرکتی است و نه یک تاکسونومی آکادمیک پذیرفته‌شده جهانی. اصطلاحات خنثی‌تر برای این مدل‌ها شامل «مدل تصمیم‌گیر احتمالی» یا «مدل تصمیم‌گیر ساختاریافته» است.

جریان مفهومی یک مدل تصمیم‌گیر به این صورت است: وضعیت + مجموعه‌ای از انتخاب‌ها $ \rightarrow $ توزیع احتمالی $ \rightarrow $ تصمیم تایپ‌شده. در مقابل، یک LLM تولیدی مسیر زیر را طی می‌کند: متن $ \rightarrow $ تولید توکن به توکن $ \rightarrow $ متن.

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

رقبای میدان: Jev و Laya

شرکت TypeSafe در ۱۵ سپتامبر ۲۰۲۶ مدل Jev را به‌عنوان نخستین «مدل سیستم یک» خود معرفی کرد. این یک مدل غیرتولیدی است که در تصمیمات ساختاریافته تخصص دارد.

تاریخچه رسمی Laya در Hugging Face نشان می‌دهد که اولین کامیت با عنوان «Initial release» در ۱۸ سپتامبر ۲۰۲۶ ثبت شده است. این سوابق عمومی سه روز با هم فاصله دارند؛ این فاصله صرفاً بازه زمانی بین یک خبر اعلامی و ثبت انتشار است و معیاری برای زمان توسعه مدل نیست. Laya نقشی مشابه Jev ایفا می‌کند اما تحت لایسنس Apache 2.0 منتشر شده است که امکان میزبانی شخصی (Self-hosting) و تغییر کامل وزن‌ها را فراهم می‌کند. در واقع، Laya به عنوان یک جایگزین متن‌باز برای APIهای بسته و گران‌قیمت معرفی شده تا کنترل بیشتری به توسعه‌دهندگان بدهد.

مشخصات فنی Laya

• معماری: چک‌پوینت انگلیسی عمومی، ترکیبی از ModernBERT-large به همراه یک لایه تصمیم‌گیر (Decision Head) است.
• پارامترها: طبق کارت مدل در نسخه‌ی مورد استفاده، این مدل دارای ۴۲۱ میلیون پارامتر است.
• کنترل نسخه: تیم تحقیق مدل convaiinnovations/laya را در ریوژن 55cf4c4ebb4ebe31b2550e8bdf3bd21b99753851 با نسخه laya==0.3.23 تثبیت کردند.
• تاریخ انتشار: نسخه Runtime در ۱ اکتبر ۲۰۲۶ منتشر شد. لازم به ذکر است که نسخه کتابخانه و ریوژن وزن‌ها دو هویت مجزا هستند که هر دو در این آزمایش منجمد (Frozen) شدند.
• چک‌پوینت‌ها: این چک‌پوینت پایه با laya-typed-decisions متفاوت است؛ چرا که دومی پیش‌تر روی جریان‌های کاری دیگر تنظیم دقیق شده بود. همچنین در این مطالعه از چک‌پوینت چندزبانه استفاده نشد.

مدل‌های تصمیم‌گیر در معماری سیستم

یک دمو برای ساخت وب‌سایت با فرمان صوتی، نقش این مدل‌ها را به‌خوبی نشان داد. سیستم یک کتابخانه شامل بیش از ۱۰۰۰ دارایی (Asset) و قطعه (Component) را مدیریت می‌کرد. جریان مفهومی به این ترتیب بود: صدا $ \rightarrow $ تبدیل متن در لحظه $ \rightarrow $ تطبیق/اصلاح زمینه $ \rightarrow $ مدل تصمیم‌گیر $ \rightarrow $ انتخاب دارایی/اکشن $ \rightarrow $ رابط کاربری (UI).

در این معماری، Jev وب‌سایت را تولید نمی‌کند. یک مدل گفتاری متن را استخراج می‌کند، لایه‌ای دیگر زمینه را نرمال‌سازی می‌کند و مدل تصمیم‌گیر از میان اکشن‌های مجاز، یکی را انتخاب می‌کند. در نهایت، کد برنامه‌نویسی مسئول اجرای و اعتبارسنجی آن اکشن‌هاست. این نشان می‌دهد که مدل‌های گفتاری، LLMها و مدل‌های تصمیم‌گیر چگونه می‌توانند نقش‌های متفاوتی را در یک سیستم واحد ایفا کنند.

آزمایش اول: شکاف Zero-Shot

برای تست مدل‌ها، محققان از یک مجموعه منجمد شامل ۷۰ تیکت مصنوعی انگلیسی استفاده کردند که پیش‌تر برای خط مبنای قطعی (Deterministic Baseline)، مدل Ollama و Jev 1.13 به کار رفته بود. هدف، پیش‌بینی درست سه فیلد «دسته»، «اولویت» و «ریسک» بود. در معیار «صحت تطابق دقیق» (Exact-tuple accuracy)، یک تیکت تنها زمانی درست محسوب می‌شود که هر سه فیلد به‌طور همزمان درست باشند.

در حالت پیش‌فرض (Out of the box)، مدل Jev 1.13 با ۶۶ مورد درست از ۷۰ مورد (۹۴.۲۹٪) بدون هیچ آموزشی در دامنه خاص، پیروز مطلق بود. تیم تحقیق نتیجه تاریخی Jev را از طریق OpenRouter در مسیر typesafe/jev-1.13 (که به نسخه typesafe/jev-1.13-20260917 ارجاع می‌داد) حفظ کردند.

در مقابل، Laya در حالت Zero-shot (بدون آموزش خاص برای این دامنه) به‌شدت دچار مشکل شد:

• صحت دسته: ۸۴.۲۹٪ (۵۹/۷۰)
• صحت اولویت: ۳۱.۴۳٪ (۲۲/۷۰)
• صحت ریسک: ۶۲.۸۶٪ (۴۴/۷۰)
• صحت تطابق دقیق: ۱۱.۴۳٪ (۸/۷۰)

یک بازرسی دقیق (Audit) نشان داد که یک شکست سیستماتیک رخ داده است: ۴۰ مورد از ۴۰ اولویت مورد انتظار «LOW» (پایین)، به‌اشتباه «MEDIUM» (متوسط) پیش‌بینی شده بودند. بازرسی روی گزینه‌ها، ترتیب، ایندکس‌ها، نگاشت‌ها، سریال‌سازی و نرمال‌سازی انجام شد و هیچ باگ یکپارچه‌سازی پیدا نشد. احتمالات آرشیو شده نشان دادند که MEDIUM در اولویت اول قرار داشت که با انتخاب منتشر شده مطابقت داشت. این تایید کرد که خطا در وزن‌های پایه مدل بود، نه در آداپتور.

چرا این نتایج با بنچمارک‌های منتشر شده Laya در تضاد نیست؟

مطالعاتی که باعث شروع این تحقیق شد، نتایج بسیار قوی‌تری را نشان می‌داد. با این حال، کارت مدل laya-typed-decisions توضیح می‌دهد که آن چک‌پوینت خاص روی جریان‌های کاری همان بنچمارک تنظیم دقیق شده بود. این کارت بین چک‌پوینت تخصصی و مدل پایه تفاوت قائل می‌شود و اشاره می‌کند که ارقام Jev توسط شخص ثالث منتشر شده و در همان اجرای فعلی اندازه‌گیری نشده‌اند. معیارهای منتشر شده مربوط به مجموعه داده، پروتکل و چک‌پوینت متفاوتی هستند و تصمیمات فردی را می‌سنجند، نه تطابق دقیق تیکت‌ها.

آزمایش دوم: قدرت تطبیق (Adaptation)

برای بررسی اینکه آیا Laya می‌تواند این شکاف را پر کند، تیم تحقیق عملیات «تطبیق دامنه» را انجام داد. آن‌ها ۱۱۲۰ تیکت مصنوعی برای آموزش (TRAIN) و ۲۸۰ تیکت برای اعتبارسنجی (VALIDATION) بر اساس تاکسونومی عملیاتی ساختند. از یک تولیدکننده قطعی (Deterministic Generator) استفاده شد تا اطمینان حاصل شود هیچ LLMی در حین ساخت، به فایل‌های کنار گذاشته شده یا خطاهای آن‌ها دسترسی ندارد.

• مجموعه TRAIN (۱۱۲۰ تیکت): برای تغییر وزن‌ها استفاده شد. برچسب‌های قطعی به اهداف One-hot تبدیل شدند (برخلاف توزیع‌های نرم در مثال‌های رسمی Laya).
• مجموعه VALIDATION (۲۸۰ تیکت): برای انتخاب بهترین چک‌پوینت استفاده شد. این مجموعه خانواده‌های سناریویی مشابه TRAIN داشت اما عبارت‌بندی‌ها متفاوت بود.
• مجموعه HELD-OUT (۷۰ تیکت): ارزیابی نهایی پس از انجماد مدل. این مجموعه در تمام مراحل تولید داده، آموزش، اعتبارسنجی، انتخاب چک‌پوینت، تعیین آستانه‌ها، کالیبراسیون و تنظیم هایپرپارامترها کاملاً خارج بود.

آموزش روی یک NVIDIA RTX A5000 با ۲۴ گیگابایت VRAM، پایتون ۳.۱۱ و PyTorch 2.5.1 با CUDA 12.1 انجام شد. فرآیند برای چهار Epoch با دقت ترکیبی (fp16 autocast و fp32 master weights) و تجمع گرادیان (Gradient Accumulation) برای مدیریت حافظه اجرا شد. چک‌پوینت‌های کاندید از دمای (Temperature) ۱.۰ استفاده کردند.

تیم با یک ناهنجاری فنی مواجه شد: GradScaler یک به‌روزرسانی بهینه‌ساز را نادیده می‌گرفت در حالی که Scheduler جلو می‌رفت. آن‌ها Scheduler را اصلاح کردند تا تنها پس از به‌روزرسانی‌های اعمال شده پیش برود. در اجرای نهایی، ۴۲۰ تلاش برای به‌روزرسانی، ۴۱۳ به‌روزرسانی اعمال شده، ۷ مورد نادیده گرفته شده توسط GradScaler و ۴۱۳ گام Scheduler ثبت شد. انتخاب بر اساس بالاترین صحت تطابق دقیق در VALIDATION بود و در صورت تساوی، از Macro-F1، میانگین Brier و زودترین Epoch استفاده شد. Epoch 4 انتخاب شد. در نهایت در Freeze 2 و کامیت 00a9a64 داده‌ها، چک‌پوینت، کد، استنتاج و آستانه‌ها پیش از ارزیابی نهایی تثبیت شدند.

پس از تطبیق، عملکرد Laya روی همان ۷۰ تیکت کنار گذاشته شده به‌طور دراماتیک تغییر کرد:

• صحت دسته: ۹۷.۱۴٪ (۶۸/۷۰)
• صحت اولویت: ۹۴.۲۹٪ (۶۶/۷۰)
• صحت ریسک: ۹۲.۸۶٪ (۶۵/۷۰)
• صحت تطابق دقیق: ۸۵.۷۱٪ (۶۰/۷۰)

خطای «پایین به متوسط» در اولویت‌ها کاملاً ناپدید شد و از ۴۰/۴۰ به ۰/۴۰ رسید.

عدم تقارن نتایج

در مقایسه این دو مدل، یک عدم تقارن شدید ظاهر می‌شود. Jev بدون هیچ آموزشی به صحت ۹۴.۲۹٪ رسید، در حالی که Laya تنها پس از مشاهده ۱۱۲۰ نمونه آموزشی توانست به ۸۵.۷۱٪ برسد.

Laya در بازخوانی ریسک‌های بالا (۷/۷) برتری اندکی داشت، هرچند تعداد کل نمونه‌ها کم بود. تنظیم دقیق همه چیز را حل نکرد: دو دسته، چهار اولویت و پنج برچسب ریسک همچنان اشتباه بودند. خطاها در فیلدهای مختلف هم‌پوشانی داشتند و ۱۰ تیکت را اشتباه کردند. نکته قابل توجه این بود که بازخوانی اولویت‌های HIGH/CRITICAL از ۱۳/۱۴ در حالت Zero-shot به ۱۲/۱۴ پس از تطبیق کاهش یافت.

کالیبراسیون و بیش‌اطمینانی

یک یافته حیاتی، تمایل Laya به «بیش‌اطمینانی» (Overconfidence) بود. پس از تطبیق، میانگین answer_confidence (احتمال گزینه برتر رند شده) تقریباً اشباع شده بود:

• دسته: ۰.۹۹۹۸۶ (Brier: ۰.۰۵۷۱۵, ECE: ۰.۰۲۸۴۴)
• اولویت: ۰.۹۹۹۹۷ (Brier: ۰.۱۱۴۲۹, ECE: ۰.۰۵۷۱۱)
• ریسک: ۰.۹۹۸۸۴ (Brier: ۰.۱۳۸۴۱, ECE: ۰.۰۷۰۲۷)

با وجود این، ۱۰ مورد از ۷۰ تیکت همچنان اشتباه بودند. یک تست گیت اکتشافی نشان داد که آستانه‌های بین ۰.۹۰ تا ۰.۹۹ به‌سختی توانستند خطاها را فیلتر کنند و ۶۹ مورد از ۷۰ تیکت را با صحت ۸۶.۹۶٪ حفظ کردند. این تایید می‌کند که اطمینان بالا به‌طور خودکار به معنای احتمال بالای درست بودن نیست. Jev اطمینان خود را گزارش می‌کند، در حالی که Laya بین answer_confidence و اطمینان مبتنی بر آنتروپی تفاوت قائل می‌شود؛ این تفاوت‌های معنایی مقایسه مستقیم مقادیر را غیرممکن می‌کند.

شکاف بین یادگیری و تعمیم

افت عملکرد در بخش‌های مختلف داده‌ها گویای همه چیز بود:

• TRAIN: ۱۰۰٪ تطابق دقیق
• VALIDATION: ۹۲.۵۰٪ تطابق دقیق
• HELD-OUT: ۸۵.۷۱٪ تطابق دقیق

با توجه به اینکه Loss در Epoch نهایی برای TRAIN صفر ثبت شد و اطمینان مدل اشباع شده بود، این نتایج با پدیده «حفظ کردن» (Memorization) و بیش‌اطمینانی سازگار است. نمونه‌ها برای تخمین کامل شکاف تعمیم در محیط عملیاتی بسیار کم هستند، اما روند آن کاملاً مشهود است.

هزینه کنترل

متن‌باز بودن به معنای هزینه صفر نیست. در حالی که Laya هیچ هزینه‌ای بابت توکن‌های API تحمیل نکرد، بار را به زیرساخت و مهندسی منتقل کرد.

تأخیر و محاسبات:

• تأخیر (Latency): روی یک CPU با چهار vCPU مدل AMD EPYC (در حالت fp32)، مدل Laya پایه به‌طور متوسط ۱۴۱۴ میلی‌ثانیه و Laya تطبیق‌یافته ۱۶۱۹ میلی‌ثانیه برای هر تیکت زمان برد. فراخوانی‌های API مدل Jev به‌طور متوسط ۵۶۹ میلی‌ثانیه بودند. زمان‌بندی Laya شامل توکن‌سازی، استنتاج روی سه سوال، تجزیه و اعتبارسنجی است.
• هزینه محاسباتی: وظایف آموزشی (حدود ۲۵ دقیقه و ۲۴ ثانیه روی A5000) بر اساس نرخ Pod حدود ۰.۲۷ دلار در ساعت، تقریباً ۰.۱۱۸۵ دلار تخمین زده شد. این مبلغ شامل زمان راه‌اندازی و زمان‌های بیکاری نمی‌شود.
• هزینه API: اجرای تاریخی Jev برای ۷۰ درخواست، مبلغ ۰.۰۰۳۷۸۹۶۱۸ دلار هزینه داشت.

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

تحلیل: راحتی در برابر حاکمیت

برای اکثر کاربران، عملکرد آماده‌ی Jev آن را به انتخابی بدیهی تبدیل می‌کند، زیرا نیاز به تولید داده‌های مصنوعی و مدیریت GPU را از بین می‌برد.

اما برای سازمان‌هایی با الزامات سخت‌گیرانه در مورد حاکمیت داده (Data Sovereignty) یا تاکسونومی‌های بسیار خاص، معماری Laya ارزشمندتر است. توانایی تغییر وزن‌ها به این معناست که شما به چرخه به‌روزرسانی‌های عمومی یک ارائه‌دهنده وابسته نیستید. شما مالک رفتار مدل هستید، اما در عین حال مالک شکست‌های آن نیز هستید.

محدودیت‌ها و کارهای آینده

این مطالعه محدودیت‌هایی داشت: مجموعه داده کوچک و مصنوعی (۷۰ تیکت انگلیسی)، نبود ترافیک واقعی تولیدی و تفاوت در سخت‌افزار و تاریخ اندازه‌گیری دو مدل. چک‌پوینت تطبیق‌یافته (حدود ۸۴۳ مگابایت) برای دانلود عمومی در دسترس نیست. Jev و Laya در Ops Triage فقط برای ارزیابی بودند و در HybridPolicy ادغام نشدند.

برای انتقال این سیستم به محیط تولید واقعی، اقدامات زیر لازم است:
۱. استفاده از تیکت‌های واقعی برچسب‌دار، با جداسازی سناریوها، منابع و بازه‌های زمانی تا VALIDATION صرفاً بازنویسی TRAIN نباشد.
۲. تعیین معیارهای پذیرش بر اساس شدت خطا و هزینه هر اشتباه پیش از ارزیابی نهایی.
۳. استفاده از داده‌های مجزا و نماینده برای کالیبراسیون و ایجاد سیستم‌های جایگزین با حضور انسان (Human-in-the-loop).
۴. اندازه‌گیری واریانس، توان عملیاتی (Throughput) و حافظه در مسیرهای واقعی سرویس‌دهی.
۵. نسخه‌بندی وزن‌ها و پیکربندی‌ها در کنار داده‌ها و کد برای نظارت بر رانش (Drift)، تایید لایسنس‌ها و آماده‌سازی برای بازگشت (Rollback).

تصمیمات تایپ‌شده یکپارچه‌سازی را ساده می‌کنند، اما قابلیت اطمینان همچنان به سیستم پیرامونی وابسته است.

گام بعدی شما

• اگر از مدل‌های LLM برای استخراج داده‌های ساختاریافته استفاده می‌کنید، مدل‌های تصمیم‌گیر (Decision Models) را برای کاهش خطای Parsing بررسی کنید.
• برای مدل‌های وزن‌باز، به‌جای تکیه بر Zero-shot، روی تولید داده‌های مصنوعی (Synthetic Data) با کیفیت برای تنظیم دقیق تمرکز کنید.
• در سیستم‌های حساس، هرگز به عدد Confidence مدل اعتماد نکنید و یک لایه اعتبارسنجی انسانی یا قاعده‌مند اضافه کنید.

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