Jev و مدل‌های تصمیم

یه اتاق تفکیک نامه

فرض کنید رفتید یه اداره‌ی پست قدیمی. پشت یه میز، یه کارمند نشسته که نامه می‌نویسه: خوش‌قلمه، هر جوابی بخواید براتون می‌نویسه، ولی هر نامه یه مدت وقت می‌گیره. کنار اون، یه نفر دیگه جلوی یه قفسه‌ی پر از خونه وایستاده. هر نامه‌ای که میاد، یه نگاه بهش می‌ندازه و در یه لحظه می‌ندازدش توی یکی از خونه‌ها. روش یه مهر فوریت می‌زنه، و یه برچسب «بله» یا «نه» می‌چسبونه. این دومی هیچ‌وقت نامه نمی‌نویسه.

توی دنیای هوش مصنوعی، اون کارمند خوش‌قلم مدل‌های زبانی بزرگن (LLM، کوتاه‌شده‌ی Large Language Model)، مثل همون چت‌بات‌هایی که می‌شناسید (درس مدل زبانی چیست). و اون تفکیک‌کننده، Jev ئه.

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

هفت کلمه پیش از کار

پیش از اینکه بریم توی جزئیات، این هفت تا کلمه رو بدونید؛ تا آخر درس زیاد میان.

یه درخواست، از نزدیک

هر بار که از Jev چیزی می‌پرسید، یه درخواست می‌فرستید با سه بخش: state (چیزی که باید بررسی بشه)، اسم مدل، و یه فهرست سوال. هر سوال یه شناسه داره که خودتون انتخاب می‌کنید، مثلا refund_requested، و جوابش با همون شناسه برمی‌گرده.

چهار تا قاعده‌ی مهم این درخواست، که سند رسمی صریح گفته:

1. همه‌ی سوال‌ها یه state رو می‌بینن. یه بار نامه رو می‌دید، ده تا سوال درباره‌ش می‌پرسید.
2. هر سوال جدا و موازی جواب داده می‌شه. جواب یه سوال، روی جواب سوال دیگه اثر نمی‌ذاره. برای همین اضافه کردن سوال تقریبا وقت بیشتری نمی‌گیره و قاطی‌شدن متن (Context Rot) هم پیش نمیاد.
3. شناسه‌ی سوال به مدل فرستاده نمی‌شه. فقط مال کد شماست. پس کل سوال رو توی متن سوال بنویسید، حتی اگه شناسه گویا باشه.
4. جواب همیشه یکی از چیزهاییه که خودتون تعریف کردید. مدل یه توزیع احتمال روی گزینه‌های شما برمی‌گردونه، هیچ‌وقت چیزی بیرونش.

یه درخواست واقعی، به همون شکلی که سند رسمی نشون می‌ده، تقریبا این شکلیه:

POST https://api.typesafe.ai/v1/systemone
{
  "model": "jev-latest",
  "state": "My running shoes arrived in the wrong size.",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "returns": "Exchanges, wrong or damaged items",
        "shipping": "Delivery status, delays, lost packages",
        "billing": "Charges, invoices, payment problems"
      }
    }
  }
}

و جوابش: "choice": "returns" با احتمال ۱ برای «returns» و صفر برای بقیه، و اطمینان ۱. کفش با سایز اشتباه رسیده، پس معلومه تیم مرجوعی باید رسیدگی کنه.

state می‌تونه یه متن ساده باشه، یا یه شیء JSON با چند بخش اسم‌دار (مثلا پیام مشتری، سفارش و قانون بازگشت پول)، یا یه آرایه، مثل چند پیام پشت هم. سند پیشنهاد می‌کنه بیشتر وقت‌ها شیء بفرستید، تا هر بخش اسم داشته باشه. Jev فعلا متن می‌خونه، به هر زبونی، ولی زبان اصلی آموزشش انگلیسیه و به گفته‌ی خود سند، دقتش توی زبان‌های دیگه کمتره. پس اگه با فارسی کار می‌کنید، حتما روی داده‌ی خودتون امتحانش کنید.

سطح‌های خوب، یعنی توصیف موقعیت

مهم‌ترین قانون Score اینه: هر سطح رو با یه موقعیت توصیف کنید، نه با یه درجه. «خراب، ولی راه دور زدن هست» به مدل یه چیز می‌ده که با گزارش مقایسه کنه. «نسبتا شدید» نمی‌ده. چرا؟ چون Jev هر سطح رو جدا می‌بینه؛ شماره‌ش رو نمی‌بینه و سطح‌های کناریش رو هم نمی‌بینه. پس «بدتر از قبلی» براش معنی نداره.

