Метрики LLM

Общее #

Большие языковые модели (LLM) по своей природе вероятностны: на один и тот же запрос они могут вернуть разные ответы, и «правильность» ответа часто нельзя проверить простым сравнением строк. Из-за этого классические подходы к контролю качества, привычные по детерминированному ПО, здесь не работают. Невозможно написать unit-тест, который гарантированно поймает регрессию модели.

Метрики LLM — это измеримые показатели, которые позволяют превратить субъективные оценки («кажется, стало лучше», «модель начала галлюцинировать») в объективные, воспроизводимые данные. Без них внедрение ИИ превращается в набор решений, принятых на интуиции, а любой контроль качества — в лотерею.

Метрики нужны, чтобы решать конкретные практические задачи:

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

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

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

Мониторинг в продакшене. Модель не статична: меняются данные, на которые опирается RAG, дрейфуют пользовательские запросы, появляются новые сценарии. Метрики в эксплуатации позволяют заметить деградацию до того, как её увидят пользователи.

Баланс стоимость/качество. Большинство операционных метрик (латентность, стоимость за токен) напрямую связаны с экономикой продукта. Часто модель чуть хуже по качеству, но в разы дешевле — и метрики помогают принять осознанный компромисс.

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

Что можно понять с помощью метрик:

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

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

Категории метрик #

Метрики LLM удобно разбить на несколько категорий по тому, какую сторону работы модели они характеризуют:

• Качество генерации — насколько текст хорош сам по себе, независимо от задачи: плавность, близость к эталону, семантическое сходство.
• Соответствие задаче — насколько модель решает именно ту задачу, ради которой её используют: точность извлечения фактов, следование формату, выполнение инструкций.
• LLM-as-a-judge — оценка одной модели другой (более сильной) моделью: гибкий способ оценивать ответы, для которых нет однозначного эталона.
• Метрики RAG — специализированные показатели для систем, где модель работает поверх базы знаний: обоснованность ответа источникам, релевантность контекста.
• Безопасность и ответственность — токсичность, галлюцинации, предвзятость, устойчивость к атакам, утечки конфиденциальных данных.
• Операционные метрики — характеристики, влияющие на экономику и пользовательский опыт: скорость, пропускная способность, стоимость.
• Стабильность и надёжность — насколько модель воспроизводима, устойчива к возмущениям и насколько можно доверять её собственной оценке уверенности.
• Бенчмарки — стандартизированные наборы задач, по которым модели сравнивают между собой на рынке.

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

Качество генерации #

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

Perplexity (Перплексия) #

Perplexity измеряет, насколько модель «удивлена» текстом — то есть насколько хорошо она его предсказывает. Чем ниже перплексия на эталонном тексте, тем лучше модель его моделирует.

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

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

BLEU #

BLEU — классическая метрика машинного перевода. Она сравнивает сгенерированный текст с одним или несколькими эталонными переводами, подсчитывая совпадения групп слов (n-грамм), и штрафует за слишком короткие или слишком длинные ответы.

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

ROUGE #

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

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

METEOR #

METEOR — развитие идей BLEU, учитывающее синонимы, формы слов и порядок. За счёт этого METEOR лучше коррелирует с человеческими оценками, чем BLEU, и более справедлив к перефразированию.

METEOR применяют там, где BLEU и ROUGE оказываются слишком жёсткими: при оценке перевода и генерации на языках с богатой морфологией (в том числе на русском), а также в задачах, где допустимы варианты формулировок.

BERTScore и BARTScore #

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

Эти метрики гораздо лучше отражают человеческое восприятие качества, чем BLEU/ROUGE, и применимы к открытым генеративным задачам. Их основной минус — зависимость от модели, используемой для эмбеддингов, и более высокая вычислительная стоимость. BARTScore дополнительно учитывает направление генерации (от эталона к ответу и обратно), что делает его более гибким.

Соответствие задаче #

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

Exact Match (Точное совпадение) #

Exact Match — доля ответов, которые совпали с эталоном дословно. Жёсткая, но прозрачная метрика, применяется в задачах извлечения фактов, классификации, ответов на вопрос в закрытой форме, где правильный ответ единственный.

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

F1 (F-мера) #

F1 — гармоническое среднее точности (precision) и полноты (recall), рассчитанное по словам ответа. F1 мягче Exact Match: она учитывает частичные совпадения и подходит для задач, где модель может вернуть часть правильных элементов.

