AI Engineers

از نظر کاربرد Decision Modelها , قضیه دیگه فقط چند Demo نیست و چند الگوی مشخص واقعاً وارد محصول و فرایندهای کاری شدن.

• توی Search و RAG**، استارتاپ Knowviq الان از Jev داخل محصولش استفاده می‌کنه: نتیجه‌های جست‌وجو رو از نظر ارتباط امتیاز می‌ده، تک‌تک جمله‌های جواب رو با شواهد چک می‌کنه و در نهایت تصمیم می‌گیره اصلاً سؤال با اطلاعات پیدا‌شده قابل پاسخ هست یا نه. برای مقایسه Jev با Clef، d1 و مدل Perplexity هم ۹۳۸ بررسی واقعی از ترافیک خودش رو بازسازی کرده که حدود ۹۳۰۰ تصمیم مستقل می‌شده.
https://knowviq.com/blog/decision-models

• توی **امنیت**، خود Cloudflare داره Clef رو داخل تیم Threat Intelligence آزمایش می‌کنه تا سایت‌ها رو مثلاً به فروشگاهی، فیشینگ، مد و بقیه دسته‌ها تقسیم کنه. در آزمایش منتشرشده‌شون، کل فرایند دریافت، Render و دسته‌بندی یه سایت با Clef حدود ۲.۲ ثانیه طول کشیده، در حالی که همون مسیر با `gpt-oss-120b` حدود ۴.۷ ثانیه بوده. یعنی Decision Model اینجا فقط جای یه classifier ساده نیست؛ بخشی از یه فرایند امنیتی واقعی شده.
https://blog.cloudflare.com/clef-decision-models

• توی **انتشار محتوا هم یه نمونه خیلی ملموس داریم. Thorsten Meyer گزارش کرده سه Decision Model workflow رو در عملیات نشر خودش اجرا می‌کنه و تا الان حدود ۹۰ هزار تصمیم گرفته شده: تشخیص اینکه یه خبر به کدوم سایت مرتبطه، تشخیص زبان مقاله و یه classifier جایگزین برای موضوع مقاله. فقط در یکی از این کارها ۷۸٬۸۸۹ مقاله با هزینه گزارش‌شده ۲.۰۱ دلار بررسی شدن؛ حدود ۱۰ هزار تطبیق «خبر ↔️ سایت» هم طی سه روز انجام شده.
https://thorstenmeyerai.com/reality-check/24-ways-to-use-jev-a-decision-model-playbook/

• توی مسیردهی (routing) بین مدل‌ها و Agentها هم این ایده عملاً تبدیل به محصول شده. OpenRouter الان Jev Router داره که برای هر درخواست مدل و میزان استدلال مناسب رو انتخاب می‌کنه. در پروژه‌های Open Source مربوط به Claude Code هم Jev برای کارهایی مثل بررسی ایمنی قبل از اجرای Tool، انتخاب اندازه مناسب Sub-agent و تشخیص اینکه Agent واقعاً کارش رو تمام کرده یا نه استفاده شده.

• توی پشتیبانی مشتری، Lead qualification و Moderation هم الگو تقریباً یکیه: به‌جای اینکه برای هر تیکت یا پیام یه LLM کامل اجرا بشه، Decision Model چند سؤال محدود مثل «برای کدوم تیمه؟»، «چقدر فوریه؟»، «نیاز به بررسی انسان داره؟» یا «با این Policy تضاد داره؟» رو هم‌زمان جواب می‌ده. Cloudflare این‌ها رو جزو کاربردهای اصلی Clef معرفی کرده و ابزارهایی مثل Vercel AI Gateway هم Jev رو مشخصاً برای routing، بررسی ریسک و guardrail داخل Agent loop ارائه کردن.

نکته مشترک تقریباً همه این استفاده‌های واقعی هم اینه که Decision Model آخرین صاحب اختیار نیست. وقتی confidence بالاست، کد خودش مسیر رو ادامه می‌ده؛ وقتی مدل مطمئن نیست، پرونده می‌ره برای LLM قوی‌تر یا انسان. یعنی کاربرد اصلی این مدل‌ها حذف کامل LLM نیست، بلکه حذف هزاران LLM call ساده و گرون از وسط سیستم و نگه‌داشتن مدل‌های بزرگ برای جاهاییه که واقعاً استدلال یا تولید لازم داریم.

به نظرم مهم‌ترین نکته اینه که Decision Model قرار نیست جای LLM رو بگیره. داره اون بخش‌هایی از سیستم رو می‌گیره که جواب باز نمی‌خوان؛ فقط یه تصمیم سریع، ارزان و قابل‌استفاده توسط کد می‌خوان.

احتمالاً معماری خیلی از Agentها به این سمت می‌ره: LLM برای برنامه‌ریزی و تولید، Decision Model برای صدها تصمیم کوچک وسط مسیر.
🛠 Join @LLMEngineers Community

