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

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

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

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

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

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

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

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

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

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

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

🛠 Join @LLMEngineers Community

Interesting 😂😂

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🛠 Join @LLMEngineers Community

MTEB Leaderboard

🛠 Join @LLMEngineers Community

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

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

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

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

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

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

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

🛠 Join @LLMEngineers Community

🛠 Join @LLMEngineers Community

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

🛠 Join @LLMEngineers Community

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

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

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

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

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

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


🛠 Join @LLMEngineers Community

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

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

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

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


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

🛠 Join @LLMEngineers Community

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

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

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

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

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

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

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

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

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

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

🛠 Join @LLMEngineers Community

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

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

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

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

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


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

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

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

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

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

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

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

💻 دمو

🛠 Join @LLMEngineers Community

یه مدل جدید و قدرتمند مولتی‌مودال از سری Qwen به اسم Qwen3-VL ریلیز شده که همزمان تصویر، ویدیو و متن رو به عنوان ورودی می‌گیره و خروجی متنی تولید می‌کنه. کاربرد اصلیش فراتر از VQA ساده رفته و روی تحلیل ویدیوهای خیلی طولانی و کاربردهای ایجنت‌محور برای کنترل رابط کاربری (GUI) تمرکز داره.

این مدل توی دو نسخه ارائه شده:

Instruct:
برای کاربردهای عمومی مثل تشخیص متن از تصویر (OCR)، تحلیل نمودار و داکیومنت و درک رابط کاربری.

Thinking:
برای استدلال‌های پیچیده‌تر، حل مسائل ریاضی و علمی که نیاز به chain-of-thought داره.

معماری این مدل از نوع Mixture-of-Experts یا MoE هست. مدل ۲۳۵ میلیارد پارامتری در مجموع حدود ۲۳۵ میلیارد پارامتر داره، اما در هر forward pass فقط حدود ۲۲ میلیارد پارامتر فعال میشه (A22B). این ساختار که از ۱۲۸ اکسپرت با ۸ اکسپرت فعال تشکیل شده، باعث میشه مدل خیلی بزرگ باشه ولی هزینه محاسباتی برای inference کنترل‌شده باقی بمونه.

از نظر فنی چندتا ویژگی کلیدی داره:

طول زمینه بالا: به صورت نیتیو 256K توکن context داره که با تکنیک‌های scaling مثل RoPE میشه اون رو تا حدود ۱ میلیون توکن افزایش داد. این قابلیت، تحلیل کتاب‌ها یا ویدیوهای چند ساعته رو ممکن می‌کنه.

درک ویدیو: با استفاده از معماری‌هایی مثل Interleaved-MRoPE و Text–Timestamp Alignment، میتونه رویدادها رو با دقت زمانی بالا توی ویدیوهای طولانی تشخیص بده.

درک فضایی: توانایی درک موقعیت اشیاء به صورت دو‌بعدی و سه‌بعدی (3D grounding) رو داره که برای رباتیک و embodied AI مهمه.

OCR پیشرفته: از ۳۲ زبان پشتیبانی می‌کنه و توی شرایط نوری ضعیف، زاویه‌های نامناسب یا روی متون تار عملکرد خوبی از خودش نشون میده.

برای اجرا کردنش به سخت‌افزار سنگین نیاز هست. توی داکیومنت‌هاش به کارت‌های H100 انویدیا با CUDA 12 به بالا اشاره شده و مثال‌های inference با موازی‌سازی روی ۸ تا GPU ارائه شدن. پس برای استفاده عملی باید به فکر زیرساخت بود.

به نظر من، Qwen3-VL یه قدم مهم در دنیای مدل‌های مولتی‌مودال اپن‌سورس (با لایسنس Apache-2.0) محسوب میشه. ترکیب MoE با context طولانی برای ویدیو و قابلیت‌های ایجنت، اون رو به یه ابزار قدرتمند برای ساخت محصولات پیچیده تبدیل کرده، به شرطی که منابع سخت‌افزاری لازم براش فراهم باشه.

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

🛠 Join @LLMEngineers Community

مدل جدید Qwen3-Omni از علی‌بابا منتشر شده و سروصدای زیادی کرده. این مدل یه جهش جدی تو مدل‌های چندوجهی (multimodal) به حساب میاد.

