مبانی و معماری عملیات یادگیری ماشین (MLOps Fundamentals)

مبحث ۶: عملیات و مهندسی یادگیری ماشین (MLOps)

MLOps: Infrastructure, Pipelines & Production Engineering

فصل پنجم: مدیریت، امکان‌سنجی و MLOps در پروژه‌های هوش مصنوعی

۱. راهنمای مطالعه و هدف آموزشی

مبحث MLOps نقطه تلاقی علم داده (Data Science)، مهندسی داده (Data Engineering) و مهندسی نرم‌افزار/DevOps است. هدف این مبحث تبدیل کدهای آزمایشگاهی پایتون به سرویس‌های ابری مقیاس‌پذیر، پایدار، خودترمیم‌شونده و قابل بازتولید است. در آزمون مشاوران نصر، محورهای تستی کلیدی این مبحث عبارتند از: - چرخه ۴ گانه پیوسته: CI (ادغام پیوسته)، CD (تحویل پیوسته)، CT (آموزش پیوسته) و CM (پایش پیوسته) - معماری انبار ویژگی‌ها (Feature Store) و تفکیک لایه‌های Online Store (با تأخیر زیر ۱۰ms) و Offline Store (برای آموزش دسته‌ای) - ابزارهای استاندارد اکوسیستم MLOps: DVC (نسخه‌بندی داده)، MLflow (ثبت مدل و پارامترها)، Kubeflow (ارکستراسیون)، Evidently AI (پایش Drift) و Triton / TorchServe (سرور استنتاج) - اعتبارسنجی خودکار داده با Great Expectations و حل معضل Training-Serving Skew - سطوح بلوغ فرآیندی MLOps و سازوکارهای تریگر بازآموزی خودکار.

۲. این مبحث درباره چیست؟

در گذشته، دانشمندان داده پس از هفته‌ها کار روی ژوپیتر نوت‌بوک، یک فایل فشرده حاوی وزن‌های مدل (model.pkl) را به مهندسان نرم‌افزار تحویل می‌دادند تا به نحوی آن را اجرا کنند. این شکاف عمیق باعث می‌شد استقرار هر مدل ماه‌ها طول بکشد و پس از استقرار نیز به دلیل عدم تطابق کتابخانه‌ها، نبود مانیتورینگ Drift و فقدان قابلیت بازتولید، سیستم دچار سقوط شود.
MLOps مجموعه‌ای از ابزارها، الگوهای معماری و خطوط لوله (Pipelines) خودکار است که فاصله میان ساخت مدل در محیط آزمایشگاهی تا استقرار ایمن و نظارت ۲۴ ساعته بر آن را پر می‌کند.

۳. تعریف ساده

تعریف ساده: اگر دانشمند داده مثل یک سرآشپز خلاق باشد که در آشپزخانه یک غذای معرکه ابداع کرده، MLOps مثل خط تولید صنعتی کارخانه کنسرو و بسته‌بندی است! وظیفه MLOps این است که مطمئن شود این دستور پخت هر روز روی هزاران قوطی با همان کیفیت اجرا می‌شود، مواد فاسد وارد دیگ نمی‌شوند، خط تولید متوقف نمی‌شود و اگر مزه گوجه‌فرنگی‌های بازار عوض شد، چاشنی غذا خودبه‌خود تنظیم می‌گردد!

۴. تعریف تخصصی

تعریف تخصصی: متدولوژی مهندسی سیستماتیک و یکپارچه برای استانداردسازی و خودکارسازی چرخه کامل حیات یادگیری ماشین (End-to-End ML Lifecycle). MLOps با ترکیب اصول DevOps با ره‌گیری تبار داده و کد (Data/Model Provenance)، اعتبارسنجی طرح‌واره داده (Schema Validation)، ارکستراسیون پایپ‌لاین‌های محاسباتی کانتینریزه (Containerized Orchestration)، سرورهای استنتاج چندمدلی با توان بالا و پایش برخط زوال آماری، کیفیت تولیدی نرم‌افزارهای داده‌محور را تضمین می‌نماید.

۵. مفاهیم و ارکان کلیدی

۵.۱. ارکان چهارگانه MLOps (CI / CD / CT / CM) 🔴

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

