🎯 100 Days of Reading LLM Papers Challenge

Day 2: Artificial Neural Networks for Beginners

🔗 https://arxiv.org/pdf/cs/0308031

Additional Resources:
⦁ 📄 Article: Neural Network Fundamentals
⦁ 🎬 Playlist: Neural networks, 3Blue1Brown
⦁ 🎬 Playlist: Neural Networks: Zero to Hero, Andrej Karpathy

🛠 @LLMEngineers

سریع‌تر یا دقیق‌تر؟ بین Kimi K2 و Grok-4 ⚔️

خلاصه بگم: طبق بنچمارک Stagehand که برای اتوماسیون مرورگره، مدل چینی Kimi K2 با اینکه دقتش *فقط کمی* از Grok-4 پایین‌تره، سرعت Inferenceـش (روی LPU های Groq البته) هفت برابر بیشتره. یعنی برای تسک‌های real-time یا جاهایی که latency مهمه، Kimi یه غول به حساب میاد.

این کندی Grok-4 اتفاقی نیست. خود ایلان ماسک هم توییت زده و اعتراف کرده که مدلشون زیادی به مسائل ساده گیر می‌ده. انگار داره با هر پرامپتی مثل یه سوال سخت فلسفی برخورد می‌کنه.

Grok 4 treats everything as a hard question. We are hoping to fix that today." — Elon Musk

این یعنی تیم xAI از مشکل خبر داره و احتمالاً یه آپدیت برای بهینه‌سازی مدل تو راهه. در مقابل، Kimi K2 با ۱ تریلیون پارامتر (البته اگه این ادعا دقیق باشه) توی one-shot coding فوق‌العاده عمل می‌کنه. اگه ضعف Kimi توی reasoning اذیتت می‌کنه، می‌تونی با ابزارهایی مثل mcp-reasoner بهش قابلیت استدلال تزریق کنین.

---
🛠 Join @LLMEngineers Community

میسترال دو تا مدل صوتی speech understanding ریلیز کرده: Voxtral Small و Voxtral Mini. 🎙

یه نسخه ۲۴ میلیارد پارامتری برای پروداکشن و یه ۳ میلیاردی جمع‌وجور برای دیپلوی لوکال و روی دستگاه‌های Edge. هر دو هم اوپن‌سورس شدن که دمشون گرم.

ادعاشون اینه که Whisper large-v3 و Gemini 2.5 Flash رو راحت می‌زنن. روی کاغذ که قوی به نظر می‌رسه، ولی خب... می‌دونیم این بنچمارک‌ها داستان دارن.

برای اجرای لوکال پیشنهاد خودشون `vLLM`ئه.

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

راه حل عملی: میسترال یه API جدا فقط برای ترنسکریپشن داده بیرون. اون نقطه ضعف instruction following رو نداره و فایل هم مستقیم قبول می‌کنه. پس اگه ترنسکریپت تمیز می‌خوای، برو سراغ اون یکی.

لینک دانلود مدل‌ها از هاگینگ‌فیس:
[Small]
[Mini]

🛠 Join @LLMEngineers Community

تیم GLM مدل GLM-4.1V-Thinking رو ریلیز کرده یه VLM که تمرکزش روی multimodal reasoning هست و برای این کار از یه تکنیک جالب استفاده کرده. 🧠

اصل داستان Reinforcement Learning with Curriculum Sampling یا RLCS هست . یعنی چی؟ یعنی مدل رو اول با مسئله‌های آسونتر تمرین می‌دن کم کم مدل که بهتر شد مسئله هارو سخت تر میکنن.
نتیجه‌ش این شده که مدل ۹ میلیارد پارامتری‌شون روی بنچمارک‌ها داره Qwen2.5-VL-72B رو می‌زنه و حتی توی بعضی تسک‌های سخت مثل استدلال علمی (STEM) با GPT-4o رقابت می‌کنه.

نکته‌ی کلیدی که خود تیم هم بهش اعتراف کرده اینه:

یک سیستم پاداش قوی و دقیق برای RL چند-دامنه حیاتی است.

یه reward ضعیف برای یه تسک می‌تونه کل ترینینگ رو ببره هوا.

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

