🧠 چرا مدل‌های 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

علی‌بابا دوباره ترکونده و یه مدل کدنویسی Agentic خفن به اسم Qwen3-Coder رو اپن‌سورس کرده.

Qwen3-Coder-480B-A35B-Instruct

▫️ معماری MoE: این مدل ۴۸۰ میلیارد پارامتر داره، اما با معماری Mixture-of-Experts کار می‌کنه و در هر لحظه فقط ۳۵ میلیارد پارامترش فعاله. نتیجه؟ سرعت و پرفورمنس یه مدل غول‌پیکر با هزینه محاسباتی یه مدل خیلی کوچیک‌تر. این یعنی کارایی خالص.
▫️ پنجره کانتکست عظیم: به صورت نیتیو از 256K توکن پشتیبانی می‌کنه و تا 1M توکن هم قابل افزایشه. یعنی چی؟ یعنی می‌تونه یه ریپازیتوری کامل کد رو بخوره و هضم کنه تا یه تسک رو انجام بده. دیگه خبری از تیکه‌تیکه کردن کدها و گم کردن کانتکست نیست.
▫️ عملکرد Agentic: این مدل فقط کد بالا نمیاره، بلکه یه *Agent* واقعیه. یعنی می‌تونه ابزارها رو استفاده کنه، با محیطش (مثلاً یه ریپازیتوری) تعامل کنه، بازخورد بگیره و تصمیم‌گیری کنه. ادعاشون اینه که بهترین مدل کدنویسی اپن‌سورس حال حاضره و داره با Claude Sonnet 4 رقابت می‌کنه، مخصوصاً روی بنچمارک سنگین SWE-bench.

فوت کوزه‌گریشون چیه؟ تمرکز وحشتناک روی Reinforcement Learning. به جای اینکه فقط به مدل بگن کد درست چیه، بهش اجازه دادن توی محیط‌های واقعی (بیش از ۲۰ هزار محیط موازی روی زیرساخت علی‌بابا!) کد بزنه، گند بزنه، یاد بگیره و بهتر بشه. به این میگن Long-Horizon RL. این مدل رو برای حل مسائل پیچیده و چندمرحله‌ای آب‌بندی کرده.

خب چطور ازش استفاده کنیم؟
علی‌بابا یه ابزار CLI به اسم Qwen Code هم منتشر کرده که از Gemini Code گوگل فورک شده. با این ابزار می‌تونید مستقیم توی ترمینال با مدل کار کنید و روی ریپازیتوری‌هاتون تسک‌های پیچیده رو اجرا کنید. خبر خوب اینه که API سازگار با OpenAI هم داره و راحت توی ابزارهایی مثل Ollama و LMStudio هم بالا میاد.

به نظر من، دو تا نکته کلیدی اینجا وجود داره:
۱. آینده با MoE هست: ساختن مدل‌های بزرگ‌تر به روش سنتی داره به بن‌بست سخت‌افزاری می‌خوره. معماری MoE راه حل هوشمندانه برای مقیاس‌پذیریه و Qwen داره نشون می‌ده که این مسیر چقدر موثره.
۲. خداحافظی با Code Generation، سلام بر Code Agents: دوران مدل‌هایی که فقط کد اسنیپت تولید می‌کردن تموم شده. ترند اصلی، ساختن *Agent*‌هاییه که می‌تونن تسک‌های مهندسی نرم‌افزار رو از صفر تا صد انجام بدن. این مدل یه قدم بزرگ تو این مسیره.

این یه حرکت خیلی جدی از طرف علی‌باباست و نشون می‌ده رقابت تو حوزه مدل‌های کدنویسی به شدت داغه. حتماً یه نگاهی بهش بندازید.

📃 بلاگ معرفی کامل

💻 چنتا دمو جالب توی توییتر

🤗 مدل در Hugging Face

🤖 ابزار Qwen Code در گیت‌هاب

🛠 Join @LLMEngineers Community

عملکرد مدل کدنویسی Agentic جدید علی بابا Qwen3-Coder

🛠 Join @LLMEngineers Community

