کنترل رفتار Agent های هوش مصنوعی یه چالش بزرگه. مدل‌های زبانی بزرگ (LLMs) ذاتا غیرقطعی (non-deterministic) هستن و همین باعث می‌شه نتونیم بهشون اعتماد کامل کنیم تا یه تسک مشخص رو هر بار دقیقاً مثل قبل انجام بدن. ممکنه وسط کار متوقف بشن، اطلاعات رو جا بندازن یا تصمیمات غیرمنتظره بگیرن.

برای حل این مشکل، یه راهکار عملی، استفاده از ماشین حالت متناهی یا Finite State Machine (FSM) هست که منطق و جریان کار Agent رو خارج از خود LLM تعریف و کنترل می‌کنه. این کار باعث می‌شه رفتار Agent قابل پیش‌بینی و قابل اعتماد بشه.

روش کار به این صورته که کل منطق Agent، حالت‌ها (states)، انتقال‌ها (transitions) و اکشن‌های مربوط به هر حالت، توی یه فایل YAML تعریف می‌شه. این فایل YAML به عنوان "منبع حقیقت" (source of truth) برای رفتار Agent عمل می‌کنه. دیگه محدودیت حجم پرامپت رو نداریم و منطق پیچیده‌تری رو می‌شه پیاده کرد.

نکته کلیدی اینه که در هر مرحله از اجرای FSM، یه اسکریپت پایتون وضعیت فعلی رو از فایل YAML می‌خونه و به LLM میگه دقیقاً چه کاری باید انجام بده. اینطوری، Agent برای فهمیدن اینکه الان کجای پروسه است و مرحله بعد چی هست، به حافظه داخلی و context خودش که ممکنه خطاپذیر باشه، تکیه نمی‌کنه. هر بار وضعیت دقیق از فایل YAML خونده می‌شه. این کار تاثیر "temperature" و حواس‌پرتی‌های احتمالی LLM رو به حداقل می‌رسونه و وفاداری Agent به سناریوی تعریف‌شده رو تضمین می‌کنه.

به نظر من، این روش یه تغییر نگرش مهمه. به جای اینکه سعی کنیم با prompt engineering پیچیده، رفتار LLM رو کنترل کنیم، منطق کنترلی رو به یه سیستم دترمنیستیک خارجی (FSM در YAML) منتقل می‌کنیم و از LLM فقط به عنوان یه موتور پردازش زبان برای انجام تسک‌های مشخص در هر حالت استفاده می‌کنیم. اینطوری، از نقاط قوت هر دو دنیا بهره می‌بریم: قابلیت اطمینان FSM و قدرت پردازش زبان طبیعی LLM.

برای پیاده‌سازی این الگو:
۱. تمام حالت‌های ممکن Agent رو شناسایی و در یک فایل YAML تعریف کنید.
۲. برای هر حالت، اکشن‌ها (دستورالعمل‌هایی که باید به LLM داده بشه) و انتقال‌های ممکن به حالت‌های بعدی رو مشخص کنید.
۳. یک اسکریپت پایتون بنویسید که به عنوان هماهنگ‌کننده (orchestrator) عمل کنه. این اسکریپت در هر مرحله، وضعیت فعلی رو از YAML می‌خونه، دستورات لازم رو به LLM می‌ده و بر اساس خروجی یا ورودی کاربر، به حالت بعدی منتقل می‌شه.

این رویکرد، ساخت Agent های قابل اعتماد برای تسک‌های ترتیبی (sequential tasks) رو به شدت ساده‌تر و عملی‌تر می‌کنه.

📃 Mastering AI Agent Behavior: From LLMs to FSM/YAML

🛠 Join @LLMEngineers Community

یه مدل جدید برای ترجمه از طرف Cohere منتشر شده به اسم Command A Translate.

کاربرد اصلیش اینه که یه مدل تخصصی برای ترجمه با کیفیت بالا در سطح سازمانی ارائه بده. مدل‌های عمومی گاهی تو ترجمه‌های حساس و تخصصی خطا دارن، ولی این مدل مشخصاً برای همین کار post-train شده.

مشخصات فنیش اینه که مدل ۱۱۱ میلیارد پارامتریه و بر پایه‌ی مدل Command A ساخته شده. معماریش همون ترنسفورمر بهینه‌سازی شده‌ست با context length هشت هزارتایی برای ورودی و خروجی. برای ۲۳ زبان از جمله فارسی، عربی، آلمانی و روسی آموزش دیده.

نکته‌ی جالبش یه رویکرد agentic به اسم Deep Translation هست. تو این روش، مدل ترجمه رو تو چند مرحله بازبینی و اصلاح می‌کنه تا خروجی نهایی روان‌تر و طبیعی‌تر باشه. این مکانیزم برای متون پیچیده مثل اسناد حقوقی که دقت بالایی می‌خوان، خیلی کاربردیه.
از لحاظ عملکرد، روی بنچمارک‌های ترجمه مثل WMT24++ نتایج خوبی گرفته و با مدل‌های بزرگ دیگه رقابت می‌کنه.

برای استفاده، مدل با لایسنس غیرتجاری (CC-BY-NC) روی هاگینگ‌فیس برای کارهای تحقیقاتی در دسترسه. نکته‌ی مهم برای دولوپرها اینه که به خاطر معماری بهینه‌ش، می‌شه با کوانتیزیشن ۴-بیت، مدل رو روی یه GPU تکی مثل H100 یا A100 اجرا کرد بدون اینکه افت کیفیت محسوسی داشته باشه. این یعنی برای دیپلوی کردنش نیاز به سخت‌افزار عجیب و غریبی نیست.

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

