LLM API и интеграция

Какие метрики отслеживать после запуска нейросети

Какие метрики отслеживать после запуска нейросети

После запуска достаточно пяти метрик: доля обращений, дошедших до человека; доля повторных обращений по той же теме; расход на одну решённую задачу, а не на запрос; доля ответов, которые правили перед отправкой; время до ответа. Остальное — число запросов, средняя длина ответа, «удовлетворённость» без шкалы — украшает отчёт и не меняет ни одного решения. Сдвиг любой из пяти на 25 % за две недели при том же объёме обращений — повод разбираться, даже если жалоб нет.

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

Какие пять метрик достаточно смотреть

Пять. Список короткий намеренно: метрика, после которой непонятно, что делать, в него не попала.

МетрикаЧто ловитКогда это проблема
Доля обращений, дошедших до человекаграницу, за которой сценарий не справляетсярастёт две недели подряд при том же потоке
Повторные обращения по той же темеответы, формально данные, но вопрос не закрывшиерастут при неизменной доле передач человеку
Расход на одну решённую задачусебестоимость результата, а не цену запросарастёт быстрее, чем число задач
Доля ответов, которые правили перед отправкойкачество, которое ещё не дошло до жалобрастёт при стабильных остальных четырёх
Время до ответатерпение пользователя95-й перцентиль, а не среднее

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

Что ловит доля обращений, дошедших до человека

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

Низкая доля сама по себе не достижение. Сценарий, который отвечает на всё и никогда не передаёт, обычно отвечает на часть вопросов неправильно — эта метрика работает только в паре с долей правок.

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

Почему повторные обращения по той же теме — самый честный сигнал

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

Её ценность в том, что она не зависит от мнения. Человек, вернувшийся второй раз, уже проголосовал, и ему не нужно ставить оценку.

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

Почему расход считают на задачу, а не на запрос

Одна задача пользователя редко равна одному запросу. Уточнение, повтор после неудачного ответа, догоняющий вопрос и передача человеку входят в ту же задачу и стоят денег. Цена запроса при этом может падать, пока себестоимость результата растёт.

Считать расход на задачу проще, когда ставка известна заранее и одинакова на вход и на выход: KeyDealer отдаёт рублёвую ставку каждой из 45 текстовых позиций в ответе GET /v1/models до первого запроса, а журнал показывает расход по каждому обращению — делить остаётся только на число закрытых задач.

Разброс ставок по каталогу большой: 1 ₽ за миллион токенов у недорогой текстовой позиции и 30 ₽ у флагманской. Поэтому «расход вырос» без знаменателя не значит ничего: сначала делим на задачи, потом делаем выводы. Приёмы, которые реально снижают счёт, собраны в статье как сократить расходы на API.

Одна оговорка про экономию: у текстовых позиций каталога поле prompt_cache сейчас отмечено как unsupported, поэтому скидку за повторяющийся префикс в расчёт закладывать нельзя — расход считается по полному объёму токенов.

Что означает доля ответов, которые правили перед отправкой

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

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

Важно фиксировать не только факт правки, но и её объём. Замена одного слова и переписанный абзац — разные события, а в отчёте без этого различия они выглядят одинаково.

Рост доли правок при неизменных остальных четырёх метриках — самый ранний из доступных сигналов. Поводы, по которым это происходит, и порядок разбора описаны в статье что делать, если нейросеть ошиблась.

Что показывает время до ответа

Смотрят 95-й перцентиль, а не среднее. Среднее прячет хвост: девять быстрых ответов маскируют один, после которого пользователь ушёл.

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

Тревожный сдвиг здесь — рост хвоста при стабильном среднем. Обычно это значит, что часть запросов регулярно упирается в лимит и уходит на повтор.

Какие метрики выглядят важными, но ничего не говорят

Три штуки встречаются в каждом втором отчёте.

Число запросов. Говорит о нагрузке, а не о качестве. Рост означает и интерес, и то, что с первого раза перестало получаться — по самой цифре не отличить.

Средняя длина ответа. Не связана с полезностью ни в одну сторону. Её сдвиг обычно означает, что кто-то поправил инструкцию, и узнать об этом можно из журнала версий, а не из графика.

«Удовлетворённость» без шкалы. Кнопка «палец вверх» собирает ответы от двух-трёх процентов пользователей, и это не случайная выборка: жмут довольные и очень недовольные. Такая цифра годится для иллюстрации, но не для решения.

