مدل هوش مصنوعی Jev برای تصمیم ساخته شده، نه نثر

TypeSafe AI، Jev را به‌عنوان یک مدل جدید مبتنی بر transformer توصیف می‌کند، اما نه یک مدل زبانی بزرگ. به‌جای تولید tokenهای متنی، Jev روی خروجی‌هایی که توسعه‌دهندگان از قبل تعریف می‌کنند احتمال برمی‌گرداند. TechCrunch می‌گوید TypeSafe این خروجی‌ها را «تصمیم‌های کالیبره‌شده» می‌نامد.

طبق گزارش، این طراحی سه پیامد فوری دارد.

اول، این مدل برای کارهای سبک classification ارزان‌تر و سریع‌تر از استفاده از یک LLM عمومی جای‌گذاری شده است. TechCrunch گزارش می‌دهد که tokenهای خروجی Jev رایگان‌اند و tokenهای ورودی آن بر اساس میلیارد سنجیده می‌شوند، نه میلیون.

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

سوم، آن احتمال بخشی از محصول است، نه چیزی اضافه‌شده در پایان. Armin Ronacher، CTO شرکت Earendil، به TechCrunch گفت Jev «مسئله hallucination را تا حدی به کاربر واگذار می‌کند». اگر نتیجه با 50٪ برگردد، اپلیکیشن ممکن است آن را نادیده بگیرد. اگر با 95٪ برگردد، اپلیکیشن ممکن است اقدام کند.

این تمایز مهم است. بخش زیادی از automation مبتنی بر AI نه به این دلیل می‌شکند که مدل هیچ‌وقت مفید نیست، بلکه چون نرم‌افزار نمی‌تواند بفهمد مدل صرفاً حدس می‌زند یا نه. توسعه‌دهندگان اغلب تلاش می‌کنند با درخواست از یک LLM برای توضیح دادن خودش، رأی‌گیری با خودش، یا خروجی دادن JSON ساختاریافته، اعتماد را بازیابی کنند. Jev به‌عنوان مدلی معرفی می‌شود که امتیاز اطمینان در آن اصل ماجراست.

TechCrunch گزارش می‌دهد علاقه توسعه‌دهندگان آن‌قدر زیاد بود که TypeSafe AI برای مدتی کوتاه توانایی سرویس‌دهی به کاربران از API خود را از دست داد. مقاله جذابیت اولیه Jev را حول automation نرم‌افزاری تصویر می‌کند: توسعه‌دهندگانی که از هوشمندی درون کد استفاده می‌کنند، نه به‌عنوان یک رابط chat.

دو نمونه در گزارش شکل این تقاضا را نشان می‌دهند.

Pranit Sharma، مهندس نرم‌افزار در Vercel، به TechCrunch گفت Vercel از یک مدل OpenAI برای اجرای classifier استفاده کرده بود که فرمان‌ها را از نظر ایمنی بررسی می‌کرد. وقتی Vercel مدل Luna از OpenAI را با Jev جایگزین کرد، Sharma گفت نتایج را 5 تا 18 برابر سریع‌تر و با دقت بیشتر گرفت.

Nikhil Mudholkar، CTO شرکت Bryo AI، طبق گزارش TechCrunch، Jev را در برابر Gemini برای classification ایمیل‌های کاری آزمایش کرد. در آزمون او، Gemini کمی دقیق‌تر بود، اما 10 تا 20 برابر گران‌تر. Mudholkar روی امتیازهای اطمینان Jev تأکید کرد و گفت Jev «تنها مدلی بود که یک احتمال واقعی برمی‌گرداند»؛ چیزی که آن را برای خودکارسازی workflowها مفید می‌کرد.

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

نمونه‌ها شامل این‌هاست:

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

اگر ادعاهای اولیه Jev بیرون از نمونه‌هایی که TechCrunch گزارش کرده هم برقرار بماند، در همان فضای طراحی عملی tool calling و خروجی‌های ساختاریافته قرار می‌گیرد: تبدیل رفتار مدل به قراردادهایی که نرم‌افزار می‌تواند مصرف کند.

یکی از جالب‌ترین کاربردها در گزارش TechCrunch جایگزین کردن LLMها نیست، بلکه تصمیم گرفتن درباره زمان استفاده از آن‌هاست.