🤗 مدل در هاگینگ‌فیس

🛠 Join @LLMEngineers Community

برای ساختن voice agent های حرفه‌ای که واقعاً در محیط production کار کنن، OpenAI مدل و API خودش رو آپدیت کرده. کاربرد اصلیش برای شرکت‌هایی هست که می‌خوان سیستم‌های پشتیبانی مشتری، دستیارهای صوتی هوشمند یا IVR های نسل جدید بسازن که بتونن به تلفن وصل بشن، تصویر ببینن و با ابزارهای دیگه مثل سیستم پرداخت کار کنن.

مدل جدیدی به اسم gpt-realtime معرفی شده که یه مدل speech-to-speech یکپارچه (end-to-end) هست. این یعنی دیگه خبری از زنجیره‌ی مدل‌های Speech-to-Text، بعد LLM و در آخر Text-to-Speech نیست.
یک مدل واحد ورودی صوتی رو می‌گیره و خروجی صوتی تولید می‌کنه. این معماری ذاتاً latency رو پایین میاره و باعث می‌شه لحن و احساسات در مکالمه بهتر حفظ بشه.بهبودهای کلیدی مدل gpt-realtime این‌هاست:ت
وانایی دنبال کردن دستورات (Instruction Following) به شکل قابل توجهی بهتر شده. مثلاً می‌تونه اسکریپت‌های دقیق رو کلمه به کلمه بخونه یا وسط مکالمه بین دو زبان سوییچ کنه.

فراخوانی ابزار (Function Calling) هم دقیق‌تر شده و هم حالا به صورت asynchronous کار می‌کنه. این یعنی ایجنت می‌تونه همزمان با اینکه منتظر جواب یک API هست، به مکالمه با کاربر ادامه بده و مکث نکنه؛ این برای تجربه کاربری در دنیای واقعی حیاتیه.

کیفیت صدای خروجی طبیعی‌تر شده و می‌تونه دستورات مربوط به لحن رو اجرا کنه. مثلاً می‌شه ازش خواست "سریع و حرفه‌ای" صحبت کنه یا "با لحنی همدلانه".
دو صدای جدید به نام‌های Cedar و Marin هم اضافه شده.
درک مطلب و هوش مدل هم بالاتره و می‌تونه نشانه‌های غیرکلامی مثل خنده رو تشخیص بده.

در کنار مدل، Realtime API هم چند قابلیت مهم و کاربردی گرفته:
پشتیبانی از MCP (Media Control Protocol) به صورت remote اضافه شده. با این قابلیت می‌شه ایجنت رو به یک سرور خارجی (مثلاً سرور Stripe) وصل کرد تا ابزارهای جدیدی برای پردازش پرداخت یا کارهای دیگه در اختیارش قرار بگیره، بدون اینکه نیاز به یکپارچه‌سازی دستی و پیچیده باشه.

ورودی تصویر (Image Input) حالا پشتیبانی می‌شه. کاربردش مشخصه؛
ایجنت می‌تونه اسکرین‌شات‌ها رو تحلیل کنه یا در مورد تصاویری که کاربر می‌فرسته، صحبت کنه.

پشتیبانی از SIP (Session Initiation Protocol) یک قابلیت کاملاً enterprise-level هست. این ویژگی اجازه می‌ده ایجنت‌های صوتی مستقیماً به شبکه‌های تلفن عمومی (PBX) و تلفن‌های شرکتی وصل بشن.

این آپدیت‌ها نشون می‌ده که OpenAI بازار enterprise رو خیلی جدی هدف گرفته. قابلیت‌هایی مثل SIP و MCP دقیقاً برای حل مشکلات شرکت‌ها در دنیای واقعی طراحی شدن. حرکت به سمت مدل‌های end-to-end برای صوت، یک تغییر مهم در این حوزه است چون بزرگترین مانع voice agent ها یعنی latency رو تا حد زیادی برطرف می‌کنه.

بهبود در asynchronous function calling هم به تنهایی می‌تونه تجربه کاربری رو متحول کنه، چون ایجنتی که برای هر کار ساده‌ای چند ثانیه سکوت کنه، در عمل قابل استفاده نیست.این API از حالت بتا خارج شده و به صورت عمومی (GA) در دسترسه. قیمت مدل جدید هم ۲۰٪ از نسخه preview کمتر شده که برای پروژه‌های بزرگ خبر خوبیه.

🛠 Join @LLMEngineers Community

یک مدل end-to-end multi-modal به نام Step-Audio 2 Mini با ۸ میلیارد پارامتر منتشر شده. این مدل برای پردازش speech-to-speech طراحی شده و هدف اصلیش درک عمیق صوت و مکالمات هوشمنده.

معماری مدل بر پایه‌ی Multimodal Discrete Token Modelling است که توکن‌های صوتی و متنی رو در یک جریان یکپارچه مدل می‌کنه. این ساختار به مدل اجازه می‌ده استدلال رو به صورت همزمان روی هر دو مودالیته انجام بده. یکی از قابلیت‌های فنی اون، استفاده از RAG چندوجهی در زمان inference هست که بهش اجازه می‌ده با بازیابی زمینه متنی یا صوتی، پاسخ تولید کنه یا حتی استایل صدای خروجی رو بر اساس صدای بازیابی شده تغییر بده.

عملکرد مدل در بنچمارک‌ها به صورت کمی قابل بررسیه.
در بنچمارک StepEval-Audio-Paralinguistic که توانایی درک مشخصات فرازبانی مثل احساسات، سن، جنسیت و لحن رو می‌سنجه، این مدل به امتیاز 80.00 رسیده در حالی که GPT-4o Audio امتیاز 43.45 رو کسب کرده. این نشون‌دهنده تمرکز اصلی مدل روی درک جنبه‌های غیرمتنی صداس.

