مفهوم Prompt Engineering دیگه داره به پایان عمرش می‌رسه و جای خودش رو به Loop Engineering میده. به جای اینکه دستی برای ایجنت پرامپت بنویسید، خروجی بگیرید و ارورها رو دوباره به خورد مدل بدید، یک سیستم طراحی می‌کنید که خودش کار رو پیدا کنه، انجام بده، با ابزارهای واقعی تست کنه و در صورت خطا خودش رو اصلاح کنه. این تغییر پارادایم، باتل‌نک توسعه رو از سرعت تایپ انسان به طراحی سیستم‌های خودکار و مستقل منتقل کرده.

پیاده‌سازی لوپ‌ها روی کاغذ جذابه اما تو واقعیت به شدت پرهزینه است. یک لوپ ساده برای یک تسک برنامه‌نویسی می‌تونه به راحتی بین ۵۰ تا ۲۰۰ هزار توکن مصرف کنه. اگه محدودیت نذارید و از مدل‌های گرون‌قیمت استفاده کنید، تو چند روز کل بودجه API شما نابود میشه. دلیل اینکه این روزها پیاده‌سازی لوپ منطقی شده، ظهور مدل‌های ارزون‌قیمت با کانتکست بالا (مثل سری DeepSeek V4) هست که اجازه میدن ایجنت‌ها بدون نگرانی از هزینه، بارها خطا کنن و خودشون رو دیباگ کنن.

معماری یک لوپ مهندسی‌شده و پایدار از ۶ بخش اصلی تشکیل میشه که باید دقیق کنار هم چیده بشن:
بخش Automations: یک سیستم زمان‌بندی (کرون جاب یا هوک) که لوپ رو بیدار می‌کنه. به جای اجرای دستی، سیستم هر روز صبح ایشوها رو چک می‌کنه.
مفهوم Worktrees: وقتی چند ایجنت موازی کار می‌کنن، نباید فایل‌های هم رو خراب کنن. استفاده از قابلیت worktree تو گیت باعث میشه هر ایجنت تو دایرکتوری ایزوله خودش کار کنه.
فایل‌های Skills: ایجنت‌ها حافظه ندارن. باید فایل‌هایی مثل VISION.md یا SKILL.md تعریف بشه تا کانونشن‌های پروژه رو یک‌بار بخونن و هر بار از صفر شروع نکنن.
پروتکل Connectors: استفاده از MCP برای اتصال ایجنت به دنیای واقعی. ایجنت باید بتونه تیکت جیرا رو آپدیت کنه یا تو اسلک پیام بده، نه اینکه فقط روی فایل سیستم بچرخه.
معماری Sub-agents: مدلی که کد رو می‌نویسه، نباید خودش رو ارزیابی کنه. همیشه باید یک ایجنت برای تولید (Maker) و یک ایجنت ایزوله با دستورالعمل‌های سخت‌گیرانه‌تر برای تایید (Checker) داشته باشید.
مدیریت State: یک فایل ساده STATE.md که لاگ کارهای انجام شده و ارورها رو نگه می‌داره تا لوپ در اجرای بعدی بدونه کجا متوقف شده و دوباره از صفر اختراع نکنه.

بزرگترین اشتباه در ساخت لوپ، نبودن یک گیت اعتبارسنجی سفت و سخته. اگر معیار پایان کار، نظر خود ایجنت باشه، لوپ شما توهم می‌زنه و کار رو نصفه رها می‌کنه. یک لوپ واقعی به محض توقف، باید به صورت خودکار تست‌ها یا Linter رو اجرا کنه (مثلا با اجرای دستورات تست در پس‌زمینه). اگر خروجی خطا داشت، لاگ ارور به صورت خودکار به کانتکست برمی‌گرده و ایجنت مجبور به رفع اون میشه. برای جلوگیری از گیر کردن در لوپ بی‌نهایت، حتما باید یک Hard limit (مثلا حداکثر ۵ بار تلاش) براش تعریف بشه تا اگر نتونست حلش کنه، تسک رو به انسان بسپاره.

بدهی درک کد (Comprehension debt) خطرناک‌ترین عارضه این سیستمه. وقتی لوپ‌ها با سرعت بالا کد می‌زنن و مرج می‌کنن، فاصله بین چیزی که تو ریپو هست و چیزی که شما از معماری می‌فهمید به شدت زیاد میشه. این سیستم قرار نیست شما رو از چرخه مهندسی حذف کنه. اگر لوپ روی کدهای حساسی مثل منطق Auth یا سیستم پرداخت رها بشه، فاجعه امنیتی و منطقی به بار میاد. بهترین نقطه شروع، اتوماتیک کردن رسیدگی به خطاهای CI، آپدیت Dependencyها و رفع باگ‌های مشخص و تکراریه.

