تمایز عملیاتی مهره‌های AI در برابر ML و دانشمند داده

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

این سردرگمی از آنجا ناشی می‌شود که عناوین شغلی، مصنوعات سازمانی برای تعیین دستمزد هستند، نه توصیف‌های دقیق فنی. این نوعی از بی‌دقتی نیست که به سادگی اصلاح شود. طبق گزارش‌های صنعتی تا اوت ۲۰۲۶، بازار با انفجاری از برچسب‌های شغلی روبروست که سه نوع کار کاملاً متفاوت را در پوشش یک عنوان پنهان می‌کنند. برای درک واقعی نقش هر فرد، نباید به عنوان او نگاه کرد، بلکه باید «محور مسئولیت» (Axis of Accountability) را یافت؛ یعنی دقیقاً چه شکست فنی‌ای است که آن فرد باید در برابر آن پاسخگو باشد. اگر این محور را پیدا کنید، تمام جزئیات دیگر نقش به طور خودکار روشن می‌شوند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی تحول در ساختار تیم‌های محصول اشاره کردیم، شفافیت در تعریف نقش، تنها راه جلوگیری از شکست پروژه‌های مقیاس‌بزرگ است. برای آشنایی بیشتر با مرزهای نظری این حوزه‌ها، می‌توانید نقشه‌ی جامع تمایز میان هوش مصنوعی، یادگیری ماشین و علم داده را مطالعه کنید تا چارچوبی عملی برای درک این مفاهیم به دست آورید.

مهندس هوش مصنوعی (AI Engineer) — مثل یک تکنسین خبره که قطعات مختلف یک دستگاه پیچیده را به هم وصل می‌کند تا دستگاه کار کند — جدیدترین نقش در این زنجیره است و محتویات شغلی آن هنوز در حال تغییر و تحول است. او معمولاً مدل‌هایی را که از آن‌ها استفاده می‌کند آموزش نمی‌دهد؛ در عوض، مدل‌هایی را که توسط دیگران آموزش دیده‌اند، در سیستمی ادغام می‌کند که باید رفتار مشخصی داشته باشد. روز کاری او به جای تئوری‌های مدل‌سازی، با «حالت‌های شکست» (Failure Modes) و مدیریت هزینه‌ها تعریف می‌شود. در واقع، هیچ بخشی از روتین روزانه او نیازی به دانستن نحوه عملکرد دقیق یک ترنسفورمر ندارد؛ بلکه نیاز دارد بداند وقتی یک جزء سیستم به جای «از دسترس خارج شدن»، «اشتباه» عمل می‌کند، سیستم چه واکنشی نشان می‌دهد.

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

• تحلیل ردپای (Trace Analysis): استخراج ردپاهای سیستمی زمانی که یک تیکت پشتیبانی گزارش می‌دهد دستیار هوشمند ادعایی را نقل کرده که در سند منبع وجود ندارد؛ سپس تصمیم‌گیری در مورد اینکه آیا باید روش تکه‌بندی (Chunking) را اصلاح کند یا یک لایه‌ی بررسی مبنی‌سازی (Grounding Check) پس از تولید متن اضافه کند.
• بهینه‌سازی عامل‌ها (Agent Optimization): بازبینی درخواست‌های ادغام (PRs) برای عامل‌ها به منظور محدود کردن لیست ابزارهای در دسترس، زیرا تعداد زیاد ابزارها باعث کاهش دقت در انتخاب ابزار صحیح می‌شود.
• مدیریت حوادث: ثابت کردن نسخه‌ی مدل‌ها (Pinning) و نوشتن یادداشت‌های حادثه در زمانی که به‌روزرسانی‌های سمت ارائه‌دهنده باعث قرمز شدن (شکست) مجموعه‌های ارزیابی می‌شود.
• راهنمایی محصول: توضیح دادن این نکته به مدیران محصول که چرا یک ویژگی درخواستی ممکن است، اما لزوماً به یک مرحله بازبینی انسانی نیاز دارد.

او مسئول پایداری سرویسی است که مدل‌ها را فراخوانی می‌کند. به طور مشخص، او در برابر تأخیر سرویس (Latency)، هزینه هر درخواست، نرخ شکست در برابر یک ارزیابی تعریف‌شده و رفتار سیستم در هنگام بدعملکردی ارائه‌دهنده مدل، پاسخگو است. خروجی‌های اصلی او شامل پرومپت‌های تحت کنترل نسخه، شمای داده‌ها (Schemas)، خطوط لوله بازیابی، چهارچوب‌های ارزیابی و منطق‌های جایگزین (Fallback) و تلاش مجدد (Retry) است.

