Eval-набор для русских сокращений и жаргона в компании

Почему обычный тест не ловит ваш жаргон

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

Публичные тесты проверяют средний язык. В них почти нет фраз вроде "проверь ДБО по юрику", "сверь ЭДО с контрагентом" или "по МЧД не проходит подписание". Для модели это не бытовая речь, а набор коротких форм, которые легко спутать или привязать не к той теме.

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

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

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

Поэтому цифра вроде "модель набрала 86%" успокаивает раньше времени. Она не показывает, поймет ли модель живой звонок с обрывками фраз, комментарий в тикете или переписку, где люди пишут "скинь МЧД", "заведи в ЭДО" и ничего не поясняют.

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

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

Откуда брать материал для набора

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

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

Потом добавьте расшифровки звонков и чаты. Живая речь почти всегда грязнее текста. Люди проглатывают слова, путают названия систем, сокращают фразы до "это не пролилось", "доки не ушли", "заявка висит в АРМ". Именно на таком материале модель чаще всего спотыкается.

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

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

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

Чистку данных лучше делать сразу. Удаляйте или маскируйте ФИО, телефоны, почту, номера договоров, адреса, служебные идентификаторы и все, по чему можно узнать клиента или сотрудника. Если вы работаете в российском контуре, такой порядок заметно сокращает время на согласования и снижает риск лишних копий данных. В среде вроде RU LLM это хорошо сочетается с хранением логов и бэкапов внутри РФ и маскированием PII, но сами данные все равно лучше приводить в порядок до запуска.

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

Какие примеры стоит отбирать

Хороший eval ломает модель не на учебных фразах, а на живой речи сотрудников. Нужны примеры, где одно сокращение означает разное в соседних командах. "АП" может быть "автоплатежом", "актом приема" или внутренним этапом процесса. "ЛК" часто читают как "личный кабинет", но в части компаний это еще и "лицевой счет". Такие случаи быстро показывают, понимает ли модель контекст или просто угадывает.

Полезны короткие реплики без полного фона. Так люди и пишут в тикетах, и говорят на звонках: "Клиент просит переоткрыть ЛК, КП не подтянулось", "По СБ вернулся отказ, проверь ПД". Если фраза понятна только сотруднику отдела, она подходит для набора. В реальной работе модель почти никогда не получает идеальную постановку задачи.

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

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

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

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

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

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

Рабочая последовательность обычно простая:

1. Выберите процессы с понятным риском ошибки. Например, в саппорте модель путает внутренние аббревиатуры в тикетах, а в расшифровках звонков не понимает короткие устные формы.
2. Соберите сырой пул примеров по каждому процессу. Берите тикеты, чаты, звонки, заметки операторов, шаблоны ответов. На старте лучше собрать 100-200 фрагментов, чем долго спорить о полноте.
3. Почистите тексты аккуратно. Уберите ФИО, телефоны, номера договоров и другие чувствительные данные, но не переписывайте саму фразу. Авторская формулировка важнее аккуратного вида.
4. Разложите примеры по типам задач. Одни случаи проверяют расшифровку сокращения, другие - выбор нужного смысла из двух похожих, третьи - умение модели запросить уточнение, если контекста мало.
5. Зафиксируйте версию набора и источник каждого примера. Для каждого фрагмента полезно хранить процесс, канал, дату выгрузки, автора разметки и короткий комментарий, почему пример попал в тест.

Лучше слегка недочистить текст, чем превратить живой тикет в учебник. Если сотрудник пишет "КД не поднялся после релиза, проверь АРМ", именно эта форма и нужна в eval. Модель должна пройти тот тест, который ей задаст реальная команда, а не редактор.

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

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

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

Как задать эталон и правила оценки

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

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

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

Простая шкала

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

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

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

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

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

Пример кейса из реальной поддержки

Хороший тест часто начинается с одного грязного, живого кейса. Например, в очереди поддержки появляется тикет: "Не проходит ЭДО после смены КЭП. Документы уходят, но контрагент их не видит".

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

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

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

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

Самый полезный ход модели здесь - задать один точный вопрос. Например: "После выпуска нового КЭП МЧД перевыпускали или перепривязывали к новому сертификату, и в каком контуре сейчас идет отправка?" Такой вопрос не уводит разговор в сторону и быстро сужает поиск.

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

Какие ошибки чаще всего портят eval

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

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

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

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

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

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

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

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

Один быстрый прогон часто экономит день споров о том, почему eval "сломался". Перед стартом проверьте не качество модели, а сам набор: достаточно ли он живой, понятный и чистый.

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

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

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

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

Перед первым прогоном уберите чувствительные данные. Не оставляйте ФИО, телефоны, номера договоров, почту, внутренние ID и свободные комментарии, где клиент мог написать лишнее. Для команд с требованиями по 152-ФЗ это базовая гигиена. Если вы прогоняете набор через RU LLM, где обработка, логи и бэкапы остаются в РФ, это упрощает организационную часть, но чистить данные все равно нужно заранее.

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

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

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

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

Смотреть стоит на несколько вещей:

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

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

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

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

Для такого сравнения удобно, когда все модели доступны через один OpenAI-совместимый эндпоинт. В RU LLM можно прогонять один и тот же eval через разные модели без переписывания SDK, кода и промптов, а для чувствительных данных оставить обработку внутри российского контура.

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