در بنچمارک MMAU برای درک و استدلال صوتی، مدل Step-Audio 2 (نسخه بزرگتر) با امتیاز 78.0 بالاتر از Gemini 2.5 Pro با امتیاز 71.6 قرار گرفته. نسخه mini هم با امتیاز 73.2 عملکرد رقابتی داره.

در تسک‌های ASR، به خصوص در زبان چینی و لهجه‌های مختلف، بهترین عملکرد رو بین مدل‌های مقایسه شده داره (Average CER: 3.19). در زبان انگلیسی هم با WER: 3.50، نزدیک به بهترین مدل‌هاست.

توانایی Tool Calling مدل هم در بنچمارک داخلی StepEval-Audio-Toolcall ارزیابی شده که برای ساخت ایجنت‌های صوتی یک قابلیت کلیدیه.

به نظر من، ارزش اصلی Step-Audio 2 Mini در ترکیب توانایی درک عمیق paralinguistic با یک لایسنس آزاد مثل Apache 2.0 هست. این مدل یک ابزار تخصصی برای کاربردهاییه که فقط trannoscription کافی نیست و درک لحن و احساسات اهمیت داره.

🤗 مدل در Hugging Face

📃 گزارش فنی و مقاله

💻 کد و جزئیات در GitHub

🛠 Join @LLMEngineers Community

یه مدل جدید MoE به اسم LongCat-Flash-Chat توسط Meituan (همون اسنپ‌فود چین) منتشر شده.

مشخصات اصلی:
▫️ کل پارامترها: 560 میلیارد
▫️ پارامترهای فعال: بین 18.6 تا 31.3 میلیارد (به طور میانگین 27 میلیارد)
▫️ داده آموزش: 20 تریلیون توکن
▫️ سرعت اینفرنس: بالای 100 توکن بر ثانیه

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

🔗 لینک مدل در Hugging Face
💻 دموی آنلاین

🛠 Join @LLMEngineers Community

مهم‌ترین نوآوری‌هاش توی معماری و آموزشه:

اول، معماری:
یک مکانیزم Zero-Computation Experts معرفی شده. این یعنی یه سری از اکسپرت‌ها عملاً هیچ کاری نمی‌کنن و ورودی رو مستقیم به خروجی می‌دن. اینطوری مدل یاد می‌گیره برای توکن‌های ساده‌تر، منابع محاسباتی مصرف نکنه و فقط روی توکن‌های پیچیده‌تر تمرکز کنه. به همین دلیله که تعداد پارامترهای فعالش داینامیکه و به طور میانگین حدود ۲۷ میلیارد پارامتر فعال داره. این یه بهینه‌سازی خیلی هوشمندانه برای کاهش FLOPS هست.

دوم، Shortcut-connected MoE یا ScMoE:
توی مدل‌های MoE بزرگ، گلوگاه اصلی معمولاً ارتباطات بین GPUها برای all-to-all هست. اینجا با یه اتصال شورتکات، کاری کردن که محاسبات لایه‌ی dense FFN قبلی با ارتباطاتِ MoE لایه‌ی فعلی همپوشانی داشته باشه. این کار پنجره‌ی computation-communication overlap رو بزرگ‌تر می‌کنه و هم سرعت ترینینگ و هم سرعت اینفرنس رو به شدت بالا می‌بره.

سوم، استراتژی‌های اسکیلینگ و پایداری:
برای پایدار کردن آموزش در این مقیاس، چند تا تکنیک کلیدی استفاده شده.
یکی Model Growth Initialization هست؛ به جای شروع از وزن‌های رندوم، اول یه مدل با نصف تعداد لایه‌ها رو آموزش دادن و بعد لایه‌هاش رو روی هم استک کردن تا مدل نهایی رو بسازن. این کار نقطه شروع بهتری برای آموزش مدل بزرگ فراهم می‌کنه.

برای جلوگیری از انفجار اکتیویشن‌ها، از یه hidden z-loss با ضریب خیلی کم استفاده شده که مقادیر خیلی بزرگ رو توی hidden stateها جریمه می‌کنه.
همچنین برای پایداری روتر، Gradient Norm Ratio رو مانیتور کردن تا مطمئن بشن گرادیانِ لاسِ load balancing روی گرادیانِ لاسِ اصلی مدل غلبه نمی‌کنه و اون رو زیر 0.1 نگه داشتن.
یه نکته‌ی خیلی فنی و جالب دیگه، تنظیم اپسیلونِ اپتیمایزر Adam روی 1e-16 بود. در مقیاس‌های بزرگ، گرادیان‌ها خیلی کوچیک میشن و مقدار پیش‌فرض epsilon می‌تونه فرآیند بهینه‌سازی رو مختل کنه.

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

📃 گزارش فنی

🛠 Join @LLMEngineers Community

یه بحثی که همیشه داغه، این همه عنوان شغلی تو حوزه AI از کجا میاد و فرقشون چیه. خیلی از این عناوین یا توسط HRها ساخته شدن یا صرفاً برای هایپ و جذب نیرو هستن. واقعیت اینه که مرز بین این نقش‌ها خیلی باریکه و تو شرکت‌های مختلف، شرح وظایف یه AI Engineer میتونه زمین تا آسمون فرق کنه. اینجا سعی می‌کنم یه دسته‌بندی منطقی و به دور از هایپ از این نقش‌ها بدم.

