# QA framework для ML-моделей: как я собрала ModelContract

> 2026-10-03 · AI Release · @ai_release1

> #QA #ML #тестирование #ModelContract #framework

### ⚡ Главное за 5 секунд - Авторка разработала фреймворк для автоматизированного тестирования готовых ML-моделей: он формирует ModelContract из metadata и формального API самой модели. - Опыт построен на модели Olist (оценка риска поздней доставки) с сохранёнными метриками: ROC AUC 0.8101, PR AUC 0.3354, Brier 0.0633. - Главное ограничение: критерии PASS/FAIL должны быть явно заданы в metadata или в самой модели; датасет не является источником требований. ### 🔍 Что обнаружено В попытке протестировать собственную ML-модель авторка столкнулась с типичной для Data Science проблемой: документация существует только в голове разработчика, а датасет охотно показывает фактические значения, но не отвечает на вопрос «как должно быть». Минимум в данных не означает допустимую границу, а отсутствие комбинации признаков — не то же самое, что её недопустимость. Для проверки нужны формальные критерии. Выход нашёлся в готовой модели Olist: рядом с ней была документация, включая описание признаков, датасет, сохранённые метрики и версии библиотек. Это позволило перейти от «проверки документации» к реализации фреймворка. Ключевая идея — разделить человекочитаемый README и машинный model_metadata.json. В metadata для Olist указаны target «is_late», метрики теста и версии scikit-learn 1.9.0, pandas 3.0.5, numpy 2.4.6. Дополнительно фреймворк читает информацию прямо из загруженной модели: feature_names_in_, classes_, наличие predict и predict_proba. Так родился ModelContract — набор требований, который собирается из двух источников и запоминает происхождение каждого пункта. ### 💡 Почему это важно Главная ценность подхода — проверки не привязаны к конкретной модели. Фреймворк содержит только механизм проверок, а все требования получает из контракта того проекта, который в него загружают. Это позволяет автоматизировать тестирование любых готовых ML-моделей, не думая о предметной области. А именно сочетание metadata и API модели даёт возможность находить расхождения: например, если в metadata заявлено 34 признака, а feature_names_in_ возвращает 33, это сразу становится конкретным FAIL. План на будущее — добавить в отчёт информацию о том, кто и когда внёс изменение, чтобы сразу идти к виновному с вопросами. Пример такого FAIL: «В тестовом датасете нет признака distance_km», требование из спецификации v2, пункт 4.1, изменение внёс @ivanov_dev, PR #142 от 15.09.2026. ### 🧩 Контекст Полгода назад авторка уже создавала агента для проверки технических заданий. Новая задача — тестирование ML — возникла из практической потребности: свой собственный проект оказался без документации, что сделало его идеальным кандидатом для эксперимента. Отсутствие формальных критериев в собственном проекте привело к выбору Olist в качестве подопытного, а затем и к созданию фреймворка. Сейчас в нём реализовано пять проверок, и он готов к использованию на других моделях.

[Источник](https://habr.com/ru/articles/1089614/)