استفاده از مدل‌های آفلاین AI برای توسعه نرم‌افزار

از اینکه این مطلب رو نه الزاما به عنوان یک موضوع مهندسی، بلکه با در نظر گرفتن شرایط تحمیلی این روزهای اینترنت ایران؛ و تفکر مخرب اینترنت طبقاتی دارم می‌نویسم؛ حس بدی دارم!

اپیزود اخیر پادکست Merge Conflict، در مورد موضوع جالبیه که که شاید توی شرایط فعلی اینترنت ایران، مرورش بد نباشه. استفاده از مدل‌های مختلف AI داخل VS Code و GitHub Copilot، ولی از طریق BYOK (یا Bring Your Own Key).

یعنی به جای اینکه فقط از مدل‌های پیش‌فرض Copilot، Claude Code، Cursor یا ابزارهای مشابه استفاده بشه، بتونیم کلید API خودمون را از OpenAI، Anthropic، Azure Foundry، OpenRouter یا حتی سرویس‌های دیگه که خودمون هاست کردیم بگیریم. بدون وابستگی به اینترنت. بدون مصرف اعتبار Copilot. مثلا Qwen با حدود ۲۷ میلیارد پارامتر، با quantization چهار بیتی، روی یک GPU با ۲۴ گیگابایت VRAM اجرا میشه. و تجربه گوینده توی خیلی از کارهای روزمره کدنویسی، تشخیص تفاوت بین این مدل‌های کوچیک و لوکال از مدل‌های بزرگی مثل Opus یا Sonnet رو سخت کرده!

نکته اول اینکه شاید ما بیش از حد روی «اسم مدل» حساس شدیم. یا اولویت مدل رو به فرایند برتری دادیم.
به جای اینکه بپرسیم Claude بهتره یا GPT؟ Sonnet بهتره یا Opus؟ شاید سوال مهم‌تر این باشه که آیا workflow ما درست طراحی شده یا نه؟ این چالش فقط برای دلداری دادن برای استفاده از مدل آفلاین نیست؛ خیلی شرکت‌ها و تیم‌ها چالش هزینه مصرف توکن رو دارن (و مثلا مایکروسافت اشتراک Claude code نیروهاش رو داره قطع می‌کنه) یا تجربه شخصی خودم: اعدادی که هر ماه از میزان مصرف توکن و هزینه‌ی AI تیمم می‌گیرم؛ باعث شد بفهمم خیلی از برنامه‌نویس‌ها ولو اینکه توی حوزه خودشون که اتفاقا AI هم هست، تخصص عمیق و تجربه طولانی دارن؛ الزاما LLM رو به خوبی نمی‌شناسن و ۵ رکن Harness و Model و Context و Tools و Prompts رو درک نکردند. برای همین مصرف توکنشون و هزینه‌شون خیلی بالاست؛ و مثلا برای تولید توضیحات PR هم از مدل‌های بزرگ و گرون مثل Opus 4.7 و GPT 5.5 و... استفاده می‌کنن!! اگر دوست داشتید می‌تونیم روی این موضوع عمیق‌تر صحبت کنیم بعدن.

ولی به صورت کلی؛ اگه context رو خوب بسازیم؛ فایل‌های درست رو در اختیار agent بگذاریم، planning داشته باشیم، task رو خوب خرد کنیم و خروجی رو مرحله به مرحله review کنیم، شاید تفاوت مدل‌ها توی خیلی از سناریوهای روزمره کمتر از چیزی باشه که تصور می‌کنیم.

دوم اینکه agent فقط مدل نیست. و چیزی که ما توی VS Code، Copilot، Claude Code یا Cursor یا گراک‌بیلد تجربه می‌کنیم، فقط یه LLM خام نیست. پشتش کلی system prompt، ابزار خوندن و ویرایش فایل، حافظه، planning mode، sub-agent، permissions و کلی glue code دیگه وجود داره. به همین دلیل دو ابزار مختلف با یک مدل یکسان، لزوما تجربه یکسانی نمی‌دن.