سند این رو با یه آزمایش نشون داده. گزارش «دکمه‌ی خروجی چند پیکسل جابه‌جاست»، با سه سطح توصیفی، امتیاز صفر با اطمینان یک گرفت؛ یعنی کاملا ظاهری. همون گزارش، وقتی سطح‌ها فقط «۰»، «۱» و «۲» بودن، امتیاز ۰٫۵۵ با اطمینان ۰٫۳۳ گرفت؛ مدل چیزی برای مقایسه نداشت و دودل شد.

دو تا قانون دیگه: هر Score فقط یه چیز رو بسنجه (اگه توصیف می‌گه «وقت‌شناس و باهوش و باتجربه»، سه تا Score جدا لازمه)؛ و اگه بالای طیف یه حالت نادر ولی مهم هست، مثلا «توهین‌آمیز یا تهدیدکننده» بالای «خیلی عصبانی»، بهش یه سطح خودش رو بدید. اگه سطح‌ها هنوز دودلی می‌سازن، می‌شه به هر سطح چند مثال اضافه کرد. سند نشون داده یه مثال مرتبط («توی یه مرورگر خراب، توی یکی دیگه سالم») اطمینان رو از ۰٫۳۵ به ۰٫۹۶ برد، و یه مثال بی‌ربط هیچ فرقی نکرد. ولی دقت کنید: اطمینان بالاتر خودش ثابت نمی‌کنه جواب درست‌تره؛ همیشه روی نمونه‌هایی که جوابشون رو می‌دونید بسنجید.

Noul خط‌کش نیست

یه اشتباه خیلی رایج: فکر کنیم Noul اندازه‌ی یه چیز رو می‌گه. سند چهار نفر رو با دو سوال مقایسه کرده. Noul: «توی پایتون قویه؟». Score: «چقدر تجربه‌ی پایتون داره؟» با چهار سطح (هیچ، کمی، استفاده‌ی روزانه سر کار، تخصص عمیق). کسی که هشت ساله هر روز پایتون می‌نویسه، Noul ۰٫۹۲ گرفت و Score ۲٫۸۹. کسی که دو سال هر روز نوشته، ۰٫۸۱ و ۲٫۰۵.

۰٫۸۱ یعنی «۸۱ درصد احتمال داره جواب «قویه» بله باشه»، نه «۸۱ درصد قوی». و یه عدد وسط، مثلا ۰٫۵، می‌تونه یعنی «تجربه‌ی متوسط» یا «معلوم نیست». اگه اندازه می‌خواید، Score بپرسید. اگه بله و نه می‌خواید، شرط رو دقیق بنویسید: «توی رزومه نوشته سر کار از پایتون استفاده کرده؟».

آستانه‌ی Noul، بسته به گرونی اشتباه

بیشتر وقت‌ها کد Noul رو با یه آستانه به بله و نه تبدیل می‌کنه. کجا بذاریمش؟ سند می‌گه بسته به اینکه کدوم اشتباه گرون‌تره. اگه بله و نه هم‌اندازه‌ان، ۰٫۵. اگه بله‌ی اشتباه گرونه، مثلا پول برگردوندن یا بیدار کردن یه نفر نصفه‌شب، آستانه رو بالا ببرید. اگه نه‌ی اشتباه گرونه، مثلا جا انداختن یه خطر امنیتی، پایین بیارید. و عددهای وسط رو بدید به یه آدم. مثال سند: زیر ۰٫۲ یعنی نه، بالای ۰٫۸ یعنی بله، و بینشون بررسی آدم.

سه تا قانون نوشتن Noul: یه سوال، یه شرط (نه «عصبانیه و پول می‌خواد؟»)؛ طوری بپرسید که عدد بالا یعنی بله («پیام اطلاعات شخصی داره؟»، نه «پیام از اطلاعات شخصی خالیه؟»)؛ و مرز بله و نه رو روشن کنید. اگه مرز ظریفه، می‌شه توضیح جدا برای «بله» و «نه» داد. جمله‌ی خبری هم به‌جای سوال کار می‌کنه: «مشتری پول برگشتی می‌خواد».

اطمینان: «نمی‌دونم» هم یه جوابه