F1 широко применяется при оценке извлечения сущностей (NER), ответов на вопросы с извлечением (extractive QA), поиска релевантных фрагментов. Там, где эталон содержит несколько верных элементов и важно, сколько из них найдено, F1 — стандартная метрика.

Instruction-following rate #

Instruction-following rate — доля ответов, в которых модель точно выполнила все явные инструкции: верный формат вывода (JSON, таблица, конкретная схема), соблюдение ограничений (длина, язык, отсутствие определённого содержания), следование пошаговым требованиям.

Эта метрика критична для агентных и пайплайнных сценариев, где вывод модели парсится программой downstream. Если модель должна вернуть JSON, а возвращает JSON с поясняющим текстом — пайплайн ломается, и неважно, насколько «умным» был ответ. Instruction-following rate измеряет именно надёжность исполнения формальных требований.

LLM-as-a-judge #

Для большинства реальных задач открытой генерации (чат, консультации, креативные тексты) нет и не может быть единственного эталонного ответа. Человеческая оценка дорога и медленна. Решение — поручить оценку другой, более сильной модели.

G-Eval #

G-Eval — методика, в которой сильная модель-судья (например, GPT-4-класса) оценивает ответ по заданному критерию с использованием chain-of-thought: сначала рассуждает, затем выставляет оценку. Критерии могут быть любыми — релевантность, связность, полезность, тон, соответствие брендбуку.

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

GPTScore #

GPTScore — обобщённый подход к оценке через вероятности модели-судьи: насколько «вероятным» судья считает хороший ответ в данном контексте. Это позволяет получать непрерывные оценки без необходимости просить модель явно выставить балл.

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

Pairwise и win-rate #

Pairwise-сравнение — простая и надёжная схема: судье предъявляются два ответа (например, от конкурирующих моделей или двух версий промпта) и спрашивается, какой лучше. Результат агрегируется в win-rate — долю побед.

Pairwise устойчивее абсолютной оценки: модели-судьи гораздо лучше справляются с задачей «что из двух лучше», чем с простановкой абсолютного балла. Именно на pairwise-сравнениях построена популярная Chatbot Arena (см. раздел «Бенчмарки»).

Оговорки про bias судьи #

LLM-as-a-judge — мощный, но не идеальный инструмент. Модели-судьи имеют свои систематические искажения:

• Position bias — склонность предпочитать первый или второй из предложенных вариантов (поэтому варианты всегда меняют местами и усредняют).
• Verbosity bias — предпочтение более длинных ответов вне зависимости от содержания.
• Self-preference bias — тенденция выше оценивать ответы моделей того же семейства.
• Контекстная слепота — судья не знает ваших реальных пользователей и бизнес-требований и оценивает «в среднем».

Поэтому LLM-as-a-judge всегда калибруют на подмножестве данных с человеческой оценкой и никогда не доверяют слепо. Это инструмент для масштабирования оценки, а не замена человеческого суждения на критических участках.

Метрики RAG #

Retrieval-Augmented Generation (RAG) — схема, в которой модель отвечает на вопрос пользователя, опираясь на документы, найденные в базе знаний. У RAG две точки отказа: поиск может достать не те документы, а генерация может исказить то, что в них написано. Поэтому метрики RAG устроены сложнее классических и оценивают обе стадии.

Де-факто стандартом стала методология RAGAS (RAG Assessment) и аналогичные фреймворки, измеряющие три ключевых аспекта.

Faithfulness (Обоснованность) #

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

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

Answer Relevance (Релевантность ответа) #

Answer Relevance измеряет, насколько ответ действительно отвечает на заданный вопрос, а не уходит в сторону. Ответ может быть полностью обоснован источником (высокий faithfulness), но при этом не по теме — и это тоже брак.

Answer Relevance и faithfulness оценивают две разные грани и должны рассматриваться вместе: хороший RAG-ответ одновременно обоснован и релевантен.

Context Precision и Context Recall #

Это метрики качества самой стадии поиска (retrieval), а не генерации.

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

Context Recall — доля релевантной информации, которую поиск вообще смог найти. Низкий recall означает, что нужные документы поиск не нашёл, и модели просто неоткуда взять правильный ответ.

Сильная RAG-система даёт высокий recall (находит всё важное) при приемлемой precision (не тащит лишнего). Часто эти метрики конфликтуют: расширение поиска повышает recall, но снижает precision — и метрики помогают найти рабочий баланс.

Безопасность и ответственность #

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

Токсичность #

