Бенчмарки для русского языка: где общие тесты врут

Почему общий тест не показывает реальное качество

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

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

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

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

Общий балл чаще всего скрывает четыре вещи:

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

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

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

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

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

Где русский ломает шаблонные задания

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

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

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

Числительные тоже хорошо ловят просадки модели. После "2", "5" и "21" слово меняется по-разному, и многие модели путаются уже на простых примерах: "2 документа", "5 документов", "21 документ". Если добавить род, падеж и деловой контекст, ошибок становится еще больше: "с 22 сотрудниками", "по 3 заявкам", "о 11 клиентах".

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

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

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

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

Почему длинные инструкции меняют итог

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

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

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

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

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

Проверьте хотя бы четыре вещи:

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

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

Как проверять деловой стиль без вкусовщины

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

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

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

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

Проще всего отмечать не "красоту", а рабочие дефекты:

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

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

Помогает короткая шкала из 4-5 пунктов с оценкой 0 или 1. Есть нужный тон. Есть обязательные оговорки. Нет лишней самоуверенности. Формулировки точные. Текст решает задачу без лишнего объема. Такой способ проще защитить перед командой, чем бесконечный спор о том, какая модель "пишет приятнее".

Как собрать свой набор шаг за шагом

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

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

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

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

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

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

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

Пример с ответом для службы поддержки банка

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

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

Здравствуйте, Иван!

Мы получили ваше заявление на перевыпуск дебетовой карты.
Карта будет готова в течение 5 рабочих дней. Получить карту за пределами РФ нельзя, банк выдает ее только в офисах на территории России.

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

С уважением,
служба поддержки

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

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

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

Ошибки при сравнении моделей

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

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

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

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

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

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

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

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

Проверьте пять вещей:

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

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

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

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

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

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

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

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

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

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

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

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