مهندس هوش مصنوعی شدن فقط بلد بودن مدل ها نیست

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

در نمونه آگهی های آمریکا که در این مقاله بررسی شده، کارفرما ها مهارت مدل را کنار ابر، نرم افزار، ارزیابی و عملیات می خواهند. پس پرسش فقط این نیست که «مدل چه می تواند بکند؟»؛ باید نشان دهید کل سامانه در استفاده روزمره چگونه کار می کند.

در یک نمونه ی پاک سازی شده از ۲۱ نقش متمایز مهندس هوش مصنوعی در آمریکا، از ۱۶ کارفرما، مهارت های مرتبط با ابر در ۸۵٫۷٪ نقش ها آمده بود. پایتون در ۷۶٫۲٪، مدل های زبانی بزرگ در ۷۱٫۴٪، ایجنت های هوش مصنوعی در ۶۱٫۹٪ و RAG در ۴۲٫۹٪.

پس پاسخ عملی این است:

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

در این یادداشت توضیح می دهم این یعنی چه، کارفرمایان دقیقاً چه می خواهند و قدم بعدی شما چه باید باشد.

چه چیزی مهندس هوش مصنوعی را از سازنده ی دمو جدا می کند؟

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

کار روزانه ی مهندس هوش مصنوعی چیست؟

مهندس هوش مصنوعی محصولات و سامانه های نرم افزاری می سازد که از هوش مصنوعی استفاده می کنند.

این کار ممکن است شامل این ها باشد:

• یکپارچه سازی مدل های زبانی بزرگ با برنامه ها؛
• ساخت سامانه های RAG که دانش سازمان را بازیابی می کنند؛
• ساخت ایجنت هایی که از ابزار استفاده می کنند یا گردش کاری را کامل می کنند؛
• ارائه ی قابلیت های هوش مصنوعی از طریق API؛
• استقرار مدل ها و برنامه ها در محیط های ابری؛
• ارزیابی کیفیت پاسخ ها و رفتار سامانه؛
• پایش تأخیر، قابلیت اطمینان و هزینه؛
• افزودن کنترل های امنیتی، سازوکار های محافظتی و مراحل تأیید؛
• اتصال سامانه های هوش مصنوعی به پایگاه های داده، نرم افزار های کسب وکار و سرویس های بیرونی.

این نقش جایی میان مهندسی نرم افزار، یادگیری ماشین، مهندسی داده و مهندسی ابر قرار دارد.

وزن هر کدام از شرکتی به شرکت دیگر فرق می کند.

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

اولین چیزی که به کسانی می گویم که از من می پرسند چطور برای مشاغل مهندسی هوش مصنوعی آماده شوند، این است:

فقط برای عنوان شغلی آماده نشوید. برای نوع کاری در مهندسی هوش مصنوعی آماده شوید که می خواهید انجام دهید.

آگهی های بررسی شده چه مهارت هایی می خواهند؟

داده های اولیه شامل ۶۳ آگهی فعال در آمریکا بود که در دسته ی مهندس هوش مصنوعی قرار گرفته بودند. اما چند آگهی در واقع یک نقش واحد بودند که جداگانه برای شهر های مختلف منتشر شده بودند.

پس از حذف تکراری های آشکارِ مربوط به محل، یک آگهی آزمایشیِ داخلی و یک مورد ناسازگاری جغرافیایی، ۲۱ نقش متمایز از ۱۶ کارفرما باقی ماند.

پرتکرارترین توانایی ها این ها بودند:

این اعداد همین مجموعه داده ی گزینشی را توصیف می کنند و نباید آن ها را اندازه گیری کاملِ کل بازار کار آمریکا دانست. شمارش های تجمیعی به صورت فایل CSV هم در دسترس است.

پنج آگهی بررسی شده که این الگو را نشان می دهند

این آگهی ها وقتی در ۲۵ ژوئیه ی ۲۰۲۶ بررسی شان کردم فعال بودند. صفحه های شغلی ممکن است بسته یا جابه جا شوند، برای همین برای هر کدام کارفرما، نقش، محل، توانایی های خواسته شده و نکته ای را که آگهی پشتیبانی می کند ثبت کرده ام.

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

پایتون لازم است، اما کافی نیست