Общий признак бесполезной метрики: после её изменения непонятно, что именно делать завтра.

Как понять, что модель стала отвечать хуже, если жалоб нет

Через две метрики сразу: доля правок и доля повторов. Обе растут раньше, чем появляется первая жалоба, потому что люди сначала обходят проблему молча.

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

Подтверждается это не спором, а прогоном сохранённой выборки. Тридцать-пятьдесят реальных обращений с эталонными ответами, прогнанные сегодня и месяц назад, дают сравнимый результат; как такую выборку собрать, описано в статье как тестировать нейросеть.

Откуда брать цифры, если ничего не пишется

Из журнала, и завести его придётся до того, как метрики понадобятся. Задним числом они не восстанавливаются: данных о правках и повторах в счёте поставщика нет.

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

Две недели записи дают базу для сравнения. До этого момента любое «стало хуже» — ощущение.

Как часто смотреть и что считать поводом вмешаться

Раз в неделю, одной таблицей на пять строк. Ежедневный просмотр на потоке в сотни обращений показывает шум и провоцирует правку инструкции ради самой правки.

Поводом вмешаться считаем изменение на 25 % за две недели при неизменном объёме. Меньшие колебания записываем и не трогаем.

У таблицы должен быть один читатель с правом остановить сценарий. Отчёт, который рассылается всем и не обязывает никого, перестаёт читаться на третьей неделе.

Чего мы не утверждаем

Мы не утверждаем, что этих пяти метрик хватит любому сценарию. В регулируемых отраслях список обязательных показателей задан требованиями надзора, и он длиннее.

Мы не утверждаем, что порог в 25 % за две недели универсален. Это рабочее значение для потока в сотни обращений; на десятках оно даст ложные срабатывания, на десятках тысяч — сработает слишком поздно.

Мы не утверждаем, что рост метрики всегда означает проблему в модели. Чаще меняется вход: приходит новый тип обращений, меняется сезон, кто-то правит инструкцию и не записывает версию.

Что нужно, чтобы попробовать

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог из 56 позиций.

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

Пять текстовых позиций после первого пополнения не тарифицируются. На них удобно прогнать сохранённую выборку и посмотреть, как считаются доли, прежде чем ставить замер на боевой поток.

Что держать в голове

Пять метрик, и все пять — про исход, а не про процесс. Доля передач человеку, повторы по той же теме, расход на задачу, доля правок, время до ответа по 95-му перцентилю.

Смотреть надо на сдвиг, а не на значение. Абсолютная цифра без истории не позволяет принять ни одного решения, а история начинается с первой записи в журнале.

Деградация приходит раньше жалоб и видна по правкам и повторам. Как мы проверяем факты и почему у каждой цифры стоит дата — на странице о проекте. Завести ключ и посмотреть, как выглядит расход по запросам: keydealer.ru/login.

Частые вопросы

Какие метрики смотреть после запуска нейросети?

Пять: доля обращений, дошедших до человека; доля повторных обращений по той же теме; расход на одну решённую задачу; доля ответов, которые правили перед отправкой; время до ответа по 95-му перцентилю. Остальное считают, когда эти пять уже собираются.

Почему нельзя считать расход на один запрос?

Потому что одна задача пользователя почти никогда не равна одному запросу: уточнения, повторы после неудачного ответа и передача человеку входят в ту же задачу. Счёт за запрос может падать, пока себестоимость результата растёт.

Как понять, что модель стала отвечать хуже, если никто не жалуется?

По двум метрикам сразу: растёт доля ответов, которые правили перед отправкой, и растёт доля повторных обращений по той же теме. Жалобы приходят на несколько недель позже, когда деградацию уже видно в цифрах.

Число запросов в день — это плохая метрика?

Как метрика качества — да, она говорит только о нагрузке. Для планирования лимитов и расхода число запросов нужно, но само по себе его изменение ничего не подсказывает: рост может означать и интерес, и то, что с первого раза перестало получаться.

Какой сдвиг метрики считать поводом вмешаться?

Изменение на 25 % за две недели при неизменном объёме обращений. Более мелкие колебания на потоке в сотни обращений — обычный шум, и реакция на них приводит к бесконечной правке инструкции без измеримого результата.

Что делать, если никаких цифр нет вообще?

Начать с журнала: время, идентификатор модели, версия инструкции, признак правки и исход обращения. Две недели записи дают базу, с которой можно сравнивать. Задним числом метрики не восстанавливаются.

Источники