Точность и полнота — две базовые метрики качества классификации и поиска. Точность (precision) показывает, какая доля случаев, названных системой положительными, действительно положительные; полнота (recall) — какая доля всех положительных случаев системой найдена. Почти всегда растут одна за счёт другой, и баланс между ними — инженерное решение, зависящее от цены ошибок, а не свойство модели.
Как считаются обе метрики
Обе выводятся из четырёх исходов разметки. Точность — доля верных срабатываний среди всех срабатываний: из 100 обращений, помеченных как срочные, срочными оказались 70 — точность 0,70. Полнота — доля найденных среди всех искомых: если срочных в потоке 200, а система поймала 70, полнота 0,35. Клетки, из которых это считается, разобраны в статье про матрицу ошибок.
Каждая метрика слепа к ошибкам другого типа. Точность не видит пропусков, полнота — ложных срабатываний. Отсюда способ «дёшево» поднять любую из них: помечайте срочным каждое обращение — полнота 1,0 при точности на уровне доли срочных в потоке; срабатывайте только на идеальное совпадение с шаблоном — точность около 1,0 при полноте около нуля. Отчёт с одной метрикой поэтому ничего не доказывает.
Почему они конфликтуют и при чём тут порог
Классификатор выдаёт вероятность, а решение принимает порог. Модель говорит «срочно с вероятностью 0,63»; все обращения выше порога уходят в срочную очередь. Порог ниже — срабатываний больше, полнота растёт, но в выдачу попадают сомнительные случаи и точность падает; порог выше — наоборот.
Значения метрик без порога бессодержательны. «Точность 0,9» ничего не говорит о системе, если неизвестно, при каком пороге и на каком распределении она получена: при пороге 0,5 на одном потоке и при 0,8 на другом выйдет одинаковая цифра при разном поведении в эксплуатации. Порог — часть конфигурации: его фиксируют и версионируют вместе с моделью.
Компромисс делает видимым кривая точность–полнота. Перебирая порог от 0 до 1, получают набор пар значений и кривую в координатах «полнота по горизонтали, точность по вертикали»; по ней видно, сколько точности придётся отдать за прирост полноты. Кривая, прижатая к осям, означает слабую модель: выбор порога на ней — выбор между двумя плохими вариантами, чинить надо признаки и модель.
Два примера: поиск фрагментов и классификация обращений
В поиске фрагментов для RAG сначала важнее полнота. Генератор строит ответ только из фрагментов, попавших в контекст: если нужный фрагмент не найден, чинить генерацию бессмысленно. Поэтому первый этап оптимизации — recall@k, доля вопросов, у которых нужный фрагмент попал в топ-k. Когда полнота доведена до приемлемого уровня, включается точность: каждый посторонний фрагмент — потраченные токены и риск, что ответ соберётся из чужого материала. Специфику метрик поиска — recall@k, precision@k, MRR — мы разбираем в статье про метрики качества RAG.
В классификации обращений баланс задаёт цена ошибки. Классификатор «срочное / несрочное» отправляет срочные в отдельную очередь с жёстким SLA. Пропуск срочного — сорванный SLA и потерянный клиент, то есть ущерб на порядки больше стоимости проверки; ложная тревога — одна-две минуты оператора. Здесь полноту ценят выше точности, и порог опускают, сознательно принимая рост ложных срабатываний.
Та же модель с другим порогом — другая система. Если метка «срочное» лишь подсвечивает обращение в интерфейсе, низкий порог уместен: оператор быстро отсеивает ложные. Если метка запускает эскалацию дежурному в ночную смену, цена ложной тревоги вырастает в разы, и порог поднимают. Про классификацию обращений как задачу есть отдельная статья.
Как выбирать рабочую точку под цену ошибок
Порог выводят из стоимостей, а не из круглой цифры. Порядок действий: оценить стоимость ложного срабатывания (обычно это время ручной проверки), стоимость пропуска (ущерб, штраф, потерянный клиент), построить кривую точность–полнота и посчитать ожидаемые суммарные потери при каждом пороге. Рабочая точка — порог с минимумом потерь, а не с максимумом какой-либо метрики.
Иллюстративный расчёт. Поток 10 000 обращений в месяц, из них 5% срочных — 500. Ложная тревога — 50 рублей (две минуты оператора), пропуск срочного — 10 000 рублей. При полноте 0,90 и точности 0,60 система ловит 450 срочных, пропускает 50 — потери 500 000 рублей; ложных тревог 300 — ещё 15 000, итого 515 000. При полноте 0,95 и точности 0,45 пропуски — 25 случаев, 250 000 рублей; ложных тревог около 580 — порядка 29 000, итого около 280 000. Вторая точка выигрывает по деньгам, хотя точность в ней хуже. Цифры условные; на своих данных сумму пересчитывают и порог берут по минимуму.
Порог токсичности не равен порогу автодействия. Один и тот же сигнал обслуживает два процесса с разной ценой ошибок. Ручная модерация с предварительной фильтрацией — порог низкий: цена ложной тревоги — задержка публикации на минуты, цена пропуска — публичный репутационный ущерб. Автоматическое отклонение контента без человека — порог высокий: ложный отказ пользователь видит лично, и с каждой такой ошибкой доверие к продукту падает. Два процесса — два порога, и оба версионируются.
Типичные ошибки
Оптимизировать одну метрику и молчать про другую. Самая частая ошибка отчётности: «подняли точность до 0,95» — порогом, при котором полнота упала с 0,8 до 0,5. Половина срочных обращений теперь едет в общем потоке, но в отчёте этого нет. Правило: точность и полнота публикуются парой, при указанном пороге и на одном наборе.
Выбирать порог на тех же данных, где считаете итог. Порог, подобранный под максимум метрики на проверочном наборе, подгоняется под его особенности, и итоговая оценка на этом же наборе завышена. Порог подбирают на одном разбиении, финальную оценку считают на данных, которые в подборе не участвовали, — об этом в статье про кросс-валидацию.
Усреднять по сегментам. Средняя точность 0,85 может раскладываться на 0,95 у коротких обращений и 0,55 у длинных с вложениями. Там, где сегменты различаются ценой ошибок, рабочую точку выбирают по сегментам; сводить их в одну цифру имеет смысл только для первого среза.
Держать порог неизменным при дрейфе. Поток обращений меняется с запуском новых продуктов и сезонностью; кривая точность–полнота смещается, и старый порог незаметно уводит систему в сторону точности или полноты. Порог пересматривают при дрейфе данных и при изменении стоимости ошибок.
Частые вопросы
Какая метрика важнее — точность или полнота?
Та, что ограничивает более дорогую ошибку. Пропуск дороже проверки — важнее полнота: срочные обращения, модерация с человеком в контуре. Ложная тревога дороже пропуска — важнее точность: автодействия без человека, автоматические блокировки. В остальных случаях публикуют обе и не сводят их насильно.
Можно ли поднять обе метрики одновременно?
Порогом — нет: он лишь перемещает систему по кривой точность–полнота. Сдвинуть кривую можно сменой модели, признаков, промпта, дообучением на своих данных; после этого порог выбирают заново.
Откуда берётся число всех положительных случаев для полноты?
На проверочном наборе — из разметки: сколько срочных обращений в нём реально есть, известно. В эксплуатации полноту напрямую не измерить — неизвестно, сколько срочных система молча пропустила; её оценивают на наборе и по косвенным сигналам, например по обращениям, поднятым клиентами повторно.
Что делать, если кривая точность–полнота прижата к осям?
Модель не различает классы, и смещение порога лишь меняет вид ошибки. Чинить надо модель и признаки: типовые причины — мало примеров редкого класса, утечка метки во вход или сигнал, которого во входе нет.
Как часто пересматривать порог?
При изменении распределения потока и при изменении стоимости ошибок — пересмотре SLA, стоимости проверки, штрафов. Порог — конфигурация системы: его пересчитывают по методике и фиксируют вместе с версией, а не подгоняют под каждый отчёт.
Чем это отличается от ROC-анализа?
ROC-кривая перебирает те же пороги в других координатах — доля верно пойманных положительных против доли ошибочно тронутых отрицательных — и применяется для сравнения моделей до выбора порога; детали — в статье про ROC-AUC.