یک تیکت کوتاه را تصور کنید: «پول از حسابم کم شده، ولی سفارشم ثبت نشده.» برای پاسخ به آن، ChatGPT میتواند متن مودبانهای بنویسد. اما نرمافزار پشتیبانی قبل از نوشتن متن، سه تصمیم ساده میخواهد: این پیام برای تیم مالی است یا فنی؟ چقدر فوری است؟ آیا باید پیش از پاسخ، انسان آن را ببیند؟ Jev برای همین چند تصمیم کوچک ساخته شده است.
۱. Jev دقیقاً چیست؟
Jev (بخوانید «جِو») نخستین مدل عمومی شرکت TypeSafe AI است که در ۱۴ سپتامبر ۲۰۲۶ معرفی شد. این شرکت نام خانوادهٔ این مدلها را System One گذاشته: اشارهای به قضاوتهای سریع و شهودی انسان، نه فکرکردن طولانی و مرحلهبهمرحله.
اما Jev قرار نیست شبیه یک انسان حرف بزند. شما به آن «وضعیت» میدهید؛ مثلاً متن یک تیکت، گزارش رخداد یا دادهٔ یک فرم. بعد چند پرسش با پاسخهای مجاز تعریف میکنید. خروجی نیز دقیقاً در همان قالب برمیگردد: Choice برای انتخاب از فهرست، Score برای امتیاز روی یک مقیاس، و Noul برای احتمال بله/خیر. هر پرسش روی همان وضعیت مشترک و در یک درخواست، مستقل و موازی بررسی میشود.
پشت نامها چه داستانی است؟
TypeSafe در ۱۵ سپتامبر ۲۰۲۶ از حالت مخفی خارج شد. دیوگو آلمیدا (Diogo Almeida)، همبنیانگذار و مدیرعامل شرکت، پیشتر در OpenAI روی پژوهشهای مرتبط با RLHF، InstructGPT، ChatGPT و GPT‑4 کار کرده بود. او TypeSafe را همراه اریک گافنی و ساشا شنگ بنیان گذاشت؛ DCVC نیز راند Seed چهلمیلیوندلاری شرکت را رهبری کرده است. این پیشزمینه بهخودیخود تضمین کیفیت محصول نیست، اما توضیح میدهد چرا مسئلهٔ «قابلاتکا کردن AI برای نرمافزار» محور اصلی این تیم شده است.
نام System One از تمایز مشهور دنیل کانمن میان تفکر سریع و شهودیِ «سیستم ۱» و تفکر کند و سنجیدهٔ «سیستم ۲» گرفته شده است. «Jev» نیز به ویلیام استنلی جونز و پارادوکس Jevons اشاره دارد: کارآمدترشدن یک منبع، گاهی بهجای کاهش مصرف، استفاده از آن را بیشتر میکند. شرط TypeSafe این است که هر مرتبه ارزانتر و سریعترشدن تصمیمهای ماشینی، کاربردهای بیشتری در نرمافزار باز میکند.
اطلاعاتی که برنامه دارد: متن، JSON یا آرایه.
پرسشهای بسته: «کدام تیم؟»، «چقدر فوری؟»
پاسخ ساختیافته همراه احتمال یا اطمینان.
۲. فرق Jev با LLM چیست؟ یک نویسنده در برابر یک داور
مدلهای زبانی بزرگ یا LLM—مانند ChatGPT، Claude و Gemini—برای تولید زبان ساخته شدهاند: واژه را پس از واژه انتخاب میکنند تا جواب، ایمیل، کد یا خلاصه بسازند. این انعطاف فوقالعاده است؛ ولی وقتی برنامه فقط میخواهد یکی از سه مسیر را انتخاب کند، تولید یک پاسخ متنی و سپس فهمیدنِ آن پاسخ، یک دور اضافه است.
| پرسش | LLM | Jev |
|---|---|---|
| خروجی اصلی چیست؟ | متن آزاد؛ برای انسان خوانا | تصمیم محدود؛ برای کد قابلاستفاده |
| نمونه خروجی | «این مورد احتمالاً مربوط به پرداخت است و بهتر است…» | queue: billing, p: 0.96 |
| آیا میتواند مقاله، ایمیل یا کد بنویسد؟ | بله؛ این کارِ اصلی اوست. | خیر؛ این اصلاً وظیفهاش نیست. |
| چطور با ابهام روبهرو میشود؟ | میتواند توضیح بدهد یا سؤال بپرسد. | احتمال/اطمینان میدهد؛ برنامه آستانهٔ اقدام را تعیین میکند. |
| بهترین استفاده | گفتوگو، خلق محتوا، تحلیل باز و استدلال پیچیده | مسیردهی، دستهبندی، امتیازدهی و گیت ایمنیِ پرتکرار |
۳. یک مثال واقعی: تیکت پشتیبانی در کمتر از یک چشمبرهمزدن
فرض کنید مشتری نوشته: «برای تمدید اشتراک دو بار از من پول کم شده؛ لطفاً بررسی کنید.» برنامه میتواند سه پرسش را همزمان به Jev بدهد:
state: "برای تمدید اشتراک دو بار از من پول کم شده..." questions: team: Choice [billing, technical, sales] urgency: Score [1..5] review: Boolean [needs human review?] answer: team = billing (0.98) | urgency = 4 | review = true (0.93)
حالا خودِ نرمافزار قانون شفاف دارد: اگر احتمال انتخاب کمتر از ۰٫۸۰ بود، درخواست به بازبینی انسان برود؛ اگر بالاتر بود، مستقیماً در صف مناسب قرار بگیرد. این همان فرق «یک پاسخ قشنگ» با «یک خروجی عملیاتی» است.
۴. چرا این چند روز خبرساز شده است؟
چون ادعای TypeSafe ساده و بزرگ است: بخش زیادی از تماسهای هوش مصنوعی در نرمافزارها، واقعاً نوشتن نمیخواهند؛ فقط به تصمیمهای کوچک، زیاد و سریع نیاز دارند. Jev این پرسشها را در یک درخواست بهصورت موازی بررسی میکند. Vercel از ۱۶ سپتامبر آن را در AI Gateway عرضه کرده و آن را برای انتخاب ابزار یا زیرعامل، امتیازدهی ریسک، اعتبارسنجی خروجی مدل و گاردریلها مناسب دانسته است.
سرعت واکنش جامعهٔ توسعهدهندگان نیز غیرعادی بود: طبق گزارش خود Vercel، Jev در ۲۴ ساعت اول به نزدیک ۱۳٪ از تیمهای پولی AI Gateway رسید؛ بیش از دو برابر هر عرضهٔ مدل قبلی در این سرویس. این آمار، میزان کنجکاوی اولیه را نشان میدهد، نه موفقیت قطعی یا ماندگار محصول.
- پشتیبانی: تشخیص نوع درخواست و اولویتدادن به تیکتها.
- فروش: امتیازدهی سرنخها پیش از واگذاری به تیم فروش.
- عاملهای هوش مصنوعی: تصمیم برای ادامهدادن، تلاش دوباره، پرسیدن از کاربر یا توقف.
- امنیت و نظارت: نشانهگذاری اقدامهای پرریسک برای تأیید انسانی.
- محتوا: دستهبندی یا بررسی اولیهٔ پیامها بر اساس یک سیاست مشخص.
۵. مردم چه چیزهایی با Jev ساختهاند؟ (نمونههای واقعی با ورودی و خروجی)
تنها ظرف چند روز پس از معرفی مدل، توسعهدهندگان پروژههای کاربردی متعددی بر پایهٔ Jev توسعه دادند که در مخزن متنباز awesome-jev-usecases گردآوری شدهاند. بررسی دقیق ساختار وضعیت ورودی (State)، پرسشها (Questions) و تصمیم نهایی (Answer) در این پروژهها به درک عینی این شیوه از طراحی معماری کمک میکند.
صورت مسئله: هدایت خودکار مرورگر و کلیک روی عناصر صفحه توسط مدلهای زبانی مانند GPT-4 بسیار کند و پرهزینه است. در این پروژه، Jev اکشن بعدی و عنصر هدف را انتخاب میکند و تنها زمانی که تایپ یک متن آزاد ضروری باشد، کار به LLM سپرده میشود.
state: dom_elements: ["#origin_input", "#dest_input", "#date_picker", "#submit_search"] last_action: "filled_destination_london" questions: next_action: Choice [click, type_text, scroll, wait, finish] target_node: Choice ["#origin_input", "#dest_input", "#date_picker", "#submit_search"] needs_llm: Noul [آیا برای این گام نیاز به نگارش جمله توسط LLM است؟] answer: next_action = click (0.97) | target_node = "#submit_search" (0.94) | needs_llm = false (0.01)
صورت مسئله: عاملهای خودکار اقداماتی نظیر اجرای دستورات شل یا اصلاح پایگاهداده را پیشنهاد میدهند. این پروژه پیش از اجرای هر Tool Call، سطح ریسک را بدون معطلی و ایجاد تاخیر برای سیستم اعتبارسنجی میکند.
state: user_intent: "پاکسازی لاگهای قدیمی سیستم" tool_call: "rm -rf /var/log/app/cache/* && DROP TABLE temp_audit;" questions: data_loss_hazard: Noul [آیا خطر حذف غیرقابل بازگشت دادههای حیاتی وجود دارد؟] severity: Score [سطح خطر عملیات از ۱ تا ۵] verdict: Choice [ALLOW_AUTOMATIC, REQUIRE_HUMAN_APPROVAL, HARD_BLOCK] answer: data_loss_hazard = true (0.98) | severity = 4.8 | verdict = REQUIRE_HUMAN_APPROVAL (0.93)
صورت مسئله: جستجو و فیلتر کردن مفهومی رکوردهای دیتابیس معمولاً نیازمند ایجاد پایگاهداده برداری و محاسبات پرهزینه Embedding است. این راهکار تصمیمهای معنایی را مستقیماً روی دادههای JSON ردیفها اجرا میکند.
state: customer_record: { "id": 1042, "overdue_days": 45, "debt": 85000000, "note": "قول تسویه بعد از وصول مطالبات" } questions: high_credit_risk: Noul [آیا این مشتری در آستانه ریسک اعتباری بحرانی است؟] collection_queue: Choice [normal_reminder, legal_escalation, credit_freeze] answer: high_credit_risk = true (0.92) | collection_queue = legal_escalation (0.89)
صورت مسئله: در ابزارهای برنامهنویسی مانند Claude Code، پر شدن پنجره کانتکست باعث خلاصه کردن تاریخچه توسط LLM میشود که ممکن است متغیرها و امضای توابع را مخدوش کند. با Jev، مدل فقط تصمیم به ماندن یا رفتن میگیرد.
state: chat_block: "export function calculateTax(amount: number) { return amount * 0.09; }" active_file: "src/tax_engine.ts" questions: keep_decision: Choice [keep_verbatim, discard_safely] is_active_code: Noul [آیا این بخش متعلق به منطق اجرایی فایل فعال است؟] answer: keep_decision = keep_verbatim (0.99) | is_active_code = true (0.96)
۶. واقعیت پشت اعداد پرسروصدا: سریعتر؟ ارزانتر؟ بیخطا؟
شرکت سازنده میگوید Jev در ارزیابیهای workflow خود تا ۱۹۳٫۶ برابر سریعتر و ۴۴۴٫۶ برابر ارزانتر از LLMها بوده؛ Vercel نیز همین ارقام را با انتساب روشن به TypeSafe نقل کرده است. TypeSafe زمان پاسخ سرتاسری ۷۰ تا ۵۰۰ میلیثانیه را اعلام میکند و صفحهٔ مدل در Vercel قیمت ورودی را ۰٫۰۴ دلار برای هر یک میلیون توکن نمایش میدهد. اینها جذاباند، اما نباید بهعنوان قانون کلی همهٔ پروژهها خوانده شوند.
۱) این مقایسهها از ارزیابیها و workflowهای خود سازنده میآیند؛ هنوز جای بنچمارک مستقل و آزمون روی دادهٔ واقعی هر کسبوکار خالی است.
۲) «خروجی همیشه در قالب درست است» با «تصمیم همیشه درست است» فرق دارد. Jev ممکن است یک پاسخ کاملاً معتبر اما اشتباه انتخاب کند. پس آستانه، دادهٔ برچسبخورده و مسیر بازبینی انسانی همچنان ضروریاند.
یک نکتهٔ فنی دیگر، روش آموزشی اعلامشدهٔ TypeSafe با نام RLCD یا «یادگیری تقویتی برای تصمیمهای کالیبرهشده» است. ایدهٔ ادعاشده این است که احتمال خروجی با میزان درستبودن آن در یک مجموعه داده همراستا باشد؛ برخلاف RLHF که بیشتر خروجیِ مطلوب برای ارزیاب انسانی را بهینه میکند. با این حال، کالیبراسیون نیز تضمین یک پاسخِ واحد نیست و باید با نمونههای برچسبخوردهٔ همان کسبوکار سنجیده شود.
Jev همچنین ورودی متن، JSON و آرایه را ارزیابی میکند؛ برای دیدن عکس، شنیدن تماس یا تولید محتوا ساخته نشده است. توضیح reasoning یا توجیه متنیِ بلند نیز وظیفهٔ آن نیست. برای درخواستهای مبهم، استدلال بلند، گفتوگوی چندمرحلهای و هر جایی که توضیح انسانی لازم است، LLM انتخاب طبیعیتری است.
۷. نگاه مهندسی ژیار: هوش مصنوعی لازم نیست همیشه «حرف بزند»
موج اصلی اینجا احتمالاً خودِ نام Jev نیست؛ بلکه یک الگوی معماری است: مدل مولد را فقط جایی بهکار بگیریم که واقعاً تولید لازم است، و تصمیمهای بسته و پرتکرار را با خروجی قابلاعتمادتر برای کد انجام دهیم. نتیجه میتواند هزینه و تأخیر کمتر، گزارشپذیری بهتر و کنترل انسانی روشنتر باشد.
برای سازمانها، سؤال درست این نیست که «آیا Jev را جایگزین ChatGPT کنیم؟» سؤال بهتر این است: کدام تصمیمهای روزمرهٔ ما آنقدر مشخص، پرتکرار و قابلسنجشاند که ارزش دارد به یک مسیر تصمیمگیری جدا تبدیل شوند؟ پاسخ این سؤال از یک نمونهٔ کوچک با دادهٔ واقعی شروع میشود، نه از شعار سرعت.
منابع و تاریخ بررسی
جزئیات محصول، قیمت و قابلیتها ممکن است تغییر کنند. این مقاله در ۲۸ شهریور ۱۴۰۵ / ۱۹ سپتامبر ۲۰۲۶ بررسی و نگارش شده است.
- TypeSafe AI — Introducing System One Models and Jev (اعلام رسمی، RLCD، نامگذاری و محدودیتهای ارزیابی)
- TypeSafe AI — Workflow evals (تعریف Noul / Choice / Score و روش ارزیابی)
- Awesome Jev Use Cases (GitHub) (فهرست پروژهها، بنچمارکهای جامعه متنباز و نمونههای ورودی/خروجی)
- Vercel Changelog — Jev now available on AI Gateway (کاربردها، API و انتساب ارقام مقایسه)
- Vercel — Jev is the fastest-adopted model in AI Gateway history (آمار پذیرش اولیه)
- DCVC — TypeSafe emerges from stealth (بنیانگذاران و سرمایهگذاری)
- Vercel AI Gateway — Jev model page (قیمت نمایشدادهشده و زمان عرضه)
میخواهید تصمیمهای هوشمند را وارد محصولتان کنید؟
تیم ژیار میتواند جریانهای کاری، دادهها و سطح ریسک سازمان شما را بررسی کند تا مشخص شود کجا LLM، کجا مدل تصمیمگیری و کجا کنترل انسانی مناسبتر است.