گوگل از یه ورژن خیلی کوچیک Gemma 3 رونمایی کرده که ۲۷۰ میلیون پارامتریه.

کاربرد اصلی این مدل برای fine-tune کردن سریع و اجرای تسک‌های هوش مصنوعی روی دستگاه‌های کاربر (on-device) هست. نقطه قوت کلیدی این مدل، توانایی بالای اون در دنبال کردن دستورات یا instruction following هست که توی بنچمارک IFEval سنجیده شده.

توی نمودار مقایسه‌ای، نسخه 270M با اینکه سایز کوچیکی داره، مدل‌های بزرگتری مثل Qwen 2.5 0.5B و SmolLM2-360M رو با اختلاف کنار زده. این موضوع نشون‌دهنده بهینگی بالا در معماری و کیفیت دیتاست pre-train هست.

🛠 Join @LLMEngineers Community

جزئیات فنی معماری و آموزش

معماری این مدل ۲۷۰ میلیون پارامتری خیلی جالبه. از این عدد، ۱۷۰ میلیون پارامتر فقط برای embeddingهاست و ۱۰۰ میلیون پارامتر به بلوک‌های transformer اختصاص داده شده. این یعنی بخش بزرگی از ظرفیت مدل صرف درک توکن‌ها شده. دلیلش هم داشتن یک vocabulary بسیار بزرگ با ۲۵۶ هزار توکنه. این ویژگی باعث میشه مدل پایه (base model) خیلی قوی باشه و برای fine-tune شدن روی دامنه‌های تخصصی یا زبان‌های مختلف که توکن‌های نادری دارن، عملکرد فوق‌العاده‌ای از خودش نشون بده.

نکته کلیدی دیگه، حجم دیتای آموزشیه. این مدل ۲۷۰ میلیون پارامتری روی ۶ تریلیون توکن آموزش دیده. در حالی که نسخه‌های بزرگتر مثل Gemma 3 1B روی ۲ تریلیون و 4B روی ۴ تریلیون توکن آموزش دیدن. این نسبت بالای دیتا به پارامتر (data-to-parameter ratio) یکی از دلایل اصلی عملکرد قوی این مدل در زمینه instruction following هست. امتیاز ۵۱.۲ در بنچمارک IFEval برای مدلی در این سایز، نشون‌دهنده همین بهینگی در آموزشه.

برای بهینگی بیشتر، گوگل نسخه‌های Quantization-Aware Trained یا QAT رو هم منتشر کرده. این یعنی مدل از همون ابتدا با در نظر گرفتن کوانتایز شدن آموزش دیده و میشه اون رو با دقت INT4 و با کمترین افت عملکرد اجرا کرد. تست‌های داخلی روی چیپست Pixel 9 Pro نشون داده که نسخه INT4 این مدل برای ۲۵ مکالمه فقط ۰.۷۵٪ از باتری رو مصرف کرده که اون رو به بهینه‌ترین مدل Gemma از نظر مصرف انرژی تبدیل می‌کنه.

چطور ازش استفاده کنیم؟

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

ابزارهایی مثل Unsloth و فریمورک‌های استاندارد مثل JAX و Hugging Face به طور کامل ازش پشتیبانی می‌کنن. برای اجرا هم می‌تونید از پلتفرم‌هایی مثل Ollama، LM Studio یا llama.cpp استفاده کنید.

🤗 صفحه مدل در Hugging Face

🛠 Join @LLMEngineers Community

یکی از ابزارهای خفن برای فاین‌تونینگ مدل‌های زبانی Axolotl عه،
خیلی ساده، Axolotl یه فریم‌ورک اوپن‌سورس برای فاین‌تون کردن LLMهاست. تمرکزش روی اینه که بهترین و جدیدترین تکنیک‌ها رو خیلی سریع در اختیارت بذاره. از مدل‌های Llama و Qwen گرفته تا Gemma و حالا gpt-oss.

این فریم‌ورک با بهینه‌سازی‌های پیشرفته‌ای مثل FlashAttention برای محاسبات سریع‌تر attention، و gradient checkpointing برای صرفه‌جویی تو مصرف مموری، خودش رو مجهز کرده. قابلیت‌هایی مثل multipacking (استفاده بهینه از مموری با پک کردن چند سکانس کوتاه کنار هم) و RoPE scaling (برای کار با context lengthهای متغیر) هم جزو ویژگی‌های استانداردشه.