+-------------------------------------------------------------------------------+
|                       ارکان چهارگانه چرخه حیات MLOps مدرن                     |
+-------------------------------------------------------------------------------+
| ۱. یکپارچه‌سازی پیوسته (CI): تست کد پایتون + تست کیفیت و توزیع آماری داده‌ها  |
|                                       |                                       |
|                                       v                                       |
| ۲. تحویل پیوسته (CD): استقرار خودکار پایپ‌لاین آموزش و سرویس‌دهی وب‌سرویس مدل |
|                                       |                                       |
|                                       v                                       |
| ۳. آموزش پیوسته (CT): بازآموزی خودکار مدل با داده‌های جدید بدون دخالت دست     |
|                                       |                                       |
|                                       v                                       |
| ۴. پایش پیوسته (CM): پایش توزیع ورودی (Data Drift)، مفاهیم و معیارهای سرور    |
+-------------------------------------------------------------------------------+

نکته طلایی نصر: رکن CT (Continuous Training) و پایش Data Drift ویژگی‌های انحصاری MLOps هستند که در DevOps کلاسیک نرم‌افزاری وجود ندارند.

۵.۲. معماری انبار ویژگی‌ها (Feature Store Architecture) 🔴

انبار ویژگی‌ها ستون فقرات مهندسی ویژگی در سازمان‌های بزرگ داده‌محور است:

                  [پایگاه داده‌های تراکنشی و لاگ‌های خام]
                                     |
                                     v
                  [پایپ‌لاین تبدیل و مهندسی ویژگی‌ها]
                                     |
                                     v
                       +---------------------------+
                       |       FEATURE STORE       |
                       |       (مثلاً Feast)       |
                       +---------------------------+
                               /           \
                             /               \
                            v                 v
           [Online Store (حافظه‌محور)]     [Offline Store (ستون‌محور)]
           - Redis / DynamoDB              - Snowflake / Parquet / S3
           - ویژگی: تأخیر زیر ۱۰ میلی‌ثانیه - ویژگی: حجم بالا و ارزان
           - کاربرد: استنتاج بلادرنگ API   - کاربرد: آموزش دسته‌ای مدل‌ها

• هدف حیاتی Feature Store: جلوگیری از معضل Training-Serving Skew؛ یعنی تضمین اینکه منطق ریاضی و مقادیر یک ویژگی (مثلاً «میانگین خرید کاربر در ۳۰ روز گذشته») در زمان آموزش آفلاین دقیقاً با زمان فراخوانی آنلاین وب‌سرویس یکسان باشد.

۵.۳. جعبه‌ابزار استاندارد MLOps (MLOps Tooling Landscape) 🔴

در آزمون نصر، کارکرد دقیق هر ابزار صنعتی مورد سوال قرار می‌گیرد:

۵.۴. تریگرهای بازآموزی خودکار (Continuous Training Triggers) 🟠

در سطح ۱ و ۲ MLOps، آموزش مجدد مدل بر اساس ۳ سناریو آغاز می‌شود: 1. تریگر تقویمی / زمان‌بندی‌شده (Schedule-driven): اجرای آموزش در پایان هر هفته یا هر ماه (مناسب برای داده‌های با تغییرات قابل پیش‌بینی). 2. تریگر مبتنی بر رویداد Drift (Event / Metric-driven): به محض عبور شاخص رانش جمعیت (PSI > 0.25) یا افت معیار دقت F1 به زیر آستانه مجاز. 3. تریگر تغییر حجم داده (Data-volume-driven): هر زمان که ۱۰۰,۰۰۰ رکورد برچسب‌خورده جدید به پایگاه داده اضافه شد.

۶. چگونه کار می‌کند؟ (معماری جریان کامل پایپ‌لاین تولیدی MLOps)

[کد مهندس داده در Git]      [داده خام جدید]
          |                        |
          |                        v
          |            [تست کیفیت با Great Expectations]
          |                        |
          v                        v