🤗 وزن مدل
📃 مقاله


🛠 Join @LLMEngineers Community

خب، خبر داغ از دنیای اپن‌سورس: دیتاست Nous Hermes 3 ریلیز شده و چند ساعت پیش، خود مدیرعامل هاگینگ‌فیس تویبت زد که شده رتبه‌ی یک ترندینگ توی دیتاست ها.

این دیتاست یه مجموعه‌ی غول‌پیکر با نزدیک به یک میلیون مکالمه‌ی سینتتیک و بدون سانسور که تیم Nous Research برای فاین‌تیون خانواده‌ی Hermes 3 روی Llama 3.1 جمع کرده. تمرکز اصلی روی reasoning، کدنویسی، tool-use و دنبال کردن دقیق دستوراته.

> به قول یکی از سازنده‌هاش، هدفشون «رسیدن به پرفرمنس SOTA بدون سانسور» بوده و به نظر می‌رسه به هدفشون رسیدن.

این دیتاست برای Supervised Fine-Tuning (SFT) عالیه. فقط حواست باشه که بایاس‌های مدل معلم (احتمالاً GPT-4o) ممکنه توش باشه.
دیتاست روی هاگینگ‌فیس موجوده میتونید بررسی و استفاده کنین.

---
🛠 Join @LLMEngineers Community

هفت سال از تولد اولین GPT گذشته و با اینکه کلی مدل خفن مثل DeepSeek-V3 و Llama 4 اومدن، ولی تهِش همشون هنوز یه شباهت‌هایی به جدّ بزرگشون، ترنسفورمر، دارن. سباستین راشکا تو مقاله‌ی جدیدش کالبدشکافی کرده که این مدل‌های مدرن واقعاً چه فرقی با هم دارن.

به قول خودش

شاید تعجب‌آوره که این مدل‌ها از نظر ساختاری چقدر هنوز شبیه به هم هستن.

اما این بهینه‌سازی‌های کوچیک، دنیایی از تفاوت رو رقم می‌زنن. 🧠

مهم‌ترین ترند امسال، بی‌شک Mixture-of-Experts (MoE) هست. به جای اینکه کل مدل رو برای هر توکن لود کنی، فقط چندتا «متخصص» (expert) رو فعال می‌کنی. اینجوری مدل‌هایی مثل DeepSeek-V3 (با ۶۷۱ میلیارد پارامتر) موقع inference فقط ۳۷ میلیارد پارامتر فعال دارن. کاربردش واضحه: مدل‌های غول‌پیکر با هزینه inference پایین‌تر.

توی Attention هم دعواست. DeepSeek به جای GQA (که دیگه استاندارد شده) از Multi-Head Latent Attention (MLA) استفاده می‌کنه. MLA میاد Key و Value رو فشرده می‌کنه تا توی KV cache جای کمتری بگیره؛ یک تیر و دو نشون. از اون‌ور Gemma 3 با Sliding Window Attention حافظه‌ی KV cache رو بهینه می‌کنه. یعنی هر توکن فقط به همسایه‌های نزدیکش نگاه می‌کنه.

یک سری هم رفتن سراغ Normalization. مدل OLMo 2 با جابجایی RMSNorm و اضافه کردن QK-Norm (نرمالایز کردن Query و Key قبل از RoPE) تونسته پایداری ترینینگ رو بالا ببره. حتی SmolLM3 هم پاشو فراتر گذاشته و با NoPE کلاً positional encoding رو حذف کرده و به causal attention mask اعتماد کرده تا مدل ترتیب رو بفهمه.

و در آخر هم Kimi K2 که ترکونده، از نظر معماری تقریباً همون DeepSeek-V3ـه که بزرگ‌ترش کردن. خلاصه که جنگ، جنگِ بهینه‌سازیه، نه انقلاب ساختاری. 🚀

📃 مقاله The Big LLM Architecture Comparison

🛠 Join @LLMEngineers Community

اگه تو حوزه LLMها فعال باشید، حتماً متوجه شدید که موج جدیدی راه افتاده و کلمه‌ی «مهندسی کانتکست» (Context Engineering) همه‌جا شنیده می‌شه. انگار feautre engineering در دوران کلاسیک ML یا prompt engineering در ابتدای راه LLMها، حالا جاشو به این مفهوم جدید داده.

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

