SLO для LLM-приложений: как считать по целям бизнеса

Где метрики начинают врать

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

Первая ловушка проста: команда мерит то, что удобно системе, а не то, что важно сервису. График времени ответа не показывает, понял ли бот вопрос, выдал ли нужный формат и не отправил ли человека по кругу. Если из 100 ответов 92 приходят быстро, а 8 ломают сценарий оплаты или подачи заявки, сервис уже бьет по бизнесу, даже если дашборд выглядит спокойно.

Чаще всего врет средняя задержка. Один ответ за 200 мс и один таймаут за 20 секунд дают среднее, которое звучит терпимо. Для живого сервиса важнее хвосты: сколько запросов укладывается в 2 секунды, сколько уходит в таймаут, сколько требует повторной попытки. Пользователь запоминает не среднее значение, а тот случай, когда чат завис и все пришлось писать заново.

Цена тоже легко обманывает. Дешевая модель на один вызов может выйти дороже по итогу, если она чаще просит уточнение, путает поля в JSON или дает текст, который нельзя отправить клиенту без правки. Тогда один "экономный" запрос превращается в два или три, а следом появляется ручная работа команды. В поддержке это заметно сразу: оператор тратит не 30 секунд на проверку, а 3 минуты на спасение диалога.

Когда задержка, доля валидных ответов и стоимость живут отдельно, команда спорит вместо того, чтобы что-то исправить. Инженеры говорят, что система быстрая. Финансы видят нормальный расход на токены. Бизнес видит, что завершенных сценариев стало меньше. SLO для LLM-приложений начинает работать только тогда, когда эти три метрики связаны между собой.

Даже если команда использует API-шлюз вроде AI Router, проблема никуда не исчезает. Один OpenAI-совместимый endpoint упрощает сравнение моделей, маршрутов и провайдеров, но не отвечает на главный вопрос: пользователь решил задачу с первого раза или нет.

Что бизнес ждет от ответа модели

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

Поэтому начните с простого вопроса: зачем человек вообще открывает этот экран или отправляет этот запрос? Ответ должен описывать конкретную работу, а не общую пользу. Не "помогает сотрудникам", а "сокращает разбор входящего письма до двух минут" или "дает первый черновик ответа, который менеджер правит за 30 секунд".

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

Дальше нужна простая граница между "годно" и "не годно". Не ищите идеальный ответ. Ищите ответ, после которого человек не переделывает все с нуля. Обычно спор исчезает, когда команда записывает 3-4 признака нормального результата: верный формат, отсутствие выдуманных фактов, нужные поля, смысл по запросу.

Цена здесь тоже часто сбивает с толку. Стоимость одного вызова почти ничего не говорит бизнесу. Если модель отвечает дешево, но каждый пятый запрос уходит на повтор, ручную правку или на более дорогой fallback, задача уже стоит заметно дороже.

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

Нормальная формулировка ожиданий звучит приземленно: система за 5 секунд готовит черновик ответа по документу, в 90% случаев юрист вносит только мелкие правки, средняя цена одной завершенной проверки укладывается в бюджет. С таким описанием бизнес уже не подменишь красивым графиком задержки.

Какие метрики войдут в SLO

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

По задержке смотрите на p95 или p99, а не на среднее. Средняя цифра почти всегда выглядит прилично, даже когда заметная часть пользователей ждет слишком долго. Если чат отвечает в среднем за 2 секунды, но каждый двадцатый запрос висит 12 секунд, люди запомнят именно это.

Долю валидных ответов тоже нельзя мерить "на глаз". Сначала задайте явные правила: ответ по теме, в нужном формате, без выдуманных фактов, без запрещенного контента, с заполненными обязательными полями, если это JSON или форма. Тогда спор о качестве превращается в проверку по чек-листу, а не в обмен мнениями.

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

Не смешивайте разные типы задач

У чата, поиска, классификации и агентных сценариев разные ожидания, поэтому общий SLO по всем сразу почти бесполезен. Для чата обычно важны p95 задержки и доля ответов без смысловых ошибок. Для поиска с генерацией добавляются точность ссылок на источник и число пустых ответов. Для классификации важнее точность по классам и стабильный формат вывода. Для агентных задач нужно считать завершение всего сценария, а не только первый ответ модели.

Если вы маршрутизируете запросы через общий шлюз, считайте метрики отдельно по типу задачи, модели и провайдеру. Иначе одна быстрая модель скроет медленную, а дешевый маршрут замаскирует дорогие повторы. Дашборд будет выглядеть красиво, но так и не объяснит, что именно получает бизнес за свои деньги.

Как собрать SLO по шагам

SLO для LLM-приложений лучше собирать не от дашборда, а от тех задач, где ответ модели влияет на деньги, нагрузку на людей или риск ошибки. Если брать все запросы сразу, получится красивое среднее и мало пользы.

Начните с 2-4 сценариев, где эффект можно увидеть в работе команды. Обычно хватает ответа клиенту в чате, разбора обращения, поиска по базе знаний и черновика для оператора. Большее число сценариев на старте только путает.

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

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

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

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

Небольшой пример. Если чат-бот должен экономить время первой линии, цель можно записать так: p95 не выше 6 секунд, валидные ответы не ниже 92%, цена не выше 18 тенге за успешный диалог. Команда сразу видит компромисс. Модель может отвечать быстрее, но чаще ошибаться. Или отвечать лучше, но съедать бюджет.

Если вы меняете модель через AI Router или другой совместимый шлюз, не переносите SLO автоматически на новый маршрут. Один и тот же промпт на другой модели часто меняет и задержку, и долю годных ответов, и стоимость. Неделя проверки на свежем трафике обычно экономит больше времени, чем потом исправление плохо выбранного порога.

