مقایسه فنی مدل‌های تصمیم‌گیری Jev، Microsoft-Decision-1، Decider V1.1 27B، GPT-6 Luna Decisions و Laya

این پنج گزینه، با وجود شباهت در کاربرد آنها ، از نظر نوع معماری، اندازه پنجرهٔ زمینه، نحوه استقرار محلی و شیوهٔ ارائهٔ سرویس یکسان نیستند. در میان آن‌ها، دو گزینهٔ قابل اجرای محلی و لوکال ، Laya و Perplexity Decider V1.1 27B هستند (مدل های وزن باز هستند) ؛ که اولی خانواده‌ای از مدل‌های چندصد میلیون‌پارامتری است و دومی برای وزن‌ها به‌تنهایی حدود ۴۹ گیگابایت حافظهٔ GPU نیاز دارد. Jev و Microsoft-Decision-1 و GPT-6 Luna Decisions به‌صورت API میزبانی‌شده عرضه می‌شوند.

نکتهٔ محوری این مقایسه، کالیبراسیون است: برای سیستم تصمیم‌گیری، فقط درست بودن گزینهٔ منتخب مهم نیست و باید احتمال اعلام شده نیز روی داده‌های واقعی قابل اعتماد باشد. مدل دارای دقت بالاتر، الزاماً بهترین مدل برای تصمیم‌گیری خودکار با آستانهٔ اطمینان نیست. مستندات این سرویس‌ها نیز بر ارزیابی احتمال‌ها و تنظیم آستانه با دادهٔ کاربرد نهایی تأکید می‌کنند.

تاریخ بررسی: ۱۵ اکتبر ۲۰۲۶. قیمت‌ها، محدودیت‌ها و وضعیت نسخه‌ها مربوط به منابع بررسی‌شده در این تاریخ‌اند. این مقاله مرور فنی مستندات و نتایج منتشرشده است، نه گزارش بنچمارکی که شخصاً روی هر پنج مدل اجرا کرده باشم. اعداد ارایه شده نتایج خوداظهاری سازندگان و محدودیت‌های مستندات هستند که در بخش‌های مربوط از یکدیگر تفکیک شده‌اند.

۱. مدل تصمیم‌گیری چیست و چه تفاوتی با چت‌بات دارد؟

در یک مدل مولد عمومی، معمولاً از مدل می‌خواهیم پاسخی متنی تولید کند؛ حتی اگر خروجی JSON باشد، مدل ممکن است مقادیر یا توضیحات آن را تولید کند. در مدل های تصمیم‌گیری، فضای پاسخ را پیشاپیش محدود می‌کنیم: مدل باید دربارهٔ یک شرط احتمال بدهد، یکی از گزینه‌های مشخص را انتخاب کند یا ورودی را روی یک مقیاس مرتب امتیازدهی کند. خروجی برای مصرف مستقیم در کد طراحی شده، نه لزوماً نمایش به کاربر.

برای مثال، به‌جای درخواست زیر:

«این پیام مشتری را بخوان و توضیح بده به کدام واحد مربوط است.»

می‌توان سؤال را چنین تعریف کرد:

«با توجه به تعریف واحدهای مالی، فنی و حساب کاربری، احتمال تعلق این پیام به هر واحد چقدر است؟»

خروجی فرضی:

json{
  "choice": "billing",
  "probabilities": {
    "billing": 0.93,
    "technical": 0.04,
    "account": 0.03
  }
}

این نمونه، نتیجهٔ واقعی هیچ‌یک از مدل‌ها نیست؛ صرفاً شکل مسئله را نشان می‌دهد. چنین خروجی‌ای اجازه می‌دهد برنامه بر اساس آستانه، درخواست را مسیریابی کند یا به بررسی انسانی بفرستد. همین الگو در مستندات Microsoft و OpenAI برای طبقه‌بندی و ارجاع درخواست‌ها استفاده شده است.

تمایز مهم این است که «خروجی ساختاریافته و محدود» به معنی «تصمیم بدون خطا» نیست. مدل ممکن است قالب کاملاً معتبری برگرداند، اما گزینهٔ نامناسب را با اطمینان بالا انتخاب کند؛ محدودیت‌های منتشرشدهٔ Laya و Microsoft صراحتاً به چنین مسائل اطمینان و قابلیت اعتماد اشاره دارند.

۲. مقایسهٔ سریع مشخصات

در جدول زیر، قیمت‌ها به دلار آمریکا برای یک میلیون توکن ورودی‌اند. برای سرویس‌های میزبانی‌شده، هزینهٔ توکن خروجی در مسیر تصمیم‌گیری صفر اعلام شده است؛ این به معنی رایگان بودن کل سرویس نیست.