البته صدای مخالف هم کم نیست. خیلیا می‌گن: «این که همون RAG خودمونه که لباس پلوخوری پوشیده» یا «شما مهندسای نرم‌افزار، اسم معماری سیستم رو عوض کردین و به اسم خودتون زدین». این نقدها تا حدی درسته. مفاهیمی مثل Separation of Concerns یا مدیریت state، سال‌هاست که در مهندسی نرم‌افزار وجود داره.

پس تفاوت کجاست؟ تفاوت در قلب سیستم ماست. ما دیگه با یه API یا دیتابیس deterministic سروکار نداریم. ما با یک مدل زبانی طرفیم: یک موجود غیرقطعی (non-deterministic) که تمام حافظه فعالش به یک پنجره کانتکست (Context Window) به شدت محدود خلاصه می‌شه. این محدودیت، تمام قواعد بازی رو عوض می‌کنه. مهندسی کانتکست، یعنی طراحی معماری جریان اطلاعات با در نظر گرفتن این تنگنای اساسی.

وقتی کانتکست به درستی مهندسی نشه، با پدیده‌هایی مثل Context Poisoning (یه داده غلط کل استدلال رو خراب می‌کنه) یا Context Distraction (مدل بین انبوه اطلاعات بی‌ربط گم می‌شه) مواجه می‌شیم که عملکرد ایجنت رو نابود می‌کنه.

برای مقابله با این چالش‌ها، ۴ استراتژی اصلی در حال شکل‌گیریه که هرکدوم دنیایی از تکنیک‌ها رو شامل می‌شن:

۱. نوشتن و تداوم (Write & Persist): اطلاعات نباید بی‌دلیل در کانتکست باقی بمونن. باید اون‌ها رو به صورت ساختاریافته در یک حافظه‌ی خارجی persist کرد. این کار با استفاده از یک Scratchpad برای یادداشت‌های موقت حین اجرای تسک، یا پیاده‌سازی Memory بلندمدت (مثل کاری که Reflexion یا Generative Agents کردن) انجام می‌شه. این حافظه می‌تونه یه فایل ساده، یه key-value store یا حتی یک دیتابیس وکتوری باشه.

۲. انتخاب و بازیابی (Select & Retrieve): اینجا جاییه که RAG وارد می‌شه، ولی خیلی پیشرفته‌تر از یه جستجوی ساده‌ی وکتوری. ما در مورد Agentic RAG صحبت می‌کنیم. یعنی بازیابی هوشمندانه‌ی ابزارها (Tool Selection RAG)، خاطرات مرتبط (Memory Retrieval) یا قطعه کدهای لازم برای تسک. تکنیک‌هایی مثل Hybrid Search، Re-ranking و استفاده از Knowledge Graphها برای درک روابط بین داده‌ها، اینجا نقش کلیدی بازی می‌کنن تا فقط مرتبط‌ترین اطلاعات به کانتکست تزریق بشه.

۳. فشرده‌سازی و هرس (Compress & Prune): کانتکست بی‌نهایت نیست. باید دائماً بهینه‌سازی بشه. Summarization یکی از راه‌هاست؛ از خلاصه‌سازی بازگشتی (Recursive Summarization) برای مکالمات طولانی گرفته تا استفاده از یک مدل fine-tune شده فقط برای خلاصه‌سازی خروجی ابزارها (رویکردی که Cognition AI استفاده می‌کنه). در کنارش، Pruning یا هرس کردن هم وجود داره؛ یعنی حذف هوشمندانه پیام‌های قدیمی یا اطلاعاتی که دیگه به درد نمی‌خورن.