▫️ خیلیا دارن می‌گن این اولین مدل اپن‌سورسیه که جرئت کرده مستقیم خودش رو با یه مدل پولی و خفن مثل Claude Sonnet 4 مقایسه کنه. بعضی دولوپرها، مخصوصاً اونایی که تو دامین‌های خاص (مثلاً توسعه برای Swift) کار می‌کنن، می‌گن تا حالا فقط Sonnet کارشون رو راه مینداخته و حالا یه جایگزین اپن‌سورس دارن. این یعنی یه برد بزرگ برای جامعه اپن‌سورس. 🏆

▫️ اولین واکنش ملت بعد از دیدن سایز مدل: «VRAM من داره زار می‌زنه!». تقریباً همه دارن التماس می‌کنن که نسخه‌های کوانتایز شده یا مدل‌های کوچیک‌تر زودتر منتشر بشه تا بشه روی سخت‌افزارهای مردمی و ابزارهایی مثل Ollama اجراش کرد. این نشون می‌ده جامعه بیشتر از مدل‌های غول‌پیکر، تشنه‌ی مدل‌های بهینه و قابل اجراست.

▫️ ملت سریع رفتن سراغ ابزارهای محبوبشون و شروع کردن به تگ کردن Cursor`، `DeepInfra و OpenRouter. این یعنی بازار به شدت آماده‌ست تا این مدل رو توی ورک‌فلوهای روزمره‌ش جا بده. موفقیت مدل فقط به پرفورمنسش نیست، به اینه که چقدر راحت توی ابزارهای دیگه ادغام بشه.

▫️ خود اکانت رسمی SWE-bench اومده به تیم Qwen تبریک گفته. این یه مهر تایید خیلی مهمه و نشون می‌ده ادعاهای پرفورمنس، الکی و روی هوا نیست.

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

🛠 Join @LLMEngineers Community

🎯 100 Days of Reading LLM Papers Challenge

Day 3: GLU Variants Improve Transformer

🔗 https://arxiv.org/pdf/2002.05202

Additional Resources:
⦁ 📄 Math behind SwiGLU
⦁ 📄 Article: What is SwiGLU? - J. Carlos Roldán

🛠 @LLMEngineers

یه مقایسه‌ی عملی بین مدل Kimi K2 و Claude 3.5 Sonnet برای کدنویسی انجام شده که نتایج جالبی داره:

هدف تست، ساخت یه چت اپلیکیشن با Next.js بوده که قابلیت چت صوتی و یه سری ورک‌فلوهای agentic هم داشته باشه.

نکات کلیدی این مقایسه:
قیمت: این بزرگترین مزیت Kimi K2 هست. توی تستی که انجام شد، با توکن مصرفی مشابه، هزینه Kimi K2 حدود ۰.۵ دلار شد، در حالی که هزینه Claude 3.5 Sonnet حدود ۵ دلار بود. یعنی تقریباً ۱۰ برابر ارزون‌تر.

سرعت: اینجا Sonnet برنده مطلق هست. سرعت تولید توکن Kimi K2 حدود ۳۴ توکن بر ثانیه بود، در حالی که Sonnet با سرعت ۹۱ توکن بر ثانیه کد رو تولید می‌کرد. این یعنی Kimi K2 به شکل قابل توجهی کندتره.

کیفیت کدنویسی Frontend:
برای ساخت چت اپلیکیشن پایه، هر دو مدل خوب عمل کردن. اما Kimi K2 یه مقدار بهتر بود و موفق شد قابلیت چت صوتی رو هم پیاده‌سازی کنه. در مقابل، Sonnet توی پیاده‌سازی این بخش ناموفق بود.

کیفیت کدنویسی Agentic:
برای تسک پیچیده‌تر، یعنی اضافه کردن پشتیبانی از یه پروتکل جدید به اسم MCP با یه کتابخونه‌ی نه چندان قدیمی، هر دو مدل به مشکل خوردن و کد هیچکدوم بدون دستکاری اجرا نشد.
با این حال، کدی که Kimi K2 تولید کرد به یه راه حل کارآمد نزدیک‌تر بود. Sonnet نه تنها کدش کار نکرد، بلکه یه سری خطای false positive هم می‌داد و از SDK اشتباهی استفاده کرده بود.

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

🛠 Join @LLMEngineers Community

