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

اصل داستان، ساخت یک پایپ‌لاین Speech-to-Speech با کمترین Latency ممکن روی سخت‌افزار معمولیه. معماری کلی سیستم به این شکله که صدا به صورت استریم پردازش می‌شه و از یک چرخه چندمرحله‌ای عبور می‌کنه:
۱. تشخیص فعالیت صوتی (VAD) با pyannote/segmentation-3.0
۲. تبدیل گفتار به متن (STT) با whisper-tiny.en
۳. پردازش توسط مدل زبان (LLM) از طریق Ollama با مدلی مثل qwen2.5:0.5b
۴. تبدیل متن به گفتار (TTS) با Kokoro-82M

اما بخش مهم ماجرا، تکنیک‌هایی هست که برای کاهش Latency استفاده شده، خصوصاً Perceived Latency یا تأخیری که کاربر حس می‌کنه.

اولین تکنیک، Priority-based Text Chunking هست. به جای اینکه منتظر بمونیم تا کل جواب LLM آماده بشه، خروجی مدل به صورت استریم گرفته می‌شه و به محض رسیدن اولین کلمات، پردازش شروع می‌شه. یک TextChunker سفارشی، این متن رو بر اساس اولویت‌بندی هوشمندانه‌ای به قطعات کوچیک‌تر تقسیم می‌کنه. اولویت با علائم نگارشی مثل نقطه و علامت سواله، بعدش نوبت کلمات ربطی مثل "however" یا "and" و در نهایت کاما و خط تیره می‌رسه. اینطوری TTS می‌تونه اولین تیکه از جواب رو خیلی سریع‌تر به صوت تبدیل کنه، در حالی که بقیه جواب هنوز داره تولید می‌شه.

دومین تکنیک، یه حقه جالب توی پرامپت‌نویسیه. از LLM خواسته می‌شه که جوابش رو با کلمات پُرکننده (Filler Words) مثل "umm" یا "so" شروع کنه. این کلمات تک‌هجایی هستن و TTS در چند میلی‌ثانیه اون‌ها رو به صوت تبدیل می‌کنه. این باعث می‌شه کاربر تقریباً بلافاصله یه صدایی از سیستم بشنوه و حس کنه که سیستم داره فکر می‌کنه تا جواب بده. این مکث کوتاه و طبیعی، زمان لازم برای تولید بقیه جواب رو می‌خره و تأخیر واقعی سیستم رو از دید کاربر پنهان می‌کنه.

نتیجه‌ی این رویکرد روی یک سیستم بدون GPU با پردازنده AMD Ryzen 5600G، رسیدن به Latency حدود ۲ ثانیه بوده. اما با این تکنیک‌ها، زمان شنیدن اولین صوت از سیستم به ۰.۵ تا ۰.۷ ثانیه کاهش پیدا کرده که تجربه مکالمه رو خیلی طبیعی‌تر می‌کنه.

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

📃 مشاهده پروژه در گیت‌هاب:
https://github.com/asiff00/On-Device-Speech-to-Speech-Conversational-AI

🛠 Join @LLMEngineers Community

پشت این ویدیو از مبارزه زاکربرگ و آلتمن، مدل Wan 2.1 از شرکت علی‌بابا قرار داره.

چالش اصلی اینجا character consistency یا ثابت نگه داشتن چهره‌ها در شات‌های مختلفه که با ابزارهای جانبی مثل IP-Adapter حل شده تا هویت بصری کاراکترها در تمام کلیپ حفظ بشه.

این صرفاً خروجی خام یه مدل text-to-video نیست؛ نتیجه‌ی یک pipeline کامله. اول کلیپ‌ها تولید شدن، بعد چهره‌ها ثابت شدن و در نهایت پست-پروداکشن سنگین با افکت‌های ویژه ماتریکس، اصلاح رنگ و صداگذاری انجام شده.

🛠 Join @LLMEngineers Community

پارت 2
درباره فاین‌تیون مدل gpt-oss
ساخته شده با notebooklm

🛠 Join @LLMEngineers Community

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

مدل DeepSeek-V3.1