کمتر از یک ماه از معرفی Jev گذشته و چیزی که اول شبیه یه مدل خاص برای «تصمیم‌گیری بدون تولید متن» بود، الان تبدیل شده به یه دسته مستقل از مدل‌ها؛ Jev، Clef، d1، GLiDE، Decision 2.0، Julia، OpenJev و چند پروژه دیگه هم‌زمان دارن روی همین ایده کار می‌کنن.

ایده اصلی خیلی ساده‌ست: برای خیلی از کارهای نرم‌افزار اصلاً لازم نیست LLM شروع کنه به تولید متن. مثلاً وقتی فقط می‌خوای بدونی «این تیکت برای کدوم تیمه؟»، «کدوم Tool اجرا بشه؟»، «این نتیجه RAG مرتبطه؟» یا «Agent اجازه داره این کار رو انجام بده؟»، مدل می‌تونه مستقیماً احتمال گزینه‌ها رو برگردونه و کد بر اساس همون تصمیم بگیره. Cloudflare همین الگو رو برای دسته‌بندی درخواست پشتیبانی و حتی تشخیص نوع سایت‌ها توضیح داده و Knowviq هم Decision Modelها رو برای سنجش ارتباط نتایج، پشتیبانی جمله‌ها با شواهد و تشخیص قابل‌پاسخ‌بودن سؤال استفاده کرده.
https://blog.cloudflare.com/clef-decision-models

چیزی که این چند روز جالب‌تر شده، رقابت شدید روی مدل‌های بازه. کلودفلر Clef و Clef-flash رو با Apache 2.0 منتشر کرده؛ خانواده Decision 2.0 از vLLM هم از 0.6B تا 27B می‌ره و می‌تونه تا ۶۴ سؤال درباره یک ورودی رو در یک Forward Pass جواب بده. حتی Julia-1 فقط 144M پارامتر داره، یعنی برای خیلی از دسته‌بندی‌ها و مسیردهی‌های ساده شاید اصلاً مدل چندمیلیاردپارامتری لازم نباشه.

از اون طرف llama.cpp در نسخه 0.6.0 یه endpoint جدید به اسم /v1/systemone اضافه کرده و چند مدل مثل OpenJev، Julia، Kev، Lev و Laya رو محلی اجرا می‌کنه؛ Clef هم با متن و تصویر پشتیبانی شده. یعنی این مدل‌ها دیگه فقط API ابری نیستن و می‌شه بخشی از تصمیم‌های حساس رو کاملاً روی سیستم خودمون نگه داشت.

یه مسیر متفاوت هم داره شکل می‌گیره: «فکر بیشتر» بدون تولید Token بیشتر. GLiDE وقتی بین گزینه‌ها مطمئن نباشه محاسبه بیشتری اختصاص می‌ده، و RSI-Jev v6.0-VL حتی عمق شبکه رو برای هر تصمیم تغییر می‌ده؛ نسخه 4B اون می‌تونه بسته به سختی سؤال در لایه 16، 20 یا 32 متوقف بشه و امتیاز گزارش‌شده‌اش در Decision Index از 38.38 به 46.24 رسیده.

خود Decision Index هم الان داره تبدیل به یکی از محل‌های اصلی مقایسه این مدل‌ها می‌شه، ولی رتبه‌بندی هنوز خیلی سیاله. مثلاً Fastino برای GLiDE امتیاز 64.81 گزارش کرده و Cloudflare هم در زمان انتشار Clef اون رو صدرنشین معرفی کرده؛ این اعداد از روش‌های ارزیابی متفاوت و بعضاً گزارش خود سازنده‌ها میان، پس نباید ازشون یه جدول قطعی «بهترین مدل» ساخت.

https://huggingface.co/spaces/multimodalart/jev-decision-index

🛠 Join @LLMEngineers Community

جدا از موج Decision Modelها، چند خبر فنی این هفته هست که برای AI Engineerها واقعاً ارزش دنبال‌کردن داره.

اولیش EmbeddingGemma 2 از Google DeepMindـه؛ یه مدل باز 740M پارامتری که متن، کد، تصویر، صدا و ویدیو رو داخل یه فضای Embedding مشترک می‌بره. مدل Apache 2.0ـه، برای اجرای روی لپ‌تاپ و موبایل طراحی شده و حتی می‌شه فقط بخش‌های موردنیازش رو بارگذاری کرد؛ مثلاً نسخه متن و کد سبک‌تر از مدل کامل چندرسانه‌ایه. برای جست‌وجوی محلی، RAG، جست‌وجوی کد و بازیابی بین چند نوع محتوا، این خیلی کاربردی‌تر از فرستادن همه‌چیز به یه API بزرگه.
https://blog.google/innovation-and-ai/technology/developers-tools/embeddinggemma-2


