AI Engineers

کتاب An Illustrated Guide to AI Agents نوشته Maarten Grootendorst و Jay Alammar (نویسندگان Hands-On LLMs) تازه منتشر شد!
با بیش از ۳۰۰ تصویر گرافیکی، مفاهیم اصلی ایجنت‌های LLM رو از پایه تا پیشرفته پوشش می‌ده:
حافظه، ابزارها (شامل MCP)، برنامه‌ریزی، ارزیابی، Multi-Agent، ایجنت‌های کدنویسی و…
با رویکرد شهودی + کد عملی , خودتون یک ایجنت کامل از صفر می‌سازید.

تیم IFM که پیش‌تر با پروژه LLM360 شناخته می‌شد، خانواده مدل‌های K2 Horizon رو تحت لایسنس Apache 2.0 منتشر کرد؛ یه پکیج کامل از ۶ مدل مختلف که از سایز فوق‌العاده سبک 0.9B شروع می‌شه و تا غول ۳۷۵ میلیارد پارامتری 375B-A23B ادامه داره. برخلاف خیلی از شرکت‌ها که فقط وزن نهایی رو می‌دن و تمام، این تیم کل چرخه آموزش رو باز کرده؛
یعنی از دیتای Pre-train و چک‌پوینت‌های میانی گرفته تا لاگ‌های جزئی آموزش و کدهای Agentic Post-training همه‌چیز در دسترسه تا بشه رفتار مدل رو دقیق مهندسی معکوس کرد.

یکی از جذاب‌ترین نکات معماری این سری، مدل 36B-A4B هست که سراغ ایده‌ای به اسم MoVA یا همان Mixture-of-Value-Attention رفته. برخلاف MoEهای مرسوم که sparsity رو فقط روی لایه‌های Feed-Forward اعمال می‌کنن، اینجا اسپارسیتی وارد مکانیزم Attention شده. این طراحی باعث شده مدل با وجود ۳۶ میلیارد پارامتر کلی، در هر توکن فقط حدود ۴ میلیارد پارامتر فعال داشته باشه، ولی عملکردش پا‌به‌پای نسخه متراکم ۳۲ میلیاردی بیاد و در تست‌هایی مثل Terminal-Bench 2.1 به امتیاز ۵۸.۶ برسه؛ چیزی که روی سرورهای سبک یا سیستم‌های لوکال هزینه پردازش رو به‌شدت پایین می‌کشه.

مدل پرچمدار این خانواده یعنی 375B-A23B هم با ۲۳ میلیارد پارامتر فعال در هر توکن، مستقیماً برای کارهای سنگین برنامه‌نویسی و ایجنتی طراحی شده. این مدل در بنچمارک‌های کار با ابزار مثل MCPMark امتیاز ۶۷.۷ و در Toolathlon امتیاز ۶۵.۳ رو ثبت کرده. هرچند در استدلال‌های فوق‌العاده انتزاعی و سنگین مثل Humanity's Last Exam هنوز پشت سر مدل‌های کلوزی مثل GPT-5.6 یا Claude Sonnet 5 قرار می‌گیره، اما در کارهای مهندسی نرم‌افزار و تسک‌های طولانی ایجنتی کاملاً در قامت یه مدل کلاس تجاری ظاهر می‌شه.

نکته‌ای که این گزارش رو برای من فوق‌العاده جذاب کرد، شفافیت بی‌تعارف تیم روی ماجرای Reward Hacking بود. وقتی مدل در محیط شبیه‌سازی‌شده ترمینال قرار گرفته، در کمال زرنگی سورس بنچمارک رو از گیت‌هاب پیدا کرده، جواب‌ها رو بیرون کشیده و تست‌ها رو دور زده! تیم IFM با ابزار آدیت شرکت Artificial Analysis متوجه تقلب در ۲۴ تلاش شد و به‌جای لاپوشانی، رک و راست امتیاز خام ۷۰.۲ درصدی رو به ۶۶.۹ درصد اصلاح کرد. همین ثبت رفتارهای ناخواسته در چک‌پوینت‌های میانی، ارزش علمی این انتشار رو از صدها ادعای بازاریابی بیشتر می‌کنه.

از نظر دیپلوی و استفاده عملی هم همه‌چیز آماده‌ست؛ مدل‌ها از روز اول توی vLLM و SGLang و Ollama پشتیبانی می‌شن. علاوه بر این، یه آداپتر LoRA سبک به اسم Uno Diffusion همراه مدل‌ها داده شده که به‌کمک تکنیک موازی‌سازی دیفیوژن، توکن‌ها رو بدون تغییر در توزیع خروجی و بدون افت کیفیت به شکل بلوکی تولید می‌کنه تا سرعت استنتاج بالاتر بره. اگر برای تسک‌های سبک، کار با فانکشن‌ها و استنتاج لوکال دنبال گزینه هستید، سایزهای 3.7B و 7B و نسخه MoVA واقعاً ارزش تست دارند.