۴. ایزوله‌سازی و پارتیشن‌بندی (Isolate & Partition): یکی از بهترین راه‌ها برای مدیریت پیچیدگی، شکستن اون به اجزای کوچکتره. معماری Multi-agent (مثل OpenAI Swarm) همین کار رو می‌کنه. هر ایجنت، کانتکست، ابزارها و حافظه‌ی ایزوله‌ی خودشو داره و فقط روی یه تخصص متمرکز می‌شه. یک رویکرد دیگه، استفاده از محیط‌های اجرایی ایزوله (Sandboxed Environments) هست. در این مدل (که HuggingFace استفاده می‌کنه)، LLM به جای فراخوانی مستقیم API، کدی رو تولید می‌کنه که در یک Sandbox اجرا می‌شه. اینطوری اشیای سنگین (مثل دیتافریم‌ها یا فایل‌های حجیم) هرگز وارد کانتکست مدل نمی‌شن و فقط نتیجه‌ی نهایی بهش برگردونده می‌شه.

نتیجه‌گیری نهایی:
مهندسی کانتکست فقط یک اسم جدید نیست، بلکه نشونه‌ی بلوغ حوزه‌ی ماست. ما از کلنجار رفتن با یک فایل `prompt.txt`، به سمت معماری پایپ‌لاین‌های پیچیده‌ی اطلاعاتی حرکت کردیم. این یعنی ساختن ایجنت‌های هوشمند، روزبه‌روز بیشتر شبیه به مهندسی سیستم‌های نرم‌افزاری پیچیده و کمتر شبیه به هنر و شهود می‌شه.

برای مطالعه عمیق‌تر، این دو مقاله فوق‌العاده‌ان:
https://rlancemartin.github.io/2025/06/23/context_engineering/
https://blog.langchain.com/the-rise-of-context-engineering/

🛠 Join @LLMEngineers Community

یه ابزار اپن‌سورس به اسم MegaParse پیدا کردم که ادعای بزرگی داره: پارس کردن هر نوع داکیومنتی بدون اینکه اطلاعاتی از دست بره. از PDF و Word گرفته تا پاورپوینت و CSV.

قسمت خفنش MegaParseVision هست. این ماژول مستقیم از مدل‌های مولتی‌مودال مثل GPT-4o و Claude 3.5 استفاده می‌کنه تا ساختار داکیومنت رو "ببینه". یعنی دیگه لازم نیست با جدول‌ها و نمودارها کشتی بگیری. خود مدل محتوا رو درک می‌کنه. تستش کردم، برای استخراج جدول از چندتا PDF سنگین واقعاً خوب جواب داد.

توی بنچمارک‌های خودشون، ابزارهای معروفی مثل unstructured و llama_parser رو با اختلاف شکست دادن. البته که بنچمارک رو خودشون منتشر کردن، ولی همین که جرئت کردن این مقایسه رو بذارن یعنی به کارشون ایمان دارن.

ابزار هنوز کاملاً پایدار نیست و بخش‌هایی مثل خروجی ساختاریافته (Structured Output) هنوز در حال توسعه‌ست، ولی پتانسیلش بالاست.

💻 https://github.com/QuivrHQ/MegaParse

🛠 Join @LLMEngineers Community

این عکس اومده اکتیویشن فانکشن‌ها رو به رقص تشبیه کرده. ایده‌ش برای یه مبتدی بامزه‌ست؛ از Step که رباتیه تا Sigmoid که نرمه.
فانکشن‌های Sigmoid و Tanh، با اون مشکل معروف vanishing gradients، رسماً مدل‌های عمیق رو فلج می‌کنن. امروز فقط ته یه شبکه برای طبقه‌بندی باینری یا توی گیت‌های یک RNN کلاسیک پیداشون می‌کنی. خودکشیه اگه توی لایه‌های اصلی بذاریشون.

اصل کار هنوز با ReLU و فک و فامیلشه (Leaky, PReLU). سریع و بی‌دردسر. تنها ریسکش اینه که نورون‌ها بمیرن (Dying ReLU Problem) و دیگه یاد نگیرن. برای اکثر CNNها هنوزم انتخاب اوله.

اما تو دنیای LLMها، بازی فرق کرده. اینجا GeLU و Swish و به‌خصوص نسخه‌های ترکیبی مثل SwiGLU حکمرانی می‌کنن. اینا ورژن‌های اسموث و پیوسته‌ی ReLU هستن که به گرادیان اجازه‌ی جریان بهتری می‌دن و برای معماری Transformer بهینه‌ترن. Llama 3 و DeepSeek و Qwen هم از همین SwiGLU استفاده می‌کنه که نشون می‌ده چقدر قضیه جدیه. البته گوگل با Gemma یه ذره متفاوت عمل کرده و از GeGLU استفاده می‌کنه که همین منطق رو با GELU پیاده کرده.