سند TypeSafe یه جمله‌ی خوب داره: سیستمی که نتونه صادقانه بگه مطمئن نیست، قابل اعتماد نیست. اطمینان دقیقا برای همینه. Jev برای هر Choice و Score یه عدد اطمینان برمی‌گردونه که از شکل احتمال‌ها حساب می‌شه: اگه همه‌ی احتمال روی یه جواب باشه، یک؛ اگه یکسان پخش شده باشه، صفر.

فرمول‌ها رو خود سند منتشر کرده، برای اینکه بدونید هر عدد از کجا میاد:

1. Choice: احتمال گزینه‌ی برنده، منهای یک تقسیم بر تعداد گزینه‌ها، تقسیم بر یک منهای یک تقسیم بر تعداد گزینه‌ها. یعنی چقدر بالاتر از «تقسیم مساوی» وایستاده. مثلا با سه گزینه و احتمال ۰٫۹ برای برنده: (۰٫۹ منهای یک‌سوم) تقسیم بر دوسوم، می‌شه ۰٫۸۵. فقط برنده حساب می‌شه؛ پس (۰٫۶، ۰٫۳، ۰٫۱) و (۰٫۶، ۰٫۲، ۰٫۲) هر دو ۰٫۴ می‌گیرن.
2. Score: چون سطح‌ها ترتیب دارن، فاصله هم مهمه. اطمینان می‌شه یک منهای «میانگین فاصله‌ی احتمال‌ها از پربارترین سطح، تقسیم بر همین میانگین برای یه پخش یکسان». نتیجه: دودلی بین دو سطح کنار هم، کمتر از دودلی بین دو سر خط اطمینان رو پایین میاره. با سه سطح، (صفر، ۰٫۵، ۰٫۵) اطمینان ۰٫۲۵ می‌گیره، ولی (۰٫۵، صفر، ۰٫۵) صفر.
3. Noul: اطمینان جدا نداره؛ خود عدد کافیه.

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

چطور آموزش دیده

مدل‌های زبانی بعد از خوندن اینترنت (درس پیش‌آموزش) یه آموزش دوم می‌بینن تا به کار خاصی بیان. سند TypeSafe سه راه رو کنار هم گذاشته:

1. RLHF، کوتاه‌شده‌ی Reinforcement Learning from Human Feedback، یعنی «یادگیری تقویتی از بازخورد آدم». مدل یاد می‌گیره جوابی بده که آدم‌ها بیشتر می‌پسندن؛ همین چت‌بات‌ها رو ساخت (درس RLHF). یه نکته‌ی جالب: به گفته‌ی سند، دیوگو آلمیدا، هم‌بنیان‌گذار TypeSafe، خودش از هم‌سازنده‌های همین روش بوده.
2. RLVR، کوتاه‌شده‌ی Reinforcement Learning with Verifiable Rewards، یعنی «یادگیری تقویتی با پاداش قابل بررسی». مدل روی چیزهایی که ماشین می‌تونه درست و غلطش رو چک کنه، مثل ریاضی، تمرین می‌کنه؛ مدل‌های استدلال این‌جوری ساخته شدن، که قوی‌ان ولی کند و گرون.
3. RLCD، کوتاه‌شده‌ی Reinforcement Learning for Calibrated Decisions، یعنی «یادگیری تقویتی برای تصمیم کالیبره». راه TypeSafe: مدل متن نمی‌سازه، تصمیم و احتمال برمی‌گردونه، و احتمال بالاتر باید یعنی شانس بیشتر درست بودن.

چرا راه سوم؟ سند می‌گه RLHF مدل رو تشویق می‌کنه چیزی بگه که آدم‌ها خوششون میاد، و این می‌تونه به چاپلوسی و توهم‌های مطمئن‌نما (Hallucination) برسه (درس توهم مدل). یه اثر دیگه هم داره به اسم افت حالت (Mode Dropping): مدل یه سبک رو ترجیح می‌ده و احتمال بقیه‌ی جواب‌های ممکن رو کم می‌کنه، که شکل ملایم‌تر همون چیزیه که بهش می‌گن فروپاشی حالت (Mode Collapse). جوابی که به نظر آدم قانع‌کننده‌ست، لزوما برای یه کار خودکار بی‌ناظر قابل اعتماد نیست.