نه. اما پایتون هنوز بهترین زبان برای شروع است.

پایتون در ۱۶ نقش از ۲۱ نقش آمده بود. این زبان همچنان رایج ترین زبان در توسعه ی برنامه های هوش مصنوعی، یادگیری ماشین، RAG، چارچوب های ایجنت، ابزار های ارزیابی، پردازش داده و APIهای مدل است.

اما کارفرمایان به ندرت پایتون را به تنهایی می خواستند.

آن ها کسی را می خواستند که بتواند با پایتون:

• API بسازد؛
• به پایگاه داده وصل شود؛
• داده را پردازش کند؛
• سرویس های بیرونی را یکپارچه کند؛
• آزمون بنویسد؛
• خطا ها را مدیریت کند؛
• برنامه را بسته بندی کند؛
• سرویس را مستقر کند؛
• سامانه های عملیاتی را پایش کند.

بعضی شرکت ها هم انتظار داشتند مهندس با فناوری های موجود سازمان مثل جاوا، Go، C++، C#، ‎.NET، جاوااسکریپت یا TypeScript کار کند.

یک نقش هوش مصنوعی ایجنتیک را با بک اند C# و ‎.NET، SQL Server، Docker و Jenkins ترکیب می کرد. نقش دیگری برای یک موقعیت ارشد پلتفرم هوش مصنوعی، پایتون، Go، Scala یا جاوا را می پذیرفت. یک نقش بسیار ارشد هم پایتون به علاوه ی یک زبان عملیاتی دیگر می خواست.

توصیه ی من ساده است:

پایتون را فقط به عنوان زبانی برای نوت بوک یاد نگیرید. آن را به عنوان زبانی برای ساختن و اداره کردن نرم افزار یاد بگیرید.

باید در ساختن ماژول، API، آزمون، اتصال به پایگاه داده، کار های پس زمینه، فایل های پیکربندی، ثبت رویداد و منطق مدیریت خطا راحت باشید. دوره ی رایگان پایتون پایه ی زبان را می سازد و درس اولین API با FastAPI نشان می دهد چطور همان دانش پایتون به یک سرویس کارا تبدیل می شود.

چرا باید بتوانید برنامه را در ابر اجرا کنید؟

بله. در این نمونه، مهارت های مرتبط با ابر از هر مدل، چارچوب یا تکنیک خاص هوش مصنوعی پرتکرارتر بودند.

دست کم یک توانایی مرتبط با ابر در ۱۸ نقش از ۲۱ نقش آمده بود.

AWS پرتکرارترین پلتفرم بود و بعد از آن Google Cloud و Azure. کارفرمایان به سرویس ها و محیط هایی مثل این ها هم اشاره کرده بودند:

• AWS Bedrock؛
• Google Vertex AI؛
• Azure OpenAI؛
• SageMaker؛
• Kubernetes؛
• Docker؛
• APIهای میزبانی شده در ابر؛
• ابر خصوصی؛
• زیرساخت GPU؛
• ذخیره سازی مدیریت شده؛
• سامانه های پایش و ثبت رویداد.

این به آن معنا نیست که باید در هر سه ارائه دهنده ی بزرگ ابری متخصص باشید.

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

برای مثال، باید بدانید چطور:

• یک API را مستقر کنید؛
• اطلاعات محرمانه را امن نگه دارید؛
• به پایگاه داده وصل شوید؛
• ثبت رویداد و پایش پایه ایجاد کنید؛
• برنامه را با Docker بسته بندی کنید؛
• دسترسی ها و هویت را بفهمید؛
• هزینه ی پایه ی اجرا را برآورد کنید؛
• برنامه را به روز کنید یا به نسخه ی قبل برگردانید.

دوره ی Docker و Kubernetes قدم بعدی مفیدی است، چون از نوت بوک محلی فراتر می رود و به کانتینر های تکرارپذیر، پیکربندی، ذخیره سازی و استقرار می رسد.

در سطوح پیشرفته تر بازار، دانش ابری می تواند به مهندسی زیرساخت تبدیل شود.

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

برای اولین برنامه ی هوش مصنوعی تان به این عمق نیاز ندارید. اما نشان می دهد عنوان «مهندس هوش مصنوعی» چقدر گسترده شده است.

