آیا خواندن Logprobs می‌تواند مدل‌های زبانی را به سرعت Jev برساند؟

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

در ۲۴ سپتامبر ۲۰۲۶، مارکو روزنمولر (PhD) و تیم Privatemode نشان دادند که مدل GLM-5.3-Flash می‌تواند بدون هیچ‌گونه تنظیم دقیق (Fine-tuning) — شبیه وقتی به یک پزشک عمومی، تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود — به‌عنوان یک مدل «سیستم یک» (System One) عمل کند. این یعنی مدل به‌جای تفکر طولانی و گام‌به‌گام، سریعاً و به‌صورت غریزی تصمیم می‌گیرد.

بسیاری از تعاملات نرم‌افزاری با مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در واقع همان تصمیم‌گیری هستند؛ مثلاً مسیریابی یک تیکت پشتیبانی («کدام تیم باید این تیکت را مدیریت کند؟») یا طبقه‌بندی یک بند در قرارداد («آیا این بند مربوط به بخش مسئولیت‌ها است؟»). طبق گزارش این تیم، توسعه‌دهندگان معمولاً مدل را مجبور می‌کنند خروجی JSON یا کلمات خاصی مثل «بله» یا «خیر» تولید کند که به‌دلیل تولید توکن‌های متعدد، کند و گران است. مدل‌های استدلالی حتی ممکن است صدها توکن فکر کنند و سپس پاسخ نهایی را ارائه دهند. این تأخیر و هزینه، مدل‌های عمومی LLM را برای محیط‌های عملیاتی با حجم بالای درخواست (High-throughput) غیرعملی می‌کند.

همان‌طور که در تحلیل قبلی ما درباره‌ی CLM-8B اشاره کردیم، مدل‌های بازِ سیستم یک می‌توانستند اقدامات عامل‌ها را بسیار سریع‌تر از Jev امتیازدهی کنند. این رویکرد در واقع پاسخی به محدودیت‌های خروجی‌های ساختاریافته است که در بررسی ما پیرامون تبدیل خروجی‌های JSON به موتورهای تصمیم‌گیرنده به تفصیل مورد بحث قرار گرفت. اکنون این رویکرد جدید ثابت می‌کند که مدل‌های چندمنظوره نیز می‌توانند برای همین نقش سازگار شوند. در حالی که مدل‌هایی مثل Jev و Laya به‌طور خاص برای تصمیم‌گیری آموزش دیده‌اند — جایی که شما یک وضعیت (State) و گزینه‌های نام‌گذاری شده را وارد می‌کنید تا یک گزینه منتخب و مقدار اطمینان (Confidence) دریافت کنید — روش Privatemode از سازوکار ذاتی LLMها در محاسبه احتمالات توکن‌ها بهره می‌برد.

سازوکار: تبدیل تولید متن به تحلیل احتمال

یک LLM مستقیماً متن نمی‌نویسد؛ بلکه برای هر توکن، یک توزیع احتمالی روی کل واژگان (Vocabulary) خود خروجی می‌دهد. در حالت عادی تولید متن، توکنی با بیشترین احتمال انتخاب، به پرامپت اضافه شده و این فرآیند تکرار می‌شود. تیم Privatemode متوجه شد اگر قالب خروجی از پیش مشخص باشد، مدل نیازی به «نوشتن» واقعی پاسخ ندارد.

برای اجرای این متد، یک فرآیند سه مرحله‌ای طی می‌شود:

• شماره‌گذاری گزینه‌ها: وضعیت، سؤال و گزینه‌های خروجی به‌صورت JSON در پرامپت قرار می‌گیرند. هر گزینه یک شاخص (Index) اختصاص می‌یابد. دستورالعمل‌ها صراحتاً از مدل می‌خواهند که پاسخ را با عبارت choice_index: و سپس شماره شاخص شروع کند.
• پیش‌پُرکردن پاسخ (Answer Prefilling): پرامپت با عبارت choice_index: به پایان می‌رسد. این کار مدل را مجبور می‌کند اولین توکن پیش‌بینی‌شده‌اش، حتماً یکی از شماره‌های گزینه‌های تعریف‌شده باشد.
• ارزیابی احتمال: سیستم به‌جای خواندن توکن تولیدشده، احتمالات تخصیص‌یافته به تمام شماره‌های گزینه‌ها را در همان یک موقعیت (Position) می‌خواند. این احتمالات روی گزینه‌ها نرمال‌سازی می‌شوند تا برای هر پاسخ یک احتمال به دست آید و محتمل‌ترین گزینه انتخاب شود.