این مدل یه معماری هیبریدی داره که دو حالت thinking و non-thinking رو توی یه مدل واحد جمع کرده. یعنی برای تسک‌های سنگین و نیازمند استدلال، از حالت thinking استفاده می‌کنه که توکن بیشتری مصرف می‌کنه ولی دقت بالاتری داره و برای جواب‌های سریع، میره سراغ حالت non-thinking. این مدل ۶۷۱ میلیارد پارامتر داره که البته در هر لحظه فقط ۳۷ میلیاردش فعاله (MoE).

نکته‌ی مهمش اینه که تو بنچمارک‌های کدنویسی و ایجنت مثل LiveCodeBench و SWE-Bench به ترتیب به امتیازهای ۷۴.۸٪ و ۶۶٪ رسیده که جهش قابل توجهی نسبت به نسخه‌های قبلیه. با این حال، جامعه کاربری معتقده که توی نوشتن خلاقانه ضعیف‌تر شده و هنوز مشکل هذیان‌گویی (hallucination) توی contextهای طولانی رو داره. در کل، برای تسک‌های برنامه‌نویسی و ایجنت خیلی خوبه، ولی برای کاربردهای عمومی‌تر شاید بهترین گزینه نباشه.

مدل Command-A-Reasoning-08-2025

این مدل ۱۱۱ میلیارد پارامتری از طرف Cohere برای کاربردهای enterprise و چندزبانه (۲۳ زبان) ساخته شده. مثل DeepSeek، این مدل هم یه سوییچ برای خاموش/روشن کردن حالت استدلال (reasoning) داره تا بشه بین سرعت و دقت یه تعادل برقرار کرد.

قدرت اصلیش توی استفاده از ابزار (tool use) هست و تونسته تو بنچمارک ToolBench به امتیاز ۷۸.۴٪ برسه که برای ساخت ایجنت‌های سازمانی خیلی کاربردیه. نقطه ضعف اصلیش اما لایسنس محدودکننده‌ی اونه. برای استفاده خصوصی اوکیه، ولی برای کارهای تجاری باید پول پرداخت بشه.

مدل Seed-OSS-36B-Instruct

این مدل ۳۶ میلیارد پارامتری از ByteDance با context نیتیو ۵۱۲ هزارتایی ریلیز شده که برای یه مدل اپن‌سورس در این اندازه، فوق‌العاده‌ست. یه قابلیت جالب به اسم thinking budget داره (مشابه مدل های Gemini گوگل) که به کاربر اجازه می‌ده میزان thinking رو محدود کنه .

توی بنچمارک‌های مربوط به context طولانی مثل RULER امتیاز ۹۲.۱٪ رو گرفته و تو بنچمارک SWE-Bench هم به امتیاز ۴۸.۷٪ رسیده که نشون می‌ده برای تحلیل و کدنویسی روی پایگاه‌کدهای بزرگ گزینه‌ی خیلی خوبیه. به نظر من، این مدل برای تیم‌هایی که با داده‌های حجیم سروکار دارن یه ابزار مناسبه

مدل Grok-2

این مدل از xAI دیشب ریلیز شد، با هدف ارائه‌ی هوش خالص و جواب‌های بدون فیلتر و سانسور عرضه شده. حدود 500GB حجمشه و برای اجرا به سخت‌افزار سنگینی (حدود ۸ کارت گرافیک 40GB) نیاز داره.

توی بنچمارک‌های استاندارد مثل MMLU و HumanEval به ترتیب امتیازهای ۸۷.۵٪ و ۸۸.۴٪ رو کسب کرده و به خاطر جواب‌های مستقیم و بی‌حاشیه‌اش معروف شده. جامعه کاربری هنوز در حال مقایسه‌ش با مدل‌های آینده مثل Grok-3 هست و بحث اصلی سر اینه که آیا این مدل فقط یه نسخه‌ی post-trained هست یا یه معماری جدید.

صفحات مدل‌ها در Hugging Face:

🤗 مدلDeepSeek-V3.1

🤗 مدل Command-A-Reasoning

🤗 مدل Seed-OSS-36B-Instruct

🤗 مدل Grok-2

🛠 Join @LLMEngineers Community

مقایسه برترین LLM های اوپن سورس
🛠 Join @LLMEngineers Community

ااینم مقایسه چنتا از SLM های اوپن سورس (زیر 10b)
🛠 Join @LLMEngineers Community