آگهی ها از ایجنت چه انتظاری دارند؟

بله، دست کم در این نمونه.

مهارت های مربوط به ایجنت در ۱۳ نقش از ۲۱ نقش، یعنی ۶۱٫۹٪، آمده بود.

نکته ی مهم این است که کارفرمایان فقط چت بات های خودمختار ساده نمی خواستند.

آن ها به توانایی هایی مثل این ها اشاره کرده بودند:

• فراخوانی ابزار؛
• هماهنگ سازی چندایجنتی؛
• ماشین حالت؛
• گراف اجرا؛
• خروجی ساختاریافته؛
• تأیید انسانی؛
• حافظه ی ایجنت؛
• تلاش دوباره و رفتار جایگزین؛
• ثبت رخداد ها برای ممیزی؛
• اجرای امن ابزار؛
• Model Context Protocol؛
• ارتباط ایجنت با ایجنت.

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

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

نقش سرپرست هشت سال سابقه ی توسعه ی نرم افزار و تجربه ی بردن سامانه های مبتنی بر مدل زبانی به محیط عملیاتی را انتظار داشت. LangGraph، CrewAI، AutoGen و پروتکل های MCP و A2A هم در آن آمده بود.

این تفاوت مهم است.

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

• ایجنت اجازه ی انجام چه کار هایی را دارد؛
• به چه داده هایی دسترسی دارد؛
• چه زمانی یک انسان باید اقدامی را تأیید کند؛
• یک اقدام چطور قابل بازگشت است؛
• خطا ها چطور مدیریت می شوند؛
• سامانه چطور ارزیابی می شود؛
• سازمان چطور رفتار آن را ممیزی می کند.

این ها تصمیم های مهندسی اند.

برای این که مهندسیِ پشت کلمه ی ایجنت را ببینید، با درس حلقه ی ایجنت شروع کنید. بعد آموزش حلقه ی امن ایجنت در پایتون را بسازید که به جای فرض این که ایجنت همیشه درست رفتار می کند، محدودیت، اعتبارسنجی و ردگیری اضافه می کند.

RAG را با ارزیابی یاد بگیرید، نه فقط با دمو

بله.

RAG در ۹ نقش از ۲۱ نقش، یعنی ۴۲٫۹٪، آمده بود.

اما سطح انتظار دارد تغییر می کند.

یک آموزش مقدماتی RAG ممکن است نشان دهد چطور اسناد را تکه تکه کنید، embedding بسازید، آن ها را در پایگاه داده ی برداری ذخیره کنید، چند بخش را بازیابی کنید و به مدل زبانی بفرستید.

این برای یادگرفتن معماری مفید است. درس ساخت خط پردازش RAG همین پایه را فراهم می کند.

اما کارفرمایان بیش از پیش از این ها حرف می زنند:

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

یک نقش در BeaconFire مسئولیت سرتاسری ورود داده، بازیابی، هماهنگ سازی ایجنت، ارزیابی، استقرار، API، پایش، امنیت و بهینه سازی هزینه را توصیف می کرد.

پس RAG هنوز ارزش یادگرفتن دارد، اما پروژه ی نمونه کار شما باید از وصل کردن یک پایگاه داده ی برداری به یک مدل زبانی فراتر برود.

یک پروژه ی قوی تر توضیح می دهد:

• چرا اسناد به این شکل تکه بندی شده اند؛
• کیفیت بازیابی چطور اندازه گیری می شود؛
• شواهد نامرتبط چطور کنار گذاشته می شوند؛
• دسترسی ها چطور مدیریت می شوند؛
• پاسخ ها چطور ارزیابی می شوند؛
• وقتی بازیابی شکست می خورد، سامانه چه رفتاری دارد.

دو آموزش عملی قدم بعدی را برمی دارند: مقایسه ی اندازه ی تکه ها با آزمون بازیابی و ارزیابی پاسخ های RAG بدون داور مدل زبانی. این دو با هم جمله ی «من RAG ساختم» را به شاهدی تبدیل می کنند که بازیابی و پاسخ ها آزموده شده اند.

چه مقدار یادگیری ماشین لازم است؟

بستگی به نقش دارد.