این ساختار با استفاده از vLLM در محیط Privatemode پیاده‌سازی شده است. تیم از اندپوینت /chat/completions با تنظیمات continue_final_message و add_generation_prompt: false استفاده کرد. این تنظیمات خاص به مدل اجازه می‌دهد به‌جای شروع یک نوبت جدید، دقیقاً نوبت پیش‌پُر شده‌ی دستیار در مرحله دوم را ادامه دهد. همچنین این روش امکان ارسال تصاویر در کنار متن را فراهم می‌کند.

حفاظ‌های فنی و پیاده‌سازی

برای تضمین پایداری و قابلیت اطمینان، تیم از allowed_token_ids در vLLM استفاده کرد تا واژگان خروجی را به‌طور سخت‌گیرانه فقط به شماره‌های گزینه‌های مجاز محدود کند. این کار مانند یک نرده ایمنی عمل می‌کند و هر توکن دیگری را به منفی بی‌نهایت (-inf) می‌برد تا احتمال انتخاب آن‌ها صفر شود.

آن‌ها دریافتند که استفاده از top_logprobs استاندارد کافی نیست، زیرا توکن‌های فرمت‌بندی (مانند یک فاصله در ابتدای متن) اغلب جایگاه‌های برتر را اشغال می‌کردند. این موضوع باعث می‌شد برخی گزینه‌ها از لیست حذف شوند و احتمال آن‌ها صفر به نظر برسد. در عوض، آن‌ها از logprob_token_ids استفاده کردند که احتمال لگاریتمی دقیقاً برای شناسه‌های توکنی (Token IDs) که کاربر درخواست کرده است را برمی‌گرداند.

از آنجا که توکن‌سازی (Tokenization) — یعنی تبدیل متن به تکه‌های کوچک شبیه برش‌های یک کیک — در هر مدل متفاوت است (مثلاً مدل GLM-5.3-Flash برای عدد «12» یک توکن واحد دارد)، کتابخانه آن‌ها به‌طور پویا شناسه‌های توکن را از سرور می‌گیرد. این کار با ارسال یک پرامپت به /completions با قابلیت echo فعال انجام می‌شود که توکن‌سازی دقیق مورد استفاده در سرور را بازمی‌گرداند.

نتایج محک: GLM-5.3-Flash در برابر Jev و Laya

این رویکرد با استفاده از یک محک سفارشی روی ۲۹ مجموعه داده عمومی و برچسب‌دار آزمایش شد. این مجموعه‌ها شامل گزینه‌هایی بین ۲ تا ۱۵۱ مورد بودند و حوزه‌هایی چون مسیریابی قصد (Intent Routing)، تحلیل احساسات، طبقه‌بندی موضوع، نظارت (Moderation)، استلزام (Entailment)، پاسخ به سؤال، متون حقوقی و اسناد اسکن‌شده در هر دو زبان انگلیسی و آلمانی را پوشش می‌دادند.

برای اطمینان از دقت، هر مجموعه داده دو بار اجرا شد. حتی در دمای (Temperature) صفر، مدل‌های GLM-5.3-Flash و Jev در ۳.۵٪ موارد پاسخ‌های متفاوتی دادند. این تفاوت به دلیل عملیات دسته‌بندی (Batching) و محاسبات ممیز شناور در سرورهای شلوغ است که مانع از بازتولید بیت‌به‌بیت (Bit-reproducibility) می‌شود. این تفاوت‌های کوچک به‌عنوان نویز در نظر گرفته شدند.