Как считать долю валидных ответов

Если модель отвечает быстро, но не решает задачу, график задержки ничего не спасает. Поэтому долю валидных ответов считают не по общему впечатлению, а по простому правилу: ответ засчитывается только тогда, когда он выполнил задачу без критических ошибок.

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

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

Для задач со строгой структурой проверку лучше автоматизировать полностью. Если модель должна вернуть JSON, поля, типы, обязательные значения и длину ответа можно проверить кодом. То же касается классификации, выбора категории, обязательных предупреждений и работы по шаблону. Здесь ручная оценка часто только тратит время.

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

Оценка "понравилось" почти всегда портит метрику. Пользователю может не нравиться тон ответа, хотя задача решена. Бывает и наоборот: текст звучит уверенно, но в нем ошибка. Для SLO важнее другой вопрос: выполнил ли ответ задачу по правилам.

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

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

Хорошая метрика не спорит с операторами, продуктом и финансами. Она показывает, сколько ответов реально можно было использовать в работе.

Пример для службы поддержки

Оператору банка не нужен идеальный текст. Ему нужен черновик, который приходит быстро, не придумывает лишнего и правда экономит время. Поэтому SLO для LLM-приложений в поддержке лучше считать по пригодному ответу, а не по красивой средней задержке.

Представим простой сценарий. Клиент пишет в чат по спорной операции по карте. Модель готовит черновик ответа для оператора. Если черновик приходит позже 4 секунд, оператор обычно не ждет и пишет сам. Средняя задержка тут почти бесполезна: даже если она равна 1,8 секунды, длинный хвост все ломает. Для команды важнее другое правило: в 95% случаев ответ должен прийти не позже 4 секунд.

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

Есть и более жесткая проверка на пользу. Оператор может слегка поправить формулировку, это нормально. Но если он меняет больше двух фрагментов, черновик не сработал. Он занял время вместо того, чтобы сэкономить его.

В таком кейсе SLO можно описать четырьмя правилами: 95% ответов приходят за 4 секунды или быстрее, валидный ответ не содержит выдуманных условий, включает все обязательные поля, а цена считает и повторный запрос после ошибки или таймаута.

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

Допустим, из 1000 обращений 950 ответов пришли вовремя. Из них 890 прошли проверку на валидность. Еще в 80 случаях оператору пришлось править больше двух фрагментов. Значит, пригодных черновиков осталось 810. Если при этом система сделала 60 повторных запросов после таймаутов и ошибок, бизнес смотрит на цену 810 полезных результатов, а не на отчет с "успешными" 1000 запросами.

Такой расчет быстро меняет разговор. Дешевая модель может проиграть, если она чаще ошибается или дольше отвечает. А более дорогая модель может выйти дешевле, если она дает больше пригодных ответов без повторов и лишней правки.

Где команды ошибаются

Чаще всего команда берет то, что легко показать на графике, и выдает это за реальное качество сервиса. Так SLO для LLM-приложений быстро превращается в витрину, а не в рабочий договор с бизнесом.

Первая ошибка - смотреть на среднюю задержку. Среднее почти всегда успокаивает. Если семь ответов пришли за 2 секунды, а три за 18, цифра выглядит терпимо. Для пользователя и оператора это уже плохой опыт: диалог рвется, человек жмет "отправить" еще раз, а стоимость и число ошибок растут.

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

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

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

Отдельная ошибка - прятать труд оператора за пределами общей метрики. Модель ответила за 4 секунды, и формально все хорошо. Но если оператор потом 90 секунд исправляет текст, удаляет лишнее и дописывает факты, сервис сработал плохо.

На практике полезнее держать перед глазами не одну "красивую" цифру, а четыре: p95 или p99 задержки вместо среднего, долю валидных ответов на живом трафике, стоимость одного завершенного кейса, а не только токенов, и долю ответов, которые оператор исправил вручную.

Если эти метрики двигаются в правильную сторону, сервис помогает делу. Если растет только средняя скорость на графике, а команда поддержки злится, график можно закрыть.

Быстрые проверки перед запуском

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

Сначала разложите продукт на отдельные сценарии. Ответ в чате поддержки, авторазбор обращения и генерация внутренней сводки - это разные задачи. У каждой должен быть владелец, который может назвать пороги по задержке, доле валидных ответов и допустимой цене результата. Если владельца нет, спор о качестве начнется уже после запуска.

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

Если вы используете AI Router, заранее проверьте, что в логах и аудит-записях сохраняются эти поля. Сам по себе единый шлюз не решает вопрос наблюдаемости. Он только делает сравнение маршрутов удобнее, если команда изначально договорилась, что именно она считает успехом.

Дашборд тоже должен делить исходы хотя бы на четыре группы: успешный ответ без правок, отказ или блокировка, таймаут или техническая ошибка, ответ, который человек исправил вручную. Если все это сложено в одну цифру "успешности", команда увидит проблему слишком поздно. Особенно часто так маскируются ручные правки: формально ответ есть, по факту сотрудник потратил еще 3 минуты и переписал половину текста.

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

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

Такой набор проверок занимает пару часов. Зато потом видно, где именно сервис перестал выполнять свою работу.

Что делать дальше

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

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

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

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

Имеет смысл смотреть не только на крупных провайдеров, но и на open-weight модели. Иногда они уступают в общей силе, но выигрывают по цене, задержке или требованиям к данным. Для команд в Казахстане такое сравнение удобно делать через AI Router: можно менять только base_url на api.airouter.kz и прогонять одинаковые запросы через разные модели и провайдеров без смены SDK, кода и промптов. Это упрощает эксперимент, но сами пороги SLO все равно нужно проверять на живом трафике.

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