تکرارپذیری و پروژه پایان به انتها: ترکیب همه چیز

سود:

• قابلیت اطمینان از تکرارپذیری با چهار ستون (تثبیت بذر، نسخه سازی داده ها، انجماد رسانه ها، نظارت بر آزمایش) و ایجاد نتیجه یکسان در هنگام تکرار همان اجرا
• امکان ترکیب تمام مراحل ماژول (متریک ها، داده ها، مدل، اجزای LLM، ارزیابی، عدالت، امنیت، توزیع، نظارت) در یک زنجیره انتها به انتها
• توانایی تأیید اینکه تصمیم حیاتی در هر توقف با انسان باقی می ماند و پروژه را به شیوه ای قابل ممیزی مستند می کند.

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

چرا تکرارپذیری دشوار است

در نرم افزارهای معمولی همان کد خروجی یکسانی می دهد. در ML متغیرهای بسیار بیشتری وجود دارند که نتیجه را تعیین می کنند:

• تصادفی بودن: به هم زدن داده ها، مقدار اولیه وزن، تقسیم داده ها - همه به تصادفی بودن تکیه می کنند.
• داده: همان کد مدل های مختلف را با نسخه داده های مختلف تولید می کند.
• محیط: نسخه های کتابخانه، سخت افزار (CPU/GPU)، حتی سیستم عامل می توانند نتیجه را تغییر دهند.
• مورد پنهان: یک هایپرپارامتر ذخیره نشده، یک مرحله پیش پردازش دستی، یک انتخاب بدون اشاره.

تکرارپذیری یک "خوب داشتن" نیست بلکه یک ضرورت علمی و مهندسی است. نتیجه ای که قابل بازتولید نیست، ادعایی است که قابل اثبات نیست.

چهار رکن تکرارپذیری

1. تصادفی بودن را برطرف کنید. همه دانه های تصادفی را در یک مکان قرار دهید: تقسیم داده ها، مقداردهی اولیه مدل، درهم ریختن داده ها. دانه ثابت اساس تضمین "هنگام تکرار همان نتیجه یکسان" است.

2. نسخه داده ها. ثبت کنید که هر آزمایش با کدام نسخه داده انجام شده است (نسخه سازی داده در واحد 2). "آخرین داده ها" مبهم است. "نسخه داده v3، هش abc123" دقیق است.

3. محیط را فریز کنید. همه وابستگی‌ها را به نسخه‌های دقیق آنها پین کنید (مثلاً نسخه‌های دقیق مانند numpy==1.26.4 در requirement.txt یا یک تصویر ظرف). "آخرین نسخه" یک روز همه چیز را خراب می کند.

4. همه چیز را ردیابی کنید (ردیابی آزمایشی). ذخیره خودکار برای هر آزمایش: نسخه کد (git commit)، نسخه داده، همه فراپارامترها، معیارها و ساختارهای خروجی. ابزارهای ردیابی آزمایشی مانند MLflow، Weights و Biases این کار را به طور سیستماتیک انجام می دهند. بدون ثبت نام، سوال "کدام تنظیم بهترین بود" بی پاسخ باقی می ماند.

احتیاط: "بعداً یادم می آید" گرانترین مغالطه است. دو هفته بعد شما به یاد نمی آورید که کدام دانه، کدام داده و کدام هایپرپارامتر را استفاده کرده اید. ردیابی خودکار اتکا به حافظه را از بین می برد.

رویکرد ضعیف / رویکرد قوی

ضعیف: "من بهترین مدل را پیدا کردم، روی دفترچه است، فکر می کنم امتیاز آن 89٪ بود."

Strong: "#147 را در ابزار ردیابی آزمایش اجرا کنید: git commit a3f9c، نسخه داده v3 (هش abc123)، seed 42، همه هایپرپارامترها ثبت شده اند، PR-AUC 0.887 را تست کنید. وقتی دوباره همان فرمان را اجرا می کنم، همان نتیجه را ذره ذره دریافت می کنم.

