Онлайн и офлайн оценка качества: когда чему верить

Где возникает путаница

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

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

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

То же и с конверсией. Иногда она растет не из-за модели, а из-за скидки, нового экрана, сезона или просто другого трафика. В такой момент легко похвалить ответ не за то. А ошибка внутри ответа никуда не делась.

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

Обычно спор сводится к двум вопросам:

• Полезен ли ответ человеку в реальной задаче?
• Ошибается ли ответ там, где ошибка дорого стоит?

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

Что показывают онлайн-метрики

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

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

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

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

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

• жалобы после диалога
• эскалации на оператора
• отмены уже начатого действия
• повторные обращения по той же теме
• рост времени до решения вопроса

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

Что дает офлайн-проверка

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

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

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

Удобно делить офлайн-оценку на четыре части:

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

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

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

Когда онлайн вводит в заблуждение

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

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

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

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

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

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

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

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

Когда офлайн тоже ошибается

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

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

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

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

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

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

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

Как выстроить оценку по шагам

Онлайн- и офлайн-оценка работают, когда команда отвечает на один конкретный вопрос, а не пытается измерить все сразу. Вместо "модель стала лучше?" лучше спросить: "Ассистент реже отправляет оператора перепроверять правило?" или "Ответ помогает закрыть типовой запрос без эскалации?" Один сценарий сразу делает проверку честнее.

1. Сформулируйте один рабочий вопрос для одного сценария. Не смешивайте в один тест возвраты, поиск по базе и проверку документов. Для каждого случая нужны свои критерии.
2. Выберите пару метрик. Одна должна показывать эффект в работе: долю решенных обращений, среднее время обработки или число повторных контактов. Вторая должна измерять качество вне трафика: точность по рубрике, полноту ответа, фактологичность, соблюдение политики, отсутствие утечки PII.
3. Соберите свежий набор из реальных обращений. Лучше брать недавние диалоги, а не старые примеры, к которым команда уже привыкла. Добавьте и обычные случаи, и трудные: неполный контекст, двусмысленный вопрос, конфликтующие правила. Спорные примеры отдайте на экспертную проверку. Именно там видно, где слаба рубрика, а где ошибается модель.
4. Запустите A/B-тест на малой доле трафика. Так команда дешевле ловит проблемы и не рискует всем потоком сразу. Смотрите не только на клики и конверсии, но и на жалобы, эскалации, ручные правки и редкие, но дорогие ошибки.
5. После теста верните все новые промахи в набор. Если модель сорвалась на новом типе запроса, этот пример должен попасть в офлайн-проверку перед следующим релизом. Так набор не застывает и начинает отражать реальную работу системы.

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

Пример: ассистент в поддержке банка

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

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

Офлайн

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

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

Онлайн

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

Полезно смотреть и на повторные обращения по той же теме через 10-30 минут. Клиент мог нажать "полезно", а потом вернуться с тем же вопросом про карту или перевод. Для поддержки это плохой сигнал.

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

Короткий чек-лист перед релизом

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

Для онлайн- и офлайн-оценки полезна одна дисциплина: договориться о правилах до старта, а не после первых графиков.

• Выберите одну главную метрику на этот тест. Если ассистент отвечает в поддержке, это может быть доля диалогов без перевода на оператора. Остальные числа оставьте вспомогательными.
• Проверьте, что офлайн-набор собран из свежих запросов за последние недели. Старый набор часто не ловит новые формулировки, сезонные темы и свежие ошибки пользователей.
• Дайте экспертам одну инструкцию и несколько одинаково разобранных примеров. Иначе один человек снижает оценку за осторожный тон, а другой считает его нормой.
• Пускайте эксперимент на ровном участке трафика. Если в эти дни у вас акция, сбой в соседнем сервисе или резкий приток новых пользователей, клики и конверсии будут шуметь.
• До старта запишите условие остановки. Нужны срок теста, минимальный объем трафика и понятный порог, после которого команда останавливает эксперимент или выкатывает релиз.

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

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

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

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

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

Дальше держите один и тот же ритм:

• прогоняйте офлайн-тест перед каждым заметным изменением модели или промпта
• после релиза смотрите онлайн-метрики на ограниченном трафике
• разбирайте случаи, где офлайн и онлайн дали разный сигнал
• фиксируйте решение команды и причину, почему вы ему доверяете

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

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

Для продакшен-команд это особенно удобно, когда модели можно быстро переключать без переписывания интеграции. В AI Router для этого используют один OpenAI-совместимый эндпоинт, а audit-логи помогают потом проверить, какая модель, настройка или маршрут дали сбой в конкретном диалоге.

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