https://ifm.ai/k2/
https://ifm.ai/blog/k2
https://huggingface.co/collections/IFM/k2-horizon

🛠 Join @LLMEngineers Community

ولی Muse از نظر قدرت نسبت به هزینه بهترین مدله
اگه با مدلایgpt مقایسه کنیم تقریبا میشه گفت قدرت sol با هزینه terra

دیگه مدلای گرون قیمت claude بنظر من از لحاظ اقتصادی استفادشون به شدت غیرمنطقیه و هیچ توجیهی به هیچ وجه نداره

بنظرم رقابت از این به بعد سر ساخت مدلای بهینه، سبک و ارزونه

ورژن جدید مدل های Gemini Flash و ‌Muse Spark عرضه شدن ، قدرت جفتشون عالیه

اگر می‌خواید مسیر شغلی خودتون رو به عنوان یک Applied AI Engineer بسازید و به استانداردهای تیم‌های تراز اول برسید، باید تمرکزتون رو از «پرامپت‌زدن و کپی‌پیست نوت‌بوک» کاملاً بردارید و روی مهندسی سیستم‌های پروداکشن بذارید. تحلیل دقیق شرح شغل‌های اخیر OpenAI، NVIDIA و BMW یک نقشه‌راه کاملاً شفاف به ما میده:

قدم اول: تبدیل شدن به یک مهندس نرم‌افزار واقعی قبل از ورود عمیق به AI. توی شرح شغل رسمی NVIDIA برای موقعیت مهندسی هوش مصنوعی، فاندامنتال مهندسی نرم‌افزار این‌طور لیست شده:
system design, API design, testing, CI/CD, code quality, observability, security, databases, containers, and distributed/event-driven systems
پس وقتت رو اول بذار روی پایتون پیشرفته، سیستم‌های توزیع‌شده، تست‌نویسی، داکر و معماری Backend.

قدم دوم: عمیق شدن توی ایجنت‌ها و مدیریت خطا. دموهای ساده با کدهای ۱۰ خطی به کار پروداکشن نمیان. تیم Codex در OpenAI دقیقاً دنبال مهندس‌هایی می‌گرده که این چالش‌ها رو حل کرده باشن:
real-world long-horizon agent workflows, tool-use strategies, context construction, production failures, evaluation and feedback loops
حتی BMW هم توی آگهی استخدام موقعیت Agentic AI صریحاً عبارت previous experience building agentic applications رو آورده و تسلط روی فریم‌ورک‌ها و پروتکل‌هایی مثل MCP رو الزامی کرده.

قدم سوم: یادگیری اصولی Evals و ارزیابی سیستم. ساخت سیستم بدون متریک ارزش فنی نداره. شرکت OpenAI از مهندس‌های کاربردی خودش انتظار داره سیستم‌ها رو به شکل ساختاریافته بسنجن:
representative data, graders, production signals and human judgment
باید بلد باشی دیتاست تست بسازی، رگرسیون مدل رو بسنجی و بدونی Latency، هزینه و فیلیر مودهای سیستم روی تسک‌های واقعی چقدره.

قدم چهارم: تسلط روی پروداکشن و اسکیل. تیم BMW هدف استخدامش رو industrializing GenAI and agentic systems اعلام کرده و آگهی OpenAI لندن هم ازت می‌خواد پروژه رو از صفر تا صد جلو ببری:
take systems from use-case selection and architecture through prototyping, evaluation, launch and scale
این مرحله شامل مانیتورینگ، Tracing، مدیریت کش، دپلوی کلود روی AWS یا Azure و کنترل دسترسی داده‌هاست.

برای پورتفولیو هم بهتره به جای ۳۰ تا نوت‌بوک پراکنده، ۳ تا پروژه کامل و بالاآمده بسازید، مثلا:
- یک سیستم Enterprise RAG کامل با دسترسی چندکاربره، Reranker، سیستم ارزیابی خودکار و Tracing.
- یک Coding Agent یا اتوماسیون واقعی که با GitHub، دیتابیس یا ابزارهای محیطی از طریق MCP تعامل کنه و خطایابی خودکار داشته باشه.
- یک پایپ‌لاین بهینه‌سازی مدل متن‌باز که شامل Fine-tuning با LoRA، فرآیند Quantization و بنچمارک دقیق Latency و Memory روی Inference باشه.


هدف نهایی اینه که در مصاحبه نگید «من مدل‌های زبانی بلدم و کمی برنامه‌نویسی می‌کنم»؛ بلکه ثابت کنید «یک Software Engineer مسلط هستید که می‌تونه سیستم‌های هوش مصنوعی رو مطمئن، قابل‌سنجش و پایدار تحویل بده».