تفاوت: در رویکرد قوی، نتیجه مبتنی بر حافظه نیست، بلکه بر اساس یک زنجیره ثابت و نظارت شده است. همه می توانند هر بار یک نتیجه را به دست آورند.

پروژه پایان به پایان: ترکیبی از ماژول

حالا بیایید کل ماژول را در یک جریان پروژه واحد ترکیب کنیم. یک سیستم ML واقعی از این توقف ها عبور می کند و هر توقف بر روی توقف قبلی ایجاد می شود:

1. تعریف مسئله: چه چیزی را حل می کنیم، چگونه موفقیت را اندازه گیری کنیم (واحد 3: متریک درست، زمینه کسب و کار). متریک و آستانه از ابتدا مشخص است.
2. خط لوله داده: جمع آوری، اعتبارسنجی، پاکسازی، پارتیشن بندی بدون نشت، نسخه سازی (واحد 2).
3. توسعه مدل: آموزش، مقایسه پایه، اعتبارسنجی متقابل، دانه سخت (واحد 3 + این واحد).
4. اجزای LLM (در صورت وجود): RAG (واحد 4) و/یا عوامل (واحد 5)؛ تنظیم دقیق در صورت لزوم (واحد 6).
5. ارزیابی: eval cluster با لبه و موارد امنیتی، eval چند لایه در سیستم های LLM (واحد 8).
6. حسابرسی عدالت و اخلاق: تحلیل زیر گروه، کارت مدل، توضیح پذیری (واحد 10).
7. ممیزی امنیتی: تزریق سریع، حریم خصوصی، زنجیره تامین (واحد 9).
8. توزیع: بسته بندی، توزیع تدریجی، برگشت، رجیستری مدل (واحد 7).
9. مانیتورینگ: مانیتورینگ سه لایه، هشدارهای رانش (واحد 8).
10. تکرارپذیری: بذر، نسخه داده، رسانه و ردیابی آزمایش در کل زنجیره (این واحد).

در این جریان، هوش مصنوعی یک شتاب دهنده و مولد طرح در هر توقف است. اما انتخاب متریک، تصمیم‌گیری داده‌ها، اولویت‌بندی عادلانه، آستانه استقرار و تأیید انتشار - تصمیم‌های حیاتی با انسان باقی می‌مانند. این ماهیت ماژول است.

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

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

سه کیف کوچک

مورد 1 - نتیجه از دست رفته. یک مهندس مدل فوق العاده ای را آموزش داد، اما او Seed را درست نکرد و نسخه داده را ذخیره نکرد. وقتی او کار را ترک کرد، هیچ کس نتوانست آن نتیجه را بازتولید کند. این مدل به یک "افسانه جعبه سیاه" تبدیل شد و در نهایت از ابتدا ساخته شد. هفته ها تلف شد. درس: یک نتیجه غیر قابل تکرار، یک نتیجه غیر موجود است.

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

مورد 3 - قدرت نظارت. یک تیم به طور خودکار هر آزمایش را زیر نظر داشت. سه ماه بعد طی یک ممیزی نظارتی به این سوال پاسخ دادند که «با چه داده‌هایی، با چه تنظیماتی، چه عملکردی در چه گروه‌هایی داشته است؟» با ضبط کامل در عرض چند دقیقه بازرسی به آرامی انجام شد. درس: نظارت یک ابزار انطباق است، نه فقط یک ابزار مهندسی.

قالب های قابل کپی

یک بررسی تکرارپذیری برای این پروژه ML انجام دهید.- آیا همه دانه های تصادفی ثابت هستند (تقسیم، مقداردهی اولیه، درهم ریختن)؟- آیا داده ها نسخه بندی شده اند؟- آیا وابستگی ها به نسخه های دقیق ثابت می شوند؟- آیا هر آزمایش (تعهد کد، داده، هایپرپارامتر، متریک) ردیابی می شود؟ مراحل مشخصی را در مورد چگونگی رفع آن برای هر ستون مفقود بنویسید. ساختار پروژه: [توضیح]