• صحت (Accuracy): در ۲۸ مجموعه داده متنی، GLM-5.3-Flash و Jev در یک سطح بودند. هر یک در ۱۰ مجموعه داده دقیق‌تر بود و در ۸ مورد باقی‌مانده، اختلاف آن‌ها کمتر از یک درصد بود. میانگین شکاف ۰.۷ درصد به نفع Jev بود (p = 0.64) که از نظر آماری معنی‌دار نیست.
• عملکرد Laya: مدل Laya با ۴۲۱ میلیون پارامتر که به‌صورت محلی اجرا شد، به‌طور قابل‌توجهی ضعیف‌تر بود و میانگین شکاف دقتی آن به ۱۳ تا ۱۵ درصد رسید (p < 0.001).
• مقیاس گزینه‌ها: تعداد گزینه‌ها تأثیر بیشتری از نوع مدل بر دقت داشت. در مجموعه داده TREC، افزایش گزینه‌ها از ۶ به ۴۲، باعث شد دقت Jev از ۹۲.۱٪ به ۸۵.۶٪، GLM از ۹۱.۲٪ به ۷۹.۶٪ و Laya از ۸۸.۴٪ به ۵۱.۲٪ سقوط کند. در مقابل، در مجموعه داده MASSIVE، انتقال از ۱۸ سناریو به ۵۹ قصد، در واقع امتیازات Jev و GLM-5.3-Flash را افزایش داد.

تحلیل تأخیر و هزینه

تأخیر (Latency) به‌گونه‌ای اندازه‌گیری شد که هر بار یک درخواست ارسال شود تا زمان‌های صف انتظار حذف شوند. به‌دلیل تفاوت مکان سرورها (اتحادیه اروپا برای Privatemode و آمریکا برای Jev)، نتایج بر اساس منطقه متفاوت بود:

• از آلمان: Privatemode در ۱۸۰ میلی‌ثانیه و Jev در ۲۶۴ میلی‌ثانیه پاسخ داد.
• از آمریکا: Jev در ۱۶۴ میلی‌ثانیه و Privatemode در ۲۹۹ میلی‌ثانیه پاسخ داد.

هزینه استنتاج تفاوت اصلی است. یک میلیون تصمیم با GLM-5.3-Flash حدود ۶۲ یورو و با Jev حدود ۱۶ یورو هزینه دارد. این تفاوت ناشی از قیمت توکن‌های ورودی و نحوه بسته‌بندی پرامپت است. مدل Jev حدود ۲۷۰ توکن سربار ثابت و ۱۰ توکن به ازای هر گزینه اضافه می‌کند. پرامپت GLM-5.3-Flash حدود ۵۵ توکن سربار ثابت و ۲۰ توکن به ازای هر گزینه دارد. در نتیجه، GLM برای لیست‌های زیر ۲۱ گزینه، توکن‌های کمتری ارسال می‌کند اما برای لیست‌های بزرگ‌تر، گران‌تر می‌شود.

مزیت چندوجهی (Multimodal)

یک پیشرفت کلیدی، توانایی انجام تصمیمات تایپ‌شده روی تصاویر است؛ قابلیتی که Jev و Laya ندارند، زیرا Jev روی متن کار می‌کند و Laya یک رمزگذار متن (Text Encoder) است. چون GLM-5.3-Flash یک مدل چندوجهی (Multimodal) است — یعنی مثل ما با چند حس دنیا را می‌خواند و هم‌زمان متن و عکس را می‌فهمد — کاربران می‌توانند فاکتورهای اسکن‌شده، عکس بسته‌های آسیب‌دیده یا اسکرین‌شات‌ها را به همان پرامپت ارسال کنند.

در محک RVL-CDIP که شامل ۱۶۰۰ سند تجاری اسکن‌شده در ۱۶ کلاس مختلف است، GLM-5.3-Flash به صحت ۷۰.۲٪ رسید. البته پردازش این اسناد گران‌تر است؛ هر تصویر حدود ۱۳۵۰ توکن ورودی اضافه می‌کند که هزینه را به حدود ۲۷۰ یورو به ازای هر میلیون تصمیم می‌رساند.

مدیریت وظایف پیچیده

در تعداد گزینه‌های بالا، سیستم به سقف‌های فنی می‌رسد. استقرار Privatemode برای GLM-5.3-Flash حداکثر ۱۲۸ ورودی را در logprob_token_ids گزارش می‌کند، هرچند ماسک allowed_token_ids می‌تواند موارد بیشتری را مدیریت کند.