به نظر من، کسایی که هنوز دارن روی تکنیک‌های پرامپت‌نویسی وقت می‌ذارن، دارن روی مهارت اشتباهی سرمایه‌گذاری می‌کنن. طراحی لوپ‌های بسته (Closed Loops) که تسک‌های مشخص رو با ابزارهای تست خودکار هندل می‌کنن، چیزیه که تفاوت یک توسعه‌دهنده سینیور و یک کاربر ساده رو در آینده نزدیک مشخص می‌کنه. قبل از ساخت لوپ، مطمئن بشید که تسک شما حداقل هفته‌ای یک‌بار تکرار میشه و تست خودکار براش وجود داره، در غیر این صورت همون پرامپت زدن دستی کاملا منطقی‌تره.

🛠 Join @LLMEngineers Community

معماری Agent Skills در واقع یک فرمت استاندارد و سبک برای بسته‌بندی دانش تخصصی و جریان‌های کاری (Workflows) است تا ایجنت‌های هوشمند بتوانند فراتر از چت کردن ساده، کارهای واقعی و تکرارپذیر انجام دهند. مشکل اصلی ایجنت‌ها این است که مثل ماهی قرمز حافظه کوتاه‌مدت دارند و کانتکست پروژه را بین جلسات مختلف فراموش می‌کنند. استاندارد Agent Skills که توسط Anthropic معرفی شده، این دانش را در قالب یک پوشه شامل دستورالعمل‌ها، اسکریپت‌ها و فایل‌های مرجع پکیج می‌کند تا ایجنت هر بار چرخ را از اول اختراع نکند.

ساختار فنی یک Skill بسیار ساده و در عین حال قدرتمند است. یک پوشه حاوی فایل حیاتی SKILL.md که شامل Metadata (نام و توضیحات) و دستورالعمل‌های گام‌به‌گام است. در کنار آن، پوشه‌های اختیاری مثل scripts برای کدهای اجرایی پایتون یا بش، references برای مستندات فنی و assets برای تمپلیت‌ها قرار می‌گیرند. این یعنی شما دانش دامنه (Domain Expertise) خودتان را، مثلاً نحوه بازبینی کدهای امنیتی یا تحلیل داده‌های مالی، به صورت Version-controlled در کنار سورس‌کد پروژه نگه می‌دارید.

مکانیزم Progressive Disclosure یا افشای تدریجی، برگ برنده این استاندارد برای مدیریت هزینه و کانتکست است. ایجنت در مرحله اول (Discovery) فقط نام و توضیحات اسکیل را می‌خواند تا بداند چه ابزارهایی در اختیار دارد. تنها زمانی که تسک کاربر با توضیحات یک اسکیل مطابقت داشته باشد، مرحله Activation رخ می‌دهد و کل محتوای دستورالعمل‌ها وارد Context Window مدل می‌شود. این روش باعث می‌شود ایجنت بتواند صدها مهارت مختلف داشته باشد بدون اینکه توکن‌های ارزشمند را با اطلاعات غیرضروری هدر دهد.

تفاوت Skill با Plugin در این است که اسکیل فرمت نگارش و توسعه (Authoring) است، در حالی که پلاگین فرمت توزیع و بسته‌بندی (Shipping) محسوب می‌شود. وقتی شما چند اسکیل و کانکتور را برای بقیه هم‌تیمی‌ها بسته‌بندی می‌کنید، در واقع یک پلاگین ساخته‌اید. این تفکیک باعث می‌شود توسعه‌دهنده روی منطق کار (Logic) تمرکز کند و درگیر پیچیدگی‌های استقرار نشود.

به نظر من، بزرگترین مزیت Agent Skills این است که ایجنت را از حالت "حدس زدن" (Confident Guessing) خارج می‌کند. وقتی ایجنت وارد یک سشن جدید می‌شود، هیچ ایده‌ای از کانونشن‌های تیم یا حوادث قبلی پروژه ندارد. با نوشتن یک اسکیل دقیق، شما "قوانین بازی" را یک‌بار می‌نویسید و ایجنت در هر اجرا موظف به رعایت آن‌هاست. این یعنی خروجی ایجنت دیگر وابسته به شانس یا پرامپت‌های تصادفی نیست، بلکه پیرو یک متدولوژی مهندسی‌شده است.

📃 مستندات Agent Skills:
https://agentskills.io


🛠 Join @LLMEngineers Community

مفهوم Harness Engineering کلید گمشده تولید نرم‌افزار با ایجنت‌ها در سال ۲۰۲۶ است. فرمول ساده‌ست:
Agent = Model + Harness.
هارنس یعنی هر چیزی که مدل نیست؛ از محدودیت‌ها و ابزارها گرفته تا لوپ‌های فیدبک و فایل‌های استیت. اگر مدل را CPU در نظر بگیریم، هارنس نقش Operating System را بازی می‌کند که منابع را مدیریت می‌کند، کارهای تکراری را Schedule می‌کند و اجازه نمی‌دهد مدل در Context Window خودش غرق شود. واقعیت این است که در پروژه‌های بزرگ، محیطی که مدل در آن کار می‌کند، بسیار مهم‌تر از خود مدل است.