آقا این مقاله یه Position Paperئه، یعنی اومده یه دیدگاه رو مطرح کنه و بگه آینده این شکلیه. خلاصه حرفش اینه که آینده‌ی ایجنت‌ها دست مدل‌های کوچیک (SLMs) هست، نه این LLMهای غول‌پیکر. استدلالش هم اینه که اکثر کارهایی که یه ایجنت می‌کنه، تکراری و تخصصیه. پس چرا برای یه کار ساده، یه مدل ۱۷۵ میلیاردی رو صدا بزنیم؟ به جاش بیایم برای هر تسک یه SLM متخصص و fine-tune شده بذاریم که هم سریع‌تره، هم ارزون‌تر. برای اون بخش‌هایی هم که نیاز به فکر کردن و استدلال عمیق داره، یه LLM رو به عنوان مغز متفکر یا orchestrator می‌ذاریم که کارها رو به SLMهای کارگر پاس بده. یه معماری heterogeneous.

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

اقتصاد Inference رو درست فهمیدن: اینکه هزینه سرو کردن یه مدل ۷ میلیاردی ۱۰ تا ۳۰ برابر ارزون‌تر از یه مدل ۷۰ میلیاردیه، یه فکت کاملاً تجربه‌شده‌ست. وقتی نیاز به parallel کردن مدل روی کلی GPU نداری، هزینه‌های نگهداری و عملیات (operational cost) به شدت میاد پایین. اینو هرکی یه مدل رو production برده باشه با گوشت و پوستش حس کرده.

زدن تو خال با Behavioral Alignment: این یکی از بهترین نکته‌های فنی مقاله‌ست. توی سیستم‌های ایجنتیک، مدل باید یه خروجی با فرمت دقیق (مثلاً JSON) بده تا tool بعدی کار کنه. هرکی ایجنت واقعی نوشته باشه می‌دونه LLMهای بزرگ گاهی زیادی خلاق می‌شن و فرمت رو یه جوری می‌دن که کل پایپ‌لاین می‌خوابه. یه SLM که فقط برای تولید یه فرمت خاص fine-tune شده، خروجی به شدت قابل اعتمادتر و deterministicتری می‌ده. این یه درد واقعی تو مهندسی ایجنته.

ایده‌ی Data Flywheel درسته: اینکه تعاملات ایجنت بهترین منبع برای جمع‌آوری دیتا و بهبود مدل‌های آینده‌ست، یه استراتژی MLOps کلاسیک و درسته. لاگ‌هایی که از ایجنت جمع می‌شه، بهترین و تمیزترین دیتاست دنیاست برای fine-tune کردن یه SLM متخصص و این یه نکته‌ی کاملاً فنی و قابل دفاعه.

ولی خب، بریم سراغ جاهایی که مقاله زیادی خوش‌بین بوده:

الگوریتم مهاجرتشون یه شوخیه: الگوریتمی که تو بخش ۶ داده، روی کاغذ قشنگه ولی تو دنیای واقعی کابوسه. مرحله Data Curation که میگه داده‌های حساس (PII) رو با "ابزارهای اتوماتیک" پاک کنیم؟ تو محیط enterprise، این کار به شدت پرریسک و گرونه. یه اشتباه کوچیک تو این مرحله کل مدل fine-tune شده رو سمی می‌کنه و می‌تونه یه فاجعه امنیتی به بار بیاره.

پیدا کردن تسک با کلاسترینگ؟ جدی؟ اینکه بشینی با الگوریتم‌های unsupervised کلاسترینگ روی promptها، تسک‌های بیزینس رو پیدا کنی بیشتر شبیه یه پروژه‌ی دانشگاهیه تا کار واقعی. تو دنیای واقعی، تسک رو بیزینس و مدیر محصول تعریف می‌کنه، نه k-means. این بخش از مقاله خیلی از واقعیت دوره.

هزینه کل مالکیت (TCO) رو ندیدن: مقاله فقط روی هزینه‌ی inference زوم کرده، ولی هزینه‌ی کل مالکیت یه معماری با صدها SLM رو کلاً فراموش کرده. مدیریت، مانیتورینگ، آپدیت و ارزیابی این "باغ‌وحش مدل" (model zoo) یه جهنم عملیاتیه. واسه همین خیلی از شرکت‌ها ترجیح می‌دن پول API یه مدل خفن مثل GPT-4o رو بدن ولی سردرد نگهداری صدتا مدل ریز و درشت رو نداشته باشن.

