یه مدل جدید به اسم 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
این نمودار عملکرد کدنویسی مدلهای gpt-oss رو در مسائل مسابقات برنامهنویسی Codeforces، نشون میده.
مدل gpt-oss-120b با استفاده از tools (ابزارهایی مثل مفسر پایتون) به ریتینگ قابل احترام ۲۶۲۲ رسیده. این امتیاز خیلی بالاست و نشوندهنده توانایی بالای استدلال الگوریتمیه.
با این حال، هنوز از مدلهای بسته مثل o4-mini که ریتینگ ۲۷۱۹ داره، کمی ضعیفتره.
عملکرد مدل gpt-oss-20b هست. این مدل کوچیک وقتی از ابزار استفاده میکنه، به ریتینگ ۲۵۱۶ میرسه که حتی از مدل ۱۲۰ میلیاردی بدون ابزار هم بهتره. این نشون میده معماری و آموزش برای استفاده از ابزار چقدر بهینهست.
🛠 Join @LLMEngineers Community
مدل gpt-oss-120b با استفاده از tools (ابزارهایی مثل مفسر پایتون) به ریتینگ قابل احترام ۲۶۲۲ رسیده. این امتیاز خیلی بالاست و نشوندهنده توانایی بالای استدلال الگوریتمیه.
با این حال، هنوز از مدلهای بسته مثل o4-mini که ریتینگ ۲۷۱۹ داره، کمی ضعیفتره.
عملکرد مدل gpt-oss-20b هست. این مدل کوچیک وقتی از ابزار استفاده میکنه، به ریتینگ ۲۵۱۶ میرسه که حتی از مدل ۱۲۰ میلیاردی بدون ابزار هم بهتره. این نشون میده معماری و آموزش برای استفاده از ابزار چقدر بهینهست.
🛠 Join @LLMEngineers Community
با انتشار مدل های gpt-oss-20b و gpt-oss-120b به صورت اوپن سورس OpenAI کاملاً داره رقیباشو له میکنه
مقایسه با مدل های Qwen با اینکه اینا حدود ۵ برابر پارامترهای فعال کمتر دارن
🛠 Join @LLMEngineers Community
مقایسه با مدل های Qwen با اینکه اینا حدود ۵ برابر پارامترهای فعال کمتر دارن
🛠 Join @LLMEngineers Community
LLM Engineers
Photo
فرمت Harmony که OpenAI با مدلهای gpt-oss معرفی کرده، یه پروتکل ساختاریافته برای تعامل با مدلهای ایجنتمحوره.
چند تا از کلیدیترین ویژگیهای این فرمت:
کانالهای مجزا (Channels): این نوآورانهترین بخش فرمته. به جای اینکه کل جواب مدل یه تیکه تکست باشه، به کانالهای مختلف تقسیم میشه:
کانال analysis: اینجا جاییه که Chain-of-Thought (CoT) یا همون فرآیند فکری مدل قرار میگیره. این همون بخشیه که فیلتر نشده و نباید مستقیم به کاربر نشون داده بشه.
کانال commentary: برای فراخوانی ابزارها (tool calls) استفاده میشه. مدل توی این کانال، پارامترهای فانکشن مورد نظرش رو به صورت ساختاریافته برمیگردونه.
کانال final: این کانال حاوی جواب تمیز و نهاییه که برای نمایش به کاربر در نظر گرفته شده.
نقش Developer و سلسلهمراتب: علاوه بر نقش System و User، یه نقش جدید به اسم Developer اضافه شده. این نقش برای تعریف ابزارها و دادن دستورالعملهای سطح بالا به مدل استفاده میشه. نکته حیاتی، سلسلهمراتب دستوریه: System > Developer > User. این یعنی دستورات System به Developer و دستورات Developer به User ارجحیت دارن و این به دولوپر کنترل دقیقی روی رفتار مدل میده.
تنظیم سطح استدلال (Reasoning Effort): داخل System پراپمت میتونید مشخص کنید که مدل چقدر برای رسیدن به جواب تلاش کنه. سه سطح low، medium و high وجود داره که به شما اجازه میده بین سرعت و دقت، یه تریدآف هوشمندانه برقرار کنید.
کتابخانه رسمی: برای اینکه درگیر پیچیدگیهای رندر و پارس کردن این فرمت رشتهای نشید، OpenAI یه کتابخونه رسمی به اسم openai-harmony منتشر کرده. این کتابخونه که هستهش با Rust برای پرفورمنس بالا نوشته شده و با pyo3 به پایتون متصل شده، به شما اجازه میده با آبجکتهای پایتونی مثل Conversation و Message کار کنید و خود کتابخونه زحمت تبدیلش به توکنهای مورد نیاز مدل رو میکشه.
به نظر من، فرمت Harmony یه شمشیر دولبهست. از یه طرف، با جدا کردن CoT از جواب نهایی، شفافیت و کنترل بینظیری به دولوپر میده و راه رو برای ساخت ایجنتهای پیچیده باز میکنه. از طرف دیگه، پیچیدگی پیادهسازی رو به شدت بالا میبره و مسئولیت مدیریت این فرمت کاملاً روی دوش دولوپره. در واقع OpenAI داره یه استاندارد جدید رو به کامیونیتی تحمیل میکنه که برای استفاده از مدلهاش باید ازش پیروی کنید.
💻 اطلاعات بیشتر و کتابخانه Harmony
🛠 Join @LLMEngineers Community
چند تا از کلیدیترین ویژگیهای این فرمت:
کانالهای مجزا (Channels): این نوآورانهترین بخش فرمته. به جای اینکه کل جواب مدل یه تیکه تکست باشه، به کانالهای مختلف تقسیم میشه:
کانال analysis: اینجا جاییه که Chain-of-Thought (CoT) یا همون فرآیند فکری مدل قرار میگیره. این همون بخشیه که فیلتر نشده و نباید مستقیم به کاربر نشون داده بشه.
کانال commentary: برای فراخوانی ابزارها (tool calls) استفاده میشه. مدل توی این کانال، پارامترهای فانکشن مورد نظرش رو به صورت ساختاریافته برمیگردونه.
کانال final: این کانال حاوی جواب تمیز و نهاییه که برای نمایش به کاربر در نظر گرفته شده.
نقش Developer و سلسلهمراتب: علاوه بر نقش System و User، یه نقش جدید به اسم Developer اضافه شده. این نقش برای تعریف ابزارها و دادن دستورالعملهای سطح بالا به مدل استفاده میشه. نکته حیاتی، سلسلهمراتب دستوریه: System > Developer > User. این یعنی دستورات System به Developer و دستورات Developer به User ارجحیت دارن و این به دولوپر کنترل دقیقی روی رفتار مدل میده.
تنظیم سطح استدلال (Reasoning Effort): داخل System پراپمت میتونید مشخص کنید که مدل چقدر برای رسیدن به جواب تلاش کنه. سه سطح low، medium و high وجود داره که به شما اجازه میده بین سرعت و دقت، یه تریدآف هوشمندانه برقرار کنید.
کتابخانه رسمی: برای اینکه درگیر پیچیدگیهای رندر و پارس کردن این فرمت رشتهای نشید، OpenAI یه کتابخونه رسمی به اسم openai-harmony منتشر کرده. این کتابخونه که هستهش با Rust برای پرفورمنس بالا نوشته شده و با pyo3 به پایتون متصل شده، به شما اجازه میده با آبجکتهای پایتونی مثل Conversation و Message کار کنید و خود کتابخونه زحمت تبدیلش به توکنهای مورد نیاز مدل رو میکشه.
به نظر من، فرمت Harmony یه شمشیر دولبهست. از یه طرف، با جدا کردن CoT از جواب نهایی، شفافیت و کنترل بینظیری به دولوپر میده و راه رو برای ساخت ایجنتهای پیچیده باز میکنه. از طرف دیگه، پیچیدگی پیادهسازی رو به شدت بالا میبره و مسئولیت مدیریت این فرمت کاملاً روی دوش دولوپره. در واقع OpenAI داره یه استاندارد جدید رو به کامیونیتی تحمیل میکنه که برای استفاده از مدلهاش باید ازش پیروی کنید.
💻 اطلاعات بیشتر و کتابخانه Harmony
🛠 Join @LLMEngineers Community
GitHub
GitHub - openai/harmony: Renderer for the harmony response format to be used with gpt-oss
Renderer for the harmony response format to be used with gpt-oss - openai/harmony
این جدول ارزیابی Hallucination مدلهای gpt-oss خیلی چیزها رو روشن میکنه.
نتایج فاجعهباره. مدل gpt-oss-20b روی بنچمارک SimpleQA نرخ توهم یا همون hallucination rate حدود ۹۱٪ داره. یعنی از هر ۱۰ تا جواب، ۹ تاش اشتباه یا ساختگیه. دقتش هم طبیعتاً خیلی پایینه، فقط حدود ۷٪.
نسخه بزرگتر یعنی gpt-oss-120b یکم بهتره ولی هنوز نرخ توهم ۷۸٪ داره که اصلاً قابل قبول نیست. در مقایسه، مدل OpenAI o4-mini با اینکه خودش هم بینقص نیست، نرخ توهم و دقت به مراتب بهتری رو ثبت کرده.
🛠 Join @LLMEngineers Community
نتایج فاجعهباره. مدل gpt-oss-20b روی بنچمارک SimpleQA نرخ توهم یا همون hallucination rate حدود ۹۱٪ داره. یعنی از هر ۱۰ تا جواب، ۹ تاش اشتباه یا ساختگیه. دقتش هم طبیعتاً خیلی پایینه، فقط حدود ۷٪.
نسخه بزرگتر یعنی gpt-oss-120b یکم بهتره ولی هنوز نرخ توهم ۷۸٪ داره که اصلاً قابل قبول نیست. در مقایسه، مدل OpenAI o4-mini با اینکه خودش هم بینقص نیست، نرخ توهم و دقت به مراتب بهتری رو ثبت کرده.
🛠 Join @LLMEngineers Community
نتایج بنچمارکهای EQ-Bench و نویسندگی خلاقانه برای مدلهای gpt-oss منتشر شده و خب، ناامیدکنندهست. این مدلها در زمینههایی که نیاز به هوش هیجانی و خلاقیت داره، عملکرد ضعیفی از خودشون نشون دادن.
این ضعف احتمالاً به خاطر معماری MoE و تعداد پایین پارامترهای فعال (active parameters) در هر لحظهست. با اینکه مدل کلی مثلاً ۱۲۰ میلیارد پارامتر داره، اما برای پردازش هر توکن فقط بخش کوچکی از این پارامترها فعال میشن. این موضوع میتونه روی غنای زبانی و خلاقیت خروجی تأثیر منفی بذاره. البته عملکرد بالای این مدلها در بنچمارکهای دیگه نشون میده که اولویتهای OpenAI جای دیگهای بوده؛ احتمالاً روی کدنویسی، استدلال منطقی و tool use
🛠 Join @LLMEngineers Community
این ضعف احتمالاً به خاطر معماری MoE و تعداد پایین پارامترهای فعال (active parameters) در هر لحظهست. با اینکه مدل کلی مثلاً ۱۲۰ میلیارد پارامتر داره، اما برای پردازش هر توکن فقط بخش کوچکی از این پارامترها فعال میشن. این موضوع میتونه روی غنای زبانی و خلاقیت خروجی تأثیر منفی بذاره. البته عملکرد بالای این مدلها در بنچمارکهای دیگه نشون میده که اولویتهای OpenAI جای دیگهای بوده؛ احتمالاً روی کدنویسی، استدلال منطقی و tool use
🛠 Join @LLMEngineers Community
بزودی خودم یسری بنچمارک روی عملکرد مدل روی دانش زبان فارسی و ایرانی اجرا میکنم و مدل های مختلف رو تست میزنم از جمله مدل های gpt-oss