AI Engineers

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

فرض کن دسترسی ایجنت به ابزارها مثل فرستادنش تو یه آشپزخونه‌ست.
فایل Skill همون دستور پخت، لیست مواد و روش کنترل کیفیته. نقطه ورودش فایل SKILL.md هست.

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

محدودیت حافظه مدل‌ها دلیل اصلیه.
برای همین از تکنیک Progressive Disclosure استفاده می‌شه:
اول فقط نام و توضیح کوتاه مهارت‌ها داده می‌شه، بعد فقط وقتی لازم باشه متن کامل خوانده می‌شه.

بخش description تو SKILL.md خیلی مهمه.
مدل بر اساس این چند خط تصمیم می‌گیره مهارت رو فعال کنه یا نه.
توضیحات کلی هدر رفت توکن میاره.

اسکیل با تنظیمات دائمی پروژه (CLAUDE.md / AGENTS.md) و با ابزارها فرق داره.
مهارت برای روندهای خاص و گاه‌به‌گاهه و به ایجنت یاد می‌ده چطور ابزارها رو با ترتیب درست ترکیب کنه.

تو متن Skill شعار ننویس.
مراحل دقیق و Gotchaهای پروژه رو بنویس (نکاتی که مدل خودش نمی‌تونه حدس بزنه).

ویژگی جالب Skill Bundle
تو Hermes می‌تونی چند مهارت مرتبط رو داخل یه فایل YAML گروه‌بندی کنی و با یک دستور همه‌شون رو یک‌جا لود کنی.

مثال:

name: backend-dev
skills:  
  - github-code-review  
  - test-driven-development  
  - github-pr-workflow  

بعد فقط اینو بنویس:
/backend-dev refactor the auth middleware

ایجنت همزمان چند مهارت رو بارگذاری می‌کنه؛ عالی برای workflowهای تکراری.

بهترین روش ساختن مهارت اینه که خودت یک‌بار کار واقعی رو انجام بدی، مشکلاتش رو پیدا کنی و بعدش تبدیلش کنی به یه رویه استاندارد برای ایجنت.

🛠 Join @LLMEngineers Community

مدل Qwen3.8-Max منتشرشد، جدیدترین و قوی‌ترین مدل سری Qwen .

چیزایی که خاصش می‌کنه:

🔹 ۲.۴ تریلیون پارامتر داره ولی فقط حدود ۹۵ میلیاردش فعال می‌شه (MoE هوشمند). یعنی هم غوله هم نسبتاً ارزون و سریع کار می‌کنه.

🔹 برای اولین بار یه مدل Max-کلاس رو قراره هفته‌ی بعد وزن‌هاش رو اوپن‌سورس کنن. قبلاً اینا رو بسته نگه می‌داشتن.

🔹 یه تست دیوانه‌وار دادن: از یه فولدر خالی شروع کرد و ۱۶ روز کامل بدون هیچ دخالت انسانی یه فریم‌ورک ایجنت خودتکامل‌دهنده ساخت (oh-my-cli). کامیت و PR و ایشو همه‌ش رو خودش زد و تو گیت‌هاب هم قابل دیدنِ.

🔹 مولتی‌مودالِ واقعی. ویژن فقط ورودی نیست، تو حلقه‌ی برنامه‌ریزی و اجرا و خودتصحیح هم هست. سند صدصفحه‌ای، ویدیو طولانی، لایو استریم… همه رو قورت می‌ده.

🔹 کانتکست ۱ میلیون توکنی + قیمت نسبتاً خوب (۲ دلار ورودی / ۶ دلار خروجی به ازای هر میلیون توکن)

🛠 Join @LLMEngineers Community

تو دنیای مدل‌های زبانی یه فرمول ساده داریم: عامل هوشمند (AI Agent) مساویه با مدل به‌علاوه‌ی Harness.

مدل زبانی به‌تنهایی فقط یه پیش‌بینی‌کننده‌ی متنه. برای اینکه بتونه کار واقعی انجام بده، به یه لایه‌ی نرم‌افزاری دور خودش نیاز داره که ابزارها، حافظه و منطق اجرا رو بهش بده؛ به این لایه می‌گن Agent Harness.

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

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

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

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

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