علی‌بابا یه مدل تخصصی برای ترجمه به اسم Qwen3-MT معرفی کرده که مستقیماً از طریق API قابل استفاده‌ است. کاربرد اصلیش برای کساییه که نیاز به ترجمه‌ی باکیفیت و قابل کنترل در محصولاتشون دارن. برخلاف سرویس‌های ترجمه‌ی عمومی، این مدل به دولوپر اجازه میده روی خروجی کنترل بیشتری داشته باشه.

نکته‌ی کلیدی این مدل، قابلیت سفارشی‌سازی ترجمه از طریق API هست:
۱- کنترل ترمینولوژی (Terminology Intervention): میتونین یه لیست از کلمات تخصصی و ترجمه‌ی دقیقشون رو به مدل بدین تا توی کل متن، ترجمه‌ی اون کلمات ثابت و مطابق با استاندارد شما باشه. مثلاً برای ترجمه‌ی داکیومنت‌های فنی که یه اصطلاح باید همیشه یکسان ترجمه بشه، این قابلیت خیلی کاربردیه.

۲- حافظه ترجمه (Translation Memory): میشه یه سری جفت جمله-ترجمه‌ی نمونه که از قبل ترجمه شدن رو به مدل داد تا از اون‌ها برای ترجمه‌های جدید الگوبرداری کنه. این کار به حفظ ثبات و سبک ترجمه در متون بلند کمک می‌کنه.

۳- پرامپت‌های دامنه-محور (Domain Prompts): میتونین با یه پرامپت متنی، به مدل بگین که متن مبدأ متعلق به چه حوزه‌ای هست (مثلاً حقوقی، فنی، محاوره‌ای) تا ترجمه با سبک و لحن اون حوزه انجام بشه.

مدل روی ۹۲ زبان، از جمله فارسی (fa)، آموزش دیده. دو نسخه ازش موجوده:
- نسخه‌ی qwen-mt-turbo: بر پایه‌ی معماری MoE ساخته شده، سریع‌تر و خیلی ارزون‌تره (حدود ۰.۵ دلار برای هر یک میلیون توکن خروجی). برای کاربردهای real-time و حجم بالا مناسبه.
- نسخه‌ی qwen-mt-plus: کیفیت بالاتری داره ولی کندتر و گرون‌تره.

نحوه‌ی استفاده ازش هم سرراسته. از طریق یه API که با OpenAI سازگاره، یه درخواست chat.completions.create ارسال میشه. پارامترهای سفارشی‌سازی مثل زبان مبدأ، مقصد و ترمینولوژی‌های خاص، داخل یه دیکشنری به اسم extra_body به درخواست اضافه میشن.

به نظر من، قدرت اصلی Qwen3-MT در همین قابلیت‌های کنترلیه. اینکه مدل صرفاً یه جعبه‌سیاهِ ترجمه نیست و میشه خروجیش رو برای سناریوهای خاص مهندسی کرد، ارزش اصلی رو ایجاد می‌کنه. خیلی از شرکت‌ها با مشکل عدم یکپارچگی در ترجمه‌ی اسامی برند یا اصطلاحات فنی درگیرن که این مدل میتونه حلش کنه.
نقطه‌ی ضعف اصلی اینه که وزن‌های مدل به صورت متن‌باز منتشر نشده. یعنی امکان fine-tune کردن یا اجرای مدل به صورت لوکال وجود نداره و فقط میشه به API علی‌بابا اتکا کرد. ا

📃 وبلاگ معرفی مدل:
https://qwenlm.github.io/blog/qwen-mt/

📃 مستندات API و کد نمونه:
https://alibabacloud.com/help/en/model-studio/translation-abilities

🛠 Join @LLMEngineers Community

علی‌بابا یه مدل جدید از سری Qwen3 داده بیرون که تخصصش reasoning هست: Qwen3-235B-A22B-Thinking-2507. کاربرد اصلی این مدل حل مسائل پیچیده‌ست که نیاز به استدلال مرحله به مرحله داره، مثل مسائل ریاضی، کدنویسی‌های رقابتی و تحلیل‌های علمی.

این مدل یه معماری Mixture-of-Experts داره با ۲۳۵ میلیارد پارامتر که ۲۲ میلیاردش در هر توکن فعال میشه. مهم‌ترین ویژگی‌ این مدل، native بودن حالت "thinking" هست. یعنی دیگه لازم نیست دستی فعالش کنید، خود مدل برای حل مسائل پیچیده از زنجیره‌های استدلال طولانی استفاده می‌کنه تا به جواب دقیق‌تری برسه. در واقع عملکرد مدل توی بنچمارک‌های منطق، ریاضی، کدنویسی و علوم به شکل قابل توجهی بهبود پیدا کرده و با مدل‌های قدرتمند سورس-بسته رقابت می‌کنه.

