Възпроизводимост и проектът от край до край: Комбиниране на всичко

Печалби:

• Възможност за осигуряване на възпроизводимост с четири стълба (фиксиране на семена, версия на данни, замразяване на медии, наблюдение на експерименти) и получаване на същия резултат при повтаряне на същия цикъл
• Възможност за комбиниране на всички спирки на модула (метрики, данни, модел, 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. Възпроизводимост: Зародиш, версия на данните, медия и проследяване на експеримент по цялата верига (този модул).

В този поток AI е ускорител и генератор на чертежи при всяко спиране; но изборът на показатели, решенията за данни, приоритизирането на справедливостта, прагът за внедряване и одобрението на изданието – критичните решения остават на човека. Това е същността на модула.

Документация: бъдещето ще ви благодари

Един добър ML проект документира себе си. Като минимум трябва да се напише следното: критерии за проблем и успех, източник на данни и версия, избор на модел и обосновки, резултати от оценка (включително подгрупи), известни ограничения и рискове, процедура за внедряване и извличане, план за мониторинг. Този документ е най-добрият приятел на човека (може би сте вие), който се връща в проекта след шест месеца.

три мини калъфа

Случай 1 - Загубен резултат. Инженер обучи страхотен модел, но не поправи семената и не запази версията на данните. Когато той напусна работата, никой не можеше да възпроизведе този резултат; моделът се превърна в "легенда на черната кутия" и в крайна сметка беше построен от нулата. Седмици бяха пропилени. Урок: невъзпроизводим резултат е несъществуващ резултат.

Случай 2 - Колапс на околната среда. Един екип не беше коригирал зависимостите. Когато библиотека се актуализира автоматично, изходните данни на модела се променят безшумно и производството е прекъснато. Отне дни да открият проблема. Когато зависимостите бяха замразени и контейнеризирани с окончателните версии, проблемът не се появи отново. Урок: замразете околната среда.

Случай 3 - Силата на наблюдението. Екип автоматично наблюдава всеки експеримент. Три месеца по-късно, по време на регулаторен одит, те отговориха на въпроса "с какви данни, с какви настройки, какво представяне получи в кои групи?" с пълен запис в рамките на минути. Проверката мина гладко. Поука: мониторингът е инструмент за съответствие, а не само инженерен.

Копируеми шаблони

Направете проверка за възпроизводимост за този ML проект.- Фиксирани ли са всички семена на произволност (разделяне, инициализиране, разбъркване)?- Версионирани ли са данните?- Зависимостите замразени ли са до точни версии?- Проследява ли се всеки експеримент (извършване на код, данни, хиперпараметър, показател)? Напишете конкретни стъпки как да го поправите за всяка липсваща колона. Структура на проекта: [описание]

Създайте скелет на план за този цялостен ML проект. Проблем: [описание] Покрийте следните спирки и маркирайте къде е ЧОВЕШКОТО решение на всяка спирка: проблем/метрика, конвейер, модел, (RAG/агент/фина настройка?), оценка, справедливост, сигурност, разпространение, мониторинг, възпроизводимост. Напишете основния риск и стъпката за проверка за всяко спиране.

Изгответе шаблон за техническа документация за този проект. Раздели: проблем + критерии за успех, данни (източник + версия), избор на модел + обосновка, оценка (включително подгрупи), известни ограничения + рискове, внедряване + връщане назад, план за мониторинг. Задайте полетата за попълване за всеки раздел като въпроси.

Проверете моята настройка за наблюдение на експеримента: Записва ли се автоматично при всяко изпълнение: git commit, версия/хеш на данните, всички хиперпараметри, всички показатели, среда (версии на библиотека)? Получавам ли същия резултат, когато изпълня същото изпълнение отново? Настройка: [описание]. Избройте недостатъците и корекцията.

Таблица с колони за възпроизводимост

колона

Какво е фиксирано

Пример за превозно средство

произволност

всички семена

настройка на семена

данни

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

DVC

среда

Библиотечни версии

ПИН изисквания, Docker

Мониторинг

Код+данни+настройка+метрика

MLflow, W&B

Често срещани грешки

• Не поправя семето. Резултатът не може да се повтори.
• Версията на данните не се запазва. — С какви данни? остава без отговор.
• Не замразяващи зависимости. Една актуализация мълчаливо ще развали всичко.
• Оставяне на експериментите на паметта. Две седмици по-късно нищо не се помни.
• Оставяне на критичните решения на изкуствения интелект. Метриките, справедливостта и решенията за разпределение трябва да останат при хората.
• Отлагане на документация. Бъдещият отбор (и вие) плащате цената.

В обобщение

Възпроизводимостта е подписът на сериозното ML инженерство: невъзпроизводимият резултат е недоказуемо твърдение. Предлага се с четири колони — коригиране на произволността, данни за версията, среда за замразяване, проследяване на всеки експеримент. Проектът от край до край съчетава всички спирки на този модул (метрика, данни, модел, LLM компоненти, оценка, справедливост, сигурност, разпространение, мониторинг) във взаимосвързана верига; Изкуственият интелект е ускорител при всяко спиране, но критичните решения остават за човека. Документирайте всичко — за бъдещ екип и одити. Тази дисциплина е рамката, която поддържа всичко, което научавате през целия модул.

Задача за приложение

Проверете ML проект спрямо четири стълба на възпроизводимост: семената неизменни ли са, данните имат ли версии, замразена ли е средата, проследяват ли се експериментите? Поправете всички липсващи колони и докажете, че можете да стартирате едно и също изпълнение два пъти и да получите същия резултат. След това изведете потока от край до край на проекта (10 спирки) на една страница и маркирайте „къде е човешкото решение“ на всяка спирка. Накрая напишете кратък проект на техническа документация.

контролен списък

• [ ] Всички семена на произволност са коригирани.
• [ ] Версия/хеш на данните се записва с всеки експеримент.
• [ ] Зависимостите са замразени до твърди версии (пин/контейнер).
• [ ] Всеки експеримент се наблюдава автоматично (код+данни+настройка+метрика).
• [ ] Когато повторя същото изпълнение, получавам същия резултат.
• [ ] Проверих и документирах, че критичните решения в потока от край до край се вземат от хора.

Изпит по модул

1. Като ML инженер, какъв е най-добрият подход при позициониране на изкуствения интелект в работния процес?

• A) AI е ускорител в нискорискови бизнеси; Критични решения като показатели, данни и производство остават валидирани и оставени на човека ✔
• B) Докато резултатите от AI изглеждат добре, няма нужда от проверка
• В) Оставянето на решението за пускане на модела в производство на изкуствения интелект спестява време.
• Г) Изкуственият интелект е полезен само за писане на текст, няма нищо общо с данни и работа с модели