🛠 Join @LLMEngineers Community

بنظر میاد هنوز کلی راه مونده تا AGI.

فرانسوا شوله (François Chollet)، نسخه جدید بنچمارک ARC-AGI-3 رو منتشر کرده. هدف این بنچمارک تست AGI واقعیه، نه حفظیات و الگوهای تکراری.

تفاوت بزرگ این نسخه با قبل اینه که دیگه استاتیک نیست؛ تبدیل شده به چندتا مینی‌گیم تعاملی. ایجنت AI باید خودش با آزمون و خطا قوانین بازی رو کشف کنه و هدف رو بفهمه. دقیقاً مثل کاری که ما آدما وقتی با یه بازی جدید روبرو می‌شیم انجام می‌دیم.

نتیجه؟ فاجعه‌بار برای AIها! آدما بازی‌ها رو تو چند دقیقه حل می‌کنن، ولی تا این لحظه هیچ مدل AI نتونسته حتی یه امتیاز بگیره. این نشون می‌ده سیستم‌های فعلی چقدر تو استدلال انتزاعی ضعیفن و بیشتر یه ماشین پیشرفته‌ی تطبیق الگو هستن تا یه موجود متفکر.

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

📃 https://arcprize.org/

🛠 Join @LLMEngineers Community

🧠 چرا مدل‌های Claude انتروپیک اینقدر خوبن؟ شاید چون پایه‌ای‌ترین کار رو درست انجام می‌دن: `Instruction Following`

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

مثلاً به مدل بگی: «برای پاراگراف اول از قانون X استفاده کن، ولی برای پاراگراف دوم قانون Y رو اعمال کن.» اکثر مدل‌های اپن‌سورس اینجا به هم می‌ریزن و یا فقط قانون اول رو اعمال می‌کنن یا کلاً قاطی می‌کنن.

ریشه‌ی این مشکل چیه؟ یه چیزی به اسم State Tracking.
یعنی مدل نمی‌تونه «وضعیت» (state) و قواعدی که بهش دادی رو در طول تولید متن حفظ کنه. اسم یه شخصیت رو توی داستان عوض می‌کنی، وسط راه یادش می‌ره. جنسیت رو تغییر می‌دی، قاطی می‌کنه. نمی‌تونه context رو بین بخش‌های مختلف خروجی حفظ کنه.

📉 این مشکل معماریه یا مشکل آموزش؟

یه عده سریع می‌پرن وسط و می‌گن این یه ضعف ذاتی و معماری تو مدل‌های ترنسفورمره (شبیه به بحث‌های Reversal Curse که آکادمیک‌ها دوست دارن).

اما دیدگاه عملی‌تر و به نظر من درست‌تر اینه که این یه post-training skill issue هست. یعنی مشکل از خود معماری نیست؛ مشکل از کیفیت پایین دیتا و پروسه‌های fine-tuning (مثل SFT و RLHF) هست. این یه مهارته که باید بعد از pre-training به مدل تزریق بشه.

🎯 راه حل چیه؟
استفاده از Reinforcement Learning (RL) با محیط‌هایی که مشخصاً برای تست و بهبود instruction following طراحی شدن. دقیقاً همون کاری که انتروپیک استادشه.

این نشون می‌ده چرا وقتی با مدل‌های اپن‌سورس (مخصوصاً مدل‌های کوچیک‌تر مثل خانواده Llama 3 8B یا Mistral 7B) کار می‌کنید، حس می‌کنید دستوراتتون رو نادیده می‌گیرن. این اتفاقی نیست، یه چالش اساسیه. طرف داشته با یه مدل 24B کار می‌کرده و دیده گند می‌زنه، تهش برگشته سراغ DeepSeek v3 که ظاهراً تو این زمینه بهتر عمل می‌کنه.

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

🛠 Join @LLMEngineers Community