با اینکه پنجره زمینه یا context window مدل به صورت native تا ۲۵۶ هزار توکن پشتیبانی می‌شه، اما توی API و بعضی پلتفرم‌ها مثل OpenRouter فعلاً تا ۱۳۱ هزار توکن قابل استفاده‌ست. خود تیم Qwen هم توصیه کرده که برای تسک‌های پیچیده که نیاز به reasoning عمیق داره، حتماً context length رو بالای ۱۳۱ هزار توکن تنظیم کنید تا مدل فضای کافی برای "فکر کردن" داشته باشه.

برای اجرا، می‌شه از فریمورک‌هایی مثل vLLM یا sglang استفاده کرد. Unsloth هم GGUF داینامیک براش منتشر کرده که این امکان رو میده تا نسخه ۲-بیتی مدل رو روی سیستمی با ۸۸ گیگابایت رم یکپارچه (unified memory) یا رم معمولی با سرعت بالای ۶ توکن بر ثانیه اجرا کرد. این برای کسایی که دسترسی به کلاسترهای بزرگ ندارن، خوبه.

به نظر من، تیم Qwen داره با سرعت خیلی بالایی مدل‌های SOTA اپن‌سورس رو ریلیز می‌کنه و رقابت رو برای بقیه سخت کرده. اسم مدل‌هاشون (مثلاً همین Qwen3-235B-A22B-Thinking-2507) یکم طولانی و عجیبه، ولی عملکرد، مخصوصاً توی حوزه reasoning، واقعاً قویه و این مدل یه رقیب جدی برای بقیه مدل‌های اپن‌سورس حساب می‌شه. این پیشرفت سریع نشون‌دهنده قدرت آزمایشگاه‌های چینی توی مسابقه هوش مصنوعیه.

📃 مدل اصلی در هاگینگ‌فیس:
https://huggingface.co/Qwen/Qwen3-235B-A22B-Thinking-2507

📃 نسخه FP8 برای مصرف رم کمتر:
https://huggingface.co/Qwen/Qwen3-235B-A22B-Thinking-2507-FP8

📃 گزارش فنی (Technical Report):
https://arxiv.org/abs/2505.09388

🛠 Join @LLMEngineers Community

این چارت، عملکرد مدل جدید علی‌بابا، Qwen3-235B-A22B-Thinking-2507 رو با مدل‌های دیگه مقایسه می‌کنه.

نکته اصلی، جهش عملکرد این نسخه (قرمز) نسبت به نسخه قبلی خودشه (آبی). توی بنچمارک‌های مهمی مثل AIME25 برای ریاضیات، LiveCodeBench v6 برای کدنویسی و Arena-Hard برای همسویی با انسان (alignment)، این مدل جدید تقریباً در تمام موارد در صدر قرار گرفته.

به‌خصوص جهش امتیاز توی LiveCodeBench خیلی قابل توجهه و نشون میده که توانایی کدنویسی مدل به شکل جدی بهتر شده.

به نظر من، این نتایج، Qwen3 رو به عنوان یکی از قوی‌ترین مدل‌های اپن‌سورس در حوزه reasoning تثبیت می‌کنه. مدل حالا دیگه صرفاً یه آلترناتیو نیست، بلکه یه رقیب مستقیم برای مدل‌های بسته مثل Gemini 2.5 Pro و O4-mini محسوب میشه.

🛠 Join @LLMEngineers Community

رویکرد Knowledge Distillation یا به اختصار KD، یه تکنیک برای انتقال دانش از یه مدل بزرگ و قوی (Teacher) به یه مدل کوچیک‌تر و بهینه‌تره (Student). کاربرد اصلیش اینه که مدل‌های غول‌آسا مثل GPT-4 رو که نیازمند منابع محاسباتی سنگین هستن، به نسخه‌های جمع‌وجوری تبدیل کنیم که روی سخت‌افزارهای ضعیف‌تر مثل موبایل یا سرورهای معمولی هم اجرا بشن، بدون اینکه بخش زیادی از عملکردشون رو از دست بدن. این کار هزینه‌های inference رو کم می‌کنه و سرعت رو بالا می‌بره.