یک اسکلت طرح برای این پروژه ML سرتاسر تولید کنید. مشکل: [توضیح] ایستگاه‌های زیر را بپوشانید و محل تصمیم HUMAN را در هر توقف علامت‌گذاری کنید: مشکل/متریک، خط لوله، مدل، (RAG/agent/fine-tune؟)، ارزیابی، عدالت، امنیت، توزیع، نظارت، تکرارپذیری. ریسک اصلی و مرحله تأیید را برای هر توقف بنویسید.

یک الگوی مستندات فنی برای این پروژه تهیه کنید. بخش ها: مشکل + معیارهای موفقیت، داده ها (منبع + نسخه)، انتخاب مدل + توجیه، ارزیابی (شامل زیر گروه ها)، محدودیت های شناخته شده + خطرات، استقرار + بازگشت مجدد، طرح نظارت. فیلدهایی را که باید برای هر بخش پر شود به عنوان سؤال در نظر بگیرید.

تنظیمات نظارت بر آزمایش من را بررسی کنید: آیا در هر اجرا به صورت خودکار ذخیره می شود: git commit، نسخه داده/هش، همه پارامترها، همه معیارها، محیط (نسخه های کتابخانه)؟ آیا وقتی دوباره همان اجرا را اجرا می کنم همان نتیجه را می گیرم؟ راه اندازی: [توضیح]. ایرادات و تصحیح را فهرست کنید.

جدول ستون های تکرارپذیری

ستون

آنچه ثابت شده است

نمونه وسیله نقلیه

تصادفی بودن

همه دانه ها

تنظیم دانه

داده ها

نسخه داده/هش

DVC

محیط زیست

نسخه های کتابخانه

پین الزامات، داکر

نظارت

کد+داده+تنظیم+متریک

MLflow، W&B

اشتباهات رایج

• دانه را ثابت نمی کند. نتیجه قابل تکرار نیست.
• ذخیره نشدن نسخه داده "با چه داده ای؟" بی پاسخ می ماند
• عدم انجماد اعتیاد به روز رسانی بی سر و صدا همه چیز را خراب می کند.
• آزمایش ها را به حافظه بسپارید. دو هفته بعد چیزی به یاد نمی‌آید.
• واگذاری تصمیمات حیاتی به هوش مصنوعی معیارها، عدالت و تصمیمات توزیع باید با مردم باقی بماند.
• به تعویق انداختن مستندات تیم آینده (و شما) بهای آن را می پردازید.

به طور خلاصه

تکرارپذیری امضای مهندسی جدی ML است: نتیجه غیرقابل تکرار ادعای غیرقابل اثبات است. این دارای چهار ستون است - تصحیح تصادفی، داده های نسخه، محیط ثابت، ردیابی هر آزمایش. یک پروژه انتها به انتها تمام نقاط این ماژول (متریک، داده، مدل، اجزای LLM، eval، عدالت، امنیت، توزیع، نظارت) را در یک زنجیره به هم پیوسته ترکیب می کند. هوش مصنوعی در هر نقطه شتاب دهنده است، اما تصمیمات حیاتی با انسان باقی می ماند. همه چیز را مستند کنید - برای تیم و ممیزی های آینده. این رشته چارچوبی است که هر آنچه را که در طول ماژول یاد می گیرید حفظ می کند.

وظیفه کاربردی

یک پروژه ML را در برابر چهار ستون تکرارپذیری بررسی کنید: آیا دانه‌ها تغییر ناپذیرند، آیا داده‌ها نسخه‌بندی شده‌اند، آیا محیط منجمد شده است، آیا آزمایش‌ها ردیابی می‌شوند؟ ستون‌های از دست رفته را برطرف کنید و ثابت کنید که می‌توانید همان اجرا را دو بار اجرا کنید و همان نتیجه را بگیرید. سپس جریان پایان به انتها پروژه (10 توقف) را در یک صفحه خروجی بگیرید و در هر توقف علامت «جایی که تصمیم انسان است» را علامت بزنید. در نهایت، یک پیش نویس مستند فنی کوتاه بنویسید.

چک لیست

