۱۵ میلی‌ثانیه. این کفِ جدید تأخیر برای تسک‌های طبقه‌بندی است، وقتی یک مدل محلی پاسخ‌های یک مدل زبانی بزرگ را با تضمین ۹۸ درصدی تقلید می‌کند. Jevstiller با تبدیل نرخ توافق از یک تخمین ساده به یک قرارداد سخت‌گیرانه، سرعت را ۲۰ برابر افزایش داده است تا پایداری تولید در حلقه‌های عامل‌محور و تیک‌های بازی تضمین شود.
بسیاری از توسعه‌دهندگان هنگام تقطیر (Distillation) — شبیه وقتی که عصاره یک کتاب هزار صفحه‌ای را در یک برگه خلاصه می‌کنیم تا سریع‌تر خوانده شود — از قوانین تخمینی (point-estimate) استفاده می‌کنند. آن‌ها یک حد آستانه اطمینان را روی یک مجموعه داده کوچک انتخاب می‌کنند و امیدوارند این حد در محیط تولید (Production) نیز پابرجا بماند. اما طبق داده‌های سپتامبر ۲۰۲۶، این رویکرد تقریباً در نیمی از موارد شکست می‌خورد، زیرا این روش باعث می‌شود مدل روی نویزهای موجود در نمونه‌های محدود متمرکز شود.
تصور کنید در حال ساخت یک عامل (Agent) هستید که باید در چند میلی‌ثانیه تصمیم بگیرد و عمل کند. یک فراخوانی شبکه به یک ارائه‌دهنده خارجی (Vendor) ۳۰۰ میلی‌ثانیه زمان می‌برد، که عملاً تمام بودجه زمانی شما را می‌بلعد. با قرار دادن یک مدل محلی در ابتدای این فراخوانی، می‌توانید اکثریت قریب به اتفاق درخواست‌ها را به‌صورت محلی روی CPU پردازش کنید، بدون اینکه قابلیت‌های مدل «معلم» بزرگ‌تر را فدا کنید. همان‌طور که در تحلیل‌های قبلی ما درباره بهینه‌سازی مدل‌های لبه اشاره کردیم، کاهش وابستگی به APIهای ابری کلید دستیابی به پاسخ‌های آنی است؛ موضوعی که در بررسی سرعت مدل‌های کوچک تنظیم‌شده در مقایسه با APIها به تفصیل به آن پرداختیم.
قرارداد در یک خط
برای درک این سازوکار، ابتدا باید قرارداد را تعریف کنیم. برای هر تسک در یک بازه ترافیکی، سیستم دو معیار اصلی را ردیابی می‌کند:
- پوشش (Coverage - c): سهم درخواست‌هایی که مدل محلی به آن‌ها پاسخ می‌دهد.
- عدم توافق (Disagreement - e): سهم درخواست‌های پاسخ‌داده‌شده که در آن‌ها برچسب مدل محلی با برچسب مدل معلم (Jev) متفاوت است.
درخواست‌هایی که مدل محلی رد می‌کند، مستقیماً به Jev می‌روند و طبق تعریف با آن توافق دارند. بنابراین، توافق کل سیستم با بودجه $\beta = 1 - A^$ تعریف می‌شود، که در آن $A^$ هدف توافق است (مثلاً ۹۸٪). در سطح ۹۸٪، بودجه $\beta$ برابر با ۲ در ۱۰۰ است. تنها وظیفه مسیریاب (Router) این است که پوشش $c$ را به حداکثر برساند، در حالی که حاصل‌ضرب $c \cdot e$ زیر مقدار $\beta$ باقی بماند.
نکته مهم این است که این قرارداد، صحت (Accuracy) را نسبت به حقیقت مطلق نمی‌سنجد. اگر مدل Jev اشتباه کند، مدل محلی هم به همان شکل اشتباه می‌کند. هدف اینجا توافق روی تمام درخواست‌هاست، نه دقت مدل محلی روی زیرمجموعه‌ای که خودش برای پاسخ دادن انتخاب کرده است.
شکست روش‌های متداول
دستورالعمل‌های استاندارد تقطیر معمولاً شامل پیمایش (Sweep) یک حد آستانه اطمینان و نگه داشتن سهل‌گیرانه‌ترین حدی است که از یک مجموعه تست عبور کند. Jevstiller این قانون «تخمینی» را روی ۵ تسک عمومی با ۲۰ تقسیم‌بندی تصادفی برای هر کدام آزمایش کرد. بر اساس مستندات این پروژه، نتایج بسیار متناقض بود:
- Banking77 (۷۷ قصد/Intent): قانون تخمینی در ۹ مورد از ۲۰ تقسیم‌بندی بودجه ۲٪ را شکست. میانگین عدم توافق ۱.۹۰٪ بود اما بدترین حالت به ۲.۷۰٪ رسید. در مقابل، قانون Bound در هیچ‌کدام از ۲۰ مورد شکست نخورد و میانگین ۱.۱۵٪ داشت.
- CLINC150 (۱۵۱ قصد): این روش در ۱۲ مورد از ۲۰ تقسیم‌بندی شکست خورد و عدم توافق به ۲.۸۵٪ رسید، در حالی که بودجه ۲٪ بود. قانون Bound در هیچ‌کدام شکست نخورد.
- AG News (۴ کلاس): قانون تخمینی در ۱۱ مورد از ۲۰ تقسیم‌بندی شکست خورد (بدترین حالت ۲.۶۵٪)، در حالی که قانون Bound در هیچ‌کدام شکست نخورد.
- TweetEval Sentiment: در ۸ مورد از ۲۰ تقسیم‌بندی شکست خورد (بدترین حالت ۲.۶۰٪). قانون Bound تنها در ۱ مورد از ۲۰ شکست خورد و به ۲.۱۰٪ رسید.
- TweetEval Offensive: در ۶ مورد از ۲۰ تقسیم‌بندی شکست خورد (بدترین حالت ۲.۷۰٪). قانون Bound در هیچ‌کدام شکست نخورد.
این اتفاق به این دلیل رخ می‌دهد که سهل‌گیرانه‌ترین آستانه عبور در داده‌های محدود، ترجیحاً آستانه‌ای را انتخاب می‌کند که در آن نویز به‌طور اتفاقی رو به پایین بوده است. وقتی مدل با ترافیک واقعی مواجه می‌شود، نویز تغییر می‌کند و بودجه شکسته می‌شود. در ۱۰۰ تقسیم‌بندی، قانون Bound تنها یک بار بودجه را شکست (۲.۱۰٪) که با توجه به اینکه این یک بیانیه اطمینان ۹۵٪ است، کاملاً مورد انتظار است.
سازوکار فنی Jevstiller
برای حل این مشکل، Jevstiller چهار تصمیم فنی خاص می‌گیرد تا تضمین کند قرارداد توافق با احتمال حداقل ۹۵٪ برای هر نسخه تولیدی برقرار باشد:
- تابع زیان مبتنی بر قرارداد (Contract-Based Loss): سیستم از کران اطمینان Clopper–Pearson روی یک مجموعه کالیبراسیون استفاده می‌کند که IID (مستقل و دارای توزیع یکسان) است و هرگز برای آموزش به کار نرفته است. این سیستم نمره ۱ را برای حالتی که مدل محلی پاسخ دهد و با معلم مخالفت کند، و نمره ۰ برای سایر حالات در نظر می‌گیرد. میانگین این شاخص دقیقاً همان «عدم توافق روی تمام درخواست‌ها» است. این روش یک کران دوجمله‌ای دقیق فراهم می‌کند بدون اینکه به تقریب‌های نمونه‌های بزرگ نیاز باشد.
- تست توالی ثابت (Fixed-Sequence Testing): مسیریاب آستانه‌ها را از سخت‌گیرانه‌ترین به سهل‌گیرانه‌ترین روی یک شبکه ثابت تست می‌کند و در اولین شکست متوقف می‌شود. از آنجایی که نرخ خطا با سهل‌گیرتر شدن آستانه فقط رشد می‌کند، حرکت از سخت به سهل، احتمال انتخاب اشتباه را در ۵٪ کنترل می‌کند بدون اینکه نیازی به اصلاحات برای مقایسه‌های متعدد باشد. این همان تست توالی ثابت است که در متدولوژی «ابتدا یاد بگیر، سپس تست کن» (Learn Then Test) دیده می‌شود.
- جداسازی کالیبراسیون (Calibration Isolation): سیستم تضمین می‌کند که گیتِ خارج از توزیع (که ورودی‌های ناشناخته را به Jev می‌فرستد) و آستانه‌های کاندید، روی ردیف‌های کالیبراسیون تنظیم نشوند. نقطه قطع گیت از داده‌های آموزشی استخراج می‌شود. اگر این‌ها روی ردیف‌های کالیبراسیون تنظیم می‌شدند، کران روی داده‌هایی محاسبه می‌شد که قبلاً برای انتخاب خودِ کران استفاده شده‌اند؛ یعنی همان اشتباه قانون تخمینی.
- حاشیه امنیت بودجه (Budget Headroom): آستانه‌ها ابتدا روی ۸۵٪ از بودجه تنظیم می‌شوند. سپس باید یک بررسی دوم را در سطح بودجه کامل با استفاده از مجموعه‌ای از ردیف‌های کالیبراسیون و ترافیک سایه (Shadow Traffic) تازه پاس کنند. این کار آستانه‌هایی را که دقیقاً روی خط مرزی قرار دارند، شناسایی و حذف می‌کند.
مدیریت عدم قطعیت و رانش
یک ریسک بزرگ در طبقه‌بندی انتخابی، از دست دادن پرچم‌های «نامطمئن» (unsure) است. مدل‌های بزرگ اغلب نمرات اطمینان پایینی برمی‌گردانند که باعث تحریک دخالت انسان می‌شود. مدل محلی که فقط وقتی مطمئن است پاسخ می‌دهد، به‌طور خاموش این پرچم‌ها را حذف می‌کند. در تسک‌های بنچمارک، یک بررسی در سطح اطمینان ۰.۶ باعث شد ۸٪ تا ۳۷٪ از پرچم‌هایی که Jev ایجاد می‌کرد، از دست بروند. این چالش با شناسایی موارد لبه‌ای و نقاط کور در جریان‌های کاری مرتبط است که می‌تواند منجر به شکست‌های پیش‌بینی‌نشده در سیستم شود.
برای رفع این مشکل، Jevstiller مفهومی به نام confidence_floor (کف اطمینان) را معرفی می‌کند. اگر مدل معلم پاسخی زیر این کف می‌داد، پاسخ مدل محلی به عنوان یک «عدم توافق» ثبت می‌شود. این کار تضمین می‌کند درخواست‌هایی که معلم درباره آن‌ها نامطمئن بود، همچنان به معلم ارجاع شوند، هرچند این کار باعث کاهش ۴ تا ۱۲ واحدی در پوشش (در کف ۰.۶) می‌شود. بودجه ۲٪ یکسان، هم عدم توافق برچسب و هم از دست دادن پرچم‌های عدم قطعیت را پوشش می‌دهد.
نگهداری این تضمین پس از روز اول نیازمند ممیزی دائمی است. Jevstiller به‌صورت ثابت ۲٪ از تمام درخواست‌ها را صرف‌نظر از میزان اطمینان مدل محلی به معلم می‌فرستد. این تنها راه مشاهده بدون سوگیری از عملکرد در محیط تولید است، زیرا درخواست‌هایی که مدل محلی رد می‌کند، ذاتاً سخت هستند.
در یک تست ۲۴ ساعته (Soak Test)، مدل معلم در ساعت دوازدهم به‌طور خاموش تمام پاسخ‌هایش را تغییر داد. ممیزی این تغییر را فوراً شناسایی کرد. سهم مدل محلی در عرض چهار دقیقه از ۹۰٪ به ۹٪ افت کرد و سیستم در ۴۹ دقیقه بدون دخالت انسان، خود را دوباره آموزش داد تا به پوشش ۹۰٪ برسد، در حالی که فقط روی پاسخ‌های پس از تغییر آموزش می‌دید.
موازنه عملکرد
این رویکرد محافظه‌کارانه هزینه‌ای در پوشش دارد. Jevstiller در مقایسه با روش ریسکی تخمینی، ۴ تا ۸ درصد از پوشش را فدا کرد. با این حال، آموزش روی توزیع‌های احتمالی کامل به جای فقط برچسب برتر (Top Label)، ۲ تا ۳ درصد در تسک‌های چندکلاسه را بازگرداند.
تغییر هدف توافق تأثیر زیادی دارد. تغییر هدف از ۹۸٪ به ۹۵٪، نرخ پاسخ‌های محلی را در تسک‌های مبتنی بر توییتر تقریباً دو برابر کرد و تسک‌های مربوط به قصد (Intent) را از ۷۰٪ به ابتدای ۸۰٪ رساند. جالب اینجاست که صحت نسبت به برچسب‌های مرجع (Ground-truth) در بازه ۹۰٪ تا ۹۹٪، در فاصله یک نقطه از مدل معلم باقی ماند.
این نشان می‌دهد وقتی مدل محلی با معلم متفاوت است، تقریباً به همان اندازه معلم درست است. اما این یک قانون جهانی نیست. در تسک‌های نویزی مثل TweetEval، جایی که معلم تنها ۶۴٪ و ۷۴٪ با انسان‌ها توافق دارد، مدل محلی نمی‌تواند نویز را در بودجه ۲٪ بازتولید کند. در این حالت، مدل فقط به یک‌چهارمِ مطمئن پاسخ می‌دهد و بقیه را ارجاع می‌دهد.
تحلیل: تغییر پارادایم تقطیر
برای توسعه‌دهندگان، این نشان‌دهنده تغییری از تقطیر «بهترین تلاش» (best-effort) به تقطیر «تضمین‌شده» (guaranteed) است. اکثر استقرار‌های SLM (مدل‌های زبانی کوچک) در حال حاضر یک قمار روی این موضوع هستند که آیا مجموعه اعتبارسنجی، نماینده توزیع تولید است یا خیر. با پیاده‌سازی یک قرارداد توافق رسمی، Jevstiller مسیریابی مدل را به یک محدودیت مهندسی پیش‌بینی‌پذیر تبدیل می‌کند.
این رویکرد به نفع جریان‌های کاری عامل‌محور با فرکانس بالا است که در آن‌ها تأخیر ۳۰۰ میلی‌ثانیه‌ای یک عامل شکست‌دهنده است. این به تیم‌ها اجازه می‌دهد مدل‌های محلی را با این اطمینان مستقر کنند که به‌طور خاموش یک نرخ خطای ۵ درصدی را وارد سیستم نمی‌کنند. نوآوری واقعی نه در اندازه مدل، بلکه در ادغام تشخیص رانش (Drift Detection) و بازآموزی خودکار در منطق مسیریابی است. برای کسانی که به دنبال جایگزین‌های متن‌باز با تأخیر پایین هستند، مقایسه مدل Laya در برابر Jev دیدگاه‌های مفیدی درباره جایگزینی APIهای گران‌قیمت ارائه می‌دهد.
این اثر بر پایه طبقه‌بندی انتخابی با تضمین‌های ریسک (Geifman and El-Yaniv, 2017) و تست توالی ثابت از «Learn Then Test» بنا شده است. در حالی که یادگیری آبشاری از مدل‌های بزرگ در OCaTS (2023) و Cache & Distil (2024) ظاهر شده و BARGAIN تضمین‌های نمونه محدود را برای پردازش دسته‌ای فراهم می‌کند، Jevstiller این‌ها را در یک سیستم جاری با بازآموزی مداوم و ممیزی دائمی ترکیب می‌کند.
گام بعدی شما
- مخزن Jevstiller را از گیت‌هاب کلون کرده و اسکریپت‌های بازتولید را اجرا کنید. نتیجه Banking77 از پاسخ‌های ضبط‌شده حدود ۱۰ دقیقه و بنچمارک کامل ۵ تسک یک تا دو ساعت زمان می‌برد.
- اگر از مدل‌های محلی برای کاهش هزینه استفاده می‌کنید، یک ممیزی ۲ درصدی (Random Audit) را برای شناسایی رانش مدل (Model Drift) پیاده کنید.
- از Docker برای استقرار سریع استفاده کنید،
TYPESAFE_BASE_URLرا به آن اشاره دهید و گزارش وضعیت را پس از چند هزار درخواست بررسی کنید تا کران به‌دست‌آمده و بازه ممیزی را ببینید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو