Відтворюваність і наскрізний проект: поєднання всього

Прибуток:

• Можливість гарантувати відтворюваність за чотирма основними принципами (фіксація вихідного коду, версії даних, заморожування носія, моніторинг експерименту) і отримувати той самий результат при повторенні того самого циклу
• Можливість об’єднати всі зупинки модуля (метрики, дані, модель, компоненти LLM, оцінка, справедливість, безпека, розподіл, моніторинг) у наскрізний ланцюжок
• Можливість перевіряти, чи критично важливе рішення залишається за людиною під час кожної зупинки, і документувати проект у спосіб, який можна перевірити

Найпідступніший збій проекту ML – це не збій; «Не отримати той самий результат знову». Якщо ви не можете сьогодні відтворити оцінку моделі, яку ви запустили у виробництво три місяці тому, ви насправді не контролюєте цю модель. У цьому заключному розділі ми поглиблюємо відтворюваність: здатність надійно отримувати той самий результат з тими самими вхідними даними та об’єднати весь модуль у наскрізну проектну дисципліну.

Чому відтворюваність складна

У звичайному програмному забезпеченні той самий код дає однаковий результат. У ML є багато інших змінних, які визначають результат:

• Випадковість: перетасування даних, ініціалізація ваги, розділення даних — все залежить від випадковості.
• Дані: той самий код створює різні моделі з різними версіями даних.
• Середовище: версії бібліотеки, обладнання (CPU/GPU), навіть операційна система можуть змінити результат.
• Прихований випадок: незбережений гіперпараметр, етап попередньої обробки вручну, виділення без поміток.

Відтворюваність — це не «приємно мати», а науковий та інженерний імператив. Результат, який не можна відтворити, є твердженням, яке неможливо довести.

Чотири стовпи відтворюваності

1. Виправити випадковість. Встановити всі випадкові початкові числа в одному місці: розділення даних, ініціалізація моделі, перетасування даних. Фіксоване насіння є основою гарантії «той самий результат, коли ви повторюєте той самий цикл».

2. Версія даних. Запишіть, з якою версією даних проводився кожен експеримент (версія даних у блоці 2). «Останні дані» розпливчасті; "версія даних v3, хеш abc123" є точним.

3. Заморозьте середовище. Закріпіть усі залежності до їхніх точних версій (наприклад, точних версій, таких як numpy==1.26.4 у requirements.txt, або зображення контейнера). «Остання версія» колись все зламає.

4. Відслідковувати все (відстеження експерименту). Автоматично зберігати для кожного експерименту: версію коду (git commit), версію даних, усі гіперпараметри, метрики та вихідні структури. Такі інструменти відстеження експериментів, як MLflow, Weights & Biases, роблять це систематично. Без реєстрації питання «яке налаштування було найкращим» залишається без відповіді.

Обережно: «Я згадаю пізніше» — найдорожча помилка. Через два тижні ви не згадаєте, яке насіння, які дані, який гіперпараметр використовували. Автоматичне відстеження усуває залежність від пам'яті.

Слабкий підхід / Сильний підхід

Слабкий: «Я знайшов найкращу модель, вона в зошиті, мені здається, її оцінка 89%».

Сильно: «Запустіть #147 в інструменті відстеження експерименту: git commit a3f9c, версія даних v3 (хеш abc123), початкове значення 42, усі зареєстровані гіперпараметри, тест PR-AUC 0,887. Коли я знову запускаю ту саму команду, я отримую той самий результат поетапно. Модель залежить від цього запуску в реєстрі».

Відмінність: у сильному підході результат базується не на пам’яті, а на фіксованому та контрольованому ланцюжку. Кожен може кожного разу досягати однакового результату.

Наскрізний проект: поєднання модуля

Тепер давайте об’єднаємо весь модуль в єдиний потік проекту. Справжня система ML проходить через ці зупинки, і кожна зупинка спирається на попередню:

1. Визначення проблеми: що ми вирішуємо, як виміряти успіх (розділ 3: правильна метрика, бізнес-контекст). Показник і порогове значення зрозумілі з самого початку.
2. Конвеєр даних: збір, перевірка, очищення, розділення без витоків, керування версіями (блок 2).
3. Розробка моделі: навчання, базове порівняння, перехресна перевірка, жорстке початкове значення (модуль 3 + цей блок).
4. Компоненти LLM (якщо застосовно): RAG (блок 4) та/або агенти (блок 5); доведення, якщо необхідно (блок 6).
5. Оцінка: кластер eval з граничними і безпековими випадками, багаторівневе оцінювання в системах LLM (блок 8).
6. Аудит справедливості та етики: Аналіз підгруп, картка моделі, можливість пояснення (розділ 10).
7. Аудит безпеки: швидке впровадження, конфіденційність, ланцюг поставок (блок 9).
8. Розповсюдження: Упаковка, поступовий розподіл, відкат, модельний реєстр (блок 7).
9. Моніторинг: трирівневий моніторинг, сигналізація дрейфу (блок 8).
10. Відтворюваність: відстеження вихідного коду, версії даних, середовища та експерименту по всьому ланцюжку (цей блок).

У цьому потоці ШІ є прискорювачем і генератором схем на кожній зупинці; але вибір показників, рішення щодо даних, визначення пріоритетів справедливості, поріг розгортання та схвалення випуску — важливі рішення залишаються за людиною. Це і є суть модуля.

Документи: майбутнє скаже Вам спасибі

Хороший проект ML документує себе. Як мінімум слід записати наступне: критерії проблеми та успіху, джерело та версія даних, вибір моделей та обґрунтування, результати оцінки (включаючи підгрупи), відомі обмеження та ризики, процедуру розгортання та пошуку, план моніторингу. Цей документ є найкращим другом людини (можливо, це ви), яка повертається до проекту через півроку.

три міні-чохла

Випадок 1 - Втрачений результат. Інженер підготував чудову модель, але він не виправив початковий код і не зберіг версію даних. Коли він залишив роботу, ніхто не міг відтворити цей результат; модель стала «легендою чорної скриньки» і зрештою була побудована з нуля. Тижні були витрачені даремно. Урок: невідтворюваний результат - це неіснуючий результат.

Випадок 2 - Колапс середовища. Одна команда не виправила залежності. Коли бібліотека оновлювалася автоматично, результати моделі мовчки змінювалися, а виробництво було перервано. Знадобилися дні, щоб знайти проблему. Коли залежності були заморожені та контейнеризовані з остаточними версіями, проблема більше не виникала. Урок: заморозити середовище.

Випадок 3 – Сила моніторингу. Команда автоматично відстежувала кожен експеримент. Через три місяці під час регуляторного аудиту вони відповіли на питання «з якими даними, з якими налаштуваннями, яку продуктивність він отримав у яких групах?» з повним записом протягом декількох хвилин. Перевірка пройшла гладко. Урок: моніторинг — це інструмент відповідності, а не лише інженерний.

Шаблони, які можна копіювати

Виконайте перевірку відтворюваності для цього проекту ML.– Чи виправлено всі початкові параметри випадковості (розділення, ініціалізація, перемішування)?– Чи версії даних?– Чи залежності заморожено до точних версій?– Чи відстежується кожен експеримент (фіксація коду, дані, гіперпараметр, метрика)? Напишіть конкретні кроки, як це виправити для кожного відсутнього стовпця. Структура проекту: [опис]

Створіть скелет плану для цього наскрізного проекту ML. Проблема: [опис] Охопіть наступні зупинки та позначте, де на кожній зупинці знаходиться рішення ЛЮДИНИ: проблема/метрика, конвеєр, модель, (RAG/агент/точне налаштування?), оцінка, справедливість, безпека, розподіл, моніторинг, відтворюваність. Напишіть основний ризик і етап перевірки для кожної зупинки.

