Обзор Evidently: отчёты о качестве и сдвиге данных

Обзор Evidently: отчёты о качестве и сдвиге данных строятся вокруг библиотеки с открытым кодом на Python. Она оценивает, тестирует и наблюдает ML- и LLM-системы, работает с табличными и текстовыми данными и даёт более ста встроенных метрик. Отчёт сравнивает текущую выборку с опорной и показывает изменения распределений.

Библиотека Evidently и способы размещения отчётов

Evidently — открытая библиотека на Python для оценки, тестирования и наблюдения ML- и LLM-систем, от экспериментов до продакшена. В репозитории проекта на GitHub она описана как модульный фреймворк: можно начать с разовых прогонов и дойти до полноценного сервиса мониторинга. Библиотека поддерживает табличные и текстовые данные, оценку предсказательных и генеративных задач, от классификации до RAG, и более ста встроенных метрик — от обнаружения сдвига данных до судей на базе LLM. Есть интерфейс Python для собственных метрик.

Отчёт — центральный объект. В документации проекта Report описан как способ посчитать и свести воедино разные оценки качества данных, модели и LLM. Начинать предлагается с пресетов и встроенных метрик, а дальше настраивать состав. Отчёт подходит для экспериментов, разведочного анализа и отладки. Результат можно смотреть интерактивно в Python или выгружать в JSON, словарь Python, HTML и в интерфейс мониторинга.

Любой отчёт превращается в набор тестов добавлением условий pass/fail. В документации это описано как Test Suite: он удобен для регрессионных проверок, CI/CD и валидации данных. Условия можно сгенерировать автоматически из опорного набора данных, а можно задать вручную через простой синтаксис вроде gt (больше) и lt (меньше).

Размещение отчётов бывает разным. Первый путь — локальный: HTML-файл, JSON или словарь Python, который читает ваш код. Второй — интерфейс мониторинга. В репозитории проекта на GitHub описаны три варианта: развернуть открытую версию у себя, посмотреть живую демонстрацию или зарегистрироваться в Evidently Cloud. Для локального запуска с демонстрационными проектами выполните команду evidently ui —demo-projects all, затем откройте localhost:8000. Интеграция с ZenML показывает ещё один способ: валидатор в пайплайне выдаёт отчёты в форматах JSON и HTML, а для версии с одним набором данных достаточно не передавать набор для сравнения.

Роли reference, current, target, prediction

Роли колонок и наборов данных определяют, что именно сравнивает отчёт. В документации проекта сказано, что второй набор данных, reference, готовится по желанию и используется во время оценки. Первый набор — current, то, что вы проверяете сейчас. Порядок аргументов важен: в примерах документации первым идёт текущий набор, вторым — опорный, из которого генерируются условия тестов.

Роль reference задаёт базу сравнения. Когда опорный набор передан, тесты сравнивают новые данные с ним. В документации проекта приведён пример: проверка пропусков сверяет текущую долю пропусков с опорной в пределах плюс-минус десять процентов. Без опорного набора тесты опираются на встроенные эвристики: проверка пропусков просто ожидает ноль процентов, а тест точности классификации сравнивает результат с фиктивным базовым уровнем.

Роли target и prediction относятся к качеству модели. В документации проекта указано: чтобы оценивать качество ML-модели без истинных меток, включайте входные признаки и предсказания. Колонки target и prediction попадают в оценку сдвига вместе с остальными, а для отдельного виджета по предсказанию в отчёт добавляют ValueDrift для этой колонки. Интеграция с ZenML отмечает, что target и predictions нужны для отчётов о производительности модели.

Разделение ролей определяет и то, какой вопрос вы задаёте данным. Сдвиг признаков отвечает на вопрос, изменилось ли окружение модели. Сдвиг предсказаний показывает, поменялось ли распределение выхода. Метрики качества требуют истинных меток и отвечают на вопрос, стало ли предсказание хуже.

Заполненная частотная таблица двух выборок

