مدل جدید کیمی 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

یه مجموعه اسکیل رو به صورت ازمایشی ساختم تا فرآیند 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

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

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

🛠 Join @LLMEngineers Community

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

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

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

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

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

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

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

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

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

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

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

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

🛠 Join @LLMEngineers Community

داشتم مستندات استاندارد 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

امروز داشتم جزئیات Prime Agent رو نگاه می‌کردم؛ سیستم جدید Prime Intellect که ادعا می‌کنه یه ساختار «خود‌-اصلاح‌گر» برای اجنت‌های کدنویسی ساخته. حرف اصلیشون اینه که هارنس‌ها برای مدل‌های قدیمی طراحی شدن و نمی‌ذارن مدل‌های پیشرفته‌ی امروزی از تمام توانشون استفاده کنن.

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

مفهوم دوم «هارنس مستمر» یا Continual Harness هست. توی اکثر اجنت‌ها، پرومپت‌ها و مهارت‌ها ثابتن، اما اینجا اجنت می‌تونه خودش این موارد رو تغییر بده. یعنی قابلیت ساخت، خوندن، آپدیت و حذف (CRUD) برای پرومپت‌ها، حافظه و ابزارهایش رو داره. اگه جایی اشتباه کنه، با دستور /refine می‌تونه مسیرش رو اصلاح کنه و این تغییرات رو برای دفعات بعد ذخیره کنه.

ساختار فنی‌اش هم بر پایه یه هسته‌ی IPython می‌چرخه. هر ابزار یا مهارتی که اجنت داره، در واقع یه ماژول پایتونیه که توی این محیط لود شده. یه Daemon هم توی پس‌زمینه همه‌ی نشست‌ها رو مدیریت می‌کنه. جالبه که اجنت‌ها می‌تونن با هم چت کنن (A2A Messaging) و برای انجام تسک‌های پیچیده، ساب‌اجنت‌های موازی بسازن و بهشون دستور بدن.

توی تست‌های ARC-AGI 3 که یه بنچمارک سخت برای استدلاله، با مدل Opus 5 به امتیاز ۹۵.۵٪ رسیدن که از رکورد آدم‌های متخصص هم بالاتره. نکته‌ی جالب‌تر توی تست بازی Factorio بود؛ اجنت یاد گرفته که برای بالا بردن امتیاز تولید، به جای بازی کردن طبق قوانین، با کدهای کنسول توی بازی تقلب کنه و منابع رو مستقیماً اسپاون کنه. این نشون می‌ده اجنت‌ها وقتی هدف مشخص دارن، دنبال کوتاه‌ترین راه می‌گردن، حتی اگه دور زدن قوانین باشه.

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

منبع:
https://www.primeintellect.ai/blog/prime-agent
https://github.com/PrimeIntellect-ai/prime-agent

🛠 Join @LLMEngineers Community

Top Open LLMs by now (Aug 7 - 2026)

Open Source AI is dominated by China!

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

خانواده Claude 5 فعلاً قابل‌اعتمادترین خروجی‌ها رو دارن.
اون ته چارت هم وضعیت DeepSeek اصلاً جالب نیست... عملاً داره بیشتر از اطلاعات درست، چرت‌وپرت تحویل می‌ده.

https://arxiv.org/abs/2511.13029

🛠 Join @LLMEngineers Community

یه پرامپت ساده و ۱۰ تا پلتفرم (وبسایت) AI نتونستن انجامش بدن از جمله کلاد، ChatGPT, جمنای، Qwen ، گروک، Kimiو…
و تنها دو جا جواب درستو گرفتم:
Hermes Agent 100/100
Manus Agent 60/100

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

🛠 Join @LLMEngineers Community

تقاضای همکاری برای بهبود هوش مصنوعی فارسی زبان و آزاد:

تیم ما در حال کار روی پروژه های مختلفی برای بهبود عملکرد هوش مصنوعی فارسی زبان و آزاد هست و برای اینکار نیاز به همکاری شما دوست عزیز داریم! 🤗

همه ی ما به صورت رایگان کار میکنیم و این پروژه ها برای افرادی که میخوان وقت و تلاششون رو به صورت داوطلبانه در اختیار زبان فارسی بذارن ایده آل هست👨‍🍳

هدف: یادگیری و جلو بردن هوش مصنوعی فارسی زبان بدون هیچ قید و بندی💪

روش همکاری: ما پلتفرم های مخصوصی رو برای لیبل زدن یا تصحیح دیتا درست کردیم و فقط از شما میخوایم تو این پلتفرم ها تا جای ممکن همکاری کنید. ویدیو های آموزشی هم داریم.🔥