فایل‌های AGENT.md یا CLAUDE.md ابزارهای اصلی این معماری در مخازن کد هستند. این‌ها فایل‌های Markdown هستند که در ریشه پروژه قرار می‌گیرند تا ایجنت در شروع هر سشن بدونه کجاست، کانونشن‌های تیم چیست و معماری فعلی چه وضعیتی دارد. جالب اینجاست که برای رهگیری پیشرفت (Progress Tracking)، استفاده از فایل‌های JSON بسیار پایدارتر از Markdown عمل می‌کند؛ چون ایجنت‌ها در سشن‌های طولانی کمتر تمایل دارند ساختار JSON را تصادفی خراب کنند. این فایل‌ها در واقع RAM ایجنت هستند که بین ری‌استارت‌های مختلف سشن، ثابت می‌مانند.

جدا کردن مرحله Planning از Execution یک اصل حیاتی در Harness Engineering است. ایجنتی که همزمان نقشه می‌کشد و کد می‌زند، خروجی غیرقابل اعتمادی دارد. در هارنس‌های سینیور، ابتدا یک Sprint Contract بسته می‌شود؛ یعنی یک ایجنت (Planner) پیشنهاد می‌دهد که چه تغییری می‌خواهد بدهد و ایجنت دوم (Evaluator) آن را نقد می‌کند. فقط بعد از توافق، مرحله پیاده‌سازی شروع می‌شود. این یعنی Context beats Instructions؛ نشان دادن نقشه راه و وضعیت فعلی فایل‌ها به ایجنت، صد برابر بهتر از نوشتن پرامپت‌های طولانی و انتزاعی جواب می‌دهد.

پدیده Harness Decay واقعیتی است که باید به آن عادت کنیم. هر قطعه در هارنس، در واقع فرضیه‌ای است درباره اینکه مدل چه کاری را نمی‌تواند انجام دهد. با آپدیت شدن مدل‌ها (مثلاً از Opus 4.5 به 4.8)، بخش‌هایی از هارنس که قبلاً ضروری بودند تبدیل به Overhead می‌شوند چون مدل خودش هوشمندتر شده و می‌تواند آن مرحله را حذف کند. به نظر من، مهندسی که هارنس می‌سازد باید با ذهنیت Build to delete کار کند؛ یعنی هر قطعه را جوری طراحی کند که به محض قوی‌تر شدن مدل، بتوان آن را حذف کرد تا هزینه توکن بیهوده بالا نرود.

هزینه اجرای یک لوپ کامل با هارنس مهندسی شده ممکن است ۲۰ برابر بیشتر از یک پرامپت ساده باشد، اما خروجی یک نرم‌افزار واقعی با UI تمیز و منطق درست است، نه یک دموی شکسته که فقط در اسکرین‌شات خوب به نظر می‌رسد. مهندس هوش مصنوعی واقعی در سال ۲۰۲۶ کسی نیست که پرامپت‌های زیباتری می‌نویسد، بلکه کسی است که بهترین Runtime را برای هوش طراحی می‌کند تا ایجنت بتواند در یک محیط ایزوله (Sandbox)، کد بزند، تست بگیرد و در صورت خطا، خودش را اصلاح کند.

📃 مستندات Anthropic درباره ارزیابی ایجنت‌ها:
https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

📃 مقاله OpenAI درباره لوپ‌های ایجنتی Codex:
https://openai.com/index/unrolling-the-codex-agent-loop/

📃 چارچوب کاری Harness Engineering در arXiv:
https://arxiv.org/abs/2605.13357

به نظر من، دوران کل‌کل سر اینکه کدام مدل بهتر است تمام شده. برنده کسی است که هارنس قوی‌تری بسازد. اگر دیتابیس یا مخزن کد شما شلخته باشد، حتی قوی‌ترین مدل دنیا هم خروجی آشغال تحویل می‌دهد. سرمایه‌گذاری روی خوانایی کد برای ایجنت (Harnessability)، ارزشمندترین کاری است که یک تیم فنی می‌تواند انجام دهد.

🛠 Join @LLMEngineers Community