خب، همه RAG رو می‌شناسن ولی ۹۹٪ پیاده‌سازی‌هاش یه جای کارشون می‌لنگه. اینم یه لیست از ۱۰ تا گندکاری رایج تو سیستم‌های RAG که باید حواستون باشه توی پاچه‌تون نره.

۱. هذیون‌گویی (Faithfulness):
علائمش اینه که مدل از خودش فکت می‌سازه یا به منابعی ارجاع می‌ده که اصلاً ربطی به موضوع ندارن. مشکل اصلی اینه که Retriever شما داره آشغال تحویل LLM می‌ده.
درمانش: یه faithfulness score توی پایپ‌لاین ارزیابی‌تون بذارید و تا از یه حدی بالاتر نرفت، ریلیز نکنید.

۲. جواب‌های بی‌خاصیت (Helpfulness):
علائمش اینه که جواب درسته ولی به درد نمی‌خوره. مثلاً میگه «جواب در بخش ۳ موجوده». 🤦‍♂️
درمانش: مدل رو با دیتاست‌های instruction-tuning چند مرحله‌ای (multi-turn) و مخصوص دامنه‌ی خودتون fine-tune کنید تا یاد بگیره مکالمه کنه.

۳. بازیابی ضعیف (Low Recall):
یعنی جواب توی دیتابیس شما هست ولی Retriever پیداش نمی‌کنه و مدل میگه «نمی‌دونم».
درمانش: از Hybrid Search (ترکیب جستجوی وکتوری با متنی مثل BM25) و یه Cross-Encoder Reranker آخرش استفاده کنید تا تیر خلاص رو بزنه.

۴. چانک‌بندی افتضاح (Sub-optimal Chunking):
تقسیم کردن داکیومنت‌ها بر اساس تعداد کلمات یه اشتباه مرگباره. ساختار معنایی متن از بین میره.
درمانش: از Semantic Chunking استفاده کنید و متادیتای هر چانک (مثل عنوان بخش) رو حتماً ذخیره کنید.

۵. افت کیفیت Embeddingها:
اگه از embedding modelهای عمومی برای دیتای تخصصی (مثلاً پزشکی یا حقوقی) استفاده کنید، گند می‌زنید.
درمانش: مدل embedding رو روی دیتای دامنه‌ی خودتون fine-tune کنید. این کار زمین تا آسمون کیفیت رو عوض می‌کنه.

۶. رنکینگ ضعیف (Weak Re-ranking):
یعنی کلی چانک مرتبط پیدا می‌شه، ولی بی‌ربط‌ها میان اول لیست و پرامپت رو خراب می‌کنن.
درمانش: یه Cross-Encoder Reranker (مثلاً Cohere) بذارید تا بهترین‌ها رو سوا کنه و نویز رو کم کنه.

۷. دیتابیس تاریخ‌گذشته (Stale Indexes):
یعنی مدل به قوانین قدیمی شرکت ارجاع می‌ده چون دیتابیس شما آپدیت نیست.
درمانش: یه مکانیزم برای آپدیت لحظه‌ای یا روزانه‌ی Vector Database بذارید (مثلاً با CDC).

۸. کندی سیستم (Latency):
یعنی جواب‌ها یا کندن یا بی‌دقت. یه بده‌بستان همیشگی.
درمانش: از Caching برای کوئری‌های تکراری و معماری چندمرحله‌ای (pre-filtering -> search -> reranking) استفاده کنید.

۹. سرریز شدن کانتکست (Context Overflow):
اگه ورودی از Context Window مدل بزرگتر باشه، مدل بی سروصدا یه تیکه‌ای از آخرش رو حذف می‌کنه و جواب ناقص می‌ده.
درمانش: یه قانون سرانگشتی میگه بیشتر از ۶۰-۷۰٪ کانتکست رو با ورودی پر نکنید.

۱۰. ریسک‌های امنیتی (Privacy Risks):
یعنی اطلاعات محرمانه شرکت یا کاربرها لو میره یا یه نفر با تزریق داکیومنت مسموم، سیستم رو به فنا می‌ده.
درمانش: قبل از ایندکس کردن، دیتای حساس (PII) رو حذف کنید و مکانیزم‌های کنترل دسترسی بذارید.

