این مطلب، نگارش سوم از متنیه که روزهای اول بعد از انتشار Jev نوشتم. حدود یک ماه و نیم، به‌صورت پیش‌نویس موند، و دو بار بازنویسیش کردم تا هم با داده‌های به‌روز بخونه و هم یادگیری‌ها و تجربه‌ی عملی خودم رو توی متن لحاظ کنم. بعد از خوندنش می‌دونین Decision Model چیه، کجا به‌دردت می‌خوره، و کجا نه، و چطور اولین تجربه رو با داده‌ی خودتون بسنجین. اگه هم فقط کد رو می‌خواین، لینک repo آخر مطلبه.
اگر در این چند سال LLMها رو داخل نرم‌افزارهاتون استفاده کرده باشین، احتمالاً این الگو رو زیاد دیدین که هر جا به کمی هوشمندی نیاز داریم، درخواست رو می‌فرستیم برای یه مدل زبانی و منتظر می‌مونیم تا یه چیزی برامون تولید کنه!
فرقی هم نمی‌کنه بخوایم یه ایمیل بنویسیم، یا یه مسئله پیچیده رو تحلیل کنیم یا فقط تشخیص بدیم یه تیکت پشتیبانی بهتره برای کدوم تیم ارسال بشه. مثلاً فرض کنین که مشتری یه چنین پیامی فرستاده:
“!My card was charged twice and nobody answers me”
نرم‌افزار ما باید سه چیز رو تشخیص بده:
- آیا این درخواست فوریه؟
- باید برای کدوم تیم ارسال بشه؟ تیم Billing، Support یا Fraud؟
- مشتری چقدر ناراحته؟
روش رایج اینه که پیام رو همراه با یک Prompt به LLM بدیم، ازش بخوایم JSON تولید کنه، خروجی رو Parse و Validate کنیم و بعد تصمیم بگیریم. این روش کار می‌کنه، اما واقعاً برای هر تصمیم کوچیکی به یه مدل تولیدکننده متن نیاز داریم؟
ما که نمی‌خوایم مدل درباره ناراحتی مشتری انشا بنویسه! فقط می‌خوایم چند قضاوت مشخص رو انجام بده تا نرم‌افزار بتونه قدم بعدی رو برداره. برای چنین شرایطیه که دسته‌ای از مدل‌ها و APIها به ذیل عنوان System One Models یا دقیق‌تر، Decision Models وارد داستان می‌شن.
System One اصلاً یعنی چی؟
اسم System One از تقسیم‌بندی معروف دنیل کانمن درباره دو شیوه تفکر انسان الهام گرفته شده:
- System 1: سریع، شهودی و تقریباً بدون تأمل آگاهانه.
- System 2: کندتر، تحلیلی‌تر و نیازمند بررسی و استدلال.
البته این تقسیم‌بندی مربوط به شناخت انسانه و استفاده ازش توی حوزه AI بیشتر یک تشبیهه. قرار نیست تصور کنیم دو نوع مغز دیجیتال داریم که یکی فکر می‌کنه و اون یکی نه! توی دنیای AI، اصطلاح System One معمولاً برای مدل‌هایی به کار می‌ره که به‌جای تولید پاسخ‌های طولانی یا زنجیره‌های استدلال، برای تصمیم‌گیری سریع درباره سؤال‌های محدود بهینه شدن.
به بیان ساده، به‌جای این الگو:
Prompt ➡️ Generated Textبا یه چیزی شبیه این سروکار داریم:
State + Questions + Options ➡️ Decisions + Probabilitiesیعنی وضعیت فعلی رو به مدل می‌دیم، سؤال‌هایی مشخص می‌پرسیم و خروجی‌هایی دریافت می‌کنیم که مستقیماً توی منطق نرم‌افزار قابل استفاده‌اند. برای تیکت قبلی، خروجی واقعی Jev روی OpenRouter ساختاری شبیه این داره:
{
"team":{
"type":"choice",
"choice":"billing",
"confidence":0.67,
"probabilities":{
"billing":0.78,
"support":0.17,
"fraud":0.05
}
},
"urgent":{
"type":"noul",
"noul":0.82
},
"frustration":{
"type":"score",
"score":1.69,
"confidence":0.69,
"probabilities":{
"0":0.03,
"1":0.25,
"2":0.72
}
}
}این ساختار مال Jev است و API هنوز alpha است، پس ممکنه عوض بشه. به سه نوع سؤال دقت کن: noul فقط احتمال «بله» رو می‌ده، choice برای هر گزینه احتمال می‌ده، و score جایگاه روی یه مقیاس مرتب‌شده رو نشون می‌ده. اما نکته اصلی اینه که مدل به‌جای تولید یک متن آزاد، گزینه‌ها رو ارزیابی کرده و نتایجی ارائه داده که نرم‌افزار می‌تونه ازشون برای انتخاب مسیر بعدی استفاده کنه.
مثلاً وقتی احتمال ارجاع به Billing بالاست و شواهد کافی هم وجود داره، تیکت به این تیم ارسال بشه. اگر تصمیم مبهمه، برای بررسی انسانی فرستاده بشه. و این دقیقاً جاییه که Decision Models جذاب می‌شن.
از Jev تا OpenAI و Microsoft
سپتامبر ۲۰۲۶ شرکت TypeSafe AI یه مدل به اسم Jev معرفی کرد که مشخصاً برای چنین تصمیم‌هایی طراحی شده بود. Jev به‌جای اینکه یه چت‌بات عمومی باشه، روی ارزیابی سؤال‌های محدود و خروجی‌های احتمالاتی تمرکز داشت.
توی API اولیه Jev، سه نوع عملیات اصلی وجود داشت (توی OpenAI Decisions API اسم‌ها فرق می‌کنه، ولی ایده یکیه.)
:
| مفهوم | Jev | OpenAI Decisions API |
|---|---|---|
| احتمال درست بودن یک گزاره | Noul | predicate |
| انتخاب بین گزینه‌ها | Choice | choice |
| امتیاز روی یک مقیاس | Score | score |
مثلاً می‌تونستیم یک State مشترک شامل پیام مشتری داشته باشیم و چند سؤال متفاوت درباره همون پیام بپرسیم.
در ضمن، شرکت TypeSafe روشی به نام RLCD یا Reinforcement Learning for Calibrated Decisions هم معرفی کرد که هدفش بهبود کیفیت تصمیم‌ها و معنادارتر کردن احتمالات خروجی بود. اما داستان به Jev محدود نموند. ۶ اکتبر ۲۰۲۶، OpenAI هم Decisions API رو به‌صورت بتا معرفی کرد و توی ۲۲ اکتبر نسخه عمومی اون رو عرضه کرد.
این API از مدل gpt-6-luna استفاده می‌کنه و سه نوع سؤال داره:
predicate: احتمال درست بودن یک گزاره چقدره؟choice: از بین گزینه‌های موجود، کدوم مناسب‌تره؟score: ورودی روی یک مقیاس تعریف‌شده چه امتیازی می‌گیره؟
علاوه بر متن، می‌تونه تصاویر و داده‌های ساختاریافته رو هم ارزیابی کنه و چندین سؤال رو در یک درخواست پاسخ بده.
چند روز بعد از معرفی اولیه OpenAI، مایکروسافت هم ۹ اکتبر Microsoft-Decision-1 رو معرفی کرد؛ مدلی مبتنی بر Qwen3.5-9B که برای وظایفی مثل Classification، Routing، Prioritization و Verification آموزش تکمیلی دیده.
البته Jev مدل بسته‌ست و API اون فقط به‌صورت میزبانی‌شده در دسترسه. چند مدل open-weight هم اومدن، مثل Clef از Cloudflare با API سازگار با Jev، یا Liquid d1 و CLM-8B از Stanford و NVIDIA. وقتی داده نباید از سرور خودتون بیرون بره، این‌ها گزینه‌ی مهمی‌ان.
این محصولات لزوماً معماری یکسانی ندارن و حتی استفاده از یک Decisions API هم به معنی وجود یک معماری کاملاً جدید در پشت پرده نیست. اما جهت حرکت مشترکشون جالبه:
به‌جای استفاده از مدل‌های مولد عمومی برای هر کار کوچیکی، بخشی از ظرفیت AI رو روی تصمیم‌های مشخص، سریع و قابل استفاده در نرم‌افزار متمرکز کنیم.
مگه Structured Outputs همین کار رو نمی‌کنه؟
تا حدی چرا! و اتفاقاً این یکی از رایج‌ترین و مهم‌ترین سؤال‌هاست. ما می‌تونیم با JSON Schema یا Constrained Decoding از یه LLM بخوایم خروجی مشخصی تولید کنه؛ مثلاً یه JSON این شکلی:
{
"department": "billing"
}پس چرا به یه Decision Model نیاز داریم؟ تفاوت اصلی توی نوع قراردادیه که با مدل داریم؛ توی Structured Outputs معمولاً از یه مدل مولد می‌خوایم پاسخی تولید کنه که با ساختار مشخصی سازگار باشه. اما توی Decision Model، مسئله مستقیماً ارزیابی یک گزاره یا مجموعه‌ای از گزینه‌هاست و مدل برای این نوع وظایف بهینه شده.
به‌جای اینکه صرفاً نام Billing رو تولید کنه، می‌تونه میزان ترجیح گزینه‌های مختلف رو هم برگردونه. البته این تفاوت مطلق نیست. یه LLM معمولی هم می‌تونه گزینه‌ها رو مقایسه کنه، بهشون امتیاز بده یا از طریق Token Probabilities اطلاعات احتمالاتی رو ارائه بده. بنابراین نوآوری فقط توی فرمت خروجی نیست؛ بلکه توی هدف آموزش مدل، مسیر Inference، قرارداد API و بهینه‌سازی برای تصمیم‌های محدود هم هست.
ضمن اینکه برای استخراج اطلاعات پیچیده، تولید آبجکت‌های چندلایه یا ساخت پاسخ‌های ترکیبی، Structured Outputs همچنان می‌تونه انتخاب بهتری باشه.
پس چرا از یک Classifier معمولی استفاده نکنیم؟
اتفاقاً توی خیلی از مواقع باید همین کار رو بکنیم! فرض کنید سیستمی داریم که فقط قراره میلیون‌ها ایمیل رو به دو دسته Spam و Not Spam تقسیم کنه. یک Classifier کوچیک و تخصصی ممکنه سریع‌تر، ارزون‌تر و حتی دقیق‌تر از یه Decision Model عمومی باشه. اما تفاوت مهم اینه که خیلی از Decision Modelها می‌تونن بدون آموزش مجدد برای هر مسئله، سؤال‌ها و گزینه‌های تازه‌ای رو در زمان اجرا دریافت کنن.
مثلاً امروز درباره تیم مسئول یه تیکت می‌پرسیم، فردا درباره ارتباط یه داکیومنت با سؤال کاربر، و پس‌فردا درباره اینکه کدوم ابزار برای ادامه کار یه AI Agent مناسب‌تره!!
پس با یه مفهوم کاملاً تازه توی Classification مواجه نیستیم، بلکه با تلاش برای ترکیب انعطاف‌پذیری مدل‌های عمومی و کارایی مدل‌های تخصصی تصمیم‌گیری روبه‌رو هستیم.
چرا این مدل‌ها می‌تونن خیلی سریع‌تر باشن؟
مدل‌های زبانی مولد معمولاً خروجی رو به‌صورت مرحله‌ای و توکن‌به‌توکن تولید می‌کنن. طبیعتاً حتی وقتی فقط یک پاسخ کوتاه می‌خوایم، کماکان با فرایند تولید پاسخ سروکار داریم.
در مقابلش، مدل‌های System One (طبق تعریف مقاله‌ی System1-Arena) ورودی رو یک‌بار می‌خونن و احتمال گزینه‌ها رو مستقیم از همون Forward Pass بیرون می‌کشن. یعنی به‌جای ده‌ها مرحله‌ی تولید توکن، فقط یک مرحله‌ی خوندن داریم. مثلاً OpenAI اعلام کرده Decisions API برای این وظایف می‌تونه تا ۱۰ برابر سریع‌تر از استفاده از GPT-6 Luna توی Responses API باشه. مایکروسافت هم می‌گه Decision-1 نتایج چشمگیری توی سرعت و کیفیت تصمیم‌گیری داشته.
البته این اعداد وابسته به شرایط آزمایش، مدل مقایسه‌شده، اندازه ورودی و تعداد سؤال‌هاست. نباید تصور کنیم هر Decision Modelی همیشه ۱۰ برابر سریع‌تر از هر LLM دیگه‌ای خواهد بود. و مهم‌تر اینکه:
سریع‌تر تصمیم گرفتن لزوماً به معنی درست‌تر تصمیم گرفتن نیست!
نکته‌ی هزینه: هزینه‌ی Jev عملاً فقط از توکن‌های ورودی میاد (طبق README پروژه‌ی نمونه، حدود ۰٫۰۴۲ دلار برای هر میلیون توکن ورودی، خروجی رایگان). پس اگه چند سؤال درباره‌ی یه متن داری، همه رو توی یک request بفرست تا متن فقط یک‌بار حساب بشه.
Probability، Confidence و داستان Calibration
یکی از ویژگی‌های این مدل‌ها، خروجی‌های احتمالاتیه. مثلاً فرض کنین مدل برای ارجاع یه تیکت، یه چنین نتیجه‌ای داده:
Billing: 0.51
Fraud: 0.49و برای یه تیکت دیگه:
Billing: 0.98
Fraud: 0.02اگه صرفاً argmax بگیریم، توی هر دو حالت Billing انتخاب می‌شه. ولی مشخصه که این دو تصمیم از نظر عدم‌قطعیت یکسان نیستن. اینجا مفهوم Calibration اهمیت پیدا می‌کنه.
فرض کنین مدل توی تعداد زیادی از پیش‌بینی‌هاش احتمال ۰٫۸ رو گزارش کرده. اگر درست کالیبره شده باشه، انتظار داریم در شرایط مشابه تقریباً ۸۰ درصد اون پیش‌بینی‌ها درست باشن. اما این ویژگی باید با آزمایش روی داده‌های واقعی بررسی بشه. صرف اینکه مدل یه عددی بین صفر و یک تولید می‌کنه، به معنی کالیبره بودن اون نیست.
توی Jev، معیار Confidence برای Choice نشون می‌ده احتمال‌ها چقدر روی یک گزینه متمرکزن، نه اینکه جواب چقدر احتمال داره درست باشه. فرمولش (p_max − 1/n) / (1 − 1/n)ـه. مثلاً با احتمال‌های ۰٫۸ و ۰٫۲، Confidence می‌شه ۰٫۶. چون به تعداد گزینه‌ها بستگی داره، Confidence ۰٫۸۵ با سه گزینه یعنی بالاترین احتمال حدود ۰٫۹۰، و با شش گزینه حدود ۰٫۸۸. برای همین بهتره روی خود احتمال گزینه‌ی اول Threshold بذاریم، یا دقیقاً بدونیم Confidence چطور تعریف شده. Noul هم Confidence جدا نداره و فقط یه احتمال برمی‌گردونه. حتی احتمالات حاصل از دو سؤالِ مستقل هم الزاماً قابل جمع یا مقایسه مستقیم نیستن. مثلاً اگه یه بار بپرسیم:
Does the customer want a refund?
و دفعه بعد بپرسیم:
Does the customer NOT want a refund?
و مدل به‌ترتیب ۰٫۷۲ و ۰٫۴۷ جواب بده، نمی‌تونیم صرفاً با جمع کردنشون نتیجه بگیریم که مدل قوانین احتمال رو نقض کرده. این‌ها دو ارزیابی جداگانه با صورت‌بندی متفاوت‌اند، نه الزاماً دو خروجی مکمل از یه توزیع احتمال واحد. این ناسازگاری رو می‌شه به نفع خودمون استفاده کرد: اگه سؤال و معکوسش هر دو عدد بالایی بگیرن (مثلاً هر دو بالای ۰٫۶)، تصمیم رو به انسان بسپاریم. ترتیب گزینه‌های Choice هم می‌تونه روی جواب اثر بذاره، پس توی تست خودتون ترتیب رو عوض کنین.
خلاصه اینکه احتمالات خروجی ابزار ارزشمندی برای تصمیم‌گیری هستن، اما قرار نیست به چشم حقیقت قطعی بهشون نگاه کنیم.
آیا این مدل‌ها Hallucination (توهم‌زدگی) ندارن؟
یکی از ادعاهایی که TypeSafe توی معرفی Jev مطرح کرد، موضوع Zero Hallucinations بود. اما باید مشخص کنیم منظور از این عبارت چیه. فرض کنید خروجی مجاز مدل فقط یکی از این گزینه‌ها باشه:
billing
support
fraudتوی چنین شرایطی مدل نمی‌تونه یهو یه گزینه‌ای مثل legal_department بسازه، چون این گزینه اصلاً توی فضای خروجی مجاز وجود نداره. این ویژگی ارزشمنده و جلوی خطاهای ساختاری رو می‌گیره. اما اگه پاسخ صحیح Fraud باشه و مدل Billing رو انتخاب کنه چی؟ خب، مدل همچنان اشتباه کرده! فقط این بار اشتباهش داخل Schema اتفاق افتاده.
Type-safe بودنِ خروجی به معنی Correct بودن تصمیم نیست!
حتی بهتره توی خیلی از مسائل گزینه‌هایی مثل unknown یا needs_review هم داشته باشیم تا مدل مجبور نشه تحت هر شرایطی یکی از گزینه‌های موجود رو انتخاب کنه. البته وجود این گزینه‌ها هم به‌تنهایی تضمین نمی‌کنه که مدل همیشه عدم‌قطعیت خودش رو درست تشخیص بده.
ورودی غیرقابل‌اعتماد: Prompt Injection
متن تیکت رو مشتری می‌نویسه، پس باید ورودی غیرقابل‌اعتماد حسابش کرد. Decision Model هم مثل LLMها ممکنه تحت‌تأثیر جمله‌هایی قرار بگیره که توی متن جا داده شدن. توی گزارشی که VentureBeat منتشر کرد، اضافه کردن یه فیلد جعلی مثل «کاربر قبلاً تأیید کرده» به خروجی یه ابزار، احتمال block شدن یه دستور خطرناک رو از ۰٫۷۶ به ۰٫۴۸ رسوند. نتیجه‌ی عملی:
- متن کاربر رو همیشه توی state بذارین، نه توی instructions.
- کار برگشت‌ناپذیر (پرداخت، حذف، دسترسی) هیچ‌وقت فقط به احتمال مدل بسته نباشه.
- متنی که مهاجم کنترلش می‌کنه نباید بتونه خودش مجوز اجرای خودش رو صادر کنه.
کاربرد واقعی: جای این مدل‌ها توی معماری نرم‌افزار کجاست؟
به نظرم جذاب‌ترین بخش ماجرا اینجاست. فرض کنین یه AI Agent داریم که درخواست مشتری رو بررسی می‌کنه. LLM می‌تونه درخواست رو بفهمه، اطلاعات لازم رو از سیستم‌های مختلف جمع کنه، درباره مسئله استدلال کنه و پاسخ نهایی رو بنویسه. اما بین این مراحل، تعداد زیادی تصمیم کوچک وجود داره:
- آیا اطلاعات کافی جمع شده؟
- آیا سند بازیابی‌شده واقعاً مرتبطه؟
- کدوم ابزار باید اجرا بشه؟
- آیا نتیجه به بازبینی انسانی نیاز داره؟
- مرحله بعدی Continue، Retry، Escalate یا Stop باشه؟
لزومی نداره برای همه این تصمیم‌ها یه مدل مولد رو وادار کنیم فرایند کامل تولید پاسخ رو طی کنه. می‌تونیم بعضی از این قضاوت‌های محدود رو به یک Decision Model بسپاریم، بدون اینکه کنترل واقعی سیستم رو به اون واگذار کنیم. مثلاً برای مسیریابی تیکت، روند کلی می‌تونه این باشه:
درخواست مشتری ➡️ Decision Model ➡️ تصمیم + احتمال ➡️ Policy نرم‌افزار
├─ Auto Route
├─ Human Review
└─ Request More Infoو توی کد، این تفکیک یه شکل ساده داره. مدل فقط احتمال می‌ده و بخش decide که کد معمولیه تصمیم می‌گیره (نسخه‌ی کامل با درخواست HTTP توی repo آخر مطلبه):
def decide(answers: dict) -> dict:
team = answers["team"]["choice"]
p_top = answers["team"]["probabilities"][team]
urgent = answers["urgent"]["noul"] >= 0.5
if team == "unclear":
return {"action": "human_review", "reason": "model says: unclear"}
if team == "fraud": # hard rule: never auto-handle fraud
return {"action": "human_review", "reason": "fraud always needs a person", "urgent": urgent}
if p_top < MIN_TOP_PROBABILITY: # 0.80, an example
return {"action": "human_review", "reason": f"low confidence ({p_top:.2f})"}
return {"action": "auto_route", "team": team, "urgent": urgent}این کد و آستانه‌ی ۰٫۸۰ صرفاً مثاله. در عمل باید براساس داده‌های واقعی، نوع خطا، هزینه تصمیم اشتباه و کیفیت کالیبراسیون تعیین بشه. نسخه‌ی مدل رو هم pin کنید بهتره (مثلاً typesafe/jev-1.13 نه jev-latest) تا با هر release، آستانه‌هاتون جابه‌جا نشه. هر تصمیم رو با احتمال‌ها و نسخه‌ی مدل log کنین، ولی متن حساس مشتری رو نه. ولی در عمل باید براساس داده‌های واقعی، نوع خطا، هزینه تصمیم اشتباه و کیفیت کالیبراسیون تعیین بشه. نکته مهم‌تر اینه که Decision Model نباید جای Business Rules و کنترل‌های قطعی نرم‌افزار رو بگیره.
اگه قاعده مشخصی داریم که مثلاً تمام تیکت‌های دارای کد خطای X باید به Billing برن، بهتره همون قاعده رو در کد پیاده کنیم. اما اگه لازم باشه از یک پیام مبهم بفهمیم مشتری واقعاً درباره چه موضوعی صحبت می‌کنه، اون‌وقت استفاده از یک مدل هوشمند می‌تونه منطقی باشه.
به بیان دیگه، مدل درباره معنای ورودی قضاوت می‌کنه؛ نرم‌افزار براساس قوانین و سیاست‌های خودش تصمیم می‌گیره چه عملی مجاز و مناسب است. این تفکیک برای معماری AI Agentها هم مهمه. قرار نیست هر تصمیم احتمالاتی مستقیماً به اجرای یک عملیات واقعی منجر بشه.
آیا System One می‌تونه جای مدل‌های استدلالی رو بگیره؟
اینجا بد نیست به یه پژوهش تازه اشاره کنیم؛ ۱۵ اکتبر ۲۰۲۶ یه تیم از دانشگاه تگزاس در آستین مقاله‌ی System1-Arena: Which Decisions Can Be Left to System 1? رو منتشر کردن (البته هنوز داوری‌نشده). اون‌ها ۳۰ مدل، شامل ۱۰ مدل System One، رو روی حدود ۹۲ هزار سؤال و ۱۳۸ محیط تعاملی بررسی کردن. توی سؤال‌های غیر ایجنتیک، بزرگ‌ترین مدل‌های System One به دقت LLMهای بسته‌ی سریع رسیدن یا ازشون بهتر بودن، با احتمالات باکیفیت‌تر (Brier پایین‌تر: ۰٫۳۴۹ در برابر ۰٫۴۶۱) و حدود یک‌چهارم Latency (میانه‌ی ۳۲۱ میلی‌ثانیه برای Jev در برابر ۱٬۲۷۶ برای GPT-6 Luna). اما توی محیط‌های چندمرحله‌ای، مدل‌های کوچیک System One به‌ندرت موفق شدن (حداکثر ۳٫۱٪). نکته‌ی جالب‌تر اینه که سه مدل با دقت تک‌مرحله‌ای یکسان ۶۷٫۸٪، توی حلقه‌ی بسته موفقیت‌های ۲۶٫۵٪، ۱۷٫۴٪ و ۵٫۷٪ داشتن. یعنی دقت یک قدم، موفقیت کل مسیر رو پیش‌بینی نمی‌کنه.
بنابراین نتیجه پژوهش این نیست که دوران مدل‌های استدلالی تمام شده! برعکس، سؤال مهم‌تری مطرح می‌کنه:
کدوم تصمیم‌ها رو می‌تونیم به یک مدل سریع و محدود بسپاریم و کدوم‌ها همچنان به استدلال عمیق‌تر نیاز دارن؟
کجا نباید استفاده کنیم؟
- حساب و شمارش و مقایسه‌ی تاریخ: توی کد بمونه. مدل فقط استخراج کنه، کد مقایسه کنه.
- استدلال چندمرحله‌ای: همون‌جا که نتیجه‌ی هر قدم به قدم قبلی وابسته‌ست.
- خروجی متنی: خلاصه، پاسخ به مشتری، توضیح.
- تصمیم برگشت‌ناپذیر بدون بازبینی: پرداخت، حذف، دسترسی.
- داده‌ی حساس: اگه نباید به API میزبانی‌شده بره، سراغ مدل open-weight بریم بهتره.
از کجا شروع کنیم؟
اگه بخوام فردا این فناوری رو وارد یه پروژه واقعی کنیم، احتمالاً از یه مسئله کوچک شروع می‌کنیم، نه بازطراحی کل معماری! مثلاً مسیریابی تیکت‌های پشتیبانی:
- اول مجموعه‌ای از تیکت‌های واقعی با پاسخ‌های درست جمع می‌کنم، شامل موارد معمول، مبهم و حساس.
- گزینه‌ها و معیارهای تصمیم‌گیری رو مشخص می‌کنم، از جمله شرایطی که باید به انسان ارجاع داده بشن.
- چند روش رو با هم مقایسه می‌کنم: Rule-based، Classifier، LLM با Structured Outputs و Decision Models.
- دقت، Latency، هزینه، Calibration و هزینه تصمیم‌های اشتباه رو اندازه می‌گیرم.
- بعد از آزمایش، مشخص می‌کنم کدوم تصمیم‌ها قابل خودکارسازی هستن و کدوم‌ها همچنان باید بازبینی بشن.
- Threshold رو از روی نمودار «چند درصد خودکار می‌شه در برابر چند درصد درسته» روی داده‌ی برچسب‌خورده انتخاب می‌کنیم، نه از یه عدد پیش‌فرض.
- ترتیب گزینه‌ها رو عوض می‌کنیم و چند بار تکرار می‌کنیم تا پایداری جواب‌ها مشخص بشه.
برای شروع می‌تونید مستندات Jev، OpenAI Decisions API و Microsoft-Decision-1 رو بررسی کنید.
ولی توصیه من اینه که قبل از انتخاب هرکدوم، مسئله و معیار موفقیت خودتون رو دقیق تعریف کنین. نتایج بنچمارک‌های عمومی و ادعاهای سازندگان، لزوماً به معنی عملکرد مشابه روی داده‌های شما نیستن.
جمع‌بندی
به نظرم داستان System One Models فقط ظهور چند تا مدل سریع‌تر و ارزون‌تر نیست.
ما توی مهندسی نرم‌افزار سال‌ها تلاش کردیم مسئولیت‌ها رو از هم جدا کنیم؛ ولی با اومدن LLMها، گاهی دوباره همه‌چیز رو به یک مدل واحد سپردیم: فهم مسئله، تحلیل، تصمیم‌گیری، اعتبارسنجی و حتی اجرای عملیات!
شاید حالا وقتش باشه همین اصل ساده مهندسی رو در معماری نرم‌افزارهای مبتنی بر AI هم جدی‌تر بگیریم.
قرار نیست برای هر تصمیمی یه مدل استدلالی بزرگ اجرا بشه، برای هر طبقه‌بندی ساده یک LLM تولید متن کنه، یا هر AI Agent برای انتخاب قدم بعدی یک رمان بنویسه!
گاهی بهترین ابزار یه if ساده است. گاهی یک Classifier تخصصی، گاهی یک Decision Model سریع و گاهی یک مدل استدلالی قدرتمند یا حتی قضاوت انسان.
مسئله اصلی این نیست که کدوم مدل باهوش‌تره؛ مسئله اینه که برای هر نوع تصمیم، چه ابزاری مناسب‌تره.