Описание: AI е мощен ускорител за задачи с нисък риск, които лесно се проверяват, като код, обобщени данни и документи; Въпреки това, отговорността за решенията, засягащи парите, поверителността и правната отговорност, като избор на показатели, кои данни отиват в обучение и пускането на модела в производство, се носи от квалифицирания инженер и екип. Всеки изход не трябва да се използва без проверка.

2. Защо валидирането на схемата се поставя в началото на конвейер за данни?

• А) Защото директно повишава точността на модела
• Б) Защото прави ненужно управлението на версии на данни
• C) Защото улавя повредени данни в най-ранния и най-евтиния момент и предотвратява изтичането им в следващите стъпки ✔
• Г) Защото елиминира необходимостта от етикетиране

Обяснение: Колкото по-рано се уловят повредени данни, толкова по-евтино е да се коригират. Проверката на схемата предотвратява безшумното изтичане на повредени данни в обучението или производството чрез отхвърляне на данни извън очаквания тип и диапазон в началото на реда (напр. промяна на цената 100x с промяна на единица); Същата грешка, уловена в производството, е в пъти по-скъпа.

3. Какъв е правилният подход при разделяне на данните на обучение и тестване в проблем, включващ време (времеви серии)?

• A) Използване на произволно разделяне, защото винаги е най-справедливият метод
• B) Използване на временно разделяне: предотвратяване на изтичане чрез обучение с миналото и тестване в бъдещето ✔
• C) Използване на всички данни както за обучение, така и за тестване
• D) Включване на тестови данни в параметри за мащабиране преди обучение

Обяснение: Случайното разделяне на времевите серии дава на модела предимство за „виждане в бъдещето“, което никога няма да се случи в производството и изкуствено завишава показателите (времево изтичане). Правилното е времевото разделение: тренирайте с миналото, тествайте в бъдещето. Това измерва действителната производителност, която го поддържа в производство.

4. Защо точността е подвеждаща в модел за откриване на измами с положителен класов процент от 1,5%?

• A) Тъй като точността винаги е ниска при небалансирани данни
• Б) Тъй като точността може да се използва само при регресионни проблеми
• C) Тъй като изчисляването на точността изисква много процесорна мощност
• Г) Дори нищожен модел, който предвижда класа на мнозинството, може да бъде много точен, като по този начин прикрива истинския успех ✔