ریسک Edge Caseها رو دست‌کم گرفتن: مهم‌ترین ریسک فنی که مقاله بهش وزن نداده، همین edge caseهاست. اون قدرت استدلال عمومی (general reasoning) توی یه LLM بزرگ، مثل یه safety net عمل می‌کنه. وقتی یه سناریوی پیش‌بینی‌نشده پیش میاد، LLM یه شانس برای هندل کردنش داره. ولی یه SLM که فقط روی تسک خودش ترین شده، وقتی با یه ورودی عجیب و خارج از توزیع (out-of-distribution) روبه‌رو بشه، یه شکست فاجعه‌بار می‌خوره که توی یه سیستم بیزینسی یعنی فاجعه.

به نظر من، جهت‌گیری کلی مقاله درسته؛ آینده‌ی سیستم‌های AI به سمت معماری‌های ترکیبی (heterogeneous) میره. اما این مسیر رو خیلی صاف و ساده و بدون چالش نشون داده. واقعیت اینه که پیاده‌سازی این چشم‌انداز تو مقیاس enterprise پر از چالش‌های مهندسی، MLOps و مدیریتیه که مقاله خیلی راحت از کنارشون گذشته.

🛠 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

مایکروسافت یه مدل Text-to-Speech جدید و open-source به اسم VibeVoice داده که تمرکزش روی حل مشکلات مدل‌های فعلیه. این مدل برای ساختن محتوای صوتی طولانی مثل پادکست و کتاب صوتی که چند نفر توش صحبت می‌کنن، عالیه.

برتری‌ها و ویژگی‌های کلیدیش نسبت به بقیه اینه:

۱. تولید صدای خیلی طولانی: بزرگترین مزیتش اینه که می‌تونه تا ۹۰ دقیقه صدای پیوسته تولید کنه. مدل‌های دیگه معمولاً برای متن‌های کوتاه خوبن و توی محتوای طولانی به مشکل می‌خورن، اما VibeVoice برای یه اپیزود کامل پادکست طراحی شده.

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

۳. کیفیت صدای بالاتر از رقبا: توی مقایسه‌هایی که انجام شده، کیفیت صدای VibeVoice توی معیارهایی مثل "طبیعی بودن" و "غنی بودن حس صدا" از مدل‌های خیلی قوی و تجاری مثل Gemini 2.5 گوگل و ElevenLabs هم بهتر بوده.

۴. کارایی بالا: یه تکنیک هوشمندانه برای فشرده‌سازی صدا داره. این باعث می‌شه بتونه حجم عظیمی از صدا رو با سرعت بالا پردازش کنه بدون اینکه کیفیت خراب بشه. این همون راز تواناییش در تولید محتوای ۹۰ دقیقه‌ایه.

به نظر من، VibeVoice یه ابزار خیلی قدرتمند برای تولیدکننده‌های محتواست. تا امروز ساختن یه پادکست چند نفره‌ی باکیفیت از روی متن، تقریباً غیرممکن یا خیلی پرهزینه بود. این مدل این کار رو به شکل open-source در دسترس قرار داده و می‌تونه استاندارد جدیدی برای محتوای صوتی تولید شده با هوش مصنوعی تعریف کنه.

البته این مدل فعلاً فقط برای کارهای تحقیقاتی منتشر شده و مایکروسافت برای جلوگیری از سوءاستفاده و ساخت deepfake، یه پیام صوتی کوتاه که میگه "این صدا با هوش مصنوعی ساخته شده" و یه واترمارک نامرئی به تمام خروجی‌ها اضافه کرده.

📃 گزارش فنی VibeVoice

💻 صفحه پروژه و کد

🛠 Join @LLMEngineers Community

نکات کلیدی این سری مدل‌ها اینه که روی یک مجموعه داده‌ی بسیار بزرگ و با کیفیت آموزش دیدن. حجم دیتاست به حدود ۶۰ میلیارد توکن رسیده که بخش عمده‌ای از اون به صورت سینتتیک و با تمرکز بر روی 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

گوگل یه مدل تصویر جدید به اسم 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

یه نفر تجربه ساخت حدود ۳۰۰ ایجنت 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

کنترل رفتار 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