یه نکته‌ی صادقانه: جزئیات روش RLCD منتشر نشده (معماری رو هم چند بخش پایین‌تر باز می‌کنیم)، و سند هم می‌گه Jev با داده‌ی مشتری‌ها شخصی‌سازی نمی‌شه؛ یه مدل برای همه‌ست. شما جواب‌هاش رو فقط از راه خود درخواست شکل می‌دید: state، متن سوال و توضیح گزینه‌ها.

زیر کاپوت: Jev ترنسفورمره؟ اصلا LLM‌ه؟

تا این‌جا دیدیم Jev از بیرون چی کار می‌کنه. حالا سوال اصلی: توی اون جعبه چیه؟ همون ترنسفورمری (Transformer) که ChatGPT و Claude روش ساخته شدن (درس ترنسفورمر چیست)، یا یه چیز کاملا تازه؟ شاید هم یه LLM معمولیه که فقط کارش رو عوض کردن؟

اول یه چیز رو صاف بگم: TypeSafe تا امروز (۲۵ مهر ۱۴۰۵) نه مقاله‌ی فنی داده، نه وزن‌های مدل رو منتشر کرده، نه گفته چند پارامتر (Parameter) داره. مدیرعاملش توی بحث Hacker News گفته معماری رو فعلا پیش خودشون نگه می‌دارن و شاید بعدا مقاله بنویسن. پس هر کی با اطمینان بهتون گفت «Jev فلان معماریه»، داره حدس می‌زنه. کاری که ما این‌جا می‌کنیم اینه که مثل یه کارآگاه، چیزهایی که خودشون گفتن رو از حدس بقیه جدا کنیم، و ببینیم سرنخ‌ها به کدوم طرف اشاره می‌کنن.

توی بلاگ رونمایی (۲۴ شهریور ۱۴۰۵، یعنی ۱۵ سپتامبر ۲۰۲۶)، TypeSafe فقط سه تا کلمه درباره‌ی ساختش گفته: یه معماری تازه (New Model Architecture)، یه نمونه‌گیر موازی (Parallel Sampler) برای سرعت، و روش آموزش RLCD. یه جمله‌ی دیگه هم هست که از همه مهم‌تره: Jev همه‌ی احتمال‌ها رو موازی بیرون می‌ده، نه این‌که تکه به تکه بنویسه. توی پرسش‌های پرتکرار همون صفحه هم یه سوال گذاشتن به اسم «Jev فقط یه LLM کوچیک‌تره؟»، ولی جوابش رو ننوشتن.

فرق بزرگ: نوشتن تکه به تکه، یا یه دور خوندن

این تنها چیزیه که درباره‌ی درونش مطمئنیم، و مهم‌ترینش هم هست. یه LLM مثل ChatGPT جوابش رو تکه به تکه می‌نویسه؛ هر تکه رو بر اساس همه‌ی تکه‌های قبلی حدس می‌زنه. به این کار می‌گن تولید خودبازگشتی (Autoregressive Generation) (درس پیش‌بینی تکه‌ی بعد). مثلا فرض کنید جواب «billing» سه تا توکن باشه. مدل باید سه بار پشت سر هم کل شبکه‌ش رو اجرا کنه، و هر بار منتظر بمونه بار قبلی تموم بشه. هر کدوم از این دورها رو بهش می‌گن یه گذر رو به جلو (Forward Pass).

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

همین یه فرق، سه تا چیز عجیب Jev رو توضیح می‌ده. اول این‌که چرا خروجی مجانیه: توی LLM هر توکن خروجی یه دور کامل خرج داره، ولی Jev اصلا خروجی متنی نمی‌سازه که خرج داشته باشه؛ همه‌ی خرج همون خوندنه. دوم این‌که چرا انقدر سریعه (۷۰ تا ۵۰۰ میلی‌ثانیه): هیچ حلقه‌ای نیست که منتظرش بمونه. سوم این‌که چرا هیچ‌وقت جواب بی‌ربط یا خارج از گزینه‌ها نمی‌ده: چون جواب رو نمی‌نویسه، فقط بین گزینه‌هایی که شما دادید احتمال پخش می‌کنه، شبیه کاری که سافت‌مکس (Softmax) می‌کنه (درس سافت‌مکس). ولی یادتون باشه: گزینه‌ی غلط ولی معتبر رو هنوز می‌تونه انتخاب کنه، و خود مدیرعامل هم گفته این مدل‌ها احتمالاتی‌ان و ممکنه با اطمینان اشتباه کنن.

سه حدس درباره‌ی توی جعبه