مهارت های سنتی یادگیری ماشین در آگهی های کمتری نسبت به پایتون، ابر، مدل های زبانی، ایجنت ها یا RAG صراحتاً آمده بودند.

این به معنای بی اهمیت بودن یادگیری ماشین نیست. یعنی عنوان مهندس هوش مصنوعی حالا چند نوع کار را در بر می گیرد.

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

برای مثال، GE HealthCare تجربه با مدل های پایه، یادگیری انتقالی، بهینه سازی، ارزیابی مدل، PyTorch، سامانه های توزیع شده ی هوش مصنوعی، میزبانی مدل و استنتاج عملیاتی می خواست.

برای نقش های کاربردی، شاید لازم نباشد همه ی الگوریتم های یادگیری ماشین را از نظر ریاضی اثبات کنید. اما باید این مفاهیم را بفهمید:

• تفاوت آموزش و استنتاج؛
• بیش برازش؛
• داده ی اعتبارسنجی؛
• ارزیابی مدل؛
• embedding؛
• شباهت؛
• طبقه بندی؛
• رتبه بندی؛
• دقت و فراخوانی؛
• رانش مدل؛
• آزمایش گری پایه.

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

وقتی دمو کار کرد، کیفیت را چطور ثابت می کنید؟

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

اما کارفرمایان بیش از پیش به این علاقه دارند که بعد از آن چه اتفاقی می افتد.

چند نقش در این داده ها از این موارد حرف می زدند:

• ارزیابی کیفیت پاسخ؛
• شاخص های بازیابی؛
• آزمون توهم؛
• آزمون استحکام؛
• شاخص های اعتماد؛
• استقرار سایه؛
• بازخورد انسانی؛
• پایش؛
• مشاهده پذیری؛
• تأخیر؛
• هزینه؛
• قابلیت ممیزی.

Capital One ارزیابی مدل، آزمایش گری، حاکمیت، سازوکار های محافظتی و مشاهده پذیری را جزو مسئولیت های یک نقش ارشد پلتفرم هوش مصنوعی آورده بود.

Palo Alto Networks ابزار های ارزیابی ای می خواست که دقت، تأخیر و هزینه را اندازه بگیرند.

TCP رفتار جایگزینِ قطعی، امتیاز اطمینان، محدودیت زمانی، پنجره ی بازگشت، تلاش دوباره، ثبت رخداد ها برای ممیزی، مجموعه های ارزیابی و شاخص های اعتماد را توصیف می کرد.

این روز ها وقتی به کسانی که نمونه کار هوش مصنوعی می سازند مشاوره می دهم، می پرسم:

از کجا می دانید سامانه تان خوب است؟

«چون دمو کار کرد» دیگر پاسخ قوی ای نیست.

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

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

آیا می شود از همین حالا مهندس هوش مصنوعی شد؟

معمولاً نه، دست کم نه مستقیم.

برچسب های خودکار سطح تجربه در داده های خام بدون بازبینی دستی قابل اعتماد نبودند. یک نقش بسیار ارشد که بیش از ده سال سابقه می خواست، به اشتباه «سطح ورود» برچسب خورده بود.

پس از خواندن شرح شغل ها، نمونه به شدت به سمت متقاضیان باتجربه سنگین بود.

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

فرصت های واقعی برای تازه کار ها هم بود. نقش تازه کارِ مهندس هوش مصنوعی ایجنتیک در EchoStar یک تا دو سال سابقه می خواست. اما حتی همین نقش پایتون، آشنایی با مدل های زبانی، تجربه ی بک اند، Docker، دانش ابری و مبانی مهندسی نرم افزار را انتظار داشت.

برای بیشتر تازه کار ها، مسیر واقع بینانه تر این است:

• پایتون و مبانی نرم افزار را یاد بگیرید؛
• مهارت های بک اند و داده را بسازید؛
• ابر و استقرار را یاد بگیرید؛
• برنامه های مبتنی بر مدل زبانی، RAG، ایجنت ها و ارزیابی را اضافه کنید؛
• برای نقش های تازه کار در نرم افزار، داده، یادگیری ماشین، خودکارسازی یا برنامه های هوش مصنوعی درخواست بدهید؛
• به تدریج به مسئولیت های گسترده تر مهندس هوش مصنوعی برسید.