هسته‌ی فنی و مهندسی (The Core Engineers)
اینجا با نقش‌هایی طرفیم که بیس کار AI رو تشکیل میدن و بیشترین هم‌پوشانی رو دارن.

ML Engineer:
میشه گفت این اصلی‌ترین و جاافتاده‌ترین عنوانه. کارش ساخت، آموزش و دیپلوی مدل‌های machine learning هست. از ساخت data pipeline گرفته تا training و مانیتورینگ مدل تو پروداکشن، همه با این شخصه. ابزارهاش هم Python، فریمورک‌هایی مثل PyTorch و TensorFlow و ابزارهای MLOps هست.

AI Engineer:
این عنوان یه کم کلی‌تر از ML Engineer هست. یه AI Engineer ممکنه روی سیستم‌های AI که لزوماً learning-based نیستن هم کار کنه (مثلاً سیستم‌های rule-based یا optimization). اما در عمل، ۹۰ درصد مواقع شرکت‌ها از این عنوان به جای ML Engineer استفاده می‌کنن و فرق خاصی بینشون نیست.

Deep Learning Engineer:
این یه تخصص از ML Engineer به حساب میاد. تمرکزش فقط روی شبکه‌های عصبی عمیق و معماری‌های پیچیده‌ست. این افراد معمولاً روی مسائل Computer Vision یا NLP کار می‌کنن که مدل‌های ساده جواب نمیدن. باید درک عمیقی از GPU، بهینه‌سازی و ریاضیات پشت این مدل‌ها داشته باشه.

بچه‌های پروداکت و نرم‌افزار (The Application Layer)
این گروه کارشون اینه که AI رو از فاز تئوری و مدل، بیارن تو دل یه محصول واقعی.

Applied AI Engineer:
این عنوان یعنی «بیا این مدل رو بردار و یه مشکل واقعی تو بیزینس رو باهاش حل کن». تفاوتش با ML Engineer اینه که تمرکزش روی کاربرد و بیزینسه، نه لزوماً ساخت بهترین مدل. باید دانش دامنه (مثلاً مالی یا پزشکی) داشته باشه و بتونه سریع prototype بسازه.

AI Software Engineer:
این یه مهندس نرم‌افزاره که AI هم بلده. کار اصلیش software engineering هست ولی میتونه مدل‌های آماده رو تو یه اپلیکیشن بزرگ‌تر ادغام کنه. کدنویسی تمیز، معماری نرم‌افزار و کار با APIها براش مهم‌تر از خودِ الگوریتم‌هاست.

موج جدید: متخصص‌های GenAI و LLM
اینا نقش‌هایی هستن که با ظهور Generative AI و LLMها به وجود اومدن و هنوز خیلی‌هاشون به بلوغ نرسیدن.

LLM Engineer:
کار این شخص تماماً حول Large Language Models می‌گرده. از fine-tuning کردن مدل‌ها با تکنیک‌های PEFT مثل LoRA گرفته تا بهینه‌سازی inference و کار با ابزارهای مرتبط. این نقش الان خیلی رو بورسه.

AI Agent Developer:
این نقش روی ساخت ایجنت‌های هوشمند و خودمختار تمرکز داره که میتونن با استفاده از LLM و ابزارهای دیگه، وظایف چندمرحله‌ای رو انجام بدن. کار با فریمورک‌هایی مثل LangChain یا ساخت سیستم‌های planning و reasoning جزو کارشونه.

زیرساخت و عملیات (The Infrastructure & Ops)
اینا کسایی هستن که چرخ‌دنده‌های سیستم‌های AI رو روغن‌کاری می‌کنن تا همه چیز روان کار کنه.

MLOps Engineer:
این شخص مسئول اتوماسیون و مدیریت چرخه حیات مدل‌های ML هست. کارش ساخت CI/CD pipeline برای مدل‌ها، مانیتورینگ، ورژن‌بندی و تضمین scalability اونهاست. با ابزارهایی مثل Kubernetes، Kubeflow و Prometheus سر و کار داره. مدل نمیسازه، ولی کمک می‌کنه مدل‌ها به درستی دیپلوی بشن و زنده بمونن.

LLMOps Engineer:
این همون MLOps هست ولی برای دنیای LLMها. چالش‌های LLMها مثل هزینه‌های سرسام‌آور inference، مدیریت پرامپت‌ها و مانیتورینگ hallucination باعث شده این تخصص جدید به وجود بیاد.

استراتژیست‌ها و محقق‌ها (The Big Picture & Research)
این گروه یا در لبه‌ی دانش حرکت می‌کنن یا تصویر بزرگ سیستم رو طراحی می‌کنن.

AI Researcher / Research Scientist:
کارش تحقیق و توسعه‌ی الگوریتم‌ها و روش‌های جدیده. این افراد معمولاً درگیر انتشار مقاله و کارهای آکادمیک هستن و کمتر با پروداکشن درگیرن. معمولاً مدرک دکترا دارن و ریاضیشون خیلی قویه.

Data Scientist:
این نقش بیشتر به تحلیل داده و کشف insight مرتبطه تا مهندسی. از ML استفاده می‌کنه تا الگوها رو پیدا کنه و به سوالات بیزینس جواب بده. خروجیش معمولاً گزارش، داشبورد و مدل‌های پیش‌بینی‌کننده‌ست، نه یه سیستم نرم‌افزاری production-grade.

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

🛠 Join @LLMEngineers Community

یه وبسایت دیدم که اومده نگاه عمیق و بدون هایپ به ساخت ایجنت‌های صوتی یا Voice AI انداخته:
https://voiceaiandvoiceagents.com/
این حوزه فقط چت کردن با صدا نیست، کلی جزئیات مهندسی داره که اگه ندونی، محصولت در حد یه پروژه دانشجویی باقی می‌مونه.

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