[CI: اجرای Unit Tests] ---> [ارکستراسیون پایپ‌لاین با Kubeflow / Airflow]
                                   |
                                   v
                      [واکشی ویژگی‌ها از Offline Feature Store]
                                   |
                                   v
                      [آموزش توزیع‌شده مدل بر کلاستر GPU]
                                   |
                                   v
                      [ثبت مدل و لاگ پارامترها در MLflow]
                                   |
                                   v
                      آیا دقت مدل جدید > مدل پروداکشن فعلی است؟
                                  /         \
                                بله         خیر ---> [هشدار به تیم فنی]
                                /
                               v
               [CD: استقرار قناری بر Triton Inference Server]
                               |
                               v
           [سرویس‌دهی API با واکشی سریع از Online Feature Store]
                               |
                               v
            [لاگ پیش‌بینی‌ها و مانیتورینگ Drift با Evidently AI]

۷. سناریوی واقعی سازمانی

فروشگاه آنلاین بزرگ دیجی‌کالا (سیستم توصیه‌گر هوشمند): - مسئله: مدل‌های توصیه‌گر محصولات برای هر کاربر بر اساس ترندهای روز به شدت متغیر بودند. استقرار دستی مدل‌ها هر ۲ هفته یک‌بار انجام می‌شد؛ در نتیجه کالاهای حراجی جدید تا چندین روز به کاربران پیشنهاد داده نمی‌شدند و نرخ کلیک (CTR) افت کرده بود. - راهکار استقرار MLOps: 1. راه‌اندازی Feast Feature Store: ویژگی‌های لحظه‌ای (مانند آخرین ۵ محصول مشاهده‌شده کاربر) در Redis (Online Store) ذخیره شد تا در کمتر از ۸ میلی‌ثانیه فراخوانی شوند. 2. استقرار خط لوله CT با Kubeflow: به محض انباشت داده‌های خرید شب گذشته، پایپ‌لاین آموزش به طور خودکار ساعت ۳ بامداد فعال شده و مدل به‌روزشده را تا ساعت ۵ صبح آموزش می‌دهد. 3. استقرار با Triton Inference Server: با قابلیت Dynamic Batching، توان پاسخگویی سرور از ۲۰۰ درخواست در ثانیه به ۱,۸۰۰ RPS ارتقا یافت. - نتیجه: افزایش ۲۲ درصدی نرخ تبدیل سبد خرید و حذف کامل خطاهای دستی در استقرار.

۸. مثال خیلی ساده و شهودی

فرض کنید یک برنامه رژیم غذایی هوشمند دارید: - داده و ویژگی‌ها: وزن، قد و تعداد قدم‌های شما. - نبود Feature Store: مجبورید هر بار که برنامه را باز می‌کنید دوباره قد و وزنتان را دستی تایپ کنید! (Training-Serving Skew). - با Feature Store: قد شما در پرونده ذخیره است و تعداد قدم‌های امروزتان در کسری از ثانیه از ساعت هوشمند خوانده می‌شود. - MLOps: اگر بعد از تعطیلات ۵ کیلو اضافه وزن پیدا کنید (Data Drift)، مربی هوشمند رژیم غذایی شما را بدون نیاز به تماس تلفنی بلافاصله بازآموزی کرده و کالری روزانه را کم می‌کند (Continuous Training)!

۹. مقایسه عمیق مفاهیم مشابه

۱۰. مزایا و محدودیت‌ها

مزایا (✅)

1. کاهش چشمگیر زمان استقرار (Time-to-Market): کوتاه‌سازی چرخه عرضه مدل از چند ماه به چند ساعت.
2. بازتولیدپذیری ۱۰۰٪ آزمایش‌ها (Auditability): امکان پاسخ به مراجع ناظر با بازگرداندن تبار دقیق کد، داده و وزن‌های مدل مربوط به هر تاریخ گذشته.
3. حذف خطاهای انسانی: خودکارسازی کامل اعتبارسنجی داده، آموزش، تست و انتشار.
4. بهره‌وری حداکثری از سخت‌افزار گران GPU: با سرورهای استنتاج بهینه‌شده Triton و بچ‌سازی پویا.

محدودیت‌ها و مخاطرات (⛔)

1. هزینه اولیه سنگین زیرساخت و ابزارها: پیاده‌سازی کوبرنتیز و ابزارهای تجاری MLOps نیازمند سرمایه‌گذاری اولیه است.
2. پیچیدگی فزاینده خطوط لوله: با افزایش تعداد ابزارها، دیباگ کردن خطای پایپ‌لاین نیازمند تخصص عمیق در لینوکس، شبکه و یادگیری ماشین است.
3. ریسک خطای بازآموزی خودکار: اگر مکانیزم‌های بازدارنده (Guardrails) ضعیف باشند، مدل با داده‌های مخرب بازآموزی شده و وارد پروداکشن می‌شود.