در مقابل، مهندس یادگیری ماشین (ML Engineer) — شبیه به مهندسی که کارخانه تولید قطعات را مدیریت می‌کند تا کیفیت هر قطعه ثابت باشد — مالک کامل یک مدل در محیط عملیاتی است، از ابتدا تا انتها. این نقش به شدت بر زیرساخت‌های آموزش، داده‌هایی که مدل روی آن‌ها آموزش می‌بیند و اتفاقاتی که هنگام تغییر داده‌ها رخ می‌دهد، متمرکز است. زیرساخت بخش بزرگی از این شغل را تشکیل می‌دهد.

ویژگی‌های کلیدی و شاخصه‌های کار مهندس ML عبارتند از:

• تشخیص انحراف (Skew Detection): بررسی این موضوع که چرا معیار آفلاین یک مدل توصیه‌گر بهبود یافته اما معیار آنلاین تغییری نکرده است؛ که اغلب منجر به کشف این نکته می‌شود که یک ویژگی (Feature) در پردازش دسته‌ای (Batch) متفاوت از مسیر سرویس‌دهی (Serving Path) محاسبه شده است.
• مدیریت سخت‌افزار: کاهش اندازه دسته (Batch Size) برای سازگاری با سخت‌افزارهای مختلف، به‌خصوص زمانی که یک اجرای آموزشی ساعت‌ها در صف انتظار مانده است.
• یکپارچگی داده‌ها: ساخت خطوط لوله ویژگی برای اطمینان از اینکه سیگنال‌های جدید معنای زمانی درستی دارند و هیچ‌گونه نشت داده‌ای (Data Leakage) از آینده به گذشته رخ نداده است.
• ایمنی استقرار: بازبینی کارت مدل (Model Card) و برنامه‌ی بازگشت (Rollback) پیش از استقرار کاناری (Canary Deployment).

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

در نهایت، دانشمند داده (Data Scientist) — مانند یک کارآگاه که از میان سرنخ‌های ناقص، حقیقتی را استخراج می‌کند — تولیدکننده تصمیم است، نه سیستم. خروجی او معمولاً یک استدلال است که توسط شواهد پشتیبانی می‌شود. سخت‌ترین چالش او مهندسی نیست، بلکه استنتاج (Inference) از داده‌های ناقص است.

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

• تحلیل علّی (Causal Analysis): رد ادعاهایی که می‌گویند یک ویژگی خاص باعث افزایش نرخ بازگشت کاربر شده است، با شناسایی اینکه این تغییر همزمان با تغییر قیمت رخ داده و بنابراین این دو عامل با هم درآمیخته‌اند (Confounded).
• طراحی آزمایش: طراحی آزمایش‌های سخت‌گیرانه از طریق تعریف دقیق واحدها، معیارها، اثرات قابل تشخیص حداقل (MDE) و مدت زمان آزمایش.
• بینش استراتژیک: انجام تحلیل بر روی دلیل ریزش (Churn) بخشی از کاربران، که منجر به ترسیم یک نمودار و نوشتن سه جمله می‌شود که می‌تواند کل نقشه راه محصول را تغییر دهد.
• بررسی معیارهای سنجش: مخالفت با معیارهای پیشنهادی به دلیل اینکه به‌وضوح قابل دست‌کاری (Gameable) هستند.

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

باید به نقش پژوهشگر / مهندس تحقیق (Research Engineer / Scientist) نیز اشاره کرد، زیرا آگهی‌های شغلی مکرراً این نقش را با نقش‌های دیگر اشتباه می‌گیرند. با این حال، این نقش در دسته‌بندی کاملاً متفاوتی قرار دارد.

• مسئولیت: آن‌ها در برابر رسیدن به یک نتیجه «جدید» پاسخگو هستند، نه در برابر پایداری یک سیستم.
• خروجی‌ها: آن‌ها آزمایش‌ها، تحلیل‌های حذف (Ablations)، مقالات و مدل‌هایی تولید می‌کنند که در نهایت شخص دیگری آن‌ها را عملیاتی (Productionise) می‌کند.
• ماهیت کار: این نقش بر اساس ادبیات علمی متفاوت، روتین روزانه متفاوت و استانداردهای استخدامی متفاوتی عمل می‌کند.

نقاط تلاقی این نقش‌ها جایی است که اصطکاک رخ می‌دهد. برای مثال، «ارزیابی» (Evaluation) بین این نقش‌ها مشترک است اما تعریف آن متفاوت است: یک دانشمند داده به دنبال مقایسه‌ای است که از نظر آماری قابل دفاع باشد، در حالی که یک مهندس AI به دنبال یک گیت رگرسیون (Regression Gate) است که در محیط CI اجرا شود. تیم‌هایی که فاقد یکی از این دو دیدگاه هستند، یا تغییراتی را بدون اندازه‌گیری منتشر می‌کنند یا همه چیز را اندازه‌گیری کرده و هیچ‌چیز را منتشر نمی‌کنند.