Разберём учебный пример распределения категорий. Опорный набор country содержит значения RU, RU, DE, DE. Текущий набор — RU, DE, US, US. Это ручная частотная таблица из восьми учебных значений. Она служит условным входом для разбора; измерения продукта здесь не проводились.

Диагноз по таблице: наблюдается изменение входа. Новая категория US занимает половину текущего набора, а две прежние категории сжались вдвое каждая. Качество прогноза по этой таблице неизвестно: для него нужны истинные метки и подходящая метрика. Значения p-value, автоматический вердикт Evidently и падение accuracy в этом примере не выводятся.

Практический шаг после такой таблицы — проверить, откуда взялась новая категория. Возможные причины: изменилась география трафика, обновился справочник стран, сломался маппинг кодов, часть запросов пришла из нового сегмента. Документация проекта напоминает: проверка сдвига данных отбрасывает пустые значения и сравнивает распределения непустых признаков, поэтому проверки пропусков стоит запускать отдельно, например через DataSummaryPreset. Для этого примера порядок такой: сверить справочник категорий, посмотреть долю пропусков в колонке country, разбить текущий набор по сегментам и только потом решать, что делать с моделью.

Data drift не доказывает performance drift

Сдвиг данных и падение качества — разные наблюдения. Документация проекта описывает сдвиг признаков и сдвиг предсказаний как прокси-метрики: они показывают, работает ли модель в знакомом окружении. Обнаружив сдвиг, можно запустить разметку и переобучение или решить приостановить работу и перейти к другому способу принятия решения. Прямой связи «сдвиг есть — качество упало» здесь нет.

Обратный сценарий тоже встречается. Документация проекта предлагает использовать проверку сдвига при отладке падения качества: если качество просело, сдвиг помогает понять изменение окружения или появление нового сегмента. В таком разборе сдвиг используют как диагностический сигнал при анализе уже измеренного падения качества.

Авторский туториал на krishnaik.in описывает DataDriftPreset как набор: один тест сдвига на колонку плюс счётчик, сколько колонок сдвинулось. Там же отмечено, что каждая колонка в его примере сообщает p-value. Это относится к выбранному в туториале методу: часть методов сдвига возвращает расстояние, поэтому переносить семантику p-value на все методы нельзя.

Практический вывод для читателя: держите сдвиг и качество в двух отдельных отчётах. Сдвиг признаков считайте на свежих данных без меток. Качество считайте тогда, когда пришла разметка. Сопоставляйте отчёты по времени, сегментам и нескольким подходящим показателям.

Метрики и тесты: значение отдельно от правила PASS/FAIL

В Evidently метрика и тест — разные сущности. В документации проекта сказано: можно получить либо сырые метрики, либо результаты тестов pass/fail. Тесты проверяют конкретные условия и дают результат на уровне набора данных, они добавляются к отчёту и появляются на отдельной вкладке.

Условия задаются тремя способами. Пресеты тестов дают набор проверок со сгенерированными условиями. Отдельные тесты с умолчаниями позволяют выбрать конкретные метрики, включив include_tests. Собственные тесты задают условия вручную. В документации проекта приведён пример: проверка отсутствия пропусков и значений ниже восемнадцати в колонке Age записывается как MissingValueCount с условием eq(0) и MinValue с условием gte(18). При ручных условиях include_tests уже не нужен.

Условия бывают числовыми и относительными. Доступны eq, not_eq, gt, gte, lt, lte, is_in и not_in. Для метрик с несколькими выходами, например MAE со средним и стандартным отклонением, применяются отдельные параметры вроде mean_tests и std_tests. Для метрик, возвращающих абсолютный счёт и долю, параметр tests работает со счётом, а share_tests — с относительной величиной. Условия можно привязать к опорному значению: в документации проекта показан RowCount с проверкой gte(Reference(relative=0.1)) и вариант с абсолютным отклонением.

Критичность теста управляет реакцией. По умолчанию проваленный тест даёт Fail. Параметр is_critical=False превращает результат в Warning, который не запускает оповещение и помечается жёлтым. Это позволяет строить слоистые условия: предупреждение при любых пропусках и провал при доле выше десяти процентов.

