TypeSafe دقیقاً چه مشکلی را حل میکند؟
نرمافزارها با عدد و قانون راحتاند. موجودی را میخوانند، تاریخها را مقایسه میکنند و سفارش را به صف درست میفرستند. دردسر از جایی شروع میشود که ورودی، حرف آدمهاست؛ حرفی که ممکن است ناقص، محاورهای یا دوپهلو باشد.
فرض کنید مشتری نوشته است:
یک قانون ساده ممکن است با دیدن واژه «پول»، پیام را اشتباه به بخش بازپرداخت بفرستد. مدل زبانی هم احتمالاً جواب مؤدبانهای مینویسد، درحالیکه فروشگاه فعلاً جواب نمیخواهد؛ فقط باید بفهمد مشتری تعویض میخواهد یا پسگرفتن پول.
Jev، مدل TypeSafe، همین کار را انجام میدهد. اطلاعات را میخواند، آنها را با معیارهای شما میسنجد و یکی از جوابهای ازپیشتعیینشده را پیشنهاد میکند. به این نقش لایه تصمیمگیری (Decision Layer) میگویند: معنی موقعیت را میفهمد، اما خودش کاری را اجرا نمیکند.
TypeSafe، System One و Jev چه فرقی با هم دارند؟
در مستندات TypeSafe چند اسم شبیه به هم میبینیم. TypeSafe AI نام شرکت است، System One خانواده مدلهای تصمیمگیر آن و Jev اولین مدل عمومی این خانواده. API و SDK راه ارتباط برنامه با سرویساند؛ Agent Skill هم راهنمایی است که به دستیار کدنویسی کمک میکند این ارتباط را بسازد.
| نام | چیست؟ | کارش چیست؟ |
|---|---|---|
| TypeSafe AI | شرکت | مدل، سرویس و ابزار توسعه میسازد |
| System One | خانواده مدل | مدلهای تصمیمگیر TypeSafe را دربرمیگیرد |
| Jev | مدل | از میان جوابهای مشخص انتخاب میکند |
| API و SDK | رابط فنی | برنامه را به Jev وصل میکنند |
| Agent Skill | راهنمای ساخت | به دستیار کدنویسی روش اتصال را توضیح میدهد |
نام System One از مفهوم «تفکر سریع» در کتاب تفکر، سریع و کند آمده است؛ یعنی تصمیمی سریع درباره یک سؤال محدود. طبق توضیح رسمی TypeSafe، باید سه چیز روشن باشد: مدل چه اطلاعاتی میبیند، چه سؤالی را جواب میدهد و پاسخ چه شکلی دارد.
شرکت در سال ۲۰۲۴ شکل گرفت و Jev را در سپتامبر ۲۰۲۶ معرفی کرد. بنیانگذارانش پیشتر در OpenAI، Google Brain و Meta/FAIR کار کردهاند. TypeSafe همزمان اعلام کرد در مرحله Seed و با رهبری DCVC، ۴۰ میلیون دلار سرمایه جذب کرده است؛ جزئیات در اطلاعیه تأمین مالی آمده است. البته سابقه تیم و رقم سرمایهگذاری بهتنهایی چیزی درباره کیفیت Jev ثابت نمیکند.
Jev چطور یک ورودی مبهم را به تصمیم تبدیل میکند؟
مدلهای مولد معمولاً پاسخ را کلمهبهکلمه میسازند و برای نوشتن متن یا کد مناسباند. Jev قرار نیست چیزی بنویسد. اطلاعات لازم را به آن میدهید و یک سؤال مشخص میپرسید؛ مثلاً «این مشتری تعویض میخواهد یا بازپرداخت؟» پاسخ هم باید یکی از گزینههایی باشد که خودتان از قبل تعیین کردهاید.
TypeSafe به مجموعه اطلاعاتی که Jev میبیند State میگوید. در مثال فروشگاه، متن پیام، زمان تحویل و نوع کالا کافی است. شماره کارت یا نشانی کامل کمکی به این تصمیم نمیکند و فقط اطلاعات حساس بیشتری را درگیر میکند.
TypeSafe روش آموزشی خود را RLCD مینامد؛ هدف این است که میزان اطمینان مدل هم قابلسنجش باشد.
مدل تصمیمگیرمدل میتواند چند سؤال مستقل را درباره همان اطلاعات جواب بدهد.
جواب همراه با میزان اطمینانقوانین و مجوزها مشخص میکنند پیشنهاد Jev اجرا شود یا به کارشناس برسد.
اجرای کنترلشدهJev میتواند چند سؤال مستقل را همزمان بررسی کند؛ TypeSafe نام این قابلیت را Parallel Sampler گذاشته است. روش آموزش مدل هم RLCD نام دارد و هدفش این است که Jev کنار هر انتخاب، عدد قابلاستفادهای برای میزان اطمینان بدهد. TypeSafe جزئیات دادههای آموزشی، اندازه مدل و ساختار دقیق شبکه را منتشر نکرده؛ پس چیزی که میدانیم معماری محصول است، نه جزئیات درون مدل.
سه نوع خروجی اصلی
Choice
از بین گزینههای مشخص یکی را انتخاب میکند؛ مثل تعویض، بازپرداخت یا نامشخص.
exchange: 0.92Noul
احتمال درستبودن یک گزاره را میدهد؛ مثلاً آیا مشتری بازپرداخت میخواهد؟
wants_refund: 0.03Score
ویژگی درجهای مانند فوریت را روی سطحهای تعریفشده میسنجد.
urgency: 1.4 / 3Choice یک مسیر را انتخاب میکند، Noul میگوید یک گزاره با چه احتمالی درست است و Score ویژگیهایی مثل فوریت را روی یک طیف میسنجد. Score ماشینحساب نیست؛ محاسبه تاریخ و مبلغ را به کد بسپارید. حد اطمینان هم به هزینه اشتباه بستگی دارد.
در عمل، Jev کجای یک محصول قرار میگیرد؟
سه نمونه زیر را سازندگان یا کاربران اولیه منتشر کردهاند. اینها آزمون مستقل Jev نیستند، اما خیلی روشن نشان میدهند مدل کدام تصمیم را میگیرد و چه چیزی را به ابزارهای دیگر میسپارد.
انتخاب مدل تصویر یا ویدئو
Jev پرامپت را میخواند و مناسبترین مدل را پیشنهاد میدهد. ساخت تصویر یا ویدئو همچنان کار مدلهای Higgsfield است.