ویژگی	Jev	Microsoft-Decision-1	Perplexity Decider V1.1 27B	GPT-6 Luna Decisions	Laya
ماهیت عرضه	API مدل تصمیم‌گیری	API مدل تصمیم‌گیری	API و قابل اجرای محلی	سرویس Decisions روی GPT-6 Luna و API مدل تصمیم‌گیری	خانوادهٔ قابل اجرای محلی
معماری یا پایهٔ منتشرشده	جزئیات کامل در منابع بررسی‌شده مشخص نیست	پس‌آموزش Qwen3.5-9B	پایهٔ Qwen3.8-27B با readout تصمیم و توجه غیرعلّی در لایه‌های مشخص	معماری داخلی مسیر Decisions در راهنما تشریح نشده	ModernBERT-large یا mmBERT-base با سر تصمیم
اندازه	در منابع بررسی‌شده مشخص نیست	پایهٔ 9B	نام تجاری 27B؛ وزن‌ها حدود ۴۹ GiB	اعلام‌نشده در راهنمای بررسی‌شده	421M یا 322M
اجرای محلی	وزن‌ها توزیع نشده‌اند	وزن‌ها توزیع نشده‌اند	بله؛ با محدودیت دسترسی و اجرای اختصاصی	وزن‌ها توزیع نشده‌اند	بله
مجوز وزن محلی	—	—	Apache 2.0 در کارت مدل	—	Apache 2.0
ورودی	متن و ساختارهای متنی	متن و JSON	متن و تصویر در V1.1 نسخه ۱.۲ نیز در حال انتشار میباشد	متن و تصویر	متن و JSON
قیمت ورودی API	۰٫۰۴۲ دلار	۰٫۰۴۲ دلار	۰٫۰۲ دلار در OpenRouter	پایهٔ ۰٫۱۰ دلار	هزینهٔ API الزامی ندارد؛ زیرساخت بر عهدهٔ شماست
مرجع	https://docs.typesafe.ai/models	https://commandline.microsoft.com/microsoft-decision-1-model-foundry/	https://openrouter.ai/perplexity/pplx-decider-v1.1-27b	https://developers.openai.com/api/docs/guides/decisions	https://github.com/he-jev/laya

دو احتیاط در خواندن جدول:

• وزن باز بودن مدل پایه، به معنی باز بودن مدل نهایی نیست. Microsoft-Decision-1 از Qwen استفاده می‌کند، اما وزن‌های پس‌آموزش‌دیدهٔ خود آن توزیع نشده‌اند.
• «قابل اجرای محلی» با «قابل اجرا روی هر لپ‌تاپ» تفاوت دارد. نیاز سخت‌افزاری Decider و Laya در دو مقیاس بسیار متفاوت قرار دارد.

۳. پنجرهٔ زمینه: عدد بزرگ‌تر همیشه مقایسهٔ درست‌تری نیست

جدول محدودیت‌ها

مدل یا مسیر اجرا	محدودیت مستند	نکتهٔ فنی
Jev، حالت پیش‌فرض	64k برای کل درخواست؛ 32k برای state به‌علاوهٔ هر سؤال	مجموع درخواست و بودجهٔ هر سؤال دو محدودیت جداگانه‌اند.
Jev، حالت Long Context	262k برای هر دو محدودیت	نیازمند هدر مخصوص؛ سازنده کاهش سرعت و دقت را نسبت به حالت پیش‌فرض گوشزد کرده است.
Microsoft-Decision-1 در OpenRouter	32,768 توکن	عدد اعلام‌شدهٔ مسیر میزبانی‌شده است.
Decider V1.1 در OpenRouter	262,144 توکن	نباید خودکار به اجرای محلی تعمیم داده شود.
Decider V1.1، کد محلی منتشرشده	8,192 توکن در مرحلهٔ prepareبرای متن و تصاویر هر تصمیم	ورودی بزرگ‌تر رد می‌شود، نه اینکه بی‌صدا بریده شود.
GPT-6 Luna Decisions در OpenRouter	1,050,000 توکن	راهنمای رسمی وجود ضریب قیمت برای ورودی بلند را نیز اعلام می‌کند.
Laya انگلیسی	512 توکن برای هر سؤال	سؤال، گزینه‌ها و state در همین بودجه قرار می‌گیرند.
Laya چندزبانه و typed-decisions	1,024 توکن در جدول چک‌پوینت‌ها	برای این خانواده، انتخاب نسخه مستقیماً بر ظرفیت ورودی اثر دارد.

چرا تفاوت API و اجرای محلی Decider مهم است؟

در صفحهٔ سرویس OpenRouter برای Decider V1.1، پنجرهٔ 262,144 توکنی آمده است، اما کارت مدل محلی می‌گوید پیاده‌سازی منتشرشده در مرحلهٔ آماده‌سازی هر تصمیم، سقف 8,192 توکن دارد. بنابراین عبارت «این مدل 262k کانتکست دارد» بدون مشخص کردن مسیر اجرا، برای راهنمای نصب محلی گمراه‌کننده است.

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