به نظر من، بزرگترین تله اینه که فکر کنی RAG یه جعبه‌سیاهه که خودش کار می‌کنه. هر کدوم از این مراحل یه دنیای بهینه‌سازی داره و اگه به جزئیاتش مسلط نباشی، یه سیستم پر از توهم و جواب‌های بی‌ربط تحویل می‌گیری. ☠️

🛠 Join @LLMEngineers Community

چطور میشه غول ۱ تریلیون پارامتری Kimi K2 رو روی کمترین سخت‌افزار ممکن دیپلوی کرد و تو پروداکشن ازش سرویس گرفت؟ 🤔

یه مقاله نوشتم که یه نقشه راه عملی برای دیپلوی Kimi K2 با vLLM رو از اول تا آخر توضیح میده. این مقاله حاصل جمع‌بندی داکیومنت‌های خود Moonshot و تجربه‌های کاربرا توی تو ردیت و... هست.

تو این مقاله چی پیدا می‌کنید؟
* چرا دیپلوی Kimi K2 انقدر سخته (حتی با اینکه MoE هست).
* معرفی گزینه‌های مختلف دیپلوی: از کلاستر 8xH200 تا یه کارت 4090 خونگی.
* یه دستورالعمل آماده برای راه‌اندازی روی ۲ تا A100 (اقتصادی‌ترین حالت پروداکشن).
* نکات کوانتاز، پارامترها و آماده‌سازی برای پروداکشن.

خلاصه هرچی برای دیپلوی این مدل لازم دارید، از تجربه عملی تا کد آماده، تو این مقاله هست.

📃 How to Deploy Kimi K2 on vLLM

🛠 Join @LLMEngineers Community

بچه‌ها، من این نقشه راه یادگیری هوش مصنوعی حوزه مدل های زبانی (LLMs) رو برای مسیر یادگیری خودم طراحی کردم، گفتم با شما هم به اشتراک بذارمش.

یه مسیر کامله که از صفر شروع میکنه تا معماری ترنسفورمر و آماده‌سازی دیتا و تا آموزش مدل، RAG، ایجنت‌ها و LLMOps میره.
LLMs: from Foundation to Production

مدام داره بهتر و کامل‌تر میشه. اگه دوست داشتید یه نگاهی بهش بندازید:

https://mshojaei77.github.io/roadmap

نسخه ساده و گرافیکی:
https://mshojaei77.github.io/mini_roadmap.html

🛠 Join @LLMEngineers Community

علی‌بابا یه آپدیت مهم برای مدل غول‌پیکر Qwen3-235B خودش منتشر کرده.

مهم‌ترین تغییر اینه که تیم Qwen حالت hybrid thinking رو از مدل حذف کرده. قبلاً مدل سعی می‌کرد همزمان هم استدلال کنه (با تگ‌های <think>) و هم جواب مستقیم بده. ولی انگار به این نتیجه رسیدن که یه مدل که می‌خواد همه کار بکنه، تهش هیچ کاری رو عالی انجام نمی‌ده. این یه تصمیم مهندسی کاملاً منطقیه.

حالا قراره دو تا خط تولید مدل داشته باشن:
۱. مدل‌های Instruct: برای جواب‌های مستقیم و سریع.
۲. مدل‌های Thinking: برای وظایفی که نیاز به استدلال قدم‌به‌قدم دارن.

این آپدیت جدید با اسم Qwen3-235B-A22B-Instruct-2507 در واقع اولین خروجی از خط تولید Instruct هست.

خب، تهش چی شد؟ 💥
عملکرد مدل به شدت رفته بالا. بنچمارک‌ها دروغ نمیگن. توی تسک‌های Reasoning مثل AIME و HMMT پیشرفت فضایی داشته و حالا داره با مدل‌های سنگینی مثل Claude 4 Opus و Kimi K2 شاخ به شاخ رقابت می‌کنه و حتی در مواردی جلو زده. امتیاز Arena-Hard v2 هم از ۵۲ به ۷۹ رسیده که نشون میده مدل به شدت بهتر با کاربرها align شده.