نقطه قوت اصلی Axolotl، توانایی‌هاش توی distributed training هست. یعنی اگه بخوای روی چندتا GPU یا حتی چندتا سرور (multi-node) یه مدل غول‌پیکر رو ترین کنی، Axolotl با پشتیبانی از DeepSpeed (ZeRO stages 1-3) و FSDP (Fully Sharded Data Parallel) کارت رو راه میندازه.

Axolotl یا Unsloth؟ مسئله این است

هر دو ابزار عالین، ولی انتخاب بینشون بستگی به نیازت داره.

چرا باید Axolotl رو انتخاب کنی؟

مقیاس‌پذیری و Multi-GPU: اگه می‌خوای مدل‌های واقعاً بزرگ رو روی چندین GPU رده‌بالا فاین‌تون کنی، Axolotl بهترین گزینه‌ست. استراتژی‌های distributed training توش به بلوغ رسیدن، چیزی که Unsloth هنوز توش خیلی کار داره.

انعطاف‌پذیری و کنترل کامل: Axolotl گزینه‌های کانفیگ خیلی زیادی برای کنترل دقیق پروسه ترینینگ بهت می‌ده. از sequence parallelism برای contextهای خیلی طولانی گرفته تا یکپارچه‌سازی با ابزارهایی مثل Weights & Biases برای مانیتورینگ.

چه زمانی Unsloth برنده می‌شه؟

سرعت و بهینه‌سازی VRAM روی تک GPU: اگه سخت‌افزار محدودی داری (مثلاً یه کارت گرافیک گیمینگ یا سرورهای قدیمی‌تر Colab)، Unsloth معجزه می‌کنه. با کرنل‌های سفارشی که برای GPU نوشته، می‌تونه تا ۲-۵ برابر سریع‌تر باشه و تا ۸۰٪ VRAM کمتری مصرف کنه.

به نظر من، اگه اولویتت سرعت حداکثری و بازدهی روی یک یا دوتا GPU هست و با مدل‌های محبوب کار می‌کنی، Unsloth کارت رو خیلی سریع و تمیز راه میندازه. اما برای کارهای تحقیقاتی، فاین‌تونینگ مدل‌های عظیم و نیاز به کنترل کامل روی محیط‌های distributed، قطعاً Axolotl برتری داره.

فاین‌تونینگ مدل‌های GPT-OSS با Axolotl

اخیراً OpenAI دو مدل Mixture-of-Experts (MoE) به اسم gpt-oss-20B و gpt-oss-120B رو به صورت اوپن‌ویت منتشر کرده. خبر خوب اینه که Axolotl خیلی سریع پشتیبانی از فاین‌تونینگ این مدل‌ها رو اضافه کرده.

یکی از نکات مهمی که جامعه بهش رسیده اینه که تکنیک‌های Parameter-Efficient Fine-Tuning (PEFT) مثل QLoRA، به‌خصوص روی تسک‌های پیچیده، عملکرد ضعیف‌تری نسبت به full-parameter fine-tuning دارن. برای همین Axolotl روی قابلیت‌های distributed training خودش سرمایه‌گذاری کرده تا بتونی مدل‌های 70B+ رو بدون افت کیفیت، به صورت کامل فاین‌تون کنی.
پروسه فاین‌تونینگ با Axolotl حول یک فایل کانفیگ YAML می‌چرخه که توش همه‌چیز رو تعریف می‌کنی.

نیازمندی‌های سخت‌افزاری:

QLoRA: برای این تکنیک روی مدل gpt-oss-20B، یه GPU با حدود ۱۶ تا ۲۴ گیگ VRAM کافیه.

Full Fine-Tuning (FFT): برای فاین‌تونینگ کامل، به سخت‌افزار سنگین مثل H100 با ۸۰ گیگ VRAM نیاز داری. البته با استراتژی‌هایی مثل FSDP و offloading می‌شه مدل gpt-oss-20B رو روی دوتا GPU با ۲۴ گیگ VRAM هم ترین کرد.

مدل 120B: طبق داکیومنت‌های Axolotl، می‌شه مدل gpt-oss-120B رو با FFT و offloading روی یک نود با ۸ تا H100 (هر کدوم ۸۰ گیگ) فاین‌تون کرد.

کانفیگ YAML:
توی فایل کانفیگ، base_model رو openai/gpt-oss-20b می‌ذاری و دیتاست خودت رو مشخص می‌کنی. برای تکنیک‌های مختلف، کانفیگ‌های متفاوتی وجود داره:

برای QLoRA، گزینه‌ی load_in_4bit: true و adapter: qlora رو فعال می‌کنی.

برای FFT، این گزینه‌ها رو حذف می‌کنی.

چون این مدل‌ها MoE هستن، باید lora_target_modules رو روی لایه‌های درستی مثل gate_proj تنظیم کنی.

ویژگی‌های جدید:
با آپدیت‌های اخیر، Axolotl از FP8 هم پشتیبانی می‌کنه که مصرف مموری رو از این هم کمتر می‌کنه. همچنین با همکاری Hugging Face، امکان ترکیب Context Parallelism، Tensor Parallelism و FSDP برای ترین کردن مدل‌های عظیم در مقیاس multi-node فراهم شده.

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

📃 بلاگ رسمی Hugging Face درباره ND Parallelism

📃 مثال‌های کانفیگ برای فاین‌تونینگ GPT-OSS

🛠 Join @LLMEngineers Community

یه مقایسه عملی و سریع بین Ollama و LM Studio موقع اجرای یه مدل GGUF یکسان. نتایج جالبه و شاید برای انتخاب ابزار کمکتون کنه.

توی این تست، مدل gemma-2-2b-fa یک بار با LM Studio و یک بار با Ollama روی یه مجموعه سوال یکسان ارزیابی شده.

نتایج خلاصه:

LM Studio:
دقت 31.04% و میانگین latency برابر 0.15s.

Ollama:
دقت 29.40% و میانگین latency برابر 0.43s.

همونطور که مشخصه، LM Studio هم دقت بالاتری داشته و هم تقریباً ۳ برابر سریع‌تر بوده. علاوه بر این، مصرف VRAM در Ollama هم بیشتر بود.

🛠 Join @LLMEngineers Community

داشتم قابلیت function calling یا tool use رو با مدل‌های لوکال تست می‌کردم که یه نتیجه جالب گرفتم.

مدل کوچیک jan-v1-4b که قبلتر راجبش گفته بودنم رو توی LM Studio ران کردم و بهش MCP جستجوی وب با DuckDuckGo وصل کردم. وقتی ازش خواستم آخرین اخبار هوش مصنوعی رو بهم بگه، به جای اینکه از دانش داخلی و تاریخ گذشته‌ش استفاده کنه، خودش تشخیص داد که باید از ابزار search استفاده کنه.

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

به نظر من، این قابلیت که مدل‌های کوچیک و open-source هم بتونن از ابزارهای خارجی استفاده کنن، بازی رو عوض می‌کنه. این یعنی دیگه محدود به دانش داخلی مدل نیستیم و می‌تونیم مدل‌ها رو برای کاربردهای واقعی و ساختن agent های ساده آماده کنیم.

🛠 Join @LLMEngineers Community

مجموع دانلود مدل‌های فارسی gemma-3-4b که چند ماه پیش منتشر کردم، از مرز ۴ هزار دانلود عبور کرد.
این آمار شامل تمام نسخه‌های کوانتایز شده GGUF، نسخه‌ی Ollama و ...

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

با همین انرژی، کار روی پروژه‌ی بعدی شروع شده.
منتظر نسخه‌ی فاین‌تیون شده‌ی فارسی Qwen3-4B یا gemma-3n-e4b باشید. به‌زودی ...

🤗 صفحه من توی هاگینگ فیس

🛠 Join @LLMEngineers Community

نتیجه تست مدل های زبانی کوچک SLM روی بنچمارک ParsiEval برای سنجش دانش زبان فارسی

پ.ن: لازم به ذکره qwen thinking هم خیلی کند تر بود هم gpu داغ کن تر

▫️ لیست کامل

🛠 Join @LLMEngineers Community

توضیح غیرفنی معماری MoE
🛠 Join @LLMEngineers Community

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


اصل داستان توی ساخت سیستم‌های مبتنی بر LLM، ارکستریشن (orchestration) هست. یعنی مدیریت جریان کار، فراخوانی ابزارها، و نگهداری وضعیت (state). هر فریمورکی یه راهی برای این ارکستریشن پیشنهاد می‌ده و انتخاب اشتباه می‌تونه منجر به مشکلات معماری جدی بشه.