مهم‌ترین چالش توی Voice AI، مسئله‌ی Latency هست. کاربر انسانی توی مکالمه انتظار پاسخ زیر یک ثانیه رو داره. یه مکث طولانی حس غیرطبیعی بودن به کل سیستم می‌ده. هدف خوب برای latency کلی voice-to-voice حدود ۸۰۰ میلی‌ثانیه است. این عدد فقط شامل زمان پاسخ مدل (TTFT) نیست؛ پردازش صدا، انکودینگ، شبکه و بافرهای سیستم‌عامل همگی تأثیرگذارن.

معماری استاندارد فعلی یه لوپ سه‌مرحله‌ایه:
- صدا با Speech-to-Text (STT) به متن تبدیل می‌شه.
- متن به عنوان ورودی به یه LLM داده می‌شه تا پاسخ تولید کنه.
- متن خروجی با Text-to-Speech (TTS) دوباره به صدا تبدیل می‌شه.

برای انتخاب LLM، مدل‌هایی مثل GPT-4o و Gemini 2.0 Flash به خاطر Time-to-first-token یا TTFT پایین (حدود ۴۰۰-۵۰۰ میلی‌ثانیه) و قابلیت instruction following خوب، گزینه‌های اصلی هستن. مدل‌های open-weights مثل Qwen 3 هم برای self-hosting گزینه‌های قابل‌توجهی شدن.

مدل‌های Speech-to-speech مثل API جدید OpenAI، آینده‌ی این حوزه محسوب می‌شن چون مراحل STT و TTS رو حذف می‌کنن و latency رو پایین میارن. توی متن میگه که این مدل‌ها هنوز برای کارهای پروداکشن به بلوغ نرسیدن. چون ورودی و خروجی صوتی توکن‌های خیلی بیشتری نسبت به متن مصرف می‌کنه، توی مکالمه‌های طولانی، context بزرگ می‌شه و خود این موضوع باعث افزایش latency می‌شه. فعلاً برای اکثر کارها، همون معماری چندمدلی قابل‌اعتمادتره.

در مورد Speech-to-text، سرویس‌هایی مثل Deepgram و faster-whispe به خاطر ترکیب خوبی از latency پایین و دقت بالا، انتخاب اکثر تیم‌ها هستن. یه تکنیک کاربردی اینه که توی پرامپت به LLM بگی که ورودی حاصل از ترنسکرایبه و ممکنه خطا داشته باشه؛ اینطوری خود مدل می‌تونه خطاهای جزئی رو تصحیح کنه.

برای Text-to-speech، کیفیت صدا، latency، هزینه و پشتیبانی از timestamp های کلمه‌به‌کلمه مهمه. سرویس‌هایی مثل Cartesia، ElevenLabs و Rime گزینه‌های خوبی هستن که هرکدوم روی یکی از این فاکتورها تمرکز بیشتری دارن.

دو تا چالش مهندسی دیگه هم هست که مختص Voice AI هست:
یکی Turn detection، یعنی تشخیص اینکه کاربر حرفش تموم شده یا نه. ساده‌ترین راه استفاده از یه مدل کوچیک Voice Activity Detection یا VAD هست که سکوت طولانی رو به عنوان پایان صحبت در نظر می‌گیره (برای این روش بهترین مدل ten-vad هست ) روش‌های پیشرفته‌تر مثل semantic VAD از خود LLM یا مدل‌های طبقه‌بندی دیگه استفاده می‌کنن تا با درک محتوا، پایان جمله رو بهتر تشخیص بدن.

دومی Interruption handling هست. کاربر باید بتونه وسط حرف ایجنت بپره. این یعنی کل پایپ‌لاین شما باید cancellable باشه و بتونید پخش صدا سمت کلاینت رو فوراً متوقف کنید.

در نهایت، Function calling توی ایجنت‌های صوتی خیلی استفاده می‌شه ولی خودش باعث افزایش latency می‌شه. چون برای هر فانکشن کال، حداقل دو بار inference لازمه: یک بار برای تشخیص نیاز به فانکشن و یک بار بعد از گرفتن نتیجه‌ی اون. این تأخیر رو باید توی طراحی تجربه کاربری در نظر گرفت.
اگه روی ایجنت صوتی کار میکنید حتما این مقاله رو کامل بخونید.

🛠 Join @LLMEngineers Community

Interesting 😂😂

🐧 همایش روز آزادی نرم‌افزار

امسال میزبان اجرای جشن روز آزادی نرم‌افزار در شیرازلینوکس هستیم🎈

تمرکز این رویداد بر معرفی عملی نرم‌افزار آزاد و بحث درباره تأثیرات آن بر جامعه ایرانی است. ما می‌خواهیم فضایی ایجاد کنیم که در آن افراد بتوانند سؤال بپرسند، تجربیات خود را به اشتراک بگذارند و ببینند چگونه آزادی نرم‌افزار به زندگی روزمره‌شان مربوط می‌شود.

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

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

📆 جزئیات برگزاری همایش
زمان| پنج‌شنبه ۲۰ ام شهریور، ساعت ۱۷ الی ۲۰
مکان| شیراز، میدان ارم، دانشگاه شیراز، ساختمان معاونت فرهنگی، سالن شهرراز

👥 حضور برای عموم آزاد است
🤝 اسپانسر برگزاری: شرکت رقم

🌐 اطلاعات بیشتر و مسیریابی: https://sudoshz.ir/sfd-2025/

#نرم‌_افزار_آزاد #روز_آزادی_نرم_افزار