۱۱. کاربردهای کلیدی در صنایع

+-------------------------------------------------------------------------------+
|                         کاربردهای عملیاتی MLOps در صنایع                      |
+-------------------------------------------------------------------------------+
| ۱. پلتفرم‌های استریم و مدیا: به‌روزرسانی ساعتی ماتریس ویژگی‌های تعاملی کاربران |
| ۲. بانکداری و اعتبارسنجی: ایجاد Audit Trail کامل برای انطباق با قوانین رگولاتوری|
| ۳. صنعت خودروسازی خودران: پردازش ترافیک‌های سنگین تصاویر ضبط‌شده با پایپ‌لاین |
| ۴. شبکه‌های مخابراتی ۵G: بازآموزی بلادرنگ مدل‌های مسیریابی ترافیک بسته‌ها     |
| ۵. تجارت الگوریتمی بورس: استنتاج با تأخیر میکروثانیه‌ای و پایش زوال بازار     |
+-------------------------------------------------------------------------------+

۱۲. دیدگاه مشاوره‌ای (سناریوی آزمون نصر)

سناریوی آزمون نصر:

«یک شرکت فین‌تک برای مدل کشف کلاهبرداری خود متوجه اختلافی عجیب شده است: مدل در مرحله آموزش آفلاین بر روی داده‌های تاریخی به دقت و بازخوانی ۹۶٪ دست یافته بود، اما در محیط عملیاتی، دقت مدل به زیر ۶۵٪ سقوط کرده است. مهندس نرم‌افزار ادعا می‌کند مدل را عیناً از نوت‌بوک اکسپورت کرده و هیچ باگی وجود ندارد. علت ریشه‌ای این بحران چیست و مشاور چه تغییری در معماری پیشنهاد می‌دهد؟»

تحلیل مشاور ارشد هوش مصنوعی:

1. تشخیص عارضه Training-Serving Skew:
2. مهم‌ترین عامل اختلاف کارایی مدل در آزمایشگاه و پروداکشن، تفاوت در نحوه محاسبه و استخراج ویژگی‌ها (Feature Engineering Logic) است. به عنوان مثال، در فاز آموزش آفلاین، ویژگی «میانگین تراکنش‌های ۷ روز گذشته» با استفاده از کوئری SQL روی کل جدول محاسبه شده، اما در سرور استنتاج آنلاین، کدهای پایتون به دلیل اختلاف در مناطق زمانی (Timezone) یا داده‌های ناقص کش، این ویژگی را با منطقی متفاوت محاسبه کرده‌اند.
3. پدیده نشت داده در آموزش (Data Leakage):
4. ممکن است متغیری در آموزش استفاده شده باشد که در لحظه انجام تراکنش آنلاین هنوز در سیستم وجود ندارد.

بسته راهکار مشاور:

1. استقرار فوری Feature Store متمرکز (مانند Feast):
2. تعریف یکپارچه و متمرکز منطق استخراج ویژگی‌ها؛ به طوری که هم پایپ‌لاین آموزش آفلاین و هم وب‌سرویس برخط استنتاج، دقیقاً از یک پایگاه کد و تعریف مشترک برای محاسبه متغیرها استفاده کنند.
3. اعتبارسنجی طرح‌واره ورودی (Schema Validation):
4. استقرار کتابخانه Great Expectations برای اطمینان از تطابق دقیق انواع داده و بازه‌های عددی ورودی‌های آنلاین با داده‌های آموزشی.

۱۳. قاعده تصمیم‌گیری مشاور (درخت تصمیم انتخاب سطح بلوغ MLOps)

                 چند مدل یادگیری ماشین در محیط عملیاتی فعال دارید؟
                                       |
    +----------------------------------+----------------------------------+
    |                                                                     |
[تنها یک مدل با تغییرات داده‌ای بسیار نادر]                           [بیش از ۲ مدل یا داده‌هایی با تغییرات مداوم]
    |                                                                     |
    v                                                                     v