استفاده مستقیم از OpenAI SDK یعنی شما مسئولیت کامل لایه ارکستریشن رو به عهده می‌گیرید. این به معنی کنترل صددرصدی روی پرامپت‌ها، مدیریت state و منطق فراخوانی ابزارهاست. از نظر فنی، این روش کمترین overhead و dependency رو داره ولی تمام پیچیدگی‌های state management و control flow رو به کدبیس اپلیکیشن شما منتقل می‌کنه. برای سیستم‌های پیچیده، این یعنی باید یک مینی-فریمورک داخلی برای خودتون بنویسید.

فریمورک LangChain مشکل اصلیش سطح بالای انتزاع (high level of abstraction) هست. این فریمورک منطق اصلی رو پشت کلاس‌ها و متدهای خودش مخفی می‌کنه و این باعث می‌شه introspection یا همون بازبینی عملکرد داخلی سیستم، به شدت سخت بشه. مثلا فهمیدن اینکه پرامپت نهایی که به مدل ارسال شده دقیقاً چی بوده، کار ساده‌ای نیست. این "جادو" هزینه داره: سربار محاسباتی و حافظه بیشتر، و سختی در دیباگ کردن. LangGraph تلاشی برای حل این مشکله؛ با تبدیل کردن جریان کار به یک گراف صریح (explicit graph)، کنترل بیشتری روی control flow به دولوپر می‌ده. در واقع شما یک state machine تعریف می‌کنید. چالش فنی LangGraph اینه که هنوز جدیده، ابزارهای جانبی و مستندات کاملی نداره و پیچیدگی مدیریت گراف به عهده خود شماست.

ابزار LlamaIndex معماریش کاملاً داده-محور (data-centric) هست و برای پایپ‌لاین‌های ingestion و retrieval در RAG بهینه‌سازی شده. انتزاع‌های اصلیش مثل Index و QueryEngine برای این کار طراحی شدن. نقطه ضعف فنیش اینه که قابلیت‌های agentic اون به اندازه بخش retrieval توسعه پیدا نکرده. اگه بخواید یک ایجنت با منطق پیچیده و ابزارهای متنوع بسازید، ممکنه معماری LlamaIndex محدودتون کنه.

در مورد Haystack باید گفت که یک فریمورک پایپ‌لاین-محور (pipeline-centric) هست. شما یک Pipeline از Node های مختلف می‌سازید که هرکدوم یک وظیفه مشخص دارن. این معماری ماژولار و شفاف، دیباگ کردن رو ساده می‌کنه. اما برای ساخت ایجنت‌های پیچیده که نیاز به حلقه‌های منطقی (reasoning loops) و مدیریت حافظه مکالمه دارن، Haystack ابزارهای آماده کمتری ارائه می‌ده و باید منطق رو به صورت سفارشی در Node های خودتون پیاده‌سازی کنید.

فریمورک‌هایی مثل CrewAI و AutoGen یک پارادایم سطح بالاتر برای سیستم‌های چند-ایجتی (multi-agent systems) ارائه می‌دن. مشکل فنی این رویکرد، نبود observability و کنترل دقیق روی تعاملات بین ایجنت‌هاست. وقتی چندین ایجنت با هم شروع به کار می‌کنن، فضای حالت (state space) سیستم به شدت پیچیده می‌شه و دیباگ کردن اینکه چرا یک ایجنت تصمیم اشتباهی گرفته، تقریباً غیرممکنه. این‌ها بیشتر برای کارهای تحقیقاتی و اتوماسیون‌های خاص مناسبن تا اپلیکیشن‌های پروداکشن که نیاز به پایداری و رفتار قابل پیش‌بینی دارن.

پلتفرم‌های low-code مثل Langflow و Dify.ai برای پروتوتایپینگ سریع عالین، ولی از نظر مهندسی نرم‌افزار مشکلات جدی دارن. بزرگترین مشکل، عدم سازگاری با فرآیندهای استاندارد CI/CD و version control هست. مدیریت تغییرات، تست‌نویسی و همکاری تیمی روی یک فلو-چارت گرافیکی بسیار سخت‌تر از کد هست. این ابزارها برای رسیدن به پیچیدگی‌های دنیای واقعی، مقیاس‌پذیر نیستن.

در نهایت، ابزارهای تخصصی و مینیمال هم جایگاه خودشون رو دارن. Vanna فقط برای Text-to-SQL طراحی شده و معماریش برای همین کار بهینه شده. txtai و smol-agents هم فلسفه مینیمالیسم دارن. چالش فنی smol-agents عدم پشتیبانی نیتیو از async هست که برای ساخت اپلیکیشن‌های I/O-bound مقیاس‌پذیر یک محدودیت جدیه.

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