خبر دوم شاید از نظر مهندسی حتی مهم‌تر باشه. Hugging Face یه راهنمای کامل برای Multi-Harness RL منتشر کرده و یه نتیجه خیلی معنی‌دار داره: همون مدل LFM2.5-2.6B با دقیقاً همون وزن‌ها در Mini-SWE-Agent حدود ۶۲٪ و در Claude Code فقط ۳۳٪ از کارها رو حل کرده. یعنی عملکرد Agent فقط «قدرت مدل» نیست؛ برنامه‌ای که دور مدل ساخته شده، Toolها، Context، حلقه اجرا و نحوه پایان‌دادن کار می‌تونن نتیجه رو تقریباً دو برابر تغییر بدن.
https://adithyask-multi-harness-rl.hf.space

جالب‌تر اینکه وقتی همون مدل با RL روی چند Harness مختلف آموزش داده شد، عملکرد کلیش از ۴۲٪ به ۵۴٪ رسید. این یه نکته مهم برای Benchmarkها هم داره: وقتی می‌گیم «فلان مدل روی Coding Agent بهتره»، بدون گفتن Harness عملاً نصف اطلاعات رو حذف کردیم.

یه موضوع کوچیک‌تر ولی کاربردی هم از پست Andrej Karpathy راه افتاده: استفاده از ASD-STE100 برای توضیح‌های LLM. این همون انگلیسی کنترل‌شده‌ایه که برای مستندات فنی صنایع هوایی ساخته شده؛ جمله کوتاه، فعل مستقیم، واژه ساده و ابهام کمتر. الان چند Skill برای Claude Code و Agentهای دیگه ساخته شده که خروجی توضیحی رو با همین قواعد بازنویسی می‌کنن تا از متن‌های شلخته و پر از حاشیه کم بشه.
https://github.com/JordanBelfort1/explaining-in-asd-ste100

و یه نمونه جالب دیگه از قدرت مدل‌های تخصصی BioCLIP 2ـه. این مدل برای تصاویر موجودات زنده روی TreeOfLife-200M آموزش دیده و روی تشخیص گونه‌ها و چند کار تصویری زیستی از مدل‌های عمومی جلو زده. نکته مهمش برای من خود زیست‌شناسی نیست؛ دوباره همون الگوییه که داریم همه‌جا می‌بینیم: یه مدل نسبتاً تخصصی، وقتی دقیقاً برای یک فضای مسئله ساخته شده، لازم نیست اندازه یه Frontier LLM باشه تا روی همون کار خیلی قوی عمل کنه.
https://huggingface.co/imageomics/bioclip-2

خلاصه اینکه جهت کلی معماری AI داره جالب می‌شه: به‌جای اینکه همه‌چیز رو بندازیم گردن یه LLM غول‌پیکر، داریم قطعات تخصصی می‌سازیم؛ Embedding Model برای بازیابی، Decision Model برای تصمیم، مدل تخصصی برای دامنه مشخص، و یه Agent Harness خوب برای وصل‌کردن همه این‌ها به هم.

شاید سؤال مهم دیگه «بهترین مدل چیه؟» نباشه؛ «بهترین ترکیب مدل‌ها برای این مسئله چیه؟» سؤال بهتریه.

🛠 Join @LLMEngineers Community

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

اول از همه، OpenAI با GPT-6.1 Sol، Dots، Codex Cloud، Space و Ultrafast عملاً داره ChatGPT رو از یه چت‌بات به پلتفرمی برای اجرای Agentها تبدیل می‌کنه. Dots قراره Agentهای شخصی و دائمی باشن که کامپیوتر ابری خودشون رو دارن و می‌تونن روی کارهای طولانی ادامه بدن. Codex هم بیشتر از قبل از «دستیار کدنویسی» فاصله گرفته و به سمت انجام کامل کارهای مهندسی می‌ره.

از طرف دیگه، Google با Gemini 4 Argon تمرکزش رو گذاشته روی کارهای پیچیده و طولانی مثل مهندسی نرم‌افزار، کارهای سازمانی، حقوقی، مالی و امنیت سایبری. نکته مهم این نسل از مدل‌ها دیگه فقط جواب بهتر به یه سؤال نیست؛ مهم اینه که مدل تا چه حد می‌تونه وسط یه فرایند طولانی، وضعیت کار رو حفظ کنه، ابزار استفاده کنه و چند مرحله جلو بره.

در Anthropic هم Claude Sonnet 5.5 اومده که طبق اعلام خود شرکت بیش از ۳۰٪ سریع‌تر شده و هزینه انجام بعضی کارها رو هم تا ۳۰٪ پایین آورده، در حالی که عملکردش به مدل‌های Opus نزدیک شده. این اتفاق مهمه چون برای سیستم واقعی همیشه قوی‌ترین مدل انتخاب منطقی نیست؛ نسبت هزینه، سرعت و کیفیت خیلی وقت‌ها مهم‌تر از چند امتیاز بیشتر در Benchmarkه.