[سطح صفر MLOps کفایت می‌کند]                                  آیا زوال دقت مدل زیان مالی مستقیم دارد؟
- آموزش و استقرار دستی                                                    |
- نسخه‌بندی کد با Git                                                   /   \
                                                                      بله   خیر
                                                                      /       \
                                        [استقرار سطح ۲ MLOps]        [استقرار سطح ۱ MLOps]
                                        - خط لوله کامل CI/CD/CT       - پایپ‌لاین آموزش خودکار (CT)
                                        - Feature Store و Triton      - پایش دستی هفتگی
                                        - مانیتورینگ خودکار Drift     - ثبت مدل با MLflow

۱۴. 🔴 نکات طلایی آزمون نصر (۱۰ نکته کنکوری)

1. وجه تمایز انحصاری MLOps نسبت به DevOps: وجود مؤلفه‌های Continuous Training (CT) و مانیتورینگ Data/Concept Drift.
2. تعریف معضل Training-Serving Skew: تفاوت در نحوه پیش‌پردازش، محاسبه ویژگی‌ها یا توزیع داده میان فاز آموزش و فاز استنتاج زنده.
3. راهکار قطعی Training-Serving Skew: استقرار Feature Store با تعریف یکپارچه منطق متغیرها.
4. تفاوت Online Store و Offline Store در انبار ویژگی: اولی پایگاه داده کم‌تأخیر (Redis) برای استنتاج برخط است و دومی انبار داده حجیم و ارزان (Parquet/S3) برای آموزش گروهی.
5. نقش DVC (Data Version Control): نسخه‌بندی فایل‌های حجیم داده و مدل با متاداده‌های متنی کوچک درون مخزن Git.
6. سطح ۱ MLOps در استاندارد گوگل: خودکارسازی خط لوله آموزش مدل (CT) بدون نیاز به مداخله دستی دانشمند داده.
7. سطح ۲ MLOps در استاندارد گوگل: اتوماسیون کامل پایپ‌لاین‌های CI/CD نرم‌افزار به همراه CT و ارزیابی خودکار مدل.
8. ابزار MLflow Registry: مدیریت نسخه‌های مختلف مدل و اعمال برچسب‌های چرخه عمر (Development, Staging, Production, Archived).
9. سرور استنتاج Triton (محصول انویدیا): استاندارد صنعتی برای سرویس‌دهی مدل‌های چندگانه فریم‌ورک‌های PyTorch و TensorFlow با قابلیت Dynamic Batching.
10. اعتبارسنجی داده با Great Expectations: ممانعت خودکار از ورود داده‌های آلوده، تهی یا خارج از محدوده به چرخه آموزش و استنتاج.

۱۵. ⚠️ دام‌های رایج آزمون

دام ۱: «برای راه‌اندازی MLOps، کافی است کدهای پایتون را در مخزن Git ذخیره کنیم.»
❌ پاسخ دام‌شکن: گیت تنها کد متنی را نسخه‌بندی می‌کند. در سیستم‌های یادگیری ماشین، نسخه‌بندی سه‌گانه کد + داده + وزن‌های مدل الزامی است که مستلزم ابزارهایی مانند DVC و MLflow است.

دام ۲: «Feature Store یک پایگاه داده رابطه‌ای سنتی مانند MySQL است.»
❌ پاسخ دام‌شکن: خیر! انبار ویژگی دارای معماری دوگانه Online/Offline، مدیریت سری‌های زمانی (Point-in-time correctness) و ممانعت از نشت اطلاعات آینده به گذشته است.

دام ۳: «سرورهای استنتاج مانند Triton فقط برای مدل‌های یادگیری عمیق تصویری هستند.»
❌ پاسخ دام‌شکن: تریتون یک سرور استنتاج عمومی فوق‌سریع برای تمامی مدل‌های یادگیری عمیق، مدل‌های سنتی (Scikit-Learn/XGBoost با موتور FIL) و مدل‌های زبانی بزرگ است.

دام ۴: «Continuous Delivery (CD) در MLOps همان دیپلوی کردن فایل پایتون در سرور وب است.»
❌ پاسخ دام‌شکن: در سطح بالای MLOps، آنچه مستقر می‌شود خودِ پایپ‌لاین آموزش و اعتبارسنجی مدل است، نه صرفاً یک فایل خروجی مدل.

