Главная
→
Блог
→
Метрики в разработке ИИ: считать на каждом этапе, а не только в конце

Метрики в разработке ИИ: считать на каждом этапе, а не только в конце

“

Саммари: Запускать ИИ-проект без метрик — значит узнавать о его провале от клиента, а не от собственной системы контроля. Мы в AllSee считаем метрику на трёх разных этапах — аналитики, разработки и эксплуатации, — и каждый раз это разная метрика, измеренная на разных данных.

Этап аналитики: метрика ставится раньше кода

Первый вопрос в любом ИИ-проекте — не "какую модель выбрать", а "как мы поймём, что она работает". На этапе аналитики мы разбираем данные заказчика и определяем метрику до того, как написана первая строчка кода. Дальше развилка: если метрику можно измерить количественно и заранее понятно, какое значение будет означать успех, — мы фиксируем конкретную цель. Если такой уверенности нет, мы всё равно фиксируем формулу расчёта, но вместо абсолютного целевого значения отслеживаем рост метрики от итерации к итерации — так видно прогресс даже там, где заранее невозможно сказать, какое число окажется "достаточно хорошим".

Показательный пример первого сценария — проект по классификации почтовых обращений для компании, занимающейся спецтехникой: мы сразу зафиксировали, что точность ниже 80% будем считать провалом проекта, и в итоге вышли на 87%. А вот с задачами на базе RAG так честно поступить обычно не получается: то, что считается хорошим показателем, сильно зависит от конкретной задачи — для одних сценариев приемлемым результатом будет 60%, а для других планка начинается только от 85% и выше. Это не случайность конкретного проекта, а системная особенность подобных систем: помимо точности им требуется более широкая оценка — соответствие контексту, обоснованность ответа, полнота — а не единственная универсальная цифра.

Этап разработки: валидационное множество можно "подглядывать", контрольное — нельзя

Здесь чаще всего происходит методологическая ошибка, которую легко не заметить: считать метрику один раз на всех доступных данных и на этом успокоиться. Мы разделяем данные на три части, и это разделение — не формальность. Обучающее множество идёт на тренировку модели. Валидационное — на подбор гиперпараметров, сравнение версий и анализ ошибок в процессе работы, и в него можно заглядывать сколько угодно раз, потому что оно для этого и существует А вот контрольное, "слепое" множество трогается один раз — в самом конце, для финальной оценки перед сдачей или запуском в продакшен.

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

Этап эксплуатации: метрика не заканчивается на сдаче проекта

Финальная оценка на контрольном множестве отвечает на вопрос "насколько хорошо модель должна работать", но не на вопрос "будет ли работать так же хорошо спустя три месяца после запуска". Это два разных измерения, и путать их — ещё одна частая ошибка: оценка модели показывает ожидаемое качество на исторических данных, а мониторинг модели в проде показывает, как она реально ведёт себя на свежих, живых данных здесь и сейчас. Именно поэтому мы считаем метрику и в процессе использования продукта: даже модель, безупречно прошедшая все офлайн-тесты, в реальной эксплуатации может начать давать сбои, которых процесс валидации попросту не предусматривал — из-за новых сегментов пользователей или сценариев, которых не было в обучающих и тестовых данных. Регулярный расчёт метрики в онлайн также даёт возможность заранее увидеть момент, когда данные и поведение пользователей начинают "уезжать" от того, на чём модель обучалась, и спланировать переобучение до того, как это заметит клиент.

Почему это в итоге окупается

Три этапа расчёта метрики — это не бюрократическая перестраховка, а способ разделить три разных вопроса, которые иначе легко перепутать: "правильно ли мы вообще ставим задачу" (аналитика), "не обманываем ли мы сами себя оптимизацией под знакомые данные" (валидация против контрольного множества) и "не деградирует ли качество там, где его уже никто специально не проверяет" (эксплуатация). Заранее зафиксированный порог в 80% для классификации обращений и осознанно не зафиксированный порог для RAG-задачи — это не противоречие, а два правильных ответа на один и тот же вопрос "как мы поймём, что система работает", просто для разных по своей природе задач.