🛠 Join @LLMEngers Community

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

🛠 Join @LLMEngineers Community

یه بنچمارک برای long context به اسم Fiction.LiveBench هست که نشون می‌ده کدوم مدل‌ها واقعاً می‌تونن محتوای طولانی رو بفهمن.

عملکرد اکثر مدل‌ها، به خصوص مدل‌های open-source، با افزایش طول متن به شدت افت می‌کنه. این یعنی پشتیبانی از یک context window بزرگ، به هیچ وجه تضمینی برای فهم عمیق محتوا نیست.

مدل gpt-oss-120b یه مثال بارزه. با اینکه مدل بزرگیه، عملکردش با افزایش کانتکست به سرعت سقوط می‌کنه و توی 8k توکن به زیر ۵۰٪ دقت می‌رسه. این نشون می‌ده برای کارهایی که نیاز به استدلال و درک عمیق در متن‌های طولانی دارن، هنوز راه زیادی در پیش داره.

در مقابل، مدل‌های proprietary مثل gpt-5 و gemini-2.5-pro پایداری فوق‌العاده‌ای دارن و حتی در کانتکست‌های بالای 120k توکن، دقت بالایی رو حفظ می‌کنن.

به نظر من، این نوع ارزیابی‌ها واقعیت مدل‌ها رو بهتر نشون می‌ده. توانایی reasoning و comprehension در یک long context چالش اصلیه، نه فقط داشتن یک پنجره کانتکست بزرگ.

🛠 Join @LLMEngineers Community

یه مدل جدید برای ادیت عکس اومده به اسم Qwen-Image-Edit که مستقیم روی تسک‌های ویرایش تصویر تمرکز کرده. کاربرد اصلیش اینه که می‌تونی با دستورات متنی، تغییرات دقیق و کنترل‌شده‌ای روی عکس‌ها اعمال کنی، مخصوصاً وقتی پای ویرایش متن داخل عکس وسط باشه.

مدل Qwen-Image-Edit بر پایه‌ی مدل بزرگ‌تر Qwen-Image با ۲۰ میلیارد پارامتر ساخته شده. معماری این مدل برای کنترل دقیق روی ویرایش، یه رویکرد هوشمندانه داره. تصویر ورودی به دو بخش داده می‌شه:
۱. یک بخش میره به Qwen2.5-VL که یک مدل ویژن-زبان هست. این قسمت مسئول درک معنایی و مفهومی تصویره. یعنی مدل می‌فهمه توی عکس چه خبره و دستور شما برای تغییر، چه مفهومی داره. این برای کنترل Semantic Editing استفاده می‌شه.
۲. بخش دوم میره به یک VAE Encoder. این قسمت روی ظاهر بصری و جزئیات سطح پایین تصویر تمرکز می‌کنه. هدفش اینه که مناطقی از عکس که قرار نیست تغییر کنن، دست‌نخورده باقی بمونن. اینم برای کنترل Appearance Editing هست.

خروجی این دو انکودر با هم به مدل اصلی که یک Multimodal Diffusion Transformer یا MMDiT هست، داده می‌شه. اینطوری مدل می‌تونه بین حفظ جزئیات اصلی تصویر و اعمال تغییرات معنایی، تعادل برقرار کنه.

قابلیت‌های اصلی که ارائه می‌ده به این شکله:

ویرایش معنایی (Semantic Editing): برای تغییرات سطح بالا مثل عوض کردن استایل هنری عکس (مثلاً به سبک استودیو جیبلی)، چرخوندن اشیاء توی صحنه (Novel View Synthesis) یا حتی خلق کاراکترهای جدید بر اساس یک IP اولیه. اینجا کل پیکسل‌های عکس می‌تونه تغییر کنه ولی مفهوم اصلی حفظ می‌شه.

ویرایش ظاهری (Appearance Editing): برای تغییرات دقیق و محلی. مثلاً اضافه کردن یا حذف یک شیء، تغییر پس‌زمینه، یا عوض کردن رنگ لباس. نکته کلیدی اینه که بقیه‌ی قسمت‌های عکس کاملاً ثابت باقی می‌مونن.