چرا محدودیت Jev با یک عدد بیان نمی‌شود؟

Jev، وضعیت state مشترک را دریافت می‌کند و سؤال‌ها را در برابر آن ارزیابی می‌کند. دو شرط باید هم‌زمان برقرار باشند:

$$T_{\text{state}}+\sum _j{T}_{{\text{question}}_j}\le T_{\text{request limit}}$$Tstate​+∑^j​Tquestion^j​​≤Trequest limit​

$$T_{\text{state}}+T_{{\text{question}}_j}\le T_{\text{per-question limit}}$$Tstate​+Tquestion^j​​≤Tper-question limit​

به همین دلیل، وجود بودجهٔ 64k برای درخواست به معنی امکان فرستادن یک state تقریباً 64k در حالت پیش‌فرض نیست. مستندات Jev این تفکیک را صریحاً بیان کرده‌اند.

۴. دسته‌بندی خروجی‌ها و متغیرهای تصمیم‌ساز

۴.۱. سه نوع خروجی اصلی

نوع تصمیم	ماهیت متغیر	خروجی	کاربرد نمونه
دودویی	درست/نادرست	احتمال برقرار بودن شرط	آیا پیام درخواست لغو اشتراک دارد؟
دسته‌ای اسمی	چند دستهٔ بدون ترتیب	گزینهٔ منتخب و توزیع احتمال	مالی، فنی یا حساب کاربری؟
ترتیبی	سطح‌های مرتب	توزیع احتمال سطح‌ها و امتیاز مورد انتظار	کم، متوسط، زیاد، بحرانی

این سه خانواده در مستندات مدل‌های بررسی‌شده دیده می‌شوند؛ نام تصمیم دودویی در رابط‌های Jevمانند noulاست، ولی در API مستقیم OpenAI، predicate نام دارد.

تصمیم دودویی

$$p=P(Y=\text{true}\mid x,q)$$

مثلاً «آیا مشتری صراحتاً تهدید به لغو کرده است؟» با «آیا احتمال می‌دهیم مشتری در آینده لغو کند؟» یک سؤال نیست. اولی تشخیص شواهد موجود است؛ دومی پیش‌بینی آینده. توصیهٔ طراحی این مقاله آن است که این دو را در نام متغیر، برچسب داده و ارزیابی جدا نگه دارید؛ مستندات OpenAI نیز توصیه می‌کند سؤال‌ها بر معیارهای مشاهده‌پذیر متمرکز باشند.

انتخاب دسته‌ای

برای گزینه‌های متقابلاً انحصاری:

$$\sum _{k=1}^K{p}_k=1$$

اما اگر یک پیام هم موضوع مالی داشته باشد و هم مشکل فنی، الزاماً یک choice تک‌برچسبی نمایش مناسبی نیست. می‌توان مسئله را به سؤال‌های دودویی مستقل شکست یا صریحاً از مدل خواست «موضوع اصلی» را انتخاب کند. جداسازی دغدغه‌ها و تعریف روشن گزینه‌ها در راهنمای OpenAI و Microsoft توصیه شده است.

امتیاز ترتیبی

در این APIها، score معمولاً میانگین وزنی اندیس سطح‌هاست:

$$s=\sum _{i=0}^{K-1}i{p}_i$$

مثلاً اگر احتمال سه سطح برابر ۰٫۱ ، ۰٫۷ و ۰٫۲ باشد، امتیاز ۱٫۱ خواهد بود؛ همین مثال در مستندات OpenAI آمده است. این مقدار یک خلاصهٔ عددی از توزیع سطح‌هاست، نه لزوماً اندازه‌گیری فیزیکی شدت یا درصد خسارت.

۴.۲. متغیرهای ورودی را از سیاست اقدام جدا کنیم

برای طراحی سامانه، پیشنهاد می‌کنم متغیرها در شش گروه ثبت شوند:

گروه	نمونه	جای پیشنهادی در سامانه
شواهد خام	پیام، لاگ، عکس کالا	state یا input
ویژگی‌های ساختاریافته	تعداد خطا، مبلغ، زمان، وضعیت سفارش	همراه شواهد، با نام و واحد روشن
تعریف مسئله	منظور از «بحرانی» چیست؟	instructions و تعریف گزینه‌ها
خروجی احتمالاتی	احتمال هر برچسب	پاسخ مدل
هزینه و محدودیت اقدام	سقف بازپرداخت، هزینهٔ اشتباه، ممنوعیت عملیاتی	لایهٔ سیاست برنامه
کنترل ارجاع	حداقل اطمینان، نیاز به تأیید انسان	لایهٔ سیاست و گردش‌کار