• [ ] همه دانه های تصادفی ثابت شدند.
• [ ] نسخه/هش داده با هر آزمایش ثبت می شود.
• [ ] وابستگی ها به نسخه های محکم (پین/کانتینر) منجمد می شوند.
• [ ] هر آزمایش به طور خودکار نظارت می شود (کد+داده+تنظیم+متریک).
• [ ] وقتی همان اجرا را تکرار می کنم، همان نتیجه را می گیرم.
• [ ] من تأیید و مستند کردم که تصمیمات حیاتی در جریان انتها به انتها توسط انسان ها گرفته می شود.

امتحان ماژول

1. به عنوان یک مهندس ML، بهترین رویکرد هنگام قرار دادن هوش مصنوعی در گردش کار چیست؟

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

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

2. چرا اعتبار سنجی طرحواره در ابتدای خط لوله داده قرار می گیرد؟

• الف) زیرا مستقیماً دقت مدل را افزایش می دهد
• ب) زیرا نسخه سازی داده ها را غیر ضروری می کند
• ج) زیرا داده های خراب را در اولین و ارزان ترین نقطه می گیرد و از نشت آن در مراحل بعدی جلوگیری می کند.
• د) زیرا نیاز به برچسب زدن را بی نیاز می کند

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

3. هنگام تقسیم داده ها به آموزش و آزمایش در مسئله ای که شامل زمان (سری های زمانی) می شود، رویکرد صحیح چیست؟

• الف) استفاده از تقسیم تصادفی زیرا همیشه منصفانه ترین روش است
• ب) استفاده از تقسیم زمانی: با آموزش با گذشته و آزمایش در آینده از نشت جلوگیری کنید.
• ج) استفاده از تمام داده ها به عنوان آموزش و آزمایش
• د) گنجاندن داده های آزمون در پارامترهای مقیاس بندی قبل از آموزش

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

4. چرا دقت در مدل کشف تقلب با نرخ کلاس مثبت 1.5% گمراه کننده است؟

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

توضیح: در داده‌های نامتعادل، حتی یک مدل پایه که می‌گوید «همه چیز را منفی بنامید» حدود 98.5 درصد دقت دارد، اما حتی یک تقلب نمی‌گیرد. بنابراین، در طبقه بندی نامتعادل، به جای دقت، از دقت، یادآوری، F1 یا PR-AUC استفاده می شود و هر متریک بر اساس یک مدل پایه تفسیر می شود.

5. چرا هنگام صحبت در مورد متریک یک مدل، مقایسه خط پایه ضروری است؟

• الف) زیرا مدل پایه همیشه بهتر از مدل واقعی است
• ب) زیرا مشخص است که آیا یک متریک تنها در مقایسه با یک مدل پایه ساده معنادار است یا نه
• ج) زیرا مدل پایه اعتبارسنجی متقاطع را غیر ضروری می کند
• د) زیرا مدل پایه قانوناً در هر گزارشی الزامی است

توضیح: یک معیار به خودی خود خوب یا بد نیست. طبق یک مدل اولیه خوب یا بد است. جمله "85% صحیح" به معنای تقریباً بی ارزش است اگر مدل پایه قبلاً 84٪ داشته باشد و اگر 50٪ باشد عالی است. بدون لنگر مقایسه، متریک بی معنی است.

6. مهمترین عنصر امنیتی که باید در دستور تولید سیستم RAG (Retrieval-Augmented Generation) گنجانده شود، کدام است؟

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

توضیح: تنها مهم ترین دستور RAG این است که به مدل بگویید فقط به منبع داده شده تکیه کند و اگر اطلاعات در منبع نیست، بگویید "نمی دانم" و منبع را بدون ساختن ذکر کنید. بدون این سه گانه، مدل ممکن است زمینه را نادیده بگیرد و توهم ایجاد کند و پاسخ غیرقابل تایید شود.

7. یک سیستم RAG پاسخ های نادرست می دهد. بهترین مکان برای شروع تشخیص کجاست؟

• الف) ابتدا اندازه گیری واکشی (Recall@K): آیا قطعه صحیح می رسد؟ ✔
• ب) فورا مدل را با مدل بزرگتر جایگزین کنید
• ج) دستور را به طور تصادفی تغییر دهید و به تلاش ادامه دهید
• د) جاسازی تمام اسناد در مدل با تنظیم دقیق

