Не ждите точности 99%: рамка выбора точности AI-продукта

Не ждите точности 99%: окно принятия решений от 20% до 80% для AI-продуктов

Несколько лет назад, когда я делал AI-инструмент для письма, команда потратила две недели на повышение точности генерации заголовков с 80% до 85%. Отзывы пользователей? Ничего не изменилось. Но когда мы преждевременно запустили сырую функцию саммари (точность всего 60%), дневная активность выросла на 12%.

Это не история «чем точнее, тем лучше». Продуктовые менеджеры AI-продуктов часто попадают в «ловушку точности» — думают, что немного лучшая производительность модели сделает пользователей счастливее. На самом деле пользователи гораздо терпимее, чем вы думаете, при условии, что вы закрываете критические сценарии.

Пользователи терпят ошибки, а не непредсказуемость

Однажды мы провели простой тест: две версии грамматического корректора — одна с точностью 85%, другая 95%. Оценки удовлетворённости различались всего на 0,3 балла (по 5-балльной шкале), но с одним условием: когда инструмент ошибался, он должен был явно сказать «я не уверен», а не принудительно исправлять.

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

Это означает: вместо того чтобы вкладывать ресурсы в повышение средней точности, сначала обеспечьте точность на критическом пути до «приемлемого» порога, одновременно минимизируя колебания поведения системы.

Вес принятия решений для 20% ключевых сценариев

Предположим, вы делаете AI-продукт для генерации музыки. Типичный путь пользователя: ввести настроение и жанр → сгенерировать мелодию → настроить детали → экспортировать. Шаг «сгенерировать мелодию» — критический сценарий; сбой (шум, зависание, несоответствие стилю) вызывает немедленный уход. А несовершенства на этапе «настройки деталей» (например, нота на 5 центов выше) вполне терпимы.

Я ввёл для своей команды простую рамку «Трёхуровневая классификация сценариев»:

Уровень 1: Жизненно важные сценарии — если здесь ошибка, пользователь сразу уходит. Такие сценарии нужно запускать первыми, даже при точности 70%. Но необходимо предусмотреть запасные варианты: когда качество генерации ниже порога, автоматически предоставлять упрощённую версию или шаблоны, подготовленные человеком.

Уровень 2: Сценарии накопления доверия — пользователь готов пробовать несколько раз, но накопленные ошибки ведут к оттоку. Целевая точность выше 80%, постепенно улучшать. Ключ — давать понятную обратную связь после ошибок (например, «Этот совет имеет низкую уверенность»).

Уровень 3: Приятные дополнения — ошибки не влияют на основную задачу, пользователи их игнорируют. Оптимизировать только при избытке ресурсов или вообще не делать.

Убывающая отдача от повышения точности

Я собрал примерную статистику по двум AI-продуктам: функция оценки произношения в приложении для изучения языка и инструмент для саммари финансовых текстов. Кривые были похожи:

0% до 60% точности: 2 недели, успешность задачи с 0% до 40%
60% до 80%: 3 недели, успешность до 65%
80% до 90%: 5 недель, успешность до 72%
90% до 95%: 8 недель, успешность до 75%

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

Поэтому моё правило: запускать, когда точность модели около 80%, затем наблюдать за поведением пользователей. Если пользователи уходят из-за точности, оптимизировать 20% наиболее частых типов ошибок, а не все ошибки.

Запасные варианты важнее точности

Когда точность не дотягивает, не надо форсировать. Нужно спроектировать пользовательский опыт для «отказа модели». Три распространённые стратегии:

Явное сообщение: «Я уверен только на 60%, вот моя догадка». Пользователи корректируют ожидания и исправляют ошибки.
Упрощённый режим: Откат к более базовой функции, когда модель не справляется со сложностью. Например, AI-ассистент, не понимающий длинный текст, предлагает только извлечение ключевых слов.
Человек для подстраховки: Для небольших команд — внутренний канал проверки, передавать крайнюю неопределённость человеку (только если объём мал).

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

Практический чек-лист

Принимая решение, достаточно ли точность модели для запуска, пройдите по пунктам:

Есть ли точное определение неудачи для критических сценариев? (например, «заголовок с явными грамматическими ошибками» — неудача, «заголовок недостаточно яркий» — нет)
При текущей точности частота неудач в критических сценариях ниже психологического порога пользователя? (Обычно 20-30% — верхняя граница)
Сконцентрированы ли типы ошибок в нескольких высокочастотных сценариях? Если да, исправлять сначала их, а не всю модель.
Есть ли запасной план для ошибок, выходящих за рамки точности? (Явное сообщение, упрощение, человек)
Есть ли мониторинг трендов неудач в критических сценариях? Если после запуска частота растёт, есть ли механизм отката или оперативного исправления?

Этот чек-лист не идеален, но помогает принять обоснованное решение между «подождать лучшей точности» и «запускать сейчас».

Наконец

Я до сих пор часто колеблюсь в решениях о точности. Каждый раз, когда офлайн-метрика поднимается на 2%, я радуюсь секунду — а затем спрашиваю: превращается ли этот 2% в улучшение поведения пользователей? Чаще всего ответ — нет.

Суть запуска AI-продукта — не потолок возможностей модели, а то, как продакт-менеджер с ограниченными ресурсами быстро закрывает критические сценарии в пределах терпимости пользователей. То окно принятия решений от 20% до 80% — вот где нужно думать hardest.

PaxLee