از وقتی Jev اومده، برنامه‌نویس‌ها توی Hacker News و Reddit سه تا حدس زدن. ترنسفورمرها دو تا نیمه دارن: رمزگذار (Encoder) که متن رو می‌فهمه و رمزگشا (Decoder) که متن می‌نویسه (درس رمزگذار و رمزگشا). دو تا از حدس‌ها سر همینه که Jev از کدوم نیمه ساخته شده.

1. حدس اول: یه LLM رمزگشا که حلقه‌ی نوشتنش رو برداشتن. یعنی یه مدل زبانی معمولی، از همون خانواده‌ای که ChatGPT ازشه (درس فقط رمزگشا)، که به جای «بنویس تکه‌ی بعد» یه سر تازه (Head) روش گذاشتن که مستقیم احتمال گزینه‌ها رو بده، و بعد با RLCD حسابی آموزشش دادن. بیشتر کسایی که توی بحث‌ها نظر دادن همین رو گفتن، و با همه‌ی سرنخ‌ها هم جور درمیاد: توکن، پنجره‌ی ۲۶۲ هزارتایی، و اون جمله‌ی «مدل‌های زبانی پیش‌آموزش‌دیده».
2. حدس دوم: یه رمزگذار، شبیه BERT. BERT، کوتاه‌شده‌ی Bidirectional Encoder Representations from Transformers، یعنی «نمایش دوطرفه با رمزگذار ترنسفورمر»، مدل معروف گوگل از سال ۲۰۱۸ (درس فقط رمزگذار). این مدل‌ها متن نمی‌نویسن، فقط می‌فهمن و دسته‌بندی می‌کنن؛ یعنی دقیقا کار Jev. یکی توی Hacker News نوشت «این فقط BERT با داده‌ی بیشتره». ولی یه چیز جور درنمیاد: BERT اصلی فقط ۵۱۲ توکن جا داشت و نسخه‌ی تازه‌ترش، ModernBERT، حدود ۸ هزار. ۲۶۲ هزار توکن برای این خانواده خیلی دوره. یکی دیگه هم جواب داد که مدل‌های BERT‌مانند برای این‌که همه‌جور سوالی رو بی مثال جواب بدن، زیادی کوچیکن. جواب وسط هم این بود: شاید BERT‌مانند، ولی با داده و محاسبه و دستور آموزش LLM‌های امروز.
3. حدس سوم: دیفیوژن. مدل‌های دیفیوژن (Diffusion) کل خروجی رو با هم و در چند قدم صاف می‌کنن، نه تکه به تکه. این هم با «همه با هم» جور درمیاد. یکی هم گفت با یه مدل زبانی دیفیوژنی تونسته رابطی شبیه Jev بسازه. ولی برای خود Jev هیچ مدرکی نیست؛ فقط حدسه.

منبع حدس‌ها: بحث‌های Hacker News درباره‌ی رونمایی Jev و پروژه‌ی OpenJev (مهر ۱۴۰۵)؛ هیچ‌کدوم رو TypeSafe تایید نکرده.

سوال خوب نوشتن

سند می‌گه «این احتمالا مهم‌ترین مفهوم این راهنماست»: سوال‌ها باید روشن، باریک، مشخص و اتمی باشن. سوال کلی چند قضاوت رو پشت یه جواب قایم می‌کنه؛ سوال اتمی هر قضاوت رو جدا جلوی چشم شما می‌ذاره تا بسنجید، تنظیم کنید و ترکیب کنید.

1. یه سوال، یه چیز. به‌جای «این پیشنهاد استارتاپی رو امتیاز بده»، سه تا سوال: اندازه‌ی بازار، شدنی بودن فنی، تفاوت با رقیب. بعد با وزن‌های خودتون ترکیب کنید.
2. به بخش درست اشاره کنید. اگه state چند بخش داره، توی سوال با یه مسیر نقطه‌ای و بک‌تیک بهش اشاره کنید، مثلا `ticket.messages[0].text`. این‌جوری مدل می‌دونه کدوم بخش رو بسنجه.
3. فقط چیزی که لازمه رو بفرستید. متن بی‌ربط حواس مدل رو پرت می‌کنه. پیش از فرستادن، توی کد فیلتر کنید.
4. به دانسته‌ی مدل تکیه نکنید. اطلاعات به‌روز رو از پایگاه دانش خودتون بیارید و بذارید توی state (درس RAG).
5. کار قطعی رو بدید به کد. «سی روز گذشته؟» رو کد حساب می‌کنه، نه مدل.
6. ساختار، وقتی لازمه. متن سوال و توضیح‌ها می‌تونن شیء باشن: سوال توی یه فیلد، داده‌ی کمکی (مثلا یه رکورد از پایگاه داده) توی فیلد دیگه. سند می‌گه حداکثر ۶۴ لایه‌ی تودرتو قبوله.