Виготовити шаблон технічної документації для цього проекту. Розділи: проблема+критерії успіху, дані (джерело+версія), вибір моделі+обґрунтування, оцінка (включаючи підгрупи), відомі обмеження+ризики, розгортання+відкат, план моніторингу. Задайте поля для заповнення для кожного розділу як запитання.

Перевірте налаштування моніторингу експерименту: чи автоматично зберігається під час кожного запуску: git commit, версія/хеш даних, усі гіперпараметри, усі показники, середовище (версії бібліотеки)? Чи отримаю я той самий результат, коли повторю той самий запуск? Налаштування: [опис]. Перелічіть недоліки та виправлення.

Таблиця стовпців відтворюваності

колонка

Що виправлено

Приклад транспортного засобу

випадковість

все насіння

налаштування насіння

дані

Версія/хеш даних

DVC

середовище

Бібліотечні версії

PIN-код вимог, Docker

Моніторинг

Код+дані+параметр+метрика

MLflow, W&B

Поширені помилки

• Не фіксуючи насіння. Результат не можна повторити.
• Не зберігається версія даних. «З якими даними?» залишається без відповіді.
• Не заморожування залежностей. Оновлення мовчки все зламає.
• Залишення дослідів на пам'ять. Через два тижні нічого не згадується.
• Залишити критичні рішення штучному інтелекту. Рішення про показники, справедливість і розподіл повинні залишатися за людьми.
• Відкладення документації. Майбутня команда (і ви) платить ціну.

Підсумовуючи

Відтворюваність є ознакою серйозної інженерії ML: невідтворюваний результат є недоказовою заявою. Він містить чотири стовпці — виправити випадковість, дані версії, заморозити середовище, відстежувати кожен експеримент. Наскрізний проект поєднує всі зупинки цього модуля (метрика, дані, модель, компоненти LLM, оцінка, справедливість, безпека, розподіл, моніторинг) у взаємопов’язаний ланцюжок; Штучний інтелект є прискорювачем на кожній зупинці, але важливі рішення залишаються за людиною. Документуйте все — для майбутньої команди та аудитів. Ця дисципліна є основою, яка підтримує все, що ви вивчаєте протягом усього модуля.

Аплікаційне завдання

Перевірте проект ML за чотирма основними принципами відтворюваності: чи незмінні вихідні дані, чи версії даних, чи заморожене середовище, чи відстежуються експерименти? Виправте будь-які відсутні стовпці та доведіть, що ви можете виконати один і той самий запуск двічі й отримати той самий результат. Потім виведіть наскрізний потік проекту (10 зупинок) на одній сторінці та позначте «де людське рішення» на кожній зупинці. Нарешті, напишіть короткий проект технічної документації.

контрольний список

• [ ] Виправлено всі початкові числа випадковості.
• [ ] Версія/хеш даних записується з кожним експериментом.
• [ ] Залежності заморожені до фірмових версій (pin/контейнер).
• [ ] Кожен експеримент автоматично відстежується (код+дані+параметр+метрика).
• [ ] Коли я повторюю той самий запуск, я отримую той самий результат.
• [ ] Я підтвердив і задокументував, що критичні рішення в наскрізному потоці приймаються людьми.

Модульний екзамен

1. Який найкращий підхід для позиціонування штучного інтелекту в робочому процесі як для інженера ML?

• A) AI є прискорювачем у бізнесі з низьким рівнем ризику; Важливі рішення, як-от показники, дані та виробництво, залишаються перевіреними та залишаються на розсуд людини ✔
• B) Поки результати штучного інтелекту виглядають добре, перевірка не потрібна
• В) Залишення рішення про запуск моделі у виробництво штучному інтелекту економить час.
• D) Штучний інтелект корисний лише для написання тексту, він не має нічого спільного з даними та роботою з моделлю

Опис: штучний інтелект є потужним прискорювачем для завдань із низьким ризиком, які легко перевіряються, наприклад коду, дайджестів даних і документів; Однак відповідальність за рішення, що стосуються грошей, конфіденційності та юридичної відповідальності, як-от вибір показників, які дані йдуть на навчання та впровадження моделі у виробництво, лежить на кваліфікованому інженері та команді. Кожен вихід не слід використовувати без перевірки.