توضیح: ضعیف ترین حلقه RAG معمولا واکشی است نه تولید. اگر قطعه صحیح هرگز آورده نشود، مدل نمی تواند آن اطلاعات را تولید کند، مهم نیست که چقدر درخواست بهبود یافته است. بنابراین، ابتدا Recall@K اندازه گیری می شود تا ببینیم آیا قسمت صحیح وارد شده است یا خیر. اگر واکشی خوب باشد، تولید و سریع بررسی می شود.

8. هنگام دادن ابزار به یک عامل، چه اقداماتی باید پشت سر تایید انسان قرار گیرد؟

• الف) هیچ کدام؛ عامل باید بتواند هر عملی را به طور مستقل انجام دهد
• ب) فقط اعمال برگشت پذیر مانند خواندن و جستجوی داده ها
• ج) اقدامات برگشت ناپذیر یا با تاثیر زیاد مانند انتقال وجه، حذف، ارسال ✔
• د) اقداماتی که فقط شامل محاسبات است

توضیحات: اقدامات بر اساس سطح ریسک از هم جدا می شوند. کارهای قابل بازیابی مانند خواندن، جستجو، محاسبه و تولید پیش نویس ها را می توان به طور مستقل انجام داد. با این حال، اقدامات غیرقابل برگشت یا با تأثیر بالا مانند انتقال پول، ارسال ایمیل، حذف داده‌ها، ثبت سفارش و غیره نیاز به تأیید انسانی دارد. هر اقدام غیر قابل فسخ باید منوط به رضایت باشد.

9. بهترین رویکرد طراحی در برابر خطر تزریق سریع غیر مستقیم چیست؟

• الف) کافی است یک جمله "نادیده گرفتن دستورالعمل های بد" را به اعلان سیستم اضافه کنید
• ب) با تکیه بر دستورالعمل های موجود در محتوای خارجی به مدل اختیار بیشتری بدهید
• ج) عدم رعایت احتیاط زیرا تزریق غیر قابل پیشگیری است
• د) جداسازی محتوای خارجی به عنوان داده های غیرقابل اعتماد و ایجاد دفاع لایه ای با حداقل مجوز، تایید و کنترل خروجی ✔

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

10. تمایز اصلی هنگام تصمیم گیری در مورد اینکه آیا یک مشکل باید با تنظیم دقیق یا RAG حل شود چیست؟

• الف) مشکلات اطلاعاتی با RAG بهتر حل می شوند، مشکلات رفتاری/قالبی با تنظیم دقیق بهتر حل می شوند ✔
• ب) هر مشکلی همیشه باید با تنظیم دقیق حل شود
• ج) RAG فقط برای تولید کد استفاده می شود، تنظیم دقیق فقط برای ترجمه استفاده می شود
• د) تنظیم دقیق همیشه می تواند ارزان تر و سریعتر از RAG به روز شود

توضیح: تنظیم دقیق در آموزش مدل اطلاعات جدید ضعیف و مخاطره آمیز است. اما در آموزش رفتار، قالب، لحن و سبک قدرتمند است. «شرکت مدل اطلاعات ما را نمی‌داند» یک مشکل اطلاعاتی است و متعلق به RAG است. «اجازه دهید مدل همیشه در قالب دقیق ما خروجی داشته باشد» یک مشکل رفتاری و کاندیدای تنظیم دقیق است. علاوه بر این، باید قبل از تنظیم دقیق، عکس‌های سریع و چندگانه مصرف کرد.

11. کدام یک برای استقرار ایمن هنگام تولید یک مدل جدید اجباری است؟

• الف) اگر مدل در تست خوب است، آن را مستقیماً به ترافیک 100٪ باز کنید
• ب) به هیچ وجه پس از استقرار مانیتورینگ را راه اندازی نمی کند
• ج) استقرار مرحله‌ای (سایه/قناری) و طرح بازگشت از پیش آزمایش‌شده ✔
• د) انتشار مدل حتی در صورت عدم رعایت آستانه ارزیابی