چهار الگوی ساختن

سند TypeSafe یه فکر اصلی داره: نرم‌افزار معمولی بنویسید و Jev رو فقط جایی بذارید که هوش لازمه. کنترل کار، قانون‌های قطعی و کارهای پیامددار مال کد باشه؛ Jev فقط قضاوت‌های باریک. این رو با ایجنت‌ها مقایسه می‌کنه (درس ایجنت)، که خودشون قدم بعدی رو انتخاب می‌کنن و هر دور می‌تونن از مسیر خارج بشن. چهار الگوی رسمی:

1. فن‌اوت حدسی (Speculative Fan-out). همه‌ی سوال‌هایی که شاید لازم بشن رو با هم بپرسید، حتی اونایی که فقط برای بعضی ورودی‌ها مهمن، و کد تصمیم بگیره کدوم رو استفاده کنه. مثلا «شدت باگ» رو همیشه بپرسید؛ اگه تیکت باگ نبود، جوابش رو نادیده بگیرید. سند با یه نمونه نشون داده ۱۳ سوال توی یه درخواست، ۱۲٫۲ برابر ارزون‌تر و ۱۰ برابر تندتر از ۱۳ درخواست جداست، بی هیچ فرقی توی جواب‌ها.
2. مسیریابی با اطمینان (Confidence-gated Routing). جواب می‌گه «چی»؛ اطمینان می‌گه «انجامش بدیم یا نه». همون مثال بانکی بالا.
3. امتیاز ترکیبی (Composite Scoring). یه قضاوت پیچیده رو به چند امتیاز اتمی بشکنید و با وزن‌های خودتون ترکیب کنید؛ مثلا رتبه‌بندی رزومه‌ها با چند معیار.
4. مسیریابی نیت (Intent Routing). هر درخواست رو دسته‌بندی کنید و بفرستید پیش بهترین جواب‌دهنده: کد قطعی، یه LLM تخصصی، یا یه آدم.

و یه قانون درباره‌ی ترتیب: سوال‌های یه درخواست به هم وابسته نیستن. فقط وقتی دو درخواست بفرستید که کد واقعا بدون جواب اولی نتونه دومی رو بسازه؛ مثلا اول بفهمه کدوم سه تا ابزار مرتبط‌ترن، بعد متن کامل همون سه تا رو بیاره و دوباره بسنجه.

نه لبه‌ی ناصاف

یه کار خوب TypeSafe اینه که خودش یه صفحه نوشته با عنوان «Jev کامل نیست» و فهرست جاهایی که نسخه‌ی ۱٫۱۳ می‌لنگه (آخرین بازبینی، ۲ اکتبر ۲۰۲۶). به این جاها می‌گن ناصافی (Jaggedness): مدلی که توی یه کار خیلی خوبه، توی یه کار کناری یهو ضعیف می‌شه. نه مورد:

نشونه، نه کلید در

1. نشونه، نه دروازه. برای کارهایی مثل پاک کردن، پرداخت یا فرمان خطرناک، قانون قطعی کد و تایید آدم بمونه؛ Jev فقط یه نشونه بده.
2. هر چی Jev دید و گفت رو ثبت کنید. چون توضیح نمی‌ده، برای اینکه بعدا بدونید چرا یه تصمیم گرفته شد، state، سوال‌ها، نسخه‌ی مدل و جواب رو نگه دارید.
3. نسخه رو قفل کنید. اسم مستعار jev-latest با هر نسخه‌ی تازه جابه‌جا می‌شه و جواب‌ها ممکنه عوض بشن. اگه مرزهاتون رو روی یه نسخه تنظیم کردید، شماره‌ی دقیقش رو بفرستید، و پیش از عوض کردن، دوباره بسنجید.
4. داده‌ی حساس رو حذف کنید پیش از فرستادن، و دنبال جمله‌های «تایید شده» و دستورهای قایم‌شده توی state بگردید.
5. روی کار خودتون آزمون کنید: تزریق، ادعای تایید، و عوض کردن ترتیب گزینه‌ها.

