LLM Engineers
ااینم مقایسه چنتا از SLM های اوپن سورس (زیر 10b) 🛠 Join @LLMEngineers Community
یه مدل جدید از انویدیا اومده که میتونه محاسبات سنگین reasoning رو با context طولانی ۱۲۸ هزار توکنی، روی یه کارت گرافیک با ۲۲ گیگ VRAM اجرا کنه. این یعنی دسترسیپذیری بالاتر برای تسکهایی که نیاز به "فکر کردن" طولانی دارن، بدون نیاز به سختافزارهای فضایی.
مدل Nemotron-Nano-9B-v2 یه مدل هیبرید Mamba-Transformer هست. معماریش به این صورته که اکثر لایههای self-attention با لایههای Mamba-2 جایگزین شدن. این کار باعث شده سرعت inference و throughput مدل، مخصوصاً در سناریوهایی با ورودی و خروجی طولانی (مثلاً ورودی ۸ هزار و خروجی ۱۶ هزار توکن)، تا ۶ برابر بیشتر از مدلهایی مثل Qwen3-8B بشه، در حالی که دقتش رو هم حفظ کرده.
ساخت این مدل چندتا مرحلهی کلیدی داشته که برای ماها هم قابل استفادهست:
اول یه مدل پایه ۱۲ میلیارد پارامتری (12B) روی ۲۰ تریلیون توکن با استفاده از FP8 training recipe آموزش داده شده. دیتاست عظیم و باکیفیتی هم براش ساختن، از جمله یه دیتاست ریاضی جدید به اسم Nemotron-CC-Math که میگن از پایپلاینهای قبلی خیلی بهتره.
بعد از آموزش اولیه و alignment با تکنیکهایی مثل SFT، DPO، GRPO و RLHF، مدل اصلی رو با یه استراتژی هوشمندانه فشرده کردن. از فریمورک Minitron برای pruning استفاده شده. توی این فرآیند، هم لایههای کامل (depth) و هم ابعاد FFN و embedding (width) رو هرس کردن تا مدل از ۱۲ میلیارد به ۹ میلیارد پارامتر برسه و توی حافظهی 12 گیگی A10G جا بشه.
برای اینکه افت دقت ناشی از pruning جبران بشه، از knowledge distillation استفاده شده. یعنی مدل ۱۲ میلیاردی به عنوان "معلم"، دانشش رو به مدل ۹ میلیاردیِ "شاگرد" منتقل کرده تا دقتش بازیابی بشه.
یه نکتهی جالب دیگه در فاز alignment، استفاده از model merging بوده. دوتا checkpoint مختلف که یکی در reasoning و دیگری در chat قویتر بوده رو با هم ترکیب کردن (interpolation) تا به یه تعادل مناسب بین این دو قابلیت برسن. همچنین یه قابلیت budget control برای "فکر کردن" مدل پیادهسازی کردن که به کاربر اجازه میده مشخص کنه مدل قبل از دادن جواب نهایی، چند توکن برای خودش تحلیل بنویسه.
رسما اومدن بهترین تکنیکها رو یاهم ترکیب کردن!
انویدیا هم مدلهای 9B و 12B-Base و هم بخش بزرگی از دیتاستهای pre-training و post-training رو به صورت متنباز منتشر کرده.
📃 مقاله فنی Nemotron Nano 2
🛠 Join @LLMEngineers Community
مدل Nemotron-Nano-9B-v2 یه مدل هیبرید Mamba-Transformer هست. معماریش به این صورته که اکثر لایههای self-attention با لایههای Mamba-2 جایگزین شدن. این کار باعث شده سرعت inference و throughput مدل، مخصوصاً در سناریوهایی با ورودی و خروجی طولانی (مثلاً ورودی ۸ هزار و خروجی ۱۶ هزار توکن)، تا ۶ برابر بیشتر از مدلهایی مثل Qwen3-8B بشه، در حالی که دقتش رو هم حفظ کرده.
ساخت این مدل چندتا مرحلهی کلیدی داشته که برای ماها هم قابل استفادهست:
اول یه مدل پایه ۱۲ میلیارد پارامتری (12B) روی ۲۰ تریلیون توکن با استفاده از FP8 training recipe آموزش داده شده. دیتاست عظیم و باکیفیتی هم براش ساختن، از جمله یه دیتاست ریاضی جدید به اسم Nemotron-CC-Math که میگن از پایپلاینهای قبلی خیلی بهتره.
بعد از آموزش اولیه و alignment با تکنیکهایی مثل SFT، DPO، GRPO و RLHF، مدل اصلی رو با یه استراتژی هوشمندانه فشرده کردن. از فریمورک Minitron برای pruning استفاده شده. توی این فرآیند، هم لایههای کامل (depth) و هم ابعاد FFN و embedding (width) رو هرس کردن تا مدل از ۱۲ میلیارد به ۹ میلیارد پارامتر برسه و توی حافظهی 12 گیگی A10G جا بشه.
برای اینکه افت دقت ناشی از pruning جبران بشه، از knowledge distillation استفاده شده. یعنی مدل ۱۲ میلیاردی به عنوان "معلم"، دانشش رو به مدل ۹ میلیاردیِ "شاگرد" منتقل کرده تا دقتش بازیابی بشه.
یه نکتهی جالب دیگه در فاز alignment، استفاده از model merging بوده. دوتا checkpoint مختلف که یکی در reasoning و دیگری در chat قویتر بوده رو با هم ترکیب کردن (interpolation) تا به یه تعادل مناسب بین این دو قابلیت برسن. همچنین یه قابلیت budget control برای "فکر کردن" مدل پیادهسازی کردن که به کاربر اجازه میده مشخص کنه مدل قبل از دادن جواب نهایی، چند توکن برای خودش تحلیل بنویسه.
رسما اومدن بهترین تکنیکها رو یاهم ترکیب کردن!
انویدیا هم مدلهای 9B و 12B-Base و هم بخش بزرگی از دیتاستهای pre-training و post-training رو به صورت متنباز منتشر کرده.
📃 مقاله فنی Nemotron Nano 2
🛠 Join @LLMEngineers Community
مایکروسافت یه مدل Text-to-Speech جدید و open-source به اسم VibeVoice داده که تمرکزش روی حل مشکلات مدلهای فعلیه. این مدل برای ساختن محتوای صوتی طولانی مثل پادکست و کتاب صوتی که چند نفر توش صحبت میکنن، عالیه.
برتریها و ویژگیهای کلیدیش نسبت به بقیه اینه:
۱. تولید صدای خیلی طولانی: بزرگترین مزیتش اینه که میتونه تا ۹۰ دقیقه صدای پیوسته تولید کنه. مدلهای دیگه معمولاً برای متنهای کوتاه خوبن و توی محتوای طولانی به مشکل میخورن، اما VibeVoice برای یه اپیزود کامل پادکست طراحی شده.
۲. پشتیبانی از چند گوینده: میتونه مکالمه بین حداکثر ۴ نفر رو با صدای متفاوت و طبیعی شبیهسازی کنه. دیگه لازم نیست صدای هر کس رو جدا بسازی و به هم بچسبونی؛ مدل خودش جریان و نوبتدهی صحبت رو مدیریت میکنه تا حس یه گفتگوی واقعی رو بده.
۳. کیفیت صدای بالاتر از رقبا: توی مقایسههایی که انجام شده، کیفیت صدای VibeVoice توی معیارهایی مثل "طبیعی بودن" و "غنی بودن حس صدا" از مدلهای خیلی قوی و تجاری مثل Gemini 2.5 گوگل و ElevenLabs هم بهتر بوده.
۴. کارایی بالا: یه تکنیک هوشمندانه برای فشردهسازی صدا داره. این باعث میشه بتونه حجم عظیمی از صدا رو با سرعت بالا پردازش کنه بدون اینکه کیفیت خراب بشه. این همون راز تواناییش در تولید محتوای ۹۰ دقیقهایه.
به نظر من، VibeVoice یه ابزار خیلی قدرتمند برای تولیدکنندههای محتواست. تا امروز ساختن یه پادکست چند نفرهی باکیفیت از روی متن، تقریباً غیرممکن یا خیلی پرهزینه بود. این مدل این کار رو به شکل open-source در دسترس قرار داده و میتونه استاندارد جدیدی برای محتوای صوتی تولید شده با هوش مصنوعی تعریف کنه.
البته این مدل فعلاً فقط برای کارهای تحقیقاتی منتشر شده و مایکروسافت برای جلوگیری از سوءاستفاده و ساخت deepfake، یه پیام صوتی کوتاه که میگه "این صدا با هوش مصنوعی ساخته شده" و یه واترمارک نامرئی به تمام خروجیها اضافه کرده.
📃 گزارش فنی VibeVoice
💻 صفحه پروژه و کد
🛠 Join @LLMEngineers Community
برتریها و ویژگیهای کلیدیش نسبت به بقیه اینه:
۱. تولید صدای خیلی طولانی: بزرگترین مزیتش اینه که میتونه تا ۹۰ دقیقه صدای پیوسته تولید کنه. مدلهای دیگه معمولاً برای متنهای کوتاه خوبن و توی محتوای طولانی به مشکل میخورن، اما VibeVoice برای یه اپیزود کامل پادکست طراحی شده.
۲. پشتیبانی از چند گوینده: میتونه مکالمه بین حداکثر ۴ نفر رو با صدای متفاوت و طبیعی شبیهسازی کنه. دیگه لازم نیست صدای هر کس رو جدا بسازی و به هم بچسبونی؛ مدل خودش جریان و نوبتدهی صحبت رو مدیریت میکنه تا حس یه گفتگوی واقعی رو بده.
۳. کیفیت صدای بالاتر از رقبا: توی مقایسههایی که انجام شده، کیفیت صدای VibeVoice توی معیارهایی مثل "طبیعی بودن" و "غنی بودن حس صدا" از مدلهای خیلی قوی و تجاری مثل Gemini 2.5 گوگل و ElevenLabs هم بهتر بوده.
۴. کارایی بالا: یه تکنیک هوشمندانه برای فشردهسازی صدا داره. این باعث میشه بتونه حجم عظیمی از صدا رو با سرعت بالا پردازش کنه بدون اینکه کیفیت خراب بشه. این همون راز تواناییش در تولید محتوای ۹۰ دقیقهایه.
به نظر من، VibeVoice یه ابزار خیلی قدرتمند برای تولیدکنندههای محتواست. تا امروز ساختن یه پادکست چند نفرهی باکیفیت از روی متن، تقریباً غیرممکن یا خیلی پرهزینه بود. این مدل این کار رو به شکل open-source در دسترس قرار داده و میتونه استاندارد جدیدی برای محتوای صوتی تولید شده با هوش مصنوعی تعریف کنه.
البته این مدل فعلاً فقط برای کارهای تحقیقاتی منتشر شده و مایکروسافت برای جلوگیری از سوءاستفاده و ساخت deepfake، یه پیام صوتی کوتاه که میگه "این صدا با هوش مصنوعی ساخته شده" و یه واترمارک نامرئی به تمام خروجیها اضافه کرده.
📃 گزارش فنی VibeVoice
💻 صفحه پروژه و کد
🛠 Join @LLMEngineers Community
مدل جدید Hermes 4 بر پایهی Llama 3.1 در دو سایز 70B و 405B منتشر شد. این مدل یه فاینتیون قدرتمند با تمرکز ویژه روی Reasoning و تواناییهای Agentic هست که توسط Nous Research توسعه داده شده. کاربرد اصلیش برای تولید تسکهای پیچیده، کدنویسی و مخصوصاً Function Calling هست.
🛠 Join @LLMEngineers Community
🛠 Join @LLMEngineers Community
LLM Engineers
مدل جدید Hermes 4 بر پایهی Llama 3.1 در دو سایز 70B و 405B منتشر شد. این مدل یه فاینتیون قدرتمند با تمرکز ویژه روی Reasoning و تواناییهای Agentic هست که توسط Nous Research توسعه داده شده. کاربرد اصلیش برای تولید تسکهای پیچیده، کدنویسی و مخصوصاً Function…
نکات کلیدی این سری مدلها اینه که روی یک مجموعه دادهی بسیار بزرگ و با کیفیت آموزش دیدن. حجم دیتاست به حدود ۶۰ میلیارد توکن رسیده که بخش عمدهای از اون به صورت سینتتیک و با تمرکز بر روی reasoning تولید شده.
یکی از ویژگیهای جالب این مدل، حالت استدلال هیبریدی یا Hybrid Reasoning Mode هست. مدل قبل از ارائهی پاسخ نهایی، فرآیند فکر کردن خودش رو داخل تگهای <think>...</think> قرار میده. این باعث میشه که بشه مسیر استدلال مدل رو دنبال کرد و همچنین کیفیت پاسخ نهایی در تسکهای پیچیده بالاتر بره.
در فرآیند آموزش، از تکنیکهای جالبی استفاده شده:
دیتاست سینتتیک: با استفاده از یک ابزار داخلی به اسم DataForge، دیتاستهای متنوعی برای آموزش مدل تولید شده.
یادگیری تقویتی: از یک محیط به اسم Atropos برای Rejection Sampling استفاده شده تا مدل در تسکهای خاصی مثل Schema Adherence (تولید JSON معتبر بر اساس اسکیما) و Tool Use (استفاده از ابزار و فانکشن) به شدت بهینه بشه.
کنترل طول استدلال: یه مشکل رایج در مدلهای reasoning اینه که ممکنه زنجیرهی فکر کردنشون بینهایت طولانی بشه. تیم Nous با یه مرحله فاینتیونینگ اضافه، به مدل یاد داده که بعد از حدود ۳۰ هزار توکن، تگ </think> رو ببنده و پاسخ رو تولید کنه. یه راهحل مهندسی و عملی برای یه مشکل واقعی.
به نظر من، Hermes 4 یه نمونهی عالی از یک فاینتیون مهندسیشده و باکیفیته. تمرکز روی کیفیت و تنوع دیتا، به خصوص دادههای سینتتیک برای قابلیتهای خاص مثل JSON generation و Tool Use، دقیقا همون چیزیه که یه مدل رو از سطح معمولی به سطح حرفهای میرسونه. گزارش فنی شفافی هم ارائه دادن که ارزش کارشون رو دوچندان میکنه.
فرمت پرامپت همون Llama 3 Chat هست و برای فعال کردن حالت reasoning، میشه از System Prompt خاصی استفاده کرد یا فلگ thinking=True رو در تمپلیت چت قرار داد.
📃 گزارش فنی Hermes 4
🤗 مدل 70B در هاگینگفیس
🤗 مدل 405B در هاگینگفیس
🛠 Join @LLMEngineers Community
یکی از ویژگیهای جالب این مدل، حالت استدلال هیبریدی یا Hybrid Reasoning Mode هست. مدل قبل از ارائهی پاسخ نهایی، فرآیند فکر کردن خودش رو داخل تگهای <think>...</think> قرار میده. این باعث میشه که بشه مسیر استدلال مدل رو دنبال کرد و همچنین کیفیت پاسخ نهایی در تسکهای پیچیده بالاتر بره.
در فرآیند آموزش، از تکنیکهای جالبی استفاده شده:
دیتاست سینتتیک: با استفاده از یک ابزار داخلی به اسم DataForge، دیتاستهای متنوعی برای آموزش مدل تولید شده.
یادگیری تقویتی: از یک محیط به اسم Atropos برای Rejection Sampling استفاده شده تا مدل در تسکهای خاصی مثل Schema Adherence (تولید JSON معتبر بر اساس اسکیما) و Tool Use (استفاده از ابزار و فانکشن) به شدت بهینه بشه.
کنترل طول استدلال: یه مشکل رایج در مدلهای reasoning اینه که ممکنه زنجیرهی فکر کردنشون بینهایت طولانی بشه. تیم Nous با یه مرحله فاینتیونینگ اضافه، به مدل یاد داده که بعد از حدود ۳۰ هزار توکن، تگ </think> رو ببنده و پاسخ رو تولید کنه. یه راهحل مهندسی و عملی برای یه مشکل واقعی.
به نظر من، Hermes 4 یه نمونهی عالی از یک فاینتیون مهندسیشده و باکیفیته. تمرکز روی کیفیت و تنوع دیتا، به خصوص دادههای سینتتیک برای قابلیتهای خاص مثل JSON generation و Tool Use، دقیقا همون چیزیه که یه مدل رو از سطح معمولی به سطح حرفهای میرسونه. گزارش فنی شفافی هم ارائه دادن که ارزش کارشون رو دوچندان میکنه.
فرمت پرامپت همون Llama 3 Chat هست و برای فعال کردن حالت reasoning، میشه از System Prompt خاصی استفاده کرد یا فلگ thinking=True رو در تمپلیت چت قرار داد.
📃 گزارش فنی Hermes 4
🤗 مدل 70B در هاگینگفیس
🤗 مدل 405B در هاگینگفیس
🛠 Join @LLMEngineers Community
گوگل یه مدل تصویر جدید به اسم Gemini 2.5 Flash Image رو منتشر کرده که قبل از معرفی رسمی، با اسم مستعار Nano-Banana توی پلتفرمهای بنچمارک مثل lmarena تست میشد و ترکونده بود.
کاربرد اصلی و نقطهی قوت این مدل، image editing هست. این مدل فقط برای تولید عکس از متن (text-to-image) نیست، بلکه توی ویرایش، دستکاری و in-painting تصاویر موجود، به شکل قابل توجهی بهتر از رقبا عمل میکنه. نتایج بنچمارکهای Artificial Analysis هم همینو نشون میده؛ مدلهایی مثل GPT-4o و Qwen-Image-Edit رو با اختلاف زیاد کنار زده و در جایگاه اول قرار گرفته.
دو تا از قابلیتهای کلیدی که این مدل رو واقعاً متمایز میکنه، character consistency و درک عمیق دستورات پیچیدهست. یعنی میشه یه کاراکتر رو توی صحنهها، لباسها و حالتهای مختلف با حفظ کامل ظاهر و هویتش ویرایش کرد. این قابلیت برای تولید محتوای داستانی یا هر سناریویی که نیاز به هویت بصری ثابت داره، یه مشکل اساسی رو حل کرده. دیگه نیازی به تکنیکهای پیچیدهی prompt engineering برای حفظ چهره نیست.
عملکرد این مدل توی lmarena هم با اختلاف امتیاز Elo بسیار بالا، رتبهی اول رو تو بخش Image Edit Arena به دست آورده. این اختلاف زیاد نشون میده که عملکردش فقط یه بهبود جزئی نیست، بلکه یه جهش نسلی توی تواناییهای ویرایش تصویره. استراتژی عرضهی ناشناس این مدل باعث شد کیفیتش بدون تاثیر از برند، توسط کامیونیتی تأیید بشه و یه هایپ ارگانیک شکل بگیره.
به نظر من، Gemini 2.5 Flash Image بازی رو تو حوزهی generative image editing عوض کرده. تمرکز از تولید عکس خام، به سمت یه ورکفلوی کامل ویرایشی و تعاملی شیفت پیدا کرده که کنترل خیلی بیشتری به کاربر میده. این مدل الان به صورت رایگان توی اپلیکیشن Gemini و Google AI Studio در دسترسه و API اون هم با قیمت حدوداً ۰.۰۴ دلار برای هر تصویر ارائه شده.
🛠 Join @LLMEngineers Community
کاربرد اصلی و نقطهی قوت این مدل، image editing هست. این مدل فقط برای تولید عکس از متن (text-to-image) نیست، بلکه توی ویرایش، دستکاری و in-painting تصاویر موجود، به شکل قابل توجهی بهتر از رقبا عمل میکنه. نتایج بنچمارکهای Artificial Analysis هم همینو نشون میده؛ مدلهایی مثل GPT-4o و Qwen-Image-Edit رو با اختلاف زیاد کنار زده و در جایگاه اول قرار گرفته.
دو تا از قابلیتهای کلیدی که این مدل رو واقعاً متمایز میکنه، character consistency و درک عمیق دستورات پیچیدهست. یعنی میشه یه کاراکتر رو توی صحنهها، لباسها و حالتهای مختلف با حفظ کامل ظاهر و هویتش ویرایش کرد. این قابلیت برای تولید محتوای داستانی یا هر سناریویی که نیاز به هویت بصری ثابت داره، یه مشکل اساسی رو حل کرده. دیگه نیازی به تکنیکهای پیچیدهی prompt engineering برای حفظ چهره نیست.
عملکرد این مدل توی lmarena هم با اختلاف امتیاز Elo بسیار بالا، رتبهی اول رو تو بخش Image Edit Arena به دست آورده. این اختلاف زیاد نشون میده که عملکردش فقط یه بهبود جزئی نیست، بلکه یه جهش نسلی توی تواناییهای ویرایش تصویره. استراتژی عرضهی ناشناس این مدل باعث شد کیفیتش بدون تاثیر از برند، توسط کامیونیتی تأیید بشه و یه هایپ ارگانیک شکل بگیره.
به نظر من، Gemini 2.5 Flash Image بازی رو تو حوزهی generative image editing عوض کرده. تمرکز از تولید عکس خام، به سمت یه ورکفلوی کامل ویرایشی و تعاملی شیفت پیدا کرده که کنترل خیلی بیشتری به کاربر میده. این مدل الان به صورت رایگان توی اپلیکیشن Gemini و Google AI Studio در دسترسه و API اون هم با قیمت حدوداً ۰.۰۴ دلار برای هر تصویر ارائه شده.
🛠 Join @LLMEngineers Community
یه نفر تجربه ساخت حدود ۳۰۰ ایجنت AI و کار توی ۵ استارتاپ مختلف رو منتشر کرده. نکاتش حاصل کار عملیه، نه تئوریهای آکادمیک و به درد جامعه مهندسی میخوره.
نکته اصلی اینه که ساخت ایجنت، اون چیزی نیست که خیلیا فکر میکنن. بیشتر از اینکه یه کار AI/ML باشه، یه تخصص مهندسی نرمافزار و بکاند به حساب میاد. کسی که پایههای مهندسی نرمافزار قویای نداره، تو این حوزه به مشکل میخوره. فرمول اصلی خیلی سادهست:
Agent = LLM + Tools + Memory
الگوریتمهای Reasoning الان دیگه بخشی از خود LLM ها شدن.
یکی از مهمترین یافتههاش اینه که ایجنتها بدون ابزار (Tools) تقریباً بیفایدهان. یه LLM که فقط فکر میکنه و به هیچ API یا دیتابیسی وصل نیست، سریع به بنبست میرسه. قدرت واقعی ایجنت زمانی مشخص میشه که بهش اجازه بدی یه کاری تو دنیای واقعی انجام بده.
برخلاف تصور، چارچوبها و فریمورکها اونقدرام کلیدی نیستن. بعد از کار با crewai, dspy, langgraph, autogen و حتی SDK های خود OpenAI و گوگل، نتیجهگیری شده که تمرکز باید روی معماری و پایپلاین اپلیکیشن باشه، نه محدود شدن به یه فریمورک خاص.
کیفیت یه ایجنت هم مستقیماً به کانتکستی که براش فراهم میشه بستگی داره. این تصور که یه هدف کلی به LLM میدی و اونم جادو میکنه، اشتباهه. در عمل، کیفیت پرامپت، ابزارهای دقیق و حافظه مناسب، تاثیرشون از انتخاب یه مدل بزرگتر خیلی بیشتره.
تجربه نشون داده که موثرترین ایجنتها، سادهترینها بودن: یه پرامپت شفاف، یکی دوتا ابزار مشخص و یه مسئولیت واحد. پیچیدگی زیاد، سیستم رو شکننده میکنه. بهترین کاربرد برای ایجنتها، تعریف یک تسک مشخص و اجرای بینقص همونه.
موضوع ارزیابی (Evaluation) هم خیلی دستکم گرفته میشه. ساختن یه دموی پر زرق و برق سادهست، اما اندازهگیری عملکرد واقعی یه ایجنت تو شرایط مختلف، کار سختیه. همین ارزیابی و گرفتن فیدبک، تفاوت بین یه پروژه اسباببازی و یه سیستم پروداکشن رو مشخص میکنه.
به نظرش، DSPy آینده این حوزه است. ساختار Signatures و Optimizers و مخصوصاً متد .compile()ـش خیلی طبیعی و درست به نظر میاد و حس میکنیم که ابزارها باید از اول همینطوری طراحی میشدن.
در نهایت، نتیجهگیری اینه که ایجنتها محصول نهایی نیستن، بلکه توانمندساز (enabler) هستن. جادو زمانی اتفاق میفته که ایجنتها در پسزمینه یک محصول یا سرویس قرار بگیرن، طوری که کاربر اصلاً متوجه حضورشون نشه و کارها «فقط انجام بشن».
منبع
🛠 Join @LLMEngineers Community
نکته اصلی اینه که ساخت ایجنت، اون چیزی نیست که خیلیا فکر میکنن. بیشتر از اینکه یه کار AI/ML باشه، یه تخصص مهندسی نرمافزار و بکاند به حساب میاد. کسی که پایههای مهندسی نرمافزار قویای نداره، تو این حوزه به مشکل میخوره. فرمول اصلی خیلی سادهست:
Agent = LLM + Tools + Memory
الگوریتمهای Reasoning الان دیگه بخشی از خود LLM ها شدن.
یکی از مهمترین یافتههاش اینه که ایجنتها بدون ابزار (Tools) تقریباً بیفایدهان. یه LLM که فقط فکر میکنه و به هیچ API یا دیتابیسی وصل نیست، سریع به بنبست میرسه. قدرت واقعی ایجنت زمانی مشخص میشه که بهش اجازه بدی یه کاری تو دنیای واقعی انجام بده.
برخلاف تصور، چارچوبها و فریمورکها اونقدرام کلیدی نیستن. بعد از کار با crewai, dspy, langgraph, autogen و حتی SDK های خود OpenAI و گوگل، نتیجهگیری شده که تمرکز باید روی معماری و پایپلاین اپلیکیشن باشه، نه محدود شدن به یه فریمورک خاص.
کیفیت یه ایجنت هم مستقیماً به کانتکستی که براش فراهم میشه بستگی داره. این تصور که یه هدف کلی به LLM میدی و اونم جادو میکنه، اشتباهه. در عمل، کیفیت پرامپت، ابزارهای دقیق و حافظه مناسب، تاثیرشون از انتخاب یه مدل بزرگتر خیلی بیشتره.
تجربه نشون داده که موثرترین ایجنتها، سادهترینها بودن: یه پرامپت شفاف، یکی دوتا ابزار مشخص و یه مسئولیت واحد. پیچیدگی زیاد، سیستم رو شکننده میکنه. بهترین کاربرد برای ایجنتها، تعریف یک تسک مشخص و اجرای بینقص همونه.
موضوع ارزیابی (Evaluation) هم خیلی دستکم گرفته میشه. ساختن یه دموی پر زرق و برق سادهست، اما اندازهگیری عملکرد واقعی یه ایجنت تو شرایط مختلف، کار سختیه. همین ارزیابی و گرفتن فیدبک، تفاوت بین یه پروژه اسباببازی و یه سیستم پروداکشن رو مشخص میکنه.
به نظرش، DSPy آینده این حوزه است. ساختار Signatures و Optimizers و مخصوصاً متد .compile()ـش خیلی طبیعی و درست به نظر میاد و حس میکنیم که ابزارها باید از اول همینطوری طراحی میشدن.
در نهایت، نتیجهگیری اینه که ایجنتها محصول نهایی نیستن، بلکه توانمندساز (enabler) هستن. جادو زمانی اتفاق میفته که ایجنتها در پسزمینه یک محصول یا سرویس قرار بگیرن، طوری که کاربر اصلاً متوجه حضورشون نشه و کارها «فقط انجام بشن».
منبع
🛠 Join @LLMEngineers Community
کنترل رفتار 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
برای حل این مشکل، یه راهکار عملی، استفاده از ماشین حالت متناهی یا 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
کاربرد اصلیش اینه که یه مدل تخصصی برای ترجمه با کیفیت بالا در سطح سازمانی ارائه بده. مدلهای عمومی گاهی تو ترجمههای حساس و تخصصی خطا دارن، ولی این مدل مشخصاً برای همین کار 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
مدل جدیدی به اسم 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
معماری مدل بر پایهی 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
مشخصات اصلی:
▫️ کل پارامترها: 560 میلیارد
▫️ پارامترهای فعال: بین 18.6 تا 31.3 میلیارد (به طور میانگین 27 میلیارد)
▫️ داده آموزش: 20 تریلیون توکن
▫️ سرعت اینفرنس: بالای 100 توکن بر ثانیه
به نظر میاد رقابت تو چین خیلی جدیتر از این حرفاست. یه شرکت که کار اصلیش تحویل غذاست، یه مدل با گزارش فنی پر از نوآوری منتشر کرده.
🔗 لینک مدل در Hugging Face
💻 دموی آنلاین
🛠 Join @LLMEngineers Community
LLM Engineers
یه مدل جدید MoE به اسم LongCat-Flash-Chat توسط Meituan (همون اسنپفود چین) منتشر شده. مشخصات اصلی: ▫️ کل پارامترها: 560 میلیارد ▫️ پارامترهای فعال: بین 18.6 تا 31.3 میلیارد (به طور میانگین 27 میلیارد) ▫️ داده آموزش: 20 تریلیون توکن ▫️ سرعت اینفرنس: بالای…
مهمترین نوآوریهاش توی معماری و آموزشه:
اول، معماری:
یک مکانیزم 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
اول، معماری:
یک مکانیزم 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
هستهی فنی و مهندسی (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
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
This media is not supported in your browser
VIEW IN TELEGRAM
Interesting 😂😂