Обяснение: При небалансирани данни дори основен модел, който казва „наречете всичко отрицателно“, получава около 98,5% точност, но няма да улови нито една измама. Следователно при небалансирана класификация се използват прецизност, припомняне, F1 или PR-AUC вместо точност и всеки показател се интерпретира според базов модел.

5. Защо базовото сравнение е важно, когато говорим за показател на модел?

• A) Защото базовият модел винаги е по-добър от реалния модел
• B) Тъй като е ясно дали даден показател е значим или не само когато се сравни с прост базов модел ✔
• В) Тъй като базовият модел прави кръстосаното валидиране ненужно
• Г) Тъй като основният модел е законово задължителен във всеки отчет

Обяснение: Един показател не е добър или лош сам по себе си; Добър или лош е според базов модел. Изречението „85% правилно“ означава почти безполезно, ако базовият модел вече получава 84%, и перфектно, ако получава 50%. Без опорна точка за сравнение показателят е безсмислен.

6. Кой е най-критичният защитен елемент, който трябва да бъде включен в подканата за производство на системата RAG (Retrieval-Augmented Generation)?

• A) Инструкция да разчитате само на посочения източник, да кажете „Не знам“, ако източникът не съществува, и да цитирате източника ✔
• B) Да кажете на модела да даде възможно най-дълги и креативни отговори
• В) Моделът дава приоритет на собствените си образователни знания пред ресурсите
• Г) Изпълнете всички инструкции в документите, въведени като команди

Обяснение: Единствената най-важна инструкция на RAG е да кажете на модела да разчита само на дадения източник и ако информацията не е в източника, кажете „не знам“ и цитирайте източника, без да го измисляте. Без тази триада моделът може да пренебрегне контекста и да предизвика халюцинации, а отговорът да стане непроверим.

7. RAG система дава неверни отговори. Къде е най-доброто място за започване на диагностика?

• A) Първо измерване на извличането (Recall@K): правилната част пристига ли някога? ✔
• Б) Незабавно сменете модела с по-голям
• C) Променете подканата произволно и продължете да опитвате
• D) Вграждане на всички документи в модела с фина настройка

Обяснение: Най-слабото звено на RAG обикновено е извличането, а не производството. Ако правилната част никога не бъде предоставена, моделът не може да произведе тази информация, без значение колко е подобрена подканата. Следователно, първо се измерва Recall@K, за да се види дали е пристигнала правилната част; Ако извличането е добро, тогава производството и подканата се проверяват.

8. Какви действия трябва да бъдат поставени зад одобрението на човека, когато давате инструмент на агент?

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

Описание: Действията са разделени по ниво на риск. Възстановими задачи като четене, търсене, изчисляване и генериране на чернови могат да се извършват автономно; Въпреки това, необратими или силно въздействащи действия като прехвърляне на пари, изпращане на имейли, изтриване на данни, пускане на поръчки и т.н. изискват одобрение от човек. Всяко неотменимо действие трябва да бъде предмет на съгласие.

9. Какъв е най-добрият проектен подход срещу риска от индиректно незабавно инжектиране?

• A) Достатъчно е да добавите едно-единствено изречение „игнорирайте лоши инструкции“ към подканата на системата
• B) Дайте повече авторитет на модела, като разчитате на инструкции във външно съдържание
• В) Не се вземат никакви предпазни мерки, тъй като инжектирането е непредотвратимо
• D) Изолиране на външно съдържание като ненадеждни данни и установяване на слоеста защита с минимално разрешение, одобрение и контрол на изхода ✔

Описание: Външно съдържание, обработвано от агента или RAG, като например уеб страница, документ, имейл и т.н., е ненадеждна информация и може да съдържа секретни инструкции. Правилният подход е многопластова защита: изолиране на външно съдържание като „данни, а не команди“ с ясни разделители, прилагане на минимално разрешение, обвързване на необратими действия с одобрението на човека и одит на изхода. Един ред инструкции не е достатъчен.

10. Каква е основната разлика, когато решавате дали даден проблем трябва да бъде разрешен с фина настройка или RAG?

• A) Проблемите с информацията се решават по-добре с RAG, проблемите с поведението/формата се решават по-добре с фина настройка ✔
• B) Всеки проблем винаги трябва да се решава чрез фина настройка
• C) RAG се използва само за генериране на код, фината настройка се използва само за превод
• Г) Фината настройка винаги може да се актуализира по-евтино и по-бързо от RAG