یه نگاه فنی‌تر بندازیم:
این مدل یه معماری Mixture of Experts (MoE) داره. یعنی از ۲۳۵ میلیارد پارامتر کل، فقط ۲۲ میلیارد پارامتر در هر لحظه فعاله (۸ expert از ۱۲۸ تا). اینطوری هم قدرت یه مدل غول‌پیکر رو داره و هم سرعت اینفرنسش قابل مدیریته. ضمناً یه نسخه FP8 هم منتشر کردن که برای اجرا به سخت‌افزار کمتری نیاز داره.

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

خبر خوب برای بچه‌های کامیونیتی اینه که تیم `Unsloth` هم داره روی نسخه‌های کوانتایز شده و GGUF کار می‌کنه تا بشه راحت‌تر روی سخت‌افزارهای ضعیف‌تر اجراش کرد.

برای تست سریع می‌تونید از وب‌سایتشون استفاده کنید و اگه می‌خواید باهاش ور برید، روی Hugging Face موجوده.

🤗 دانلود مدل از Hugging Face

🌐 چت با مدل Qwen3

🛠 Join @LLMEngineers Community

علی‌بابا آپدیت جدید Qwen3-235B-A22B رو منتشر کرد
حالت hybrid thinking حذف شد
حالا مدل توی بنچمارک‌هایی مثل AIME و HMMT رقیب جدی Claude 4 و Kimi K2 شده و امتیاز Arena-Hard v2 رو از ۵۲ به ۷۹ رسونده.
🛠 Join @LLMEngineers Community

اینقدر هر روز اسم یه Vector Database جدید میاد که آدم گیج میشه کدوم به دردش می‌خوره. بیاید یه بار برای همیشه این قصه رو جمعش کنیم و ببینیم کی به کیه.👇

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

▫️ وقتی کار جدی شد و خواستی پروژه رو self-host کنی و ببری رو پروداکشن، گزینه‌ها عوض میشه. اینجا سه تا بازیکن اصلی داریم:
* Qdrant:
با سرعت query بالا و فشرده‌سازی داخلیش خیلی محبوبه. برای جایی که پرفورمنس حرف اول رو میزنه، انتخاب اول خیلی‌هاست.
* Milvus:
یه جورایی battle-tested شده و از لپ‌تاپ تا کلاستر جواب پس داده. کامیونیتی قوی‌ای هم پشتشه.
* Weaviate:
کار رو راحت کرده و خودش vectorization و hybrid search (ترکیب BM25 و vector) رو آماده بهت میده. اگه میخوای سریع یه سیستم جستجوی ترکیبی بالا بیاری، عالیه.

▫️ اگه حال و حوصله‌ی سرور و کانفیگ نداری (zero-ops) و میخوای یه سرویس مدیریت‌شده کار رو برات جمع کنه، دو تا غول اصلی داریم:
* Pinecone:
مدلش serverless و auto-scaling داره. یعنی کاری به هیچی نداری، فقط API رو صدا می‌زنی و خودش همه‌چیز رو مدیریت می‌کنه.
* Vespa Cloud:
برای وقتی که میخوای مدل‌های پیچیده‌ی ranking و tensor رو با جستجوی وکتوری ترکیب کنی و یه موتور جستجوی خفن بسازی.

▫️ اگه از قبل Elasticsearch یا Redis داری، نیازی نیست حتماً بری سراغ یه تکنولوژی جدید. Elasticsearch الان vector search رو کنار لاگ و فول‌تکست بهت میده که برای سیستم‌های یکپارچه خیلی خوبه. Redis هم برای کارهای real-time با latency فوق‌العاده پایین و lookupsهای سریع توی مموری، گزینه‌ی خوبیه.

▫️ برای خوره‌ها و اونایی که کنترل کامل میخوان، Faiss هنوز پادشاهه. این یه کتابخونه‌ست، نه دیتابیس کامل. یعنی persistence و filtering و API رو باید خودت دورش بپیچی. ولی خب، دستت تا ته بازه. 🛠

▫️ اینجا یه مقایسه‌ی جامع هم هست که همه رو تو یه جدول گذاشتم:
https://mshojaei77.github.io/vector_dbs.html

🛠 Join @LLMEngineers Community