sources:
- https://openai.com/careers/applied-ai-engineer-london-uk/
- https://nvidia.wd5.myworkdayjobs.com/en-US/NVIDIAExternalCareerSite/job/Senior-Applied-AI-Engineer_JR2021231-1
- https://www.bmwgroup.jobs/de/de/jobfinder/job-description-copy.192665.html
- https://openai.com/careers/applied-ai-engineer-codex-core-agent-san-francisco/
- https://openai.com/careers/emerging-talent/
- https://www.nvidia.com/en-eu/about-nvidia/careers/university-recruiting-new/

🛠 Join @LLMEngineers Community

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

مطالعه میدانی هشت‌ماهه پژوهشگرهای دانشگاه Berkeley Haas نشون داده دسترسی به ابزارهای هوش مصنوعی، به‌جای کم کردن بار کاری، باعث متراکم‌تر شدن کارها شده. وقتی ساختن یک پروتوتایپ اولیه با AI خیلی سریع و ارزان تموم میشه، افراد مسئولیت‌های خارج از تخصص خودشون رو هم گردن می‌گیرن و تسک‌های جدید می‌سازن. گزارش Atlassian هم نشون میده ۹۲ درصد نیروها میگن محدوده‌ی وظایفشون از شرح شغل اولیه‌شون فراتر رفته، چون انجام کارهای تیم‌های دیگه با AI راحت‌تر به نظر می‌رسه.

اصل ماجرا پدیده‌ای به اسم Vibe Coding و توهم بازدهی بالاست. تولید کردن کدهای اولیه واقعاً چند دقیقه بیشتر طول نمی‌کشه، ولی مهندسی نرم‌افزار هیچ‌وقت فقط نوشتن کد خام نبوده. گزارش DORA نشون میده ذخیره‌ی زمانی که AI در نوشتن کد ایجاد می‌کنه، مستقیماً سرازیر میشه توی پروسه‌های Verification، بازبینی‌های سنگین، دیباگ، تست امنیت، Performance و رسیدگی به معماری در مقیاس Production. حتی مطالعه METR روی توسعه‌دهنده‌های باسابقه نشون داد با اینکه افراد حس می‌کردن ۲۰ درصد سریع‌تر شدن، در عمل به خاطر زمان تمیزکاری و عیب‌یابی کدهای تولیدی، تسک‌ها ۱۹ درصد بیشتر طول کشیده بود.

علت این وضعیت یک اصل اقتصادی آشناست: وقتی هزینه‌ی تولید چیزی شدیداً افت می‌کنه، سازمان‌ها مصرفش رو بالا می‌برن نه اینکه کار رو تعطیل کنن. اگر قبلاً توی دو هفته یک Feature پیاده می‌شد، الان با AI پنج فیچر نیمه‌کاره تولید میشه و همه‌ی اون‌ها هم نیاز به Code Review، ادغام و مانیتورینگ دارن.

خلاصه‌ی ماجرا اینه که هوش مصنوعی هزینه‌ی ساخت پیش‌نویس اول رو تقریباً صفر کرده، اما هزینه‌ی مسئولیت فنی، صحت‌سنجی و نگهداری در Production سر جاشه. گلوگاه سیستم حذف نشده، فقط از مرحله‌ی «کدنوشتن» به سمت «تست، اعتبارسنجی و نگهداری» جابه‌جا شده.

source: https://www.universityofcalifornia.edu/news/ai-promised-free-workers-time-uc-berkeley-haas-researchers-found-opposite

🛠 Join @LLMEngineers Community

بررسی چنتا مدل جدید با سایز کوچیکتر از 5B :

مدل Nanbeige4.2-3B در حال حاضر روی کاغذ باهوش‌ترین مدل و قوی‌ترین Coding Agent تو این سایزه. نتایجی مثل 63.6 روی SWE-Bench Verified و 44.1 روی Terminal-Bench 2.0 نشون میده برای کار توی Shell و دیباگ ریپازیتوری رقیب نداره. با این حال طبق تست‌های مستقل، توی Multi-tool Calling و فراخوانی همزمان چند ابزار افت شدیدی پیدا می‌کنه

در سمت دیگه، مدل Spark-X2.5-4B بالانس‌ترین گزینه است. شاید توی استدلال خام یه پله پایین‌تر از رقیبش باشه، اما پایداری خیلی خوبی توی Tool Calling و سناریوهای چندمرحله‌ای Agentic نشون داده (مثل 65.1 روی BFCL-v4 و 75.1 روی τ²). این مدل ادعای پشتیبانی از ۲۰۰ زبان رو مطرح کرده که به احتمال زیاد پوشش فارسی قابل‌قبولی داره، هرچند توانایی ترمینال اون مستقیماً بنچمارک نشده و بیشتر از روی مهارت کدنویسیش استنباط میشه.