برای اکوسیستم لوپن سورس هم چند اتفاق جدی افتاده. Mistral Large 4 با معماری MoE و یک تریلیون پارامتر، Reflection Beam و Aleph Alpha Kolibri نشون می‌دن مدل‌های با وزن باز (Open Weight) دوباره دارن به مرز مدل‌های قدرتمند بسته نزدیک می‌شن. این یعنی برای تیم‌هایی که کنترل زیرساخت، استقرار داخلی، حریم خصوصی یا Fine-tuning مهمه، گزینه‌ها خیلی جدی‌تر از یک سال قبل شدن.

ولی به نظرم یکی از مهم‌ترین روندها برای AI Engineerها رشد سریع Decision Model یا System One Modelهاست.

این مدل‌ها قرار نیست مثل ChatGPT متن تولید کنن. وضعیت سیستم + یه سؤال مشخص بهشون می‌دی و به‌جای جواب آزاد، احتمال گزینه‌ها رو برمی‌گردونن. مثلاً:
«این درخواست به کدوم مسیر بره؟»
«ایجنت باید ادامه بده یا متوقف بشه؟»
«این محتوا متعلق به کدوم دسته است؟»

اول Jev این ایده رو جدی مطرح کرد، ولی حالا GLiDE، مدل‌های Clef و Clef-flash از Cloudflare، خانواده Decision 2.0 از vLLM و d1 از Liquid AI هم وارد رقابت شدن.

اینجا هرکدوم یه مزیت متفاوت دارن: Jev فعلاً مرجع شناخته‌شده‌تر این حوزه‌ست، Clef-flash روی سرعت و ورودی تصویری جذابه، Decision 2.0 برای اجرای محلی و مدل‌های با اندازه‌های مختلف مناسبه، d1 روی هزینه پایین تمرکز داره و GLiDE ادعا می‌کنه در تصمیم‌های سخت‌تر و استدلالی بهتر عمل می‌کنه. البته بخش زیادی از این امتیازات هنوز توسط خود سازنده‌ها منتشر شده، پس قبل از انتخاب باید روی داده و سناریوی واقعی خودتون ارزیابی‌شون کنید.

در لایه زیرساخت Agent هم همین تغییر دیده می‌شه. Manus 2.0، Meta Muse و Claude Code Mods دارن نشون می‌دن Agent دیگه فقط یه حلقه ساده‌ی «Prompt → Tool → Prompt» نیست. کم‌کم داریم به سمت محیط‌های اجرایی کامل می‌ریم که حافظه، ابزار، کامپیوتر، هویت، زمان‌بندی کارها، افزونه و دسترسی به سرویس‌های مختلف دارن.

هم‌زمان، بحث ایمنی Agentها هم خیلی جدی‌تر شده. OpenAI گفته فعالیت‌های ناسازگار Agentها رو در بیش از ۱۰۰ سازمان شناسایی کرده و طبق گزارش‌ها انتشار GPT-6.1 Astra هم به‌دلیل نگرانی‌های ایمنی متوقف شده. وقتی یه Agent بتونه چند ساعت مستقل کار کنه، فایل بخونه، API صدا بزنه و روی سیستم تغییر ایجاد کنه، کنترل دسترسی، Sandbox، ثبت فعالیت‌ها، پایش و ارزیابی دیگه قابلیت جانبی نیستن؛ بخشی از معماری اصلی محصولن.

خلاصه برای AI Engineerها اینه: خیلی جدی‌تر برید سمت معماری Agentها، استفاده از Tool، کار با کامپیوتر، سیستم‌های ارزیابی، Decision Modelها، Sandbox، حافظه، کنترل دسترسی و هماهنگ‌کردن کارهای طولانی.

مدل پایه هنوز خیلی مهمه، ولی مزیت اصلی کم‌کم داره از «کدوم مدل رو استفاده کردی؟» منتقل می‌شه به «چه سیستمی دور مدل ساختی؟»

🛠 Join @LLMEngineers Community

جمنای ۴ معرفی شد !

امروز Jev 1.13 رو از طریق API رسمی OpenRouter آزمایش کردم، و نتیجه‌اش بیشتر از چیزی که انتظار داشتم جالب بود.

روی دیتاست MASSIVE با ۵٬۹۴۸ جمله‌ی فارسی و انگلیسی و ۶۰ نوع Intent، چهارده مدل رو روی یک داده‌ی یکسان مقایسه کردم. بر اساس دقت:

- اول، E5 Base با Logistic Regression: ۸۳٫۷۹٪+

- دوم، TF-IDF با Logistic Regression: ۸۲٫۴۸٪+

