Created by AIImproved by people
Riqli · living documents · updated continuously
Where AI knowledge meets human practice.
Share with friends
1. Общие положения
Настоящий документ определяет организационно-правовой статус, должностные обязанности, права, ответственность и квалификационные требования для должности «ML-инженер» (Machine Learning Engineer) в организации «General». Документ разработан на основе трудового законодательства, внутренних нормативных актов и корпоративных стандартов для обеспечения единого подхода к управлению процессами машинного обучения и искусственного интеллекта.
Документ распространяется на все проекты и задачи, связанные с разработкой, внедрением и эксплуатацией моделей машинного обучения и систем на их основе.
1.1. Основные термины и определения
В настоящем документе используются следующие термины и определения: ML-инженер — специалист, ответственный за разработку, обучение, валидацию и эксплуатацию моделей машинного обучения в составе продуктов компании. Бизнес-процесс — совокупность взаимосвязанных действий, направленных на получение измеримого результата (в контексте ML — это жизненный цикл модели). Жизненный цикл модели ML — последовательность этапов от сбора данных до мониторинга и деплоя, включая EDA, разработку, обучение, оценку и внедрение.
Для описания процессов используются нотации: BPMN (Business Process Model and Notation) для визуализации процедур, IDEF0 для функционального моделирования и EPC (Event-driven Process Chain) для описания логики событий. Сценарий работ — это детализированный план действий ML-инженера в рамках конкретной бизнес-задачи.
1.2. Правовая основа деятельности
Деятельность ML-инженера регулируется следующими нормативными и организационными документами: Трудовой кодекс РФ, Федеральный закон «О персональных данных» (№ 152-ФЗ), внутренний Регламент по работе с данными, Политика информационной безопасности, а также настоящая должностная инструкция. В части разработки и использования программного обеспечения, ML-инженер руководствуется Корпоративным стандартом разработки и Регламентом по управлению изменениями.
ML-инженер обязан соблюдать требования лицензионных соглашений используемого программного обеспечения (библиотеки, фреймворки, платформы), а также не разглашать конфиденциальную информацию, ставшую известной в ходе работы.
2. Цель должности и сфера ответственности
Основной целью деятельности ML-инженера является создание и поддержка надежных, воспроизводимых и масштабируемых решений на основе машинного обучения, которые приносят измеримую бизнес-ценность организации.
2.1. Миссия и стратегические задачи
Миссия ML-инженера — преобразовывать бизнес-задачи в технические требования к ML-моделям и обеспечивать их интеграцию в существующие продукты и сервисы. Стратегические задачи включают: снижение времени вывода моделей в промышленную эксплуатацию (Time-to-Market), обеспечение высокого качества прогнозов (Accuracy, Precision, Recall), сокращение технического долга в ML-коде и автоматизация рутинных операций в пайплайне обработки данных. Ожидаемый результат — создание надежных ML-сервисов с минимальным временем простоя и высокой точностью.
2.2. Ожидаемые результаты и KPI
Ключевые результаты деятельности ML-инженера включают: успешный вывод в продакшен как минимум 3 ML-моделей в год; достижение целевых метрик качества (например, Accuracy > 0.90, F1-Score > 0.85) для новых моделей; сокращение времени инференса модели до < 100 мс для онлайн-систем; снижение доли «технического долга» (технического дефицита) в ML-коде на 15% ежегодно; автоматизация этапов EDA и Feature Engineering для сокращения времени исследования данных на 20%.
Степень достижения этих результатов оценивается в рамках квартальных и годовых обзоров производительности.
3. Подчиненность и линии отчетности
Определены прямые, функциональные и матричные связи ML-инженера внутри организации «General».
3.1. Прямое подчинение и замещение
ML-инженер подчиняется непосредственно Руководителю направления ML / AI (Head of ML/AI). В случае временного отсутствия (отпуск, командировка, болезнь) права и обязанности ML-инженера передаются по распоряжению руководителя другому ML-инженеру или Team Lead’у. Замещение оформляется внутренним приказом.
3.2. Функциональные и матричные связи
В рамках выполнения проектных задач ML-инженер взаимодействует с другими подразделениями и ролями в матричной структуре: с продуктовыми менеджерами (для определения бизнес-требований); с инженерами по данным (Data Engineers) для построения и поддержки пайплайнов данных; с DevOps-инженерами и MLE-инженерами по инфраструктуре для деплоя и мониторинга; с бизнес-аналитиками для оценки экономического эффекта; с юристами и комплаенс-специалистами по вопросам соблюдения законодательства о персональных данных и этике ИИ.
Координация осуществляется на регулярных митингах (Daily Stand-ups, Sprint Planning, Retrospectives) и через инструменты управления проектами (Jira, Confluence).
4. Должностные обязанности
Раздел содержит полный перечень трудовых функций, выполнение которых обеспечивает достижение целей, указанных в разделе 2.
4.1. Участие в бизнес-анализе и сбор данных
ML-инженер обязан: участвовать в сборе данных из внутренних и внешних источников (базы данных, API, файловые хранилища, стриминговые системы); совместно с бизнес-аналитиками формулировать гипотезы и требования к данным; документировать источники данных, их структуру и периодичность обновления; оценивать пригодность данных для решения задачи (качество, полнота, репрезентативность).
- Разрабатывать запросы к базам данных (SQL) для выгрузки тренировочных и тестовых выборок.
- Обеспечивать соблюдение политик безопасности и конфиденциальности при работе с данными, включая деидентификацию персональных данных.
4.2. Проведение разведочного анализа данных (EDA)
Обязанности ML-инженера включают: проведение разведочного анализа данных (EDA) для выявления структуры, распределений, корреляций, выбросов и пропущенных значений в данных; визуализацию данных с использованием инструментов (Matplotlib, Seaborn, Plotly); формулировку статистических гипотез и их проверку; документирование выводов EDA в виде отчетов (Jupyter Notebook, Confluence).
- Применять методы статистического анализа для обоснования выбора признаков и архитектуры модели.
- Выявлять и устранять смещения (bias) в данных, которые могут привести к нечестным или неэтичным результатам модели.
4.3. Разработка признакового пространства (Feature Engineering)
Должностная обязанность предполагает: создание новых признаков на основе существующих данных для улучшения качества модели; применение методов трансформации (масштабирование, нормализация, логарифмирование) и кодирования категориальных переменных; использование методов понижения размерности (PCA, t-SNE) для улучшения интерпретируемости и производительности.
Обеспечение автоматизации разработки модели через создание воспроизводимых пайплайнов обработки признаков с использованием библиотек (Scikit-learn Pipelines, Featuretools).
4.4. Разработка и архитектура модели
Основные обязанности: выбор подходящей архитектуры модели на основе бизнес-задачи и EDA; реализация прототипов моделей с использованием фреймворков (Scikit-learn, XGBoost, LightGBM, PyTorch, TensorFlow); оптимизация гиперпараметров с использованием Grid Search, Random Search или Bayesian Optimization; документирование архитектурных решений и выбора гиперпараметров.
- Сравнение нескольких моделей (бенчмаркинг) по выбранным метрикам качества.
- Использование техник регуляризации и аугментации данных для борьбы с переобучением.
4.5. Обучение модели и оценка качества
ML-инженер обязан проводить обучение модели на подготовленных данных, используя стратегии кросс-валидации для получения надежной оценки качества. Оценка модели проводится на отложенной выборке с использованием метрик: Accuracy, Precision, Recall, F1-Score, ROC-AUC для классификации; MAE, MSE, RMSE, R² для регрессии; метрик ранжирования (NDCG@k) для рекомендательных систем.
- Анализировать ошибки модели (например, confusion matrix) для выявления слабых мест.
- Проводить A/B-тестирование новых моделей против текущего продакшен-решения.
4.6. Инструменты и технологии для разработки
В своей работе ML-инженер использует следующий стек технологий: языки программирования — Python (основной) и SQL; библиотеки — NumPy, Pandas, Scikit-learn, PyTorch, TensorFlow, XGBoost, LightGBM, Transformers (Hugging Face); среда разработки — Jupyter Notebook, VS Code, PyCharm; системы контроля версий — Git, GitLab; системы управления данными — Hadoop, Spark, DVC; инструменты для экспериментов — MLflow, Weights & Biases.
Данный список может дополняться и уточняться по мере появления новых технологических решений в организации.
4.7. Внедрение модели в промышленную эксплуатацию
Обязанности по этапу внедрения модели: контейнеризация модели с использованием Docker; настройка CI/CD пайплайнов для автоматической сборки и деплоя (GitLab CI, GitHub Actions, Jenkins); интеграция модели в сервисы компании через REST API (FastAPI, Flask) или gRPC; настройка мониторинга производительности модели в продакшене (метрики инференса, задержки, использование ресурсов); обеспечение возможности быстрого отката на предыдущую версию модели в случае ошибок.
- Разработка автоматизированных тестов для проверки модели на корректность работы.
- Организация каналов для сбора обратной связи и данных для дообучения модели.
4.8. Мониторинг и поддержка модели
В рамках мониторинга ML-инженер обязан: настроить дашборды для визуализации производительности модели (Grafana, Prometheus); отслеживать дрейф данных (data drift) и дрейф концепции (concept drift); настраивать алерты на критические отклонения метрик; проводить регулярные ретроспективы производительности и плановые переобучения моделей (периодичность определяется бизнес-требованиями).
Поддержка включает: обновление модели на новых данных; исправление багов и оптимизацию кода; реагирование на инциденты в соответствии с SLA (Service Level Agreement).
4.9. Документирование и отчетность
ML-инженер обязан вести следующую документацию: архитектурные документы на проектируемые системы (ADR — Architectural Decision Records); техническая документация по моделям (Model Cards); описания пайплайнов и скриптов обработки данных; инструкции по деплою и эксплуатации; отчеты по результатам экспериментов, включая сравнение моделей.
Отчетность еженедельно предоставляется руководителю в форме статус-отчета о ходе выполнения задач. По итогам месяца подготавливается отчет о достигнутых KPI и результатах экспериментов.
4.10. Управление проектами и командная работа
Участие в планировании спринтов, оценке задач в Story Points. Работа в распределенной команде с использованием инструментов совместной работы: Jira для управления задачами, Confluence для документации, Slack/MS Teams для коммуникации. Активное участие в код-ревью для повышения качества кода и обмена знаниями.
Предоставление консультаций и экспертной поддержки другим членам команды и смежным отделам по вопросам машинного обучения.
5. Права сотрудника
Раздел определяет полномочия ML-инженера, необходимые для эффективного выполнения возложенных на него обязанностей.
5.1. Право принятия решений
ML-инженер имеет право принимать технические решения в рамках своей компетенции, включая: выбор библиотек и фреймворков для решения задачи; выбор архитектуры модели и методов обучения; определение стратегии валидации и критериев остановки обучения. Все ключевые архитектурные решения должны быть согласованы с руководителем направления.
В случае необходимости привлечения дополнительных ресурсов (вычислительных мощностей, облачных сервисов) ML-инженер имеет право подавать запросы через установленные процедуры.
5.2. Доступ к информации и ресурсам
Для выполнения своих обязанностей ML-инженеру предоставляется доступ к: корпоративным хранилищам данных в соответствии с его уровнем доступа; внутренней документации, репозиториям кода, технологической документации; инструментам мониторинга, логирования и визуализации данных; облачным сервисам и вычислительным кластерам (AWS, GCP, Azure, Yandex Cloud), в зависимости от проекта.
Право доступа регулируется Политикой безопасности и может быть изменено в рамках процедуры управления доступом.
5.3. Право на обучение и развитие
ML-инженер имеет право на прохождение профессионального обучения, участие в конференциях, семинарах и вебинарах за счет средств организации (при соответствии бюджету и стратегическим планам компании). Также сотрудник имеет право запрашивать доступ к научным публикациям, образовательным платформам (Coursera, Udacity, DeepLearning.AI, O’Reilly) и корпоративной библиотеке.
Ежегодно ML-инженер составляет индивидуальный план развития (IDP), который согласовывается с руководителем.
6. Ответственность
Раздел устанавливает персональную ответственность ML-инженера за результаты своей работы.
6.1. Дисциплинарная и материальная ответственность
ML-инженер несет дисциплинарную ответственность за: невыполнение или ненадлежащее исполнение своих должностных обязанностей, установленных настоящим документом; несоблюдение сроков выполнения задач; нарушение внутреннего трудового распорядка и требований информационной безопасности.
Материальная ответственность наступает за прямой действительный ущерб, причиненный организации, в соответствии с ТК РФ, в том числе за утрату или порчу вверенного имущества, а также за убытки от неправомерного использования данных.
6.2. Ответственность за качество и соответствие требованиям
ML-инженер отвечает за: качество разрабатываемых моделей (соответствие заявленным бизнес-метрикам); корректность и воспроизводимость экспериментов; соблюдение стандартов качества кода, соглашений об именовании и структуры проектов; полноту и актуальность технической документации.
Особое внимание уделяется ответственности за этические аспекты работы моделей: ML-инженер обязан минимизировать риски дискриминации, нарушения приватности и других негативных социальных последствий внедрения моделей.
7. Квалификационные требования
В разделе приведены минимальные требования к образованию, опыту и компетенциям претендента на должность ML-инженера.
7.1. Образование и опыт работы
Требуемое образование: высшее профессиональное образование в области Computer Science, Data Science, Математики, Статистики, Физики или смежных дисциплин. Желательно наличие ученой степени (магистр/кандидат наук).
Опыт работы: не менее 3 лет в роли ML-инженера, Data Scientist или аналогичной должности, связанной с разработкой и внедрением моделей машинного обучения. Опыт работы в крупных проектах с большими объемами данных (Big Data) является преимуществом.
7.2. Профессиональные компетенции и навыки
ML-инженер должен владеть: одним из языков программирования высокого уровня (Python, R, Scala) — в совершенстве; библиотеками машинного обучения и глубокого обучения; теорией вероятностей, математической статистикой, методами оптимизации; навыками работы с базами данных (SQL, NoSQL); принципами построения ETL/ELT-пайплайнов; основами DevOps (Docker, CI/CD, мониторинг); английским языком на уровне не ниже Intermediate для чтения технической документации и общения с международными коллегами.
Оценка компетенций проводится с помощью тестирования и технических собеседований.
7.3. Сертификация и курсы повышения квалификации
В качестве рекомендации или требования (в зависимости от специфики проектов) ML-инженер должен иметь или стремиться получить сертификации: TensorFlow Developer Certificate, AWS Certified Machine Learning — Specialty, Microsoft Certified: Azure Data Scientist Associate, DeepLearning.AI Specialization (или аналоги).
Периодическое прохождение курсов повышения квалификации является обязательным условием для поддержания актуальности знаний, особенно в области новых архитектур (Transformer, Generative AI) и методов обучения.
8. Условия труда
В разделе описываются условия трудовой деятельности ML-инженера в организации «General».
8.1. Режим работы и организация труда
Режим работы определяется Правилами внутреннего трудового распорядка. Для ML-инженера установлен гибкий график работы с возможностью удаленной работы (при условии выполнения задач и обеспечения доступа к корпоративным ресурсам). Нормированный рабочий день составляет 8 часов с часовым обеденным перерывом. Возможны командировки для участия в конференциях или встреч с ключевыми заказчиками.
Рабочее место оснащается необходимым оборудованием (мощный ПК/ноутбук, мониторы) и программным обеспечением, согласованным с IT-отделом.
8.2. Охрана труда и техника безопасности
ML-инженер обязан соблюдать правила охраны труда и техники безопасности при работе с компьютерной и офисной техникой. При работе в лабораториях или серверных помещениях необходимо соблюдать правила электробезопасности и пожарной безопасности. Медицинское освидетельствование для данной должности не требуется, но рекомендуется ежегодный профилактический осмотр у офтальмолога.
Инструктаж по охране труда проводится при приеме на работу и далее периодически, согласно графику компании.
9. KPI и показатели эффективности
Раздел устанавливает количественные и качественные метрики для оценки эффективности ML-инженера.
9.1. Ключевые показатели эффективности (KPI)
Основные KPI для оценки деятельности ML-инженера: доля успешно завершенных проектов (деплой модели в продакшен) от общего числа инициированных; отклонение бизнес-метрик модели от целевых значений (не более 5% в худшую сторону); время на развертывание новой модели в продакшен (менее 2-х недель с момента получения чистых данных); количество инцидентов, связанных с работой модели в продакшене (не более 1 критического инцидента в квартал); уровень удовлетворенности смежных команд (продуктов, аналитики) — не менее 4.5 из 5 по результатам опросов.
Показатели пересматриваются ежегодно и корректируются в зависимости от стратегических целей организации.
9.2. Порядок оценки и пересмотра KPI
Оценка выполнения KPI проводится ежеквартально руководителем направления ML совместно с HR-менеджером. Основными источниками данных являются система Jira (выполнение задач), системы мониторинга (Grafana, Prometheus), отчеты о проектах и обратная связь от бизнес-заказчиков. По итогам оценки формируется план корректирующих действий в случае невыполнения показателей.
Пересмотр KPI может проводиться при изменении бизнес-приоритетов или технологических стратегий компании.
10. Бизнес-процессы, чек-листы и сценарии работ
Данный раздел содержит детализированное описание бизнес-процессов, в которых участвует ML-инженер, с использованием нотаций BPMN, IDEF0 и EPC. Приведены чек-листы этапов для типовых сценариев работ.
10.1. Сценарий: Планирование и инициация ML-проекта
Вход в процесс: получение бизнес-запроса от продукт-менеджера. Основные этапы (по нотации EPC): 1. Анализ бизнес-запроса. 2. Оценка реализуемости и ресурсов. 3. Формирование гипотезы о влиянии ML на метрику бизнеса. 4. Оценка ROI (Return on Investment) проекта. 5. Принятие решения о старте проекта. Результат: согласованный Project Charter или отказ с обоснованием.
Выход процесса: утвержденный план проекта, определенная команда и бюджет.
10.2. Сценарий: Сбор, подготовка и маркировка данных
Чек-лист этапов для сценария «Сбор и подготовка данных»: 1. Определение и документирование источников данных. 2. Разработка запросов для выгрузки данных. 3. Первичная валидация данных (проверка дубликатов, пропусков). 4. Очистка данных (удаление выбросов, заполнение пропусков). 5. Разметка данных (если требуется). 6. Создание репрезентативных выборок (train/valid/test). 7. Сохранение данных в централизованном хранилище с версионированием (DVC). 8. Документирование этапов подготовки данных.
Контрольная точка: сформированный и проверенный датасет, согласованный с продуктовой командой.
10.3. Сценарий: Исследование данных (EDA) и разработка признаков
Чек-лист EDA: 1. Статистический анализ переменных. 2. Визуализация распределений и корреляционных матриц. 3. Анализ пропусков и выбросов. 4. Исследование целевой переменной (баланс классов, распределение). 5. Генерация гипотез о важных признаках. 6. Создание новых признаков (Feature Engineering). 7. Выбор методов предобработки и трансформации. 8. Документирование всех выводов в ноутбуке или отчете.
Результат: EDA-отчет и спецификация на преобразование данных, подписанные руководителем.
10.4. Сценарий: Разработка и обучение модели
Чек-лист разработки: 1. Определение baseline-решения (простейшая модель). 2. Построение пайплайна для обучения с кросс-валидацией. 3. Гиперпараметрическая оптимизация. 4. Сравнение нескольких моделей по метрикам. 5. Анализ ошибок модели (confusion matrix, ошибки регрессии). 6. Выбор лучшей модели и фиксация ее состояния (модель + гиперпараметры). 7. Сохранение модели в реестре (MLflow). 8. Документирование результатов эксперимента.
Результат: обученная модель и подробный отчет о ее производительности на тестовой выборке.
10.5. Сценарий: Внедрение модели (Промышленная эксплуатация)
Чек-лист внедрения: 1. Упаковка модели в Docker-контейнер. 2. Разработка API-эндпоинтов для инференса (FastAPI). 3. Написание тестов (юнит-тесты, интеграционные тесты). 4. Настройка CI/CD пайплайна (GitLab CI). 5. Деплой модели в тестовую среду. 6. Проведение нагрузочного тестирования. 7. Деплой в продакшен (Canary или Blue-Green deployment). 8. Включение мониторинга и алертов (Prometheus, Grafana). 9. Документирование процесса деплоя и API.
Результат: работающий ML-сервис в продакшене, соответствующая документация и настроенная система мониторинга.
10.6. Сценарий: Мониторинг, обслуживание и переобучение
Чек-лист мониторинга и поддержки: 1. Ежедневный контроль метрик производительности модели (точность, задержка). 2. Мониторинг дрейфа данных и концепции (применение статистических тестов). 3. Анализ обратной связи от пользователей (если применимо). 4. Плановое переобучение модели (по расписанию или по факту дрейфа). 5. Версионирование новой модели и обновление в продакшене. 6. Формирование регулярного отчета о «здоровье» модели (Health Check Report). 7. Ретроспектива по инцидентам (Post-Mortem).
Контрольная точка: периодический отчет о состоянии модели и список действий по улучшению.
10.7. Методология BPMN для управления этапами
Для управления описанными процессами используется нотация BPMN, позволяющая создавать наглядные диаграммы потока работ. Применяются основные элементы: пулы и дорожки (Pool/Swimlane) для разделения ответственности; задачи (User Task, Service Task) для конкретных действий; шлюзы (Gateway) для ветвления логики; события (Start, End, Intermediate Events) для обозначения начала и завершения процессов. Пример: этап «Подготовка данных» — это Service Task, выполняемый ML-инженером; шлюз после валидации данных разветвляет процесс на «Успех» и «Ошибка в данных».
Для хранения моделей процессов используется корпоративный репозиторий или инструмент моделирования (например, Camunda Modeler).
10.8. Методология IDEF0 для функционального моделирования
Применяется для описания высокоуровневых функций и их взаимосвязей. Каждая функция (Activity) имеет входы (Input), выходы (Output), управления (Controls) и механизмы (Mechanisms). Для ML-процесса, например, функция «Обучение модели» имеет: вход — подготовленные данные; выход — обученная модель; управление — требования к точности и бизнес-правила; механизм — ML-инженеры, вычислительные ресурсы, библиотеки. Декомпозиция проводится до уровня, достаточного для понимания распределения ответственности.
В документации поддерживается контекстная диаграмма и диаграммы декомпозиции (до A-3 уровня).
10.9. Методология EPC для событийных цепочек
Используется для детального описания логики процессов, где основными элементами являются события (создают условия) и функции (выполняются при наступлении события). Связи между функциями строятся через логические операторы AND, OR, XOR. Пример для сценария «Развертывание модели»: событие «Модель прошла все тесты» → функция «Подписать документацию» → событие «Документация готова» → функция «Упаковать модель в Docker» → логический оператор AND → функции «Настроить мониторинг» и «Обновить документацию» → событие «Модель готова к деплою».
EPC-диаграммы помогают выявить узкие места и избыточные шаги в процессах.
10.10. Чек-лист преддеплойной проверки модели
Данный чек-лист является обязательным для заполнения перед любым деплоем модели в продакшен: 1. Проверка версии кода и модели (в репозитории). 2. Успешное прохождение всех автоматических тестов (юнит, интеграция, нагрузка). 3. Оценка качества на тестовой выборке не ниже согласованного порога. 4. Проверка документации (API, README, конфигурации). 5. Проверка соответствия стандартам безопасности (нет уязвимостей в зависимостях). 6. Согласование с продуктовой командой и получение approval. 7. Проверка плана отката (Rollback Plan). 8. Наличие настроенных дашбордов и алертов. 9. Запись в журнал изменений (Change Log). 10. Проведение тестирования в стейджинге (Staging) с данными, приближенными к реальным.
10.11. Чек-лист работы с Git и воспроизводимостью
Обязательный чек-лист для управления кодом и данными: 1. Код обучения модели хранится в Git-репозитории с осмысленными сообщениями коммитов. 2. Ветвление по модели Git Flow (main, develop, feature/*, hotfix/*). 3. Все запуски экспериментов логируются в MLflow (метрики, параметры, артефакты). 4. Данные и промежуточные файлы версионируются с помощью DVC. 5. Используется файл requirements.txt / conda-env для воспроизводимости окружения. 6. После каждого эксперимента создается тег в репозитории, соответствующий версии модели. 7. При необходимости предоставляется воспроизводимый Jupyter Notebook / Python скрипт.
Нарушение требований чек-листа является основанием для отказа в ревью.
10.12. Чек-лист проведения A/B теста
При внедрении новой модели, заменяющей существующую, обязательно проведение A/B теста: 1. Определить целевую метрику для A/B теста. 2. Обеспечить рандомизацию трафика между старой и новой моделью (50/50 или иная пропорция). 3. Включить логирование всех запросов и ответов с указанием варианта. 4. Убедиться, что система мониторинга фиксирует метрики отдельно по каждой группе. 5. Провести тест в течение заранее определенного периода (обычно 1-2 недели). 6. Проанализировать статистическую значимость различий в метриках. 7. Принять решение: оставить старую модель, заменить на новую, или доработать. 8. Задокументировать результаты теста.