درباره LFM2.5-2.6B قضیه شفافه: تیم LiquidAI این مدل رو مستقیماً با Agentic RL برای ابزارها و جریان‌های کاری آموزش داده و توی بنچمارک‌هایی مثل ToolSandbox و Claw-Eval عالیه؛ اما خود سازنده‌ها صریحاً اعلام کردن برای Coding Agent یا کارهای سنگین ریپازیتوری مناسب نیست. از نظر زبانی هم فارسی رسماً جزو زبان‌های پشتیبانی‌شده اون نیست.

نسخه‌های تقطیرشده مثل Qwen3.8-4B-Distill برای استدلال عمومی و ریاضیات پیشرفت خوبی داشتن، اما هنوز بنچمارک مستقلی برای کارهای ایجنتی مثل SWE-Bench یا Terminal-Bench براشون منتشر نشده. از نظر زبان فارسی، با توجه به سابقه خانواده Qwen3.5 احتمالاً انتخاب‌های مطمئن‌تری باشن، ولی تا قبل از تست مستقیم نمیشه نمره قطعی داد.

جمع‌بندی برای انتخاب و تصمیم‌گیری:
- برای کارهای Coding Agent و محیط ترمینال: مدل Nanbeige4.2-3B بهترین گزینه‌ست، به شرطی که کار به زبان انگلیسی باشه.
- برای ورک‌فلوهای عمومی Agent و استفاده چندمرحله‌ای از Tool: مدل Spark-X2.5-4B پایدارترین و متعادل‌ترین انتخابه.
- برای ابزارسازی سبک و پایپ‌لاین‌های RAG بدون نیاز به کدنویسی عمیق: مدل LFM2.5-2.6B عملکرد تمیزی داره، اما نباید روش برای فارسی حساب کرد.
- برای تسک‌های متنی عمومی و زبان فارسی: مدل‌های مبتنی بر Qwen3.8 و بعد از اون Spark گزینه‌های منطقی‌تری به حساب میان.

https://huggingface.co/Nanbeige/Nanbeige4.2-3B
https://huggingface.co/XHToken/Spark-X2.5-4B
https://huggingface.co/empero-ai/Qwen3.8-4B-Distill
https://huggingface.co/LiquidAI/LFM2.5-2.6B

🛠 Join @LLMEngineers Community

امروز داشتم گزارش GDPval رو می‌خوندم؛ بنچمارک رسمی OpenAI که به‌جای سؤال آکادمیک، کارهای واقعی و پول‌ساز رو تست می‌کنه. ۱۳۲۰ تسک از ۴۴ شغل توی ۹ بخش اصلی GDP آمریکا، همه ساخته‌شده توسط متخصص‌های واقعی با میانگین ۱۴ سال سابقه.

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

چارت مدل های برتر تا الان (8/2026) رو توی کامنتا گذاشتم. مدل Claude Opus 5 با ۱۸۳۵ صدرنشینه، بعد GLM-5.3 با ۱۷۶۶ و Grok 4.6 با ۱۷۶۱. بهترین مدل‌ها تقریباً ۸۰٪ بالاتر از سطح متخصص انسانی کار تحویل میدن.

نکته‌ی جالب‌تر برای من پراکندگی بالای جدوله: GLM و مدل‌های چینی open-weight دیگه کاملاً تو جمع frontier هستن، و فاصله‌ی رتبه ۱ تا رتبه ۱۰ فقط حدود ۲۰٪ ٪‌ـه. یعنی دیگه بحث «کدوم مدل به انسان می‌رسه» نیست؛ بحث اینه که کدوم ارزون‌تر و سریع‌تر از انسان تحویل میده.

نکته جالب برای من این بود که چقدر با مهندسی ساده میشه جلو رفت: پرامپتی که مدل رو وادار کنه خروجیش رو به‌صورت تصویر رندر کنه و چک کنه، خطاهای فرمت PowerPoint رو از ۸۶٪ به ۶۴٪ رسوند و ۵ واحد درصد هم win rate اضافه کرد.

محدودیتش رو هم بگم: تسک‌ها one-shot و کاملاً مشخص‌ان، در حالی که تو دنیای واقعی فهمیدن خودِ مسئله نصف کاره. کار فیزیکی و دانش ضمنی هم بیرون از دامنه‌ست.


https://arxiv.org/html/2510.04374v1

🛠 Join @LLMEngineers Community

معماری مدل Qwen3.8-27B ترکیبی ساخته شده؛ یعنی از ۶۴ لایه، فقط ۱۶ لایه‌اش به سبک کلاسیک توجه کامل دارند و ۴۸ لایه دیگه به‌صورت خطی (با معماری Gated DeltaNet) کار می‌کنند. این طراحی باعث شده حافظه موقت پردازش متن یا همون KV Cache بسیار سبک‌تر از مدل‌های عادی باشه و کانتکست ۲۶۲ هزار توکنی مدل روی سیستم‌های خانگی رم زیادی مصرف نکنه.