Ronacher به TechCrunch گفت Jev می‌تواند برای model routing مفید باشد: پیش‌بینی اینکه آیا یک workload مشخص به مدلی خاص نیاز دارد یا نه. استفاده از یک LLM برای گرفتن این تصمیم می‌تواند گران باشد. یک مدل ارزان‌تر و سریع‌تر که امتیازی کالیبره‌شده برمی‌گرداند می‌تواند جلوی یک stack مدل قرار بگیرد و تصمیم بگیرد هر درخواست باید به کجا برود.

این مسئله برای هر کسی که با چند مدل می‌سازد آشناست. قوی‌ترین مدل همیشه لازم نیست. ارزان‌ترین مدل همیشه امن نیست. بعضی promptها به استدلال با context طولانی نیاز دارند؛ بعضی دیگر به یک classifier سریع؛ بعضی دیگر به تصویر، صدا، یا ابزار retrieval. یک router باید قبل از خرج کردن بودجه، کار را تخمین بزند.

اینجاست که فرم Jev هم مهم می‌شود. یک router به مقاله‌ای درباره اینکه چرا یک prompt سخت است نیاز ندارد. به تصمیمی شبیه این نیاز دارد:

• ارسال به یک مدل کوچک؛
• ارسال به یک مدل frontier؛
• ابتدا بازیابی اسناد؛
• درخواست تأیید انسانی؛
• رد کردن به‌عنوان ناامن.

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

Jev نشان می‌دهد که خود routing شاید به یک workload هوش مصنوعی با مدل‌های تخصصی پشت آن تبدیل شود.

TechCrunch همچنین گزارش می‌دهد که Almeida کاربرد Jev را در پایش traceهای agentهای LLM و جلوگیری از jailbreak می‌بیند. استدلال هزینه روشن است. اگر هر اقدام agent باید با یک LLM کامل دیگر بررسی شود، لایه ایمنی می‌تواند گران شود. اگر یک مدل تصمیم‌گیری کوچک‌تر بتواند رفتار مشکوک را ارزان علامت‌گذاری کند، اپلیکیشن‌های بیشتری می‌توانند پایش پیوسته را تحمل کنند.

این بخش‌های سخت ایمنی agent را حذف نمی‌کند. یک classifier به برچسب‌های خوب تعریف‌شده نیاز دارد. به مثال نیاز دارد. به آستانه نیاز دارد. به سیاستی برای وقتی که اطمینان پایین است نیاز دارد. و اگر اقدام به‌اندازه کافی حساس باشد، امتیاز احتمال نباید جایگزین قضاوت انسانی شود.

اما معماری تمیز است:

1. یک agent مرحله‌ای را پیشنهاد می‌کند یا انجام می‌دهد؛
2. یک مدل تصمیم‌گیری به آن مرحله امتیاز می‌دهد؛
3. سیستم مسدود می‌کند، اجازه می‌دهد، ثبت می‌کند یا escalation انجام می‌دهد؛
4. انسان فقط مواردی را بازبینی می‌کند که به بازبینی انسانی نیاز دارند.

این به شیوه‌ای نزدیک است که سیستم‌های production همین حالا درباره ریسک فکر می‌کنند. سیستم‌های پرداخت، fraud، spam و abuse اغلب از طریق آستانه‌ها و مسیرهای escalation عمل می‌کنند. agentهای هوش مصنوعی هم کم‌کم به همین الگو نیاز پیدا می‌کنند.

برای تیم‌هایی که workflowهای خودمختار می‌سازند، درس این نیست که «کار ایمنی خود را با Jev جایگزین کنید». درس این است که ایمنی می‌تواند از تولید جدا شود. می‌توانید agentهایی طراحی کنید که از یک مدل برای عمل کردن، از مدل یا classifier دیگری برای پایش، و از یک لایه تأیید انسانی برای اقدامات برگشت‌ناپذیر استفاده کنند. همین اصل در تأییدهای human-in-the-loop و در سیستم‌های multi-agent که یک جزء پیش از ادامه کار جزء دیگر را بررسی می‌کند هم دیده می‌شود.