هرمس ایجنت (Hermes Agent) یک Agent Harness از تیم Nous Research است که مدل‌های زبانی رو در یک پکیج عملیاتی از ابزارها، حافظه و کنترلرهای محیطی محصور می‌کنه. برخلاف دستیارهای معمولی که فقط به سوالات جواب میدن، هرمس به عنوان یک Runtime عمل می‌کنه که قابلیت‌هایی مثل کنترل ترمینال و مرورگر، اجرای Cron Job، مدیریت Subagents و اتصال به پیام‌رسان‌هایی مثل تلگرام و اسلک رو به صورت پیش‌فرض درون خودش داره. در واقع هرمس اون "چسب" یا Glueای هست که شما رو از سرهم‌بندی دستی LangGraph، داکر، سیستم‌های زمان‌بندی و دیتابیس‌های حافظه بی‌نیاز می‌کنه.

تفاوت اصلی هرمس در مفهوم Harness Engineering نهفته است. هدف اینجا این نیست که مدل رو با پرامپت‌های طولانی‌تر باهوش‌تر کنیم، بلکه مهندسی کردن محیطی (Environment) است که مدل در آن فعالیت می‌کنه. هرمس این کار رو با لایه‌بندی دقیق انجام میده: لایه ابزارها (Web search, Terminal, Home Assistant)، لایه اجرا (Docker, SSH, Modal) و لایه حافظه (Persistent Memory). یکی از نقاط قوت فنی هرمس، سیستم Skillهاست؛ مهارت‌ها به صورت اسناد دانش (Markdown) در مسیر ~/.hermes/skills/ ذخیره میشن و فقط در صورت نیاز بارگذاری میشن تا مصرف توکن بیهوده بالا نره. این یعنی ایجنت با گذشت زمان و یادگیری از تسک‌های قبلی، پخته‌تر میشه و عملاً با شما رشد می‌کنه.

یکی از جذاب‌ترین بخش‌های هرمس، Compounding Workflows یا جریان‌های کاریِ تجمیعی هست. هرمس از تجربه‌های قبلی اسکیل می‌سازه، اون‌ها رو در حین استفاده اصلاح می‌کنه و یک مدل ذهنی از کاربر و پروژه در سشن‌های مختلف ایجاد می‌کنه. این دقیقاً همون چیزیه که هرمس رو از ابزارهایی مثل Claude Code یا Cursor متمایز می‌کنه. هرمس بیشتر شبیه به یک Junior Operator است که همیشه روی سرور (VPS) شما بیداره، از طریق تلگرام در دسترسه، کارهای روتین رو با Cron انجام میده و تاریخچه تمام تعاملاتش رو برای استفاده در آینده ایندکس می‌کنه.

کاربردهای واقعی هرمس فراتر از کدنویسی ساده‌ست. شما می‌تونید هرمس رو روی یک سرور خونگی یا VPS بالا بیارید و از طریق تلگرام بهش دستور بدید. مثلاً می‌تونید براش تعریف کنید که هر روز صبح اخبار خاصی رو مانیتور کنه، خلاصه‌سازی کنه و براتون بفرسته، یا اینکه مخازن گیت شما رو چک کنه و در صورت وجود آپدیت، یک گزارش تغییرات (Changelog) بنویسه. قدرت واقعی هرمس وقتی مشخص میشه که تسک‌های تکراری پروژه رو به Skill تبدیل کنید؛ کارهایی مثل "ایجاد PR برای ریفکتورینگ" یا "اجرای چک‌لیست ریلیز" که نیاز به دسترسی به ترمینال، گیت و مستندات دارن، با هرمس به تسک‌های خودکار تبدیل میشن.

نکته فنی که نباید ازش غافل شد، امنیت و پایداری در تسک‌های طولانی‌مدت (Long-horizon) هست. اجرای ایجنت‌هایی که دسترسی به Shell دارن و همیشه آنلاین هستن، ریسک‌های امنیتی بزرگی مثل Sleeper Channels رو به همراه داره؛ جایی که ورودی‌های غیرقابل اعتماد می‌تونن به عنوان حافظه یا اسکیل در سیستم ذخیره بشن و بعداً کدهای مخرب اجرا کنن. همچنین، گزارش‌های جدید از شکست‌هایی مثل Channel Fracture در سیستم‌های چند ایجنتی هرمس خبر میدن که نشان‌دهنده چالش‌های جدی در پایداری تحویل پیام‌ها و تزریق حافظه در کارهای سنگین هست. هرمس هنوز یک ابزار تجربی محسوب میشه و نباید بدون ایزولاسیون کامل (Containerization) و لایه‌های تایید انسانی روی سیستم‌های حساس رها بشه.

در نهایت، هرمس برای چه کسی مناسبه؟ اگر تسک‌های شما ماهیت تکرارپذیر دارن (مثل مانیتورینگ روزانه، نگهداری CI/CD، یا مدیریت دانش در ابزاری مثل Obsidian)، هرمس بهترین انتخابه. اما اگر فقط برای یک‌بار کدنویسی یا پرسیدن سوال به هوش مصنوعی نیاز دارید، ابزارهایی مثل Claude Code یا Cursor به دلیل سادگی و تمرکز بر IDE گزینه‌های منطقی‌تری هستن. هرمس زمانی ارزش خودش رو نشون میده که بخواهید یک "سیستم‌عامل برای هوش" بسازید که حافظه، اسکیل و زمان‌بندی رو به صورت یکپارچه مدیریت کنه.