محتوای ورودی رو محدود نگه دار. هرچی ابزار و دستورالعمل دائمی بیشتری تعریف کنی، توکن بیشتری هدر می‌ره.
ابزارهایی که لازم نداری رو غیرفعال کن. تو هرمس بهتره به جای یه دستیار همه‌کاره، چند تا پروفایل جداگانه برای برنامه‌نویسی، تحقیق یا کارهای سرور بسازی.
تو کلاود کد هم بعد از تموم شدن هر تسک، حتماً تاریخچه رو با دستور clear/ پاک کن تا هزینه‌ی اضافی ندی.

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

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

🛠 Join @LLMEngineers Community

مدل deepseek v4 flash اپدیت شد
همچنین مدل Gpt5.6 luna هم اپدیت شد
جفتشون عملکردشون نسبت به هزینشون فوق العادس
مدل های محبوب من برای کدنویسی ان

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

AI/ML Research Scientist
تمرکزش روی خلق ایده‌ها، معماری‌های جدید و نوشتن مقاله‌های علمیه. موفقیتش با نوآوری و آزمایش‌های تئوری سنجیده می‌شه و معمولاً مدرک دکترا یا رزومه پژوهشی خیلی قوی می‌خواد.

AI/ML Research Engineer
کارش اینه که اون ایده‌های تئوری و مقاله‌ها رو به کدهای واقعی تبدیل کنه تا بشه روشون آزمایش انجام داد. زیرساخت‌های لازم برای آموزش مدل و جمع‌آوری دیتا رو می‌سازه و بیشتر از دانشمند تحقیق، دست به کد هست.

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

Machine Learning Engineer
مسئولیتش اینه که مدل رو به یه نرم‌افزار پایدار و قابل استفاده برای کاربر تبدیل کنه. از مدیریت مسیرهای انتقال داده (Data Pipelines) گرفته تا مانیتورینگ و نگهداری مدل توی محیط واقعی؛ در واقع یه مهندس نرم‌افزاره که تخصصش یادگیری ماشینه.

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

ML/AI Platform Engineer
ابزارهای داخلی می‌سازه تا بقیه مهندس‌های همون شرکت بتونن راحت‌تر کارهای ماشین‌لرنینگی رو انجام بدن؛ مثلاً سیستم‌های خودکار برای تست مدل یا ثبت نسخه‌های مختلف مدل (Model Registry).

ML/AI Infrastructure Engineer
تمرکزش روی لایه‌های زیرساختی و سخت‌افزاریه. مدیریت سرورها، پردازش‌های موازی سنگین، خوشه‌بندی پردازنده‌ها و کلاً هر چیزی که به پایداری و مقیاس‌پذیری سیستم محاسباتی ربط داره.

ML Framework Engineer
روی هسته اصلی کتابخانه‌ها و ابزارهای پایه کار می‌کنه. مثلاً بهینه‌سازی کدهای سطح پایین برای کتابخانه‌هایی مثل PyTorch یا کار روی کامپایلرهایی که مدل رو برای اجرا روی سخت‌افزار آماده می‌کنن.

AI Hardware Engineer
کارش طراحی و بهینه‌سازی تراشه‌ها و قطعات سخت‌افزاریه که مخصوص پردازش‌های سنگین هوش مصنوعی ساخته می‌شن؛ مثل کار روی پردازنده‌های گرافیکی یا تراشه‌های مخصوص پردازش عصبی.

ML/AI Solutions Architect
قبل از پیاده‌سازی، نیاز مشتری رو بررسی می‌کنه و طراحی می‌کنه که چطور ابزارهای هوش مصنوعی باید توی سیستم‌های بزرگ مشتری جا بگیرن و با بقیه بخش‌ها کار کنن.

AI/ML Solutions Engineer
بیشتر نقش اجرایی و پشتیبانی داره. به مشتری‌ها کمک می‌کنه تا محصول رو عملاً راه بندازن، کدها رو یکپارچه کنن و اگه موقع نصب یا استفاده مشکلی پیش اومد حلش کنن.

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

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

منبع: کتاب Machine Learning Interviews اثر Chip Huyen

🛠 Join @LLMEngineers Community