معماری تا حدی مبهم باقی مانده است. TechCrunch می‌گوید Almeida درباره جزئیات داخلی Jev «کم‌حرف» است، در حالی که ناظران بیرونی حدس می‌زنند این مدل روی یک LLM با open weights ساخته شده باشد. TypeSafe AI، Jev را یک «مدل System One» می‌نامد: مدلی بهینه‌شده برای تصمیم‌های سریع و شبیه شهود، نه استدلال صریح، با طراحی محدودتری که با وظیفه هم‌خوان است.

Almeida به TechCrunch گفت Jev صرفاً روی داده synthetic و با استفاده از تکنیکی آموزش دیده که او آن را «reinforcement learning from calibrated decisions» می‌نامد. او همچنین گفت TypeSafe AI از ابتدا روی ساخت همه داده‌های خودش شرط‌بندی کرده بود. او بخشی از شرکت را آزمایشگاهی توصیف کرد که روی «داده synthetic با درک آماری خوب» متمرکز است.

این مقدار برای فهم thesis محصول کافی است، اما برای ارزیابی مستقل روش آموزش کافی نیست. از گزارش TechCrunch نمی‌دانیم calibration چگونه اندازه‌گیری می‌شود، بیرون از توزیع چقدر robust است، مدل با ورودی‌های adversarial چگونه برخورد می‌کند، یا عملکرد آن در domainهای مختلف چگونه تغییر می‌کند.

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

یک ارزیابی معقول فقط accuracy را نمی‌سنجد، بلکه منحنی‌های calibration، رفتار abstention، عملکرد آستانه‌ها و هزینه زیر ترافیک واقعی را هم آزمایش می‌کند. برای تیم‌هایی که همین حالا ارزیابی مدل اجرا می‌کنند، Jev باید در همان test harness قرار بگیرد که LLM احتمالیِ قابل جایگزینی یا قابل پایش با آن قرار دارد.

نام Jev از William Stanley Jevons گرفته شده؛ اقتصاددان قرن نوزدهمی که با پارادوکس Jevons شناخته می‌شود: وقتی استفاده از یک منبع کارآمدتر می‌شود، مصرف کل می‌تواند به‌جای کاهش، افزایش یابد. Almeida به TechCrunch گفت TypeSafe AI انتظار دارد هوشمندی ارزان‌تر به «نرم‌افزار هوشمند در همه‌جا» منجر شود؛ بیشتر شبیه اینترنت اولیه تا جهانی که فقط تحت سلطه «mega app»ها باشد.

این ادعای راهبردی است. اگر هوشمندی آن‌قدر ارزان شود که بتوان آن را در control flow معمولی قرار داد، توسعه‌دهندگان شاید دیگر AI را فقط برای chatbotها و تجربه‌های agentic بزرگ نگه ندارند. در عوض، تصمیم‌های کوچک همه‌جا ظاهر می‌شوند: در صف‌ها، پنل‌های admin، workflowهای پشتیبانی مشتری، بررسی‌های deployment، سیستم‌های پیام‌رسانی و pipelineهای داده.

این می‌تواند یک تغییر معنادار باشد. رابط دوران ChatGPT، chat بوده است. Jev به سمت inference تعبیه‌شده اشاره می‌کند: تصمیم‌های نامرئی، محدود و پرتکرار که باعث می‌شوند نرم‌افزار در لحظه تطبیق پیدا کند.

برای سازندگان، حرکت عملی این است که جاهایی را فهرست کنند که امروز از یک LLM عمومی می‌خواهید کاری محدود انجام دهد. classification، routing، extraction، ranking، moderation و escalation نامزدهای واضح‌اند. بعضی‌ها همچنان ممکن است به LLM نیاز داشته باشند. بعضی‌ها شاید با ruleها بهتر مدیریت شوند. بعضی‌ها اگر اقتصادشان جور دربیاید، ممکن است یک مدل تصمیم‌گیری تخصصی را توجیه کنند.

اگر workflow شما شامل پردازش تعداد زیادی ردیف، پیام، ticket یا event است، سؤال تیزتر می‌شود: آیا به متن تولیدشده نیاز دارید، یا به یک تصمیم قابل اعتماد در مقیاس؟ این همان خط اقتصادی پشت AI batch processing و بسیاری از سیستم‌های automation در production است.

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