Обяснение: Фината настройка е слаба и рискована при преподаване на нова информация на модела; но е мощен в преподаването на поведение, формат, тон и стил. „Моделната компания не знае нашите данни“ е информационен проблем и принадлежи на RAG. „Нека моделът винаги извежда в нашия стриктен формат“ е поведенчески проблем и е кандидат за фина настройка. Освен това трябва да се използват бързи и няколко снимки преди фина настройка.

11. Кое е задължително за безопасно внедряване при пускане на нов модел в производство?

• A) Ако моделът е добър при тестване, отворете го директно на 100% трафик
• B) Изобщо не е настроен мониторинг след внедряването
• C) Поетапно внедряване (shadow/canary) и предварително тестван план за връщане назад ✔
• Г) Публикуване на модела, дори ако прагът за оценка не е достигнат

Обяснение: отварянето на новия модел директно към целия трафик е рисковано; Ако не е наред, всички са засегнати. Правилното е, че това е постепенно разпределение (сянка, канарче) и всяко разпределение има тестван план за връщане назад. Разпределението не е пълно без план за връщане на средства; Възможността за връщане към предишната версия в рамките на минути защитава потребителя, когато моделът се държи неочаквано в производството.

12. Как един ML модел може да се провали „безшумно“ в производството и какъв е начинът да се хване това?

• А) Моделът се разпада; регистрационните файлове на сървъра показват това
• B) Чрез създаване на грешни прогнози без допускане на грешки; ✔ Той улавя оперативен, входен и изходен мониторинг на слоеве
• C) Моделът никога не може да се провали тихо, винаги аларма
• Г) Самото наблюдение на латентността е достатъчно, за да се засече всяко влошаване

Обяснение: Моделът може да се провали просто като произведе неправилни прогнози, без да се срине или да даде грешки; Основната причина за това е дрейфът на данните и концептуалният дрейф. Самото наблюдение на оперативните показатели (закъснение, процент грешки) не е достатъчно; Разпределението на входа и разпределението на изхода/прогнозата също трябва да се наблюдават. Дрейфът на входа дава ранно предупреждение, ако действителният резултат се забави.

13. Какъв принцип е от съществено значение при използване на LLM-as-judge за оценка на LLM система?

• A) LLM-реферът винаги е коректен, не е необходима човешка проверка
• B) Реферът трябва да вземе решение само въз основа на дължината на отговора.
• В) Базираните на правила контроли и човешката оценка трябва да бъдат напълно отхвърлени, когато се използват рефери
• D) Оценките на съдиите трябва да бъдат калибрирани с проба, маркирана от хора, и техните отклонения да бъдат измерени, преди да им се вярва ✔

Описание: LLM-референт също е модел; То може да бъде халюцинаторно, пристрастно (предпочитащо дълги, уверени отговори) и непоследователно. Следователно оценките на реферите трябва да бъдат калибрирани с проба, маркирана от човек, и системното им отклонение трябва да бъде измерено, преди да се вземе решение за производство. Един непроверен съдия дава фалшива увереност.

14. Защо разглеждането на общата точност е неадекватно, когато се оценява пристрастието на модела?

• A) Цялостната точност е достатъчна, защото винаги отразява представянето на най-лошата група
• B) Цялостната точност сама по себе си е недостатъчна, тъй като може да замъгли систематичната разлика (скрита дискриминация) между подгрупите ✔
• В) Защото точността е показател, който няма нищо общо с пристрастията
• Г) Отклонението идва само от модела и няма нищо общо с данните.

Обяснение: Цялостната точност може да прикрие систематичните разлики между подгрупите. Например, докато общата точност е 88%, припомнянето може да бъде 91% в една група и 67% в друга група; Моделът систематично пропуска тази група. Следователно моделът трябва да бъде оценен въз основа на подгрупи (демографски данни/сегмент) и кое определение за правосъдие трябва да бъде приоритетно, трябва да бъде решено със заинтересованите страни.

15. Кои четири неща трябва да бъдат фиксирани заедно, за да може резултатът от машинното обучение да бъде възпроизводим?

• A) Само име на модела, размер, цена и дата на пускане на пазара
• B) Само марка GPU и интернет скорост
• C) Само крайната оценка на точността на модела; останалото може да се запази в паметта
• D) Произволно начало, версия на данните, среда (версии на зависимост) и проследяване на експерименти ✔

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