2. Чому перевірка схеми розміщується на початку конвеєра даних?

• A) Тому що це безпосередньо підвищує точність моделі
• B) Тому що це робить версії даних непотрібними
• C) Тому що він виявляє пошкоджені дані в найранішій і найдешевшій точці та запобігає їх витоку на наступних етапах ✔
• D) Оскільки це позбавляє від необхідності маркування

Пояснення: чим раніше буде виявлено пошкоджені дані, тим дешевше їх виправити. Перевірка схеми запобігає тихому витоку пошкоджених даних у навчання або виробництво, відхиляючи дані поза очікуваним типом і діапазоном на початку рядка (наприклад, зміна ціни в 100 разів із зміною одиниці); Та ж помилка, виявлена ​​на виробництві, коштує в рази дорожче.

3. Який правильний підхід до розподілу даних на навчальні та тестові в задачі, що включає час (часовий ряд)?

• A) Використання випадкового розподілу, оскільки це завжди найсправедливіший метод
• B) Використання тимчасового розщеплення: запобігайте витоку, тренуючись з минулим і тестуючи в майбутньому ✔
• C) Використання всіх даних як для навчання, так і для тестування
• D) Включення тестових даних у параметри шкалювання перед навчанням

Пояснення: випадкове поділ на часові ряди дає моделі перевагу «бачення майбутнього», яка ніколи не відбудеться у виробництві, і штучно завищує показники (часовий витік). Правильний – часовий поділ: тренуйтеся з минулим, перевіряйте в майбутньому. Це вимірює фактичну продуктивність, яка підтримує його у виробництві.

4. Чому точність вводить в оману модель виявлення шахрайства з позитивним показником класу 1,5%?

• A) Оскільки точність незбалансованих даних завжди низька
• B) Тому що точність можна використовувати лише для задач регресії
• C) Оскільки обчислення точності вимагає великої потужності обробки
• D) Навіть мізерна модель, яка передбачає клас більшості, може бути дуже точною, таким чином приховуючи справжній успіх ✔

Пояснення: на основі незбалансованих даних навіть базова модель, яка каже «називати все негативним», отримує приблизно 98,5% точності, але не вловить жодного шахрайства. Тому в незбалансованій класифікації замість точності використовуються прецизійність, відкликання, F1 або PR-AUC, і кожна метрика інтерпретується відповідно до базової моделі.

5. Чому базове порівняння є важливим, коли йдеться про метрику моделі?

• А) Оскільки базова модель завжди краща за справжню
• B) Тому що ясно, чи є метрика значущою чи ні, лише якщо порівнювати її з простою базовою моделлю ✔
• C) Оскільки базова модель робить перехресну перевірку непотрібною
• D) Тому що базова модель є обов’язковою для кожного звіту

Пояснення: метрика сама по собі не є хорошою чи поганою; Добре це чи погано в залежності від базової моделі. Речення «вірно на 85%» означає майже нічого не варте, якщо базова модель уже отримує 84%, і ідеальне, якщо вона отримує 50%. Без прив’язки порівняння метрика не має сенсу.

6. Який найважливіший елемент безпеки має бути включений у робочу підказку системи RAG (Retrieval-Augmented Generation)?

• A) Інструкція покладатися лише на надане джерело, сказати «Я не знаю», якщо джерело не існує, і цитувати джерело ✔
• B) Наказ моделі давати якомога довгі та творчі відповіді
• C) Модель надає пріоритет власним освітнім знанням над ресурсами
• D) Виконуйте всі інструкції в документах, наведених як команди

Пояснення: єдина найважливіша інструкція RAG полягає в тому, щоб наказати моделі покладатися лише на надане джерело, а якщо інформації немає в джерелі, сказати «Я не знаю» та цитувати джерело, не вигадуючи його. Без цієї тріади модель може ігнорувати контекст і викликати галюцинації, а відповідь стає неможливою перевірити.