۱۶. 🧠 خلاصه یک‌دقیقه‌ای

• تعریف MLOps: پیوند علم داده با مهندسی پروداکشن برای اتوماسیون چرخه حیات مدل.
• ارکان ۴ گانه: ادغام پیوسته (CI)، تحویل پیوسته (CD)، آموزش پیوسته (CT) و پایش پیوسته (CM).
• مخزن ویژگی (Feature Store): تفکیک لایه آنلاین سریع (استنتاج) از آفلاین عمیق (آموزش) برای حذف Training-Serving Skew.
• جعبه‌ابزار اصلی: DVC (داده)، MLflow (ثبت آزمایش و مدل)، Kubeflow (ارکستراسیون)، Evidently (پایش رانش).

۱۷. نقشه ذهنی (ASCII Mind Map)

                                 مهندسی عملیات یادگیری ماشین (MLOps)
                                                 |
    +--------------------+-----------------------+--------------------+--------------------+
    |                    |                                            |                    |
[ارکان چهارگانه]         [معماری Feature Store]                       [جعبه‌ابزار استاندارد]  [سطوح بلوغ و تریگرها]
    |                    |                                            |                    |
    |-- CI (تست داده/کد) |-- Online Store (تأخیر < 10ms - Redis)      |-- DVC (نسخه‌بندی)  |-- تریگر زمان‌بندی
    |-- CD (استقرار خط)  |-- Offline Store (آموزش - S3/Snowflake)     |-- MLflow Registry  |-- تریگر رانش داده
    |-- CT (بازآموزی)    |-- مهار Training-Serving Skew               |-- Kubeflow/Airflow |-- تریگر حجم داده
    |-- CM (پایش Drift)  |-- سازگاری زمانی (Point-in-time)            |-- Triton Server    |-- سطوح ۰، ۱ و ۲ گوگل

۱۸. ارتباط با سایر مباحث

• مبحث ۱ از همین فصل (Project Management): مبانی نظری متدولوژی و مدیریت بدهی فنی داده.
• مبحث ۵ از همین فصل (Success Metrics): تغذیه سنجه‌های p99 Latency و Throughput به داشبوردهای CM در MLOps.
• مبحث ۴ از همین فصل (Risk Management): استقرار Guardrails در خط لوله CD برای مهار خطاهای مدل.
• مبحث ۶ از فصل ۲ (Data Governance): حاکمیت و تبارشناسی داده‌ها (Data Lineage) در انبار ویژگی‌ها.

۱۹. سؤالات احتمالی آزمون (۶ تست استاندارد نصر)

تست ۱ (🔴 — مفاهیم بنیادین و تفاوت با DevOps)

کدام مؤلفه فرآیندی زیر، مشخصه انحصاری مهندسی عملیات یادگیری ماشین (MLOps) است که در متدولوژی‌های سنتی DevOps نرم‌افزاری وجود ندارد؟

الف) یکپارچه‌سازی پیوسته کدهای منبع (Continuous Integration)
ب) آموزش پیوسته مدل با داده‌های جدید (Continuous Training - CT) و مانیتورینگ رانش آماری (Drift Monitoring)
ج) استفاده از سیستم‌های مدیریت کانتینر نظیر Docker
د) خودکارسازی استقرار با پایپ‌لاین‌های CI/CD

کلید: ب
تحلیل تشریحی:
- رد الف، ج، د: داکر، CI و اتوماسیون استقرار مفاهیم استاندارد و مشترک در DevOps کلاسیک نرم‌افزار هستند.
- تأیید ب: در نرم‌افزار سنتی، کد پس از استقرار تا زمان ویرایش دستی توسط برنامه‌نویس تغییر رفتار نمی‌دهد. اما در یادگیری ماشین، رفتار سیستم تابع داده‌های ورودی است؛ از این رو مؤلفه Continuous Training (CT) برای بازآموزی خودکار و Drift Monitoring برای پایش زوال توزیع آماری داده، ویژگی‌های منحصربه‌فرد MLOps هستند.

تست ۲ (🔴 — معماری Feature Store)

