AI Engineers

بینا ۰.۱ ✨ 👀

نشستم ۲۲ تا ابزار کدزنی AI رو با هم مقایسه کردم... بحث سر Harness یا همون بستر اجرای مدله. یعنی اون سیستم مدیریت کانتکست و ابزارهایی که دور مدل کشیده شده.

خلاصه چندتا دسته‌بندی اصلی:
— اگه دنبال سرعت و تجربه تمیز توی ادیتوری: Cursor هنوز بی‌رقیبه.
— اگه گیک ترمینالی: Claude Code جادو می‌کنه.
— اگه کنترل کامل و دنیای متن‌باز رو می‌خوای: Cline و opencode رو حتماً تست کن.
— اگه می‌خوای تسک رو بسپری به ایجنت و بری سراغ کارای دیگه: Devin و Codex و Jules گزینه‌های اصلی‌ان.

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

لینک مقاله:
https://medium.com/@mshojaei77/i-compared-22-ai-coding-harnesses-most-developers-are-comparing-the-wrong-thing-4efb26650fcd

🛠 Join @LLMEngineers Community

مفهوم Agent Harness یا Harness Engineering یکی از اون اصطلاحاتیه که این روزها زیاد شنیده می‌شه، اما چون هم خیلی کلیه و هم خیلی تخصصی، خیلیا هنوز دقیقاً نمی‌دونن چیه. در ساده‌ترین تعریف، خیلیا فکر می‌کنن Harness فقط همون محیط (Environment) اجرای ایجنت هست، اما داستان خیلی عمیق‌تر از این حرف‌هاست.

برای درک بهتر، باید مسیر تکامل تعامل با مدل‌ها رو ببینیم:

۱. سال ۲۰۲۳ و Prompt Engineering:
اوایل که ChatGPT اومد، با Context Window محدود (۴۰۹۶ توکن) درگیر بودیم. تمام تلاشمون این بود که با نوشتن پرامپت‌های بهتر، خروجی دقیق‌تری بگیریم. اما برای کارهای پیچیده اصلاً کافی نبود.

۲. سال ۲۰۲۴ و Context Engineering:
اینجا ابزارهایی مثل RAG، Tool Calling و پروتکل‌هایی مثل MCP وارد شدن. هدف این بود که کانتکست مدل رو بهتر مدیریت کنیم تا ایجنت بتونه به دیتابیس یا فایل‌های خاص دسترسی داشته باشه. اما یک مشکل بزرگ وجود داشت: وقتی تسک‌ها طولانی می‌شد (مثلاً ۱۰-۱۲ ساعت کار مداوم)، کانتکست پر می‌شد و ایجنت مجبور بود اطلاعات رو خلاصه‌سازی (Summarize) کنه. این کار باعث می‌شد جزئیات فنی گم بشه، ایجنت گیج بشه و تسک‌ها رو نصفه رها کنه.

۳. ظهور Harness Engineering:
اینجاست که مفهوم Harness وارد عمل می‌شه. Harness در واقع یک لایه‌ی Orchestration بالای سر کانتکست هست. به جای اینکه ایجنت رو توی کانتکست خودش غرق کنیم، اون رو وارد یک Loop (حلقه) منظم می‌کنیم.

ساختار کار در Harness معمولاً به این شکله:
* ابتدا یک فایل نیازمندی‌های دقیق (PRD) تولید می‌شه.
* این فایل به تسک‌های ریز در قالب JSON شکسته می‌شه.
* ایجنت در هر تکرار (Iteration) از حلقه، فقط روی یک تسک مشخص تمرکز می‌کنه.
* در شروع هر مرحله، ایجنت یک کانتکست کاملاً تازه و تمیز (Fresh Context) دریافت می‌کنه، اما با قوانین (Rules) سخت‌گیرانه‌ای که از قبل براش تعریف شده.

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

نمونه‌های عملی این رویکرد رو می‌شه توی دموی اخیر Anthropic دید. حتی Cursor با معرفی Cloud Agents و قابلیت تعریف Automation برای آپدیت خودکار کدبیس، عملاً داره به سمت Harness Engineering حرکت می‌کنه. در این حالت، شما حتی لازم نیست IDE باز باشه؛ ایجنت توی کلاود طبق تسک‌های تعریف شده کار می‌کنه، کد می‌زنه، تست می‌کنه و در نهایت Pull Request رو براتون می‌فرسته.