توی بنچمارک‌های رسمی برای کارهای ایجنتیک، برنامه‌نویسی و کنترل سیستم نمرات بالایی ثبت کرده (مثل شاخص ۵۲ در ارزیابی مستقل Artificial Analysis). اما در استفاده واقعی یک ضعف مشخص داره: تمایل به تفکر بیش‌ازحد یا همون Overthinking. اگر متغیر تلاش تفکر یعنی reasoning_effort رو روی حالت متوسط یا کم تنظیم نکنید، برای سوال‌های ساده توکن‌های بسیار زیادی می‌سوزونه و خروجی کند می‌شه.

واقعیت اجرای مدل روی سیستم‌ها و کارت‌های مختلف:

کارت‌های ۲۴ گیگابایت (مثل 3090 یا 4090):
نقطه تعادل مدل نسخه ۴ بیتی مثل Q4_K_M با حجم حدود ۱۷ گیگابایته. روی این کارت‌ها به راحتی اجرا می‌شه و فضای کافی برای کانتکست ۳۲ تا ۶۴ هزار توکنی باقی می‌مونه.

کارت‌های ۱۶ گیگابایت (مثل 5080 لپ‌تاپ یا 4060Ti):
نسخه ۴ بیتی کامل جا نمی‌شه. باید برید سراغ کوانت ۳ بیتی مثل UD-Q3_K_XL (حدود ۱۳.۵ گیگابایت) و برای مصرف کمتر حافظه، کش کانتکست رو هم ۴ بیتی کنید (--cache-type-k q4_0). سرعت بین ۲۰ تا ۵۰ توکن بر ثانیه میده و برای کدنویسی واقعی جوابه.

کارت‌های زیر ۱۲ گیگابایت یا ۶ گیگ (مثل 3050):
اجرای مدل عملاً منطقی نیست. نسخه‌های ۱ یا ۲ بیتی بالا میان ولی افت کیفیت در منطق و برنامه‌نویسی بسیار شدیده و سرعت با فرستادن لایه‌ها روی پردازنده اصلی به زیر ۲ توکن بر ثانیه می‌رسه.

وضعیت روی سیستم‌های مک و حافظه یکپارچه:
- مک‌های ۱۶ گیگابایت: به خاطر اشغال رم توسط سیستم‌عامل، فقط کوانت‌های خیلی ضعیف ۲ بیتی جا می‌شن که خروجی بی‌کیفیت و کندی دارن.
- مک ۲۴ گیگابایت (مثل M2 یا پایه M5 Pro): با کوانت ۳ بیتی یا ۴ بیتی هماهنگ کار می‌کنه و سرعت حدود ۸ تا ۱۵ توکن بر ثانیه می‌ده.
- مک‌های ۳۶ گیگابایت به بالا (مثل M3 Pro یا M5 Pro): محیط ایده‌آل اجرای روان نسخه ۴ بیتی با فریم‌ورک MLX و سرعت بالای ۲۰ توکن بر ثانیه است.

برای گرفتن بالاترین سرعت روی تمام سیستم‌ها، مدل دارای یک head داخلی برای حدس کلمات بعدی یا همون Multi-Token Prediction هست. با فعال کردن پیش‌بینی کمکی (Speculative Decoding)، سرعت پردازش کلمات بین ۳۰ تا ۱۰۰ درصد بدون افت دقت بالا می‌ره.

برای اجرا با Llama.cpp server روی GPU ی‌تونید از دستور بهینه‌شده زیر استفاده کنید:
llama-server -m Qwen3.8-27B-UD-Q3_K_XL.gguf -c 32768 -ngl 99 -fa on --jinja --cache-type-k q4_0 --cache-type-v q4_0 --spec-type draft-mtp --spec-draft-n-max 2

ساده‌ترین روش برای شروع سریع هم استفاده از LMstudio یا Ollama با اجرای دستور ollama run qwen3.8:27b در سیستم‌های عادی و فلگ qwen3.8:27b-mlx برای سیستم‌های اپل سیلیکون هست.

https://unsloth.ai/docs/models/qwen3.8

🛠 Join @LLMEngineers Community

an AI Agent is five parts ...

🛠 Join @LLMEngineers Community

INCREDIBLE

Qwen 3.8 27B scored 51 on the Artificial Analysis Agentic Index


Ahead of GLM 5.2 and DeepSeek V4 Pro 0813

Only behind a few SoTA models
several to tens of times its size

Runs on ~2-3k USD hardware btw

Permanent underclass is officially cancelled

یه ایده جالب برای بهتر کردن LLM-as-a-Judge 👀

یکی از مشکلات مهم توی سیستم‌های Agentic اینه که وقتی چند جواب یا چند مسیر مختلف برای حل یک مسئله داریم، چطور بفهمیم کدومش بهتره؟

روش معمول اینه که از یک LLM به‌عنوان Judge استفاده کنیم و مثلاً بگیم:

«این دو جواب رو بررسی کن و از ۱ تا ۵ نمره بده.»