اساس کار اینه که مدل Student فقط از روی لیبل‌های واقعی (ground-truth) یاد نمی‌گیره، بلکه تلاش می‌کنه خروجی‌های مدل Teacher رو هم تقلید کنه. این خروجی‌ها فقط جواب نهایی نیستن، بلکه شامل توزیع کامل احتمالاتی روی تمام توکن‌های ممکن (logits) هم میشن. این اطلاعات غنی که بهش "dark knowledge" هم میگن، به Student کمک می‌کنه تا "روش فکر کردن" Teacher رو یاد بگیره، نه فقط جواب درست رو.

چندتا استراتژی اصلی برای این کار وجود داره:

یک. Response-Based Distillation
این روش کلاسیک و ساده‌ترین راهه. اینجا Student سعی می‌کنه توزیع احتمالاتی (logits) خروجی Teacher رو برای هر توکن تقلید کنه. مدل‌هایی مثل DistilBERT از این روش استفاده کردن. این متد از نظر سخت‌افزاری بهینه‌ترینه.

دو. Feature-Based Distillation
اینجا به جای خروجی نهایی، حالت‌های میانی (hidden states) یا attention maps مدل Teacher به Student منتقل میشه. این کار Student رو مجبور می‌کنه که ساختار داخلی و فرآیند استدلال Teacher رو یاد بگیره. این روش برای پر کردن گپ بین یه Teacher خیلی بزرگ و یه Student خیلی کوچیک مفیده.

سه. Instruction & Rationale-Based Distillation
این یکی از موثرترین تکنیک‌ها برای مدل‌های امروزیه. به جای جواب تنها، از Teacher خواسته میشه که مراحل استدلال خودش یا همون Chain-of-Thought (CoT) رو هم تولید کنه. بعد Student روی این دیتاست که شامل دستور -> مراحل استدلال -> جواب نهایی هست، فاین‌تیون میشه. پروژه‌هایی مثل Orca نشون دادن که این روش می‌تونه عملکرد مدل‌های کوچیک در تسک‌های استدلالی رو به شدت بهبود بده. اصل داستان اینه که به جای یاد دادن *جواب نهایی*، به مدل *روش فکر کردن* رو یاد بدی.

گردش کار عملیاتی برای پیاده‌سازی Knowledge Distillation معمولاً اینطوریه:

۱. جمع‌آوری دیتا: یه مجموعه از پرامپت‌ها یا دستورات آماده میشه. این دیتا می‌تونه از دیتاست‌های عمومی مثل Alpaca بیاد یا به صورت مصنوعی با روش‌هایی مثل Self-Instruct تولید بشه.

۲. گرفتن خروجی از Teacher: با استفاده از دیتاست مرحله قبل، از مدل Teacher خروجی گرفته میشه. اینجا تنظیم هایپرپارامترهایی مثل Temperature مهمه. دمای بالاتر (مثلاً T > 1.0) تنوع بیشتری در خروجی ایجاد می‌کنه، در حالی که دمای پایین‌تر (مثلاً T ≈ 0.7) جواب‌های دقیق‌تری میده.

۳. فیلتر کردن و امتیازدهی: خروجی‌های Teacher همیشه بی‌نقص نیستن و ممکنه شامل hallucination یا اطلاعات غلط باشن. به نظر من، مهم‌ترین قسمت داستان همین فیلتر کردنه. با استفاده از روش‌هایی مثل rejection sampling، بررسی `perplexity`، یا فیلترهای مبتنی بر قوانین، خروجی‌های بی‌کیفیت حذف میشن تا Student دیتای تمیزی برای یادگیری داشته باشه.

۴. فاین‌تیون کردن Student: مدل Student روی دیتاست تمیز شده فاین‌تیون میشه. تابع هزینه (loss function) معمولاً ترکیبی از دو بخشه: یکی `Cross-Entropy` روی لیبل‌های واقعی (اگه وجود داشته باشن) و دومی KL Divergence بین خروجی Student و Teacher. تفاوت بین رویکرد black-box (فقط دسترسی به متن خروجی Teacher) و white-box (دسترسی به logits) هم اینجا مشخص میشه.

