مدل Jev هزینه‌های استنتاج مدل‌های زبانی را ۴۴۴ برابر کاهش داد

تصور کنید برای هر ۱ دلار هزینه، بتوانید ۴۵ هزار درخواست طبقه‌بندی تیکت‌های پشتیبانی را پردازش کنید. این عدد خیره‌کننده، خروجی مدل TypeSafe AI Jev است که هوش مصنوعی را از «نویسندگی» به «تصمیم‌گیری» تغییر مسیر می‌دهد.

یک فراخوانی API در این مدل برای طبقه‌بندی یک تیکت استاندارد، تنها ۰.۰۰۰۰۲۲ دلار هزینه دارد. این نقطه قیمتی به توسعه‌دهنده اجازه می‌دهد تا حجم عظیمی از درخواست‌ها با هزینه‌ای ناچیز مدیریت کند. به جای اینکه مدل مانند یک چت‌بات عمل کند یا شبیه به مدل‌های زبانی بزرگ باشد که کلاه کوچکتری بر سر گذاشته‌اند، Jev را باید به عنوان یک تابع تصمیم‌گیری «مبهم» (Fuzzy Decision Function) دید که به جای تولید جملات طولانی، فقط از بین گزینه‌های مشخص انتخاب می‌کند.

همان‌طور که در تحلیل قبلی ما درباره‌ی جداول گمراه‌کننده مقایسه قیمت مدل‌ها اشاره کردیم، Jev رویکردی به سمت هزینه‌های قابل اندازه‌گیری و پیش‌بینی‌پذیر می‌برد. در حالی که مدل‌های مولد برای هر توکن (Token) — مثل برش‌های کوچکی از یک کیک طولانی که مدل تکه‌تکه می‌خورد — هزینه می‌گیرند، Jev بر خروجی‌های محدودی تمرکز دارد که پاسخ‌های معتبر آن‌ها پیش از ارسال درخواست تعریف شده‌اند.

معماری «سیستم یک»

شرکت TypeSafe مدل Jev را یک مدل «سیستم یک» می‌نامد. در روان‌شناسی، سیستم یک سریع، غریزی و احساسی است. در دنیای نرم‌افزار، این یعنی مدلی که برای تصمیمات سریع و ساختاریافته ساخته شده تا کد برنامه بتواند مستقیماً از آن استفاده کند، بدون اینکه نیاز باشد متن‌های غیرقابل‌پیش‌بینی را تجزیه (Parse) کند. این رویکرد در واقع تکامل یافته‌ی متدهای استخراج احتمال است که پیش‌تر در بررسی رویکرد Jevper برای تبدیل متن به عدد و طبقه‌بندی دقیق داده‌ها به آن پرداخته بودیم. این یک رابط چت جدید یا یک دسته‌بندی استاندارد صنعتی از مدل‌ها نیست، بلکه یک دسته‌بندی محصول خاص برای تصمیماتی است که توسط نرم‌افزار قابل مصرف باشند.

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

سه نوع پرسش محدود

برای تضمین امنیت تایپ (Type Safety)، Jev از سه قالب پرسش استفاده می‌کند. هر پرسش فضای پاسخ مخصوص به خود را تعریف می‌کند:

• Choice (انتخاب): می‌پرسد «کدام گزینه پیش‌فرض مناسب‌تر است؟». این مدل از بین لیستی تا سقف ۲۵۵ گزینه، یکی را انتخاب می‌کند. خروجی شامل گزینه انتخاب شده، توزیع احتمالات در میان تمام گزینه‌ها و یک مقدار اطمینان (Confidence) است. این حالت برای مسیریابی قصد کاربر (Intent Routing) و طبقه‌بندی تاکسونومی ایده‌آل است.
• Score (امتیاز): می‌پرسد «این مورد در کجای یک معیار رتبه‌بندی مرتب‌شده قرار می‌گیرد؟». این مدل بین ۲ تا ۱۰ سطح مرتب‌شده را می‌پذیرد. خروجی شامل یک امتیاز وزنی، احتمالات هر سطح، یک راهنما (Legend) و مقدار اطمینان است. این ابزار برای سنجش شدت، کیفیت یا فوریت به کار می‌رود.
• Noul (بله/خیر): می‌پرسد «احتمال درست بودن این گزاره بله/خیر چقدر است؟». این مدل احتمالی بین ۰ تا ۱ برمی‌گرداند و برای تشخیص، تأیید و سیگنال‌های بازبینی دوتایی به کار می‌رود. برخلاف Choice و Score، مدل Noul فیلد جداگانه‌ای برای مقدار اطمینان برنمی‌گرداند.