علت اصلی تفکیک انبار ویژگی‌ها (Feature Store) به دو لایه Online Store و Offline Store در سامانه‌های بزرگ مقیاس یادگیری ماشین چیست؟

الف) لایه آنلاین برای ذخیره فایل‌های PDF و لایه آفلاین برای تصاویر است.
ب) پاسخگویی به دو نیازمندی کاملاً متفاوت: لایه آنلاین با پایگاه داده‌های درون‌حافظه‌ای تأخیر چند میلی‌ثانیه‌ای را برای استنتاج برخط فراهم می‌سازد، در حالی که لایه آفلاین با انبارهای ستون‌محور حجم‌های عظیم داده را با هزینه اندک برای آموزش دسته‌ای مدل‌ها مدیریت می‌کند.
ج) الزامات پدافند غیرعامل که ارتباط اینترنت را در لایه آفلاین قطع می‌کند.
د) عدم توانایی زبان پایتون در خواندن همزمان داده از یک دیتابیس واحد.

کلید: ب
تحلیل تشریحی:
- رد الف، ج، د: توجیهات نادرست، ساختگی و غیرفنی هستند.
- تأیید ب: در استنتاج بلادرنگ (Inference Time)، وب‌سرویس باید در کمتر از ۱۰ میلی‌ثانیه بردار ویژگی کاربر را واکشی کند که این امر نیازمند دیتابیس‌های In-Memory گران‌قیمت (مانند Redis) در لایه Online است. اما در فاز آموزش (Training Time)، میلیون‌ها رکورد تاریخی با کوئری‌های سنگین پردازش می‌شوند که نیازمند انبارهای داده ارزان و با ظرفیت بالا (مانند Parquet/S3) در لایه Offline است.

تست ۳ (🔴 — ریشه‌یابی خطاهای پروداکشن)

پدیده Training-Serving Skew در پروژه‌های یادگیری ماشین چیست و چه عاملی موثرترین راهکار برای پیشگیری از آن است؟

الف) اختلاف زمان ساعت سیستم‌عامل سرور آموزش و سرور استنتاج؛ راهکار استفاده از ساعت اتمی است.
ب) تفاوت در توزیع آماری یا تفاوت در منطق و کدهای مهندسی ویژگی میان فاز آموزش و فاز سرویس‌دهی زنده؛ مؤثرترین راهکار استقرار Feature Store متمرکز است.
ج) سوختن کارت‌های گرافیک در حین استنتاج؛ راهکار تعویض منبع تغذیه سرور است.
د) نشت حافظه در کدهای زبان C++.

کلید: ب
تحلیل تشریحی:
- تأیید ب: معضل Training-Serving Skew زمانی اتفاق می‌افتد که یک متغیر (مثلاً نرمال‌سازی داده‌ها یا محاسبه نرخ خرید) در فاز آموزش با یک فرمول محاسبه شده و در فاز اجرای واقعی با کدی دیگر یا داده‌های متفاوت محاسبه شود که منجر به سقوط دقت مدل در پروداکشن می‌گردد. استفاده از Feature Store متمرکز با یکسان‌سازی منبع و منطق ویژگی‌ها این چالش را ریشه‌کن می‌کند.
- رد الف، ج، د: گزینه‌های انحرافی و بی‌ارتباط با مهندسی یادگیری ماشین هستند.

تست ۴ (🟠 — ابزارشناسی تخصصی MLOps)

ابزار متن‌باز DVC (Data Version Control) چگونه چالش نسخه‌بندی مجموعه‌داده‌های چند گیگابایتی را بدون نقض محدودیت‌های سیستم Git برطرف می‌نماید؟

الف) کل داده‌ها را فشرده کرده و در قالب فایل متنی ZIP در کامیت‌های گیت قرار می‌دهد.
ب) فایل‌های حجیم را در فضاهای ذخیره‌سازی ابری یا محلی (مانند S3 یا MinIO) نگهداری کرده و صرفاً یک فایل اشاره‌گر متنی کوچک حاوی هش امنیتی (md5) داده‌ها را درون مخزن Git نسخه‌بندی می‌کند.
ج) حجم داده‌ها را با حذف تصادفی ۹۰٪ سطرها کاهش می‌دهد.
د) داده‌ها را به کدهای باینری زبان اسمبلی تبدیل می‌کند.

