Проверка LLM на 10 миллионах диалогов в телекоме

Почему архив из 10 миллионов диалогов ломает обычную проверку

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

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

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

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

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

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

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

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

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

Удобно заранее зафиксировать простую матрицу:

• Инфо-запросы: точность 95%+, полнота 90%+
• Операции с риском: безопасность 99,5%+, без пропуска обязательных шагов
• Жалобы и эскалации: точность 90%+, тон 98%+
• Продажи и апсейл: точность 92%+, без выдуманных обещаний

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

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

Как собрать рабочую выборку

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

Сначала разрежьте архив на понятные слои. Для телеком-команды обычно хватает пяти осей: тема обращения, канал общения, регион, линия поддержки и длина диалога. После этого берите не только пропорциональную долю, но и минимальный объем из каждого слоя. Если роуминг дает 0,8% архива, случайная выборка почти не поймает нужные случаи. Лучше сразу поставить нижний порог, например 300-500 диалогов на редкую тему, чтобы проверять модель на реальных примерах, а не на удаче.

Что добавлять отдельно

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

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

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

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

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

Как превратить диалоги в тестовые кейсы

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

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

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

До любого прогона замаскируйте персональные данные. Номера телефонов, ФИО, адреса, номера договоров и лицевых счетов не нужны модели для честной проверки качества. Ей нужен смысл задачи: клиент не может подключить роуминг, спорит со списанием или просит перенести номер. Если команда прогоняет кейсы через RU LLM на rullm.com, маскирование PII и аудит-трейлы удобно включить в этот же этап.

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

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

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

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

Как провести пакетный прогон

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

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

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

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

Что писать в лог

Без нормального лога пакетный прогон быстро превращается в шум. Для каждого кейса сохраняйте:

• входной текст или собранный контекст
• ответ модели
• число входных и выходных токенов
• задержку
• версию модели, промпта и провайдера

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

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

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

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

Как разметить ошибки без чтения всего массива

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

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

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

Смотрите на действие, а не только на текст

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

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

Короткая таксономия обычно работает лучше длинной:

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

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

Когда подключать вторую модель

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

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

Пример на телеком-сценарии

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

Берите не один вид разговора, а смесь. Короткий чат на две реплики покажет, умеет ли модель сразу задавать нужный уточняющий вопрос. Длинный звонок с эскалацией покажет, держит ли она контекст после 15-20 реплик и не теряет ли причину жалобы.

Обычно хватает четырех сегментов:

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

В этом наборе быстро видно, где модель путает пакет, опцию и тариф. Это частая ошибка. Клиент пишет: "У меня был пакет в роуминге, почему списали деньги?" Модель отвечает общими словами и не различает, что пакет мог покрывать только интернет, опция - только отдельные страны, а тариф вообще не включал льготный роуминг. Формально ответ спокойный, но по сути неверный.

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

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

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

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

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

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

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

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

Есть и набор кейсов, которые команды часто забывают вынести отдельно:

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

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

Короткая проверка перед финальным отчетом

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

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

Потом разложите стоп-ошибки по сегментам. Один общий процент мало что дает. Гораздо полезнее увидеть, где именно модель опасна: в удержании, в финансовых спорах, в техподдержке, в продажах, в VIP-очереди. Если в одном сегменте стоп-ошибок 0,3%, а в другом 4%, это уже не средняя температура, а явный риск.

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

Что стоит сверить вручную

Перед отправкой отчета полезно просмотреть короткий набор примеров:

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

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

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

Что делать после первого прогона

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

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

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

Практичный порядок такой:

• собрать 5-10 классов ошибок с самым высоким ущербом
• для каждого класса отобрать по 30-50 подтвержденных примеров и контрпримеров
• переписать правила разметки так, чтобы два аналитика принимали одно и то же решение
• запустить второй цикл только на спорных сегментах, а не на всем архиве

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

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

Если команде нужен единый OpenAI-совместимый эндпоинт для пакетного прогона через разных провайдеров, такой цикл удобно держать в RU LLM: можно менять base_url и продолжать работать с теми же SDK, кодом и промптами. Для российских команд это еще и упрощает требования по хранению логов и работе с персональными данными внутри РФ.

И отдельный блок стоит вынести под 152-ФЗ, даже если качество ответа уже устраивает. Проверьте, где система хранит логи и бэкапы, как маскирует PII и можно ли поднять аудит-трейл по конкретному запросу. В телекоме именно этот пункт часто решает судьбу пилота не меньше, чем точность самой модели.