Доля ответов, содержащих оскорбления, ненормативную лексику, разжигание вражды или иной неприемлемый контент. Измеряется как классификаторами-модераторами, так и LLM-as-a-judge по специальным рубрикам.

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

Галлюцинации #

Доля ответов, в которых модель уверенно выдаёт фактически неверную информацию. Галлюцинации — главный источник недоверия к LLM и самая частая причина, по которым продукты на их основе отвергаются конечными пользователями.

Галлюцинации измеряют разными способами: верификацией фактов по внешним источникам (fact-checking), LLM-as-a-judge с доступом к надёжной базе, faithfulness в RAG-сценариях. Полностью устранить галлюцинации пока невозможно, поэтому задача метрики — держать их на приемлемом уровне и отслеживать рост.

Bias и справедливость #

Bias (предвзятость) — систематическое отклонение ответов модели в ущерб определённым группам: по полу, возрасту, этнической принадлежности, региону, социальному статусу. Метрики bias измеряют, насколько модель ведет себя по-разному для разных демографических групп в одинаковых по сути сценариях.

Bias особенно критичен в HR-сценариях (скрининг резюме), скоринге, кредитных и медицинских применениях — там, где решения модели затрагивают права и возможности людей. Регуляторы (GDPR, AI Act) прямо требуют от разработчиков отслеживать и документировать предвзятость.

Refusal rate и over-refusal #

Refusal rate — доля запросов, на которые модель отказалась отвечать. Нулевой refusal-rate нежелателен (модель должна отказывать на действительно недопустимые запросы), но чрезмерный — признак over-refusal, когда модель начинает отказывать и на безобидные запросы, перестраховываясь.

Over-refusal — частая проблема после жёсткого alignment: модель становится «пушистой» и бесполезной для пользователя. Метрику замеряют как на безопасных запросах (должен быть низким), так и на заведомо недопустимых (должен быть высоким), и ищут баланс.

Устойчивость к джейлбрейкам и инъекциям #

Jailbreak — специальные формулировки, заставляющие модель нарушить собственные ограничения (например, выдать инструкции по изготовлению запрещённого). Prompt injection — атака на RAG-системы, когда вредоносный текст встраивается в документ, который попадёт в контекст, и пытается заставить модель действовать в интересах атакующего.

Метрики устойчивости измеряются на специально собранных наборах атак (red-teaming) и показывают, какую долю атак модель отражает. Это одна из самых быстроразвивающихся областей: новые типы атак появляются быстрее, чем модели учатся им сопротивляться.

Утечка PII #

PII (Personally Identifiable Information) — персональные данные. Метрика измеряет, не выдаёт ли модель конфиденциальную информацию, которую она могла запомнить на этапе обучения (номера телефонов, email, паспортные данные), а также не передаёт ли PII из одного контекста в другой.

Эта метрика напрямую связана с комплаенсом: утечка персональных данных подпадает под GDPR, 152-ФЗ и аналогичные регламенты и грозит штрафами. Для продуктов, обрабатывающих чувствительные данные, контроль утечки PII обязателен.

Операционные метрики #

Эти метрики определяют, можно ли модель использовать в реальном продукте — хватит ли скорости, вместится ли в бюджет, выдержит ли нагрузку.

Латентность #

Время ответа модели — критическая характеристика пользовательского опыта. Различают несколько граней:

TTFT (Time To First Token) — время от отправки запроса до первого токена ответа. Для чат-сценариев это воспринимаемая скорость: пользователь видит, что «модель начала печатать», и готов ждать остальное.

TPOT (Time Per Output Token) — время генерации каждого последующего токена. Определяет, как быстро модель «допечатывает» длинный ответ.

Общая latency — время от запроса до полного ответа. Важна для небатных синхронных сценариев: агентных пайплайнов, интеграций в интерфейс.

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

Throughput (Пропускная способность) #

Throughput — количество запросов или токенов, которое инфраструктура модели способна обработать в единицу времени. Измеряется в запросах в секунду (QPS) или токенах в секунду (TPS).

Throughput критичен для планирования ёмкости: недостаточный throughput приводит к очередям и тайм-аутам под нагрузкой, избыточный — к переплате за простаивающие мощности. Баланс throughput и латентности — одна из ключевых задач при развёртывании модели.

Стоимость за 1M токенов #

Стоимость — чаще всего цена за миллион входных и миллион выходных токенов. У коммерческих моделей это тариф вендора, у self-hosted — расчётная стоимость (амортизация GPU, электричество, обслуживание).