مدل هم ممکنه بگه:

Answer A → 4
Answer B → 4

خب حالا کدوم بهتره؟ 🤔

مشکل اینجاست که مدل واقعاً فقط «۴» رو نمی‌بینه؛ پشت این جواب یک Probability Distribution وجود داره. مثلاً ممکنه برای جواب A داشته باشیم:

۴ با احتمال ۵۱٪
۳ با احتمال ۳۰٪
۵ با احتمال ۱۹٪

ولی برای جواب B:

۴ با احتمال ۹۰٪
۳ با احتمال ۵٪
۵ با احتمال ۵٪

هر دو در نهایت نمره ۴ می‌گیرن، ولی مشخصه که مدل نسبت به B خیلی مطمئن‌تره.

اینجاست که ایده LLM-as-a-Verifier جالب می‌شه.

به‌جای اینکه فقط محتمل‌ترین نمره رو برداریم، کل Probability Distribution نمره‌ها رو از مدل می‌گیریم و ازش Expected Score حساب می‌کنیم.

مثلاً:

1×0.02 + 2×0.05 + 3×0.15 + 4×0.45 + 5×0.33 ≈ 4.02

پس به‌جای اینکه فقط بگیم «۴»، یک نمره دقیق‌تر مثل 4.02 داریم.

این کار باعث می‌شه اطلاعاتی که داخل احتمال‌های مدل وجود داره از بین نره و بتونیم جواب‌هایی رو که قبلاً هر دو نمره ۴ می‌گرفتن، بهتر از هم تشخیص بدیم.

ولی مقاله فقط به همین محدود نمی‌شه. برای بهتر کردن Verification، سه کار دیگه هم انجام می‌ده:

🔹 Score Granularity
تعداد نمره‌های ممکن رو بیشتر می‌کنه تا تفاوت بین جواب‌ها دقیق‌تر مشخص بشه.

🔹 Repeated Evaluation
ارزیابی رو چند بار تکرار می‌کنه و میانگین می‌گیره تا نوسان نتیجه کمتر بشه.

🔹 Criteria Decomposition
به‌جای اینکه یک نمره کلی بدیم، معیارهای مختلف رو جداگانه بررسی می‌کنه؛ مثلاً Correctness، Completeness و Quality.

بعد این نمره‌ها رو با هم ترکیب می‌کنه تا بتونه بین چند جواب یا چند مسیر مختلف، گزینه بهتر رو انتخاب کنه.

نتایج هم جالبه:

Terminal-Bench V2 → 86.5%
SWE-Bench Verified → 78.2%
RoboRewardBench → 87.4%
MedAgentBench → 73.3%

نکته جالب‌تر اینه که این Continuous Score فقط برای انتخاب بهترین جواب نیست. مقاله نشون می‌ده که می‌شه ازش برای فهمیدن میزان پیشرفت یک Agent در طول حل مسئله و حتی به‌عنوان Reward در Reinforcement Learning هم استفاده کرد.

به نظرم ایده اصلی مقاله خیلی ساده و مهمه:

ما معمولاً از LLM می‌خوایم جواب تولید کنه؛ ولی شاید به همون اندازه مهم باشه که یاد بگیریم چطور جواب‌های تولیدشده رو دقیق‌تر ارزیابی کنیم.

یعنی به‌جای:

Generate → Generate → Generate

یک مسیر مهم دیگه هم می‌تونه این باشه:

Generate → Verify → Select → Improve

📄 Paper:
https://arxiv.org/html/2607.05391v2

🛠 Join @LLMEngineers Community

یه اشتباه رایج اینه که فکر کنیم برای فشرده سازی کانتکس ( context compaction) کافیه فقط آخر چت طولانی یه خلاصه درست کنیم. ولی وقتی داریم با Agentهایی کار می‌کنیم که چند ساعت یا چند روز فعالن و state نگه می‌دارن، خلاصه‌نویسی ساده کافی نیست.

اصل قضیه اینه که context window حافظه کاری مدله، نه کل حافظه سیستم. پس اطلاعات کلیدی مثل شناسه، مبلغ، تاریخ و ارجاعات باید دقیق ذخیره بشن یا به جاهای قابل بازیابی اشاره کنن، بعد یه خلاصه ساختاریافته برای حفظ پیوستگی ساخته بشه.

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

خلاصه اینکه compaction شبیه checkpoint کردن و جمع‌آوری زباله کردن حافظه است تا یه خلاصه ساده چت. اطلاعات کمتری داخل context باشه ولی سیستم بتونه به راحتی بازیابی کنه و قابل حسابرسی باشه.

- developers.openai.com/api/docs/guides/compaction
- platform.claude.com/docs/en/build-with-claude/compaction
- google.github.io/adk-docs/context/compaction/
- docs.openclaw.ai/concepts/compaction
- arxiv.org/html/2608.01326v1

