Содержание
Проверка качества языковой модели — это не один экзамен и не процент «правильных ответов» с публичной таблицы. Разные тесты отвечают на разные утверждения: умеет ли модель решать школьные задачи, следует ли инструкции, выдумывает ли факты, обходит ли запреты, не сломала ли вчерашняя смена промпта ваш продукт. Смешать их в один балл — значит получить число, которое нельзя ни объяснить, ни откатить.
Ниже — карта видов проверок для инженеров и технических лидеров: что именно измеряет каждый класс, где он врёт и как собрать набор под конкретный сервис, а не под чужой рейтинг. Как встроить эти проверки в конвейер выпуска — в контуре оценки ИИ. Управленческий взгляд на метрики предприятия — в оценке корпоративного ИИ.
Ключевые выводы
Качество модели — несколько независимых свойств. Возможности («может ли решить задачу»), надёжность («решает ли её стабильно»), безопасность («не делает ли запрещённого»), соответствие продукту («помогает ли в нашем сценарии») и стоимость («укладывается ли в бюджет токенов и задержки») меняются порознь. Высокий балл на открытом наборе знаний не гарантирует безопасный отказ в вашей справке.
Тест проверяет утверждение, а не «ум». Набор вроде экзамена с вариантами ответа проверяет выбор из закрытого списка. Исполнение сгенерированного кода проверяет, проходит ли программа скрытые случаи. Сравнение двух ответов людьми проверяет предпочтение стиля и полезности, а не истинность. Пока утверждение не названо, цифра из отчёта неинтерпретируема.
Публичный рейтинг — чужая выборка с чужой ценой ошибки. Он полезен как грубый фильтр кандидатов. Для выпуска нужен собственный набор: ваши формулировки, ваши запреты, ваши эталоны и ваш ущерб от ложного согласия.
Автоматический судья — ускоритель, не истина. Модель, которая оценивает другую модель, наследует её слепые зоны и меняется вместе с версией. Её калибруют на человеческой разметке и не ставят единственным барьером там, где цена ошибки высока.
Регрессия продукта важнее охоты за публичным рейтингом. Падение на пяти ваших критичных сценариях важнее прироста на тысяче чужих вопросов. Скрытая контрольная выборка и версионирование набора защищают от подгонки промпта под известный тест.
Что называют качеством языковой модели
Для функции с фиксированным входом и выходом «тест» обычно значит: при этих аргументах получается этот результат. У языковой модели вход — свободный текст, выход — распределение следующих токенов, а «правильный» результат часто не единственный. Поэтому качество приходится раскладывать на слои.
Возможности — верхняя граница того, что модель вообще умеет на классе задач: математика, код, извлечение полей, следование длинной инструкции. Их измеряют на открытых и закрытых наборах, часто в нулевом обучении на примерах или с несколькими демонстрациями.
Надёжность — насколько стабилен этот уровень. Одна и та же задача при температуре выше нуля, при перефразировании вопроса или при смене системной инструкции может дать другой ответ. Команда, которая гоняет набор один раз при температуре ноль, измеряет потолок, а не поведение в чате.
Фактичность и обоснованность — не выдумывает ли модель факты и опирается ли на поданный контекст. Это разные свойства. Модель может честно отказаться и быть фактичной, но бесполезной. Может красиво ответить по корпусу и всё равно исказить цифру в таблице.
Следование инструкциям и формату — соблюдает ли ограничения: язык, схему JSON, запрет на определённые темы, длину, тон, использование только указанных инструментов. Для агентов и шлюзов это часто важнее «общих знаний».
Безопасность и политики — отказ от запрещённых действий, устойчивость к внедрению инструкций, утечкам системного промпта и обходу ограничений. Падение здесь — инцидент, даже если остальные графики зелёные.
Продуктовая пригодность — решает ли модель ваши задачи при ваших правах доступа, задержке и цене. Этот слой нельзя купить чужим рейтингом.
Публичные наборы задач: знания, математика, код, рассуждения
Открытые наборы — это стандартизированные экзамены. Их сила в сравнимости между лабораториями. Их слабость — в том, что они измеряют чужой экзамен, часть которого могла попасть в данные обучения.
Классические наборы знаний вроде MMLU проверяют выбор ответа из нескольких вариантов по школьным и университетским предметам. Это удобно считать: есть ключ, есть доля верных. Это плохо переносится на свободный ответ в продукте: модель может угадать букву и не уметь объяснить, или наоборот — дать верное рассуждение и споткнуться о формат бланка. Многопредметность маскирует провал в одном домене, если вы смотрите только среднее.
Математические наборы вроде GSM8K и олимпиадных выборок проверяют многошаговый счёт и иногда формализуемый вывод. Здесь эталон часто однозначен, поэтому автоматическая проверка сильнее, чем на эссе. Но школьный сюжет «у Кати пять яблок» слабо предсказывает ошибку модели на вашей формуле тарифа с исключениями и курсами валют.
Кодовые наборы — от синтеза функции по описанию (HumanEval и родственники) до правок в репозитории (SWE-bench и производные). Они ближе к инженерии: скрытые тесты исполняются, «почти правильный» код не проходит. Даже здесь утверждение узкое: модель умеет закрыть этот класс задач в этой обвязке (доступ к файлам, несколько попыток, конкретный судья). Смена обвязки меняет балл сильнее, чем смена «интеллекта».
Наборы на «рассуждение» пытаются поймать цепочку шагов, а не только финальное число. Их легко испортить подсказкой «думай пошагово» в системной инструкции, которую в продукте вы как раз запретили из‑за длины и стоимости. Сравнивайте модели в том режиме, в котором их будете звать: с инструментами или без, с коротким или длинным ответом.
Заражение тестовой выборки — отдельный риск. Если формулировки задач встречались в обучающем корпусе, балл отражает память, а не обобщение. Практически это значит: не ставьте публичный набор единственным критерием закупки и держите собственную скрытую выборку, которую не публикуете в промптах и тикетах.
Предпочтения людей и арены парных сравнений
Люди плохо ставят абсолютный балл «насколько хорош ответ», но сравнительно уверенно выбирают из двух. Отсюда арены вроде чата с парным голосованием: две модели отвечают на один запрос, человек отмечает победителя, из тысяч таких дуэлей считают рейтинг.
Что проверяет арена. Предпочтение как ответа в диалоге: ясность, тон, готовность помочь, отсутствие отказа, иногда стилистическую близость к ожиданиям аудитории. Сильная модель на арене часто та, что охотнее отвечает и звучит уверенно. Это может быть ровно то поведение, которое вы хотите подавить в юридическом или медицинском контуре.
Чего арена не проверяет. Истинность без экспертизы. Соблюдение вашей политики. Поведение на ваших внутренних документах. Стоимость и хвост задержки. Устойчивость к враждебному вводу. Смещение выборки запросов: волонтёры арены спрашивают не то, что спрашивает бухгалтер в системе учёта.
Парное сравнение внутри команды — другой инструмент. Эксперты предметной области сравнивают кандидата с текущей версией на ваших случаях. Рубрика должна быть явной: фактичность, полнота, отказ, тон, формат. Иначе победит «более вежливый абзац».
Модель-судья и автоматические текстовые метрики
Когда ответов тысячи, людей не хватает. Два обходных пути: сравнить текст с эталоном поверхностными метриками и попросить другую модель вынести вердикт.
Перекрытие токенов (ROUGE, похожие схемы) и близость векторных представлений (BERTScore и аналоги) дешёвы и воспроизводимы. Они хорошо ловят «похоже на эталон». Они плохо ловят отрицание и прямое противоречие: ответ «запрещено» и «разрешено» могут оказаться близки по словам или по вектору. Исследование метрики MATCHA как раз показывает, что классические схемы ставят высокий балл тексту, который опровергает эталон; разбор — в заметке про эту метрику.
Модель-судья читает задание, ответ и иногда эталон, затем ставит оценку или выбирает победителя. На многих задачах свободного ответа она лучше совпадает с людьми, чем перекрытие токенов. Цена известна: судья пристрастен к длине, к своему «семейству» моделей, к порядку вариантов, к формулировке рубрики. Смена версии судьи меняет историю графиков, как смена компилятора меняет предупреждения.
Практические правила. Фиксируйте идентификатор судьи, температуру, системную инструкцию и рубрику как часть версии оценки. Калибруйте на скрытой человеческой выборке: доля согласия, систематические ошибки по стратам. Для критичных классов (безопасность, деньги, здоровье, доступ) не делайте судью единственным барьером. Для массовой сортировки черновиков — делайте, но оставляйте хвост на эксперта.
Отдельно стоит схема «модель проверяет модель на выдумках» без эталона. Это слабый сигнал: модель может уверенно подтвердить собственную выдумку. Сильнее — проверить утверждения против поданного контекста или против структурированного факта.
Точное совпадение, исполнение и трассировка инструментов
Самые честные тесты — те, где вердикт не читает прозу.
Извлечение полей: модель должна вернуть JSON по схеме. Проверка — валидатор схемы плюс сравнение значений с эталоном. Здесь ловят лишние поля, смену типов, «почти правильные» даты. Для шлюзов и агентов это базовый слой: если формат плавает, дальше конвейер не имеет права работать.
Исполнение кода: сгенерированная функция или патч прогоняются против скрытых тестов. Утверждение: программа удовлетворяет спецификации тестов, а не «выглядит как Python». Слабое место — тесты, которые написала та же модель, и обвязка, дающая подсказки из стека вызовов.
Вызов инструментов: эталон — не текст ответа, а последовательность и аргументы вызовов. Проверяют, что модель вызвала нужный инструмент, не вызвала запрещённый, передала корректный идентификатор, остановилась после успеха. Это ближе к интеграционному тесту агента, чем к экзамену по знаниям. Без такой проверки «умный чат» может рассказывать, что отправил письмо, не отправив его.
Детерминированные оракулы (калькулятор, база, компилятор, контракт API) стоит вызывать из проверки, а не просить модель пересказывать их результат. Иначе вы снова оцениваете прозу.
Фактичность, обоснованность и граница с RAG
Два разных вопроса путают чаще всего.
«Верно ли утверждение о мире?» — фактичность. Для неё нужен эталон вне модели: база знаний, документ, эксперт, исполнение. Без опоры это оценка «звучит правдоподобно».
«Следует ли утверждение из поданного контекста?» — обоснованность. Здесь эталон — фрагменты, которые вы сами положили в окно. Модель может быть обоснованной и фактически устаревшей, если контекст устарел. Может быть фактически верной «из параметров» и при этом нарушать правило «отвечай только по документам».
Для помощников с поиском эти слои разводят специально: сначала измеряют, попал ли нужный фрагмент в выдачу, затем — использован ли он в ответе, затем — не добавила ли модель лишнего. Подробности цепочки — в промышленной инженерии RAG, сбор эталонов — в золотом наборе для RAG. Этот материал фиксирует только принцип: не оценивайте генерацию одной цифрой, если ошибка могла случиться на поиске.
Проверки без поиска тоже нуждаются в политике отказа. Набор, где на каждый вопрос есть ответ, учит модель никогда не говорить «не знаю». Добавьте случаи без ответа и измеряйте ложные ответы отдельно от полезных.
Безопасность, политики и враждебные проверки
Обычный экзамен по знаниям почти не видит вреда. Безопасность проверяют отдельными наборами.
Политические тесты задают запрещённые классы: инструкции по вреду, обход модерации, запросы чужих секретов, действия вне роли ассистента. Эталон здесь часто «отказать / эскалировать / ответить в рамках политики», а не «дать лучший ответ». Метрика — доля нарушений и доля ложных отказов на безобидных запросах. Зажать отказ — легко улучшить «безопасность» ценой бесполезности.
Внедрение инструкций проверяет, подчинится ли модель тексту в документе, на веб-странице или в сообщении пользователя вида «игнорируй предыдущие правила». Контур продукта, который подмешивает ненадёжный контекст, обязан иметь такие случаи в регрессии. Разбор класса атак — в защите от внедрения инструкций и в ограничениях ИИ.
Утечка системной инструкции и секретов из контекста — отдельный набор: прямые просьбы «повтори свои правила», косвенные («какие инструменты тебе доступны?»), попытки вытащить ключи из истории. Здесь эталон — отсутствие секрета в выводе, а не вежливый отказ.
Враждебная проверка (красная команда) не заменяет регрессию. Это исследование: люди и автоматические генераторы ищут новые дыры. Найденное повышают до постоянного случая. Путать разовое исследование с барьером выпуска — оставлять дыру открытой до следующего сеанса.
Мультимодальность и инструменты расширяют поверхность: модель может отказать в тексте и одновременно вызвать опасный инструмент. Тест обязан смотреть на действие, а не только на абзац.
Регрессия продукта против охоты за публичным рейтингом
Команда выбирает модель по таблице лидеров, встраивает её, затем меняет системную инструкцию, инструменты и маршрутизацию — и удивляется, что «качество плавает». Публичный балл описывал другую сборку.
Регрессионный набор продукта — это не уменьшенный MMLU. Это ваши критичные диалоги: типичный успешный запрос, точный идентификатор, отказ, конфликт политик, граница арендатора, длинный контекст, вызов инструмента, враждебная фраза в документе. Каждый случай имеет владельца, уровень риска и правило: блокировать выпуск или только наблюдать. Как устроить барьеры в CI — в контуре оценки.
Три популяции, которые стоит держать раздельно. Набор коммита — десятки детерминированных случаев, секунды, без дорогого судьи. Набор релиза — шире, может включать модель-судью и человеческую выборку. Скрытый контроль — случаи, которых нет в тикетах настройки промпта, чтобы не выучить тест наизусть.
Смена модели, промпта, температуры, маршрута шлюза и версии судьи — разные эксперименты. Если меняете два сразу, вы не знаете, что улучшило график. Фиксируйте базовую версию и сравнивайте пары на одних и тех же входах.
Экономика здесь та же, что в обычном ПО: проверяйте пропорционально ущербу, а не «покрытию вопросов». Рамка — в экономике стоимости ошибок. Один пропущенный сценарий списания важнее сотни зелёных шуточных запросов.
Онлайн-проверка: теневой трафик, сравнения и следы
Офлайн-набор стареет. Пользователи задают новые формулировки, корпус документов двигается, мода на промпты обхода ограничений меняется. Онлайн-слой не отменяет офлайн, а ловит дрейф.
Теневой прогон гоняет новую версию на живых запросах без показа пользователю. Сравнивают отказы, длину, вызовы инструментов, срабатывание политик, расхождение с текущим ответом. Это дешевле инцидента и дороже офлайн-набора: нужны маскирование, сроки хранения и запрет на попадание секретов в логи оценки.
Контролируемое сравнение двух версий на живом трафике показывает влияние на продукт: конверсия, повторные вопросы, эскалация к человеку, оценка пользователем. Хвост «не понравилось» смешивает плохой ответ, медленный ответ и неверный сценарий. Без разметки причины сравнение учит оптимизировать вежливость.
Явные сигналы пользователя (палец вверх, «перефразируй», смена темы) — слабые и смещённые. Их используют как источник кандидатов в золотой набор после разбора, а не как единственную метрику качества модели.
Трассировка обязана сохранять достаточно, чтобы воспроизвести случай: версия модели, системная инструкция, инструменты, фрагменты контекста по политике данных. Иначе онлайн-оценка превращается в анекдоты из чата поддержки.
Как собрать набор видов проверок под продукт
Начните с вреда, не с каталога аббревиатур. Для справки по внутренним регламентам критичны обоснованность, отказ и права доступа. Для агента, который вызывает оплату, — схема вызова, идемпотентность, запрет на лишние инструменты. Для публичного чата — безопасность и тон. Для помощника в IDE — исполнение тестов и дифф, а не эрудиция.
Минимальный каркас, который закрывает большинство сервисов с LLM:
| Класс проверки | Что утверждает | Типичный оракул | Когда обязателен |
|---|---|---|---|
| Формат и схема | Вывод машиночитаем | Валидатор | Всегда, если ответ идёт в код |
| Следование инструкции | Соблюдены язык, запреты, длина | Рубрика + эталон / судья | Почти всегда |
| Предметные эталоны | Верны поля, расчёты, ссылки | База, документ, эксперт | Где есть цена ошибки |
| Обоснованность | Утверждения следуют из контекста | Сопоставление с фрагментами | RAG и «только по документам» |
| Инструменты | Вызвано нужное действие | Трасса вызовов | Агенты, MCP, шлюзы |
| Безопасность | Нет запрещённого действия и утечки | Политический набор + красная команда | Внешний и внутренний доступ к данным |
| Регрессия продукта | Не хуже текущей службы | Парное сравнение на своих случаях | Перед сменой модели и промпта |
| Онлайн-дрейф | Живой поток не разъехался | Тень, жалобы, трассы | После выпуска |
Не копируйте все открытые экзамены «для полноты». Каждый набор стоит сопровождения: кто обновляет, как попадает новый инцидент, когда случай удаляют. Мёртвый каталог из десяти тысяч чужих вопросов хуже живых восьмидесяти ваших.
Свяжите виды проверок с маршрутизацией. Дешёвая модель на типовых вопросах может проходить только формат, отказ и маленький регрессионный набор. Дорогая модель на спорных тикетах — ещё и человеческую выборку. Как бюджеты стыкуются со шлюзом — в материале про шлюз языковых моделей и операционную дисциплину затрат.
Типичные ошибки
Один балл на всех слайдах. Усреднение знаний, безопасности и предпочтений даёт удобную презентацию и бесполезное решение о выпуске.
Оценка прозы там, где есть оракул. Спрашивать судью, верна ли сумма, вместо того чтобы сложить числа.
Тесты, которые видел промпт. Выучили набор — улучшили график — сломались на первой новой формулировке.
Смена модели и судьи в одном релизе. История качества необъяснима.
Арена как приёмка. Пользователям арены нравится словоохотливость; вашему юристу — отказ.
Безопасность как доля отказов. Модель, которая отказывает всегда, «безопасна» и бесполезна. Нужны и запрещённые, и разрешённые случаи.
Игнорировать обвязку. Балл SWE-bench с агентом и без агента — разные продукты. Ваш сервер протокола контекста моделей — часть системы, которую тоже тестируют.
Путать пилот из десяти диалогов с набором. Пилот находит дыры. Набор фиксирует их и не даёт вернуться.
Частые вопросы
Чем тест языковой модели отличается от юнит-теста?
Юнит-тест фиксирует детерминированный результат функции. Тест модели фиксирует утверждение о поведении на распределении входов: доля нарушений, устойчивость к перефразированию, качество относительно базовой версии. Где вывод можно проверить машиной (схема, код, вызов инструмента), стоит писать почти обычный автотест.
Нужно ли гонять MMLU, если продукт — внутренний помощник?
Нет как барьер выпуска. Да как грубый фильтр при выборе семейства моделей. Решение о включении принимают ваши регрессия, безопасность и обоснованность.
Можно ли обойтись одной моделью-судьёй?
Для черновой сортировки — да. Для денег, доступа, здоровья и регуляторики — нет. Судью калибруют людьми и дополняют детерминированными проверками.
Что важнее: офлайн-набор или отзывы пользователей?
Офлайн даёт воспроизводимый запрет на выпуск. Отзывы показывают новые формулировки и дрейф. Одно без другого слепнет: набор стареет, отзывы смещены и неизмеримы.
Как понять, что публичный набор заражён обучением?
Прямого доказательства у потребителя API обычно нет. Практическая защита — собственная скрытая выборка, перефразирование, свежие случаи из продакшена и недоверие к скачку балла без роста на ваших задачах.
Сколько случаев достаточно?
Столько, чтобы покрыть страты вреда, а не «круглое число». Для барьера коммита часто хватает десятков критичных сценариев. Для релиза — сотен с разбивкой по типам ошибок. Тысячи чужих вопросов не заменяют двадцать ваших инцидентов.
Температура ноль делает оценку честной?
Она делает её стабильнее и ближе к потолку. В чате температура и перефразирование другие. Гоняйте релизный набор в том режиме, который видит пользователь, и отдельно — детерминированный набор коммита.
Как тестировать агента, а не «голую» модель?
Эталоном становится трасса: какие инструменты вызваны, с какими аргументами, чем закончился цикл, соблюдены ли права. Текстовый ответ — вторичен. Обвязка входит в версию системы так же, как вес модели. Практическая рамка — в агентной инженерии.
Когда человеческая разметка обязательна?
Когда автоматический оракул слаб: тон, спорная полнота, новые классы вреда, разногласия политик. Людей используют точечно и дорого: калибровка судьи, скрытый контроль, разбор инцидентов — не разметка каждого ответа в проде.
Как связать тесты модели с тестами RAG?
Разведите слои. Поиск измеряют полнотой нужных фрагментов. Генерацию — обоснованностью и отказом. Сквозной ответ нужен, но без разложения вы будете менять модель, когда виноват индекс. См. контур оценки и золотой набор RAG.
Дальнейшее чтение
- Контур оценки ИИ в 2026 — как превратить виды проверок в CI, теневой трафик и критерии релиза.
- Как оценивать корпоративный ИИ — связь качества с процессом и безопасностью на уровне архитектуры предприятия.
- Золотой набор для оценки RAG — эталоны поиска и ответа, а не экзамен «голой» модели.
- Промышленная инженерия RAG — где в цепочке рождается ошибка, которую тест генерации не увидит.
- Экономика стоимости ошибок — сколько проверки покупать относительно ущерба.
- Метрика, которая ловит противоречие эталону — почему поверхностные текстовые метрики пропускают опровержение.
- Агентная инженерия — качество цикла инструментов, а не только абзаца.
Внешние ориентиры (не замена своему набору): документация открытых наборов задач и арен, статьи о заражении тестов обучением, практики красных команд поставщиков моделей.
Заключение
Проверка качества языковой модели начинается с фразы, которую вы готовы защищать: «на этих входах система соблюдает этот контракт». Контракт бывает про знания, про формат, про обоснованность, про действие инструмента, про запрет. Под каждый контракт — свой оракул. Чужой экзамен, арена и модель-судья — полезные приборы с известной погрешностью. Решение о выпуске принимают ваши страты вреда, скрытый контроль и способность объяснить откат.
Соберите за одну итерацию не «полный чужой экзамен», а короткую матрицу: какие утверждения критичны, чем их проверять, что блокирует релиз. Затем наращивайте набор случаями из инцидентов, а не строками из чужой таблицы лидеров. Лабораторный принцип здесь простой: измеряют то, что нельзя подменить впечатлением от удачного чата.