7. Система RAG дає неправильні відповіді. З чого найкраще почати діагностику?

• A) Спочатку виміряйте вибірку (Recall@K): чи надходить правильний шматок? ✔
• B) Негайно замінити модель на більшу
• C) Змініть підказку випадковим чином і продовжуйте спроби
• D) Вбудовування всіх документів у модель з тонким налаштуванням

Пояснення: найслабшою ланкою RAG зазвичай є вибірка, а не виробництво. Якщо правильна частина ніколи не надається, модель не може видавати таку інформацію, незалежно від того, наскільки покращено підказку. Тому спочатку Recall@K вимірюється, щоб побачити, чи надійшла правильна деталь; Якщо вибірка хороша, перевіряються виробництво та підказка.

8. Які дії повинні бути схвалені людиною, коли ви передаєте інструмент агенту?

• А) жодного; Агент повинен мати можливість виконувати кожну дію автономно
• B) Тільки оборотні дії, такі як читання та пошук даних
• C) Незворотні або серйозні дії, такі як переказ грошей, видалення, надсилання ✔
• Г) Дії, що передбачають лише обчислення

Опис: Дії розділені за рівнем ризику. Відновлювані завдання, такі як читання, пошук, обчислення та створення чернеток, можна виконувати автономно; Однак незворотні або серйозні дії, такі як переказ грошей, надсилання електронних листів, видалення даних, розміщення замовлень тощо, потребують схвалення людини. Будь-яка невідклична дія має бути згодою.

9. Який найкращий проектний підхід проти ризику непрямого швидкого введення?

• А) Достатньо додати одне речення «ігнорувати погані інструкції» до системного підказки
• B) Надайте більше авторитету моделі, покладаючись на інструкції у зовнішньому вмісті
• C) Не вживає жодних запобіжних заходів, оскільки ін’єкцію неможливо запобігти
• D) Ізоляція зовнішнього вмісту як ненадійних даних і встановлення багатошарового захисту з мінімальною авторизацією, схваленням і контролем вихідних даних ✔

Опис. Зовнішній вміст, який обробляється агентом або RAG, як-от веб-сторінка, документ, електронна пошта тощо, є ненадійними даними та може містити секретні інструкції. Правильний підхід — багаторівневий захист: виділення зовнішнього вмісту як «даних, а не команд» із чіткими розділювачами, застосування мінімальної авторизації, зв’язування незворотних дій із схваленням людини та аудит результатів. Одного рядка інструкцій недостатньо.

10. Яка головна відмінність при вирішенні, чи проблему слід вирішувати за допомогою тонкого налаштування чи RAG?

• A) Проблеми з інформацією краще вирішуються за допомогою RAG, проблеми з поведінкою/форматом краще вирішуються за допомогою точного налаштування ✔
• B) Будь-яка проблема завжди повинна вирішуватися шляхом точного налаштування
• C) RAG використовується лише для генерації коду, точне налаштування використовується лише для перекладу
• D) Точне налаштування завжди можна оновити дешевше та швидше, ніж RAG

Пояснення: точне налаштування є слабким і ризикованим у навчанні моделі нової інформації; але є потужним у навчанні поведінки, формату, тону та стилю. «Модельна компанія не знає наших даних» є інформаційною проблемою та належить до RAG. «Нехай модель завжди виводить у нашому строгому форматі» є проблемою поведінки та кандидатом на тонке налаштування. Крім того, перед тонким налаштуванням слід робити швидкі та кілька знімків.

11. Що є обов’язковим для безпечного розгортання під час запуску нової моделі у виробництво?

• A) Якщо модель добре тестується, відкрийте її безпосередньо для 100% трафіку
• B) Відсутність налаштування моніторингу взагалі після розгортання
• C) Поетапне розгортання (shadow/canary) і попередньо перевірений план відкату ✔
• D) Публікація моделі, навіть якщо поріг оцінки не досягнуто