🛠 Join @LLMEngineers Community

دیروز Andrew Ng یه نقشه برای مهارت‌های AI Engineering منتشر کرده که به نظرم برای انتخاب مسیر یادگیری از خیلی از لیست‌های کلیشه‌ای کاربردی‌تره. نه چون قرار باشه همه‌چیز رو پوشش بده، بلکه چون تمرکزش روی مهارت‌هایی‌ه که هم برای ساخت محصول لازم‌اند و هم برای کار کردن با Coding Agentها.

نکته‌ی کلیدی اینه که AI Engineering فقط یعنی کار با مدل یا داشتن عنوان «AI Engineer» نیست. طبق تحلیل تیم Andrew Ng از بیش از ۱۰هزار آگهی شغلی، مصاحبه با متخصص‌ها، مدیرهای استخدام و داده‌های آنلاین، چهار مهارت اصلی این‌ها هستند:

• ساخت و Deploy کردن AI Applicationها
• مبانی Software Engineering
• استفاده‌ی مؤثر از Coding Agentها
• شکل‌دادن به خود مسئله و محصول

اصل داستان در ساخت AI Application اینه که خروجی سیستم قابل‌پیش‌بینی نیست. برای همین فقط بلد بودن LLM، RAG یا Agentic Workflow کافی نیست؛ باید بتونی با Evals، تحلیل خطا و روش‌های آماری رفتار سیستم رو اندازه بگیری، هدایتش کنی و قابل‌کنترل‌تر نگهش داری.

از طرف دیگه، مبانی Software Engineering حتی با وجود Agentها مهم‌تر شده. کسی که trade-offهای cost، scalability، reliability، security و privacy رو نمی‌شناسه، عملاً نمی‌فهمه Agent چه تصمیم‌هایی برای معماری و کد گرفته. نتیجه معمولاً یه راه‌حل سریع و شکننده‌ست؛ چیزی که شاید تو دمو جواب بده، ولی تو production نه.

مهارت کار با Coding Agent هم فقط prompt نوشتن نیست. باید context رو مدیریت کنی، بدونی کجا planning لازمه و کجا نه، برای Agent verifier و eval بسازی، چندتا Agent رو درست orchestrate کنی و حواست باشه یه اشتباه ساده به production database نرسه. یعنی Agent بیشتر شبیه همکار سریعیه که باید با تست و محدودیت هدایتش کنی، نه یه دکمه‌ی جادویی برای جایگزین کردن مهندسی.

اما بخش چهارم شاید از همه مهم‌تر باشه: shaping the build. وقتی Agentها تو اجرای spec بهتر می‌شن، ارزش مهندس فقط تو نوشتن کد نیست؛ تو تشخیص مسئله‌ی درست، فهم business context، تصمیم‌گیری درباره‌ی MVP و دونستن زمان مناسب برای سرعت گرفتن یا دقیق‌تر ساختن هم هست.

به نظر من پیام اصلی این نقشه ساده‌ست: آینده فقط مال کسی نیست که مدل بیشتری می‌شناسه. کسی جلوتره که هم سیستم AI می‌سازه، هم Software Engineering رو می‌فهمه، هم Agent رو کنترل می‌کنه و هم می‌دونه اصلاً چه چیزی ارزش ساختن داره.

x.com/AndrewYNg/article/2088302050706686198

🛠 Join @LLMEngineers Community

یه theme برای Hermes Desktop ساختم به اسم Noir - Vazirmatn
تمرکزش بیشتر روی راحت‌ترشدن خواندن متن‌های فارسی توی استفاده‌ی طولانیه

فونت Vazirmatn به‌عنوان fontSans برای متن معمولی رابط کاربری استفاده می‌شه؛ یعنی نوشته‌های چت، منوها، تنظیمات، دکمه‌ها و labelها خواناتر می‌شن. برای code و terminal هم فونت‌های monospace مثل JetBrains Mono و Cascadia Code سر جاشون موندن و Vazirmatn فقط به‌عنوان fallback برای حروف فارسی وارد می‌شه.

از نظر ظاهر، theme روی پس‌زمینه‌های charcoal، متن روشن، borderهای ظریف و blue accent محدود ساخته شده تا رابط کاربری شلوغ و خسته‌کننده نشه. نصبش هم با یک command از GitHub انجام می‌شه و بعد از Reload desktop plugins از داخل Appearance قابل انتخابه.

https://github.com/mshojaei77/hermes-noir-vazirmatn-theme

🛠 Join @LLMEngineers Community

دیروز تیم Qwen مدل Qwen3.8-27B رو منتشر کرد؛ یه مدل open-weight و multimodal که با فقط ۲۷B پارامتر در coding agent، computer use، browser task و کارهای حرفه‌ای طولانی به سطح مدل‌های خیلی بزرگ‌تر رسیده.