کاربرد اصلیش ساختن دستیارهای هوشمنده که می‌تونن همزمان متن، عکس، صدا و ویدیو رو درک کنن و در لحظه خروجی متنی و صوتی (real-time speech) تولید کنن. دیگه خبری از چسبوندن چندتا مدل مختلف به هم نیست؛ Qwen3-Omni یه مدل واحد و end-to-end هست.

معماری این مدل بر اساس یک ساختار Thinker-Talker مبتنی بر MoE طراحی شده. یه بخش Thinker وظیفه‌ی درک ورودی‌های چندوجهی و استدلال رو بر عهده داره و خروجی‌های سطح بالاش رو به یه بخش Talker می‌ده. بخش Talker هم با استفاده از یه codebook عصبی، صدا رو با latency خیلی پایین (حدود ۲۱۱ میلی‌ثانیه) تولید می‌کنه.

سه تا مدل ۳۰ میلیاردی از این خانواده با لایسنس Apache-2.0 اپن‌سورس شدن:

Qwen3-Omni-30B-A3B-Instruct:
مدل اصلی که هم Thinker و هم Talker رو داره. برای ساخت دستیارهای هوشمند و کاربردهای عمومی طراحی شده و خروجی متن و صدا می‌ده.

Qwen3-Omni-30B-A3B-Thinking:
فقط شامل بخش Thinker می‌شه. برای کارهای سنگین تحلیلی و استدلال چندوجهی که فقط به خروجی متنی نیاز دارن، بهینه شده.

Qwen3-Omni-30B-A3B-Captioner:
یه مدل تخصصی که روی Instruct فاین‌تیون شده تا بتونه برای ورودی‌های صوتی، کپشن‌های دقیق و با کمترین میزان توهم (hallucination) تولید کنه.

برای اجرای این مدل‌ها به سخت‌افزار جدی نیاز هست. مدل Instruct برای پردازش یه ویدیوی ۱۵ ثانیه‌ای حدود ۷۹ گیگابایت VRAM و برای یه ویدیوی ۲ دقیقه‌ای تا ۱۴۵ گیگابایت VRAM مصرف می‌کنه. به همین خاطر، تیم توسعه‌دهنده استفاده از vLLM رو برای اجرا توصیه کرده چون برای مدل‌های MoE بهینه‌تره. پشتیبانی از Transformers هم اضافه شده ولی فعلاً باید از سورس نصب بشه.

به نظر من، Qwen3-Omni یه گام فنی خیلی مهمه، چون مفهوم omni-modal رو به شکل یکپارچه و اپن‌سورس پیاده‌سازی کرده. مدل Captioner به تنهایی یه ابزار خیلی ارزشمند برای جامعه‌ست چون چنین مدل تخصصی و باکیفیتی برای تحلیل صوت کمتر پیدا می‌شه. با این حال، نیاز بالای این مدل‌ها به VRAM، استفاده ازشون رو برای دولوپرهای مستقل و تیم‌های کوچیک تقریباً غیرممکن می‌کنه و بیشتر به درد شرکت‌های بزرگ و آزمایشگاه‌های تحقیقاتی می‌خوره. باید توجه داشت که نسخه‌ی Flash-Realtime که پایین‌ترین latency رو داره، یه سرویس API پولی هست و با مدل‌های اپن‌سورس متفاوته.

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

🛠 Join @LLMEngineers Community

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

اول از همه، راهنمای سریع انتخاب بر اساس موقعیت:

اگه فقط یه اپ دسکتاپ ساده می‌خوای (دانلود، کلیک، چت/API):
برو سراغ LM Studio که هم UI داره هم سرور محلی سازگار با OpenAI. گزینه‌های دیگه Ollama (برای کارای سریع با CLI) و Jan (اپ دسکتاپ اوپن‌سورس) هستن. هر سه عمدتاً از اکوسیستم GGUF و llama.cpp استفاده می‌کنن.

اگه دنبال throughput بالا برای پروداکشن با کلی کاربر هستی: vLLM با تکنیک PagedAttention و continuous batching یه استاندارد صنعتیه. SGLang هم با RadixAttention و بهینه‌سازی‌های خفنش رقیب جدی‌ایه. Text-Generation-Inference (TGI) از Hugging Face هم یه گزینه‌ی قوی برای پروداکشنه.

