برای ساختن 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

مسیر ساخت اولین AI Agent؛ بدون هایپ و تئوری‌های اضافه.

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

اولین قدم، انتخاب یه مسئله‌ی خیلی کوچیک و مشخصه. فکر ساختن یه "ایجنت همه‌کاره" رو از سرت بیرون کن. یه وظیفه‌ی خاص رو مشخص کن. مثلاً: رزرو وقت دکتر از یه سایت بیمارستان، یا پیدا کردن شغل‌های مرتبط با تو و فرستادن ایمیل. هرچی مسئله کوچیک‌تر و شفاف‌تر باشه، دیزاین و دیباگ کردنش راحت‌تره.

دومین قدم، انتخاب یه LLM پایه است. لازم نیست از اول مدل خودت رو ترین کنی. از مدل‌های آماده مثل GPT، Claude یا Gemini استفاده کن. اگه می‌خوای self-host کنی، Kimi-K2 یا Qwen گزینه‌های خوبی‌ان. فقط مطمئن شو مدل قابلیت reasoning و تولید خروجی‌های ساختاریافته (structured outputs) رو داشته باشه، چون ایجنت‌ها به اینا وابسته‌ان.

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

- وب اسکرپینگ با Playwright یا Puppeteer
- کار با ایمیل از طریق Gmail API یا Outlook API
- دسترسی به تقویم با Google Calendar API
- عملیات روی فایل مثل خوندن و نوشتن یا پارس کردن PDF

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

برای حافظه از اول سراغ سیستم‌های پیچیده نرو. حافظه‌ی کوتاه‌مدت (short-term context) که همون چندتا پیام آخره، برای شروع کافیه. اگه نیاز به حافظه‌ی بلندمدت داشتی، یه فایل JSON ساده یا یه دیتابیس Sqlite کار رو راه میندازه. Vector databaseها رو بذار برای وقتی که واقعاً بهشون نیاز پیدا کردی (سیستم RAG).

در نهایت، برای ایجنتت یه رابط کاربری ساده بساز. یه اسکریپت CLI برای اولش خوبه، ولی بعداً با Streamlit می‌تونی یه وب اپ ساده براش بیاری بالا تا توی یه محیط واقعی تستش کنی.

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

🛠 Join @LLMEngineers Community

ٖ🐧 ویدیو ارائه (اثر نرم‌افزار آزاد در رشد هوش مصنوعی) منتشر شد.

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

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

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

📌 لینک ویدیوی کامل: https://tubedu.org/w/mMUTdti8QGQSUvDupFoSuK


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

یه مشکل اساسی تو پایپ‌لاین‌های RAG، پردازش داکیومنت‌های پیچیده‌ مثل PDF هست. ابزارهای عادی متن رو به صورت خطی و بدون ساختار استخراج می‌کنن که باعث می‌شه کلی از کانتکست مثل جداول، لیست‌ها و ترتیب خوندن متن از بین بره. اینجاست که مدل جدید و اوپن‌سورس IBM یعنی Granite-Docling وارد می‌شه تا این مشکل رو حل کنه.

این مدل یه Vision-Language Model یا VLM خیلی کوچیک با حجم 258M پارامتره که برای فهم کامل ساختار داکیومنت‌ها طراحی شده. کارش اینه که به جای استخراج متن خام، ساختار سند رو با تمام جزئیاتش مثل جداول، فرمول‌های ریاضی، بلوک‌های کد و لی‌اوت صفحه حفظ می‌کنه. این مدل بر اساس معماری Granite 3 و انکودر بصری SigLIP2 ساخته شده و تحت لایسنس Apache 2.0 در دسترسه.

نقطه‌ی قوت اصلی Granite-Docling در فرمت خروجی منحصربه‌فردش به اسم DocTags هست. این یه زبان نشانه‌گذاریه که خود IBM توسعه داده تا تمام المان‌های صفحه رو به صورت ساختاریافته توصیف کنه. DocTags محتوای متنی رو از ساختار سند جدا می‌کنه و روابط بین المان‌ها، مثلاً اینکه یک کپشن مربوط به کدوم شکله، رو هم مشخص می‌کنه. این فرمت برای پردازش توسط LLM ها بهینه شده و می‌شه به‌راحتی اون رو به Markdown، JSON یا HTML تبدیل کرد.

باید بین Granite-Docling و کتابخونه‌ی Docling تفاوت قائل شد. Docling یه کتابخونه پایتون و یه پایپ‌لاین کامله که کل فرآیند تبدیل سند رو مدیریت می‌کنه. می‌تونه مدل‌های مختلفی رو ارکستر کنه. در مقابل، Granite-Docling یه مدل خاص و تخصصی برای همین کاره که می‌تونه به عنوان موتور اصلی توی این پایپ‌لاین استفاده بشه. این ترکیب، یه راهکار end-to-end برای آماده‌سازی داکیومنت‌ها برای RAG فراهم می‌کنه.

برای کاربردهای RAG، این رویکرد یه تغییر بازیه. وقتی شما داکیومنت رو با حفظ ساختارش به Markdown تبدیل می‌کنید، فرآیند chunking خیلی هوشمندانه‌تر انجام می‌شه. کتابخونه‌ی Docling یه ابزار به اسم HybridChunker داره که chunk هایی با کانتکست بهتر تولید می‌کنه. این یعنی امبدینگ‌های باکیفیت‌تر، بازیابی دقیق‌تر و در نهایت، کاهش چشم‌گیر هذیان‌گویی یا hallucination در پاسخ‌های مدل.

به نظر من، ارزش اصلی Granite-Docling در اندازه‌ی کوچیک و تخصص بالای اونه. دیگه لازم نیست برای فهم ساختار سند به سراغ مدل‌های غول‌پیکر چند ده میلیاردی بریم. این مدل نشون می‌ده که با یه معماری درست و دیتاست تمیز، می‌شه یه مدل کم‌حجم و کارآمد ساخت که یه مشکل مشخص رو به خوبی حل کنه. فرمت DocTags هم یه ایده‌ی خیلی خوبه چون یه لایه‌ی میانی استاندارد برای نمایش ساختار داکیومنت ایجاد می‌کنه که می‌تونه اساس خیلی از تسک‌های downstream باشه. این مدل همچنین قابلیت‌های آزمایشی برای زبان‌های غیرلاتین مثل چینی، ژاپنی و عربی هم داره که نشون‌دهنده‌ی مسیر توسعه‌ی آینده‌شه.

💻 دمو

🛠 Join @LLMEngineers Community