برای دور زدن این محدودیت، کتابخانه برای وظایفی با بیش از ۱۲۸ گزینه، سؤال را دو بار ارسال می‌کند. سیستم ۱۲۸ احتمال اول را از پاسخ اول و مابقی (مثلاً ۲۳ مورد از ۱۵۱ مورد) را از پاسخ دوم می‌خواند. در مجموعه داده CLINC150، این متد اجازه داد GLM-5.3-Flash به صحت ۸۷.۵٪ برسد و از رقم ۷۸.۴٪ مدل Jev پیشی بگیرد. البته این کار تأخیر را افزایش داد و زمان تصمیم‌گیری به ۷۱۹ میلی‌ثانیه در مقابل ۲۴۹ میلی‌ثانیه Jev رسید. سقف مطلق ۱۹۱ شاخص گزینه است، زیرا این آخرین عددی است که GLM-5.3-Flash آن را به‌عنوان یک توکن واحد می‌شناسد.

یافته‌های تکمیلی و هزینه استدلال

تیم متوجه شد برخی خطاها در خودِ برچسب‌های مرجع (Labels) وجود دارد. در مجموعه داده banking77، حدود ۱۷٪ نمونه‌ها دو پاسخ قابل دفاع داشتند (مثلاً get_physical_card در مقابل order_physical_card)، به این معنی که حداکثر امتیاز ممکن حدود ۸۵٪ است.

به‌عنوان یک کنترل، تیم بررسی کرد که آیا اجازه دادن به مدل برای «استدلال» یا زنجیره تفکر (Chain-of-Thought) — مثل وقتی شاگرد ریاضی پای تخته بلند بلند فکر می‌کند تا به جواب برسد — نتایج را بهبود می‌بخشد یا خیر. اگرچه صحت افزایش یافت (مثلاً رسیدن به ۸۲.۰٪ در مقابل ۷۹.۲٪ برای وظایفی با ۲۱ تا ۸۰ گزینه)، اما هزینه به شدت بالا رفت و به ۳۵۰ یورو به ازای هر میلیون تصمیم رسید، چون مدل مجبور بود برای هر تصمیم صدها توکن بنویسد.

در مقابل، شباهت ساده‌ی بردار معنایی (Embedding Similarity) — یعنی انتخاب نزدیک‌ترین گزینه بدون استفاده از مدل تصمیم‌گیرنده — عملکرد ضعیفی داشت و تنها بین ۴۵.۹٪ تا ۷۲.۸٪ صحت به دست آورد. تیم همچنین دریافت که تغییر نام گزینه‌ها به مترادف‌ها، تأثیر متفاوتی روی مدل‌ها دارد؛ در مجموعه boolq، تغییر «درست/نادرست» به «صحیح/غلط» باعث شد GLM-5.3-Flash ۲۰ امتیاز از دست بدهد، در حالی که Jev و Laya کمتر از سه امتیاز کاهش داشتند.

امنیت و محرمانگی

از آنجا که این تصمیمات روی Privatemode میزبانی می‌شوند، از رایانش محرمانه (Confidential Computing) استفاده می‌کنند. این یعنی داده‌ها در حین پردازش در حافظه رمزگذاری شده‌اند و مشتریان می‌توانند پیش از ارسال داده‌های حساس، استقرار را از طریق یک گزارش تأییدیه (Attestation Report) بررسی کنند.

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

برای کسانی که می‌خواهند این روش را پیاده کنند، کتابخانه پایتون با هر اندپوینتی که از vLLM پشتیبانی کند سازگار است. متدولوژی، مشخصات داده‌ها، ابزار تست و نتایج خام برای بازتولید کامل در مخزن عمومی پروژه در دسترس است.

گام بعدی شما

• اگر از vLLM استفاده می‌کنید، به‌جای تولید توکن برای طبقه‌بندی، از logprob_token_ids برای استخراج مستقیم احتمال گزینه‌ها استفاده کنید.
• برای کاهش هزینه در لیست‌های طولانی (بیش از ۲۱ گزینه)، ساختار پرامپت خود را برای کاهش توکن‌های سربار بهینه‌سازی کنید.
• در وظایفی که دقت حیاتی است اما سرعت اولویت ندارد، زنجیره تفکر را فعال کنید، اما برای عملیات Real-time، حتماً از متد Single-Pass استفاده کنید.

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