‏کالبدشکافی Jev، مدلی که به‌جای متن احتمال می‌ده

نویسنده می‌گه بیشتر واکنش‌ها به معرفی Jev نکتهٔ اصلی رو ندیدن. مشکل اینه که وقتی یه LLM معمولی می‌نویسه «۹۰٪ مطمئنم»، این فقط یه رشته توکنه؛ احتمال اینکه مدل این کلمه‌ها رو بنویسه ربطی به احتمال درست بودن تصمیم نداره. با این حال تشخیص تقلب، مودریشن، روتینگ و ارزیابی ریسک روی همین الگو ساخته می‌شن. ادعای TypeSafe اینه که Jev دانش یه مدل زبانی از پیش آموزش‌دیده رو نگه می‌داره ولی به‌جای ادعای متنی، احتمال‌ها رو مستقیم از نمایش داخلی خودش می‌خونه.

استفاده‌ش این شکلیه: شما یه state مشترک (مثلاً متن تیکت پشتیبانی) می‌دی، به‌علاوهٔ چند سؤال و جواب‌های مجاز هرکدوم، و مدل توزیع احتمال همه رو موازی برمی‌گردونه. مثلاً صف payments احتمال ۰.۹۱ می‌گیره و «نیاز به رسیدگی فوری» فقط ۰.۴۲؛ اینا دو تا عدم‌قطعیت جداگونه‌ن و کد برنامه می‌تونه تیکت رو خودکار روت کنه ولی تصمیم escalation رو به یه سیاست دیگه بسپاره.

حدس نویسنده اینه که به‌جای decode loop، اینفرنس با یه readout تموم می‌شه: بردار مخفی نهایی از یه ماتریس و softmax رد می‌شه و به‌اندازهٔ تعداد گزینه‌ها عدد می‌ده. شاهدش اینه که فیلد output_tokens تو API یه رقم صورت‌حسابه نه نشونهٔ تولید متن؛ سؤالی با ۲۰۰ گزینه که ۱٬۹۱۱ توکن خروجی ثبت کرده به همون سرعت سؤال دوگزینه‌ای جواب داده و زمان سرور فقط با طول ورودی بالا رفته.

بخش دوم، اشتراک state و جداسازی سؤال‌هاست. KV cache (یعنی همون چیزی که ترنسفورمر از توکن‌های پردازش‌شده نگه می‌داره) یه بار برای state ساخته می‌شه و هر سؤال فقط دستور و گزینه‌های خودش رو بهش اضافه می‌کنه. آزمایش نویسنده اینو نشون می‌ده: یه کد مخفی که داخل یه سؤال دیگه گذاشته شده بود احتمال ۰.۰۰ گرفت، ولی همون کد وقتی رفت تو state، احتمالش شد ۰.۹۰ تا ۰.۹۲. سقف‌ها هم با همین جور درمیان: هر شاخه حدود ۳۲٬۷۶۸ توکن و کل درخواست حدود ۶۵٬۵۳۶ توکن.

داخل هر سؤال اما گزینه‌ها با هم دیده می‌شن. نویسنده یه گزینهٔ کاملاً بی‌ربط به لیست اضافه کرد و نسبت شانس دو گزینهٔ قبلی عوض شد: میانگین لگ‌اودز از حدود ۰.۳۸ افتاد به ۰.۱۱. اگه هر گزینه لاجیت مستقل خودش رو داشت و فقط softmax نرمالش می‌کرد، این نسبت نباید تکون می‌خورد. نکتهٔ عملی‌ش هم اینه که همین که ترتیب گزینه‌ها رو برعکس کنی، احتمال یه دسته‌بندی از ۰.۸۴-۰.۸۹ می‌ره به ۰.۹۳-۰.۹۶؛ پس اگه آستانهٔ تصمیمت نزدیک ۰.۹ باشه، حتماً باید تست جایگشت بذاری.

آخرین تکه آموزشه. TypeSafe روشش رو RLCD یا «یادگیری تقویتی برای تصمیم‌های کالیبره» می‌خونه ولی دستورش رو منتشر نکرده. کالیبره بودن یعنی از بین جواب‌هایی که مدل بهشون ۸۰٪ داده، واقعاً حدود ۸۰٪ درست باشن. روی نمونهٔ ۱۲۰۰تایی MMLU این خطا ۰.۰۳۱۳ درمیاد، هرچند ۹۹۰ تا از پیش‌بینی‌ها تو بازهٔ ۰.۹ تا ۱.۰ جمع شدن. تو یه آزمون ریاضی تازه، ضرب سه‌رقمی دقت ۸۶.۷٪ با میانگین احتمال ۰.۸۳ داشت و مسائل کلامی دو مرحله‌ای دقت ۳۲٪ با احتمال ۰.۳۰، یعنی مدل روی کار سخت‌تر کم‌اعتمادتر هم بوده.

نکات کلیدی:

• Jev بسته‌ست و TypeSafe تحقیقاتش رو منتشر نکرده؛ کل این معماری حدس نویسنده از رفتار API ـه
• هر شاخه (state به‌علاوهٔ یک سؤال) حدود ۳۲٬۷۶۸ توکن و کل درخواست حدود ۶۵٬۵۳۶ توکن سقف داره
• API هر سؤال رو حداکثر با ۲۵۵ گزینه قبول می‌کنه
• دقت Jev روی MMLU-Pro ۸۴.۶٪ گزارش شده و خطای کالیبراسیونش روی نمونهٔ MMLU برابر ۰.۰۳۱۳
• فیلد confidence فقط فاصلهٔ جواب برتر از توزیع یکنواخت رو حساب می‌کنه، نه یه تخمین یادگرفته‌شدهٔ جدا
• توکنایزر Jev با هیچ‌کدوم از ۱۹۲ توکنایزر عمومی تست‌شده جور درنیومد