با وجود تمام مزایا، این روش چالش‌هایی هم داره. بزرگ‌ترین مشکل، انتقال خطاها و hallucination های مدل Teacher به Student هست. اگه Teacher اطلاعات غلط تولید کنه، Student هم همون رو یاد می‌گیره. مسئله‌ی دیگه، "capacity gap" هست؛ یعنی وقتی Student خیلی کوچیک باشه، نمی‌تونه به خوبی از یه Teacher خیلی بزرگ یاد بگیره. همچنین مسائل قانونی مربوط به لایسنس API مدل‌های تجاری مثل GPT-4 هم وجود داره که استفاده از خروجی اون‌ها برای ترین کردن مدل‌های رقیب رو محدود می‌کنه.

📃 مقاله اصلی هینتون در مورد Distillation
Distilling the Knowledge in a Neural Network

📃 مقاله پروژه Orca که از CoT Distillation استفاده کرده
Orca: Progressive Learning from Complex Explanation Traces of GPT-4

🛠 Join @LLMEngineers Community

تیم Qwen از علی‌بابا یه مقاله‌ی جدید داده بیرون به اسم Group Sequence Policy Optimization یا GSPO. این همون الگوریتمیه که برای ترینینگ مدل‌های جدید سری Qwen3 با Reinforcement Learning استفاده شده. هدف اصلیش پایدارتر و بهینه‌تر کردن فرآیند RL برای مدل‌های زبانی بزرگه.

Group Sequence Policy Optimization

تحلیل مقاله رو هم اینجا گذاشتم:
https://news.1rj.ru/str/AI_LLMs/135/3002

🛠 Join @LLMEngineers Community

راهنمای پرامپتینگ مدل جدید GPT-4.1 رو خوندم. این مدل توی کدنویسی و دنبال کردن دستورات، یه سروگردن از GPT-4o بالاتره. برای اینکه بیشترین کارایی رو ازش بکشین، باید یه سری چیزا رو توی پرامپت‌هاتون تغییر بدین. این پست خلاصه‌ی نکات کلیدی و عملی این راهنماست.

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

به نظر من، مهم‌ترین نکته همینه: GPT-4.1 کلمه‌به‌کلمه و به شدت تحت‌تأثیر دستورات شماست. پرامپت‌هایی که برای مدل‌های دیگه بهینه کردین، اینجا ممکنه نتیجه‌ی متفاوتی بدن چون مدل دیگه قوانین ضمنی رو استنباط نمی‌کنه.

راهکارهای عملی برای کار با GPT-4.1:

برای ساخت Agentic Workflows
این مدل برای ساخت ایجنت عالیه. برای اینکه ایجنت شما عملکرد بهتری داشته باشه، سه تا یادآوری کلیدی رو توی System Prompt قرار بدین:
۱. پایداری (Persistence): به مدل بگین که یه ایجنته و باید کار رو تا انتها ادامه بده و زود تسلیم نشه. اینجوری وسط کار کنترل رو به کاربر برنمی‌گردونه.
۲. فراخوانی ابزار (Tool-calling): بهش تأکید کنین که اگه اطلاعات کافی نداره، از ابزارهاش برای خوندن فایل‌ها و جمع‌آوری اطلاعات استفاده کنه و به هیچ وجه حدس نزنه.
۳. برنامه‌ریزی (Planning): از مدل بخواین که قبل و بعد از هر بار استفاده از ابزار، به صورت متنی فکر و برنامه‌ریزی کنه. این کار باعث می‌شه فقط یه سری Tool Call پشت سر هم نباشه و عمیق‌تر فکر کنه.
تیم OpenAI با همین سه دستور ساده، امتیاز SWE-bench Verified رو نزدیک به ۲۰٪ بهتر کرده.

فراخوانی ابزار یا Tool Calls
همیشه ابزارهاتون رو از طریق فیلد tools در API به مدل بدین، نه اینکه توضیحات ابزار رو دستی توی پرامپت تزریق کنین. این روش خطاها رو کم می‌کنه و طبق تست‌هاشون، ۲٪ در معیار SWE-bench عملکرد بهتری داشته. اسم و توضیحات ابزار و پارامترهاش رو واضح بنویسین.