📃 وب‌سایت رسمی هرمس ایجنت:
https://hermes-agent.nousresearch.com

🛠 Join @LLMEngineers Community

بزرگترین نشتی توکن در ایجنت‌های برنامه‌نویسی، پرامپت‌ها نیستند، بلکه خروجی ابزارها (Tool Outputs) هستند. لاگ ترمینال، نتایج سرچ طولانی، گزارش‌های تست و درختی از Dependencyها که معمولاً بدون فیلتر وارد کانتکست LLM میشن. ابزار RTK (Rust Token Killer) دقیقاً برای حل همین مشکل ساخته شده. این ابزار به عنوان یک Proxy محلی بین ایجنت و ترمینال قرار می‌گیره، خروجی رو فیلتر و فشرده می‌کنه و ادعا می‌کنه بین ۶۰ تا ۹۰ درصد در مصرف توکن‌های مربوط به دستورات کدنویسی صرفه‌جویی می‌کنه. ایده اصلی اینه: مدل نباید خروجی خام رو ببینه مگه اینکه واقعاً بهش نیاز داشته باشه.

از نظر معماری فنی، RTK یک فایل اجرایی نوشته شده با Rust هست که یک Hook در مسیر ابزارهای AI (مثل Claude Code یا Cursor) نصب می‌کنه. وقتی ایجنت دستوری مثل git status یا pytest میده، RTK قبل از اجرا اون رو به rtk git status تبدیل می‌کنه. سپس دستور واقعی رو اجرا کرده، فقط بخش‌های مهم (مثل خطاهای تست یا نام فایل‌های تغییر یافته) رو استخراج می‌کنه و به مدل برمی‌گردونه. نکته مهم اینه که RTK از LLM برای خلاصه‌سازی استفاده نمی‌کنه، بلکه با استفاده از Regexو ورودی‌های ساختاریافته (مثل JSON) و یک State Machine متنی، به صورت کاملاً Deterministic خروجی رو تمیز می‌کنه.

یکی از بهترین ترفندهای مهندسی در RTK، روش "Tee Recovery" هست. به جای اینکه ۱۰۰۰۰ خط لاگ بیلد خراب شده رو به مدل بده، فقط خطاهای اصلی رو نشون میده و می‌نویسه: "لاگ کامل در فلان مسیر ذخیره شد". اینطوری اگه مدل واقعاً به لاگ کامل نیاز داشت، می‌تونه اون فایل رو بخونه، در غیر این صورت هزاران توکن الکی مصرف نمیشه. برای دستوراتی که قابلیت JSON شدن دارن RTK مستقیماً JSON رو می‌خونه و فشرده می‌کنه که ضریب خطاش به صفر می‌رسه.

البته این ابزار بدون ریسک نیست. پارس کردن دستورات Shell کار پیچیده‌ایه و RTK به درستی دستورات مرکب مثل Pipeها، Redirectها و Heredocها رو دستکاری نمی‌کنه تا رفتار سیستم تغییر نکنه. همچنین، استراتژی امنیتی اون بر اساس مدل Deny > Ask > Allow > Default طراحی شده و در حالت Default هیچ دستوری رو به صورت خودکار اجازه (Allow) نمیده. با این حال، فشرده‌سازی بیش از حد ممکنه باعث بشه ایجنت یه جزئیات مهم رو در دیباگ از دست بده، برای همین گزینه‌هایی مثل -v یا --no-compact برای بازگشت به حالت خام وجود داره.

به نظر من، ایده پشت RTK همون چیزیه که آینده Agent Harnessها رو شکل میده. این ابزار به جای اینکه مدل رو باهوش‌تر کنه، محیط اطرافش رو ایزوله و تمیز می‌کنه (Context Engineering for Terminal). اگر تیم شما داره روی یک محصول بر پایه ایجنت کار می‌کنه، نیازی نیست حتماً از RTK استفاده کنید، اما معماری اون (فیلتر کردن لاگ‌ها، ذخیره خروجی خام در فایل، و برگرداندن فقط سیگنال‌های مهم) یک الگوی بی‌نقص برای پیاده‌سازی در پروژه‌های سطح بالاست.

🛠 Join @LLMEngineers Community

پدیده Code-Switching (تغییر ناگهانی زبان) پاشنه آشیل سیستم‌های ASR است، اما بنچمارک اخیر ServiceNow نشان می‌دهد مدل‌های Frontier به ثبات خوبی رسیده‌اند. تحلیل اعداد و خروجی‌ها نکات فنی زیر را برجسته می‌کند:

