Не доверяйте только метрикам: оценивайте модели ИИ по поведению пользователей

Не доверяйте только метрикам: оценивайте модели ИИ по поведению пользователей

Мы добавили в инструмент для написания текстов новую функцию: автоматическое создание саммари. Команда модели отчиталась о красивом показателе ROUGE — на 8% выше предыдущей версии. Но после запуска вовлечённость пользователей не выросла, а упала. Я посмотрел логи и обнаружил, что многие пользователи генерировали саммари, а затем вручную удаляли и переписывали его.

В тот момент я понял: мы измеряли успех продукта метриками модели, но пользователям всё равно на ROUGE.

Это не значит, что метрики модели бесполезны. Они незаменимы на этапе обучения и выбора модели. Но как только модель попадает в продукт, якорь оценки должен сместиться на поведение пользователей.

Почему метрики модели могут обманывать

ROUGE, BLEU, точность — всё это измеряет, насколько вывод модели близок к эталону. Но "хорошо" в продукте означает, что пользователям удобно, они используют и платят. Эти две вещи часто расходятся.

Несколько примеров из моей практики:

• Модель перевода имела высокий BLEU, но пользователи жаловались, что перевод слишком буквальный и не учитывает контекст.
• Чат-бот имел точность 95%, но вопросы пользователей часто попадали в те самые 5% на границе, и именно опыт на границе решал, продолжат ли они им пользоваться.
• Модель саммари имела высокий ROUGE, но часто упускала ту самую цифру, которая была важна пользователю.

Метрики модели оптимизируют "похожесть", а пользователям нужна "пригодность".

Оценка по поведению пользователей: три шага

Я советую малым командам не строить сразу сложную платформу оценки. Используйте три шага, чтобы вернуть оценку от метрик модели к поведению пользователей.

Шаг 1: Определите ключевые действия пользователей

Каждая AI-функция соответствует нескольким ключевым действиям. Например:

• Саммари: редактируют ли пользователи вывод? Насколько? Копируют ли?
• Перевод: переключают ли язык? Повторяют ли запрос?
• Чат-бот: задают ли уточняющие вопросы? Завершают ли диалог после определённого ответа?

Для этих действий не нужны метрики модели — достаточно событийной аналитики.

Шаг 2: Установите пороговые значения поведения

Для каждого ключевого действия задайте "нормальный диапазон". Например, доля редактирований ниже 30% для саммари — норма; доля повторов выше 20% для перевода — тревожный сигнал. Пороги не должны быть точными, но они должны существовать. С ними вы быстро поймёте: это шум или сигнал?

Шаг 3: Создайте цикл обратной связи

Когда поведенческие данные выходят за пороги, не смотрите только на цифры — смотрите на конкретные пользовательские сессии. Моя практика: раз в неделю выбирать 10 сессий и смотреть, что делают пользователи и где застревают. Для этого не нужен аналитик данных — продакт-менеджер может сделать это сам.

Рамка решений: приоритет при отклонениях в поведении

Когда поведение пользователей отклоняется от нормы, что чинить сначала — модель или интерфейс? Вот простой список приоритетов:

1. Если отклонения сосредоточены на конкретном типе ввода (например, длинные документы, разговорный стиль), сначала проверяйте модель.
2. Если отклонения распределены по всем вводам, сначала проверяйте дизайн взаимодействия — расположение кнопок, формат вывода.
3. Если отклонения сопровождаются высоким оттоком, немедленно откатывайте или деградируйте, а затем медленно разбирайтесь в причинах.

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

Как внедрить в малой команде

У малых команд ограниченные ресурсы, они не могут позволить себе отдельную команду оценки. Мои рекомендации:

• Не стройте автоматический дашборд с первого дня. Используйте Excel или простые SQL-запросы, чтобы вывести поведенческие метрики и смотреть их раз в неделю.
• Вписывайте поведенческие метрики в PRD. При разработке новой функции сразу определяйте, какие действия считаются "хорошими", а какие "плохими". Это намного дешевле, чем добавлять трекинг потом.
• Дополняйте поведенческие данные интервью. Поведенческие данные говорят "что произошло", интервью — "почему". Только вместе они дают верное решение.

Граница: когда метрики модели всё ещё важны

Справедливости ради скажу: метрики модели не всегда бесполезны. Они остаются основным инструментом в таких сценариях:

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

Но как только продукт вышел в свет, пусть поведение пользователей будет окончательным судьёй.

Продакт-менеджеру не нужно становиться экспертом по машинному обучению, но нужно знать: метрики модели — это внутренний язык, поведение пользователей — внешний. Ваша задача — переводить между ними.

PaxLee