Пояснення: відкривати нову модель безпосередньо для всього трафіку ризиковано; Якщо це неправильно, це стосується всіх. Правильно те, що це поступовий розподіл (тінь, канарка), і кожен розподіл має перевірений план відкату. Розподіл не є повним без плану повернення; Можливість повернутися до попередньої версії за лічені хвилини захищає користувача від неочікуваної поведінки моделі під час виробництва.

12. Як модель ML може «тихо» вийти з ладу під час виробництва і як це вловити?

• А) Модель руйнується; журнали сервера показують це
• B) Виробляючи неправильні прогнози без помилок; ✔ Він фіксує оперативний, вхідний і вихідний моніторинг
• В) Модель ніколи не може відмовити тихо, завжди тривога
• D) Простого моніторингу затримки достатньо, щоб вловити будь-яке погіршення

Пояснення: модель може вийти з ладу, просто виробляючи неправильні прогнози без збоїв або помилок; Основною причиною цього є дрейф даних і концептуальний дрейф. Простого моніторингу операційних показників (затримки, частоти помилок) недостатньо; також слід контролювати розподіл вхідних даних і розподіл вихідних даних/прогнозів. Зміщення вхідних даних дає раннє попередження, якщо фактичний результат затримується.

13. Який принцип є важливим при використанні LLM-as-judge для оцінювання системи LLM?

• A) LLM-рефері завжди коректний, людська перевірка не потрібна
• B) Суддя повинен прийняти рішення лише на основі тривалості відповіді.
• C) Контроль, заснований на правилах, і людське оцінювання повинні бути повністю відкинуті, коли використовуються судді
• D) Оцінки суддів слід відкалібрувати за зразком, позначеним людиною, і виміряти їх упередженість, перш ніж їм можна довіряти ✔

Опис: LLM-рефері також є моделлю; Воно може бути галюцинаторним, упередженим (надавати перевагу довгим, упевненим відповідям) і непослідовним. Таким чином, оцінки рефері повинні бути відкалібровані за зразком, позначеним людиною, і їх систематичне зміщення має бути виміряно до прийняття рішення про виробництво. Неперевірений арбітр викликає помилкову впевненість.

14. Чому при оцінці упередженості моделі розглядати загальну точність є неадекватним?

• A) Загальна точність є достатньою, оскільки вона завжди відображає показники найгіршої групи
• B) Одна лише загальна точність є недостатньою, оскільки вона може приховати систематичну різницю (приховану дискримінацію) між підгрупами ✔
• В) Тому що точність – це показник, який не має нічого спільного з упередженістю
• D) Зсув походить лише від моделі і не має нічого спільного з даними.

Пояснення: загальна точність може приховувати систематичні відмінності між підгрупами. Наприклад, хоча загальна точність становить 88%, пригадування може становити 91% в одній групі та 67% в іншій групі; Модель систематично пропускає цю групу. Таким чином, модель слід оцінювати на основі підгруп (демографічних показників/сегменту), і разом із зацікавленими сторонами слід вирішити, яке визначення справедливості має бути пріоритетним.

15. Які чотири речі потрібно виправити разом, щоб результат ML був відтворюваним?

• A) Лише назва моделі, розмір, ціна та дата випуску
• B) Лише марка GPU та швидкість Інтернету
• C) Лише кінцева оцінка точності моделі; решту можна зберегти в пам'яті
• D) Відстеження вихідного коду випадковості, версії даних, середовища (версії залежностей) і експерименту ✔

Опис. Відтворюваність досягається завдяки чотирьом основним компонентам: виправленню початкових значень випадковості, версії даних (версія/хеш), заморожуванню середовища (точні версії/контейнер бібліотеки) і відстеження кожного експерименту (фіксація коду, дані, гіперпараметр, метрика). Без цього ланцюжка неможливо відтворити той самий результат; Невідтворюваний результат — це твердження, яке не можна довести.