انتخاب حرکت بعدی مرورگر
Jev از روی دکمهها و فیلدهای صفحه، قدم بعدی را انتخاب میکند و Stagehand آن را انجام میدهد.
مرتبکردن ۱۵۰۰ ایمیل
Jev موضوع و اولویت ایمیلها را تشخیص میدهد و برنامه برچسب میزند. نویسنده آمار دقت منتشر نکرده است.
نکته مشترک هر سه نمونه همین است: Jev تصمیم را پیشنهاد میدهد و ابزار دیگری آن را اجرا میکند.
Jev غیر از چتبات و ایجنت کجا به کار میآید؟
یک ایجنت برای مدیریت ابزارها، مجوزها و زمان توقف به محیطی کنترلی نیاز دارد که به آن Harness میگویند. LangChain در نمونه خود از Jev کمک گرفته تا مدل مناسب را انتخاب کند و پیش از اجرای یک ابزار، میزان خطر آن را بسنجد.
اگر Jev کاری را پرخطر بداند، برنامه میتواند جلوی اجرای آن را بگیرد. اما مجوز اصلی باید در خود ابزار کنترل شود، نه در مدل. این کاربرد فقط به ایجنتها محدود نیست. هرجا فهم زبان لازم است و جوابها از قبل معلوماند، Jev میتواند به کار بیاید:
| محیط | کاری که Jev انجام میدهد | کاری که با نرمافزار میماند |
|---|---|---|
| جستوجوی کالا | سنجیدن تناسب نتایج با خواسته کاربر | پیداکردن کالا، بررسی موجودی و مرتبسازی |
| گزارش خدمات | تشخیص نوع ایراد یا کاملبودن گزارش | فرستادن گزارش به بخش درست و کنترل ایمنی |
| بازخورد مشتری | تشخیص اشاره به قیمت، قابلیت یا دشواری | تحلیل آماری و ساخت گزارش |
| خواندن فاکتور | انتخاب مبلغ قابلپرداخت از میان عددها | کپیکردن مقدار اصلی بدون بازنویسی |
| بازی و شبیهسازی | انتخاب یکی از حرکتهای مجاز | اجرای حرکت و بهروزرسانی وضعیت بازی |
برای نمونه، برنامه ابتدا همه عددهای یک فاکتور را پیدا میکند. Jev مشخص میکند کدامیک «مبلغ قابلپرداخت» است و برنامه همان عدد را کپی میکند. اگر عدد موردنظر از ابتدا پیدا نشده باشد، Jev هم نمیتواند آن را حدس بزند.
چه زمانی Jev انتخاب خوبی است و چه زمانی نیست؟
Jev جواب همه مسئلهها نیست. اگر میشود شرط را دقیق نوشت، کد معمولی سادهتر و مطمئنتر است. اگر هم خروجی باید متن، تصویر یا راهحلی تازه باشد، مدل مولد انتخاب مناسبتری است. Jev به درد جایی میخورد که فهم ورودی سخت است، اما جوابهای ممکن را از قبل میدانیم.
| راهکار | مناسب برای | نقطه قوت | مرز مهم |
|---|---|---|---|
| قواعد قطعی | تاریخ، مبلغ، موجودی و مجوز | قابلپیشبینی و ارزان | زبان مبهم را خوب نمیفهمد |
| LLM مولد | نوشتن و مسئلههای باز | ساختن محتوای تازه | جوابهایش به چند گزینه محدود نیست |
| Jev | فهم منظور و انتخاب از چند گزینه | جواب مشخص همراه با میزان اطمینان | به قوانین و کنترل اجرای جداگانه نیاز دارد |
| طبقهبند اختصاصی | کار ثابت با داده برچسبخورده زیاد | برای یک مسئله مشخص بهینه میشود | آموزش و نگهداری جداگانه میخواهد |
| ایجنت | مأموریت چندمرحلهای با مسیر متغیر | میتواند برای چند قدم برنامه بریزد | کنترلکردن اختیار و خطاهایش سختتر است |
LLMهای امروزی هم میتوانند JSON مرتب تحویل بدهند؛ بنابراین خروجی ساختاریافته بهتنهایی دلیل انتخاب Jev نیست. مقایسه واقعی باید با داده یکسان و بر اساس دقت، قابلاعتمادبودن احتمالها، زمان و هزینه انجام شود. معمولاً هم یک ترکیب بهتر جواب میدهد: Jev منظور را تشخیص میدهد، کد واقعیتها و مجوزها را بررسی میکند و مدل مولد، در صورت نیاز، متن پاسخ را مینویسد.
قبل از استفاده واقعی، Jev را چطور آزمایش کنیم؟
محدودبودن جوابها جلوی خروجی بههمریخته را میگیرد، اما مانع تصمیم اشتباه نمیشود. TypeSafe در فهرست محدودیتها نوشته که Jev در شمارش، محاسبه، مقایسه تاریخ و روبهروشدن با دستورهای متناقض ضعف دارد. این کارها را بهتر است با کد انجام دهید.
پیام کاربر را داده در نظر بگیرید، نه دستور تغییر مجوزهای برنامه. اطلاعات حساس غیرضروری را هم برای مدل نفرستید. ما کیفیت Jev در زبان فارسی را آزمایش نکردهایم؛ پیامهای محاورهای، غلطهای تایپی، جملههای منفی و پیامهایی که چند خواسته را با هم مطرح میکنند، همگی به آزمون جداگانه نیاز دارند.
| معیار | پرسش عملی |
|---|---|
| نوع خطا | مدل کجا اشتباه کرده و پیامد آن چیست؟ |
| سهم کار خودکار | چند درصد موارد بدون دخالت انسان جلو میروند؟ |
| میزان اطمینان | آیا جوابهای ظاهراً مطمئن واقعاً بیشتر درستاند؟ |
| زمان کل | از رسیدن درخواست تا نتیجه قابلاستفاده چقدر طول میکشد؟ |
| هزینه کل | مدل، زیرساخت، بازبینی انسانی و اصلاح خطا چقدر خرج دارند؟ |
کار را با تصمیمی کوچک و قابلبازگشت شروع کنید. در مرحله اول Jev فقط پیشنهاد بدهد و کارشناسان جواب درست را ثبت کنند. وقتی الگوی خطاها روشن شد، میتوان موارد کمریسک را خودکار کرد. تصمیم مالی یا غیرقابلبازگشت هنوز به کنترل جداگانه یا تأیید انسان نیاز دارد.
مدل نظر میدهد، اما برنامه کاری انجام نمیدهد.
کارشناس پیشنهاد مدل را میبیند و تأیید یا اصلاحش میکند.
فقط کارهای کمریسک و قابلبازگشت خودکار میشوند.
Agent Skill رسمی راهنمای دستیار کدنویسی برای ساخت این اتصال است؛ نه خود Jev است و نه جای دسترسی API را میگیرد. وزنهای مدل هم منتشر نشدهاند.
خلاصه ماجرا: Jev تصمیم میگیرد، نرمافزار عمل میکند
Jev برای موقعیتی مناسب است که نرمافزار باید منظور یک ورودی را بفهمد، اما جوابهای ممکن از قبل مشخصاند. مدل یکی از آن جوابها را همراه با میزان اطمینان پیشنهاد میدهد و ادامه کار را به برنامه میسپارد. قانونها، اطلاعات قطعی، مجوزها و اجرای نهایی همچنان باید دست نرمافزار خودتان بمانند.
چه زمانی ارزش امتحانکردن دارد؟ وقتی تصمیمی تکراری با چند جواب مشخص دارید، اما نمیشود برای تمام شکلهای بیان آن قانون نوشت. اگر جوابها باز و نامحدودند یا یک شرط ساده مسئله را حل میکند، ابزار دیگری مناسبتر است.
در نهایت، یک آزمایش کوچک بیشتر از هر توضیحی جواب میدهد. دادههای خودتان، هزینه هر اشتباه و مقدار دخالت انسان نشان میدهد این لایه واقعاً مفید است یا فقط سرویس دیگری به معماری اضافه میکند.
پرسشهای کوتاه پیش از امتحانکردن Jev
آیا Jev جای LLM را میگیرد؟
معمولاً نه. Jev بین چند جواب مشخص تصمیم میگیرد؛ LLM مولد برای نوشتن یا حل مسئلههای باز مناسبتر است. این دو میتوانند کنار هم کار کنند.
آیا اطمینان بالا برای خودکارکردن پرداخت کافی است؟
نه. عدد اطمینان جای بررسی مالکیت، مجوز و قوانین مالی را نمیگیرد. هر اقدام حساس باید کنترل جداگانه داشته باشد.
آیا Agent Skill همان Jev است؟
نه. Skill فقط راهنمای ساخت اتصال است. برای استفاده واقعی از Jev همچنان به دسترسی سرویس و پیادهسازی در نرمافزار نیاز دارید.