مشخصات فنی و هزینه‌ها

به نقل از مستندات TypeSafe، نسخه فعلی مدل jev-1.13.0 است (که از طریق نام مستعار jev-latest قابل دسترسی است). قیمت این مدل ۰.۰۴۲ دلار به ازای هر میلیون توکن ورودی است و توکن‌های خروجی رایگان هستند.

این مدل از پنجره متنی (Context Window) — میزان متنی که مدل هم‌زمان در ذهن نگه می‌دارد، شبیه میز کاری که جا برای چند ورق دارد — تا سقف ۶۴ هزار توکن پشتیبانی می‌کند. البته برای مجموع وضعیت (State) و طولانی‌ترین پرسش، محدودیت جداگانه‌ای معادل ۳۲ هزار توکن دارد. ورودی‌ها فقط متنی هستند و هرگونه تصویر، صدا یا ویدیو باید پیش از رسیدن به Jev به متن تبدیل شوند.

توسعه‌دهندگان تشویق می‌شوند هنگام تنظیم آستانه‌ها (Thresholds)، یک نسخه خاص (مانند jev-1.13.0) را تثبیت کنند. استفاده از نام‌های مستعار متغیر راحت است، اما ممکن است یک به‌روزرسانی مدل در ساعت ۲ بامداد، مسیرهای تولیدی (Production Route) را تغییر دهد و شما را مجبور کند پیش از ارتقا، ارزیابی‌ها را دوباره اجرا کنید.

پیاده‌سازی عملی: مسیریابی پشتیبانی

در یک پیاده‌سازی پایتونی، Jev می‌تواند فرآیند تریاژ پیچیده را در یک رفت‌وبرگشت (Round Trip) انجام دهد. SDK پایتون برای اتصال به کلید API در TYPESAFE_API_KEY نیاز دارد. برای تیکتی با موضوع «خطای پرداخت پس از تسویه» و یک طرح تجاری مشخص، Jev می‌تواند هم‌زمان سه کار را در یک فراخوانی انجام دهد:

۱. طبقه‌بندی دپارتمان: با استفاده از پرسش Choice و معیارهایی برای «مالی» (هزینه‌ها/بازگشت وجه)، «فنی» (باگ‌ها/قطعی‌ها)، «حساب کاربری» (هویت/دسترسی‌ها) یا «سایر».
۲. امتیازدهی شدت: با استفاده از پرسش Score و یک معیار سه سطحی که از «ناراحتی جزئی» تا «مسدود شدن جریان کاری یا ضرر مالی مشتری» متغیر است.
۳. تشخیص درخواست بازگشت وجه: با استفاده از پرسش Noul برای اینکه آیا مشتری صراحتاً درخواست بازگشت پول کرده است یا خیر.

سپس کد برنامه منطق قطعی (Deterministic Logic) را اعمال می‌کند؛ مثلاً اگر امتیاز اطمینان دپارتمان زیر ۰.۶۵ یا اطمینان شدت زیر ۰.۵۵ باشد، سیستم تیکت را به «بازبینی انسانی» می‌فرستد. اگر شدت بالای ۱.۵ باشد، به «پاسخ به حادثه» (Incident Response) منتقل می‌شود و در غیر این صورت، طبق دپارتمان انتخاب شده پیش می‌رود.

موارد استفاده با تأثیر بالا

Jev برای نقاطی از معماری طراحی شده که قضاوت معنایی لازم است اما محاسبات ریاضی یا سیاست‌های قطعی پاسخگو نیستند.

بازبینی ریسک عامل‌ها: یک عامل (Agent) می‌تواند فراخوانی ابزاری را پیشنهاد دهد و Jev سیگنال ریسک محدود را صادر کند. برای دستوری مثل rm -rf dist مدل می‌تواند ریسک را «فقط خواندنی»، «نوشتنی بازگشت‌پذیر»، «نوشتنی غیربازگشت‌پذیر» یا «نامشخص» طبقه‌بندی کند. همچنین می‌تواند از پرسش Noul برای تأیید اینکه آیا اقدام با هدف اعلام شده کاربر مطابقت دارد یا خیر استفاده کند. توجه داشته باشید که این یک سیگنال بازبینی است، نه یک مرز امنیتی؛ لیست‌های مجاز (Allowlists) و محیط‌های ایزوله (Sandboxing) همچنان باید در کد مدیریت شوند.