این جدول یک الگوی پیشنهادی طراحی است، نه ادعای وجود این شش فیلد در API همهٔ شرکت‌ها. مبنای آن تفکیک شواهد، سؤال و اقدام در مستندات است: مدل قضاوت عددی می‌دهد و برنامه با آستانه و قواعد خود تصمیم می‌گیرد چه اقدامی انجام دهد.

۵. معماری و نحوهٔ عملکرد هر گزینه

۵.۱. Jev: رابط تصمیم‌گیری با تأکید بر احتمال و سؤال‌های مشترک

Jev مدل پرچم‌دار TypeSafe است و از مسیر POST /v1/systemone ارائه می‌شود. مستندات می‌گوید با RLCD، یعنی Reinforcement Learning for Calibrated Decisions، برای پاسخ‌های تصمیم‌گیری آموزش دیده است؛ اما جزئیات کامل معماری و اندازهٔ آن در منابع بررسی‌شده منتشر نشده است.

ویژگی‌های مهم:

• state مشترک و سؤال‌های متعدد در یک درخواست؛
• نبود سقف مستقل تعداد سؤال، مشروط به رعایت بودجه‌های توکن؛
• شخصی‌سازی رفتاری از طریق state، instructions و criteria، نه fine-tuning یا LoRA اختصاصی هر مشتری؛
• آموزش عمدتاً انگلیسی و ضرورت آزمون مستقل برای زبان‌های دیگر.

در زمان بررسی، نسخهٔ 1.14 از ۱۴ اکتبر در دسترس است، اما جدول aliasها هنوز jev-latest را به 1.13 و jev-preview را به 1.14 متصل می‌کند. بنابراین برای بازتولید نتایج وبلاگ یا محصول، شناسهٔ نسخه‌دار مانند jev-1.13.0یا jev-1.14.0 از نام متحرک latest مناسب‌تر است.

۵.۲. Microsoft-Decision-1: پس‌آموزش مدل 9B برای امتیازدهی تک‌گذر

Microsoft اعلام کرده این مدل را با پس‌آموزش Qwen3.5-9B برای تصمیم‌گیری تک‌گذر ساخته است. ورودی، state متنی یا JSON و سؤال‌های محدود است؛ خروجی شامل احتمال، انتخاب یا امتیاز می‌شود و توضیح آزاد متنی تولید نمی‌کند.

دو نکتهٔ معماری و عملیاتی:

1. استفاده از مدل پایهٔ مولد، مانع تبدیل آن به سرویس تصمیم‌گیری محدود نیست؛ مهم، مسیر آموزش و خواندن خروجی نهایی است.
2. استقرار در Foundry و تلفیق و تغییر مدل اولیه وزن باز به معنی اجرای محلی نیست. سرویس از deployment ابری و endpoint اختصاصی استفاده می‌کند و وزن نهایی توزیع نشده است.

مزیت مستند این گزینه برای سازمان‌های دارای زیرساخت Azure، ادغام با Entra ID، نقش‌های دسترسی و deploymentهای DataZoneStandard یا GlobalStandard است. با این حال، خود Microsoft هشدار می‌دهد که نوع deployment به‌تنهایی کاهش تأخیر را تضمین نمی‌کند.

۵.۳. Decider V1.1 27B: چک‌پوینت تصمیم با توجه غیرعلّی و سر خروجی اختصاصی

کارت مدل Decider V1.1 پایه را Qwen3.8-27B معرفی می‌کند. چک‌پوینت شامل backbone و فایل جداگانهٔ readout.safetensors است؛ سر تصمیم یک ماتریس BF16 با ابعاد [255, 5120] دارد و جایگزین یک lm_head کاملِ واژگان است.

جزئیات تعیین‌کننده:

• لایه‌های full-attention در حالت ذخیره‌شدهٔ غیرعلّی اجرا می‌شوند؛
• لایه‌های linear-attention رفتار بومی خود را حفظ می‌کنند؛
• تابع DecisionModel.predict دمای کالیبراسیون ذخیره‌شده را اعمال می‌کند؛
• اجرای causal پیش‌فرض، تنظیم ارزیابی‌شدهٔ این چک‌پوینت را بازتولید نمی‌کند.

در نتیجه، صرف بارگذاری وزن‌ها در یک سرور عمومی چت، بدون حفظ این رفتارها، مبنای معتبری برای مقایسه نیست. کارت مدل صراحتاً استفاده از پیاده‌سازی همراه را برای حفظ رفتار ارزیابی‌شده توصیه می‌کند.

نسخهٔ V1.1 از تصویر نیز پشتیبانی می‌کند و سرویس OpenRouter تا ۱۲۸ سؤال روی محتوای مشترک را معرفی کرده است. این قابلیت را نباید با V1 اشتباه گرفت؛ توضیح مسیر V1 در OpenRouter محدودیت ورودی تصویری داشته است.