در واقع قدرت واقعی ایجنت‌های آینده نه فقط توی مدل قوی‌تر، بلکه توی Harness یا همون زیرساخت مدیریتی هست که ایجنت رو هدایت می‌کنه تا تسک‌های طولانی رو بدون افت کیفیت به پایان برسونه.

🛠 Join @LLMEngineers Community

Boom 💣

اگه میتونستم هر career ای دلم میخواد انتخاب کنم، حوزه مورد علاقم post-train و benchmarks design می بود، هم در سطح research هم پروداکشن
لعنتی خیلی جذابه

مدل Kimi K3 معرفی شد. و توی سایت در دسترسه
kimi.com

کمپانی Moonshot AI تیزر رسمی این مدل رو منتشر کرده و به نظر می‌رسه قراره یکی از جدی‌ترین مدل‌های متن‌باز امسال باشه.
گویا میگن 3T پارامتر داره 1M کانتکس و قدرتش در حد Opus و حتی بالاتره.
هنوز بنچمارک‌ها و جزئیات کامل منتشر نشده، ولی احتمالاً به‌زودی رقابت جذاب‌تری بین مدل‌های متن‌باز و بسته خواهیم دید.

منتظر نتایجش هستم 👀

چیزی که تو معماریش واسم جالب بود بحث Continuous Reasoning Effort هست. جای اینکه مثل بقیه مدل‌ها فقط چند تا مود ثابت واسه ریزونینگ داشته باشه، یه پارامتر بین صفر و یک می‌گیره. من رو ۰.۷ تنظیمش کردم واسه تسک‌های روتین، و فقط وقتی می‌خوام یه کد پیچیده رو دیباگ کنه می‌ذارمش رو ۰.۹۹. اینطوری هم توکن کمتری مصرف می‌شه هم سرعت ریسپانس خیلی بالاتره، چون مدل مجبور نیست رو سوال‌های ساده پردازش الکی انجام بده.

واسه فاین‌تیون کردنش هم داکیومنت‌های پلتفرم Tinker یه سری دیتای خوب داده که به درد پروژه‌های دیگه هم می‌خوره. نوشتن اگه می‌خواید رو این مدل‌های اسپارس MoE لورا بزنید، فقط تارگت کردن لایه‌های اتنشن جواب نمیده. باید وزن‌های LoRA رو روی تمام ماتریکس‌ها، از جمله MLP و خود لایه‌های MoE اعمال کنید. رنک دیفالت رو ۳۲ پیشنهاد دادن و گفتن لرنینگ ریت رو حدود ۱۰ برابر زمانی بذارید که دارید فول‌فاین‌تیون می‌کنید. این ستاپ واسه SFT و حتی RL روی دیتای کاستوم بهترین نتیجه رو داده.

واقعیتش مدلی که من منتظرشم این نسخه ۹۷۵ میلیاردی نیست. تو پیش‌نمایش‌هاشون حرف از Inkling-Small زدن که کلا ۲۷۶ میلیارد پارامتر داره و فقط ۱۲ میلیاردش تو هر توکن اکتیوه. بنچمارک‌هاش تو پردازش صدا و ریکوئست‌های ایجنتیک تقریبا هم‌سطح برادر بزرگترشه ولی هنوز وزن‌هاش رو پابلیک نکردن...

گزارش کامل وضعیت ساپورت نرم‌افزاری و بررسی بنچمارک‌های نسخه کوچیکتر:
https://thinkingmachines.com/inkling-technical-ecosystem

🛠 Join @LLMEngineers Community

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

معماریش یه هیولای ۹۵۲ میلیارد پارامتریه که حدود ۴۱ میلیاردش تو هر توکن اکتیوه. یعنی عملا ۱۶ تا کارت H200. حتی نسخه کوانتایز شده NVFP4 هم ۶۰۰ گیگ مموری می‌خواد. پس عملا اجرای لوکالش واسه ماها قفله و باید از همون سرویس Tinker خودشون یا پرووایدرهای دیگه استفاده بشه.

بچه‌های تیم سازنده‌ش که اکثرا از OpenAI اومدن بیرون، تصمیم جالبی واسه اسکیل کردن گرفتن. برگشتن سمت muP یا همون Maximal Update Parametrization. چند وقت پیش یه پیپر می‌خوندم که نشون می‌داد واسه مدل‌های بالای یک تریلیون پارامتر، این روش چطور پایداری ترینینگ رو تضمین می‌کنه. ۴۵ تریلیون توکن دیتای آموزشی به خورد مدل داده شده که تو فضای اوپن‌‌ها یه عدد عجیبه.

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

