Не верьте ROUGE: оценивайте AI-продукты по поведению пользователей
Офлайн-метрики часто обманывают. В статье предлагается трёхшаговый фреймворк, который выводит качество модели из поведения пользователей — с минимальными затратами для небольших команд.
Один провал, который меня отрезвил
Несколько лет назад я руководил разработкой AI-помощника для письма. Перед запуском мы прогнали тесты по ROUGE-L и BLEU-4 — получили 0.65 и 0.42, выше среднего для подобных задач. Команда была уверена в успехе. Но через неделю после запуска удержание рухнуло. Пользователи жаловались: «Результаты непригодны».
Разрыв между офлайн-метриками и восприятием пользователей оказался гораздо больше, чем я думал.
Почему традиционные метрики вводят в заблуждение
ROUGE и BLEU — это, по сути, совпадение n-грамм. Они хорошо ловят ключевые слова, но почти не учитывают семантическую связность, тональную согласованность и фактическую точность. Задача суммаризации может выдать все ключевые сущности, но текст будет бессвязным. Перевод может иметь высокий BLEU, но читаться отвратительно.
Главное: эти метрики не знают, что на самом деле нужно пользователю. В AI-помощнике для письма пользователь хочет «меньше правок» или «больше вдохновения»? Ответ зависит от сценария. Хорошие метрики не гарантируют успеха бизнеса.
Альтернативный фреймворк: оценивать качество модели по поведению пользователей
Я разработал трёхшаговую методику для небольших команд, у которых нет бюджета на массовую разметку.
Шаг 1: Определите ключевые бизнес-действия
Начинайте не с качества выдачи модели, а с вопроса: достиг ли пользователь цели?
- Для помощника письма: нажал ли пользователь «вставить»? Было ли после вставки больше трёх исправлений?
- Для приложения изучения языка: завершил ли пользователь дневной план? Повторял ли один и тот же урок?
- Для службы поддержки: завершил ли пользователь диалог после первого ответа или задавал уточняющие вопросы?
Эти действия напрямую связаны с бизнес-ценностью. Сопоставьте их с возможными проблемами модели:
| Действие пользователя | Возможная проблема модели |
|---|---|
| Высокая вставка + высокая пост-правка | Выдача не соответствует ожиданиям (стиль, длина, точность) |
| Низкая вставка | Предложения бесполезны или незаметны |
| Частая смена ввода | Модель не понимает исходный запрос |
Шаг 2: Постройте отображение от действий к выдаче модели
Собрав данные, проведите диагностику: какой компонент модели работает плохо? Простое групповое сравнение обходится без сложной статистики.
Разделите пользователей на группу A (довольные — вставили без правок) и группу B (недовольные — вставили и много редактировали). Сравните распределение выдачи для обеих групп по длине предложений, синтаксической сложности, охвату тем. Если предложения группы B в среднем на 30% длиннее, возможно, модель выдает слишком длинные тексты, которые нужно обрезать.
Разметка «хороших»/«плохих» выдач выполняется автоматически по логам — никакой ручной работы.
Шаг 3: Создайте лёгкую приборную панель для онлайн-оценки
Офлайн-метрики оставьте для регрессионного тестирования, а ежедневная панель должна показывать поведенческие индикаторы. Я фокусируюсь на трёх числах:
- Уровень принятия: % сгенерированных результатов, которые пользователь активно использует (копирует, вставляет, сохраняет).
- Уровень пост-правок: % использованных выдач, которые пользователь затем изменяет. Если >50%, направление выдачи неверно.
- Завершённость задачи: % пользователей, выполнивших цепочку ключевых действий (например, написать статью → нажать «опубликовать»).
Эти три цифры вместе говорят о полезности модели больше, чем любой ROUGE.
Гипотетический кейс: AI-рекомендации музыки
Представим, что я делаю AI-рекомендатель музыки. Офлайн-кликабельность — 0.18, неплохо. Но удержание низкое.
По трём шагам:
- Шаг 1: Ключевое действие — сохраняет ли пользователь рекомендованную песню или переключает сразу после прослушивания. Частые переключения — сигнал несовпадения.
- Шаг 2: Сравниваю пользователей с высоким сохранением и низким. У второй группы рекомендации слишком узкие — модель переобучилась на историю, создала пузырь фильтров.
- Шаг 3: Панель отслеживает «последовательные переключения» и «отличается ли стиль следующей песни от предыдущей». Это быстро указывает на причину.
Границы применения и предостережения
Фреймворк требует данных о поведении пользователей. Если продукт ещё не запущен, можно имитировать с ручным тестированием, но это дорого. Поведенческие сигналы подвержены шуму (например, сбои сети). Необходима простая очистка данных.
Ещё одна ловушка: ориентация на поведенческие метрики может подталкивать к действиям ради краткосрочных кликов в ущерб долгосрочной ценности (например, рекомендовать кликбейт). Поэтому раз в квартал полезно проводить опрос удовлетворённости пользователей для калибровки.
В заключение
Оценка AI-продукта — это не проблема модели, а проблема пользователя. Офлайн-метрики полезны на этапе разработки, но после запуска единственная валидная оценка — поведение пользователя. Для небольших команд с ограниченными ресурсами замена дорогой ручной разметки на дешёвые поведенческие сигналы позволяет сосредоточить усилия там, где они действительно влияют на удержание и доход.
PaxLee