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 % за две недели при неизменном объёме обращений. Более мелкие колебания на потоке в сотни обращений — обычный шум, и реакция на них приводит к бесконечной правке инструкции без измеримого результата.
Что делать, если никаких цифр нет вообще?
Начать с журнала: время, идентификатор модели, версия инструкции, признак правки и исход обращения. Две недели записи дают базу, с которой можно сравнивать. Задним числом метрики не восстанавливаются.