درباره‌ی داده: سند می‌گه Jev روی درخواست‌ها و جواب‌های مشتری آموزش نمی‌بینه، و برای شرکت‌های بزرگ نگه نداشتن هیچ داده‌ای (Zero Data Retention) هم قابل مذاکره‌ست. سرویس توی آمریکا میزبانی می‌شه و منطقه‌ی دیگه‌ای اعلام نشده.

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

1. دو اندازه‌ی متن (Context Length). کل درخواست (state به‌اضافه‌ی همه‌ی سوال‌ها) تا ۶۴ هزار توکن، و state به‌اضافه‌ی هر سوال تنها تا ۳۲ هزار. تعداد سوال محدودیت جدا نداره؛ فقط باید توی این دو اندازه جا بشه (درس پنجره‌ی متن).
2. متن بلند. با یه هدر جدا، هر دو اندازه به ۲۶۲ هزار توکن می‌رسه، با همون قیمت؛ ولی به گفته‌ی سند کندتر و کم‌دقت‌تره، پس فقط وقتی لازمه. سازنده اسم این هدرها رو گذاشته «منطقه‌ی خطر» (Danger Zone)، که خودش یه هشداره.
3. قواعد درخواست. حداکثر ۳۲ مگابایت، فقط JSON با UTF-8، حداکثر ۶۴ لایه‌ی تودرتو، و فقط عدد محدود؛ عدد خیلی بزرگ یا شناسه رو به شکل متن بفرستید.
4. محدودیت سرعت. برای هر سازمان، بر اساس توکن و درخواست در ثانیه. بیشتر از اون، خطای ۴۲۹ می‌ده، و کتابخونه‌های رسمی خودشون با فاصله‌ی بیشتر دوباره امتحان می‌کنن.

عددها: سرعت و دقت

اینجا باید خیلی صادق باشیم، چون عددها از جاهای مختلف میان. سند رسمی می‌گه بیشتر درخواست‌ها حدود ۱۰۰ میلی‌ثانیه طول می‌کشن. یه آزمون مستقل آلمانی حدود ۳۰۰ میلی‌ثانیه دید، در برابر ۲ تا ۷ ثانیه برای یه LLM سبک.

برای دقت، معروف‌ترین عدد از آزمون خود TypeSafe با چهار گردش‌کار واقعیه (پاسخ به حادثه‌ی امنیتی، بررسی ردپای ایجنت، پردازش فاکتور و خدمات مشتری):

Jev با ۶۷٫۸ درصد، تقریبا هم‌اندازه‌ی GPT-5.6 Terra (۶۷٫۹) و حدود ۶ امتیاز پایین‌تر از بهترین‌ها. ولی هزینه‌ی هر مورد ۰٫۰۰۰۴ دلار در برابر ۰٫۰۳ تا ۰٫۱۸ دلار، و زمانش ۰٫۴ ثانیه در برابر ۱۰ تا ۳۸ ثانیه. سه قید مهم: این آزمون رو تیم خود TypeSafe ساخته؛ «جواب درست» میانگین جواب دو تا LLM بزرگ بوده، نه برچسب آدم؛ و LLMها از راه یه ابزار خود TypeSafe جواب دادن.

یه آزمون مستقل روی ۲۰۰ مورد، Jev رو ۷۲٫۵ درصد سنجید، در برابر ۸۴٫۰ و ۷۹٫۰ برای دو LLM بزرگ، و یه مطالعه‌ی بزرگ‌تر دید Jev توی ۱۴ از ۱۵ کار از بهترین LLM عقب‌تره. خلاصه‌ی منصفانه: Jev از بهترین‌ها کمی کم‌دقت‌تره، ولی ده‌ها تا صدها برابر تندتر و ارزون‌تره. اگه کار شما تصمیم‌های زیاد و تکراری با گزینه‌های معلومه، این معامله معمولا می‌ارزه.

مقایسه با بقیه

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

شرکت و تاریخچه

TypeSafe یه استارتاپ سان‌فرانسیسکوییه که ۱۵ سپتامبر ۲۰۲۶ از حالت پنهان بیرون اومد و همون روز Jev رو منتشر کرد، با ۴۰ میلیون دلار سرمایه‌ی بذری. بنیان‌گذارهاش، طبق گزارش‌ها، دیوگو آلمیدا (Diogo Almeida، مدیرعامل) که پیش‌تر پژوهشگر OpenAI و Google Brain بوده، ساشا شنگ (مدیر عملیات) و اریک گافنی (مدیر فنی) هستن.