استفاده از Chain-of-Thought
مدل GPT-4.1 به صورت پیش‌فرض reasoning model نیست، یعنی قبل از جواب دادن، زنجیره‌ای از افکار درونی تولید نمی‌کنه. اما شما می‌تونین با پرامپت، وادارش کنین که "بلند فکر کنه". یه دستور ساده مثل "First, think carefully step by step..." در انتهای پرامپت معمولاً کافیه. این کار توی بنچمارک SWE-bench تونسته ۴٪ بهبود ایجاد کنه.

کار با Context طولانی
این مدل تا یک میلیون توکن ورودی رو پشتیبانی می‌کنه. برای عملکرد بهتر در context های طولانی، دستورالعمل‌های اصلی رو هم در ابتدا و هم در انتهای متن context قرار بدین. این روش بهتر از اینه که دستورات فقط در بالا یا فقط در پایین باشن.
برای وارد کردن تعداد زیادی داکیومنت، فرمت XML یا فرمت‌های کاستوم مثل ID: 1 | TITLE: ... | CONTENT: ... عملکرد خیلی بهتری نسبت به JSON دارن. از JSON برای این کار استفاده نکنین چون عملکرد ضعیفی نشون داده.

فرمت‌بندی Diff برای کدنویسی
اگه ایجنت کدنویسی می‌سازین، GPT-4.1 توی تولید diff خیلی بهتر شده. OpenAI یه فرمت پیشنهادی معرفی کرده که مدل به خوبی روش آموزش دیده. ویژگی‌های کلیدی این فرمت اینه که از شماره خط استفاده نمی‌کنه و به جاش از متن اطراف کد برای پیدا کردن محل تغییر استفاده می‌کنه. این کار باعث می‌شه دقت مدل خیلی بالاتر بره.

در کل، این مدل قدرت کنترل بالایی به مهندس می‌ده، به شرطی که دستورات کاملاً واضح، دقیق و بدون ابهام باشن. باید شیوه‌ی پرامپت‌نویسی رو با این ذهنیت جدید تطبیق داد.

📃 Prompting Guide for GPT-4.1:
https://cookbook.openai.com/examples/gpt4-1_prompting_guide

🛠 Join @LLMEngineers Community

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

مسئله اصلی اینه که مدل‌های زبانی بزرگ، با پیش‌بینی توکن به توکن، مجبور میشن کل فایل رو از اول بنویسن. این کار هم توکن زیادی مصرف می‌کنه و هم پنجره‌ی خطا رو بزرگتر می‌کنه. راه حلش، آموزش مدل روی patch-level هست. یعنی مدل یاد می‌گیره به جای توکن بعدی، patch بعدی رو پیش‌بینی کنه. این روش هزینه‌های آموزش رو تا ۵۰٪ کم می‌کنه و خروجی‌ای تولید می‌کنه که مستقیم با git apply کار می‌کنه.

چندتا الگوی طراحی مهم از مقالات اخیر که میشه ازشون استفاده کرد:

* آموزش در سطح پچ: ایده اینه که مدل رو جوری train کنیم که به جای next token، یک patch کامل رو در فرمت unified-diff پیش‌بینی کنه. این کار خروجی رو با ورک‌فلوی توسعه‌دهنده‌ها هماهنگ می‌کنه.

* پرامپت‌نویسی ساختاریافته: برای دقت بالاتر در پیدا کردن محل تغییر، میشه از پرامپت‌های دو بخشی مثل ⟨where, what⟩ استفاده کرد. مثلا به مدل میگی @@ line 42 @@ REPLACE …. این ساختار به مدل کمک می‌کنه دقیقاً بفهمه کجا و چه چیزی رو باید تغییر بده.

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

* تعمیر خودکار باگ: به جای اینکه فقط باگ رو به مدل بدیم، باید خروجی تست‌های fail شده و stack trace ها رو هم به عنوان کانتکست اضافه کنیم. این کار به مدل اجازه میده هم محل باگ رو پیدا کنه و هم خودش patch مناسب رو تولید کنه.

* افزودن هدر: یه ترفند ساده ولی موثر اینه که تو پرامپت از هدرهای diff مثل --- a/foo.py\n+++ b/foo.py استفاده کنیم. این کار به طرز چشمگیری نرخ موفقیت تغییرات چندفایلی رو بالا می‌بره.