۵.۴. GPT-6 Luna Decisions: یک مسیر سرویس متفاوت، نه الزاماً یک مدل مستقل

نام «GPT-6 Luna Decisions» در OpenRouter به GPT-6 Luna از طریق Decisions API اشاره می‌کند. در API مستقیم OpenAI، مدل gpt-6-luna و endpoint برابر POST /v1/decisions است.

رابط مستقیم OpenAI با رابط Jevمانند یکسان نیست:

مفهوم	رابط Jevمانند	API مستقیم OpenAI
شواهد مشترک	state	input
سؤال‌ها	معمولاً شیء نام‌گذاری‌شده	آرایه با فیلد name
سؤال دودویی	noul	predicate
گزینه‌های انتخاب	criteria	choices
سطح‌های امتیاز	criteria مرتب	levels
پاسخ‌ها	وابسته به سرویس	آرایهٔ answers

این اختلاف از مستندات مستقیم OpenAI و Microsoft قابل مشاهده است؛ اشتراک مفهوم به معنی سازگاری کد و payload نیست.

OpenAI سرعت حدود ۱۰ برابر مسیر Responses را برای Decisions اعلام می‌کند. این یک مقایسه با مسیر سرویس خود شرکت است، نه اثبات اینکه Luna Decisions از تمام مدل‌های این مقاله سریع‌تر است. معماری داخلی این مسیر نیز در راهنمای بررسی‌شده به اندازهٔ چک‌پوینت‌های باز تشریح نشده است.

۵.۵. Laya: encoder کوچک و سریع، با وابستگی جدی به انتخاب چک‌پوینت

Laya یک مدل واحد با قابلیت ثابت نیست؛ خانواده‌ای از چک‌پوینت‌هاست:

• laya: انگلیسی، ModernBERT-large، حدود 421M پارامتر؛
• laya-multilingual: چندزبانه، mmBERT-base، حدود 322M؛
• laya-typed-decisions: نسخهٔ تنظیم‌شده برای گردش‌کارهای typed-decisions، حدود 421M.

نسخهٔ انگلیسی از backbone دوطرفه و سر تصمیم شامل دو لایهٔ ترنسفورمر، scorer نشانگر گزینه و سر act/escalate استفاده می‌کند. هر گزینه در محل نشانگر خود امتیاز می‌گیرد و سپس احتمال‌ها در مجموعهٔ گزینه‌های همان سؤال نرمال می‌شوند.

اما محدودیت‌های صریح مخزن، از ادعاهای کلی صفحهٔ معرفی مهم‌ترند:

• نسخه‌های پایه در بنچمارک typed-decisions عملکرد نزدیک به شانس و پایین‌تر از baseline اکثریت داشته‌اند؛
• نتیجهٔ ۰٫۷۶۶ متعلق به چک‌پوینت fine-tuneشده روی بخش آموزش همان بنچمارک است؛
• برای choice حدود کمتر از ۲۰ گزینه توصیه شده است؛
• مدل‌ها می‌توانند بیش‌ازحد مطمئن باشند و بازتنظیم دما روی دادهٔ خودتان توصیه شده است؛
• برای ورودی غیرانگلیسی باید نسخهٔ چندزبانه انتخاب شود.

بنابراین توصیف دقیق Laya این است: یک پایهٔ کوچک و سریع برای تخصصی‌سازی محلی، نه جایگزین اثبات‌شدهٔ تمام مدل‌های بزرگ در تصمیم‌گیری zero-shot.

۶. کدام دو مدل واقعاً محلی‌اند و نصب آن‌ها چه تفاوتی دارد؟

Laya: شروع سبک‌تر

نمونهٔ زیر مطابق الگوی API منتشرشده است و برای فارسی نسخهٔ چندزبانه را بارگذاری می‌کند. این مثال در این بررسی اجرا نشده است.

python
import laya

agent = laya.load(
    "convaiinnovations/laya",
    subfolder="multilingual"
)

result = agent.predict(
    {
        "message": "برای سفارش من دو بار پول کم شده؛ لطفاً بررسی کنید."
    },
    {
        "department": {
            "type": "choice",
            "instructions": "موضوع اصلی این درخواست مربوط به کدام واحد است؟",
            "criteria": {
                "billing": "پرداخت، صورتحساب و بازپرداخت",
                "technical": "خطای نرم‌افزاری و اختلال فنی",
                "account": "ورود و دسترسی به حساب",
                "other": "موارد خارج از دسته‌ها"
            }
        }
    }
)

نکتهٔ استقرار: مخزن هشدار می‌دهد Router با تنظیم پیش‌فرض max_loaded=1 ممکن است هنگام جابه‌جایی زبان‌ها، چک‌پوینت را دوباره بسازد. برای بار کاری ترکیبی، preload یا نگه‌داشتن مدل‌های لازم در حافظه اهمیت دارد؛ زمان بارگذاری سرد را نباید با زمان inference گرم مخلوط کرد.

