TYPESAFE AI: مدل‌های تصمیم‌گیری Jev
شرکت TYPESAFE AI مدل‌هایی برای داوری‌های مشخص می‌سازد که نرم‌افزار بتواند نتیجه آن‌ها را به‌صورت مقادیر نوع‌دار دریافت کند. مدل پرچم‌دار این شرکت، Jev، اطلاعات ورودی را بر اساس پرسش‌های صریح ارزیابی می‌کند و گزینه، امتیاز یا احتمال پاسخ بله را برمی‌گرداند. برنامه شما این پاسخ‌ها را با قواعد خود ترکیب می‌کند تا کارها را مسیریابی، رتبه‌بندی یا برای بررسی علامت‌گذاری کند.
AvalAI دسترسی را از طریق /v1/decisions با قالب تصمیم‌گیری OpenAI و /v1/systemone با قالب بومی TYPESAFE AI فراهم می‌کند. هر دو مسیر در آزمون زنده مثال‌های اصلی متنی نوع‌دار در ۱ آبان ۱۴۰۵ (2026-10-23)، برای هر دو نام مستعار Jev پاسخ موفق دادند. از کلید API خود در AvalAI و نشانی https://api.avalai.ir استفاده کنید؛ برای این درخواست‌ها نیازی به کلید جداگانه TYPESAFE AI ندارید. پیش از کپی‌کردن مثال، نقطه پایانی را انتخاب کنید، زیرا ساختار درخواست و پاسخ این دو مسیر متفاوت است.
مدل‌های در دسترس
جدول زیر نگاشت نام‌های مستعار در AvalAI در ۱ آبان ۱۴۰۵ (2026-10-23) را نشان می‌دهد. نام مستعار را در فیلد model قرار دهید:
| نام مستعار مدل در AvalAI | نسخه زیرساختی | نقاط پایانی AvalAI | کاربرد |
|---|---|---|---|
jev-preview | jev-1.13.0 | /v1/decisions، /v1/systemone | داوری نوع‌دار درباره متن و داده‌های متنی ساختاریافته |
jev-latest | jev-1.14.0 | /v1/decisions، /v1/systemone | داوری نوع‌دار با نسخه جدیدتر Jev در AvalAI |
این نگاشت‌ها مختص AvalAI هستند. ارائه‌دهنده اصلی ممکن است نام‌های مستعار خود را به نسخه‌های دیگری متصل کند. نسخه‌های زیرساختی، مدل پشت هر نام مستعار را مشخص می‌کنند؛ این جدول تأیید نمی‌کند که بتوان آن رشته‌های نسخه را مستقیماً به‌عنوان شناسه مدل در درخواست AvalAI فرستاد. برای این انتشار از دو نام مستعار مستندشده استفاده کنید.
نام مستعار می‌تواند بدون تغییر کد کلاینت به نسخه دیگری منتقل شود. نام انتخابی، تعریف پرسش‌ها، معیارهای امتیازدهی، آستانه‌های تصمیم و اطلاعات مدل در پاسخ، در صورت وجود، را در سوابق ارزیابی نگه دارید. پیش از تغییر نام مستعار یا اتکا به نگاشت تازه، آزمون‌های نماینده را دوباره اجرا کنید. مثال ارزیابی گردش‌کار روشی عملی برای این مقایسه ارائه می‌دهد.
جستجو و مقایسه مدل‌ها و جدول‌های تولیدشده قیمت ممکن است با تأخیر مسیر تازه‌فعال‌شده را نشان دهند. این صفحه نام‌های مستعار Jev را که اعلام شده‌اند ثبت می‌کند؛ برای بررسی رفتار زنده حساب خود از مثال‌های مرجع هر نقطه پایانی استفاده کنید.
قیمت‌گذاری
نرخ هر دو نام مستعار در AvalAI یکسان است. قیمت‌ها به دلار آمریکا برای هر یک میلیون توکن هستند:
| مدل | ورودی | ورودی از حافظه نهان | خروجی |
|---|---|---|---|
jev-preview | $0.042 | $0.00 | $0.00 |
jev-latest | $0.042 | $0.00 | $0.00 |
صفر بودن قیمت خروجی یعنی برای توکن‌های خروجی مقادیر تصمیم هزینه‌ای دریافت نمی‌شود؛ خود درخواست رایگان نیست. برای مثال، ۱۰۰٬۰۰۰ توکن ورودی قابل‌صورتحساب بدون حافظه نهان، ۰٫۰۰۴۲ دلار و یک میلیون توکن، ۰٫۰۴۲ دلار هزینه دارد. ورودی واقعی گزارش‌شده برای درخواست، از جمله داده‌ها و متن پرسش‌هایی که سرویس در صورتحساب محاسبه می‌کند، را مبنا قرار دهید؛ تعداد نویسه‌ها جایگزین شمارش توکن نیست.
نرخ ورودی از حافظه نهان فقط به ورودی‌ای تعلق می‌گیرد که واقعاً در محاسبه هزینه به‌عنوان ورودی از حافظه نهان ثبت شود. قیمت صفر، بازیابی موفق از حافظه نهان را تضمین نمی‌کند، طول عمر آن را تعیین نمی‌کند و پشتیبانی از پارامتر کنترل حافظه نهان OpenAI یا قالب بومی را ثابت نمی‌کند. برای صورتحساب و تطبیق درخواست‌ها، قیمت‌گذاری، هدرهای پاسخ و API کاربر را ببینید.
مدل تصمیم‌گیری چه می‌کند؟
گردش‌کار تصمیم‌گیری سه بخش دارد:
- شواهد: متن یا داده‌های متنی ساختاریافته برای ارزیابی؛ مانند پیام پشتیبانی، توضیح محصول یا بخشی از سند که متن آن استخراج شده است.
- پرسش‌ها: داوری‌های محدود با گزینه‌ها، شرط‌ها یا سطح‌های مرتب و صریح برای امتیازدهی.
- سیاست برنامه: کدی که نتیجه‌ها را اعتبارسنجی می‌کند و تصمیم می‌گیرد با آن‌ها چه کاری انجام دهد.
برای مثال، برنامه پشتیبانی می‌تواند بپرسد تیکت مربوط به کدام بخش است، آیا مشتری بازپرداخت خواسته و لحن پیام چقدر فوری است. سپس کد برنامه صف مناسب را انتخاب می‌کند و موارد نیازمند بررسی را علامت می‌زند. تشخیص درخواست بازپرداخت، مجوز انجام آن نیست؛ این اقدام همچنان به بررسی حساب، سیاست کسب‌وکار و فرایند تأیید برنامه وابسته است.
Jev برای چنین داوری‌های محدود طراحی شده است، نه تولید پاسخ آزاد یا استدلال طولانی و چندمرحله‌ای. اگر وظیفه به تحقیق، بازیابی اطلاعات گمشده، نوشتن توضیح بلند یا برنامه‌ریزی مجموعه‌ای از اقدام‌ها نیاز دارد، آن بخش را به مدل مناسب تولید متن یا استدلال بسپارید. در یک گردش‌کار ترکیبی، مدل متنی شواهد مرتبط را آماده یا بازیابی می‌کند، Jev جنبه‌های مشخص را ارزیابی می‌کند و کد برنامه قواعد نهایی را اعمال می‌کند.
اجزای پایه تصمیم‌گیری در قالب بومی
در API بومی System One، نام شواهد state و نام داوری‌ها questions است. هر پرسش یک شناسه، type و instructions دارد؛ در موارد لازم، criteria گزینه‌ها یا سطح‌های امتیاز را تعریف می‌کند. پاسخ، نتیجه نوع‌دار هر پرسش را به شناسه آن متصل می‌کند. برای ساختار دقیق درخواست و پاسخ، مرجع API بومی System One را ببینید.
| جزء پایه | کاربرد | تفسیر پاسخ بومی |
|---|---|---|
Choice (choice) | انتخاب یک گزینه از مجموعه‌ای بدون ترتیب؛ مانند billing، technical یا other | choice گزینه انتخاب‌شده را مشخص می‌کند. probabilities احتمال گزینه‌ها را نشان می‌دهد و confidence خلاصه‌ای از توزیع آن‌هاست. |
Score (score) | تعیین موقعیت روی سطح‌های مرتب و توصیف‌شده؛ مانند شدت مشکل تیکت | score می‌تواند بین دو سطح قرار بگیرد. legend سطح‌ها را مشخص می‌کند؛ probabilities و confidence به تفسیر نتیجه کمک می‌کنند. |
Noul (noul) | ارزیابی یک شرط روشن بله/خیر؛ مانند اینکه آیا پیام صریحاً درخواست لغو دارد | noul مقداری بین ۰ و ۱ است که احتمال پاسخ بله از دید مدل را نشان می‌دهد. فیلد جداگانه confidence ندارد. |
وقتی برچسب‌ها ترتیب معناداری ندارند، Choice را انتخاب کنید. وقتی می‌توانید معنای هر سطح را تعریف کنید، Score مناسب است. وقتی خود شرط دوحالتی است، از Noul استفاده کنید. مقدار Noul نزدیک ۰٫۵ یعنی مدل درباره بله یا خیر مردد است؛ به معنی میزان متوسط فوریت، کیفیت یا مهارت نیست. برای چنین طیف‌هایی از Score استفاده کنید.
شناسه پرسش بومی برای کد شماست و جای دستور پرسش را نمی‌گیرد. داوری کامل را در instructions بنویسید، حتی اگر شناسه روشن به نظر برسد. اگر گزینه‌های Choice تمام ورودی‌های محتمل را پوشش نمی‌دهند، other یا گزینه مناسبی برای حالت نامشخص اضافه کنید.
انتخاب نقطه پایانی AvalAI
| نقطه پایانی | هدف و دامنه بررسی | مرجع پیاده‌سازی |
|---|---|---|
/v1/decisions | قالب تصمیم‌گیری OpenAI؛ بدنه‌های متنی مستندشده Choice، Predicate و Score برای هر دو نام مستعار HTTP 200 برگرداندند | API تصمیم‌ها |
/v1/systemone | state، questions و پاسخ اجزای نوع‌دار بومی TYPESAFE AI؛ بدنه‌های متنی مستندشده Choice، Noul و Score برای هر دو نام مستعار HTTP 200 برگرداندند | API بومی System One |
هدف مدل در دو مسیر مشابه است، اما سازگاری قالب به قرارداد همان نقطه پایانی بستگی دارد. state و questions بومی را به مسیر Decisions نفرستید و ساختار کلی پاسخ‌های دو مسیر را یکسان فرض نکنید. فعال‌بودن این نقاط پایانی Jev نیز پشتیبانی از Chat Completions، Messages، Responses، پاسخ جریانی، ابزارها، ورودی چندوجهی یا مکالمه ذخیره‌شده را ثابت نمی‌کند.
در ۱ آبان ۱۴۰۵ (2026-10-23)، هر ۱۶ بررسی زنده با داده ساختگی پاسخ HTTP 200 و نتیجه‌های نوع‌دار معتبر دریافت کرد. این بررسی‌ها هر دو نام مستعار، هر دو نقطه پایانی، نوع‌های اصلی پرسش و بدنه‌های مثال پشتیبانی، بازیابی، کنترل حفاظتی، امتیاز وزنی و انتخاب تابع را پوشش دادند. نتیجه، این بدنه‌های درخواست متنی و ساختار پاسخ آن‌ها را تأیید می‌کند؛ پشتیبانی تصویر، رفتار در مرز محدودیت زمینه یا اجرای مثال همه زبان‌های SDK را ثابت نمی‌کند. مرجع هر نقطه پایانی پاسخ‌های ثبت‌شده و دامنه تأییدشده را توضیح می‌دهد.
برای درخواست نخست، راهنمای مدل‌های تصمیم‌گیری را دنبال کنید و سپس مثال کوچک با داده ساختگی مرجع همان نقطه پایانی را در api.avalai.ir اجرا کنید. پیش از تغییر روش دسترسی به فیلدها، پاسخ کامل را بررسی کنید. مثال کاربردی Jev این مسیر را به گردش‌کاری عملی همراه با اعتبارسنجی، بررسی انسانی و مدیریت خطا گسترش می‌دهد.
احتمال، اطمینان و بررسی
شرکت TYPESAFE AI برای پاسخ‌های بومی Choice و Score، مقدار confidence را از شکل توزیع احتمال بازگشتی محاسبه می‌کند. توزیع متمرکزتر اطمینان بیشتری دارد؛ توزیع یکنواخت یا پراکنده‌تر اطمینان کمتری نشان می‌دهد. فرمول Choice و Score متفاوت است، زیرا سطح‌های Score ترتیب دارند.
اطمینان، احتمال اندازه‌گیری‌شده درست‌بودن پاسخ نیست. پاسخ با اطمینان زیاد هم ممکن است نادرست باشد؛ به‌ویژه وقتی شواهد کافی نیست، پرسش مبهم است یا ورودی با داده‌های ارزیابی گردش‌کار تفاوت دارد. احتمال و اطمینان را نشانه‌های مدل بدانید و سپس با نمونه‌های برچسب‌خورده خود بررسی کنید که آیا نتیجه‌های مفید را پیش‌بینی می‌کنند.
پیش از فرض کامل‌بودن نگاشت احتمال، پاسخ AvalAI را بررسی کنید. در پاسخ‌های بومی ثبت‌شده Choice برای پشتیبانی، برچسب انتخاب‌شده billing در probabilities وجود نداشت، در حالی که confidence: 1.0 بازگشته بود؛ سایر موارد آزمایش‌شده Choice بومی، برچسب انتخاب‌شده خود را داشتند. نبودن گزینه را احتمال صفر تعبیر نکنید و از نگاشت ناقص، اطمینان را دوباره محاسبه نکنید. پیش از انتخاب فیلدهای موردنیاز برنامه، پاسخ بومی ثبت‌شده و راهنمای اعتبارسنجی را ببینید.
آستانه‌ها را برای هر پرسش و هر اقدام جداگانه تعیین کنید. با ورودی‌های نماینده درست، نادرست، مبهم و خارج از دامنه، میزان تشخیص مثبت اشتباه، تشخیص منفی اشتباه و سهم موارد ارسالی برای بررسی را بسنجید. فقط به این دلیل که دو مقدار در بازه صفر تا یک هستند، آستانه وظیفه‌ای دیگر را کپی نکنید. برای Noul، یک بازه بله، یک بازه خیر و یک بازه میانی تعریف کنید که به دریافت اطلاعات بیشتر یا بررسی انسانی منجر شود.
اقدام‌های اثرگذار باید همچنان به مجوز و اعتبارسنجی برنامه وابسته باشند. اطمینان می‌تواند در انتخاب تیکتی که زودتر به بررسی‌کننده نشان داده می‌شود کمک کند؛ جای سیاست بازپرداخت، تأیید پرداخت، بررسی دسترسی یا راستی‌آزمایی ادعای واقعی را نمی‌گیرد.
بهترین شیوه‌های پیاده‌سازی
- در هر پرسش یک داوری بخواهید. فوریت، دسته‌بندی و انطباق با سیاست را جدا کنید. پاسخ‌ها را با کد صریح ترکیب کنید، نه با پرسشی که هر سه را هم‌زمان سبک‌سنگین می‌کند.
- معیار مشاهده‌پذیر تعریف کنید. ارزیابی «آیا پیام ورودی صریحاً بازپرداخت می‌خواهد؟» آسان‌تر از «آیا مشتری ناراضی است؟» است. برای Score، هر سطح باید توصیف روشن داشته باشد.
- شواهد مرتبط ارائه دهید. شناسه رکوردها و مرز فیلدها را در داده ساختاریافته حفظ کنید. مشخص کنید پرسش درباره کدام فیلد است و از مدل نخواهید اطلاعات غایب را حدس بزند.
- پرسش‌های مستقل درباره شواهد یکسان را کنار هم بفرستید. System One بومی آن‌ها را بر اساس همان
stateارزیابی می‌کند. اگر پرسش بعدی برای بازیابی شواهد تازه یا ساخت گزینه‌های خود به پاسخ قبلی نیاز دارد، این وابستگی را با درخواست بعدی صریح کنید. - نتیجه‌های نوع‌دار را در کد برنامه اعتبارسنجی کنید. شناسه پاسخ، برچسب مجاز، بازه عددی مورد انتظار و متناهی‌بودن عددها را بررسی کنید. پاسخ ساختاریافته نیاز به استخراج مقدار از نثر را کم می‌کند، اما اعتبارسنجی قالب و سیاست را حذف نمی‌کند.
- انگلیسی و فارسی را جداگانه ارزیابی کنید. TYPESAFE AI انگلیسی را زبان اصلی آموزش Jev معرفی می‌کند. پیش از تعیین آستانه بررسی، عبارت‌های واقعی فارسی، شناسه‌های ترکیبی فارسی و لاتین، ابهام و واژگان تخصصی دامنه را آزمایش کنید.
- مسیر بررسی و بازگشت (fallback) داشته باشید. شواهد ناقص، برچسب ناشناخته، اطمینان کم یا پاسخ نامعتبر باید نتیجه‌ای ازپیش‌تعیین‌شده داشته باشد؛ نباید بی‌صدا به اقدام پیش‌فرض منجر شود.
متن و محدودیت زمینه
شرکت TYPESAFE AI برای Jev 1.13 و 1.14 ورودی متنی را مستند کرده است؛ از جمله رشته، شیء JSON و آرایه‌های شامل متن. پیش از ارزیابی با Jev، محتوای صوت، ویدیو یا سند اسکن‌شده را با سرویسی جداگانه به شواهد متنی مناسب تبدیل کنید.
سقف پیش‌فرض ارائه‌دهنده اصلی ۶۴ هزار توکن برای هر درخواست (state و همه پرسش‌ها) و ۳۲ هزار توکن برای هر پرسش (state و یک پرسش) است. این‌ها دو محدودیت‌اند، نه دو ظرفیت که با هم جمع شوند. ارائه‌دهنده اصلی همچنین هدری اختیاری برای زمینه طولانی معرفی کرده است، اما انتقال و رفتار آن از طریق AvalAI در این اعلام انتشار تأیید نشده است. بدون بررسی سازگاری جداگانه، به آن هدر یا سقف بزرگ‌تر اتکا نکنید. درخواست‌ها را کوچک و مرتبط نگه دارید و خطاهای زمینه را با راهنمای عیب‌یابی مدیریت کنید.
کاربردهای عملی
| گردش‌کار | پرسش‌های مشخص | اقدام بعدی کد برنامه |
|---|---|---|
| دسته‌بندی تیکت پشتیبانی | بخش مربوط، فوریت، درخواست صریح بازپرداخت | تیکت را مسیریابی می‌کند و موارد نیازمند بررسی انسانی را برجسته می‌کند |
| بازخورد محصول | دسته قابلیت، جزئیات قابل‌اقدام، شدت مشکل | رکوردها را گروه‌بندی می‌کند و شناسه منابع را برای بررسی نگه می‌دارد |
| طبقه‌بندی سند | نوع سند، وجود بخش ضروری | مسیر پردازش را انتخاب می‌کند یا اطلاعات گمشده را می‌خواهد |
| جستجو و بازیابی | آیا هر گزینه نیاز تعریف‌شده را پاسخ می‌دهد؟ | گزینه‌ها را برای تولید پاسخ متکی به شواهد رتبه‌بندی می‌کند |
| مسیریابی عامل | کدام ابزار یا گردش‌کار مجاز با درخواست سازگار است؟ | مجوزها را بررسی و مسیر مجاز را اجرا می‌کند |
| بررسی محتوا | آیا محتوای ورودی با معیار صریح مطابقت دارد؟ | محتوا را برای بررسی علامت می‌زند، بدون اینکه علامت را مدرک قطعی بداند |
این‌ها الگوهای پیاده‌سازی‌اند، نه تضمین دقت. با نمونه برچسب‌خورده‌ای از گردش‌کار موردنظر شروع کنید، آن را با قواعد یا مدل‌های موجود مقایسه کنید و نمونه خطاهایی را نگه دارید که مسیر بررسی باید شناسایی کند.
خطاها و عیب‌یابی
برای فیلدهای درخواست و مدیریت خطا، ابتدا مرجع نقطه پایانی و راهنمای مدل‌های تصمیم‌گیری را ببینید. بررسی‌های اولیه معمولاً شامل نقطه پایانی انتخابی، نام مستعار، ساختار JSON، نوع پرسش، ساختار معیارها و اندازه شواهد است.
در مسیر Decisions با قالب OpenAI، گزینه‌های نام‌دار را در choices تعریف کنید، نه options. در System One بومی، برای جزء پایه انتخاب‌شده از ساختار مستندشده criteria استفاده کنید. شباهت مفاهیم، ساختار درخواست این دو مسیر را قابل‌جایگزینی نمی‌کند.
کلید را فقط در سرور و در AVALAI_API_KEY نگه دارید. وضعیت HTTP، نقطه پایانی، نام مستعار انتخابی، زمان پاسخ، تعداد تلاش مجدد و avalai-request-id بازگشتی، در صورت وجود، را ثبت کنید. بدنه خطا را پس از حذف اطلاعات حساس نگه دارید تا خطای احراز هویت، مجوز، قالب، زمینه، محدودیت نرخ و اختلال سرویس را از هم تشخیص دهید. کلید یا شواهد خام غیرضروری را ثبت نکنید.
پیش از تلاش مجدد، درخواست نامعتبر را اصلاح کنید. برای خطاهای گذرای محدودیت نرخ یا سرویس، تعداد تلاش را محدود کنید، فاصله انتظار را افزایش دهید و در صورت وجود Retry-After، آن را رعایت کنید؛ مدیریت خطا را ببینید. پایان مهلت درخواست ثابت نمی‌کند که سرویس آن را پردازش نکرده است؛ از تلاش نامحدود خودداری کنید و درخواست تصمیم را از هر اقدام بعدی جدا نگه دارید.
مستندات مرتبط
- مفاهیم مدل تصمیم‌گیری، بهترین شیوه‌ها و عیب‌یابی
- مرجع API تصمیم‌ها
- مرجع API بومی System One
- مثال گردش‌کارهای تصمیم‌گیری با Jev
- ارزیابی گردش‌کار پیش از تغییر مدل
منابع رسمی TYPESAFE AI
منابع زیر مفاهیم و رفتار ارائه‌دهنده اصلی را توضیح می‌دهند. نگاشت نام‌های مستعار، قیمت‌ها و نقاط پایانی فعال در بخش‌های بالا، یکپارچه‌سازی اعلام‌شده AvalAI را توصیف می‌کنند.