مدل مهمه؛ اما harness یا همون محیطی که مدل رو تبدیل به یه دستیار کدنویسی واقعی می‌کنه هم به همون اندازه مهمه و باید خوب یادش بگیریم. باز به تجربه خودم برگردم که چند ماه پیش متوجه شدم که بعضی از بچه‌های تیم؛ در مورد امکان و شیوه دیباگ کردن مدل AI و ایجنت‌هاش بی‌اطلاعن؛ این یعنی همون‌طور که ما در رابطه با یک IDE جدید، زیر و بم امکانات، میانبرها و ابزارهای دیباگ کردنش رو یاد می‌گیریم؛ باید کارکرد و اجزاء ابزارهایی مثل کوپایلوت و کلادکد و... رو هم عمیق و اصولی یاد بگیریم و مثل چت تلگرام ازشون استفاده نکنیم.

و اینکه هنوز محدودیت‌ها جدی‌ان. همه یک RTX 3090 یا 4090 ندارن (البته وقتی وضع اینترنت اینه شاید شرکت‌ها بتونن بهش فکر کنن؛ من سعی کردم ببینم الان قیمت ریالی این کارت‌ها چنده؛ ولی به طور شرم‌آوری هر سایت داخلی که توی صفحه اول گوگل اومد، در دسترس نبود!!).

نهایتا این مطلب هم برای استفاده از مدل‌های لوکال و Copilot CLI شاید مفید باشه.

امیدوارم چنین راهکارهایی از سر انتخاب و ترجیح انجام باشه به جای اجبار و ناچاری.
خوشحال می‌شم نظر یا تجربه شما رو هم بدونم 😊

بعضی آدم‌ها مثل Andrej Karpathy اسمشون فقط یک رزومه نیست؛ بلکه سیگناله!

کسی که رهبری بخش AI و Autopilot Vision تسلا رو بر عهده داشت، عضو اولیه OpenAI بوده، و البته از چهره‌های مهم آموزش Deep Learning بوده هزاران نفر بخشی از سواد AIشون رو از محتوای آموزشی ایشون دارن.

حالا ایشون رفته Anthropic؛ و می‌دونیم که احتمالا امسال آنتروپیک در مسیر IPO شدن و عرضه عمومی سهام است. و ماموریتش pre-training مدل‌های Claude است.
بعد از خبر پیوستنش به آنتروپیک، بعضی‌ها نوشتند که حضور Karpathy به تنهایی ده‌ها میلیارد دلار به ارزش‌گذاری Anthropic اضافه کرده. (عدد دقیقش رو باید با احتیاط دید؛ چون سوشال‌مدیا اغراق دوست داره)
چیزی که همیشه برام جذاب بوده اینه که حضور یه آدم، همیشه پر کردن یک position نیست. گاهی مولفه اثرگذار روی سرنوشت محصول یا شرکته. گاهی یه signal مهم به بازار. گاهی سیگنال به استعدادهای اون حوزه. گاهی سیگنال به سرمایه‌گذارها. و گاهی حتی یه سیگنال به رقباست.

به نظرم هر از گاهی خوبه تا از خودمون بپرسیم:

«روی زمین، و نه پای منقل و سماور، من واقعاً چقدر برای سازمانم ارزش می‌سازم؟»

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

بلکه توی توان حل مسئله، کاهش ریسک، ساختن سیستم، تربیت آدم‌های بهتر، و بالا بردن کیفیت تصمیم‌های سازمان.

همه قرار نیست Karpathy باشیم. ولی همه می‌تونیم از خودمون بپرسیم: حضور من چه چیزی رو با چه میزان ارزشی واقعا بهتر می‌کنه؟

بهینه‌سازی خودکارِ مهارت‌ها، SkillOpt

چند سال پیش یکی از مهم‌ترین دغدغه‌های استفاده از AI این سوال‌ها بود: «کدوم مدل رو استفاده کنیم؟» یا «چجوری پرامپت بهتری بنویسیم؟»
حالا سوال مهم‌تر اینه: «این مدل با چه skillهایی کار می‌کنه، و کی کیفیتشون رو تضمین می‌کنه؟»