🛠 Join @LLMEngineers Community

یه مدل متن باز از thinking machines (فاندرش میرا موراتی cto قبلی openaiعه) به اسم Inkling منتشر شد با قدرت های فوق العاده و معماری مولتی مودال خفن
خیلی حرف برای گفتن داره، خیلی زیاد
فردا دربارش یه پست فنی میزارم

https://huggingface.co/thinkingmachines/Inkling

همیشه دوست داشتم یه مدل به درد بخور رو لوکال بالا بیارم ولی محدودیت VRAM واقعاً روی اعصاب بود (کارت گرافیک RTX 3050 با ۶ گیگابایت حافظه VRAM )
قبلاً حتی فکر کردن به لود کردن Qwen3.6-27B روی چنین سخت‌افزاری شبیه شوخی بود، اما نسخه 1-bit مدل جدید Bonsai 27B که کلاً ۳.۹ گیگابایت فضا می‌گیره رو انداختم توی LM Studio و خیلی راحت روی کارت نشست و حتی مقداری فضا برای کانتکست باقی موند...

بررسی ساختار این مدل نشون میده که چطور به این حجم رسیدن... برخلاف اکثر روش‌های کوانتیزیشن رایج که فقط بخشی از وزن‌ها رو فشرده می‌کنن و بخش‌های حساس مثل embeddings یا attention projections رو دست‌نخورده می‌ذارن، تکنولوژی Bonsai به صورت کاملاً end-to-end تمام لایه‌ها رو فشرده می‌کنه... توی مدل‌های معمولی اگه زیر ۴ بیت بریم مدل کلاً متلاشی می‌شه و رفتارهای منطقی خودش رو از دست میده، اما این پروژه وزن‌ها رو بر پایه یک فریم‌ورک ریاضیاتی دقیق به فرمت‌های فوق فشرده تبدیل کرده... نسخه Ternary این مدل با وزن‌های {-1, 0, +1} و یک اسکیل FP16 به ازای هر ۱۲۸ وزن، کلاً ۱.۷۱ بیت به ازای هر وزن مصرف می‌کنه (حدود ۵.۹ گیگابایت)... نسخه ۱ بیتی هم فقط از وزن‌های {-1, +1} استفاده می‌کنه که حجم نهایی رو به ۱.۱۲۵ بیت یعنی حدود ۳.۹ گیگابایت می‌رسونه... این یعنی عملاً امکان اجرای یک مدل کلاس ۲۷ میلیاردی روی گوشی‌های موبایل با رم محدود هم فراهم شده...

مسئله بعدی که معمولاً اجرای لوکال رو غیرممکن می‌کنه، حجم عظیمی هست که KV cache در کانتکست‌های طولانی اشغال می‌کنه... خوشبختانه معماری پایه Qwen3.6 به صورت hybrid-attention طراحی شده؛ یعنی فقط ۱۶ لایه از ۶۴ لایه اون به صورت full-attention کار می‌کنن و بقیه لایه‌ها ساختار linear-attention دارن که حافظه ثابتی می‌خواد... این باعث می‌شه حجم کش مدل از همان ابتدا ۴ برابر کوچک‌تر از مدل‌های متراکم عادی باشه... علاوه بر این، مدل‌های Bonsai مقاومت عجیبی در برابر کوانتیزیشن ۴ بیتی KV cache دارن... آزمایش‌های forward-KL divergence نشون میده که افت کیفیت ناشی از فشرده‌سازی کش در این مدل بسیار کمتر از مدل‌های عادیه... با فعال کردن کش ۴ بیتی، حافظه مورد نیاز برای کانتکست ۱۰۰ هزار توکنی در نسخه ۱ بیتی به حدود ۶.۸ گیگابایت کاهش پیدا می‌کنه که برای اجرا روی لپ‌تاپ‌های معمولی فوق‌العاده‌ست...