* مدل ElevenLabs Scribe V2 در اکثر جفت‌زبان‌ها کمترین WER (نرخ خطای کلمات) را ثبت کرده و صدرنشین است.
* گوگل Gemini 3 Flash به عنوان یک LALM (مدل زبانی-صوتی بزرگ) در شاخص AER (خطا در پاسخ‌دهی) به دلیل درک کانتکست، عملکردی خیره‌کننده دارد.
* مدل Whisper Large V3 Turbo بدترین نتیجه را گرفت، زیرا به جای Transcription، به اشتباه عمل Translation (ترجمه به انگلیسی) انجام می‌دهد.

Source: https://huggingface.co/blog/ServiceNow-AI/code-switching

🛠 Join @LLMEngineers Community

بعد از حدود ۹ ماه استفاده از مدل‌های Qwen 3 و Qwen 3.5 نسخه 4B روی سیستمم، بالاخره تصمیم گرفتم یه تکونی به ستاپ محلی بدم. الان چند وقتی هست که مدل Gemma 4 E4B نسخه 6-bit رو به عنوان مدل پیش‌فرض روی ویندوز با کارت گرافیک RTX 3060 (نسخه ۶ گیگابایتی) بالا آوردم (با LM Studio )

کوانت Q6 این مدل روی سخت‌افزارهای با VRAM محدود مثل gpu من واقعاً نرم و بی‌دردسر اجرا میشه. توی کارهای روتین، چت‌های معمولی و حتی فرستادن کدهای ساده بش (Bash) کار رو تمیز درمیاره. یکی از نکات جالبش لحن طبیعی‌تری هست که توی خروجی‌های متنی مناسب برای TTS تولید می‌کنه. برای کسایی که روی رزبری پای یا مینی‌پی‌سی هم بالا آوردنش بازخوردها مثبت بوده؛ یعنی مصرف منابعش نسبت به کیفیتی که میده واقعاً بهینه‌ست.

ضعف‌های مدل هم دقیقاً از جایی شروع میشه که یادت میره این کلاً یه مدل کوچیکه. توی ردیت خیلیا شاکی بودن که برای تسک‌های استدلالی سنگین یا خلاصه کردن متون طولانی خروجی متوسطی میده که خب طبیعیه. به نظر من بزرگ‌ترین ضعفش توی سیستم‌های ایجنتی و ابزارهای توسعه مثل Continue.dev یا کارهای نیازمند به Tool Calling عمیقه؛ کلاً ساختار خروجی رو اون‌قدر پایدار نگه نمی‌داره که بشه توی کارهای حساس بهش تکیه کرد. برای پروژه‌های لوکال ایجنتی Qwen 27b انتخاب منطقی‌تریه (که البته gpu بهتریم میخواد).

🛠 Join @LLMEngineers Community

دم همگی بابت مشارکت توی نظرسنجی
طبق آمار، ترجیح اکثریت (حدود ۶۰ درصد) روی پست‌های کوتاه‌تر همراه با سورس اصلی بود.

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

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

این‌طوری هم وقت شما روی مطالب ساده‌تر تلف نمی‌شه، هم عمق فنی کانال روی مباحث اصلی حفظ می‌شه.

همچنین لازمه بگم، از همه دوستانی که لطف داشتن توی کامنت ها خیلی ممنونم،
درسته این کانال هیچگونه سودی برای من نداره و اینقلوئنسر هم نیستم اما همین که میدونم یکی این مطالبو میخونه دلگرمم میکنه 🙏🏻🤍

مدل Qwopus 3.6-27B-Coder هم یه مدل جالب برای کدنویسه، خودم هنوز تست نکردم ولی با 67% در SWE-bench Verified بنظر مدل خوبی میاد، روی gpu شخصی و به‌صورت لوکال میشه اجراش کرد (البته با gpu مناسب)
با استفاده از داده های لورفته claude opus برای agent workflow، tool use، debugging و روی ریپوزیتوری های گیت هاب فاین تیون شده.
قطعا به سطح مدل‌های frontier نمیرسه، اما از نظر “عملکرد نسبت به هزینه” و اجرای محلی گزینه خوبی برای کدنویسیه

مدل GLM-5.2 با معماری MoE (توزیع تنک محاسبات) و کانتکست ۱ میلیون توکنی، منتشر شد.

تحلیل داده‌های ارزیابی عملکرد این مدل:
- بهبود در بنچمارک DeepSWE با جهش چشمگیر از ۱۸.۰ به ۴۶.۲.
- ثبت امتیاز ۸۱.۰ در Terminal-Bench به عنوان قوی‌ترین مدل متن‌باز.
- برتری در MCP-Atlas با امتیاز ۷۷.۰ و عبور از رقبای تجاری.
- امتیاز ۱۳۶۰ در بنچمارک DesignArena و کسب رتبه اول بالاتر از Claude Fable 5.
- رتبه دوم در بخش فرانت‌اند Code Arena با ثبت امتیاز ۱۵۹۵.
- جایگاه دهم در لیدربورد رقابتی کارهای عامل‌محور با بهبود عملکرد مثبت ۴.۴ درصدی.
- کسب رتبه دوم در بنچمارک PostTrainBench با ثبت دقت ۳۴.۲۹ درصدی.