پذیرش خیلی تند بود. شرکت Vercel که یه دروازه‌ی مدل هوش مصنوعی داره، گزارش کرد ۱۳ درصد کاربرهای پولیش توی ۲۴ ساعت اول Jev رو امتحان کردن، دو برابر هر مدل قبلی. حدود سه هفته بعد، ۹ اکتبر، TypeSafe ۸۷۰ میلیون دلار با ارزش ۷٫۵ میلیارد دلار جذب کرد، به رهبری Andreessen Horowitz و با حضور Sequoia و DCVC. یعنی طبق تعریف درس واژه‌نامه‌ی استارتاپ، توی کمتر از یه ماه یونیکورن شد. یه عدد هم منتشر شده که درآمد سالانه‌ش توی هفت روز به ۱۰۰ میلیون دلار رسیده، ولی فقط از زبون یه سرمایه‌گذار گفته شده و ثابت نشده.

۲ اکتبر صفحه‌ی نقطه‌ضعف‌های ۱٫۱۳ منتشر شد، ۱۴ اکتبر نسخه‌ی ۱٫۱۴ با عکس و Box، و ۱۵ اکتبر مانیفست شرکت. تا امروز دسترسی از راه ثبت‌نام و کنسول خودشونه، و توی بعضی دروازه‌های مدل هم هست.

شروع، قدم به قدم

اگه برنامه‌نویسید، این راه ساده‌ترینه:

1. زمین بازی (Playground). توی کنسول TypeSafe، بی یه خط کد: یه متن رو به‌عنوان state بچسبونید، یه سوال اضافه کنید، مثلا Noul «این پیام فوریت داره؟»، و جواب رو ببینید. بعد چند سوال از هر سه نوع با هم.
2. کلید (API Key). از بخش کلیدهای کنسول بسازید و توی یه متغیر محیطی به اسم TYPESAFE_API_KEY بذارید، نه توی کد.
3. نصب کتابخونه. پایتون ۳٫۱۰ به بالا: pip install typesafe-sdk. جاوااسکریپت با Node ۲۰ به بالا: npm install @typesafe-ai/sdk.
4. اولین درخواست. یه state و سه سوال (یه Choice، یه Score، یه Noul) بفرستید و جواب‌ها رو چاپ کنید؛ نمونه‌ی پایین.
5. آستانه‌ها. چند صد نمونه‌ی واقعی از کار خودتون با جواب درست جمع کنید، و مرزهای اطمینان رو روی اون‌ها بذارید.
6. ثبت و قفل نسخه. state، سوال، نسخه و جواب رو ثبت کنید و شماره‌ی دقیق نسخه رو بفرستید.

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

ticket = "Our API started returning 500 errors 20 minutes ago."

with TypeSafeClient(model="jev-latest") as client:  # reads TYPESAFE_API_KEY
    r = client.system_one(
        state=ticket,
        questions={
            "department": Choice("Which team should handle this?", {
                "billing": "Payment or subscription issues",
                "technical": "Bugs or integration problems",
                "sales": "Pricing or account questions",
            }),
            "frustration": Score("How frustrated is the customer?", [
                "Calm", "Concerned but civil", "Very angry",
            ]),
            "is_urgent": Noul("The message conveys urgency."),
        },
    )

print(r.choices["department"].choice)   # technical
print(r.scores["frustration"].score)    # 0.67
print(r.nouls["is_urgent"].noul)        # 0.99

عددهای کامنت، جواب نمونه‌ی خود سنده و ممکنه با نسخه‌ی بعد عوض بشه. اگه با یه ابزار برنامه‌نویسی هوش مصنوعی کار می‌کنید، سند یه «مهارت ایجنت» (Agent Skill) هم داره که به اون ابزار یاد می‌ده کد درست برای Jev بنویسه. ولی یادتون باشه Jev خودش جای مدل اون ابزار رو نمی‌گیره.

کی Jev، کی LLM، کی کد

سندهای رسمی این درس ۲۵ مهر ۱۴۰۵ (۱۷ اکتبر ۲۰۲۶) خونده و ذخیره شدن؛ Jev خیلی تازه‌ست و عددها، نسخه‌ها و قیمت‌ها ممکنه زود عوض بشن.