Стоимость — метрика, которая часто перевешивает качество. Модель, дающая на 5% худший ответ, но в 10 раз дешевле, может оказаться правильным выбором для массового продукта. Расчёт полной стоимости владения (TCO) с учётом нагрузки, инфраструктуры и поддержки — обязательная часть оценки.

Token efficiency #

Token efficiency — метрика того, насколько экономно модель расходует токены: средняя длина ответа, доля служебных рассуждений (reasoning tokens у reasoning-моделей), соотношение полезного содержания и «воды».

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

Утилизация контекстного окна #

Context window utilization — насколько эффективно модель использует доступное контекстное окно. Метрика важна для RAG и длинных диалогов: перегрузка контекста нерелевантными фрагментами снижает качество (модель «запутывается») и повышает стоимость (платим за каждый токен).

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

Стабильность и надёжность #

Качество и стоимость важны, но не менее важно знать, насколько модели можно доверять в повторяющихся сценариях.

Консистентность #

Консистентность измеряет, насколько модель даёт одинаковые ответы на эквивалентные по смыслу, но по-разному сформулированные запросы, и насколько стабильны ответы при повторах одного и того же запроса (с учётом температуры). Часть этой нестабильности снимается правильным выбором параметров инференса — подробно в Параметры LLM.

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

Робастность #

Робастность — устойчивость модели к небольшим возмущениям входа: перефразированию, опечаткам, перестановке слов, синонимам. Робастная модель отвечает одинаково на «Как вернуть товар?» и «как сделать возврат», на запрос с опечаткой и без.

Робастность замеряют на синтетически искажённых наборах запросов и сравнивают с эталонными (неискажёнными). Падение качества при искажениях — индикатор хрупкости модели и сигналом к дообучению или укреплению промпта.

Калибровка #

Калибровка — соответствие между заявленной моделью уверенностью и фактической вероятностью правильности ответа. Хорошо откалиброванная модель, говорящая «уверен на 90%», действительно права в 90% случаев.

Калибровка критична там, где от уверенности зависит дальнейшее решение: можно ли автоматически применить ответ или нужен человеческий контроль. Некалиброванная модель, уверенная в неверных ответах, опаснее, чем модель, честно говорящая «не знаю». Стандартная метрика — Expected Calibration Error (ECE).

Бенчмарки #

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

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

Подробно о том, какие бывают бенчмарки, как они проводятся, что реально означает их результат и каким цифрам можно доверять — в отдельной статье Бенчмарки LLM. HELM (Holistic Evaluation of Language Models от Stanford) — пример фреймворка, который вместо одной цифры показывает профиль модели: где она сильна, где слаба, какие риски несёт; такой многомерный разбор для ответственного выбора ценнее любого одиночного бенчмарка.

Как выбирать метрики #

Нет «правильного» набора метрик для LLM вообще — есть набор, адекватный вашей задаче. Ниже — практическая привязка категорий метрик к типовым сценариям.

Чат-боты и ассистенты. Главные — win-rate (pairwise), answer relevance, безопасность (токсичность, over-refusal). Операционно критичны TTFT и стоимость. Бенчмарки (Chatbot Arena Elo) — для первичного отсева моделей.

Машинный перевод. BLEU и METEOR против эталонов, плюс человеческая оценка ( adequacy/fluency). Операционно — throughput и стоимость за объём.

Суммаризация. ROUGE как быстрая метрика, BERTScore для семантической близости, faithfulness (не выдумывать факты), человеческая оценка связности и информативности.

RAG-системы. Полный набор RAGAS: faithfulness, answer relevance, context precision/recall. Операционно — стоимость контекстного окна и latency. Безопасность — prompt injection и PII.

Кодогенерация. HumanEval-подобные функциональные тесты (pass@k), instruction-following rate для формата, безопасность (не генерирует уязвимый код). Операционно — latency в IDE-интеграциях.

Классификация и извлечение. Exact Match, F1, instruction-following rate для формата вывода. Здесь метрики ближе к классическому ML и наиболее надёжны.

Универсальный практический принцип: метрики выбираются под продукт, а не продукт — под метрики. Начинать стоит с одной-двух ключевых метрик качества под основной сценарий, одной-двух операционных под экономику и одной метрики безопасности под риски — и расширять набор по мере роста зрелости внедрения. Подробно о том, куда и как осознанно встраивать ИИ в процесс разработки, — в разделе «Искусственный интеллект».