پیاده‌سازی این کار به کرنل‌های کاستوم نیاز داره تا سخت‌افزار بتونه وزن‌های کم‌بیت رو مستقیماً بدون نیاز به expand کردن در حافظه پردازش کنه... توسعه‌دهنده‌ها این مسیرها رو روی MLX برای محصولات اپل و CUDA برای کارت‌های انویدیا آماده کردن... همچنین برای افزایش سرعت تولید توکن، یک لایه درفت اختصاصی به اسم DSpark همراه مدل ارایه شده که به روش speculative-decoding سرعت خروجی رو روی کارت‌های انویدیا تا ۳۷ درصد بیشتر می‌کنه... البته طبق گزارش‌ها، سیستم‌های Apple Silicon در پردازش‌های batch size 1 هنوز امکان استفاده بهینه از DSpark رو ندارن و این ویژگی اونجا فعلاً کارایی خاصی نداره...

ارزیابی‌ها نشان میدن که در حالت تفکر یا همان thinking mode، نسخه ۱ بیتی حدود ۹۰ درصد و نسخه ternary نزدیک ۹۵ درصد از کارایی مدل اصلی رو حفظ می‌کنن... برتری بزرگ Bonsai در حفظ رفتارهای عمیق مثل حل مسائل ریاضی، ساختار زنجیره تفکر و نوشتن کدهای برنامه‌نویسی در لایه‌های زیر ۲ بیته... جایی که کوانتیزیشن‌های معمولی مثل IQ2_XXS کاملاً شکست می‌خورن...

دیدن بنچمارک‌های جدید مدل ۱ بیتی Bonsai 27B واقعاً آدم رو به آینده پردازش لوکال امیدوار می‌کنه... نسخه 1-bit این مدل با حجم ناچیز ۳.۹ گیگابایتی توی تست‌های فوق سخت ریاضی مثل AIME 2025 و بنچمارک کدنویسی LiveCodeBench پایاپای با GPT-5 Low رقابت کرده و حتی با اختلاف جزئی جلو زده... این یعنی منطق محاسباتی سنگین بالاخره راهش رو به دستگاه‌های کوچک و جیبی باز کرده...

جالب‌تر اینکه توی رقابت با مدل معروف GPT-4o، این مدل کم‌حجم برتری خودش رو توی بنچمارک‌های کلیدی مثل MATH-500، ارزیابی‌های ایجنتی τ²-Bench و تست‌های دستوری IFBench ثابت کرده... داشتن چنین سطحی از هوش بدون نیاز به سرورهای ابری و به صورت کاملاً آفلاین، دست ما رو برای ساخت پروژه‌های شخصی و ابزارهای کاربردی بازتر می‌کنه... با اینکه هنوز محدودیت‌هایی داره، اما یک شروع فوق‌العاده برای نسل جدید مدل‌های لوکاله...


https://huggingface.co/prism-ml

🛠 Join @LLMEngineers Community

تشخیص گفتار (ASR) فارسی به‌صورت استریمینگ و On-device تا قبل از این یه حفره بزرگ توی کامیونیتی بود... رضا سیار با انتشار کالکشن Shenava 1.0 عملاً یه زیرساخت سنگین و باکیفیت رو به‌صورت اوپن‌سورس در اختیار همه گذاشته. تمرکز اصلی پروژه روی Latency پایین و اجرای آفلاین روی سخت‌افزارهای ضعیفه که برای توسعه‌دهنده‌های فارسی‌زبان یه ابزار حیاتی محسوب می‌شه.

مدل‌های این مجموعه از نسخه Koochik (۱۱۴ میلیون پارامتر) که نقش Teacher رو داره، تا نسخه فوق‌بهینه Rizeh-Pizeh (۶.۹ میلیون پارامتر) رو شامل می‌شن... مدل Koochik با وجود ابعاد کوچیکش، توی بنچمارک‌های FLEURS-fa و Golden-6669 عملکردی در سطح مدل‌های بسیار بزرگ‌تر نشون داده. این یعنی می‌شه روی بردهای ارزان‌قیمت مثل ESP32-S3 یا اپلیکیشن‌های موبایل قدیمی، پردازش صوت لایو داشت بدون اینکه نیازی به کارت گرافیک‌های گرون‌قیمت یا اینترنت باشه.

معماری پروژه بر پایه FastConformer هست و تمام خروجی‌های استاندارد اینفرنس توسط رضا آماده شده... فایل‌های ONNX fp16، نسخه‌های CoreML برای iOS، فرمت‌های مخصوص Sherpa-ONNX و حتی نسخه Native Rust با استفاده از Tract توی کالکشن موجوده. عملاً تمام مراحل سختِ تبدیل مدل و بهینه‌سازی برای پلتفرم‌های مختلف انجام شده و مدل‌ها آماده استفاده توی Production هستن.