اگه فقط روی سخت‌افزار NVIDIA کار می‌کنی و دنبال نهایت سرعت و کمترین latency هستی: TensorRT-LLM انتخاب اوله. با بهینه‌سازی‌های سطح پایین مثل Inflight batching و کوانتیزیشن FP8/INT4، بهترین پرفورمنس رو از GPUهای انویدیا بیرون می‌کشه.

اگه روی Apple Silicon (مک) کد می‌زنی: MLX و MLX-LM که خود اپل توسعه داده بهترین گزینه هستن. از Metal و معماری unified memory استفاده می‌کنن و تجربه‌ی روانی رو روی مک فراهم می‌کنن.

اگه می‌خوای مدل رو کامل روی موبایل یا توی مرورگر ران کنی: MLC LLM و WebLLM این کار رو با کامپایل کردن مدل برای اندروید، iOS و WebGPU انجام می‌دن. حتی یه API سازگار با OpenAI سمت کلاینت توی مرورگر ارائه می‌دن.

اگه دنبال یه موتور سبک برای CPU یا اکوسیستم GGUF هستی: llama.cpp خود جنسه. یه موتور سبک C/C++ با پشتیبانی از CUDA, Metal و حتی Vulkan که یه سرور داخلی سازگار با OpenAI هم داره.

اگه یه GPU انویدیای تکی داری و می‌خوای مدل‌های بزرگ رو با کوانتیزیشن 4-bit ران کنی: ExLlamaV2/V3 با کرنل‌های کاستوم CUDA برای فرمت‌های GPTQ/EXL2/EXL3 ساخته شده. سرعتش تو این سناریو فوق‌العاده‌ست.

حالا چندتا نکته‌ی کلیدی که از تجربه میاد:

اول اینکه، هرجا دیدی نوشته "OpenAI-compatible" لزوماً به معنی جایگزینی صددرصدی نیست. سرورهای vLLM و TGI خیلی قوی و قابل اعتمادن. سرور داخلی llama.cpp هم کار راه‌اندازه. ولی مثلاً سازگاری Ollama هنوز experimental محسوب می‌شه و برای کارهای پیشرفته بهتره از API اصلیش استفاده بشه.

دوم اینکه، اکوسیستم‌های کوانتیزیشن با هم فرق دارن. فرمت GGUF مال خانواده‌ی llama.cpp (مثل LM Studio و Ollama) هست. در حالی که سرورهای پروداکشن مثل vLLM و TGI بیشتر با فرمت‌های GPTQ, AWQ یا FP8 که توی safetensors ذخیره شدن کار می‌کنن. نمی‌شه اینا رو جای هم استفاده کرد.

سوم، Speculative decoding که برای افزایش سرعت استفاده می‌شه، همه‌جا به یه شکل پیاده‌سازی نشده و گاهی نیاز به تنظیمات دقیق برای هر مدل داره. توی TensorRT-LLM و SGLang خیلی خوب پیاده‌سازی شده ولی انتظار معجزه نداشته باش.

🛠 Join @LLMEngineers Community

یه گزارش مفصل از خود OpenAI منتشر شده که داده‌های واقعی استفاده‌ی کاربران از ChatGPT رو تحلیل کرده. این گزارش بر اساس میلیون‌ها پیام (البته ناشناس‌سازی شده) نوشته شده و نشون می‌ده مردم واقعاً دارن با این ابزار چیکار می‌کنن.

کاربرد اصلی ChatGPT برخلاف تصور عمومی، اصلاً برای کار نیست. حدود ۷۰ درصد استفاده‌ها کاملاً شخصیه و این سهم روزبه‌روز در حال افزایشه. در حالی که بیشتر تحلیل‌های اقتصادی روی افزایش بهره‌وری تو محیط کار تمرکز دارن، داده‌ها نشون می‌ده ارزش واقعی این تکنولوژی فعلاً تو زندگی روزمره‌ی مردمه.

دسته‌بندی کلی کاربردها به این شکله:
۱. راهنمایی عملی (Practical Guidance): حدود ۲۹٪ کل پیام‌ها. شامل مشاوره، آموزش، ایده‌پردازی و دستورالعمل‌های مختلف.
۲. جستجوی اطلاعات (Seeking Information): حدود ۲۴٪. این بخش یه جایگزین مستقیم برای موتورهای جستجوی سنتیه.
۳. نوشتن (Writing): حدود ۲۴٪. شامل تولید ایمیل، اسناد، خلاصه‌سازی و ترجمه.