تنظیم دقیق (Fine-tuning) — مثل وقتی به یک پزشک عمومی، تخصص پوست می‌دهیم تا در یک حوزه دقیق شود — در مرز این دو نقش است: تصمیم به این‌که آیا اصلاً نیاز به تنظیم دقیق هست یا خیر، معمولاً یک تصمیم مهندسی AI است؛ اما انجام درست این کار با مجموعه‌ای از داده‌ها که به‌طور تصادفی مجموعه ارزیابی را لو ندهد، تخصص مهندسی ML است.

کیفیت بازیابی (Retrieval) جایی است که شدیدترین تلاقی رخ می‌دهد. این مسئله شبیه به یک problem مهندسی به نظر می‌رسد و مانند یک مسئله مربوط به مربوط بودن جستجو (Search Relevance) اندازه‌گیری می‌شود — که در واقع یک مهارت دانشمند داده است. تیم‌هایی که بازیابی را صرفاً یک مسئله مهندسی می‌بینند، معمولاً در نقطه‌ای که «دمو کار می‌کند» متوقف شده و به بن‌بست می‌رسند.

علاوه‌ بر این، اقتصاد واحد (Unit Economics) و هزینه‌ها اغلب از قلم می‌افتند. چون هیچ‌کس به طور پیش‌فرض مالک هزینه نیست، این مسئولیت بر دوش هر کسی می‌افتد که زودتر متوجه هزینه شود، که این خود نیاز به تعیین یک مالک صریح برای هزینه‌ها را برجسته می‌کند.

برای رمزگشایی از یک پیشنهاد شغلی و یافتن حقیقت پشت یک آگهی، عنوان را نادیده بگیرید و به دنبال چهار سیگنال خاص بگردید:
۱. آموزش: آیا این نقش چیزی را آموزش می‌دهد؟ اگر خط لوله (Pipeline)، مجموعه داده (Dataset) و آهنگ بازآموزی (Retraining Cadence) ذکر شده است، این یک شغل مهندسی ML است.
۲. دسترسی به مدل: اگر تنها مدل‌های مورد استفاده مدل‌هایی هستند که شرکت از طریق API فراخوانی می‌کند، این مهندسی AI است.
۳. چرخه پشتیبانی (On-call): آیا سرویسی با چرخه بیدارباش برای رفع خرابی وجود دارد؟ پیجر شدن (Paged) شدیدترین تک‌شاخص برای تشخیص این است که شغل در کدام سمت خط مهندسی قرار دارد.
۴. قالب خروجی: خروجی را چه کسی مصرف می‌کند — یک سیستم یا یک انسان؟ خروجی‌ای که یک اسلاید یا سند است، بدون توجه به ابزار مورد استفاده، یک کار تحلیلی است.

در نهایت، حلقه‌ی مصاحبه را بررسی کنید. مصاحبه‌ای که شامل یک تحلیل خانگی (Take-home analysis) است، برای سنجش قضاوت درباره داده‌ها استخدام می‌کند؛ اما مصاحبه‌ای با بخش طراحی سیستم (System Design)، برای ساخت سیستم‌ها استخدام می‌کند. حلقه‌ی مصاحبه صادقانه‌ترین توصیف شغل است زیرا با در نظر گرفتن کار واقعی طراحی شده است.

در نهایت، هیچ رتبه‌بندی ارشدی (Seniority) بین این نقش‌ها وجود ندارد. این‌ها سه شغل متفاوت هستند که با شخصیت‌های مختلف سازگارند و هیچ‌کدام نسخه ارشد دیگری نیستند. انتخاب کنید که دوست دارید در کدام «سه‌شنبه» زندگی کنید: ادغام سیستم‌ها، مدیریت خطوط لوله آموزش، یا تولید استدلال‌های مبتنی بر شواهد.

گام بعدی شما

• اگر در حال تدوین شرح شغلی هستید، به جای عنوان، «محور مسئولیت» و خروجی‌های مورد انتظار (کد یا سند) را تعریف کنید.
• در مصاحبه‌های استخدام، نوع تست (طراحی سیستم در برابر تحلیل داده) را به عنوان دقیق‌ترین توصیف شغل در نظر بگیرید.
• بررسی کنید در تیم شما چه کسی مسئول «هزینه استنتاج» است؛ اگر هیچ‌کس نیست، این یک ریسک عملیاتی است.

اما این تفاوت‌های نقش تنها نیمی از داستان است؛ تأثیر این ساختار بر حقوق و دستمزدهای سال ۲۰۲۶ در گزارش بعدی ما بررسی خواهد شد. این شکاف در تخصص‌ها می‌تواند منجر به پیدایش طبقات شغلی جدید شود، مشابه آنچه در تحلیل «کاربران پیشرفته» و شکاف مهارت‌های عملی AI بررسی کردیم که در آن توزیع نابرابر مهارت‌ها، نیروی کار را به دو سطح تقسیم می‌کند.