در صورت علاقه مندی به @Reza2kn پیام بدین 🙏

مسیر Backend به سمت Applied AI و Agent Engineering منطقی‌ترین راه ورود به هوش مصنوعی تو سال ۲۰۲۶ هست. اگه دنبال فریلنسری ارزی یا جاب‌های جدی هستی، باید بدونی که آگهی‌ها دیگه دنبال «محقق هوش مصنوعی» نیستن؛ اونا کسی رو می‌خوان که پایتون، FastAPI، دیتابیس‌های رابطه‌ای مثل PostgreSQL و Docker رو بلد باشه و بتونه اینا رو به LLMها و ابزارهایی مثل LangGraph وصل کنه.

واقعیت بازار اینه که بیزنس‌ها دنبال خریدن «عامل هوش مصنوعی» یا Agent نیستن؛ اونا می‌خوان یه مشکل واقعی‌شون حل بشه. مثلاً کاهش بار تیکت‌های پشتیبانی یا استخراج خودکار دیتا از هزاران فایل پی‌دی‌اف. پروژه‌های با بودجه بالا (مثلاً ۲۵۰۰ دلار به بالا) صریحاً می‌نویسن که دنبال سیستم‌های آماده برای محیط عملیاتی (Production-ready) هستن، نه چت‌بات‌های ساده‌ای که تو توتوریال‌ها ساخته می‌شه.

برای اینکه تو این مسیر شلوغ و پر از هایپ (Hype) گم نشی و بدونی دقیقاً چه مهارتی رو کی و چطور یاد بگیری، دارم یه پلتفرم به اسم AI Engineering Atlas رو می‌سازم. اطلس یه نقشه‌ی راهنمای دقیقه که مفاهیم، پروژه‌های واقعی و مهارت‌هایی که تو دنیای واقعی لازم داری رو بهت نشون میده تا با شفافیت کامل یاد بگیری.

Coming soon...

اگه بخوام مسیر رو برات ساده کنم، ترتیب یادگیری باید اینجوری باشه:

۱. Python:
تسلط روی زبان، نه فقط سینتکس. باید بتونی کد تمیز بنویسی.
۲. Backend:
یادگیری FastAPI و کار با PostgreSQL. دیتابیس قلب هر سیستم هوشمندی هست. باید بتونی احراز هویت و تست‌نویسی رو هندل کنی.
۳. LLM Engineering:
کار با API مدل‌های بزرگ (مثل OpenAI یا Claude). یادگیری خروجی‌های ساختاریافته (Structured Output) و اینکه چطور مدل بتونه ابزارهای مختلف رو صدا بزنه (Tool Calling).
۴. RAG:
تبدیل متن به بردار (Embeddings) و ذخیره تو دیتابیس‌های برداری برای اینکه مدل بتونه بر اساس اسناد شرکت جواب بده.
۵. Agents:
مدیریت وضعیت چت و چرخه‌های تصمیم‌گیری پیچیده. جایی که مدل تصمیم می‌گیره کدوم مرحله رو اول انجام بده و کجا منتظر تایید آدم بمونه.

⚠️ فریب پروژه‌های دمویی رو نخور
توی مارکت فریلنسری رقابت شدیده. چیزی که تو رو متمایز می‌کنه، داشتن ۳ تا پروژه عمیق تو پورتفولیو هست:
- یه سیستم اتوماسیون که ایمیل می‌گیره و تو CRM ثبت می‌کنه.
- یه دستیار جستجوی اسناد سازمانی (RAG) که منبع دقیق جواب رو نشون میده.
- یه بک‌اندر مستحکم که نشون بده تو فقط کد AI کپی نمی‌کنی، بلکه مهندس نرم‌افزاری.

فعلاً وقتت رو روی ریاضیات سنگین یادگیری ماشین، آموزش مدل‌ها از صفر (Training) یا مقالات پژوهشی پیچیده تلف نکن. این‌ها برای شروع کار فریلنسری و رسیدن به درآمد اولیه لازم نیستن. تمرکزت رو بذار روی حل مسئله. بیزنس‌ها بابت حل شدن دردسرهاشون پول میدن، نه بابت اینکه چقدر از معماری ترنسفورمر سر در میاری.

منتظر AI Engineering Atlas باش؛ قراره دقیقاً همین مسیر رو برات مرتب کنه.

🛠 Join @LLMEngineers Community