Decider V1.1: محلی، اما با زیرساخت جدی‌تر

دستورالعمل کارت مدل شامل موارد زیر است:

• Python 3.12 یا جدیدتر؛
• دسترسی احرازشده به مخزن Hugging Face که در متن راهنما private توصیف شده است؛
• نصب وابستگی‌های نسخه‌بندی‌شدهٔ مخزن؛
• GPU دارای ظرفیت حدود ۴۹ GiB برای وزن‌ها، به‌علاوهٔ حافظهٔ کاری؛
• استفاده از inference همراه برای حفظ توجه غیرعلّی و دمای کالیبراسیون.

وجود برچسب Apache 2.0 را باید از امکان دسترسی عملی حساب شما به فایل‌ها جدا دانست. همچنین ۴۹ GiB سقف کل مصرف حافظه نیست؛ کارت مدل صریحاً حافظهٔ کاری را علاوه بر وزن‌ها ذکر می‌کند.

۷. قیمت: مقایسهٔ ورودی با مقایسهٔ هزینهٔ تصمیم فرق دارد

برای یک سناریوی سادهٔ فرضی، اگر مجموع توکن ورودی قابل‌صورتحساب دقیقاً یک میلیارد توکن باشد، نرخ‌های پایهٔ اعلام‌شده چنین هزینه‌ای می‌سازند:

گزینه	هزینهٔ پایهٔ یک میلیارد توکن ورودی
Jev	۴۲ دلار
Microsoft-Decision-1	۴۲ دلار
Decider V1.1 در OpenRouter	۲۰ دلار
GPT-6 Luna Decisions	۱۰۰ دلار
Laya محلی	وابسته به هزینهٔ زیرساخت و بهره‌برداری

این محاسبه فقط تبدیل مستقیم نرخ هر میلیون توکن است. برای OpenAI، ضرایب ورودی بلند و پردازش منطقه‌ای ممکن است اعمال شوند؛ برای اجرای محلی نیز نبود هزینهٔ API به معنی نبود هزینهٔ GPU، میزبانی یا عملیات نیست.

برای تصمیم مهندسی، پیشنهاد می‌کنم به‌جای «قیمت هر میلیون توکن»، هزینهٔ هر تصمیم قابل‌استفاده را اندازه بگیرید:

$$C_{\text{usable decision}}=\frac{C_{\text{inference}}+C_{\text{retry}}+C_{\text{escalation}}+C_{\text{operations}}}{N_{\text{usable decisions}}}$$

این فرمول، معیار پیشنهادی این مقاله است، نه تعرفهٔ یکی از ارائه‌دهندگان. هدف آن روشن کردن این مسئله است که مدلی با نرخ توکن پایین‌تر، اگر ارجاع انسانی یا ارزیابی دوم بیشتری لازم داشته باشد، الزاماً ارزان‌ترین راه‌حل عملیاتی نخواهد بود. توصیهٔ تنظیم آستانه بر اساس هزینهٔ خطا نیز در مستندات OpenAI و Microsoft آمده است.

۸. سرعت و بنچمارک: کدام ادعاها قابل مقایسه‌اند؟

اعداد منتشرشده چه می‌گویند؟

منبع	نتیجهٔ گزارش‌شده	محدودیت تفسیر
Microsoft	بهترین دقت در مجموعهٔ ۳۶ بنچمارک با نزدیک ۱۵۰ هزار سؤال؛ سرعت ۳۵ برابر GPT-6 Sol در آزمون خود شرکت	گزارش سازنده است؛ نتیجهٔ یک پروتکل مشترک مستقل برای هر پنج گزینه نیست.
کارت مدل Decider V1.1	Decision Index برابر 61.56؛ در همان جدول Jev برابر 57.9	نتیجهٔ منتشرشده در کارت مدل است؛ نمایندهٔ تمام کاربردها یا همهٔ نسخه‌های Jev نیست.
مخزن Laya	32.8 ms برای یک سؤال با نسخهٔ چندزبانه روی Tesla T4	زمان اجرای محلی مشخص است؛ با رفت‌وبرگشت API اینترنتی هم‌سنخ نیست.
OpenAI	حدود ۱۰ برابر سریع‌تر از Responses API	مقایسهٔ دو مسیر سرویس است، نه رتبه‌بندی همهٔ رقبا.

نکتهٔ مهم دربارهٔ Laya این است که خود مخزن می‌گوید اعداد Jev را در همان آزمایش اندازه نگرفته و از نتایج اشخاص ثالث استفاده کرده است؛ نمونه‌ها و promptها نیز متفاوت بوده‌اند. بنابراین نسبت‌های سرعت یا برتری آن نسبت به Jev را نباید بنچمارک کنترل‌شدهٔ مستقیم معرفی کرد.