سلام دوستان عزیز 👋
بعد از تجربه‌ی خوبی که با Bina OCR و شنوا (ASR فارسی) داشتیم (هنوز تموم نشده)، پروژه‌ی بعدی‌مون شروع شده: ساخت یه مدل TTS فارسی متن‌باز 🎙️
یکی از بزرگ‌ترین چالش‌های TTS فارسی اینه که خط فارسی حرکت‌گذاری نمی‌شه، پس مدل باید حدس بزنه کلمه چطور تلفظ می‌شه. مثلاً «برگزاری» رو می‌شه چند جور خوند، و بدون داده‌ی درست، مدل گاهی اشتباه تلفظ می‌کنه.
برای حل این مشکل یه مینی‌گیم ساختیم که توش شما تلفظ درست کلمات رو مشخص می‌کنید. چند ثانیه وقت می‌گیره ولی داده‌ای که جمع می‌شه مستقیم می‌ره تو آموزش مدل TTS 🙏
اگه دوست دارید کمک کنید یه پروژه‌ی متن‌باز فارسی جلو بره:
👉 https://persianasr.com/Gooya-2/

هرچی مشارکت بیشتر بشه، مدل باکیفیت‌تر
می‌شه. ممنون از همراهیتون ❤️

🛠 Join @LLMEngineers Community

یه مجموعه اسکیل رو به صورت ازمایشی ساختم تا فرآیند Spec-Driven Development رو توی ابزارهای کدنویسی پیاده کنیم... ایده اصلی اینه که جلوی گیج شدن coding agentها و گم شدن تصمیمات معماری رو بگیریم.

مشکل اینجاست که وقتی به agent می‌گیم یه قابلیت بزرگ رو بسازه، جزئیات مهم و نیازمندی‌ها ته تاریخچه چت گم می‌شن... معمولاً هم به یک build سبز یا تست‌های ساده بسنده می‌کنن که اصلاً ضامن درست بودن منطق برنامه نیست.

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

چند تا skill براش تعریف کردم:

- اسکیل sdd-harness: مشخص می‌کنه که هر task چقدر سخت‌گیری و سندسازی لازم داره تا تعادل بین سرعت و دقت حفظ بشه.

- اسکیل sdd-feature: کار رو به چهار بخش spec.md (چی می‌خوایم)، design.md (چطور پیاده بشه)، tasks.md (لیست کارها) و verification.md (مدارک اثبات) تقسیم می‌کنه.

- اسکیل sdd-review: یک مرحله ارزیابی مستقل قبل از merge یا release که کورکورانه به خروجی agent اعتماد نمی‌کنه.

نکته مهم: هنوز خودم این workflowها و skillها رو توی پروژه‌های واقعی و سنگین تست نکردم... همه‌چیز فعلاً در حد آزمایش و Experimental هست و ممکنه نیاز به اصلاح داشته باشه.

این ابزارها فعلاً روی محیط‌هایی مثل Claude Code، OpenAI Codex، Hermes Agent و GitHub Copilot قابل استفاده‌ست:

https://github.com/mshojaei77/sdd-agent-skills

🛠 Join @LLMEngineers Community

مدل جدید کیمی K3 کلاً قضیه مدل‌های متن‌باز رو وارد یه مرحله جدید کرده... یه مدل غول‌پیکر با ۲.۸ تریلیون پارامتر کل که موقع جواب دادن به هر کلمه، ۱۰۴ میلیارد پارامترش فعال می‌شن و تا ۱ میلیون توکن متن یا تصویر رو هم‌زمان پردازش می‌کنه.

سازنده‌هاش تونستن بازدهی آموزش مدل رو نسبت به نسل قبل ۲.۵ برابر بهتر کنن. خلاصه تغییرات مهمش ایناست:

- ترکیب هوشمندانه توجه (Hybrid Attention):
برای اینکه موقع خواندن متن‌های خیلی طولانی حافظه کارت گرافیک پر نشه، ۳ لایه از یک مکانیزم سبک و سریع خطی با نام Kimi Delta Attention استفاده کردن و بعد ۱ لایه توجه کامل با نام Gated MLA گذاشتن. این ترکیب باعث می‌شه مدل متن‌های طولانی رو بدون کند شدن بفهمه.