- سوم، Decider-2B: ۸۱٫۶۴٪

- بعد، E5 Small: ۸۰٫۹۰٪

- بعد، Jev 1.13: ۷۹٫۸۶٪

- بعد، Decider-0.8B: ۷۶٫۷۷٪

- آخر، Kev-0.8B: ۵۷٫۹۵٪

یعنی یک مدل امبدینگ ۲۷۸ میلیونی از مدل‌های تخصصی تصمیم‌گیری جلوتر افتاد، و TF-IDF هم هنوز از Jev و Decider دقیق‌تر بود.

حالا راز E5 چیه؟ از مدل چندزبانه‌ی E5 استفاده کردم تا متن رو به بردارهای ۷۶۸بعدی تبدیل کنه و فقط یک Logistic Regression ساده روی خروجی‌اش آموزش دادم. هیچ‌کدوم از پارامترهای E5 رو دوباره آموزش ندادم.

ولی یک نکته‌ای هست که نباید از قلم بیفته: من برای E5 و TF-IDF از بیش از ۲۳ هزار نمونه‌ی آموزشی برچسب‌دار استفاده کردم، درحالی‌که Jev و Decider بدون آموزش و به‌صورت Zero-shot ارزیابی شدن. پس این نتایج ثابت نمی‌کنه E5 یک موتور تصمیم‌گیری عمومی قوی‌تره.

از Jev یک نتیجه‌ی غیرمنتظره هم درآمد. اگر به‌جای Accuracy از Macro-F1 استفاده کنیم، مقایسه برعکس می‌شه: Jev به ۷۷٫۳۲٪ می‌رسه و Decider-2B به ۷۶٫۲۵٪. چون Macro-F1 به همه‌ی کلاس‌ها وزن یکسان می‌ده، یعنی Jev با وجود دقت کلی پایین‌تر، بین دسته‌های مختلف متعادل‌تر بوده.

کالیبراسیون هم داستان جداگانه‌ای داشت. خطای کالیبراسیون یا ECE برای Decider-2B حدود ۰٫۰۱۸۶، برای Jev حدود ۰٫۰۵۰۹ و برای E5 Base حدود ۰٫۲۵۷۳ دراومد. هرچه ECE کمتر باشه یعنی اطمینان پیش‌بینی‌شده به دقت واقعی نزدیک‌تره. البته ECE همه‌چیز رو نشون نمی‌ده؛ E5 با وجود خطای بالاتر، توی آزمایش من در رتبه‌بندی تصمیم‌ها بر اساس ریسک بهتر عمل کرد.

از نظر هزینه و سرعت هم، اجرای کامل Jev روی هر ۵٬۹۴۸ جمله حدود ۰٫۲۹۳ دلار شد و میانه‌ی زمان پاسخ هم حدود ۶۲۶ میلی‌ثانیه.
یک نکته‌ی دیگه هم این بود که در دو اجرای مستقل روی ۳۹۸ ورودی مشترک، حدود ۲٫۳ درصد پیش‌بینی‌های Jev تغییر کرد. یعنی نتیجه‌ی یک اجرای منفرد رو نباید خیلی قطعی گرفت.

دارم هنوز تست میکنم این مدل هارو، مرحله بعدی هدفم دیگه فقط تشخیص Intent نیست؛ می‌خوام ببینم Encoderهای کوچک و چندزبانه می‌تونن توی ۵۰ کاربرد مختلف، از انتخاب ابزار و کنترل Agent تا ارزیابی RAG و تصمیم‌گیری چندمرحله‌ای، با مدل‌های تصمیم گیری تخصصی مث Jev رقابت کنن یا نه.

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

🛠 Join @LLMEngineers Community

5 تا مدل خفن ریلیز شده تو دو سه روز!
- Opus 5.5
- GPT 6 Sol
- GPT 6 Luna
- Grok 4.7
- Mimo v2.6

امتیاز بنچمارک های ورژن پرو و فلش MiMo-V2.6

مدل های جدید شیائومی منتشر شدن MiMo-V2.6
مدل pro اش قدرتش در حد gpt sol عه و قیمتش در حد luna
نسبت به قدرتی که داره به شدت ارزونه، فوق العادس

چیزی که توی موج Open Sourceهای Jev جالبه اینه که بیشتر پروژه‌ها اصلاً سعی نکردن معماری جدیدی از صفر بسازن؛ رفتن سراغ یه LLM آماده و فقط روش خروجی تصمیم‌گیری ساختن. یعنی به‌جای اینکه Qwen یا Gemma متن تولید کنه، مستقیم احتمال گزینه‌ها از داخل مدل خونده می‌شه.