بررسی شواهد در RAG: پیش از آنکه یک مدل مولد پاسخ نهایی را بنویسد، Jev می‌تواند رابطه بین یک ادعا و متن بازیابی‌شده در تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — را بررسی کند و آن را «تأیید شده»، «متناقض» یا «ناکافی» بنامد. همچنین می‌تواند از پرسش Noul برای تشخیص این موضوع استفاده کند که آیا متن حاوی دستوراتی برای تغییر رفتار ارزیاب (تزریق پرامپت یا Prompt Injection) است یا خیر. برنامه همچنان URL منبع و نقل‌قول را حفظ می‌کند، زیرا Jev وب‌گردی نمی‌کند و منشأ داده‌ها را تعیین نمی‌کند.

تریاژ برای نظارت و عملیات: Jev می‌تواند صف‌های عملیاتی را برای هشدارهای مانیتورینگ طبقه‌بندی کند. برای یک جهش تأخیر در checkout-api مدل می‌تواند مالک را شناسایی کند («تیم سرویس»، «پلتفرم»، «پایگاه داده» یا «نامشخص»)، تأثیر بر مشتری را امتیازدهی کند و با یک پرسش Noul مشخص کند که آیا هشدار فاقد زمینه‌ای است که یک پاسخ‌دهنده اولیه به آن نیاز دارد یا خیر.

مسیریابی مدل‌ها: Jev می‌تواند به عنوان مسیریاب ورودی عمل کند تا هزینه‌ها بهینه شوند. یک پرسش Choice تعیین می‌کند که درخواست به یک جست‌وجوی قطعی برود، به یک مدل کوچک برای استخراج سریع، یا به یک مدل استدلالی (Reasoning Model) — مدلی که قبل از جواب درنگ می‌کند، شبیه شطرنج‌بازی که چند حرکت جلوتر را می‌بیند — برای تحلیل اسناد طولانی، یا به یک «انسان» برای مذاکره. این کار تضمین می‌کند که توکن‌های تولیدی فقط زمانی هزینه شوند که وظیفه واقعاً به آن‌ها نیاز داشته باشد.

محدودیت‌های امنیت تایپ

اگرچه TypeSafe ادعا می‌کند Jev نمی‌تواند دچار توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — شود، زیرا نمی‌تواند مقداری خارج از طرحواره (Schema) صادر کند، اما تحلیل‌های مستقل شرکت Arize نکته مهمی را یادآور شده است: Jev نمی‌تواند گزینه‌ای چهارم بسازد وقتی فقط سه گزینه تعریف شده است، اما همچنان می‌تواند با اطمینان کامل، گزینه «اشتباه» را انتخاب کند. امنیت تایپ، شکل پاسخ را محافظت می‌کند، نه درستی قضاوت را.

این مدل صراحتاً در محاسبات ریاضی، شمارش، درونیابی عددی و مقایسه تاریخ‌ها ضعیف است. صفحه محدودیت‌های TypeSafe هشدار می‌دهد که اگرچه Jev می‌تواند تاریخ‌ها را به عنوان متن بخواند، اما آن‌ها را به طور قابل اعتمادی به عنوان مقادیر مرتب‌شده در نظر نمی‌گیرد. بنابراین، هر وظیفه‌ای که نیاز به ریاضیات دقیق، بررسی دسترسی‌ها یا وضعیت پایگاه‌داده دارد باید در کد قطعی باقی بماند.

بنچمارک‌ها و عملکرد

طبق گزارش TypeSafe، تأخیر (Latency) مدل بین ۷۰ تا ۵۰۰ میلی‌ثانیه است. در ارزیابی‌های زمان عرضه، شرکت ادعا کرد Jev در مقایسه با مدل‌های زبانی بزرگ (LLMs) که با آن مقایسه شده بود، ۱۹۳.۶ برابر سریع‌تر و ۴۴۴.۶ برابر ارزان‌تر است. اگرچه TypeSafe اعتراف می‌کند که این ارقام ممکن است در بالاترین حد دستاوردهای دنیای واقعی باشند و احتمال سوگیری در بنچمارک‌ها وجود دارد، اما اختلاف هزینه همچنان چشمگیر است.

در یک آزمایش تشخیص اسپم روی ۵۷۳۳ ایمیل (شامل ایمیل‌های عادی، اسپم و فیشینگ)، Jev بدون نیاز به تنظیمات خاص (Fine-tuning) به صحت ۹۸.۶٪ رسید. این عدد کمی کمتر از مدل‌های سنتی رگرسیون لجستیک TF-IDF (۹۸.۹٪) بود که نشان می‌دهد برای وظایف پایدار با حجم بالای داده‌های برچسب‌دار و دسته‌های پیش‌بینی‌پذیر، طبقه‌بندهای سنتی همچنان برنده هستند.