گوگل یه مدل embedding جدید به اسم EmbeddingGemma منتشر کرده که برای کاربردهای on-device و offline بهینه شده. این مدل با ۳۰۸ میلیون پارامتر، بهترین عملکرد رو بین مدل‌های زیر ۵۰۰ میلیون پارامتر در بنچمارک MTEB داره و برای ساختن پایپ‌لاین‌های RAG یا semantic search روی موبایل و لپ‌تاپ طراحی شده.

مهم‌ترین ویژگی فنی این مدل، استفاده از Matryoshka Representation Learning یا MRL هست. این تکنیک اجازه می‌ده که از یک مدل واحد، embedding با ابعاد مختلف استخراج بشه. یعنی می‌تونید از embedding کامل ۷۶۸ بعدی برای بالاترین دقت استفاده کنید، یا برای کاهش هزینه محاسباتی و حافظه، اون رو به ابعاد ۵۱۲، ۲۵۶ یا حتی ۱۲۸ کوتاه کنید. این انعطاف‌پذیری برای محیط‌های با منابع محدود خیلی کاربردیه.

چندتا نکته کلیدی دیگه:
معماری این مدل بر اساس Gemma 3 ساخته شده و روی داده‌هایی از بیش از ۱۰۰ زبان آموزش دیده، پس کاملاً multilingual هست.

با کوانتایز کردن مدل با تکنیک Quantization-Aware Training (QAT)، مصرف رم به کمتر از ۲۰۰ مگابایت می‌رسه که برای اجرا روی دیوایس‌های ضعیف عالیه.

توکنایزر این مدل با مدل زبانی Gemma 3n یکسانه که باعث کاهش memory footprint در اپلیکیشن‌های RAG می‌شه.

این مدل برای گرفتن بهترین نتیجه، نیاز به promptهای خاصی برای هر تسک داره. مثلاً برای retrieval باید از فرمت task: search
result | query: {content}
استفاده بشه. این جزئیات در عملکرد نهایی خیلی تأثیرگذاره.

به نظر من برای کاربردهای on-device فوق‌العاده‌ست. این مدل نشون می‌ده تمرکز جدی روی RAG موبایل و اپ‌های privacy-focused وجود داره و ابزار مناسبی برای این کار فراهم شده.
برای استفاده، خیلی راحت با کتابخونه sentence-transformers یل حتی ollama لود می‌شه.

📃 معرفی رسمی در بلاگ گوگل
🤗 مدل‌ در هاگینگ‌فیس

🛠 Join @LLMEngineers Community

MTEB Leaderboard

🛠 Join @LLMEngineers Community

یه دیتاست جدید و خفن برای مدل‌های زبان-بینایی (VLM) به اسم FineVision اوپن‌سورس شده که از تجمیع بیش از ۲۰۰ دیتاست عمومی ساخته شده و خروجی واقعاً بزرگه:
* شامل ۱۷ میلیون تصویر منحصر به فرد
* دارای ۱۰ میلیارد توکن برای پاسخ‌ها
* شامل قابلیت‌های جدیدی مثل ناوبری در GUI، اشاره کردن (pointing) و شمارش

نکته‌ی مهم اینه که این دیتا فقط یه تلنبار داده نیست. تمام ۲۴ میلیون نمونه‌ی موجود دسته‌بندی شدن و هر جفت پرسش و پاسخ بر اساس چهار معیار رتبه‌بندی شده: کیفیت فرمت، ارتباط، وابستگی بصری و تطابق تصویر. این رتبه‌بندی به شما اجازه می‌ده که ترکیب‌های سفارشی و باکیفیتی برای آموزش مدل‌هاتون بسازید.

یکی از نتایج جالب آزمایش‌هاشون اینه که فیلتر کردن دیتا و نگه داشتن فقط نمونه‌های "با بالاترین کیفیت" در واقع به عملکرد مدل آسیب می‌زنه. آزمایش‌ها نشون داده که در این مقیاس، آموزش روی کل دیتاست با تنوع کاملش (حتی با وجود نمونه‌های با رتبه پایین‌تر) نتیجه‌ی بهتری می‌ده. پس بیخودی دیتاتون رو دور نریزید.

یه کار مهم دیگه‌ای که انجام شده، بررسی آلودگی دیتاست به بنچمارک‌هاست (Data Leakage). یه پایپ‌لاین جدید برای این کار ساختن و فهمیدن FineVision با ۱٪ کمترین میزان آلودگی رو در مقایسه با دیتاست‌های مشابه (که بین ۲ تا ۳ درصد آلودگی دارن) داره. این تمیزکاری می‌تونه تا ۲۰٪ روی نتایج بنچمارک‌ها تأثیر بذاره. ابزار حذف داده‌های تکراری (deduplication) رو هم اوپن‌سورس کردن.

به نظر من، این دیتاست به خاطر مقیاس بزرگ، تنوع بالا و تمیز بودنش می‌تونه یه جهش جدی برای VLMهای اوپن‌سورس باشه. این‌که نتایج آزمایش‌های مختلف (ablation studies) رو هم منتشر کردن، ارزش کار رو خیلی بیشتر می‌کنه و نشون می‌ده که فقط یه دیتا دامپ ساده نیست.

🤗 لینک دیتاست در هاگینگ فیس

📝 لینک مقاله و جزئیات کامل

🛠 Join @LLMEngineers Community

🛠 Join @LLMEngineers Community

🐧 معرفی ارائه دهندگان همایش روز آزادی نرم‌افزار

👤 ارائه دهنده: محمد شجاعی

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

🎙 موضوع ارائه: اثر نرم‌افزار آزاد در رشد هوش مصنوعی