- برداشت هوشمند از لایه‌های قبلی (Attention Residuals):
توی مدل‌های قدیمی، هر لایه فقط اطلاعات لایه قبلی خودش رو می‌گرفت. اینجا هر لایه می‌تونه برگرده و بر اساس نیاز از اطلاعات لایه‌های خیلی عقب‌تر هم استفاده کنه تا مفاهیم پیچیده رو فراموش نکنه.

- تقسیم کار بین ۸۹۶ کارشناس کوچک (MoE):
به جای یک شبکه یک‌دست، مدل از ۸۹۶ کارشناس تخصصی کوچک تشکیل شده که برای هر کلمه فقط ۱۶ تاشون انتخاب می‌شن. با یک روش ریاضی جدید به اسم Quantile Balancing کاری کردن که بار پردازشی کاملاً مساوی تقسیم بشه و هیچ کارشناسی بی‌کار نمونه.

- پردازش تصویر بومی بدون مدل کمکی (MoonViT-V2):
بخش فهم تصویر مدل از همون روز اول همراه با متن آموزش دیده؛ برعکس مدل‌های دیگه که یک مدل تصویربردار آماده رو به متن وصل می‌کردن. این کار پایداری مدل رو موقع یادگیری خیلی بالاتر برده.

چرا این مدل مهمه؟
- توی تست‌های کدنویسی و هوش خودکار (مثل چرخیدن توی وب و انجام کارهای چندمرحله‌ای) پا‌به‌پای قوی‌ترین مدل‌های تجاری مثل Claude Fable 5 و GPT-5.6 Sol می‌اد.
- نمره ۹۳.۵٪ توی آزمون دانش و استدلال GPQA Diamond گرفته.
- هزینه‌ی اجرایی هر درخواستش حدود یک‌سوم مدل‌های تجاری مشابه هست.

نقطه ضعفش کجاست؟
توی استدلال‌های خیلی پیچیده در سطح تحقیقات علمی (مثل بنچمارک CritPt با نمره ۲۳.۴٪) هنوز عقب‌تر از مدل‌های تجاری قوی می‌افته که نشون می‌ده مدل‌های متن‌باز توی استدلال عمیق هنوز جای کار دارن.
https://github.com/MoonshotAI/Kimi-K3/blob/main/k3_tech_report.pdf

🛠 Join @LLMEngineers Community

امروز داشتم پیپر SkillOpt رو می‌خوندم که مایکروسافت منتشر کرده. یه ایده کاربردی برای وقت‌هایی که به وزن‌های مدل دسترسی نداریم یا تغییر دادنشون گرونه.

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

ایده اصلی این پیپر اینه که فایل متنی SKILL.md رو مثل یه متغیر قابل آموزش توی شبکه‌های عصبی در نظر بگیریم. مدل اصلی کاملا ثابت می‌مونه و یه مدل دیگه به عنوان بهینه‌ساز، فقط روی همون متن کار می‌کنه.

سازوکارش دقیقا از مفاهیم یادگیری عمیق الگو برداشته، ولی روی فضای متن:
- اول مدل روی یه دسته از تسک ها کار میکنه تا خروجی‌های درست و غلط جمع بشن.
- مدل بهینه‌ساز، الگوهای تکراریِ شکست و موفقیت رو تحلیل می‌کنه.
- به جای اینکه کل متن رو از نو بنویسه، فقط بخش‌های خاصی رو اضافه یا جایگزین می‌کنه. این سقف تعداد تغییرات مجاز، اینجا دقیقا کارکرد نرخ یادگیری رو داره تا متن یهو به هم نریزه.
- تغییرات روی یه دیتاسِت جداگانه تست می‌شن. فقط اگه امتیاز واقعا بهتر بشه، تغییر روی فایل نهایی اعمال می‌شه.
- اگه تغییری امتیاز رو کم کنه، میره تو یه حافظه موقت تا مدل دوباره همون اشتباه رو برای ویرایش‌های بعدی تکرار نکنه.

