A/B-тесты для LLM: почему CTR не показывает качество

Почему CTR и время часто врут

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

Пользователь часто кликает не потому, что ответ хороший, а потому что что-то смутило. Он открывает источник, жмет "показать больше", копирует кусок текста или переспрашивает из простого любопытства. В таком случае высокий CTR показывает не пользу, а трение.

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

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

Поведение зависит от интерфейса сильнее, чем кажется

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

Хороший пример - внутренний помощник поддержки. Вариант A пишет длинно: приветствие, дисклеймер, три абзаца фона и только потом инструкцию. Вариант B дает четыре строки по делу. У A выше время в окне и больше кликов по дополнительным элементам. У B сессия короче, зато сотрудник быстрее закрывает заявку. Если смотреть только на CTR и dwell time, легко выбрать худший вариант.

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

Что считать хорошим ответом

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

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

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

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

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

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

Какие сигналы брать вместо прокси из интерфейса

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

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

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

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

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

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

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

Как выбрать метрику под свой сценарий

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

В A/B-тестах для LLM лучше брать сигнал, который стоит ближе к итоговому результату. Сначала ответьте на два вопроса: что пользователь хотел сделать и как выглядит ошибка в этом сценарии. После этого метрика обычно находится быстро.

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

Примеры для разных задач

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

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

В RAG стоит смотреть на точность цитат и опору на источник. Сколько утверждений в ответе реально подтверждаются документом? Сколько цитат передают смысл без искажения? Это честнее, чем считать клики по кнопке "полезно".

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

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

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

Как провести тест

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

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

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

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

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

Пример на простой задаче

Банк тестирует помощника для оператора колл-центра. Модель читает обращение клиента и предлагает готовый ответ: что сказать, что проверить в CRM и когда подключать старшего смены. Команда сравнивает два варианта. Вариант A пишет коротко: 3-4 предложения и один понятный следующий шаг. Вариант B пишет подробнее: объясняет причины, перечисляет риски и добавляет запасные формулировки.

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

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

Допустим, CTR у A и B почти одинаковый: 42% и 43%. Если остановиться на этом, тест даст ложный вывод. По рабочим метрикам разница уже заметна. С вариантом A банк закрывает 71% обращений без эскалации, а с вариантом B - 66%. Повторные обращения по той же теме тоже ниже у A, потому что оператор не размазывает ответ и не теряет следующий шаг.

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

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

Где тест ломается

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

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

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

Что чаще всего портит сравнение

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

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

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

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

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

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

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

Перед стартом полезно проверить пять вещей:

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

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

Стоп-метрика нужна не для красоты. Если модель стала чаще выдумывать факты, путать тарифы или раскрывать лишние данные, тест надо останавливать, даже если главная метрика выросла.

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

Если сравниваете маршруты или модели через RU LLM, держите остальную конфигурацию одинаковой: один системный промпт, одинаковые temperature, лимиты, кэширование и правила логирования. Иначе тест покажет разницу в настройках, а не в качестве ответа.

Что делать после результата

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

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

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

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

Повторный прогон после правок

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

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

Когда команда сравнивает много моделей и провайдеров, единый OpenAI-совместимый endpoint действительно упрощает жизнь. В RU LLM можно прогонять одни и те же запросы через разных провайдеров, а логи и аудит-трейлы хранить внутри РФ. Это не заменяет оценку качества, но помогает не утонуть в версиях, логах и ручной сборке эксперимента.

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