خط لوله داده (Data Pipeline) این پروژه هم به همون اندازه مدل‌ها فنی و دقیقه... حدود ۴ میلیون سطر دیتای صوتی که با تکنیک‌های Active Learning، اصلاح دستی و فیلتر کردن نویزها تمیز شدن. وجود دیتاست‌های اختصاصی مثل Golha برای کلمات ادبی و Ganjoor برای دکلمه، باعث شده مدل توی درک لحن‌های مختلف فارسی منعطف باشه و نرخ خطای کلمات (WER) رو به‌شدت پایین بیاره.

ابزارهای جانبی مثل ShenavaSanj هم برای امتیازدهی به اهمیت کلمات توی جمله ارائه شده که برای محاسبه Semantic WER کاربرد داره... این کالکشن یه نمونه موفق از Knowledge Distillation و مهندسی دیتاست برای زبان‌های کم‌منبع مثل فارسیه که رضا سیار بدون هیچ منتی برای کامیونیتی جمع‌آوری و منتشر کرده.

https://huggingface.co/collections/Reza2kn/shenava-10-open-streaming-persian-asr-and-captioning

🛠 Join @LLMEngineers Community

تا حالا شده بخوای کاش یه ویدیو یا پادکست فارسی، زیرنویس داشت؟👨🏻‍🏫🤓
شنوا، یه برنامه‌ی رایگانه که همه‌ی مکالمه‌های فارسی رو به صورت زنده زیرنویس می‌کنه! 🔥👨‍🍳

این برنامه‌ی نصب روی گوشی های اندروید هست و برای آیفون به سایت شنوا مراجعه کنین 🫡

سایت شنوا (Shenava.app) و من ، رضا سیار در تلگرام و واتسپ صمیمانه پذیرای شما هستیم🤗

شنوا، یه برنامه‌ی رایگانه که همه‌ی مکالمه‌های فارسی رو به صورت زنده زیرنویس می‌کنه! 🔥👨‍🍳

AI Engineers pinned «سلام دوستان عزیز 👋 ما در پروژه Bina OCR در حال جمع‌آوری یک دیتاست بزرگ و متنوع برای آموزش و فاین‌تیون مدل OCR فارسی (تشخیص هوشمند متن) هستیم. هرچه داده بیشتر و واقعی‌تر داشته باشیم، مدل دقیق‌تر و کاربردی‌تر خواهد شد! اگر داده‌های زیر را دارید، خیلی ممنون…»

سلام دوستان عزیز 👋

ما در پروژه Bina OCR در حال جمع‌آوری یک دیتاست بزرگ و متنوع برای آموزش و فاین‌تیون مدل OCR فارسی (تشخیص هوشمند متن) هستیم. هرچه داده بیشتر و واقعی‌تر داشته باشیم، مدل دقیق‌تر و کاربردی‌تر خواهد شد!

اگر داده‌های زیر را دارید، خیلی ممنون می‌شیم کمک کنید:

۱. داده‌های دست‌خط (Handwritten):
• جزوه‌ها، یادداشت‌ها و نامه‌های دست‌نویس
• فرم‌های پرشده (اداری، بانکی، پزشکی، ثبت‌نام و ...)
• متن روی کاغذ، تخته، یا عکس گوشی
هرچی از دست خط خودتون باشه به نفعتونه چون این مدل دستخط شمارو بهتر تشخیص خواهد داد :))

→ ارسال به تاپیک: Data: Handwritten

۲. داده‌های تایپ‌شده / چاپی (Typed/Printed):
• اسناد رسمی، قراردادها، فاکتورها، قبوض
• صفحات کتاب، مجله، روزنامه
• گزارش‌ها، نامه‌های رسمی، اسکرین‌شات اپ و وب

→ ارسال به تاپیک: Data: Typed

نکته مهم: حتی چند عکس هم خیلی ارزشمند است! عکس‌های با کیفیت مختلف (تاریک، روشن، زاویه‌دار، نویزدار) عالی هستند چون مدل باید در دنیای واقعی کار کند.

برنامه‌نویس‌ها و متخصصان: برای مشارکت فنی (دیتاست، مدل، کد) به گروه اصلی بپیوندید:
👉 https://telegram.me/bina_ocr

ممنون از لطف و مشارکت ارزشمند شما 🙏
این پروژه کاملاً متن‌باز است و مدل نهایی روی Hugging Face منتشر خواهد شد.