مهندسی هوش مصنوعی می تواند نقش هدف شما باشد، حتی اگر اولین عنوان شغلی تان نباشد.

عنوان مهندس هوش مصنوعی چند مسیر دارد

همه ی مهندسان هوش مصنوعی یک کار را انجام نمی دهند.

مهندس هوش مصنوعی کاربردی

با مدل های زبانی، RAG، ابزار ها، API و ایجنت ها برنامه می سازد.

این دسترس پذیرترین مسیر برای توسعه دهندگان قوی پایتون و بک اند است.

مهندس پلتفرم هوش مصنوعی

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

این مسیر دانش قوی تری در ابر، DevOps، سامانه های توزیع شده و پلتفرم می خواهد.

مهندس زیرساخت هوش مصنوعی

نزدیک تر به سامانه های GPU، شبکه، ذخیره سازی، زیرساخت استنتاج، پردازش با کارایی بالا و کارایی میزبانی مدل کار می کند.

مهندس هوش مصنوعی ایجنتیک

ایجنت ها، سامانه های هماهنگ سازی، یکپارچه سازی ابزار، مدیریت حالت، جریان های تأیید و اجرای قابل اعتماد اقدامات را می سازد.

مهندس هوش مصنوعیِ مستقر در محل مشتری

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

مهندس خودکارسازی با هوش مصنوعی

هوش مصنوعی را با گردش کار کسب وکار، نرم افزار های سازمانی، RPA، Power Platform، فرایندکاوی و پردازش اسناد ترکیب می کند.

فهمیدن این تفاوت ها کمک می کند بی هدف سراغ یادگرفتن همه ی ابزار ها نروید.

مسیر یادگیری را از این پایه ها بسازید

من یک مسیر یادگیری هفت لایه پیشنهاد می کنم.

۱. پایتون و مهندسی نرم افزار

یاد بگیرید:

• پایتون؛
• Git؛
• آزمون نویسی؛
• اشکال زدایی؛
• کد تمیز؛
• ماژول و بسته؛
• ساختمان داده؛
• مدیریت خطا؛
• طراحی پایه ی سامانه.

۲. توسعه ی بک اند

یاد بگیرید:

• REST API؛
• FastAPI یا چارچوبی مشابه؛
• احراز هویت؛
• SQL؛
• PostgreSQL؛
• برنامه نویسی ناهمگام؛
• یکپارچه سازی با APIهای بیرونی.

۳. ابر و استقرار

یاد بگیرید:

• یک پلتفرم ابری؛
• Docker؛
• CI/CD؛
• مدیریت اطلاعات محرمانه؛
• ثبت رویداد؛
• پایش؛
• مفاهیم پایه ی Kubernetes.

۴. توسعه ی برنامه با مدل زبانی

یاد بگیرید:

• APIهای مدل؛
• خروجی ساختاریافته؛
• فراخوانی تابع و ابزار؛
• مدیریت زمینه؛
• تلاش دوباره؛
• محدودیت زمانی؛
• انتخاب مدل؛
• کنترل توکن و هزینه.

۵. بازیابی و RAG

یاد بگیرید:

• embedding؛
• پایگاه داده ی برداری؛
• جست وجوی ترکیبی؛
• تکه بندی؛
• فیلتر بر اساس فراداده؛
• رتبه بندی مجدد؛
• ارزیابی بازیابی؛
• اتکا به منبع.

۶. ایجنت های هوش مصنوعی

یاد بگیرید:

• ابزار ها؛
• حالت؛
• برنامه ریزی؛
• گراف اجرا؛
• حافظه؛
• مراحل تأیید؛
• دسترسی ها؛
• خودتوانی (idempotency)؛
• ثبت رخداد ها برای ممیزی؛
• بازیابی پس از خطا.

۷. ارزیابی و عملیات در محیط واقعی

یاد بگیرید:

• مجموعه داده ی آزمون؛
• شاخص های بازیابی؛
• ارزیابی پاسخ؛
• اندازه گیری تأخیر؛
• ردگیری هزینه؛
• تحلیل توهم مدل؛
• پایش؛
• امنیت؛
• مشاهده پذیری.