🗃 درباره این ارائه:
در این ارائه به نقش نرم‌افزار آزاد در تحول هوش مصنوعی می‌پردازیم. توضیح می‌دهیم چگونه کامیونیتی اوپن‌سورس با ابزارهایی مثل PyTorch و Hugging Face و مدل‌های متن‌باز، نوآوری را سرعت داده و شرکت‌های بزرگ را به شفافیت بیشتر وادار کرده است. همچنین به تفاوت مدل‌های open-source و open-weight و اهمیت این روند برای زبان‌های کمتر پشتیبانی‌شده اشاره می‌کنیم.

📆 جزئیات برگزاری همایش
      زمان| پنج‌شنبه ۲۰ ام شهریور، ساعت ۱۷ الی ۲۰
      مکان| شیراز، میدان ارم، دانشگاه شیراز، ساختمان معاونت فرهنگی، سالن شهرراز

👥 حضور برای عموم آزاد است
🤝 اسپانسر برگزاری: شرکت رقم

🎥 لینک‌ پخش زنده همایش: https://tubedu.org/w/kF4VMAzwuNrhFiiQkSHbTX

🌐 جزئیات بیشتر و مسیریابی: https://sudoshz.ir/sfd-2025/

بحث "اپن سورس" توی هوش مصنوعی خیلی‌ها رو گیج کرده. یه سری اصطلاحات مارکتینگ مثل "open-weight" رو با لایسنس‌های واقعی FOSS اشتباه می‌گیرن. این یه بحث آکادمیک نیست؛ بحث سر اینه که کنترل استک شما دست خودتونه یا دست یه شرکت دیگه. به نظر من، اکثر چیزایی که بهشون میگن "اپن"، صرفاً یه شکل جدیدی از vendor lock-in با روابط عمومی بهتره.

اول از همه، یه "مدل هوش مصنوعی" فقط اون فایل weights که دانلود می‌کنید نیست. اون فایل یه محصول نهاییه که از یه فرآیند پیچیده و گرون تولید شده. اگه فقط weights رو داشته باشید، انگار یه ماشینی دارید که کاپوتش جوش داده شده. برای فهم، دیباگ یا بازتولید یه مدل، به کل خط تولیدش نیاز دارید از جنلخ:
Training Data, Architecture, Training Code


حالا بریم سراغ سطح های "اپن" بودن که تو عمل باهاش روبرو میشیم:

* سطح ۱: Closed / API-Only
* مثال‌ها: GPT-5, Claude 4.1, Gemini 2.5
* چیزی که گیرتون میاد: یه API endpoint و یه قبض ماهانه. همین.
* معنی در عمل: قفل کامل دست فروشنده (Total vendor lock-in). هیچ کنترلی روی آپ‌تایم، قیمت‌گذاری و تغییر سیاست‌ها ندارید.

* سطح ۲: Open-Weight
* مثال‌ها: Llama 3, DeepSeek, Falcon, Gemma
* چیزی که گیرتون میاد: فقط فایل Model Weights. نه دیتای ترین، نه کد اصلی آموزش و معمولاً یه لایسنس محدودکننده.
* معنی در عمل: یه جعبه‌سیاه که می‌تونید خودتون هاست کنید. می‌تونید اینفرنس بگیرید و فاین‌تیون کنید، ولی نمی‌تونید بازتولیدش کنید، عمیقاً دیباگش کنید یا بایاس‌های بنیادینش رو بفهمید. این بهتر از هیچیه، ولی اپن سورس نیست.

* سطح ۳: Open-Source AI
* مثال‌ها: Mistral, DBRX, Phi-3
* چیزی که گیرتون میاد: Architecture`، `Training Code و Model Weights. دیتای آموزش معمولاً توی یه مقاله توضیح داده میشه ولی کامل منتشر نمیشه.
* معنی در عمل: یه سیستم قابل دیباگ. می‌تونید کد و معماری رو بررسی کنید و درک خوبی از متدولوژی آموزش داشته باشید. به نظر من، این حداقل استاندارد برای کارهای پروداکشن جدیه.

* سطح ۴: Radical Openness (شفافیت کامل)
* مثال‌ها: OLMo, Pythia, SmolLM
* چیزی که گیرتون میاد: همه چیز. دیتای آموزش کامل و قابل بازتولید، معماری، کد آموزش و weights.
* معنی در عمل: یه جعبه‌شیشه‌ای. اگه سخت‌افزارش رو داشته باشید می‌تونید کل فرآیند آموزش رو از صفر بازتولید کنید. این استاندارد طلایی برای تحقیقات و هر کسیه که دنبال شفافیت و اعتماد کامل باشه.

اینکه غول‌های تکنولوژی دارن مدل‌های open-weight منتشر می‌کنن از سر خیرخواهی نیست. این یه حرکت استراتژیک در جواب به فشار جامعه‌ی اپن سورسه. دیدن که دولوپرها دارن به سمت Llama و Mistral میرن و فهمیدن که با API های بسته، جنگ برای به دست آوردن ذهن دولوپرها رو می‌بازن. در واقع، جامعه اپن سورس اون‌ها رو مجبور کرد که در زمین ما بازی کنن و این یه برد بزرگ برای اکوسیستمه.

این تغییر بدون ابزارهای فوق‌العاده‌ای که جامعه ساخته ممکن نبود. ابزارهایی مثل PyTorch برای ساخت، Unsloth برای فاین‌تیون بهینه، llama.cpp و Ollama برای اجرای مدل‌ها روی سخت‌افزار شخصی، و vLLM برای اینفرنس در مقیاس پروداکشن، موانع رو از بین بردن و به همه قدرت دادن.

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

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