Source: https://huggingface.co/zai-org/GLM-5.2

🛠 Join @LLMEngineers Community

سایت OpenRouter یه ابزار اضافه کرده به اسم Cost Simulator
این ابزار ۱۰۰ تا ریکوئست آخرت رو برمی‌داره و می‌ندازه روی مدل‌های دیگه مثل GPT-5.5 یا GLM 5.2 تا ببینی روی اون مدلا چقد هزینت میشد.

سیستمش بر اساس Median Endpoint Pricing کار می‌کنه؛ یعنی قیمت واقعی رو حساب می‌کنه نه اون قیمت‌های اسمی که شرکت‌ها توی داکیومنت‌هاشون می‌زنن. خروجی کار هم یه جدول مقایسه‌ای و فایل CSV هست که برای گزارش دادن به تیم محصول یا مدیریت عالیه. مثلاً توی دمو نشون می‌ده که سوییچ کردن از Claude Fable 5 به مدل‌های اقتصادی‌تر می‌تونه تا ۷۰ درصد هزینه‌هات رو کم کنه بدون اینکه لازم باشه حدس بزنی.


https://openrouter.ai/labs/simulate-price

🛠 Join @LLMEngineers Community

مدل VibeThinker-3B با ادعای شکست دادن غول‌هایی مثل Gemini 3 Pro و DeepSeek توی ریاضی و کدنویسی، دوباره بحث "فشرده‌سازی استدلال" رو داغ کرده. حرف اصلیشون اینه که برای Reasoning برخلافِ دانش عمومی (Knowledge)، لزوماً به صدها میلیارد پارامتر نیاز نداریم و میشه منطق رو توی یه هسته ۳ میلیاردی جا داد.

توی پایپ‌لاین post-training از یه استراتژی به اسم Spectrum-to-Signal استفاده کردن که با RL سنگین و SFT مرحله‌بندی شده، مدل رو روی تسک‌های Verifiable (اونایی که جواب قطعی دارن) متمرکز می‌کنه. عددها روی AIME و LiveCodeBench خیره‌کننده‌ست، ولی طبق معمول نباید فریب بنچمارک رو خورد.

واقعیت اینه که این مدل‌ها معمولاً برای بنچمارک بهینه (Benchmax) میشن و توی سناریوهای واقعی یا دچار Overthinking میشن یا کلاً گیج می‌زنن. با این حال، اگه این فرضیه که استدلال یه قابلیت چگال و قابل فشرده‌سازیه واقعاً در عمل ثابت بشه، مسیر توسعه SLMها کلاً عوض میشه.

Source: https://arxiv.org/abs/2606.16140

🛠 Join @LLMEngineers Community

مدل‌های لوکال تا همین چند ماه پیش بیشتر شبیه اسباب‌بازی یا نهایتا یه سرچ‌انجین شخصی بودن، اما الان واقعا میشه برای تسک‌های agentic بهشون اعتماد کرد.
اجرای لوپ‌های کدنویسی با مدلی مثل Gemma 4 روی سخت‌افزار شخصی، الان خیلی به پرفورمنس مدل‌های frontier نزدیک شده، که دستاورد بزرگیه.
خوبی اصلیش هم اینجاست که برخلاف کار با APIها، کنترل کامل داری و می‌تونی ریز به ریز پروسه inference و پردازش توکن‌ها روی GPU رو مانیتور کنی و با quantization های مختلف تست بگیری.
تجربه جالب یه کاربر از این ستاپ با LM Studio و داکر رو اینجا بخونید:
https://vickiboykis.com/2026/06/15/running-local-models-is-good-now/

🛠 Join @LLMEngineers Community

مدل Gemma 4 26B-A4B برای تسک‌های فارسی پتانسیل خیلی بالایی داره.
صرفاً «پشتیبانی از زبان‌های مختلف» دیگه برای محصول واقعی کافی نیست؛ ما مدلی می‌خوایم که کثیفیِ دیتای فارسی، نیم‌فاصله و تفاوت ظریف لحن رسمی و محاوره رو بفهمه.
معماری MoE این مدل (۲۶ میلیارد پارامتر کل در مقابل ۴ میلیارد فعال) همون نقطه تعادلیه که همیشه دنبالش بودیم: کیفیت مدل‌های بزرگ با latency و هزینه اینفرنس مدل‌های کوچک.