مثلاً SemIf از Qwen3.5-4B استفاده می‌کنه، system-one-open روی Gemma ساخته شده و OpenJev سراغ DiffusionGemma رفته. مزیت این مسیر واضحه: دانش و درک زبانی LLM رو تقریباً آماده تحویل می‌گیری. توی JevBench v1.2 هم SemIf با امتیاز 74.6 تقریباً کنار خود Jev با 75.3 قرار گرفته.

اما یه مسیر متفاوت هم شکل گرفته: کلاً LLM مولد رو حذف کن و یه encoder کوچیک رو مخصوص تصمیم‌گیری آموزش بده. open-jev-deberta-v3-large با DeBERTa همین کار رو کرده و Laya هم با ModernBERT-large + یه decision head اختصاصی جلو رفته.

نکته اینجاست که این مدل‌ها دیگه متن تولید نمی‌کنن؛ ورودی رو می‌خونن و مستقیم می‌گن احتمال هر گزینه چقدره. نتیجه معمولاً مدل خیلی کوچیک‌تر، latency کمتر و serving ارزون‌تره. Laya مثلاً فقط 421M پارامتر داره و برای routing، moderation، Support و تصمیم‌های پرتکرار طراحی شده.

ولی هزینه این سبک هم مشخصه: LLMهایی مثل SemIf روی سؤال‌ها و دسته‌بندی‌های جدید معمولاً بهتر generalize می‌کنن، چون پشتشون یه مدل زبانی 4B با دانش عمومی نشسته. encoderهایی مثل Laya و DeBERTa وقتی وارد domain جدید می‌شن، بیشتر به fine-tuning و داده واقعی همون کسب‌وکار احتیاج دارن.

برای من دو مسیر کاملاً جدا شده: اگر یه decision engine عمومی می‌خوای که امروز CRM باشه و فردا Agent Routing و یه روز دیگه چیز جدید، مسیر SemIf منطقی‌تره. ولی اگر میلیون‌ها تصمیم تکراری و مشخص مثل Support routing، Lead Scoring، Moderation داری، مسیر Laya خیلی جذاب‌تره؛ یه مدل کوچیک که فقط همون کار رو خوب انجام بده، نه یه LLM کامل که برای هر تصمیم کوچیک بیدارش کنیم.


🛠 Join @LLMEngineers Community

پروژه ها‌ی Open Source جایگزین Jev کم کم دارن پدیدار میشن

🛠 Join @LLMEngineers Community

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

نکته کلیدی اینه که Jev وقتی خوب کار می‌کنه که انتخاب‌ها محدود و مشخص باشن. توی یه تست مرورگر، وقتی فقط باید بین چند ابزار مشخص انتخاب می‌کرد، سیستم 49 از 49 کار رو انجام داد؛ ولی وقتی آزادی بیشتری برای کنترل مستقیم مرورگر داشت، فقط 25 از 49 موفق شد.

برای همین Separation of Concerns اینجا خیلی مهمه:

* برای تصمیم‌های کوچیک و پرتعداد → Jev
* برای تحلیل، reasoning و تولید محتوا → GPT / Claude / Gemini
* برای قوانین قطعی، محاسبات و محدودیت‌های حساس → Code
* برای تصمیم‌های پرریسک → Human

مثلاً توی CRM می‌تونه مشتری‌ها رو بر اساس احتمال ریزش، اهمیت یا نوع درخواست دسته‌بندی کنه. توی Support می‌تونه فوریت و تیم مناسب رو تشخیص بده. توی Lead Scoring می‌تونه مشخص کنه کدوم سرنخ ارزش پیگیری بیشتری داره.

برای Agent Routing هم خیلی کاربردیه؛ یعنی قبل از اینکه یه Agent سنگین شروع به کار کنه، Jev تصمیم بگیره کدوم Agent، Tool یا حتی کدوم مدل مناسب‌تره. توی RAG هم می‌تونه اسناد کم‌ربط رو حذف یا نتایج رو دوباره رتبه‌بندی کنه، و توی QA خروجی مدل‌ها رو از نظر کیفیت، ارتباط یا ریسک بررسی کنه.

برای Moderation می‌تونه محتوای مشکوک رو پرچم کنه، برای Browser Automation حرکت بعدی بین چند عمل مشخص رو انتخاب کنه، و توی Workflow Automation تعیین کنه هر درخواست وارد کدوم شاخه از فرایند بشه.

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

اما نکته مهم اینه که Jev لزوماً «خیلی باهوش‌تر» نیست؛ بیشتر برای یه نوع خاص از هوش بهینه شده. روی بعضی تصمیم‌های محدود خیلی خوب جواب می‌ده، ولی روی مسئله‌های مبهم ممکنه شدیداً افت کنه. مثلاً توی یه تست ۲۰۰۰ ایمیل phishing، دقت مستقیم Jev فقط 62.6٪ بود در حالی که Claude Haiku به 81.3٪ رسید.