📃 اسلایدها:
https://mshojaei77.github.io/open_source_ai.html

📝 پست وبلاگ:
https://dev.to/mshojaei77/open-source-ai-5aio

🛠 Join @LLMEngineers Community

علی‌بابا یه مدل جدید به اسم Qwen3 Next 80B داده که تونستن به سطح هوش DeepSeek V3.1 برسن، در حالی که فقط ۳ میلیارد پارامتر فعال دارن. این یعنی کارایی و بهینگی خیلی بالا با حفظ قدرت.

معماری این مدل از چندتا تکنیک جدید استفاده می‌کنه. به جای attention استاندارد، از یه مکانیزم هیبریدی به اسم Gated DeltaNet و Gated Attention استفاده شده. مهم‌ترین بخشش اما، معماری Mixture-of-Experts با پراکندگی (sparsity) خیلی بالاست. از ۸۰ میلیارد پارامتر کل، فقط ۳.۸٪ در هر لحظه فعال میشن. این یعنی کاهش شدید فلاپس و در نتیجه سرعت بالاتر inference، مخصوصاً برای context های طولانی. یه تکنیک دیگه هم به اسم Multi-Token Prediction یا MTP برای افزایش سرعت inference به کار رفته.

عملکردش در بنچمارک‌ها خیلی خوب بوده و کنار مدل‌های سنگین‌تر قرار می‌گیره. نکته‌ی مهم اینه که روی یک کارت H200 جا میشه و این برای دولوپرهای عادی و شرکت‌هایی که نمی‌خوان هزینه سرورهای غول‌پیکر بدن، خبر خیلی خوبیه. پنجره‌ی context نیتیو مدل 256k توکنه که با تکنیک YaRN تا حدود ۱ میلیون توکن هم قابل افزایشه. این برای پردازش اسناد خیلی طولانی کاربرد داره.

برای دیپلوی کردنش، بهترین راه استفاده از فریمورک‌های بهینه‌شده مثل sglang یا vllm هست. این ابزارها بهتون یه اندپوینت OpenAI-compatible می‌دن و اجازه می‌دن از تمام ظرفیت سرعت مدل، مخصوصاً MTP، استفاده کنین. استفاده از transformers خام، تمام پتانسیل مدل رو آزاد نمی‌کنه.

به نظر من، این مدل یه سیگنال واضحه که آینده‌ی مدل‌ها فقط در بزرگ‌تر شدن خلاصه نمیشه، بلکه در هوشمندتر شدن معماریه. جنگ پارامتر داره جاش رو به جنگ بهینگی می‌ده. معماری‌های sparse که دانش رو در پارامترهای زیاد ذخیره می‌کنن ولی موقع inference فقط بخش کوچیکی رو فعال می‌کنن، آینده‌ی مدل‌های production-ready هستن. ترکیب ظرفیت بالا با هزینه محاسباتی پایین، همون چیزیه که برای کاربردهای واقعی لازم داریم و Qwen3 Next یه قدم محکم در این مسیره.

🤗 جزئیات فنی و بنچمارک‌ها


🛠 Join @LLMEngineers Community

دیتاست جدید FinePDFs برای pre-training منتشر شده. این دیتاست ۳ تریلیون توکنی از محتوای فایل‌های PDF استخراج شده و برای حل مشکل کمبود داده باکیفیت یا همون "data wall" عرضه شده. کاربرد اصلیش اینه که اگه با دیتاست‌های مبتنی بر وب ترکیب بشه، پرفورمنس مدل رو به شکل قابل توجهی بالا می‌بره. به علاوه، چون میانگین طول داکیومنت‌ها در PDFها خیلی بیشتر از صفحات وب هست، برای آموزش مدل‌های long-context یه منبع فوق‌العاده‌ست.

مدتیه که دیتاست‌های مبتنی بر وب دارن به سقف ظرفیتشون می‌رسن. PDFها همیشه یه منبع غنی از محتوای باکیفیت بودن، مثل مقالات علمی، اسناد حقوقی و گزارش‌های فنی، ولی استخراج متن ازشون به خاطر ساختار پیچیده و هزینه بالای پردازش، یه چالش بزرگ بوده. تیم Hugging Face با استفاده از کتابخونه datatrove این دیتاست رو آماده کرده.

برای استخراج متن، یه پایپ‌لاین دو مرحله‌ای طراحی شده تا هزینه رو مدیریت کنن.
۱. برای PDFهایی که متن قابل استخراج (native) دارن، از ابزار Docling روی CPU استفاده شده که روش ارزون‌تریه.
۲. برای PDFهای اسکن‌شده یا اونایی که متن‌شون به صورت عکس هست، از یه VLM به اسم rolmOCR روی GPU استفاده شده که هزینه بالاتری داره ولی کیفیتش عالیه.

نتیجه‌ی این فرایند، دیتاستی با ۳ تریلیون توکن از ۴۷۵ میلیون داکیومنت در ۱۷۳۳ زبان مختلفه. تست‌ها نشون داده که ترکیب این دیتاست با دیتاست‌های SOTA مبتنی بر وب (مثل SmolLM3-Web)، نتایج بهتری نسبت به هر کدوم به تنهایی می‌ده. بهترین عملکرد وقتی به دست اومده که حدود ۲۵٪ از دیتای pre-training از FinePDFs و بقیه‌ش از منابع وب باشه. پس توصیه نمیشه که یه مدل رو فقط با این دیتاست از صفر آموزش بدید.


🤗 دیتاست FinePDFs در Hugging Face

🛠 Join @LLMEngineers Community