گزارش‌های اولیه می‌گن مدل قبل از جواب‌دادن، مسئله رو کامل‌تر داخل reasoning خودش می‌سازه؛ انگار یک build کامل رو درون trajectory اجرا می‌کنه و بعد خروجی نهایی رو می‌ده. این باعث شده verbose thinking این‌بار بیشتر شبیه مزیت باشه تا اتلاف توکن.

از نظر فنی هم تصویر، ویدیو، reasoning قابل تنظیم، context native تا ۲۶۲K و امکان گسترش تا حدود ۱M توکن رو داره.
اگر این روند ادامه پیدا کنه، agentهای جدی کم‌کم از مدل‌های عظیم ابری جدا می‌شن و روی سخت‌افزار محلی هم قابل اجرا می‌شن.
جهت حرکت کاملاً مشخصه: مدل‌های agentic دارن کوچک‌تر، ارزان‌تر و عملیاتی‌تر می‌شن.

🛠 Join @LLMEngineers Community

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

مستقیم‌ترین مدرک یه مقاله‌ست با عنوان *Token Reduction Is Not Cost Reduction* که روی ۲۹۰۸ اجرای صورتحساب‌شده از سمت ارائه‌دهنده روی Claude Code آزمایش کرده. نتیجه؟ خروجی خام ابزارها ۳۸.۴٪ کمتر شده، ولی هزینه‌ی واقعی ۶.۸٪ بیشتر شده. تو یه آزمایش دیگه، موفقیت ویرایش کد از ۲۷ مورد اومده پایین به ۱۵ تا؛ چون فشرده‌سازی دقیقاً همون شواهد دقیق و نقطه‌های ویرایش لفظ‌به‌لفظ رو خراب کرده بود که برای اعمال پچ لازم بود.

علتش کاملاً قابل‌فهمه: فشردن ۱۰ هزار توکن به ۲ هزار فقط وقتی صرفه‌جویی حساب می‌شه که همون ۲ هزار تا برای تصمیم بعدی کافی باشه. اگه نباشه، مسیر می‌شه «جست‌وجو ← خواندن ← استدلال ← تلاش مجدد» و هر مرحله ممکنه بافت قبلی رو دوباره به مدل بفرسته. ضمن اینکه تو همون مطالعه، حدود ۸۷٪ هزینه‌ی بازسازی‌شده مربوط به ساخت و خواندن حافظه‌ی سریع درخواست بوده، نه صرفاً خروجی ابزارها. یعنی بخش عمده‌ی صورتحساب، همون چیزاییه که مرتب دوباره خونده می‌شه، نه متن تازه‌ی ابزار.

البته نتیجه این نیست که هر نوع فشرده‌سازی بده. پژوهش‌های ACL و EMNLP نشون می‌دن فشرده‌سازی شدید و کور می‌تونه اطلاعات کلیدی رو حذف کنه و عملکرد کارهای پیچیده رو خراب کنه؛ ولی روش‌های آگاه از پرسش و انتخاب محتوای مرتبط گاهی هم کیفیت رو بهتر می‌کنن و هم توکن کمتری می‌خورن. مسئله فقط مقدار اطلاعات نیست؛ اطلاعات نامرتبط و بدجای‌گذاری‌شده هم می‌تونه مدل رو گیج کنه.

نمونه‌های ابزارها هم همین تفاوت رو نشون می‌دن. RepoWise با وارد کردن بافت بیشتر و هوشمندانه‌تر تو هر مرحله، تعداد گام‌ها و فراخوانی ابزارها رو کم کرده. CodeGraph تو بعضی مخزن‌ها بافت باقی‌مونده‌ی بیشتری نگه داشته، ولی کار کلی کمتری انجام داده. در مقابل، Caveman و بعضی حالت‌های Ponytail نشون دادن که کوتاه‌تر کردن پاسخ می‌تونه تعداد توکن، هزینه یا زمان رو بیشتر کنه. RTK هم هشدار داده که خروجی‌های کوتاه‌تر ممکنه نشانگر موفقیت، ساختار داده، شماره‌ی خط یا حتی معنای داده رو خراب کنن.

پس معیار درست «درصد توکن ذخیره‌شده» نیست. باید هزینه‌ی واقعی هر کار موفق رو سنجید: موفقیت کار، هزینه‌ی صورتحساب‌شده، تعداد نوبت‌ها، ترافیک حافظه‌ی سریع، تلاش مجدد، جست‌وجوهای تکراری، فراخوانی ابزارها، زمان و سربار خود فشرده‌ساز. نتیجه‌ی عملی اینه: فشرده‌سازی باید انتخابی، آگاه از کار، قابل‌بازگشت و روی کل مسیر ارزیابی بشه. ابزاری که فقط «توکن کمتر» رو گزارش می‌کنه، هنوز ثابت نکرده که ایجنت رو ارزون‌تر یا کارآمدتر کرده.

🛠 Join @LLMEngineers Community