لازم نیست پیش از درخواست شغل در هر هفت لایه استاد شوید.

اما باید آن قدر گستردگی داشته باشید که بتوانید یک سامانه ی کامل بسازید و تصمیم هایتان را توضیح دهید.

اگر یک نقطه ی شروع ساختاریافته می خواهید، مسیر های شغلی رایگان داده و هوش مصنوعی این پایه ها را به دوره ها و پروژه های عملیِ مرتب شده وصل می کنند.

نمونه کار را به یک سامانه ی قابل آزمون تبدیل کنید

پنج چت بات تقریباً یکسان نسازید.

یک سامانه بسازید که عمق مهندسی را نشان دهد.

برای مثال، یک دستیار دانش سازمانی بسازید که:

• اسناد را از چند منبع وارد می کند؛
• آن ها را ذخیره و جست وجو می کند؛
• از بازیابی ترکیبی و رتبه بندی مجدد استفاده می کند؛
• برای هر پاسخ شاهد ارائه می دهد؛
• یک یا دو ابزار مجاز را فراخوانی می کند؛
• پیش از اقدامات حساس تأیید می گیرد؛
• ردپای ممیزی ثبت می کند؛
• تلاش دوباره و رفتار جایگزین دارد؛
• کیفیت بازیابی و پاسخ را ارزیابی می کند؛
• تأخیر و هزینه ی مدل را ردگیری می کند؛
• یک بک اند FastAPI ارائه می دهد؛
• در Docker اجرا می شود؛
• روی یک پلتفرم ابری مستقر می شود؛
• آزمون و مستندات دارد.

بعد توضیح دهید:

• مسئله؛
• معماری؛
• بده بستان ها؛
• حالت های شکست؛
• روش ارزیابی؛
• هزینه؛
• تصمیم های امنیتی؛
• و این که قدم بعدی برای بهبود چیست.

همین توضیح ممکن است برای کارفرما ارزشمندتر از افزودن یک چارچوب دیگر به پروژه باشد.

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

برای استخدام، توان اداره ی سامانه را نشان دهید

لازم نیست دنبال هر کتابخانه ی تازه ای بدوید.

چارچوب ها همچنان تغییر خواهند کرد. عنوان های شغلی هم.

مهارت های ماندگارتر این ها هستند:

• نوشتن نرم افزار قابل اعتماد؛
• یکپارچه سازی سامانه ها؛
• کار با داده؛
• استقرار برنامه ها؛
• اندازه گیری کیفیت؛
• کنترل ریسک؛
• فهمیدن کاربران؛
• توضیح دادن تصمیم های فنی.

بازار فعلی دارد از نمایش هوش مصنوعی به سمت عملیات هوش مصنوعی حرکت می کند.

یک نمایش می پرسد:

آیا مدل می تواند این کار را انجام دهد؟

یک مهندس هوش مصنوعی در محیط عملیاتی می پرسد:

آیا کل سامانه می تواند این کار را بار ها، به شکلی امن، قابل اندازه گیری و با هزینه ای قابل قبول انجام دهد؟

تفاوت میان وصل شدن به یک مدل زبانی و مهندس هوش مصنوعی شدن همین است.

نمونه ی آگهی ها و محدودیت تحلیل

یک خروجی منبع با ۶۳ رکورد فعال را بررسی کردم که در دسته ی نقش های مهندس هوش مصنوعی در آمریکا قرار داشتند. این خروجی در ۲۵ ژوئیه ی ۲۰۲۶ تهیه شده بود.

پیش از محاسبه ی درصد ها، رکورد ها را پاک سازی کردم.

یک نقش واحد از Deloitte، ۳۷ بار برای محل های مختلف تکرار شده بود.

یک آگهی صراحتاً خودش را آگهی آزمایشیِ داخلی Indeed معرفی کرده بود، نه یک موقعیت شغلی واقعی.

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

پس از حذف تکراری های آشکار و رکورد های مسئله دار، نتایج را از ۲۱ نقش متمایز (ترکیب کارفرما و عنوان) از ۱۶ کارفرما محاسبه کردم. فایل قابل دریافت شامل شمارش های تجمیعی است که در جدول استفاده شده، نه متن آگهی ها.

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