خروجی یه پروژه‌ی تحقیقاتی مشترک Microsoft و چند دانشگاه چینی شده SkillOpt که این هفته به‌صورت کدباز منتشر شد. ایده‌اش ساده‌ست: به جای fine-tune کردن مدل، فایل skill رو train کن.

یعنی یه فایل Markdown به عنوان trainable parameter یه agent frozen در نظر گرفته می‌شه. و optimizer، مسیر حل مسئله رو تحلیل می‌کنه، تغییرات ساختارمند پیشنهاد می‌ده، و فقط اگه روی مرحله ارزیابی، بهتر شده بود، تغییرات رو قبول می‌کنه.

خروجی نهایی؟ یه best_skill.md بین ۳۰۰ تا ۲۰۰۰ توکن. بدون تغییر وزن مدل، بدون overhead در inference. نتایج تجربی‌شون روی ۵۲ از ۵۲ سلول ارزیابی بهترین یا مساوی بهترین بوده. روی GPT-5.5 به‌طور میانگین +۲۳.۵ امتیاز نسبت به حالت بدون skill.

اما به نظرم مهم‌تر از خود ابزار، پیامشه:
اسکیل خوب می‌تونه خروجی یه مدل معمولی رو خیلی بهتر کنه. اسکیل بد می‌تونه خروجی یه مدل قوی رو خراب کنه. و اسکیل بدون validation و lifecycle، دیر یا زود تبدیل می‌شه به همون بدهی فنی قدیمی، فقط این بار در لباس AI.

اگه ۲۰ دقیقه وقت دارید و می‌خواید بدونید این چرخه بهینه‌سازی، چجوری کار می‌کنه، چه فرقی با prompt tuning معمولی داره، و چرا governance روی اسکیل‌ها برای تیم‌های انترپرایز جدیه، نسخه‌ی مفصل‌تر رو روی بلاگ بخونید.

🔗لینک مطلب کامل روی بلاگ خودم

وقتی ابزار بودن AI Agent تبدیل به «باور» می‌شه!

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

دو نمونه برای مثال یا سرنخ:
🔐 انتشار NVIDIA SkillSpector: یه security scanner برای AI agent skills. بر اساس کار تحقیقی روی ۴۲ هزار skill واقعی که نشون داده ۲۶٪ شون آسیب‌پذیری دارن و ۵٪ هم احتمالاً مخرب هستن! SkillSpector تا الا ۶۴ تا الگوی مشخص رو اسکن می‌کنه: از prompt injection و data exfiltration گرفته تا privilege escalation، memory poisoning، و MCP tool poisoning.

⚖️ انتشار Microsoft Agent Governance Toolkit: که یه لایه governance برای دپلوی کردن ایجنت‌ها در محیط عملیاتیه. سه سوال اصلی رو هدف می‌گیره: این action مجاز هست؟ کدوم ایجنت این کار رو کرد؟ می‌تونی ثابت کنی چه اتفاقی افتاد؟ از policy enforcement با YAML/OPA/Cedar گرفته تا identity با SPIFFE و audit log با Merkle chain. حتی cost و token budget هم داخلش هست.

اما این همه ماجرا نیست. وقتی agent ها از اسباب‌بازی به ابزار کاری تبدیل می‌شن، یه لایه کامل از مشکلات ظاهر می‌شه که قبلاً وجود نداشت:
- چه کسی هزینه inference رو می‌پردازه و چطور باید ردیابیش کرد؟
- اگر agent ای یه تصمیم اشتباه گرفت و خسارت زد، مسئ‌ولیت با کیه؟
- چطور ثابت می‌کنی که ایجنت در لحظه‌ی تصمیم، دقیقاً با همون policy که تأیید شده بود کار می‌کرد؟
- وقتی ده‌ها ایجنت به هم وکالت می‌دن (delegation chain)، اعتماد بینشون چجوری منتقل می‌شه؟

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

سوال: ایا این موضوعات جایی بین دغدغه‌های سازمان و تیم شما داره؟