Отраслевые evals для банка и телекома: как собрать набор

Почему общие тесты почти бесполезны

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

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

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

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

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

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

Где брать реальные сценарии

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

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

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

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

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

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

Как очистить и обезличить материалы

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

Сначала уберите прямые идентификаторы: ФИО, номера телефонов, адреса, e-mail, номера счетов, карт, договоров, лицевых счетов, паспортные и другие документные данные. Простое правило такое: если поле не меняет правильный ответ модели, удаляйте его.

Если деталь нужна для логики сценария, не храните исходное значение. Заменяйте его на метку или шаблон. Например, "Иван Петров" можно превратить в "Клиент_1", "+7 9XX..." в "Телефон_1", "Договор 4582-77" в "Договор_A". После такой замены перечитайте кейс и оставьте только тот контекст, который влияет на ответ.

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

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

Автоматической чистки мало. Регулярные выражения и NER быстро находят телефоны, почту и паспортные шаблоны, но легко пропускают фразы вроде "живу рядом с ТЦ" или "переводил жене с зарплатной карты". Поэтому часть выборки надо проверять вручную и смотреть текст глазами. Если вы прогоняете набор через RU LLM, помните, что у сервиса есть маскирование PII и аудит-трейлы, но ручную проверку это все равно не отменяет.

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

Кто утверждает эталоны

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

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

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

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

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

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

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

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

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

Рабочий объем для первого прохода - примерно 100-300 сырых кейсов по одной задаче. Этого хватает, чтобы увидеть повторяющиеся паттерны, редкие углы и плохие ответы модели. Меньший набор часто получается слишком гладким.

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

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

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

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

Шаг 5 - прогоните пилот на 20-30 кейсах. На этом этапе почти всегда всплывают дыры: слишком жесткий эталон, размытые критерии, одинаковый штраф за разные ошибки. Лучше чинить это сразу, пока набор маленький.

Если вы работаете в среде с требованиями по 152-ФЗ, обезличивайте материалы до того, как они попадут в eval-набор. Имена, телефоны, номера договоров, адреса и номера карт лучше маскировать автоматически, а потом проверять выборочно вручную.

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

Пример: спорный платеж и перенос номера

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

Спорный платеж в банке

Клиент пишет, что не узнает списание на 12 480 рублей и просит срочно вернуть деньги. Слабый ответ сразу обещает возврат, объявляет операцию мошенничеством или придумывает причину списания. Такой кейс надо проваливать.

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

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

Перенос номера в телекоме

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

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

В обоих примерах оценка обычно смотрит на четыре вещи:

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

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

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

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

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

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

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

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

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

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

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

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

Вот короткий чек перед запуском:

• Проверьте состав набора. В нем должны быть частые, редкие и рискованные кейсы. Если у вас 100 сценариев, 10-15 рискованных обычно нужны обязательно.
• Убедитесь, что у каждого кейса есть цель, эталон и понятный вердикт. Оценщик должен сразу понимать, что считать успехом.
• Дайте одну и ту же выборку двум или трем разметчикам. Если они расходятся слишком часто, проблема обычно в правилах, а не в людях.
• Проверьте обезличивание руками. Возьмите 20-30 случайных кейсов и попробуйте понять, можно ли узнать клиента по косвенным данным.
• Назначьте владельца набора после релиза. Один человек вносит правки, второй согласует спорные изменения со стороны бизнеса или комплаенса.

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

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

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

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

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

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

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

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

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