همچنین در جدول تفصیلی typed-decisions مخزن Laya، چک‌پوینت تخصصی آن دقت بالاتری دارد، اما ECE آن ۰٫۲۱۳ گزارش شده، در برابر ۰٫۱۴۴ برای عدد نقل‌شدهٔ Jev. حتی با کنار گذاشتن مشکل تفاوت پروتکل، همین جدول نشان می‌دهد برتری دقت را نباید خودکار به برتری کالیبراسیون تعمیم داد.

چرا «میلی‌ثانیه» به‌تنهایی کافی نیست؟

برای یک مقایسهٔ قابل انتشار، پیشنهاد می‌کنم این موارد جدا ثبت شوند:

• زمان بارگذاری سرد و inference گرم؛
• زمان محاسبهٔ محلی و زمان کامل رفت‌وبرگشت API؛
• تعداد سؤال در هر درخواست؛
• طول متن و تعداد گزینه‌ها؛
• اندازه و تعداد تصویرها؛
• هم‌زمانی، batching و صف؛
• میانه، P95، P99 و نرخ خطا.

این‌ها پروتکل پیشنهادی ارزیابی‌اند. دلیل نیاز به آن‌ها در منابع نیز روشن است: مخزن Laya اثر بارگذاری و batching را نشان می‌دهد، Microsoft اثر منطقهٔ پردازش را گوشزد می‌کند و کارت Decider اثر رزولوشن تصویر بر حافظه و تأخیر را توضیح می‌دهد.

۹. احتمال و confidence را یکسان فرض نکنید

در API مستقیم OpenAI، choice و score هم توزیع احتمال و هم فیلد جداگانهٔ confidence دارند. در مثال رسمی choice، احتمال گزینهٔ منتخب ۰٫۹۵ و confidence برابر ۰٫۹۳ است؛ پس حتی در یک پاسخ، این دو الزاماً یک عدد نیستند.

برای مقایسهٔ بین مدل‌ها، پیشنهاد عملی این است:

1. معنای دقیق هر فیلد را از مستندات همان سرویس بخوانید.
2. خروجی توزیع احتمال را نگه دارید، نه فقط گزینهٔ منتخب را.
3. آستانه را برای هر مدل، نسخه و کاربرد جدا تنظیم کنید.
4. رفتار روی موارد مبهم و خارج از توزیع را بسنجید.

مستندات Jev دربارهٔ تغییر نسخه پس از تنظیم آستانه هشدار می‌دهد؛ Laya بازتنظیم دما را توصیه می‌کند و Microsoft تأکید دارد قابلیت اعتماد احتمال‌ها روی انواع مسئلهٔ آشنا قوی‌تر است.

برای انتخاب آستانه، یک مثال فرضی: ممکن است مسیریابی یک تیکت با احتمال ۰٫۸۵ قابل قبول باشد، اما اقدام مالی همان آستانه را نپذیرد. این اعداد توصیهٔ عمومی یا آستانهٔ اثبات‌شدهٔ هیچ مدل نیستند؛ باید با هزینهٔ خطای مثبت و منفی و دادهٔ برچسب‌خورده تعیین شوند.

۱۰. مثال کامل: سامانهٔ رسیدگی به درخواست بازپرداخت

فرض کنیم پیام مشتری این است:

«دو بار از حسابم پول کم شده. اگر امروز حل نشود، اشتراکم را لغو می‌کنم.»

به‌جای درخواست یک تصمیم کلی با عنوان «چه کار کنم؟»، پیشنهاد می‌کنم مسئله به چهار سؤال شکسته شود:

متغیر	نوع	تعریف
department	choice	واحد اصلی رسیدگی
explicit_cancellation_threat	noul یا predicate	وجود تهدید صریح به لغو
urgency	score	سطح فوریت طبق rubric مشخص
enough_evidence	noul یا predicate	کافی بودن شواهد برای ادامهٔ بررسی

خروجی فرضی:

json{
  "department": {
    "choice": "billing",
    "probabilities": {
      "billing": 0.97,
      "technical": 0.01,
      "account": 0.01,
      "other": 0.01
    }
  },
  "explicit_cancellation_threat": 0.98,
  "urgency": 2.6,
  "enough_evidence": 0.42
}

این داده ساختگی است و برای توضیح طراحی آمده است. سیاست برنامه می‌تواند چنین باشد:

pythonif not payment_records_confirm_duplicate_charge:
    action = "request_or_fetch_payment_evidence"
elif refund_amount > automatic_refund_limit:
    action = "human_approval"
else:
    action = "continue_refund_workflow"

در این طرح، مدل از زبان طبیعی نشانه استخراج و آن را ارزیابی می‌کند؛ اما قواعد قطعی مانند سقف مبلغ و تأیید تراکنش در کد باقی می‌مانند. این تفکیک با الگوی «مدل برای قضاوت عددی، برنامه برای اقدام و ارجاع» در راهنماهای رسمی سازگار است.