این باید شیوه چارچوب‌بندی معماری AI در تیم‌ها را تغییر دهد.

از LLMها جایی استفاده کنید که زبان، استدلال، synthesis و استفاده از ابزار مهم است. وقتی به قرارداد نیاز دارید از خروجی‌های ساختاریافته استفاده کنید. وقتی پاسخ به دانش خصوصی یا در حال تغییر وابسته است از retrieval استفاده کنید. وقتی اقدامات حساس‌اند از تأیید انسانی استفاده کنید. و این کلاس نوظهور از مدل‌های تصمیم‌گیری را برای جاهایی زیر نظر بگیرید که احتمال‌ها از نثر مفیدترند.

Jev ممکن است یک محصول تخصصی باقی بماند، یا رقبا ممکن است در همان جهت کلی حرکت کنند. Ronacher به TechCrunch گفت انتظار دارد دیگران دنبال کنند، اما این الزاماً به معنای cloneهای مستقیم Jev نیست؛ می‌تواند به معنای سیستم‌های بیشتری باشد که به‌جای تولید متن باز، حول تصمیم‌های محدود و مبتنی بر احتمال ساخته می‌شوند. در هر صورت، این یک سیگنال مفید است: موج بعدی زیرساخت AI شاید کمتر درباره بهتر حرف زدن یک مدل باشد و بیشتر درباره دادن قطعات ارزان‌تر، کوچک‌تر و قابل‌اندازه‌گیری‌تر هوشمندی به نرم‌افزار.

نتیجه عملی کمتر درباره جایگزین کردن LLMهاست و بیشتر درباره انتخاب شکل درست مدل برای هر تصمیم.

• Jev به‌عنوان مدلی مبتنی بر transformer توصیف می‌شود که به‌جای تولید نثر، روی خروجی‌های ازپیش‌تعریف‌شده احتمال برمی‌گرداند.
• این مدل برای تصمیم‌های محدود نرم‌افزاری مثل classification، routing، moderation، escalation و بررسی‌های ایمنی معرفی می‌شود.
• آزمون‌های گزارش‌شده توسعه‌دهندگان نشان می‌دهد Jev ممکن است در بعضی workflowهای محدود classification سریع‌تر یا ارزان‌تر از LLMهای عمومی باشد، اما این‌ها benchmarkهای گسترده نیستند.
• احتمال‌های کالیبره‌شده می‌توانند به اپلیکیشن‌ها کمک کنند تصمیم بگیرند چه زمانی اقدام کنند، abstain کنند، escalation انجام دهند، یا یک مدل قوی‌تر را فراخوانی کنند.
• سازندگان باید سیستم‌های شبیه Jev را از نظر accuracy، calibration، رفتار آستانه، abstention، robustness و هزینه زیر ترافیک واقعی ارزیابی کنند.

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

Jev مدلی از TypeSafe AI است که مبتنی بر transformer توصیف می‌شود، اما یک مدل زبانی بزرگ نیست. به‌جای نوشتن متن، روی خروجی‌هایی که توسعه‌دهندگان از قبل تعریف می‌کنند احتمال برمی‌گرداند.

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

توسعه‌دهندگان علاقه‌مندند چون بسیاری از workloadهای AI به‌جای یک پاراگراف، به یک شاخه، برچسب یا تصمیم ایمنی قابل اعتماد نیاز دارند. TechCrunch آزمون‌های اولیه‌ای را گزارش کرد که در آن‌ها Jev در use caseهای مشخص classification ارزان‌تر یا سریع‌تر بود.

این مقاله use caseهایی مثل بررسی ایمنی فرمان، classification ایمیل کاری، پایش agent، model routing، triage در workflow و guardrail برای agentهای LLM را بررسی می‌کند.

تیم‌ها باید چیزی فراتر از accuracy را آزمایش کنند. آن‌ها باید calibration، عملکرد آستانه، رفتار abstention، robustness بیرون از domain آموزش، ورودی‌های adversarial و هزینه زیر ترافیک واقعی را اندازه‌گیری کنند.