جالب اینجاست که وقتی همون مسئله به چند سؤال ساده‌تر شکسته شد و تصمیم نهایی با Code گرفته شد، دقت سیستم مبتنی بر Jev به حدود 95٪ رسید. برای من این دقیقاً نشون می‌ده جای درست Jev کجاست: نه «مغز کل سیستم»، بلکه یه قطعه سریع برای تصمیم‌های محدود داخل یه معماری بزرگ‌تر.

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

منابع:
https://madewithjev.com/builds/webmcp-benchmark
https://github.com/anisselbd/jev-phishing-bench

🛠 Join @LLMEngineers Community

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

اصل مسئله‌شون اینه که LLMها برای chat عالی‌ان، ولی توی automation هنوز دردسر دارن: خروجی stringـه، باید parse و validate بشه، latency بالاست و confidence هم همیشه قابل اعتماد نیست.

مدل Jev از یه دسته‌ی جدید به اسم System One Modelsـه. ورودی می‌تونه متن یا state نامرتب باشه، ولی خروجی از قبل type مشخص داره: مثلاً یه category، score، boolean یا چند probability. یعنی مدل قرار نیست چند پاراگراف تولید کنه؛ مستقیم یه تصمیم ساختاریافته تحویل می‌ده.

برای آموزش هم یه روش به اسم RLCD معرفی کردن؛ Reinforcement Learning for Calibrated Decisions. هدف اینه که probabilityهای مدل واقعاً معنی‌دار باشن. یعنی وقتی می‌گه ۹۰٪ مطمئنم، انتظار داری تقریباً در ۹۰٪ موارد مشابه درست باشه.

یه تفاوت مهم دیگه parallel samplingـه. LLM معمولی (autoregressive) توکن به توکن خروجی می‌سازه، ولی Jev چون text generation نداره می‌تونه چند تصمیم رو در یه query با هم تولید کنه. برای چیزهایی مثل scoring، routing، classification و تصمیم‌های real-time این می‌تونه خیلی مهم باشه.

کمپانی TypeSafe ادعا می‌کنه Jev روی System One taskها intelligence مشابه بعضی مدل‌های frontier داره، ولی حدود 40x تا 200x سریع‌تره و latency حدود 70 تا 500 میلی‌ثانیه داره. قیمت input هم $0.042 برای هر یک میلیون توکن اعلام شده.

یه ادعای مهم دیگه هم «no type errors»ـه. چون خروجی از قبل schema مشخص داره، مدل نمی‌تونه یه value خارج از ساختار تعریف‌شده تحویل بده. ولی این رو نباید با «هیچ‌وقت اشتباه نمی‌کنه» قاطی کرد؛ ممکنه خروجی کاملاً type-safe باشه ولی تصمیمش غلط باشه.

https://x.com/CompleteSkeptic/status/2099925682726002904?s=20

https://typesafe.ai/blog/introducing-system-one-models-and-jev

🛠 Join @LLMEngineers Community

روند بکارگیری یادگیری تقویتی (RL) در بهبود عملکرد مدل‌های زبانی (LLMs) :

https://telegra.ph/RL-in-LLMs-09-14

مدل ۳.۷ میلیارد پارامتری K2 Horizon تو بنچمارک Artificial Analysis امتیاز ۱۶ گرفته. این عدد برای یه مدل زیر ۴ میلیارد پارامتر واقعاً بالاست و از بیشتر مدل‌های هم‌اندازه‌ش جلوتره.

علت اصلیش اینه که روی حجم خیلی بزرگی از داده (حدود ۲۰ تریلیون توکن) ترین شده و بخش زیادی از این داده‌ها مثال‌های حل مسئله و استدلال بودن. بعدش هم چند مرحله‌ی بعد از ترین اصلی روش کار کردن؛ از جمله یادگیری تقویتی مخصوص کار با ابزار و تسک‌های چندمرحله‌ای. نتیجه‌ش شده مدلی که تو کدنویسی، استدلال و کار با ابزار از چیزی که معمولاً از این سایز انتظار می‌ره خیلی بهتر عمل می‌کنه.

نکته‌ی مهم‌تر اینه که این مدل واقعاً اوپن‌سورسه، نه فقط وزن‌هاش. تیم سازنده داده‌ها یا دستور ساخت داده، کد ترینینگ، چک‌پوینت‌های میانی و همه‌چیز رو هم منتشر کرده.

https://ifm.ai/blog/k2/
https://huggingface.co/IFM/K2-Horizon-3.7B

🛠 Join @LLMEngineers Community

هر بار که Coding Agent یک فایل یا log بزرگ می‌خونه، معمولاً کل خروجی در هر model call دوباره و دوباره به context فرستاده می‌شه. نتیجه؟ tokenهای تکراری پرشدن کانتکس و هزینه‌ی اضافه.