۱۱. برای فارسی کدام نکات تعیین‌کننده‌اند؟

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

دربارهٔ دو گزینه، هشدارهای روشن‌تری داریم:

• Jev می‌گوید انگلیسی زبان اصلی آموزش و محل بهترین دقت آن است؛ سایر زبان‌ها باید روی محتوای واقعی آزمایش شوند.
• Laya برای غیرانگلیسی نسخهٔ چندزبانه دارد، اما ادعای پشتیبانی از بیش از صد زبان به معنی کیفیت برابر در همهٔ زبان‌ها نیست. مخزن خود مدل تفاوت جدی عملکرد و اطمینان میان زبان‌ها را گزارش می‌کند.

برای بنچمارک فارسی وبلاگ، پیشنهاد می‌کنم مجموعهٔ آزمایش این موارد را پوشش دهد:

• فارسی رسمی، محاوره‌ای و فینگلیش؛
• «ی/ي»، «ک/ك»، نیم‌فاصله و غلط تایپی؛
• اعداد فارسی و لاتین، مبلغ و واحد پول؛
• نفی: «نمی‌خواهم لغو کنم» در برابر «می‌خواهم لغو کنم»؛
• کنایه، ابهام و چند نیت در یک پیام؛
• متن ترکیبی فارسی و انگلیسی، به‌ویژه خطاهای فنی؛
• متن بی‌ربط، اطلاعات ناکافی و تزریق دستور در محتوای ورودی.

این فهرست، طرح پیشنهادی آزمون است، نه نتیجهٔ آزمایش مدل‌ها. برای جلوگیری از مقایسهٔ ناعادلانه نیز نسخهٔ مدل، متن دقیق سؤال‌ها، تعریف گزینه‌ها و مجموعهٔ داده باید ثابت و ثبت‌شده باشند؛ حساسیت به عبارت‌بندی و تغییر نسخه در مستندات Microsoft و Jev صریحاً مطرح شده است.

۱۲. جمع‌بندی انتخاب، بدون رتبه‌بندی تبلیغاتی

با فرض اینکه قیمت API برای پروژهٔ شما قابل قبول است، انتخاب اولیه بهتر است بر محدودیت استقرار، طول واقعی ورودی و کیفیت فارسی متمرکز شود، نه صرفاً نرخ توکن.

نیاز غالب	گزینهٔ شایستهٔ بررسی اولیه	دلیل و شرط

نیاز غالب	گزینهٔ شایستهٔ بررسی اولیه	دلیل و شرط
اجرای محلی کوچک و تخصصی	Laya	اندازهٔ کم و مسیر fine-tuning؛ مشروط به پذیرش کانتکست کوتاه و ارزیابی نسخهٔ چندزبانه.
اجرای محلی مدل بزرگ با تصویر	Decider V1.1	وزن و inference منتشرشده، پشتیبانی تصویر؛ مشروط به دسترسی، حافظهٔ کافی و رعایت سقف پیاده‌سازی محلی.
ادغام در Azure	Microsoft-Decision-1	Entra ID، deployment و کنترل‌های سازمانی؛ اجرای ابری، نه محلی.
رابط Jevمانند و سؤال‌های متعدد روی state مشترک	Jev	بودجهٔ جداگانهٔ درخواست و سؤال، نسخه‌بندی روشن و سفارشی‌سازی از طریق تعریف مسئله.
ورودی بسیار بلند در مسیر API	GPT-6 Luna Decisions	بزرگ‌ترین سقف اعلام‌شده در این مقایسهٔ سرویس‌ها؛ با توجه به ضریب قیمت long-context و وضعیت public beta.
کمترین نرخ پایهٔ ورودی در APIهای جدول	Decider V1.1 در OpenRouter	۰٫۰۲ دلار برای هر میلیون توکن ورودی؛ این نرخ به‌تنهایی کیفیت یا کمترین هزینهٔ عملیاتی را ثابت نمی‌کند.

نتیجهٔ فنی قابل دفاع، معرفی یک برندهٔ مطلق نیست. این گزینه‌ها در یک فضای مسئله رقابت می‌کنند، اما قرارداد سرویس، ظرفیت محلی، معماری و شواهد ارزیابی آن‌ها متفاوت است. برای انتشار نتیجهٔ نهایی دربارهٔ فارسی، معیار تعیین‌کننده باید آزمون مشترک روی دادهٔ فارسیِ همان کاربرد باشد؛ همراه با دقت، کیفیت احتمال‌ها، نرخ ارجاع و تأخیر کامل، نه صرفاً یک نمرهٔ عمومی یا عدد سرعتِ اعلام‌شده توسط سازنده.