می‌شه با یه SFT درست و حسابی روی دیتای فارسی تمیز و رعایت ریزه‌کاری‌ها، یه سیستم RAG یا دستیار فارسی ساخت که واقعاً محیط بیزینس یا آکادمیک ما رو درک کنه.
فرصت اصلی اینجاست که به جای منتظر موندن برای مدل‌های جهانی، لایه فارسی رو خودمون روی این بیس‌های قوی و Open-weight بسازیم تا خروجی نهایی حس هوش مصنوعی مترجم رو به کاربر نده.

https://huggingface.co/google/gemma-4-26B-A4B

🛠 Join @LLMEngineers Community

واقعیت اینه که توی دنیای Agentها، مدل فقط حکم موتور رو داره؛ اون چیزی که واقعاً محصول نهایی رو می‌سازه Harness یا همون اسکلت‌بندی دور مدله. مثلا Claude 4.5 روی یه بنچمارک با یه Harness مشخص ۴۲٪ می‌گیره و با یه معماری دیگه به ۷۸٪ می‌رسه، بدون اینکه خود مدل ذره‌ای تغییری کرده باشه.

بزرگترین اشتباه اینه که فکر کنیم هرچی ابزار و Context بیشتری به مدل بدیم باهوش‌تر عمل می‌کنه. برعکس، تجربه‌ی تیم‌های موفقی مثل Cursor و Anthropic نشون می‌ده که الگوهایی مثل Progressive Disclosure (نمایش تدریجی اطلاعات) چقدر حیاتی‌ان. یعنی به جای خفه کردن مدل با حجم عظیمی از دیتا، باید اطلاعات رو فقط وقتی که واقعاً لازم شد و به‌صورت لایه‌ای به خوردش داد تا دچار Attention fragmentation نشه.

توی سیستم‌هایی مثل Claude Code، تمرکز روی سادگی لوپ و استفاده از ابزارهای ساده (مثل Grep و Bash) به جای پکیج‌های سنگین و انتزاعی، هم هزینه‌ی Token رو پایین آورده و هم دقت رو بالا برده. مدل‌ها دارن به سمت "جایگزین‌پذیر" شدن می‌رن و فرق محصولی که واقعاً کار می‌کنه با یه دموی جذاب، توی همون مهندسی ظریفیه که دور مدل چیده شده.

Source: https://x.com/himanshutwtxs/article/2028116431876116660

🛠 Join @LLMEngineers Community

کتاب AI Engineering چیپ هوین رو نباید به چشم یه آموزش برنامه‌نویسی دید؛ این کتاب بیشتر شبیه یه نقشه راه برای فرار از دوران" دمو" ساختن هاست. اگه پروژه‌هاتون توی MVP خوب کار می‌کنن ولی توی Production وا می‌رن، مشکلتون احتمالاً کد نیست، بلکه System Design هست.

بیشترین نقدی که به کتاب می‌شه اینه که کد کمه و تئوری زیاده، ولی به نظرم این بزرگ‌ترین نقطه‌ قوت کتابه. کدها و فریم‌ورک‌ها چند ماهه دِمُدِه می‌شن، اما چیزی که کتاب روش دست گذاشته یعنی طراحی Eval، مدیریت Latency و بالانس بین RAG و Fine-tuning، همون نقطه قوته که یه AI Engineer واقعی رو از بقیه جدا می‌کنه. در واقع کتاب به جای ماهی دادن، داره ماهیگبری یاد می‌ده : چطور یه سیستم بسازیم که وقتی مدل عوض شد یا فریم‌ورک جدید اومد، کل معماری‌مون نپاشه.

رقابت توی مدل‌های امبدینگ زیر ۳۰۰ میلیون پارامتر خیلی جذاب شده. با اینکه گوگل با EmbeddingGemma-300m سر و صدای زیادی کرد، ولی جینا با مدل V5 Nano نشون داد که توی Production برنده کیه.

چند تا دلیل فنی که چرا جینا برای کارهای عملیاتی و RAG بهتره:

کانتکست ۸ هزارتایی در مقابل ۲ هزارتای گوگل، دست آدم رو برای پردازش داکیومنت‌های طولانی و … می‌ذاره.

استفاده از LoRA adapterهای اختصاصی برای تسک‌های مختلف مثل retrieval یا classification باعث میشه دقت خروجی توی سناریوهای واقعی خیلی بالاتر از یه مدل عمومی باشه.

قابلیت Binary Quantization جینا هم حجم ایندکس‌های دیتابیس رو به شدت میاره پایین بدون اینکه افت کیفیت محسوسی داشته باشیم. برای کسی که دنبال پرفورمنس بالا با هزینه inference و نگهداری کمه، این مدل جینا فعلاً بهترین گزینه‌ست.

https://huggingface.co/jinaai/jina-embeddings-v5-text-nano