مقایسه ابزارهای معروف تو این زمینه هم جالبه:
* Cursor:
این ابزار به خوبی diff رو پیاده‌سازی کرده. تغییرات رو به شکل side-by-side نشون میده و به راحتی میشه هر تیکه (hunk) رو اعمال یا رد کرد. تمام تغییرات رو به شکل commit های تدریجی ذخیره می‌کنه و rollback خیلی ساده‌ست.
* VS Code + Copilot:
متاسفانه Copilot هنوز در سطح بازنویسی کل فایل کار می‌کنه. این باعث میشه diff های شلوغ و کندی تولید کنه و خیلی‌ها برای دیدن تغییرات مجبورن از ابزارهای جانبی استفاده کنن.
* Windsurf:
برای تغییرات چندفایلی و ریفکتورینگ‌های بزرگ تحسین شده، چون کانتکست گلوبال بهتری داره. diff ها رو مستقیم به فرمتی تبدیل می‌کنه که با git سازگاره.

به نظر من، کلید موفقیت اینه که diff رو به عنوان خروجی اصلی و ground-truth در نظر بگیریم. باید مدل رو برای تولیدش آموزش بدیم، در پرامپت ازش بخوایم، اعتبارسنجیش کنیم و در نهایت به کاربر نشونش بدیم. اینطوری هم مدل با ورک‌فلوی واقعی توسعه‌دهنده‌ها هماهنگ میشه، هم هزینه‌ی توکن نصف میشه و هم از دردسرهای بازنویسی‌های مرموز فایل‌ها راحت میشیم.

📃 مقاله آموزش در سطح پچ:
https://arxiv.org/abs/2407.12665

📃 مقاله FineEdit برای ویرایش دقیق:
https://arxiv.org/html/2502.13358v1

📃 مقاله Coeditor برای کانتکست ریپازیتوری:
https://arxiv.org/html/2305.18584v2

🛠 Join @LLMEngineers Community

یه توصیه برای وقتی که به دیوار ریاضیات تو مقاله‌های دیپ‌لرنینگ می‌خورین.

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

فرمول ریاضی رو نباید «خوند». باید باهاش کشتی گرفت. باید تجزیه‌ش کرد. هدف اینه که یه «شهود» بسازی از کاری که اون فرمول انجام میده. لازم نیست تک‌تک نمادهاشو حفظ کنی. باید داستان پشتش رو بفهمی.

این چهارتا قدم رو برو، مشکلت حل میشه:

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

۲. همه‌شون رو از مانیتور بکش بیرون و روی یه تیکه کاغذ واقعی بنویس. این مهم‌ترین بخشه. وقتی فرمول رو کاغذ میاد، دستت بازه. می‌تونی دورش خط بکشی، فلش بزنی، قطعه‌هاشو از هم جدا کنی و کنارش نوت برداری کنی. محدودیت‌های دیجیتال رو نداری و تمرکزت هزار برابر میشه.

۳. حالا وقت ترجمه‌ست. سمبل‌ها رو به مفهوم تبدیل کن.
اول ببین هر حرف یونانی (مثل α, θ, L) چه معنی‌ای داره. معمولاً اول مقاله تو بخش Preliminaries یا Notation توضیح دادن. مثلاً θ همون وزن‌های مدله. α نرخ یادگیریه. L هم تابع هزینه.
بعد ببین اینا چطوری با عملیات ریاضی (+, -, √) به هم وصل شدن. مثلاً وقتی میگه θ_new = θ_old - α * ∇L یعنی وزن‌های جدید میشه وزن‌های قدیمی منهای یه قدم کوچیک در جهت مخالف گرادیان. این یعنی داریم loss رو کم می‌کنیم.

۴. در آخر، از خودت بپرس «خب که چی؟». اون شهود کلی رو بساز.
بعد از اینکه فهمیدی هر تیکه داره چیکار می‌کنه، یه جمله ساده برای خودت بساز. مثلاً الگوریتم QHM چیه؟ یه میانگین وزن‌دار بین آپدیت momentum و آپدیت SGD ساده‌ست. یا QHAdam چیه؟ همین ایده رو برداشته و روی Adam پیاده کرده تا انعطاف بیشتری داشته باشه. همین. حالا دیگه اون فرمول طولانی و ترسناک برات یه مفهوم ساده و قابل فهم داره.

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

🛠 Join @LLMEngineers Community