مکانیزم ObservationPack در SoL-Pi بعد از چند بار ارسال کامل، خروجی رو به یک placeholder کوتاه تبدیل می‌کنه و نسخه‌ی اصلی رو به‌صورت local archive نگه می‌داره. هر وقت مدل دوباره به بخشی از آن نیاز داشته باشه، با obs_recall دقیقاً همان قسمت را برمی‌گردونه.

عددهای زرد تصویر، توکن هایی هستن که با همین کار دوباره ارسال نشدن؛ مثلاً ۲٬۸۳۵ یا ۶٬۴۵۷ توکن.

دقت کنین context حذف نشده؛ فقط وقتی مدل نیازی نداره به اون فایلی که خونه و رفته دنبال مراحل بعدی کار، ما مجبور نیستیم هر بار کل اون فایل رو دوباره بفرستیم تو آرایه messages و تو کانتکست نگهش داریم.

🛠 Join @LLMEngineers Community

سه پروژه‌ی Pi و SoL-Pi و mini-swe-agent از سه مسیر متفاوت دنبال یک هدفن: کم‌کردن token مصرفی Coding Agent، بدون اینکه کارایی واقعی قربانی بشه.

پروژه‌ی Pi یک harness مینیمال و قابل‌گسترشه. ابزارهای پایه مثل خواندن و نوشتن فایل، جست‌وجو و اجرای shell commandها رو می‌ده، ولی planning، subagent و رفتارهای پیچیده‌تر رو به core تحمیل نمی‌کنه. این قابلیت‌ها رو می‌شه با Extension، Skill و Package اضافه کرد.

نکته‌ی مهم‌تر، مدیریت state و context در Piه. Sessionها به شکل JSONL ذخیره می‌شن، history ساختار درختی داره و با id و parentId می‌شه از یک نقطه branch گرفت. وقتی context بزرگ می‌شه، بخش‌های قدیمی‌تر compact می‌شن و برای پاسخ بعدی فضا باقی می‌مونه.

پروژه‌ی SoL-Pi ساخت Nvidia هست و به عنوان extension روی Pi ساخته شده و تمرکزش روی ارزmن‌ترکردن trajectoryهای طولانیه. چند ایده‌ی اصلی‌اش این‌ها هستن:

ایده‌ی Action Fusion: بعد از edit، تست یا command قابل‌پیش‌بینی رو بدون یک model call اضافه اجرا می‌کنه.
ایده‌ی ObservationPack:لاگ های بزرگ رو در archive محلی نگه می‌داره و هر بار کل‌شون رو دوباره به مدل نمی‌فرسته.
ایده‌ی Online Context Compact: هیستوری رو در مرزهای منطقی subtask compact می‌کنه، نه فقط وقتی context تقریباً پر شده.
ایده‌ی Evidence-Preserving Reducer: لاگ های طولانی رو با یک مدل ارزان‌تر بررسی می‌کنه، ولی evidence استخراج‌شده رو با log اصلی تطبیق می‌ده.
نتیجه‌ی EdgeBench جالبه: SoL-Pi حدود ۹۴٪ امتیاز میانگین Pi رو حفظ کرده، با ۴۵ تا ۴۹٪ مصرف توکن کمتر.

پروژه‌ی mini-swe-agent از مسیر مخالف می‌ره: کم‌کردن abstraction تا جای ممکن. Agent اصلی تقریباً یک loop سادس. پیام رو به مدل می‌ده، command پیشنهادی رو اجرا می‌کنه، observation رو به history اضافه می‌کنه و دوباره ادامه می‌ده.

قابلیت اصلی اینجا عملاً bashه. مدل با کامند های معمولی repository رو می‌خونه، فایل تغییر می‌ده، تست اجرا می‌کنه و Git رو صدا می‌زنه. خبری از یک مجموعه‌ی بزرگ ابزارهای اختصاصی برای navigation و editing نیست.

تاریخچه در mini-swe-agent عمدتاً linearه. این طراحی شاید از session treeهای Pi ساده‌تر باشه، ولی برای debugging، Evals، fine-tuning و RL مزیت مهمی داره: trajectory راحت‌تر بررسی می‌شه و رفتار پنهان کمتری بین مدل و environment قرار می‌گیره.

خلاصه‌اش اینه:

گزینه‌ی اول، Pi: وقتی harness قابل‌برنامه‌ریزی و session management می‌خوای.
گزینه‌ی دوم، SoL-Pi: وقتی می‌خوای context، observation و model callهای اضافه رو در Pi کم کنی.
گزینه‌ی سوم، mini-swe-agent: وقتی سادگی، observability و یک مسیر مستقیم تا shell برات مهم‌تره.
مسیر این سه پروژه فرق داره، ولی سؤال یکیه: از چه نقطه‌ای به بعد، هر feature جدید فقط token، latency و پیچیدگی اضافه می‌کنه؟

🛠 Join @LLMEngineers Community