Jev در مقابل جایگزین‌ها

مدل Jev در جایگاهی خاص بین قوانین، طبقه‌بندها و LLMها قرار می‌گیرد:

• قوانین/کد: بهترین برای بررسی‌های قطعی و دقیق. هرگاه پاسخ را بتوان دقیقاً محاسبه کرد (مثلاً بررسی سررسید فاکتور از طریق مقایسه تاریخ)، قوانین برنده هستند.
• طبقه‌بندهای سنتی: بهتر برای وظایف پایدار با داده‌های برچسب‌دار زیاد و دسته‌های مشخص.
• مدل‌های زبانی بزرگ (خروجی ساختاریافته): بهترین برای تولید متن، استخراج داده و استدلال‌های چندمرحله‌ای. اگرچه APIهای سخت‌گیرانه می‌توانند طرحواره‌های JSON را تحمیل کنند، اما تمایز Jev در رابط مخصوص تصمیم‌گیری و توزیع احتمالات درجه اول آن است.
• TypeSafe Jev: بهترین برای تصمیمات معنایی محدود که در آن یک سیگنال احتمالی لازم است تا برنامه تصمیم بگیرد که اقدام کند، تلاش مجدد نماید یا مورد را ارجاع دهد.

استراتژی ارزیابی

برای استقرار ایمن، توسعه‌دهندگان باید از «حالت سایه» (Shadow Mode) شروع کنند. این کار شامل انتخاب یک تصمیم بازگشت‌پذیر با مجموعه پاسخ بسته، تثبیت یک مجموعه داده برچسب‌دار نماینده و متن معیارهای دقیق، و اجرای Jev در کنار یک مدل پایه است.

متریک‌های کلیدی برای ردیابی عبارتند از:

• خطاهای هر کلاس و ماتریس‌های اغتشاش (Confusion Matrices).
• تعداد اقدامات خودکار اشتباه و نرخ بازبینی انسانی.
• کالیبراسیون (مثلاً مواردی که امتیاز نزدیک به ۰.۹ دارند باید بیشتر از موارد نزدیک به ۰.۶ درست باشند).
• تأخیر سرتاسری و هزینه به ازای هر تصمیم تکمیل شده.

آستانه اطمینان باید بر اساس پیامد خطا تنظیم شود. ارسال تیکت به صف اشتباه خطایی جزئی است، اما تأیید یک اقدام تخریبی یک فاجعه است و نیاز به کف اطمینان بسیار بالاتری دارد. توسعه‌دهندگان باید هزینه اقدامات خودکار اشتباه را در مقابل هزینه بازبینی انسانی متوازن کنند.

چرخش در معماری هوش مصنوعی

ارزش اصلی Jev در جداسازی «تولید» از «قضاوت» است. برای مدت‌ها توسعه‌دهندگان از مدل‌های «رمان‌نویس» برای مرتب کردن پاکت‌های نامه استفاده می‌کردند. با تفکیک این وظایف، نرم‌افزار می‌تواند از Jev برای قضاوت و از مدل‌های مولد برای نوشتن استفاده کند.

این معماری «شعاع تخریب» خطاهای هوش مصنوعی را کاهش می‌دهد. وقتی مدل احتمالی ۰.۶ برمی‌گرداند، نرم‌افزار می‌داند که مدل نامطمئن است. برخلاف مدل‌های مولد که با اطمینان کامل پاراگرافی غلط می‌نویسند و راهی برای تشخیص خطا تا زمان رسیدن به انسان وجود ندارد. با سپردن مسئولیت اقدام نهایی به کد بر اساس احتمالات تایپ‌شده، توسعه‌دهندگان می‌توانند سیستم‌های هوش مصنوعی تاب‌آورتری بسازند.

گام بعدی شما

• اگر از LLMهای گران‌قیمت برای طبقه‌بندی (Classification) استفاده می‌کنید، یک نمونه کوچک از داده‌های خود را با مدل Jev تست کنید تا کاهش هزینه را بسنجید.
• برای وظایفی که ریسک بالایی دارند، آستانه اطمینان (Confidence Threshold) را روی ۰.۹ تنظیم کرده و موارد پایین‌تر را به بازبینی انسانی ارجاع دهید.
• در معماری RAG خود، از Jev به عنوان لایه تأیید شواهد (Evidence Checking) پیش از مرحله تولید متن استفاده کنید.

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