ویرایش دقیق متن: این یکی از نقاط قوت اصلی این مدله. می‌تونه متن‌های انگلیسی و چینی رو داخل عکس‌ها ویرایش، حذف یا اضافه کنه و سعی می‌کنه استایل، فونت و اندازه‌ی متن اصلی رو هم حفظ کنه. این قابلیت توی مدل‌های غربی معمولاً ضعیفه. می‌شه به صورت زنجیره‌ای (Chained Editing) هم برای اصلاح خطاهای تایپی یا نوشتاری در تصاویر استفاده کرد.

مدل فقط یک سری پیکسل رو عوض نمی‌کنه، بلکه واقعاً می‌فهمه چه چیزی رو باید تغییر بده و چه چیزی رو باید ثابت نگه داره. عملکردش توی بنچمارک‌های GEdit و ImgEdit هم قوی بوده و در سطح مدل‌های SOTA مثل GPT-4o و FLUX.1 قرار گرفته.

📃 صفحه مدل در Hugging Face

🛠 Join @LLMEngineers Community

بر اساس تجربه تیم سازنده cline، که یک ایجنت کدنویسی پیشرفته برای VSCode هست، سه تا ویروس فکری رایج تو ساختن AI Agents وجود داره. این ایده‌ها روی کاغذ هوشمندانه به نظر میان، ولی در عمل کار نمی‌کنن.

۱. ارکستراسیون چند ایجنتی (Multi-Agent Orchestration)
این دیدگاه علمی-تخیلی که یک ایجنت اصلی، دسته‌ای از زیر-ایحنت‌ها (مثلاً ایجنت تحلیلگر، ایجنت تحقیق و...) رو مدیریت کنه و نتایج رو با هم ترکیب کنه، در عمل جواب نمیده. بیشتر کارهای مفید و واقعی ایجنت‌ها به صورت single-threaded انجام میشه.
پیاده‌سازی ارکستراسیون‌های پیچیده، فقط به سردرگمی و پیچیدگی کد اضافه می‌کنه و تفسیر رفتار مدل رو هم سخت‌تر می‌کنه، بدون اینکه ارزش واقعی تولید کنه. به اندازه کافی سخت هست که مدل رو تو یک مسیر واحد به درستی هدایت کنیم، چه برسه به مدیریت چندین ایجنت موازی. در عمل، چیزی که به عنوان «رهبر ایجنت» و «زیر-ایحنت» تو مقالات می‌بینیم، بیشتر شبیه یک ترد اصلی با چند tool call متوالی هست.

۲. بازیابی اطلاعات (RAG) برای ایجنت‌های کدنویسی
این ایده که RAG می‌تونه به ایجنت‌ها درک عمیقی از کدبیس بده، یک ویروس فکریه. در عمل، ابزارهای ساده‌تری مثل grep اغلب بهتر کار می‌کنن، مخصوصاً برای ایجنت‌های کدنویسی.
مشکل اصلی اینه که RAG (مشخصاً وقتی از Vector DB ها استفاده میشه) کدهای پراکنده و بی‌ربط رو به مدل میده که به یک "فهم" یکپارچه از کد منجر نمیشه. رویکرد بهتر اینه که مدل مثل یک برنامه‌نویس واقعی عمل کنه: فایل‌ها رو لیست کنه، با grep جستجو کنه و بعد کل فایل‌های مرتبط رو بخونه. اینطوری کانتکست کامل رو در اختیار داره، نه فقط چند تکه کد که از نظر وکتوری شبیه بودن.

۳. دستورالعمل‌های بیشتر = نتایج بهتر
این تصور که با اضافه کردن دستورالعمل‌های زیاد به system prompt، مدل هوشمندتر و قابل کنترل‌تر میشه، کاملاً اشتباهه. پر کردن پرامپت با دستورالعمل‌های زیاد، مدل رو با اطلاعات متناقض و اضافی گیج می‌کنه و باعث میشه خروجی غیرقابل پیش‌بینی بشه.
برای مدل‌های پیشرفته امروزی، بهتره زیاد در مسیرشون قرار نگیریم و اجازه بدیم کارشون رو بکنن. به جای "داد زدن" سر مدل با پرامپت‌های طولانی، باید توکن‌ها رو با دقت و به صورت بهینه مصرف کرد. این پرامپت‌های سنگین شاید برای مدل‌های قدیمی‌تر مفید بودن، ولی برای مدل‌های جدید کارایی ندارن.

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

منبع

🛠 Join @LLMEngineers Community

این روزها ساخت یه دستیار صوتی محاوره‌ای که کاملاً روی دستگاه خودتون و حتی روی 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