توضیح: باز کردن مدل جدید به طور مستقیم برای همه ترافیک خطرناک است. اگر اشتباه باشد، همه تحت تأثیر قرار می گیرند. نکته درست این است که توزیع تدریجی است (سایه، قناری) و هر توزیعی دارای یک طرح برگشت آزمایش شده است. توزیع بدون طرح clawback کامل نمی شود. توانایی بازگشت به نسخه قبلی در عرض چند دقیقه از کاربر محافظت می کند زمانی که مدل به طور غیر منتظره در تولید رفتار می کند.

12. چگونه یک مدل ML می تواند در تولید "بی صدا" شکست بخورد و راه حل آن چیست؟

• الف) مدل فرو می ریزد. گزارش های سرور این را نشان می دهد
• ب) با ایجاد پیش‌بینی‌های اشتباه بدون اشتباه؛ ✔ نظارت لایه ای عملیاتی، ورودی و خروجی را ضبط می کند
• ج) مدل هرگز نمی تواند بی سر و صدا شکست بخورد، همیشه زنگ خطر است
• د) فقط نظارت بر تأخیر کافی است تا هر گونه تخریب را مشاهده کنید

توضیح: مدل می‌تواند به سادگی با تولید پیش‌بینی‌های نادرست بدون خرابی یا دادن خطا شکست بخورد. دلیل اصلی این امر رانش داده و رانش مفهومی است. فقط نظارت بر معیارهای عملیاتی (تأخیر، نرخ خطا) کافی نیست. توزیع ورودی و توزیع خروجی/پیش بینی نیز باید نظارت شود. در صورت تاخیر در نتیجه واقعی، رانش ورودی هشدار اولیه می دهد.

13. هنگام استفاده از LLM-as-judge برای ارزیابی سیستم LLM چه اصل ضروری است؟

• الف) داور LLM همیشه درست است، تأیید انسانی غیر ضروری است
• ب) داور باید فقط بر اساس طول پاسخ تصمیم بگیرد.
• ج) کنترل های مبتنی بر قوانین و ارزیابی انسانی باید به طور کامل در هنگام استفاده از داوران کنار گذاشته شوند
• د) نمرات قاضی باید با نمونه ای با برچسب انسانی کالیبره شود و سوگیری آنها قبل از اینکه بتوان به آنها اعتماد کرد سنجیده شود.

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

14. چرا نگاه به دقت کلی هنگام ارزیابی سوگیری مدل ناکافی است؟

• الف) دقت کلی کافی است زیرا همیشه عملکرد بدترین گروه را منعکس می کند
• ب) دقت کلی به تنهایی کافی نیست زیرا می تواند تفاوت سیستماتیک (تبعیض پنهان) بین زیر گروه ها را پنهان کند.
• ج) زیرا دقت معیاری است که ربطی به سوگیری ندارد
• د) سوگیری فقط از مدل می آید و ربطی به داده ها ندارد.

توضیح: دقت کلی ممکن است تفاوت های سیستماتیک بین زیر گروه ها را پنهان کند. به عنوان مثال، در حالی که دقت کلی 88٪ است، یادآوری ممکن است 91٪ در یک گروه و 67٪ در گروه دیگر باشد. مدل به طور سیستماتیک آن گروه را از دست می دهد. بنابراین، مدل باید بر اساس زیر گروه‌ها (جمعیت‌شناسی/بخش) ارزیابی شود و اینکه کدام تعریف از عدالت باید در اولویت قرار گیرد، باید با ذینفعان تصمیم‌گیری شود.

15. چه چهار چیز باید با هم ثابت شوند تا یک نتیجه ML قابل تکرار باشد؟

• الف) فقط نام مدل، اندازه، قیمت و تاریخ عرضه
• ب) فقط برند GPU و سرعت اینترنت
• ج) فقط نمره دقت نهایی مدل. بقیه را می توان در حافظه نگه داشت
• د) دانه تصادفی، نسخه داده، محیط (نسخه های وابستگی) و ردیابی آزمایش ✔

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