Новые категории, пропуски, размер окна и сегменты

Четыре вещи чаще всего искажают картину сдвига. Первая — новые категории. В учебном примере категория US отсутствовала в опорном наборе и заняла половину текущего. Документация проекта относит появление новых категорий к проверкам качества данных, а сдвиг распределений считает отдельно.

Вторая — пропуски. Проверка сдвига отбрасывает пустые значения и сравнивает распределения непустых признаков. Значит, рост пропусков может остаться незамеченным в отчёте о сдвиге, если не добавить проверки качества данных. Документация проекта рекомендует добавлять DataSummaryPreset для описательных статистик и тестов на пропуски.

Третья — размер окна. Сравнение опирается на два набора данных, и объём текущего набора влияет на то, какие изменения вы увидите. В документации проекта RowCount можно проверять относительно опорного значения с допуском, что помогает заметить резкое сокращение или рост потока.

Четвёртая — сегменты. Документация проекта называет появление нового сегмента одной из причин, которые помогает обнаружить проверка сдвига при отладке качества. Сегментный разрез показывает, что общий показатель может скрывать: сдвиг в одной группе и стабильность в остальных. Полезно считать сдвиг по важным признакам отдельно, используя параметр columns, и добавлять проверки изменений корреляций между признаками.

Три состояния принятия решения

Решения по результатам отчёта удобно свести к трём состояниям. Первое: вход изменился, метки не пришли. Действие — проверить сбор данных и сегменты, убедиться, что новая категория или рост пропусков отражают реальность. Второе: метки пришли, качество упало. Действие — проверить ошибку по сегментам, найти группу, которая тянет показатель вниз. Третье: сдвиг есть, качество стабильно. Действие — продолжить наблюдение по задаче.

Документация проекта описывает похожую логику: при сдвиге признаков или предсказаний можно запустить разметку и переобучение либо приостановить работу и перейти к другому способу принятия решения. Перед подачей свежих данных в модель полезно проверить, есть ли вообще смысл: при отсутствии сдвига окружение стабильно, и переобучение может быть не нужно. Автоматического совета переобучать модель при любом сдвиге здесь нет.

Порядок действий для читателя: зафиксируйте опорный набор и его дату; считайте сдвиг на свежем окне; отдельно считайте качество, когда пришла разметка; разложите оба показателя по сегментам; примите одно из трёх решений и запишите, какое наблюдение его обосновало. Так отчёт остаётся инструментом наблюдения, а решение опирается на проверенные данные.

Частые вопросы

Чем Evidently отличается от системы мониторинга?
Evidently — открытая библиотека на Python для оценки, тестирования и наблюдения ML- и LLM-систем. Отчёты можно смотреть локально в Python или выгружать в JSON, словарь, HTML. Интерфейс мониторинга — отдельный слой: открытую версию разворачивают у себя, есть живая демонстрация и Evidently Cloud.

Что такое reference и current в отчёте?
Current — набор данных, который вы проверяете сейчас, он идёт первым аргументом запуска. Reference — опорный набор, база сравнения и источник условий для тестов. В документации проекта reference описан как необязательный второй набор, используемый во время оценки.

Почему сдвиг данных не равен падению качества?
Сдвиг признаков и предсказаний — прокси-метрики, они показывают изменение окружения модели. Качество требует истинных меток и подходящей метрики. Документация проекта предлагает использовать сдвиг и для отладки упавшего качества, и для решения о разметке, сохраняя эти наблюдения раздельно.

Как задать условие PASS/FAIL для метрики?
Выберите метрику и добавьте список tests с условиями eq, gt, gte, lt, lte, is_in или not_in. Для доли используйте share_tests, для метрик с несколькими выходами — параметры вроде mean_tests. Параметр is_critical=False превращает провал в предупреждение.

Что делать, если появилась новая категория?
Проверьте справочник категорий, маппинг и источник данных: новая категория может отражать реальный сегмент или ошибку сбора. Сравните доли по таблице распределений и посмотрите пропуски отдельной проверкой. Решение о переобучении принимайте после того, как увидите качество на размеченных данных.