پارادایم جدیدی به اسم RL with Verifiable Rewards یا RLVR اومده که reward model های یادگیرنده رو با توابع پاداش صریح (explicit reward functions) جایگزین کرده. این کار هم بهینهتره و هم قابل اتکاتر.
تا چند وقت پیش الگوریتم استاندارد برای این کار PPO بود. PPO خیلی سنگین و پیچیدهست چون برای اجرا به سه تا مدل همزمان نیاز داره: مدل اصلی که داره آموزش میبینه، یه کپی ثابت از همون مدل به عنوان رفرنس، و یه مدل سوم به اسم value model که کارش فقط تخمین زدن امتیاز مورد انتظار بود. این ساختار خیلی منابع مصرف میکرد.
الگوریتمهای جدیدتر مثل Group Relative Policy Optimization یا GRPO این بازی رو عوض کردن. GRPO خیلی هوشمندانه اون value model رو حذف کرده. به جاش، مدل چند بار برای یه پرامپت جواب تولید میکنه، reward function شما بهشون امتیاز میده و بعد با یه سری محاسبات آماری ساده مثل میانگین و انحراف معیار، مشخص میکنه کدوم جوابها «بهتر از میانگین» بودن. این سادگی باعث شده RL به قدری بهینه بشه که حتی روی GPUهای رایگان Colab هم قابل اجرا باشه.
به نظر من، سختترین و خلاقانهترین بخش کار، طراحی reward function هست. اینجا جاییه که هنر مهندسی شما مشخص میشه. چند تا مثال عملی:
برای فرمتبندی: میشه با یه regex ساده چک کرد که خروجی فرمت درستی داره یا نه. اگر داشت امتیاز مثبت، نداشت منفی. حتی میشه برای وجود کلیدهای درست ولی مقادیر غلط، امتیاز نسبی داد.
برای ریاضیات: به جای چک کردن جواب نهایی، میشه امتیاز نسبی یا distance-based scoring داد. یعنی هر چی جواب مدل به جواب واقعی نزدیکتر بود، امتیاز بیشتری بگیره.
برای کدنویسی: سادهترین حالت اینه که چک کنیم کد تولید شده بدون خطا اجرا میشه یا نه. if code_runs: return 1 else: return 0. این یه جایزه قابل تایید و شفافه.
یه نکته کلیدی که خیلیا نادیده میگیرن: هیچوقت یه مدل پایه (base model) رو مستقیما با RL آموزش ندین. این کار به پدیدهای به اسم reward starvation منجر میشه. یعنی مدل پایه اینقدر خروجیهای پرت و بیربط تولید میکنه که تقریباً هیچوقت شانسی هم یه امتیاز مثبت نمیگیره و در نتیجه هیچی برای یادگرفتن وجود نداره. راهحل اینه که قبل از شروع RL، مدل رو با یه SFT سریع روی چند صد مثال باکیفیت «آمادهسازی» (prime) کنین تا فرمت کلی جوابها رو یاد بگیره و خروجیهاش حداقل قابل امتیازدهی باشن.
بحث کوانتیزیشن هم خیلی مهمه. میشه مدلها رو تا ۸ برابر کوچکتر کرد در حالی که فقط ۱٪ افت دقت داشته باشن. کلیدش کوانتیزیشن پویا (dynamic quantization) هست. یعنی به جای اینکه همه لایهها رو یکسان کوانتیزه کنیم، لایههای حساستر مثل attention رو با دقت بالاتر نگه میداریم و بقیه رو فشرده میکنیم. برخلاف تصور قبلی، این فقط outlier ها یا مقادیر خیلی بزرگ نیستن که مهمن؛ گاهی مقادیر خیلی کوچیک در لایههای خاصی هستن که تاثیر حیاتی روی دقت دارن (مراجعه کنید به مقاله super weights).
در نهایت، سرعت پردازندههای گرافیکی به خاطر محدودیتهای فیزیکی در دقت عددی (مثل FP4) احتمالاً به زودی به سقف خودش میرسه. این یعنی بهینهسازی نرمافزاری و الگوریتمی از همیشه مهمتر میشه. استفاده از torch.compile میتونه سرعت آموزش رو بالا ببره ولی همیشه سرراست نیست و نیاز به تنظیم دقیق داره.
خلاصه اینکه مسیر پیشرفت الان تو سه تا حوزهست: الگوریتمهای بهینهتر مثل GRPO، تکنیکهای کوانتیزیشن دقیق، و بهینهسازیهای نرمافزاری در سطح کرنل.
📃 منبع : ویدیو ۳ ساعته فنی از Daniel Han، یکی از بنیانگذارهای Unsloth
🛠 Join @LLMEngineers Community
تا چند وقت پیش الگوریتم استاندارد برای این کار PPO بود. PPO خیلی سنگین و پیچیدهست چون برای اجرا به سه تا مدل همزمان نیاز داره: مدل اصلی که داره آموزش میبینه، یه کپی ثابت از همون مدل به عنوان رفرنس، و یه مدل سوم به اسم value model که کارش فقط تخمین زدن امتیاز مورد انتظار بود. این ساختار خیلی منابع مصرف میکرد.
الگوریتمهای جدیدتر مثل Group Relative Policy Optimization یا GRPO این بازی رو عوض کردن. GRPO خیلی هوشمندانه اون value model رو حذف کرده. به جاش، مدل چند بار برای یه پرامپت جواب تولید میکنه، reward function شما بهشون امتیاز میده و بعد با یه سری محاسبات آماری ساده مثل میانگین و انحراف معیار، مشخص میکنه کدوم جوابها «بهتر از میانگین» بودن. این سادگی باعث شده RL به قدری بهینه بشه که حتی روی GPUهای رایگان Colab هم قابل اجرا باشه.
به نظر من، سختترین و خلاقانهترین بخش کار، طراحی reward function هست. اینجا جاییه که هنر مهندسی شما مشخص میشه. چند تا مثال عملی:
برای فرمتبندی: میشه با یه regex ساده چک کرد که خروجی فرمت درستی داره یا نه. اگر داشت امتیاز مثبت، نداشت منفی. حتی میشه برای وجود کلیدهای درست ولی مقادیر غلط، امتیاز نسبی داد.
برای ریاضیات: به جای چک کردن جواب نهایی، میشه امتیاز نسبی یا distance-based scoring داد. یعنی هر چی جواب مدل به جواب واقعی نزدیکتر بود، امتیاز بیشتری بگیره.
برای کدنویسی: سادهترین حالت اینه که چک کنیم کد تولید شده بدون خطا اجرا میشه یا نه. if code_runs: return 1 else: return 0. این یه جایزه قابل تایید و شفافه.
یه نکته کلیدی که خیلیا نادیده میگیرن: هیچوقت یه مدل پایه (base model) رو مستقیما با RL آموزش ندین. این کار به پدیدهای به اسم reward starvation منجر میشه. یعنی مدل پایه اینقدر خروجیهای پرت و بیربط تولید میکنه که تقریباً هیچوقت شانسی هم یه امتیاز مثبت نمیگیره و در نتیجه هیچی برای یادگرفتن وجود نداره. راهحل اینه که قبل از شروع RL، مدل رو با یه SFT سریع روی چند صد مثال باکیفیت «آمادهسازی» (prime) کنین تا فرمت کلی جوابها رو یاد بگیره و خروجیهاش حداقل قابل امتیازدهی باشن.
بحث کوانتیزیشن هم خیلی مهمه. میشه مدلها رو تا ۸ برابر کوچکتر کرد در حالی که فقط ۱٪ افت دقت داشته باشن. کلیدش کوانتیزیشن پویا (dynamic quantization) هست. یعنی به جای اینکه همه لایهها رو یکسان کوانتیزه کنیم، لایههای حساستر مثل attention رو با دقت بالاتر نگه میداریم و بقیه رو فشرده میکنیم. برخلاف تصور قبلی، این فقط outlier ها یا مقادیر خیلی بزرگ نیستن که مهمن؛ گاهی مقادیر خیلی کوچیک در لایههای خاصی هستن که تاثیر حیاتی روی دقت دارن (مراجعه کنید به مقاله super weights).
در نهایت، سرعت پردازندههای گرافیکی به خاطر محدودیتهای فیزیکی در دقت عددی (مثل FP4) احتمالاً به زودی به سقف خودش میرسه. این یعنی بهینهسازی نرمافزاری و الگوریتمی از همیشه مهمتر میشه. استفاده از torch.compile میتونه سرعت آموزش رو بالا ببره ولی همیشه سرراست نیست و نیاز به تنظیم دقیق داره.
خلاصه اینکه مسیر پیشرفت الان تو سه تا حوزهست: الگوریتمهای بهینهتر مثل GRPO، تکنیکهای کوانتیزیشن دقیق، و بهینهسازیهای نرمافزاری در سطح کرنل.
📃 منبع : ویدیو ۳ ساعته فنی از Daniel Han، یکی از بنیانگذارهای Unsloth
🛠 Join @LLMEngineers Community
خب میرسیم به RAG یا همون Retrieval-Augmented Generation. خیلیا فکر میکنن فقط چندتا فایل رو میریزی تو یه Vector Database و یه LLM بهش وصل میکنی و تمام. این تصور اولیه شاید برای یه دموی ساده جواب بده، ولی برای یه محصول واقعی، تازه اول ماجراست.
چندتا نکته کلیدی که کاش روز اول یکی بهم میگفت:
۱. فرایند Chunking یه هنر مهندسیه، نه یه کار روتین.
اینکه چطور داکیومنتهات رو به قطعات کوچیکتر تقسیم میکنی، مستقیم روی کیفیت جواب نهایی تأثیر داره. یه چانک زیادی بزرگ، کلی اطلاعات نامرتبط و نویز وارد کانتکست مدل میکنه. یه چانک زیادی کوچیک هم باعث میشه مفهوم اصلی و ارتباط بین جملات از بین بره. استراتژیهای مختلفی هست، از fixed-size ساده گرفته تا RecursiveCharacterTextSplitter که ساختار متن رو بهتر درک میکنه. به نظر من، نقطه بهینه معمولاً با آزمون و خطا روی دیتای واقعی خودتون پیدا میشه. پارامتری مثل chunk_overlap هم مهمه تا ارتباط معنایی بین چانکهای متوالی حفظ بشه.
۲. کانتکست بیشتر به معنی جواب بهتر نیست.
اینکه ۱۰ تا چانک رو از Vector DB بازیابی کنی و همهشو بریزی تو پرامپت، معمولاً نتیجه رو خراب میکنه. مدلهای زبانی بزرگ با پدیدهای به اسم "Lost in the Middle" درگیرن؛ یعنی به اطلاعاتی که وسط یه کانتکست طولانی قرار گرفته، توجه کمتری میکنن. راه حل اینه که بعد از بازیابی اولیه، یه مرحله Re-ranking اضافه بشه. میتونین از یه مدل سبک cross-encoder یا سرویسهایی مثل Cohere Rerank استفاده کنین تا چانکها رو بر اساس ارتباط واقعیشون با سوال کاربر دوباره مرتب کنین. اینطوری مرتبطترین اطلاعات اول کانتکست قرار میگیره و مدل جواب دقیقتری تولید میکنه.
۳. انتخاب مدل Embedding یکی از حیاتیترین تصمیماته.
مدلهای Embedding مترجمهای دیتای شما به زبان ریاضی هستن. اگه مترجم کارشو بلد نباشه، کل سیستم بازیابی فلج میشه. مدلهای عمومی مثل text-embedding-3-small از OpenAI برای شروع خوبن، ولی برای دیتای تخصصی یا زبانهای خاص، ممکنه بهترین نباشن. باید مدلهای open-source مثل jina embedding رو هم بررسی کرد که روی تسکهای multilingual retrieval عملکرد خوبی نشون دادن. برای انتخاب درست، به معیارهای استاندارد نگاه کنین.
📃 مرجع مقایسه مدلهای Embedding
MTEB Leaderboard
در نهایت، RAG یه سیستم زندهس. باید به طور مداوم کیفیت بازیابی (retrieval precision) و وفاداری پاسخ مدل به منبع (faithfulness) رو ارزیابی کنین.
🛠 Join @LLMEngineers Community
چندتا نکته کلیدی که کاش روز اول یکی بهم میگفت:
۱. فرایند Chunking یه هنر مهندسیه، نه یه کار روتین.
اینکه چطور داکیومنتهات رو به قطعات کوچیکتر تقسیم میکنی، مستقیم روی کیفیت جواب نهایی تأثیر داره. یه چانک زیادی بزرگ، کلی اطلاعات نامرتبط و نویز وارد کانتکست مدل میکنه. یه چانک زیادی کوچیک هم باعث میشه مفهوم اصلی و ارتباط بین جملات از بین بره. استراتژیهای مختلفی هست، از fixed-size ساده گرفته تا RecursiveCharacterTextSplitter که ساختار متن رو بهتر درک میکنه. به نظر من، نقطه بهینه معمولاً با آزمون و خطا روی دیتای واقعی خودتون پیدا میشه. پارامتری مثل chunk_overlap هم مهمه تا ارتباط معنایی بین چانکهای متوالی حفظ بشه.
۲. کانتکست بیشتر به معنی جواب بهتر نیست.
اینکه ۱۰ تا چانک رو از Vector DB بازیابی کنی و همهشو بریزی تو پرامپت، معمولاً نتیجه رو خراب میکنه. مدلهای زبانی بزرگ با پدیدهای به اسم "Lost in the Middle" درگیرن؛ یعنی به اطلاعاتی که وسط یه کانتکست طولانی قرار گرفته، توجه کمتری میکنن. راه حل اینه که بعد از بازیابی اولیه، یه مرحله Re-ranking اضافه بشه. میتونین از یه مدل سبک cross-encoder یا سرویسهایی مثل Cohere Rerank استفاده کنین تا چانکها رو بر اساس ارتباط واقعیشون با سوال کاربر دوباره مرتب کنین. اینطوری مرتبطترین اطلاعات اول کانتکست قرار میگیره و مدل جواب دقیقتری تولید میکنه.
۳. انتخاب مدل Embedding یکی از حیاتیترین تصمیماته.
مدلهای Embedding مترجمهای دیتای شما به زبان ریاضی هستن. اگه مترجم کارشو بلد نباشه، کل سیستم بازیابی فلج میشه. مدلهای عمومی مثل text-embedding-3-small از OpenAI برای شروع خوبن، ولی برای دیتای تخصصی یا زبانهای خاص، ممکنه بهترین نباشن. باید مدلهای open-source مثل jina embedding رو هم بررسی کرد که روی تسکهای multilingual retrieval عملکرد خوبی نشون دادن. برای انتخاب درست، به معیارهای استاندارد نگاه کنین.
📃 مرجع مقایسه مدلهای Embedding
MTEB Leaderboard
در نهایت، RAG یه سیستم زندهس. باید به طور مداوم کیفیت بازیابی (retrieval precision) و وفاداری پاسخ مدل به منبع (faithfulness) رو ارزیابی کنین.
🛠 Join @LLMEngineers Community
یه مدل اپنسورس جدید به اسم XBai-o4 از شرکت MetaStone منتشر شده که روی بنچمارکهای Reasoning تونسته از مدلهایی مثل o3-mini و Claude Opus 4 بهتر عمل کنه.
ایدهی اصلیش parallel test time scaling هست. یعنی به جای اینکه مدل فقط یک جواب تولید کنه، میاد چندتا «مسیر فکری» یا Thinking Trajectory رو به صورت موازی تولید میکنه. بعد با استفاده از یک مدل پاداش (Reward Model) که روی کیفیت فرآیند استدلال آموزش دیده، بهترین مسیر رو انتخاب میکنه و جواب نهایی رو بر اساس اون تولید میکنه. به این تکنیک Process Reward Learning یا SPRM هم میگن.
این مدل چندتا حالت اجرایی داره: Low, Medium, High. این حالتها احتمالاً به تعداد مسیرهای فکریای که به صورت موازی تولید میشن ربط داره. هر چی تعداد مسیرها بیشتر باشه، دقت میره بالاتر ولی سرعت inference به شدت پایین میاد. برای همین یکی از دولوپرها اشاره کرده که نسخهی کوانتایز شدهاش «فوقالعاده کنده».
🤗 لینک وزنهای مدل
🛠 Join @LLMEngineers Community
ایدهی اصلیش parallel test time scaling هست. یعنی به جای اینکه مدل فقط یک جواب تولید کنه، میاد چندتا «مسیر فکری» یا Thinking Trajectory رو به صورت موازی تولید میکنه. بعد با استفاده از یک مدل پاداش (Reward Model) که روی کیفیت فرآیند استدلال آموزش دیده، بهترین مسیر رو انتخاب میکنه و جواب نهایی رو بر اساس اون تولید میکنه. به این تکنیک Process Reward Learning یا SPRM هم میگن.
این مدل چندتا حالت اجرایی داره: Low, Medium, High. این حالتها احتمالاً به تعداد مسیرهای فکریای که به صورت موازی تولید میشن ربط داره. هر چی تعداد مسیرها بیشتر باشه، دقت میره بالاتر ولی سرعت inference به شدت پایین میاد. برای همین یکی از دولوپرها اشاره کرده که نسخهی کوانتایز شدهاش «فوقالعاده کنده».
🤗 لینک وزنهای مدل
🛠 Join @LLMEngineers Community
LLM Engineers
یه مدل اپنسورس جدید به اسم XBai-o4 از شرکت MetaStone منتشر شده که روی بنچمارکهای Reasoning تونسته از مدلهایی مثل o3-mini و Claude Opus 4 بهتر عمل کنه. ایدهی اصلیش parallel test time scaling هست. یعنی به جای اینکه مدل فقط یک جواب تولید کنه، میاد چندتا…
نکات فنی کلیدی این مدل اینهاست:
یک. رابط یکپارچه مدل policy و مدل reward: مهمترین بخش ماجرا اینه که backbone مدل اصلی (که policy model حساب میشه) و مدل پاداش فرآیند (Process Reward Model یا PRM) مشترکه. یه head خیلی سبک (حدود ۵۳ میلیون پارامتر برای مدل ۳۲ میلیاردی) به مدل اضافه شده که کارش امتیازدهی به مراحل استدلاله. این کار هزینه محاسباتی PRM رو موقع اینفرنس تا ۹۹٪ کاهش میده چون دیگه لازم نیست یه مدل غولپیکر جداگانه برای امتیازدهی لود بشه.
دو. یادگیری خودنظارتی برای مدل پاداش (SPRM): یکی از بزرگترین مشکلات ساخت PRM، نیاز به دادههای لیبلگذاری شده در سطح فرآیندی (process-level annotation) هست که خیلی گرونه. این تیم اومده یه Self-supervised PRM یا SPRM ساخته که فقط با دیدن نتیجه نهایی (مثلاً جواب مسئله درسته یا غلط) یاد میگیره به مراحل مختلف استدلال امتیاز بده. اینجوری دیگه نیازی به دیتاستهای پیچیده و پرهزینه برای ترین PRM نیست.
کاربرد عملی این معماری تو Test-Time Scaling (TTS) مشخص میشه. مدل XBai o4 سه تا حالت داره: low و medium و high. این حالتها در واقع Best-of-N با مقادیر N برابر ۲، ۸ و ۳۲ هستن. مدل k تا جواب مختلف تولید میکنه، بعد SPRM داخلیش به هر کدوم امتیاز میده و بهترینش رو انتخاب میکنه.
به نظر من، ایده shared backbone یه حرکت مهندسی هوشمندانه و بهینهست. به جای اینکه یه PRM جدا رو به زور بچسبونن به یه مدل دیگه، کل سیستم به صورت یکپارچه طراحی شده. استفاده از یه loss سفارشی به اسم SPRLoss هم که حین آموزش جلوی نویز ناشی از لیبلهای اشتباه رو میگیره، نشون میده که به چالشهای عملی این روش فکر شده.
توی مقاله به یه پدیده جالب به اسم aha moment هم اشاره شده. ظاهراً موقع آموزش، مدل بعد از یه تعداد استپ خاص، ناگهان توانایی تفکیک بین استدلال درست و غلط رو پیدا میکنه و از اون نقطه به بعد، شکاف امتیازی که به جوابهای درست و غلط میده به سرعت زیاد میشه.
در بنچمارکهای ریاضی مثل AIME24 و AIME25، مدل XBai o4-high تونسته از مدلهای قوی مثل Qwen3-32B و حتی DeepSeek-R1-671B هم عملکرد بهتری ثبت کنه.
📃 مقاله اصلی برای جزئیات بیشتر:
Test-Time Scaling with Reflective Generative Model
🛠 Join @LLMEngineers Community
یک. رابط یکپارچه مدل policy و مدل reward: مهمترین بخش ماجرا اینه که backbone مدل اصلی (که policy model حساب میشه) و مدل پاداش فرآیند (Process Reward Model یا PRM) مشترکه. یه head خیلی سبک (حدود ۵۳ میلیون پارامتر برای مدل ۳۲ میلیاردی) به مدل اضافه شده که کارش امتیازدهی به مراحل استدلاله. این کار هزینه محاسباتی PRM رو موقع اینفرنس تا ۹۹٪ کاهش میده چون دیگه لازم نیست یه مدل غولپیکر جداگانه برای امتیازدهی لود بشه.
دو. یادگیری خودنظارتی برای مدل پاداش (SPRM): یکی از بزرگترین مشکلات ساخت PRM، نیاز به دادههای لیبلگذاری شده در سطح فرآیندی (process-level annotation) هست که خیلی گرونه. این تیم اومده یه Self-supervised PRM یا SPRM ساخته که فقط با دیدن نتیجه نهایی (مثلاً جواب مسئله درسته یا غلط) یاد میگیره به مراحل مختلف استدلال امتیاز بده. اینجوری دیگه نیازی به دیتاستهای پیچیده و پرهزینه برای ترین PRM نیست.
کاربرد عملی این معماری تو Test-Time Scaling (TTS) مشخص میشه. مدل XBai o4 سه تا حالت داره: low و medium و high. این حالتها در واقع Best-of-N با مقادیر N برابر ۲، ۸ و ۳۲ هستن. مدل k تا جواب مختلف تولید میکنه، بعد SPRM داخلیش به هر کدوم امتیاز میده و بهترینش رو انتخاب میکنه.
به نظر من، ایده shared backbone یه حرکت مهندسی هوشمندانه و بهینهست. به جای اینکه یه PRM جدا رو به زور بچسبونن به یه مدل دیگه، کل سیستم به صورت یکپارچه طراحی شده. استفاده از یه loss سفارشی به اسم SPRLoss هم که حین آموزش جلوی نویز ناشی از لیبلهای اشتباه رو میگیره، نشون میده که به چالشهای عملی این روش فکر شده.
توی مقاله به یه پدیده جالب به اسم aha moment هم اشاره شده. ظاهراً موقع آموزش، مدل بعد از یه تعداد استپ خاص، ناگهان توانایی تفکیک بین استدلال درست و غلط رو پیدا میکنه و از اون نقطه به بعد، شکاف امتیازی که به جوابهای درست و غلط میده به سرعت زیاد میشه.
در بنچمارکهای ریاضی مثل AIME24 و AIME25، مدل XBai o4-high تونسته از مدلهای قوی مثل Qwen3-32B و حتی DeepSeek-R1-671B هم عملکرد بهتری ثبت کنه.
📃 مقاله اصلی برای جزئیات بیشتر:
Test-Time Scaling with Reflective Generative Model
🛠 Join @LLMEngineers Community
یه نگاهی به چند صدتا کیس استادی جدید LLMOps که تو پروداکشن کار میکنن انداختم. چهارتا ترند اصلی خیلی داره تکرار میشه, اینا چیزاییه که تیمای جدی دارن انجام میدن، نه دموهای پرزرق و برق.
بحث Agent ها بالاخره از فاز دمو خارج شده و داره تو پروداکشن استفاده میشه. ولی این Agent ها هیچ شباهتی به سیستمهای خودکار و همهکارهای که تو مقالهها میبینیم ندارن. Agent های موفق فعلی، به طرز شگفتآوری narrow و تکدامنهای هستن. بیشتر شبیه اسکریپتهای اتوماسیون خیلی هوشمند و context-aware عمل میکنن تا یه موجودیت مستقل. نظارت انسان هم تقریبا دائمیه. حتی سیستمهایی که لیبل multi-agent میگیرن، اغلب فقط یه الگوی ساده orchestrator-worker هستن که یه کنترلر اصلی، کارها رو به ماژولهای تخصصیتر پاس میده.
موضوع بعدی اینه که زمان بیشتری صرف ساخت زیرساخت evaluation میشه تا منطق اصلی اپلیکیشن. اگه اینطور نیست، احتمالاً دارید محصول باگدار تحویل میدید. الگوی LLM-as-judge برای ارزیابیهای بدون مرجع (reference-free) غالب شده، چون scale میشه. اما این یه راهحل کامل نیست. هر پیادهسازی موفقی که بررسی شده، یه سری golden dataset داره که توسط انسان اعتبارسنجی شدن. الگو اینه: با LLM judges سریع شروع کن، ولی همه چیز رو به یه ground truth انسانی متصل نگه دار. هزینه evals هم یه فاکتور مهمه؛ تیمها متوجه شدن که اجرای eval های سنگین روی هر commit میتونه بودجه inference رو سریعتر از ترافیک پروداکشن تموم کنه. رویکرد درست، یه eval stack چندلایه است: تستهای سبک مثل unit test برای prompt template ها به صورت مکرر و تستهای سنگینتر offline در شرایط خاص.
اون روزا که RAG فقط به معنی "یه سری داکیومنت رو بریز تو vector DB و امیدوار باش خوب کار کنه" بود، تموم شده. معماریهای RAG جدید خیلی عجیب و پیچیده شدن. الان سیستمهایی رو میبینیم که vector search، keyword matching، graph traversal و پایپلاینهای reranking رو با هم ترکیب میکنن و یه LLM دیگه هم اینا رو ارکستریت میکنه. این پیچیدگی بعضی وقتا جواب میده و دقت رو برای کوئریهای تخصصی خیلی بالا میبره، اما هزینهش پیچیدگی عملیاتی وحشتناکه.
در نهایت، Data Flywheels الگوییه که برندهها رو از بازندهها جدا میکنه: تبدیل تعاملات کاربر به دیتا برای آموزش. هر سیستم موفقی یه راهی پیدا کرده که وقتی کاربر خروجی AI رو اصلاح میکنه، اون اصلاح مستقیم به سیستم برگرده و prompt ها رو آپدیت کنه، مدلها رو fine-tune کنه یا استراتژیهای retrieval رو تغییر بده. برای شروع این چرخه هم، معمولاً از synthetic data استفاده میشه تا سیستم سرد نباشه. به نظر من، چالش اصلی اینجا فنی نیست؛ طراحی UX برای گرفتن فیدبک راحت از کاربر و گرفتن تأییدیه تیم حقوقی برای استفاده از اون دیتا، بخش سخت ماجراست.
در کل، هنوز تا رسیدن به یه نقطه پایدار فاصله داریم. معماریها و زیرساختهای LLMOps همینطور در حال تکامل هستن و این الگوها نشون میده که کار تو این حوزه چقدر از فاز آزمون و خطا فاصله گرفته و جدی شده.
🛠 Join @LLMEngineers Community
بحث Agent ها بالاخره از فاز دمو خارج شده و داره تو پروداکشن استفاده میشه. ولی این Agent ها هیچ شباهتی به سیستمهای خودکار و همهکارهای که تو مقالهها میبینیم ندارن. Agent های موفق فعلی، به طرز شگفتآوری narrow و تکدامنهای هستن. بیشتر شبیه اسکریپتهای اتوماسیون خیلی هوشمند و context-aware عمل میکنن تا یه موجودیت مستقل. نظارت انسان هم تقریبا دائمیه. حتی سیستمهایی که لیبل multi-agent میگیرن، اغلب فقط یه الگوی ساده orchestrator-worker هستن که یه کنترلر اصلی، کارها رو به ماژولهای تخصصیتر پاس میده.
موضوع بعدی اینه که زمان بیشتری صرف ساخت زیرساخت evaluation میشه تا منطق اصلی اپلیکیشن. اگه اینطور نیست، احتمالاً دارید محصول باگدار تحویل میدید. الگوی LLM-as-judge برای ارزیابیهای بدون مرجع (reference-free) غالب شده، چون scale میشه. اما این یه راهحل کامل نیست. هر پیادهسازی موفقی که بررسی شده، یه سری golden dataset داره که توسط انسان اعتبارسنجی شدن. الگو اینه: با LLM judges سریع شروع کن، ولی همه چیز رو به یه ground truth انسانی متصل نگه دار. هزینه evals هم یه فاکتور مهمه؛ تیمها متوجه شدن که اجرای eval های سنگین روی هر commit میتونه بودجه inference رو سریعتر از ترافیک پروداکشن تموم کنه. رویکرد درست، یه eval stack چندلایه است: تستهای سبک مثل unit test برای prompt template ها به صورت مکرر و تستهای سنگینتر offline در شرایط خاص.
اون روزا که RAG فقط به معنی "یه سری داکیومنت رو بریز تو vector DB و امیدوار باش خوب کار کنه" بود، تموم شده. معماریهای RAG جدید خیلی عجیب و پیچیده شدن. الان سیستمهایی رو میبینیم که vector search، keyword matching، graph traversal و پایپلاینهای reranking رو با هم ترکیب میکنن و یه LLM دیگه هم اینا رو ارکستریت میکنه. این پیچیدگی بعضی وقتا جواب میده و دقت رو برای کوئریهای تخصصی خیلی بالا میبره، اما هزینهش پیچیدگی عملیاتی وحشتناکه.
در نهایت، Data Flywheels الگوییه که برندهها رو از بازندهها جدا میکنه: تبدیل تعاملات کاربر به دیتا برای آموزش. هر سیستم موفقی یه راهی پیدا کرده که وقتی کاربر خروجی AI رو اصلاح میکنه، اون اصلاح مستقیم به سیستم برگرده و prompt ها رو آپدیت کنه، مدلها رو fine-tune کنه یا استراتژیهای retrieval رو تغییر بده. برای شروع این چرخه هم، معمولاً از synthetic data استفاده میشه تا سیستم سرد نباشه. به نظر من، چالش اصلی اینجا فنی نیست؛ طراحی UX برای گرفتن فیدبک راحت از کاربر و گرفتن تأییدیه تیم حقوقی برای استفاده از اون دیتا، بخش سخت ماجراست.
در کل، هنوز تا رسیدن به یه نقطه پایدار فاصله داریم. معماریها و زیرساختهای LLMOps همینطور در حال تکامل هستن و این الگوها نشون میده که کار تو این حوزه چقدر از فاز آزمون و خطا فاصله گرفته و جدی شده.
🛠 Join @LLMEngineers Community
تنسنت (Tencent) یه خانواده جدید از مدلهای زبانی متنباز به اسم Hunyuan رو در سایزهای کوچک (0.5B, 1.8B, 4B, 7B) منتشر کرده. این مدلها برای سناریوهای کممصرف مثل اجرا روی GPU های خانگی، موبایلها و کامپیوترهای شخصی طراحی شدن.
🛠 Join @LLMEngineers Community
🛠 Join @LLMEngineers Community
LLM Engineers
تنسنت (Tencent) یه خانواده جدید از مدلهای زبانی متنباز به اسم Hunyuan رو در سایزهای کوچک (0.5B, 1.8B, 4B, 7B) منتشر کرده. این مدلها برای سناریوهای کممصرف مثل اجرا روی GPU های خانگی، موبایلها و کامپیوترهای شخصی طراحی شدن. 🛠 Join @LLMEngineers Community
نقاط قوت مشخص: شکی نیست که Hunyuan-7B در حوزه استدلال ریاضی و منطق خیلی قویه. امتیازهای بالا در بنچمارکهای MATH، GSM-8K و بهخصوص AIME این رو ثابت میکنه. در این حوزهها، با بهترینهای کلاس خودش کلکل میکنه.
نقاط ضعف یا نکات انحرافی:
بنچمارک MMLU: این یه بنچمارک استاندارد و مهمه که دانش عمومی مدل رو میسنجه. تو نمودارهای رنگی تنسنت اثری ازش نیست، ولی طبق دادههای دیگه، Hunyuan-7B با امتیاز حدود ۷۹.۸، به شکل محسوسی از رقیب اصلیش یعنی Qwen3-8B (با امتیاز ۸۷.۵ در MMLU-Redux) ضعیفتره. این اختلاف مهمه و نشون میده در دانش عمومی، Qwen3 برتری داره.
بنچمارک IFEval: این بنچمارک توانایی مدل در دنبال کردن دستورالعملها رو میسجه. اینجا هم Hunyuan از مدل OpenAI o1-mini عقبتره. این یعنی ممکنه برای تسکهایی که نیاز به پیروی دقیق و پیچیده از دستورالعمل دارن، بهترین گزینه نباشه.
دستچین کردن رقبا: در بنچمارک AIME 2024، نمودار تنسنت نشون میده که Hunyuan با امتیاز ۸۱.۱ از بقیه بهتره. اما این "بقیه" شامل مدل تخصصی DeepSeek-R1-0528-Qwen3-8B نمیشه که امتیاز ۸۶.۰ رو در همین بنچمارک کسب کرده. پس Hunyuan بهترین نیست، فقط از رقبایی که تنسنت انتخاب کرده بهتره.
ارزش واقعی Hunyuan-7B کجاست؟
به نظر من، اصل قضیه این نیست که Hunyuan توی همه بنچمارکها اول باشه، چون نیست. ارزش اصلی این مدل توی پکیج کامل و منحصر به فردشه:
۱. عملکرد استدلالی خیلی خوب (Good Enough): شاید بهترین نباشه، ولی به اندازهی کافی قوی هست که کارهای پیچیده رو انجام بده.
۲. پنجره context نیتیو و عظیم 256K: این برگ برندهی اصلیه. هیچکدوم از رقبای مستقیمش چنین پنجرهی بزرگی رو به صورت نیتیو و بدون افت کیفیت ارائه نمیدن.
۳. کوانتیزاسیون فوقالعاده: مدلهای کوانتایزشدهی FP8 و INT4 افت عملکرد بسیار کمی دارن. این یعنی میتونید یک مدل با توانایی پردازش ۲۵۶ هزار توکن رو روی یک کارت گرافیک خانگی مثل RTX 4090 اجرا کنید.
🛠 Join @LLMEngineers Community
نقاط ضعف یا نکات انحرافی:
بنچمارک MMLU: این یه بنچمارک استاندارد و مهمه که دانش عمومی مدل رو میسنجه. تو نمودارهای رنگی تنسنت اثری ازش نیست، ولی طبق دادههای دیگه، Hunyuan-7B با امتیاز حدود ۷۹.۸، به شکل محسوسی از رقیب اصلیش یعنی Qwen3-8B (با امتیاز ۸۷.۵ در MMLU-Redux) ضعیفتره. این اختلاف مهمه و نشون میده در دانش عمومی، Qwen3 برتری داره.
بنچمارک IFEval: این بنچمارک توانایی مدل در دنبال کردن دستورالعملها رو میسجه. اینجا هم Hunyuan از مدل OpenAI o1-mini عقبتره. این یعنی ممکنه برای تسکهایی که نیاز به پیروی دقیق و پیچیده از دستورالعمل دارن، بهترین گزینه نباشه.
دستچین کردن رقبا: در بنچمارک AIME 2024، نمودار تنسنت نشون میده که Hunyuan با امتیاز ۸۱.۱ از بقیه بهتره. اما این "بقیه" شامل مدل تخصصی DeepSeek-R1-0528-Qwen3-8B نمیشه که امتیاز ۸۶.۰ رو در همین بنچمارک کسب کرده. پس Hunyuan بهترین نیست، فقط از رقبایی که تنسنت انتخاب کرده بهتره.
ارزش واقعی Hunyuan-7B کجاست؟
به نظر من، اصل قضیه این نیست که Hunyuan توی همه بنچمارکها اول باشه، چون نیست. ارزش اصلی این مدل توی پکیج کامل و منحصر به فردشه:
۱. عملکرد استدلالی خیلی خوب (Good Enough): شاید بهترین نباشه، ولی به اندازهی کافی قوی هست که کارهای پیچیده رو انجام بده.
۲. پنجره context نیتیو و عظیم 256K: این برگ برندهی اصلیه. هیچکدوم از رقبای مستقیمش چنین پنجرهی بزرگی رو به صورت نیتیو و بدون افت کیفیت ارائه نمیدن.
۳. کوانتیزاسیون فوقالعاده: مدلهای کوانتایزشدهی FP8 و INT4 افت عملکرد بسیار کمی دارن. این یعنی میتونید یک مدل با توانایی پردازش ۲۵۶ هزار توکن رو روی یک کارت گرافیک خانگی مثل RTX 4090 اجرا کنید.
🛠 Join @LLMEngineers Community
اپلیکیشن Jan یه رابط کاربری دسکتاپه برای اجرای llm ها که هم آفلاین کار میکنه و هم به سرویسهای ابری وصل میشه. کاربرد اصلیش اینه که بهت اجازه میده بدون نگرانی بابت حریم خصوصی، مدلهای زبانی بزرگ رو روی سیستم شخصی خودت اجرا کنی. اخیراً هم یه قابلیت مهم بهش اضافه شده که میشه با اکانت Hugging Face PRO مدلها رو مستقیم داخلش اجرا کرد. کل کدبیسش هم کاملاً اوپنسورسه و میشه اون رو تغییر داد یا خودتون هاست کنین.
برگ برندهاش قابلیت سوییچ یکپارچه بین مدلهای محلی و ابریه. Jan به شما اجازه میده توی یک محیط چت، هم مدلهای GGUF رو با llama.cpp به صورت آفلاین اجرا کنین و هم به APIهای کلاد مثل OpenAI، Groq و Mistral وصل بشین. مهمتر اینکه، API سرور محلیش (روی localhost:1337) میتونه ترافیک رو به صورت شفاف بین یه مدل لوکال Llama 3 و یه مدل ابری مثل GPT-4o جابجا کنه. این یعنی کدی که برای توسعه میزنین، بدون هیچ تغییری میتونه از هر دو مدل استفاده کنه.
دانلود
🛠 Join @LLMEngineers Community
برگ برندهاش قابلیت سوییچ یکپارچه بین مدلهای محلی و ابریه. Jan به شما اجازه میده توی یک محیط چت، هم مدلهای GGUF رو با llama.cpp به صورت آفلاین اجرا کنین و هم به APIهای کلاد مثل OpenAI، Groq و Mistral وصل بشین. مهمتر اینکه، API سرور محلیش (روی localhost:1337) میتونه ترافیک رو به صورت شفاف بین یه مدل لوکال Llama 3 و یه مدل ابری مثل GPT-4o جابجا کنه. این یعنی کدی که برای توسعه میزنین، بدون هیچ تغییری میتونه از هر دو مدل استفاده کنه.
دانلود
🛠 Join @LLMEngineers Community
مقایسه لانچرهای لوکال مدلهای زبانی بر اساس تجربه شخصی و بحثهای کامیونیتی
🟣 LM Studio
نقطهی قوت اصلیش، رابط کاربری (GUI) و تجربهی کاربری (UX) خیلی خوبشه. برای کسی که میخواد بدون دردسر و سریع یه مدل GGUF رو تست کنه، عالیه.
مزایا: همهچیز توی یه پکیجه. دانلودر داخلی از Hugging Face داره، تنظیمات مدل مثل context size و GPU offload بهراحتی قابل کنترله و یه حالت سرور OpenAI-compatible داره که مدلها رو بر اساس درخواست، به صورت on-demand لود و آنلود میکنه. این قابلیت آخر خیلی مهمه.
معایب: رابط کاربریش closed-source هست. یعنی نمیتونی کدش رو ببینی یا تغییر بدی. برای بعضیها این یه خط قرمزه. گاهی هم باگهایی داره که البته معمولاً تو نسخههای بتا رفع میشن.
کاربرد: بهترین گزینه برای شروع، تست سریع مدلهای جدید و کسایی که نمیخوان درگیر CLI و Docker بشن.
⚪️ Ollama
Ollama بیشتر یه backend یا ابزار CLI هست تا یه اپلیکیشن کامل. هدفش اینه که اجرای مدلها و سرویسدهی از طریق API رو تا حد ممکن ساده کنه.
مزایا: خیلی سبکه، نصبش سادهست و به قول معروف set it and forget it هست. مدلها رو از لایبرری خودش میکشه و آپدیت میکنه.
معایب: یه GUI حداقلی اخیراً اضافه شده ولی برای یه تجربه کامل، معمولاً باید با یه فرانتاند مثل OpenWebUI ترکیب بشه. بعضی کاربران حرفهای معتقدن وقتی کار پیچیده میشه، Ollama گزینههای کنترلی کمتری نسبت به llama.cpp خام بهت میده.
کاربرد: عالیه برای وقتی که فقط یه API endpoint پایدار برای مدلهات میخوای و قراره از یه UI دیگه بهش وصل بشی. ترکیب Ollama + OpenWebUI یه ترکیب خیلی محبوبه.
🟡 Jan
Jan سعی کرده یه تعادل بین LM Studio و Ollama برقرار کنه. رابط کاربری داره ولی کاملاً open-source هست.
مزایا: کل اپلیکیشن (فرانت و بک) تحت لایسنس Apache-2.0 هست. بزرگترین ویژگی منحصربهفردش اینه که میتونه به صورت transparent ترافیک رو بین مدلهای لوکال و مدلهای کلاد (مثل GPT-4o یا Claude) جابجا کنه، بدون اینکه نیاز باشه کد سمت کلاینت رو تغییر بدی.
معایب: بعضیها حس میکنن هنوز به پختگی LM Studio نرسیده و یه مقدار featureless به نظر میاد.
کاربرد: برای کسایی که به open-source بودن اهمیت میدن و نیاز دارن بهراحتی بین مدلهای لوکال و APIهای خارجی سوییچ کنن، بهترین گزینهست.
🟠 Llama.cpp
این خودِ موتوره. ابزارهای دیگه مثل LM Studio و Jan در هستهی خودشون از llama.cpp استفاده میکنن.
مزایا: حداکثر پرفورمنس و کنترل. هیچ لایهی اضافهای وجود نداره. برای کارهای جدی، اجرا روی سرورهای headless و برای دولوپرهایی که میخوان روی خود انجین کار کنن، انتخاب اوله.
معایب: کار باهاش دانش فنی میخواد. همه چیز از طریق CLI و پارامترها کنترل میشه و خبری از GUI نیست.
کاربرد: برای حرفهایها و کارهای جدی.
🟣 LM Studio
نقطهی قوت اصلیش، رابط کاربری (GUI) و تجربهی کاربری (UX) خیلی خوبشه. برای کسی که میخواد بدون دردسر و سریع یه مدل GGUF رو تست کنه، عالیه.
مزایا: همهچیز توی یه پکیجه. دانلودر داخلی از Hugging Face داره، تنظیمات مدل مثل context size و GPU offload بهراحتی قابل کنترله و یه حالت سرور OpenAI-compatible داره که مدلها رو بر اساس درخواست، به صورت on-demand لود و آنلود میکنه. این قابلیت آخر خیلی مهمه.
معایب: رابط کاربریش closed-source هست. یعنی نمیتونی کدش رو ببینی یا تغییر بدی. برای بعضیها این یه خط قرمزه. گاهی هم باگهایی داره که البته معمولاً تو نسخههای بتا رفع میشن.
کاربرد: بهترین گزینه برای شروع، تست سریع مدلهای جدید و کسایی که نمیخوان درگیر CLI و Docker بشن.
⚪️ Ollama
Ollama بیشتر یه backend یا ابزار CLI هست تا یه اپلیکیشن کامل. هدفش اینه که اجرای مدلها و سرویسدهی از طریق API رو تا حد ممکن ساده کنه.
مزایا: خیلی سبکه، نصبش سادهست و به قول معروف set it and forget it هست. مدلها رو از لایبرری خودش میکشه و آپدیت میکنه.
معایب: یه GUI حداقلی اخیراً اضافه شده ولی برای یه تجربه کامل، معمولاً باید با یه فرانتاند مثل OpenWebUI ترکیب بشه. بعضی کاربران حرفهای معتقدن وقتی کار پیچیده میشه، Ollama گزینههای کنترلی کمتری نسبت به llama.cpp خام بهت میده.
کاربرد: عالیه برای وقتی که فقط یه API endpoint پایدار برای مدلهات میخوای و قراره از یه UI دیگه بهش وصل بشی. ترکیب Ollama + OpenWebUI یه ترکیب خیلی محبوبه.
🟡 Jan
Jan سعی کرده یه تعادل بین LM Studio و Ollama برقرار کنه. رابط کاربری داره ولی کاملاً open-source هست.
مزایا: کل اپلیکیشن (فرانت و بک) تحت لایسنس Apache-2.0 هست. بزرگترین ویژگی منحصربهفردش اینه که میتونه به صورت transparent ترافیک رو بین مدلهای لوکال و مدلهای کلاد (مثل GPT-4o یا Claude) جابجا کنه، بدون اینکه نیاز باشه کد سمت کلاینت رو تغییر بدی.
معایب: بعضیها حس میکنن هنوز به پختگی LM Studio نرسیده و یه مقدار featureless به نظر میاد.
کاربرد: برای کسایی که به open-source بودن اهمیت میدن و نیاز دارن بهراحتی بین مدلهای لوکال و APIهای خارجی سوییچ کنن، بهترین گزینهست.
🟠 Llama.cpp
این خودِ موتوره. ابزارهای دیگه مثل LM Studio و Jan در هستهی خودشون از llama.cpp استفاده میکنن.
مزایا: حداکثر پرفورمنس و کنترل. هیچ لایهی اضافهای وجود نداره. برای کارهای جدی، اجرا روی سرورهای headless و برای دولوپرهایی که میخوان روی خود انجین کار کنن، انتخاب اوله.
معایب: کار باهاش دانش فنی میخواد. همه چیز از طریق CLI و پارامترها کنترل میشه و خبری از GUI نیست.
کاربرد: برای حرفهایها و کارهای جدی.
تیم Qwen یه مدل جدید به اسم Qwen-Image رو اوپن سورس کرده که تمرکزش روی تولید تصویر با رندر متن خیلی قویه، مخصوصا برای زبان چینی و انگلیسی. این مدل ۲۰ میلیارد پارامتری، متن رو به صورت in-pixel یعنی به عنوان بخشی از خود تصویر تولید میکنه، نه یه لایه جدا.
اما نکته فنی کلیدی، استفاده از GRPO هست. این رویکرد، تولید تصویر رو به عنوان یک مسئله رتبهبندی فرموله میکنه. یعنی مدل به جای اینکه فقط یک خروجی «خوب» تولید کنه، یاد میگیره از بین چندتا تصویر تولید شده، اونی که به سلیقه انسان نزدیکتره رو انتخاب کنه. این فرآیند دقیقاً شبیه به مکانیزم RLHF در مدلهای زبانی برای همسو شدن با اولویتهای انسانیه. نتیجهاش هم خروجیهاییه که نه تنها دقیقن، بلکه از نظر زیباییشناسی هم قویترن.
🤗 هاگینگ فیس
🛠 Join @LLMEngineers Community
اما نکته فنی کلیدی، استفاده از GRPO هست. این رویکرد، تولید تصویر رو به عنوان یک مسئله رتبهبندی فرموله میکنه. یعنی مدل به جای اینکه فقط یک خروجی «خوب» تولید کنه، یاد میگیره از بین چندتا تصویر تولید شده، اونی که به سلیقه انسان نزدیکتره رو انتخاب کنه. این فرآیند دقیقاً شبیه به مکانیزم RLHF در مدلهای زبانی برای همسو شدن با اولویتهای انسانیه. نتیجهاش هم خروجیهاییه که نه تنها دقیقن، بلکه از نظر زیباییشناسی هم قویترن.
🤗 هاگینگ فیس
🛠 Join @LLMEngineers Community
یه مدل جدید به اسم Hierarchical Reasoning Model یا HRM اومده که نتایج جالبی روی تسکهای استدلال منطقی گرفته. بعضیها دارن بهش میگن "LLM-killer" ولی این مقایسه از پایه اشتباهه. کاربرد عملی HRM حل پازلهای منطقی پیچیده و بهینهسازی مسیر تو فضاهای بسته است، یعنی کارهایی که نیاز به جستجو و backtracking عمیق دارن.
این مدل مستقیماً به محدودیتهای معماری Transformers حمله میکنه. مدلهای ترنسفورمر، هرچقدر هم بزرگ باشن، از نظر محاسباتی "کمعمق" هستن و نمیتونن الگوریتمهای پیچیده رو به صورت end-to-end اجرا کنن. برای همین به سراغ Chain-of-Thought یا CoT میرن که در واقع نوعی برونسپاری استدلال به فضاست. CoT شکننده است و به داده زیاد برای فاینتیون شدن نیاز داره.
معماری HRM از ساختار سلسلهمراتبی و چندمقیاسی مغز الهام گرفته شده. دو ماژول recurrent داره که با هم کار میکنن:
۱. یه ماژول سطح بالا (High-level H): این ماژول آهسته آپدیت میشه و مسئولیت برنامهریزی انتزاعی و کلی رو به عهده داره.
۲. یه ماژول سطح پایین (Low-level L): این یکی سریع آپدیت میشه و محاسبات جزئی و دقیق رو انجام میده.
نتایجش روی بنچمارکهای خاص خیلی خوبه. این مدل ۲۷ میلیون پارامتری، فقط با ۱۰۰۰ نمونه داده آموزشی و بدون هیچ pre-training، تونسته پازلهای سودوکوی خیلی سخت (Sudoku-Extreme) و مازهای پیچیده (Maze-Hard) رو با دقت نزدیک به ۱۰۰٪ حل کنه؛ تسکهایی که مدلهای زبانی بزرگ با CoT عملاً روی اونها شکست خوردن (دقت صفر). توی بنچمارک ARC هم که برای سنجش هوش عمومی مصنوعی طراحی شده، عملکرد بهتری از مدلهای بسیار بزرگتر از خودش داشته.
به نظر من، HRM یه LLM-killer" نیست. LLM مثل یک سیستمعامل همه-کارهست که میتونه کد بنویسه، ایمیل بزنه و کارهای عمومی انجام بده. HRM مثل یک ماشین حساب فوقالعاده تخصصی و قدرتمنده که برای حل یک کلاس خاص از مسائل منطقی طراحی شده. قدرت اصلی این مقاله در اینه که نشون میده میشه با معماریهای جایگزین، به خصوص ساختارهای سلسلهمراتبی و recurrent، الگوریتمهای پیچیده رو به صورت بهینه و با داده کم یاد گرفت. این مدل شاید مستقیم تو محصولات روزمره استفاده نشه، ولی اصول معماریش میتونه روی نسل بعدی مدلها تاثیرگذار باشه.
📃 Hierarchical Reasoning Model
🛠 Join @LLMEngineers Community
این مدل مستقیماً به محدودیتهای معماری Transformers حمله میکنه. مدلهای ترنسفورمر، هرچقدر هم بزرگ باشن، از نظر محاسباتی "کمعمق" هستن و نمیتونن الگوریتمهای پیچیده رو به صورت end-to-end اجرا کنن. برای همین به سراغ Chain-of-Thought یا CoT میرن که در واقع نوعی برونسپاری استدلال به فضاست. CoT شکننده است و به داده زیاد برای فاینتیون شدن نیاز داره.
معماری HRM از ساختار سلسلهمراتبی و چندمقیاسی مغز الهام گرفته شده. دو ماژول recurrent داره که با هم کار میکنن:
۱. یه ماژول سطح بالا (High-level H): این ماژول آهسته آپدیت میشه و مسئولیت برنامهریزی انتزاعی و کلی رو به عهده داره.
۲. یه ماژول سطح پایین (Low-level L): این یکی سریع آپدیت میشه و محاسبات جزئی و دقیق رو انجام میده.
نتایجش روی بنچمارکهای خاص خیلی خوبه. این مدل ۲۷ میلیون پارامتری، فقط با ۱۰۰۰ نمونه داده آموزشی و بدون هیچ pre-training، تونسته پازلهای سودوکوی خیلی سخت (Sudoku-Extreme) و مازهای پیچیده (Maze-Hard) رو با دقت نزدیک به ۱۰۰٪ حل کنه؛ تسکهایی که مدلهای زبانی بزرگ با CoT عملاً روی اونها شکست خوردن (دقت صفر). توی بنچمارک ARC هم که برای سنجش هوش عمومی مصنوعی طراحی شده، عملکرد بهتری از مدلهای بسیار بزرگتر از خودش داشته.
به نظر من، HRM یه LLM-killer" نیست. LLM مثل یک سیستمعامل همه-کارهست که میتونه کد بنویسه، ایمیل بزنه و کارهای عمومی انجام بده. HRM مثل یک ماشین حساب فوقالعاده تخصصی و قدرتمنده که برای حل یک کلاس خاص از مسائل منطقی طراحی شده. قدرت اصلی این مقاله در اینه که نشون میده میشه با معماریهای جایگزین، به خصوص ساختارهای سلسلهمراتبی و recurrent، الگوریتمهای پیچیده رو به صورت بهینه و با داده کم یاد گرفت. این مدل شاید مستقیم تو محصولات روزمره استفاده نشه، ولی اصول معماریش میتونه روی نسل بعدی مدلها تاثیرگذار باشه.
📃 Hierarchical Reasoning Model
🛠 Join @LLMEngineers Community
اکثر Agentهایی که ساخته میشن، توی پروداکشن شکست میخورن. این یه واقعیته. دموهای اولیه معمولاً قشنگ و جذابن، سریع جواب میدن و از آخرین کتابخونههای اوپنسورس استفاده میکنن. ولی به محض اینکه با یه کاربر واقعی یا یه محیط پیچیدهتر روبرو میشن، سیستم از هم میپاشه.
این مشکل به خاطر تمرکز روی دمو به جای ساختن یک سیستم مهندسی شده است. باگها در شرایط خاص بیرون میزنن، پایداری Agent زیر سوال میره و لاگ گرفتن یه فکر ثانویه بوده. بعد از چند بار بازنویسی و آخر هفتههایی که صرف دیباگ کردن پرامپتهای اسپاگتی شدن، به یه نقشه راه مشخص برای ساخت Agentهای قابل اتکا برای پروداکشن میرسیم.
این نقشه راه، ۵ مرحله کلیدی داره که Agent رو از جهنم توسعه به یک سیستم قابل اتکا و مقیاسپذیر منتقل میکنه.
مرحله ۱: تسلط روی پایتون برای هوش مصنوعی پروداکشن
پایههای کار رو باید محکم گذاشت. قبل از اینکه نگران خود Agent یا LLMها باشی، باید اصول پایتون رو برای محیط پروداکشن بلد باشی:
فریمورک FastAPI: این روش صحبت کردن Agent با دنیای بیرونه. باهاش میشه Endpointهای سبک، امن و مقیاسپذیر ساخت.
برنامهنویسی Async: ایجنتها معمولاً منتظر جواب APIها یا دیتابیسها میمونن. برنامهنویسی Async کمک میکنه که سیستم بدون بلاک شدن، کارهای بیشتری رو با سرعت بالاتر انجام بده.
کتابخانهی Pydantic: دادههایی که به Agent وارد و از اون خارج میشن باید قابل پیشبینی و اعتبارسنجی شده باشن. Pydantic با تعریف Schema جلوی نصف باگهای آینده رو میگیره.
مرحله ۲: پایدار و قابل اتکا کردن Agent
توی این مرحله، Agent از نظر فنی کار میکنه، ولی پروداکشن به این اهمیت نمیده. پروداکشن نگران لحظاتیه که سیستم کار نمیکنه. دو چیز اینجا حیاتیه:
لاگینگ (Logging): این مثل اشعه ایکس برای سیستم میمونه. وقتی چیزی خراب میشه (که حتماً میشه)، لاگها نشون میدن که دقیقاً چه اتفاقی و چرا افتاده.
تستنویسی (Testing): تستهای Unit جلوی اشتباهات ساده رو قبل از رسیدن به پروداکشن میگیرن. تستهای Integration هم تضمین میکنن که ابزارها، پرامپتها و APIها با هم درست کار میکنن.
مرحله ۳: عمیق شدن در RAG
یک Agent بدون دسترسی به دانش قابل اتکا، چیز زیادی برای ارائه نداره. معماری RAG (Retrieval-Augmented Generation) به Agent حافظه، فکت و دسترسی به اطلاعات دنیای واقعی رو میده.
مبانی RAG: اول باید درک کرد که RAG چیه، چرا مهمه و چطور در طراحی سیستم جا میگیره.
ابزارهای اصلی: مفاهیم Text Embeddings و Vector Stores، بلوکهای اصلی بازیابی اطلاعات هستن.
جایگزینها: برای خیلی از کاربردها، نیازی به Vector DBهای عجیب و غریب نیست. یک PostgreSQL که خوب ایندکس شده باشه هم میتونه کار رو راه بندازه.
بهینهسازی: استراتژیهای Chunking هوشمندانه، روی کیفیت بازیابی تأثیر مستقیم داره. استفاده از فریمورکهایی مثل LangChain برای کنار هم گذاشتن قطعات و ابزارهای ارزیابی (Evaluation) هم برای سنجش کیفیت جوابها ضروریه.
به نظر من، اکثر Agentهای ضعیف همینجا زمین میخورن.
مرحله ۴: تعریف معماری مستحکم برای Agent
یک Agent قدرتمند فقط یک پرامپت نیست، بلکه یک سیستم کامله. برای ساختن چیزی که در پروداکشن کار کنه، به ساختار، حافظه و کنترل نیاز داری:
فریمورکهای Agent (مثل LangGraph): اینها مغز متفکر Agent هستن. وضعیت (state)، مراحل، تلاشهای مجدد و منطق کلی سیستم رو مدیریت میکنن.
مهندسی پرامپت: دستورالعملهای واضح تفاوت بین حدس زدن و رفتار قابل اتکا رو رقم میزنن.
مدیریت دیتابیس: به یک دیتابیس واقعی با ابزارهایی مثل SQLAlchemy و Alembic برای مدیریت لاگها، حافظه و وضعیت Agent نیاز هست.
مرحله ۵: مانیتورینگ، یادگیری و بهبود در پروداکشن
آخرین مرحله، تفاوت بین پروژههای سرگرمی و سیستمهای واقعی رو مشخص میکنه: بهبود مستمر.
وقتی Agent لانچ میشه، کار تموم نشده، تازه شروع شده. باید با ابزارهایی مثل Langfuse یا لاگهای کاستوم، رفتار Agent و کاربر رو زیر نظر گرفت. هر تعامل کاربر با سیستم، یک فیدبک حساب میشه که باید ازش برای بهبود پرامپتها و ابزارها استفاده کرد. تلهی "راهاندازی کن و فراموشش کن" چیزیه که خیلیها توش میافتن.
در نهایت، ساختن Agent برای پروداکشن، انتخاب بین ساختن یه اسباببازی و یه سیستم واقعیه. سیستمهایی که حافظه دارن، استدلال میکنن و در طول زمان بهتر میشن، با شانس ساخته نمیشن؛ با اصول مهندسی ساخته میشن.
🛠 Join @LLMEngineers Community
این مشکل به خاطر تمرکز روی دمو به جای ساختن یک سیستم مهندسی شده است. باگها در شرایط خاص بیرون میزنن، پایداری Agent زیر سوال میره و لاگ گرفتن یه فکر ثانویه بوده. بعد از چند بار بازنویسی و آخر هفتههایی که صرف دیباگ کردن پرامپتهای اسپاگتی شدن، به یه نقشه راه مشخص برای ساخت Agentهای قابل اتکا برای پروداکشن میرسیم.
این نقشه راه، ۵ مرحله کلیدی داره که Agent رو از جهنم توسعه به یک سیستم قابل اتکا و مقیاسپذیر منتقل میکنه.
مرحله ۱: تسلط روی پایتون برای هوش مصنوعی پروداکشن
پایههای کار رو باید محکم گذاشت. قبل از اینکه نگران خود Agent یا LLMها باشی، باید اصول پایتون رو برای محیط پروداکشن بلد باشی:
فریمورک FastAPI: این روش صحبت کردن Agent با دنیای بیرونه. باهاش میشه Endpointهای سبک، امن و مقیاسپذیر ساخت.
برنامهنویسی Async: ایجنتها معمولاً منتظر جواب APIها یا دیتابیسها میمونن. برنامهنویسی Async کمک میکنه که سیستم بدون بلاک شدن، کارهای بیشتری رو با سرعت بالاتر انجام بده.
کتابخانهی Pydantic: دادههایی که به Agent وارد و از اون خارج میشن باید قابل پیشبینی و اعتبارسنجی شده باشن. Pydantic با تعریف Schema جلوی نصف باگهای آینده رو میگیره.
مرحله ۲: پایدار و قابل اتکا کردن Agent
توی این مرحله، Agent از نظر فنی کار میکنه، ولی پروداکشن به این اهمیت نمیده. پروداکشن نگران لحظاتیه که سیستم کار نمیکنه. دو چیز اینجا حیاتیه:
لاگینگ (Logging): این مثل اشعه ایکس برای سیستم میمونه. وقتی چیزی خراب میشه (که حتماً میشه)، لاگها نشون میدن که دقیقاً چه اتفاقی و چرا افتاده.
تستنویسی (Testing): تستهای Unit جلوی اشتباهات ساده رو قبل از رسیدن به پروداکشن میگیرن. تستهای Integration هم تضمین میکنن که ابزارها، پرامپتها و APIها با هم درست کار میکنن.
مرحله ۳: عمیق شدن در RAG
یک Agent بدون دسترسی به دانش قابل اتکا، چیز زیادی برای ارائه نداره. معماری RAG (Retrieval-Augmented Generation) به Agent حافظه، فکت و دسترسی به اطلاعات دنیای واقعی رو میده.
مبانی RAG: اول باید درک کرد که RAG چیه، چرا مهمه و چطور در طراحی سیستم جا میگیره.
ابزارهای اصلی: مفاهیم Text Embeddings و Vector Stores، بلوکهای اصلی بازیابی اطلاعات هستن.
جایگزینها: برای خیلی از کاربردها، نیازی به Vector DBهای عجیب و غریب نیست. یک PostgreSQL که خوب ایندکس شده باشه هم میتونه کار رو راه بندازه.
بهینهسازی: استراتژیهای Chunking هوشمندانه، روی کیفیت بازیابی تأثیر مستقیم داره. استفاده از فریمورکهایی مثل LangChain برای کنار هم گذاشتن قطعات و ابزارهای ارزیابی (Evaluation) هم برای سنجش کیفیت جوابها ضروریه.
به نظر من، اکثر Agentهای ضعیف همینجا زمین میخورن.
مرحله ۴: تعریف معماری مستحکم برای Agent
یک Agent قدرتمند فقط یک پرامپت نیست، بلکه یک سیستم کامله. برای ساختن چیزی که در پروداکشن کار کنه، به ساختار، حافظه و کنترل نیاز داری:
فریمورکهای Agent (مثل LangGraph): اینها مغز متفکر Agent هستن. وضعیت (state)، مراحل، تلاشهای مجدد و منطق کلی سیستم رو مدیریت میکنن.
مهندسی پرامپت: دستورالعملهای واضح تفاوت بین حدس زدن و رفتار قابل اتکا رو رقم میزنن.
مدیریت دیتابیس: به یک دیتابیس واقعی با ابزارهایی مثل SQLAlchemy و Alembic برای مدیریت لاگها، حافظه و وضعیت Agent نیاز هست.
مرحله ۵: مانیتورینگ، یادگیری و بهبود در پروداکشن
آخرین مرحله، تفاوت بین پروژههای سرگرمی و سیستمهای واقعی رو مشخص میکنه: بهبود مستمر.
وقتی Agent لانچ میشه، کار تموم نشده، تازه شروع شده. باید با ابزارهایی مثل Langfuse یا لاگهای کاستوم، رفتار Agent و کاربر رو زیر نظر گرفت. هر تعامل کاربر با سیستم، یک فیدبک حساب میشه که باید ازش برای بهبود پرامپتها و ابزارها استفاده کرد. تلهی "راهاندازی کن و فراموشش کن" چیزیه که خیلیها توش میافتن.
در نهایت، ساختن Agent برای پروداکشن، انتخاب بین ساختن یه اسباببازی و یه سیستم واقعیه. سیستمهایی که حافظه دارن، استدلال میکنن و در طول زمان بهتر میشن، با شانس ساخته نمیشن؛ با اصول مهندسی ساخته میشن.
🛠 Join @LLMEngineers Community
توی سیستمهای RAG، یکی از مهمترین بخشها که معمولا درست بهش پرداخته نمیشه، بحث Chunking هست. اگه مدل داره جواب بیربط میده یا میگه اطلاعات کافی نداره، به احتمال زیاد مشکل از استراتژی Chunking شماست. انتخاب روش اشتباه یعنی یا مدل اصل مطلب رو نمیگیره یا کلا پرت میشه.
اینجا چند تا استراتژی رایج و پیشرفته برای Chunking رو بررسی میکنیم تا بدونید کی و کجا از هرکدوم استفاده کنید.
استراتژیهای پایه و ساده
این روشها نقطه شروع خوبی هستن و پیادهسازی سادهای دارن.
Fixed-size chunking:
سادهترین راه. متن به تکههایی با اندازه ثابت (مثلا ۱۰۰۰ کاراکتر) تقسیم میشه. این روش برای دادههای کثیف و بدون ساختار مثل متنهای استخراج شده از اسکن OCR یا فایلهای لاگ خام مناسبه، ولی ریسک شکستن جملات و از بین رفتن کانتکست رو داره.
Sliding window chunking:
نسخهی بهبود یافتهی روش قبلی. چانکها با هم همپوشانی (overlap) دارن تا کانتکست بینشون حفظ بشه. برای متونی که مفاهیم در جملات طولانی کشیده میشن، مثل مقالات و گزارشهای روایی، کاربرد داره.
Sentence-based chunking:
متن بر اساس پایان جملات (نقطه، علامت سوال و...) شکسته میشه. برای متون تمیز و خوشساختار مثل بلاگپستها و مستندات که هر جمله یک ایده کامل داره، خوبه.
Paragraph-based chunking:
متن بر اساس پاراگرافها تقسیم میشه. وقتی هر پاراگراف یک بلوک معنایی کامل رو تشکیل میده، مثل مقالات یا گزارشها، این روش کانتکست بهتری نسبت به شکستن جمله به جمله فراهم میکنه.
استراتژیهای مبتنی بر ساختار
این روشها از ساختار خود داکیومنت برای تقسیمبندی هوشمندتر استفاده میکنن.
Document-based chunking:
تقسیمبندی بر اساس ساختار طبیعی سند مثل سرفصلها (Headings) و بخشها (Sections) انجام میشه. برای کتابهای درسی، مقالات تحقیقاتی و راهنماها که ساختار سلسلهمراتبی دارن، ایدهآله.
Page-based chunking:
هر صفحه از سند به عنوان یک چانک در نظر گرفته میشه. مشخصاً برای کار با PDF، اسلاید یا کتاب که شماره صفحه اهمیت داره استفاده میشه.
Structured chunking:
برای دادههای ساختاریافته یا نیمهساختاریافته مثل HTML، JSON یا CSV کاربرد داره. در این روش، چانکها بر اساس تگها (مثلا <div> در HTML) یا فیلدهای مشخص تعریف میشن.
Table-aware chunking:
جدولها شناسایی و به صورت جداگانه و با فرمت مناسب (مثلا Markdown یا JSON) چانک میشن تا ساختارشون حفظ بشه.
استراتژیهای پیشرفته و محتوامحور
اینجا از مدلهای زبانی یا الگوریتمهای پیچیدهتر برای درک محتوا و تقسیمبندی بهینه استفاده میشه.
Semantic chunking:
در این روش، جملات یا پاراگرافها بر اساس شباهت معنایی (embedding similarity) گروهبندی میشن. چانکها زمانی شکسته میشن که موضوع بحث تغییر کنه. برای اسناد طولانی با موضوعات مختلف که روشهای ساده جواب نمیدن، خیلی موثره.
Entity-based chunking:
با استفاده از مدلهای Named Entity Recognition (NER)، موجودیتهایی مثل اسامی افراد، مکانها یا محصولات شناسایی شده و متنهای مرتبط با هر موجودیت در یک چانک قرار میگیره. برای تحلیل قراردادهای حقوقی، مقالات خبری یا اسناد مالی خوبه.
Agentic / LLM-based chunking:
اینجا از خود یک LLM خواسته میشه که تصمیم بگیره متن رو چطور تقسیم کنه. این روش قدرت انعطاف بالایی داره ولی کند و پرهزینهست. این روش معمولا overkill حساب میشه، مگر اینکه با دادههای خیلی پیچیده و بدون هیچ ساختاری سر و کار داشته باشید.
Recursive chunking:
یک رویکرد سلسلهمراتبی. اول با جداکنندههای بزرگ مثل پاراگراف شروع میکنه و اگه چانک حاصل بزرگتر از حد مجاز بود، به صورت بازگشتی با جداکنندههای کوچکتر مثل جمله، اون رو میشکنه تا به اندازه مطلوب برسه.
🛠 Join @LLMEngineers Community
اینجا چند تا استراتژی رایج و پیشرفته برای Chunking رو بررسی میکنیم تا بدونید کی و کجا از هرکدوم استفاده کنید.
استراتژیهای پایه و ساده
این روشها نقطه شروع خوبی هستن و پیادهسازی سادهای دارن.
Fixed-size chunking:
سادهترین راه. متن به تکههایی با اندازه ثابت (مثلا ۱۰۰۰ کاراکتر) تقسیم میشه. این روش برای دادههای کثیف و بدون ساختار مثل متنهای استخراج شده از اسکن OCR یا فایلهای لاگ خام مناسبه، ولی ریسک شکستن جملات و از بین رفتن کانتکست رو داره.
Sliding window chunking:
نسخهی بهبود یافتهی روش قبلی. چانکها با هم همپوشانی (overlap) دارن تا کانتکست بینشون حفظ بشه. برای متونی که مفاهیم در جملات طولانی کشیده میشن، مثل مقالات و گزارشهای روایی، کاربرد داره.
Sentence-based chunking:
متن بر اساس پایان جملات (نقطه، علامت سوال و...) شکسته میشه. برای متون تمیز و خوشساختار مثل بلاگپستها و مستندات که هر جمله یک ایده کامل داره، خوبه.
Paragraph-based chunking:
متن بر اساس پاراگرافها تقسیم میشه. وقتی هر پاراگراف یک بلوک معنایی کامل رو تشکیل میده، مثل مقالات یا گزارشها، این روش کانتکست بهتری نسبت به شکستن جمله به جمله فراهم میکنه.
استراتژیهای مبتنی بر ساختار
این روشها از ساختار خود داکیومنت برای تقسیمبندی هوشمندتر استفاده میکنن.
Document-based chunking:
تقسیمبندی بر اساس ساختار طبیعی سند مثل سرفصلها (Headings) و بخشها (Sections) انجام میشه. برای کتابهای درسی، مقالات تحقیقاتی و راهنماها که ساختار سلسلهمراتبی دارن، ایدهآله.
Page-based chunking:
هر صفحه از سند به عنوان یک چانک در نظر گرفته میشه. مشخصاً برای کار با PDF، اسلاید یا کتاب که شماره صفحه اهمیت داره استفاده میشه.
Structured chunking:
برای دادههای ساختاریافته یا نیمهساختاریافته مثل HTML، JSON یا CSV کاربرد داره. در این روش، چانکها بر اساس تگها (مثلا <div> در HTML) یا فیلدهای مشخص تعریف میشن.
Table-aware chunking:
جدولها شناسایی و به صورت جداگانه و با فرمت مناسب (مثلا Markdown یا JSON) چانک میشن تا ساختارشون حفظ بشه.
استراتژیهای پیشرفته و محتوامحور
اینجا از مدلهای زبانی یا الگوریتمهای پیچیدهتر برای درک محتوا و تقسیمبندی بهینه استفاده میشه.
Semantic chunking:
در این روش، جملات یا پاراگرافها بر اساس شباهت معنایی (embedding similarity) گروهبندی میشن. چانکها زمانی شکسته میشن که موضوع بحث تغییر کنه. برای اسناد طولانی با موضوعات مختلف که روشهای ساده جواب نمیدن، خیلی موثره.
Entity-based chunking:
با استفاده از مدلهای Named Entity Recognition (NER)، موجودیتهایی مثل اسامی افراد، مکانها یا محصولات شناسایی شده و متنهای مرتبط با هر موجودیت در یک چانک قرار میگیره. برای تحلیل قراردادهای حقوقی، مقالات خبری یا اسناد مالی خوبه.
Agentic / LLM-based chunking:
اینجا از خود یک LLM خواسته میشه که تصمیم بگیره متن رو چطور تقسیم کنه. این روش قدرت انعطاف بالایی داره ولی کند و پرهزینهست. این روش معمولا overkill حساب میشه، مگر اینکه با دادههای خیلی پیچیده و بدون هیچ ساختاری سر و کار داشته باشید.
Recursive chunking:
یک رویکرد سلسلهمراتبی. اول با جداکنندههای بزرگ مثل پاراگراف شروع میکنه و اگه چانک حاصل بزرگتر از حد مجاز بود، به صورت بازگشتی با جداکنندههای کوچکتر مثل جمله، اون رو میشکنه تا به اندازه مطلوب برسه.
🛠 Join @LLMEngineers Community
یه مدل OCR جدید اومده به اسم dots ocr یه مدل ۳ میلیارد پارامتریه که عملکرد SOTA داره و از ۱۰۰ زبان پشتیبانی میکنه. مهمتر اینکه، استفاده تجاری ازش آزاده. این مدل میتونه عکس، جدول، فرمول و ساختارهای پیچیده رو مستقیماً به فرمت Markdown تبدیل کنه.
به نظر من، این قابلیت تبدیل مستقیم به Markdown خیلی از چالشهای آمادهسازی داده برای RAG رو حل میکنه. دیگه نیازی به چندین مرحله پیشپردازش برای تمیزکاری خروجی OCR و ساختاربندی جداول و فرمولها نیست. یه مدل واحد کار رو تموم میکنه و این یعنی صرفهجویی جدی در زمان و پیچیدگی فنی. حتماً تستش کنید.
🤗 ریپوی مدل
🟠دموی آنلاین
🛠 Join @LLMEngineers Community
به نظر من، این قابلیت تبدیل مستقیم به Markdown خیلی از چالشهای آمادهسازی داده برای RAG رو حل میکنه. دیگه نیازی به چندین مرحله پیشپردازش برای تمیزکاری خروجی OCR و ساختاربندی جداول و فرمولها نیست. یه مدل واحد کار رو تموم میکنه و این یعنی صرفهجویی جدی در زمان و پیچیدگی فنی. حتماً تستش کنید.
🤗 ریپوی مدل
🟠دموی آنلاین
🛠 Join @LLMEngineers Community
مقایسه ابزارهای OCR و PDF parsing بر اساس سرعت، دقت و بازخورد کامیونیتی
ابزار Smoldocling با حجم خیلی کم (زیر ۵۰۰ مگابایت VRAM) میتونه هر صفحه رو روی یه GPU معمولی توی فقط ۰.۳۵ ثانیه پردازش کنه. نکتهی جالبش اینه که توی بنچمارکها مدلهای ۲۷ برابر بزرگتر از خودشو شکست داده.
مدلهایی مثل dots.ocr و MonkeyOCR برای پردازش اسناد چندزبانه جداول پیچیده و حفظ ساختار کلی داکیومنت عملکرد فوقالعادهای دارن. MonkeyOCR با اینکه فقط ۲۵۶ میلیون پارامتر داره، روی اسناد انگلیسی حتی از مدلهای بزرگ مثل Gemini 2.5 Pro هم بهتر عمل کرده. ابزار olmOCR هم دقت بالایی داره ولی بعضی کاربرها توی ردیت گزارش کردن که با جداول پیچیده کمی مشکل داره و گاهی دچار hallucination میشه.
اگر با اسناد علمی، فرمولهای LaTeX و جداول پیچیده سروکار دارید، Nanonets-OCR-s (که بخشی از Mathpix هست) بهترین عملکرد رو داره. برای استخراج از PDF ایزار llamaparse گزینهی خیلی خوبیه. این ابزار برای استخراج جداول و عناصر بصری از دل PDF های پیچیده بهینه شده و مستقیماً برای این کار ساخته شده.
🛠 Join @LLMEngineers Community
ابزار Smoldocling با حجم خیلی کم (زیر ۵۰۰ مگابایت VRAM) میتونه هر صفحه رو روی یه GPU معمولی توی فقط ۰.۳۵ ثانیه پردازش کنه. نکتهی جالبش اینه که توی بنچمارکها مدلهای ۲۷ برابر بزرگتر از خودشو شکست داده.
مدلهایی مثل dots.ocr و MonkeyOCR برای پردازش اسناد چندزبانه جداول پیچیده و حفظ ساختار کلی داکیومنت عملکرد فوقالعادهای دارن. MonkeyOCR با اینکه فقط ۲۵۶ میلیون پارامتر داره، روی اسناد انگلیسی حتی از مدلهای بزرگ مثل Gemini 2.5 Pro هم بهتر عمل کرده. ابزار olmOCR هم دقت بالایی داره ولی بعضی کاربرها توی ردیت گزارش کردن که با جداول پیچیده کمی مشکل داره و گاهی دچار hallucination میشه.
اگر با اسناد علمی، فرمولهای LaTeX و جداول پیچیده سروکار دارید، Nanonets-OCR-s (که بخشی از Mathpix هست) بهترین عملکرد رو داره. برای استخراج از PDF ایزار llamaparse گزینهی خیلی خوبیه. این ابزار برای استخراج جداول و عناصر بصری از دل PDF های پیچیده بهینه شده و مستقیماً برای این کار ساخته شده.
🛠 Join @LLMEngineers Community
خب، OpenAI بالاخره دو تا مدل open-weight واقعی منتشر کرد. اسم این خانواده gpt-oss هست و فعلاً دو تا عضو داره:
gpt-oss-120b:
مدل بزرگ با ۱۱۷ میلیارد پارامتر (۵.۱ میلیارد پارامتر فعال) برای پروداکشن و تسکهای سنگین استدلالی.
gpt-oss-20b:
مدل کوچیک با ۲۱ میلیارد پارامتر (۳.۶ میلیارد پارامتر فعال) برای سختافزارهای ضعیفتر و کاربردهای on-device.
کاربرد اصلیشون برای تسکهای agentic و استدلاله. مدلها text-only هستن و با لایسنس Apache 2.0 منتشر شدن که برای استفاده تجاری عالیه.
برای اجرا، میتونید از فریمورکهای استاندارد مثل transformers، vLLM و Ollama استفاده کنید.
این مدلها قابلیتهای agentic خوبی دارن مثل function calling، وبگردی و اجرای کد پایتون. همچنین میشه سطح استدلال مدل رو از طریق system prompt روی سه حالت low، medium و high تنظیم کرد.
💻 دمو (gpt-oss.com)
نکات کلیدی فنی و معماری:
معماری اصلی این مدلها Mixture-of-Experts یا MoE هست.
مدل 120B دارای ۱۲۸ اکسپرت محلی و مدل 20B دارای ۳۲ اکسپرته.
برای هر توکن، ۴ اکسپرت فعال میشه (experts_per_token: 4).
یک نوآوری مهم، استفاده از کوانتایزیشن MXFP4 به صورت native هست. این کوانتایزیشن ۴ بیتی فقط روی وزنهای MoE اعمال شده. نتیجه اینه که مدل 120B روی یک کارت H100 با ۸۰ گیگ VRAM و مدل 20B روی سختافزار معمولی با ۱۶ گیگ VRAM جا میشه. این برای چنین مدلهای بزرگی، یک دستاورد عالیه.
مکانیزم attention هم ترکیبی طراحی شده. لایهها به صورت یکی در میون از full attention و sliding window attention (با پنجره ۱۲۸ توکنی) استفاده میکنن. از GQA استفاده شده
برای positional encoding هم از Yarn RoPE scaling استفاده شده که به مدل اجازه میده کانتکست طولانی تا 128K توکن رو پشتیبانی کنه.
🤗 مدل gpt-oss-120b در هاگینگ فیس
🤗 مدل gpt-oss-20b در هاگینگ فیس
🛠 Join @LLMEngineers Community
gpt-oss-120b:
مدل بزرگ با ۱۱۷ میلیارد پارامتر (۵.۱ میلیارد پارامتر فعال) برای پروداکشن و تسکهای سنگین استدلالی.
gpt-oss-20b:
مدل کوچیک با ۲۱ میلیارد پارامتر (۳.۶ میلیارد پارامتر فعال) برای سختافزارهای ضعیفتر و کاربردهای on-device.
کاربرد اصلیشون برای تسکهای agentic و استدلاله. مدلها text-only هستن و با لایسنس Apache 2.0 منتشر شدن که برای استفاده تجاری عالیه.
برای اجرا، میتونید از فریمورکهای استاندارد مثل transformers، vLLM و Ollama استفاده کنید.
این مدلها قابلیتهای agentic خوبی دارن مثل function calling، وبگردی و اجرای کد پایتون. همچنین میشه سطح استدلال مدل رو از طریق system prompt روی سه حالت low، medium و high تنظیم کرد.
💻 دمو (gpt-oss.com)
نکات کلیدی فنی و معماری:
معماری اصلی این مدلها Mixture-of-Experts یا MoE هست.
مدل 120B دارای ۱۲۸ اکسپرت محلی و مدل 20B دارای ۳۲ اکسپرته.
برای هر توکن، ۴ اکسپرت فعال میشه (experts_per_token: 4).
یک نوآوری مهم، استفاده از کوانتایزیشن MXFP4 به صورت native هست. این کوانتایزیشن ۴ بیتی فقط روی وزنهای MoE اعمال شده. نتیجه اینه که مدل 120B روی یک کارت H100 با ۸۰ گیگ VRAM و مدل 20B روی سختافزار معمولی با ۱۶ گیگ VRAM جا میشه. این برای چنین مدلهای بزرگی، یک دستاورد عالیه.
مکانیزم attention هم ترکیبی طراحی شده. لایهها به صورت یکی در میون از full attention و sliding window attention (با پنجره ۱۲۸ توکنی) استفاده میکنن. از GQA استفاده شده
برای positional encoding هم از Yarn RoPE scaling استفاده شده که به مدل اجازه میده کانتکست طولانی تا 128K توکن رو پشتیبانی کنه.
🤗 مدل gpt-oss-120b در هاگینگ فیس
🤗 مدل gpt-oss-20b در هاگینگ فیس
🛠 Join @LLMEngineers Community
همچنین OpenAI یه مجموعه Cookbook برای مدلهای gpt-oss منتشر کرده:
- چطور مدلهای gpt-oss رو با Hugging Face Transformers فاینتیون کنیم.
- چطور مدلها رو با فریمورکهای بهینهای مثل vLLM یا به صورت محلی با Ollama اجرا کنیم.
- چطور chain-of-thought خام مدل رو مدیریت و ازش استفاده کنیم.
- و مهمتر از همه، توضیح فرمت پاسخدهی OpenAI Harmony.
این دو مورد آخر خیلی مهمن. چون این مدلها با فرمت Harmony آموزش دیدن و برای استفاده درست و گرفتن Chain-of-Thought، باید با این فرمت آشنا بود.
gpt-oss cookbook
🛠 Join @LLMEngineers Community
- چطور مدلهای gpt-oss رو با Hugging Face Transformers فاینتیون کنیم.
- چطور مدلها رو با فریمورکهای بهینهای مثل vLLM یا به صورت محلی با Ollama اجرا کنیم.
- چطور chain-of-thought خام مدل رو مدیریت و ازش استفاده کنیم.
- و مهمتر از همه، توضیح فرمت پاسخدهی OpenAI Harmony.
این دو مورد آخر خیلی مهمن. چون این مدلها با فرمت Harmony آموزش دیدن و برای استفاده درست و گرفتن Chain-of-Thought، باید با این فرمت آشنا بود.
gpt-oss cookbook
🛠 Join @LLMEngineers Community
این نمودار عملکرد مدلهای gpt-oss رو در بنچمارک Humanity's Last Exam نشون میده که شامل سوالات بسیار تخصصی در حوزههای مختلفه. این بنچمارک، توانایی استدلال عمیق و دانش تخصصی مدل رو به چالش میکشه.
مدل gpt-oss-120b با استفاده از ابزار (with tools) به دقت ۱۹٪ میرسه. این بهترین عملکرد در بین مدلهای open-weight موجود در این نموداره.
با این حال، هنوز فاصله قابل توجهی با مدلهای بسته و قدرتمندتر مثل o3 وجود داره که به دقت ۲۴.۹٪ رسیده.
مهمترین نکته، تأثیر ابزارهاست. دقت gpt-oss-120b بدون ابزار از ۱۹٪ به ۱۴.۹٪ سقوط میکنه. این الگو برای مدل gpt-oss-20b هم تکرار میشه (۱۷.۳٪ در مقابل ۱۰.۹٪).
نکته جالب اینه که gpt-oss-120b با ابزار (۱۹٪) عملکرد بهتری از o4-mini با ابزار (۱۷.۷٪) داره که این یک امتیاز مثبت برای این مدل اپن سورس محسوب میشه.
🛠 Join @LLMEngineers Community
مدل gpt-oss-120b با استفاده از ابزار (with tools) به دقت ۱۹٪ میرسه. این بهترین عملکرد در بین مدلهای open-weight موجود در این نموداره.
با این حال، هنوز فاصله قابل توجهی با مدلهای بسته و قدرتمندتر مثل o3 وجود داره که به دقت ۲۴.۹٪ رسیده.
مهمترین نکته، تأثیر ابزارهاست. دقت gpt-oss-120b بدون ابزار از ۱۹٪ به ۱۴.۹٪ سقوط میکنه. این الگو برای مدل gpt-oss-20b هم تکرار میشه (۱۷.۳٪ در مقابل ۱۰.۹٪).
نکته جالب اینه که gpt-oss-120b با ابزار (۱۹٪) عملکرد بهتری از o4-mini با ابزار (۱۷.۷٪) داره که این یک امتیاز مثبت برای این مدل اپن سورس محسوب میشه.
🛠 Join @LLMEngineers Community