نتایج تست‌ها روی شش تا بنچمارک مختلف (از پرسش‌وپاسخ تا کار با فایل‌های اکسل) و هفت تا مدل (از نسخه‌های جی‌پی‌تی ۵.۵ تا qwen) نشون میده که این روش به شدت خوب کار می‌کنه.
- روی جی‌پی‌تی ۵.۵، میانگین دقت رو حدود ۲۳.۵ درصد نسبت به حالت بدون دستورالعمل بالا برده.
- خروجی نهایی بعد از همه این کارها، فقط یه فایل متنی کوچیک بین ۳۰۰ تا ۲۰۰۰ توکنه.
- دستورالعملی که برای یه مدل قوی بهینه شده، به طرز عجیبی روی مدل‌های کوچیک‌تر هم جواب می‌ده و قابل انتقاله.

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

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

🛠 Join @LLMEngineers Community

Find out what you can’t do…

Explain what happens when your input exceeds the context window?

پروژه OpenBench v1 برای ارزیابی و بنچمارک دقیق ایجنت‌های کدنویسی منتشر شد... ابزاری متن‌باز که روی مقایسه و سنجش harnessها تمرکز داره.

اکثر تیم‌ها تمام تمرکز رو روی انتخاب مدل گذاشتن - اما یک ایجنت کدنویسی حاصل ترکیب مدل و harness است؛ یعنی همون ابزارهای جانبی، پرامپت‌ها، دسترسی‌ها و سیستم مدیریت اجرای اطراف مدل. وقتی مدل یکسان باشه (مثلاً gpt-5.6)، تغییر دادن harness از cursor به codex، claude یا devin می‌تونه درصد موفقیت و هزینه‌ها رو کلاً تغییر بده.

معیارهای سنجش توی این فریم‌ورک روی سه محور اصلی میچرخه: درصد درستی (correctness)، میزان مصرف token (ورودی، خروجی و cache) و تاخیر زمانی (latency)... ارزیابی‌ها هم داخل کانتینرهای ایزوله Docker اجرا میشن و صحت کد با اسکریپت‌های checker مستقل ارزیابی میشه، نه ادعای خود ایجنت.

https://github.com/minghinmatthewlam/openbench

🛠 Join @LLMEngineers Community

براساس این بنچمارک ما که دارای ۶,۶۶۹ خط متن تایپی و ۶,۶۶۹ صفحه متن دست نویس هست: بینا ۰.۱ در حال حاضر بهترین مدل تشخیص متن فارسی تایپی و دست نویسه! 🔥🔥

AI Engineers pinned «پروژه Bina OCR رو کلاً یک هفته‌ست که استارت زدیم و امروز اولین بنچمارک واقعی رو ازش گرفتیم... نتیجه حتی برای خودمون هم غیرمنتظره بود. مدل Bina 0.1 توی تست‌های OCR فارسی جلوتر از مدل‌های بزرگی مثل Gemini 3.5 Flash قرار گرفت. البته این تازه اول مسیره و هنوز…»

پروژه Bina OCR رو کلاً یک هفته‌ست که استارت زدیم و امروز اولین بنچمارک واقعی رو ازش گرفتیم... نتیجه حتی برای خودمون هم غیرمنتظره بود. مدل Bina 0.1 توی تست‌های OCR فارسی جلوتر از مدل‌های بزرگی مثل Gemini 3.5 Flash قرار گرفت. البته این تازه اول مسیره و هنوز کلی باگ و کار زمین‌مونده داریم.

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

این پروژه با همکاری رضا سیار جلو رفته که قبلاً هم سیستم شنوا (ASR فارسی) رو توسعه داده بود. از اون دست به کیبوردهایی که کمتر حرف می‌زنن و بیشتر کد می‌زنن. (اسپویلر: پروژه بعدی هم قراره tts فارسی باشه)

واقعیت فنی اینه که ساختن یه مدل خوب، بیشتر از اینکه درگیر بازی با معماری و مدل‌های عجیب‌وغریب باشه، لنگِ داده‌ست. برای اینکه نسخه‌های بعدی Bina OCR بتونن کارهای سخت‌تر رو انجام بدن به چندتا چیز نیاز مبرم داریم: داده‌های متنوع‌تر، اسناد واقعی‌تر، دستخط‌های نامرتب و البته قدرت پردازش (compute) برای آموزش و تست.

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

نسخه اولیه مدل :
https://huggingface.co/Reza2kn/Bina-0.1
کامیونیتی تلگرام پروژه :
https://t.me/bina_ocr


🛠 Join @LLMEngineers Community