کلید: ب
تحلیل تشریحی:
- تأیید ب: گیت برای فایل‌های حجیم چند گیگابایتی طراحی نشده است. DVC داده‌های سنگین را به حافظه‌های ذخیره‌سازی مجزا منتقل می‌کند و به ازای هر فایل داده، یک فایل متنی با پسوند .dvc تولید می‌کند که حاوی هش اطلاعات است. برنامه‌نویس با کامیت کردن این فایل کوچک در Git، تبار داده را به شکل کامل و بدون افت سرعت مخزن نسخه‌بندی می‌کند.
- رد الف، ج، د: همگی توصیفات غلط عملکرد DVC هستند.

تست ۵ (🔴 — سطوح بلوغ فرآیندی MLOps)

در طبقه‌بندی سطوح بلوغ MLOps ارائه‌شده توسط شرکت گوگل، تفاوت بنیادین «سطح ۲» با «سطح ۱» در چیست؟

الف) در سطح ۲ دیگر نیازی به نوشتن هیچ کدی نیست و سیستم با هوش عمومی مصنوعی کار می‌کند.
ب) در سطح ۱ فقط پایپ‌لاین آموزش مدل (CT) خودکار است، در حالی که در سطح ۲ خطوط لوله CI/CD نرم‌افزار نیز کاملاً خودکار بوده و امکان بیلد، تست و استقرار خودکار کل پایپ‌لاین‌ها در محیط‌های مختلف فراهم است.
ج) سطح ۲ فقط روی سرورهای ابری خارجی اجرا می‌شود و سطح ۱ روی سرور محلی.
د) در سطح ۲ داده‌های بدون برچسب مجاز هستند اما در سطح ۱ خیر.

کلید: ب
تحلیل تشریحی:
- رد الف، ج، د: فرضیات اشتباه و غیرعلمی هستند.
- تأیید ب: در Level 1 MLOps، خط لوله آموزش مدل خودکار است (CT وجود دارد)، اما در صورت تغییر کدهای زیرساخت یا الگوریتم، استقرار به صورت دستی انجام می‌شود. در Level 2 MLOps، اتوماسیون کامل حاکم است؛ به طوری که مهندسان با یک Push در گیت، کل خطوط لوله مهندسی داده، آموزش و وب‌سرویس را از طریق پایپ‌لاین‌های CI/CD چندمحیطه به صورت اتوماتیک تست و مستقر می‌سازند.

تست ۶ (🟠 — سرورهای استنتاج صنعتی)

ویژگی «Dynamic Batching» در سرورهای استنتاج پیشرفته نظیر Triton Inference Server چه مزیتی در محیط عملیاتی ایجاد می‌کند؟

الف) آموزش مدل را در طول شب متوقف می‌کند تا در مصرف برق صرفه‌جویی شود.
ب) درخواست‌های استنتاج انفرادی رسیده از کاربران مختلف را در پنجره‌های زمانی چند میلی‌ثانیه‌ای تجمیع کرده و به صورت یک بسته (Batch) به GPU ارسال می‌کند تا توان عملیاتی (Throughput) سرور به حداکثر برسد.
ج) متغیرهای گمشده را به طور خودکار با عدد صفر جایگزین می‌کند.
د) مدل‌های یادگیری ماشین را به زبان SQL ترجمه می‌کند.

کلید: ب
تحلیل تشریحی:
- تأیید ب: پردازنده‌های گرافیکی (GPU) هنگامی بالاترین راندمان را دارند که داده‌ها را به صورت دسته‌ای (Batch) پردازش کنند. سرور Triton با قابلیت Dynamic Batching درخواست‌های مجزای کاربران را که با فواصل میلی‌ثانیه‌ای می‌رسند، برای لحظه‌ای کوتاه تجمیع کرده و با هم به GPU ارسال می‌کند؛ این ویژگی توان سرویس‌دهی همزمان را تا چندین برابر افزایش می‌دهد بدون اینکه تأخیر محسوسی برای کاربر ایجاد شود.
- رد الف، ج، د: همگی عملکردهای ساختگی و نامربوط هستند.

۲۰. سطح‌بندی مطالب جهت مرور سریع