دو تا نکته‌ی خیلی جالب هم وجود داره. اول اینکه برنامه‌نویسی فقط ۴.۲٪ از کل استفاده‌ها رو تشکیل می‌ده که با تصور خیلی‌ها که ChatGPT رو ابزار اصلی کدنویسی می‌دونن، در تضاده. دوم اینکه کاربردهای مربوط به روابط عاطفی و همراهی (Companionship) فقط ۱.۹٪ هست که نشون می‌ده هایپ رسانه‌ها در این مورد با واقعیت فاصله داره.

مهم‌ترین کاربرد ChatGPT در محیط کار، نوشتن (Writing) هست که ۴۰٪ پیام‌های کاری رو شامل می‌شه. اینجا یه نکته‌ی خیلی ظریف وجود داره: حدود دو سوم از این درخواست‌های نوشتن، مربوط به ویرایش، نقد، خلاصه‌سازی یا ترجمه‌ی متنی هست که خود کاربر به مدل داده؛ نه تولید محتوای کاملاً جدید از صفر. یعنی بیشتر به عنوان یه دستیار ویراستار فوق هوشمند استفاده می‌شه تا یه تولیدکننده‌ی محتوا.

این گزارش یه دسته‌بندی جدید هم معرفی کرده: Asking در مقابل Doing.

Asking:
وقتی کاربر دنبال اطلاعات یا مشاوره برای تصمیم‌گیری بهتره (حدود ۴۹٪).

Doing:
وقتی کاربر از مدل می‌خواد یه خروجی مشخص مثل کد، ایمیل یا جدول تولید کنه (حدود ۴۰٪).

داده‌ها نشون می‌ده که استفاده‌های نوع Asking سریع‌تر از Doing در حال رشده و رضایت کاربر هم از این نوع تعاملات بیشتره. این یعنی ارزش اصلی مدل‌ها برای کاربر، نه فقط اتوماسیون وظایف، بلکه پشتیبانی از فرآیند تصمیم‌گیریه.

به نظر من، این گزارش تأیید می‌کنه که قدرت اصلی LLMها در حال حاضر، نه جایگزینی انسان (co-worker)، بلکه تقویت توانایی‌های اون (co-pilot) هست. بیشترین ارزش اقتصادی از طریق پشتیبانی در تصمیم‌گیری (decision support) ایجاد می‌شه، مخصوصاً برای نیروهای متخصصی که کیفیت تصمیم‌هاشون مستقیماً روی خروجی کار تأثیر داره.

📃 مقاله

🛠 Join @LLMEngineers Community

یه مقایسه‌ی جالب از روند ساخت LLMها بین سال ۲۰۲۳ و ۲۰۲۵

۱. مرحله Pretraining: تمرکز از دیتا میکس‌های عمومی رفته روی دیتاهای باکیفیت‌تر. اولویت با کد بوده و الان دیگه synthetic data هم بهش اضافه شده.

۲. مرحله Midtraining: این مرحله‌ی جدید، یه جور fine-tuning تخصصی بین pretraining و post-training هست. اینجا قابلیت‌های خاص مثل افزایش طول متن (Context-expansion) یا تمرکز روی تسک‌های استدلالی سنگین (Reasoning heavy) به مدل تزریق می‌شه. به نظر من، این مرحله مهم‌ترین تغییره چون اجازه می‌ده مدل‌ها برای کاربردهای خاص بهینه بشن بدون اینکه نیاز به pretrain از اول باشه.

۳. مرحله Post-training: این فاز هم دقیق‌تر شده. قبلاً کلی‌گویی بود، اما الان به دو بخش مشخص SFT برای یادگیری دنبال کردن دستورات و RL برای هم‌راستاسازی نهایی با ترجیحات انسانی تقسیم شده.

۴. مرحله Model Merging: این تکنیک به عنوان یه مرحله‌ی نهایی و مستقل اضافه شده. به جای ساخت یک مدل غول‌پیکر، چند مدل متخصص رو با هم ادغام می‌کنن تا بهترین قابلیت‌های هر کدوم رو داشته باشن. این روش از نظر محاسباتی خیلی بهینه‌تره.

🛠 Join @LLMEngineers Community