33 метрики LLM, за которыми стоит следить
Ключевые метрики и бенчмарки, по которым можно оценивать производительность, возможности, надежность и безопасность ваших ИИ-моделей и агентов
Мы все слышали мантру от квантов из делового мира: нельзя управлять тем, что нельзя измерить. И если это верно для человеческого интеллекта, то для искусственного — тоже.
Как измерять агентов и большие языковые модели (LLM)? Мы только начинаем подбирать статистические метрики. Ниже — несколько самых распространенных показателей, которые разработчики и пользователи обсуждают при оценке модели.
[ См. также: 27 вопросов, которые стоит задать перед выбором LLM ]
Время до первого токена
Сколько времени требуется, чтобы сгенерировать первый токен? Для приложений реального времени с жесткими ограничениями по времени более быстрый ответ может быть критически важен. Известно, что людям не нравится ждать даже несколько миллисекунд. Команды, создающие пользовательские интерфейсы, десятилетия назад усвоили, что программное обеспечение должно быстро реагировать, когда человек ждет ответа. Даже несколько секунд задержки могут привести к тому, что человек уйдет в другое окно — проверить почту или сделать ставку на рынке прогнозов. Время до первого токена — хороший показатель для моделей, которые работают напрямую с капризным человеческим вниманием и его скрытым дефицитом концентрации.
Время на выходной токен
Возьмите общее время ответа и разделите его на общее число токенов. Метрика времени до первого токена показывает, сколько времени нужно, чтобы начать ответ, а эта метрика показывает среднюю скорость прохождения модели через все токены. В базовых LLM это значение обычно довольно постоянно. После завершения prefill и перехода LLM в фазу decode выходные токены обычно появляются с постоянной скоростью потока. Когда ответ достаточно длинный, начальная задержка до первого токена амортизируется. В некоторых более сложных архитектурах с циклами планирования или сбором данных из разных инструментов средняя скорость может меняться, когда модель переключается между агентными решениями.
Токенов в секунду
Это просто обратная величина средней времени на токен. Иногда ее отдельно приводят для разных стадий pipeline.
Пропускная способность (запросов в минуту)
Если система поддерживает более одного пользователя, имеет смысл отслеживать число разных запросов. Эти показатели пропускной способности могут быть очень полезны для измерения мощности новых pipeline, которые эффективнее отвечают на несколько промптов одновременно.
Частота ошибок
Не каждый запрос получает ответ. Частота ошибок показывает, как часто rate limits, timeouts или отказы модели мешают получению результата. Лучше вести раздельный учет по каждому типу, потому что число сбоев в каждой категории может сильно различаться.
Эффективность токенов
Не все рабочие токены видны, и не все токены входят в финальный результат. Эта метрика показывает, сколько работы требуется, чтобы получить итоговый ответ. По мере того как модели становятся сложнее или более агентными, а pipeline — более изощренными, эффективность обычно снижается. Агентное рассуждение и стратегическое планирование, как правило, требуют больше токенов, которые не попадают в итоговый ответ. В целом это показатель того, насколько дорогим может быть запуск модели.
Хвостовая задержка
Измерять среднее время ответа хорошо, но в некоторых случаях несколько очень медленных ответов могут сильно повлиять на впечатление пользователей. Некоторым приложениям нужна хорошая производительность постоянно. Хотели бы вы ехать в автономном автомобиле, который получает команды на управление очень быстро «в среднем», а не всегда? А если так происходит только в 99% случаев? Хвостовая задержка использует сочетание теории очередей и детальных измерений, чтобы отслеживать худшие моменты в длинном хвосте графика задержек. Она полезна там, где даже редкие задержки создают проблему.
Совокупная стоимость владения
Проекты, которые используют API или покупают результат у провайдеров, обычно смотрят только на стоимость за 1 млн токенов. По сути, они арендаторы. А вот команды, которые покупают GPU и платят за электричество, складывают эти расходы вместе с косвенными затратами вроде амортизации и обслуживания, чтобы получить оценку того, во сколько токены реально обходятся в производстве. Это значение зависит от спроса и коэффициента использования — то есть от того, сколько пользователей отправляют промпты и насколько эффективно модель помещается в конкретный GPU и его RAM.
Параметры
Во многих моделях в названии есть число с суффиксом B. Оно примерно отражает число параметров, то есть число переменных, которые модель использует для получения выходных данных из входных. Обозначение «70B» означает примерно 70 миллиардов параметров. Это хороший ориентир для сложности модели и размера обучающего набора, который в нее «запихнули». Обычно большие числа означают, что внутри модели скрыт больший объем информации. Часто это также значит, что для ответа потребуется более крупный GPU с большим объемом RAM. Но это не очень точный показатель, потому что на способность модели выдать нужный ответ в рамках бюджета влияют и многие другие части архитектуры. Прогресс продолжается, и нередко кто-то утверждает, что новая модель с X параметрами лучше старой с 2X или 3X параметрами.
Частота галлюцинаций
Хотя всем хочется, чтобы LLM генерировали точные ответы, измерять это трудно, потому что определение «точности» иногда само по себе непросто. Один из подходов — попросить LLM кратко пересказать документ, а затем дать другой модели оценить, насколько хорошо пересказ совпадает с оригиналом. Хотя это не поймает все тонкие ошибки, оно выявит достаточно много самых грубых отступлений от реальности. Некоторые исследователи создали сложные тестовые наборы с эталонными ответами. LLM, которые выдают ожидаемые ответы, получают самые высокие оценки. Среди распространенных бенчмарков — TruthfulQA, HaluEval, QAFactEval и Hallucination Evaluation Model (HHEM) от Vectara.
Показатели токсичности и предвзятости
Если измерять точность сложно, то построить метрику для выявления токсичного или предвзятого вывода еще труднее, потому что сами определения могут быть очень подвижными. И все же некоторые команды создали LLM, которые ориентируются на определенные концепции или выбор слов. Они способны обнаруживать некоторые из самых очевидных тревожных сигналов, которые могут создать политические проблемы. Среди известных решений — Granica Screen и Perspective API.
Утечка PII
Один из самых больших страхов состоит в том, что LLM каким-то образом усвоят информацию, которую можно считать личной и конфиденциальной. Самые простые способы измерения могут быть совсем простыми — например, регулярные выражения, которые ищут 16-значные номера, используемые в карточных транзакциях. Многие разработчики моделей заранее работают над удалением персонально идентифицируемой информации (PII) из обучающего набора.
Точность вызова инструментов
По мере того как модели становятся сложнее и более агентными, они часто получают доступ к разным инструментам или шлюзам Model Context Protocol (MCP), которые помогают находить лучший ответ. Но не все модели используют эту помощь. Оценки точности вызова инструментов показывают, как часто модель выбирает лучший инструмент для задачи. Один из примеров такой метрики — BFCL (Berkeley Function Calling Leaderboard).
Чувствительность к промпту
Эта метрика показывает, как небольшие изменения в формулировке промпта вызывают у модели разные результаты. Это похоже на производную из курса математического анализа, хотя обычно ее вычисляют экспериментально на наборе тестовых промптов. Есть несколько подходов, зависящих от типа изменений. Одни тестовые наборы строятся на небольшом перефразировании запроса при сохранении смысла. Другие смешивают разные способы задания задачи — например, с примерами и без них. Среди конкретных примеров — PromptSE и ProSA.
Семантическое сходство и краткость
Некоторые метрики оценивают ответы, сравнивая их с набором эталонных ответов. Это часто включает подачу текста в модель векторных эмбеддингов и поиск похожих ответов в базе retrieval-augmented generation (RAG). Так можно отслеживать, насколько ответы краткие или, наоборот, слишком расплывчатые, а также насколько сильно на вариативность влияет изменение параметров вроде temperature. Один из распространенных примеров — BERTScore.
Оценка привязки к источникам
Многие системы, которые объединяют LLM с инструментом векторного поиска для RAG, измеряют эффективность такого сочетания с помощью бенчмарка вроде grounding score. LLM получает дополнительные данные из векторного поиска, а бенчмарк измеряет, насколько точно она следует этой дополнительной информации. Иными словами, сколько ответа взято из предоставленных исходных документов, а сколько синтезировано на основе данных из обучающего набора. Среди примеров — RAGAS, TruLens, ARES (Automated RAG Evaluation System), RGB (Retrieval-Augmented Generation Benchmark), HaluEval и HalluHard. Схожие понятия называются «context adherence», «context precision», «context recall» или «faithfulness».
Вариативность модели
Большинство LLM включают некоторую долю случайной энтропии, и этот объем часто контролируется параметром temperature. Вариативность модели — это показатель того, насколько ответы меняются между запусками. В некоторых приложениях, например в чат-ботах, определенная вариативность нужна, потому что случайность добавляет ответам немного «жизни». В других, например в юридических или медицинских сценариях, изменчивость ответов подрывает доверие.
Соблюдение формата
В некоторых ролях LLM просят выдавать данные в строгих форматах, например JSON или CSV. Это особенно важно, если данные затем пойдут в pipeline для дальнейшей обработки или хранения. Метрика соблюдения формата проверяет несколько распространенных форматов и измеряет, как часто LLM возвращает семантически корректные данные. Агентные системы, которые связывают вместе несколько LLM и другие инструменты, сильно зависят от моделей с хорошими результатами по этому бенчмарку.
Следование инструкциям
Некоторые промпты содержат очень конкретные инструкции, и степень их соблюдения можно измерять эмпирически. Например, в отдельных запросах LLM просят выдать ровно 300 слов или стихотворение в рифмованных двустишиях. Такие тесты используют набор примерных промптов с ответами, которые легко измерить. Среди конкретных примеров — IFEval, FollowBench и BFCL (Berkeley Function Calling Leaderboard), уже упомянутый выше в разделе об использовании инструментов.
Успешность подцелей
По мере того как агентные модели становятся все более распространенными, полезно отслеживать, насколько хорошо модель справляется с каждой из частей стратегического плана агента. Все метрики здесь можно разбивать и отслеживать отдельно по каждой подцели.
Стабильность плана
Агентные модели начинают с плана. Некоторые из них достаточно умны, чтобы отказаться от плана или хотя бы скорректировать его по мере изменения задачи. Стабильность плана показывает, как часто план меняется. Высокая частота корректировок может означать, что агент плохо планирует, или просто гибок, или и то и другое.
Оценка самоисправления
Некоторые агенты способны углубиться в задачу и распознать собственные ошибки. Оценка самоисправления показывает, как часто модель совершает ошибку, а затем распознает ее — самостоятельно или после вопроса: «Вы действительно уверены?»
Устойчивость к jailbreak
Некоторые пользователи пытаются хитро заставить LLM отбросить ограничения по темам или ответам. Раньше некоторые LLM можно было обмануть, сообщив, что ответ является частью пьесы или художественного произведения. Тогда обсуждение запретных тем не считалось проблемой, потому что все якобы было понарошку. Более новые модели имеют более сложные защиты. К бенчмаркам, оценивающим способность сопротивляться обману, относятся JailbreakBench, AgentHarm и Tele-AI-Safety.
Уязвимость к prompt injection
Иногда ненадежные данные из дополнительных источников или навыков могут содержать вредоносные инструкции, способные эксплуатировать LLM. Бенчмарки вроде Skill-Inject и SPIKEE (Simple Prompt Injection Kit for Evaluation and Exploitation) работают с известными векторами атак и измеряют, насколько модель уязвима к целевым атакам prompt injection.
Оценка нарушения авторских прав
Некоторые LLM могут воспроизводить данные из обучающего корпуса так, что это похоже на плагиат или нарушение авторских прав. Это может стать проблемой, если обучающие материалы были плохо лицензированы. Оценка нарушения авторских прав показывает, как часто LLM может слишком близко пересказывать обучающий материал. Инструменты защиты от этого включают CopyrightCatcher и DE-COP.
RULER
Насколько хорошо модель может извлекать информацию из всего контекста? Бенчмарки NIAH (needle-in-a-haystack) измеряют, насколько хорошо модель умеет извлекать маленькие, но критически важные фрагменты информации из длинных контекстов. RULER развивает NIAH-тесты дальше, позволяя менять типы и количество «иголок», размер «стога» и сложность задачи.
GSM8K
Создатели GSM8K (Grade School Math 8K) хотели оценить способность LLM справляться с многошаговыми математическими задачами, поэтому собрали 8 500 задач, типичных для школьной математики. Хотя акцент явно сделан на решении домашних заданий по математике, бенчмарк также измеряет способность строить цепочки рассуждений.
GPQA
Graduate-Level Google-Proof Q&A состоит из сотен сложных вопросов, на которые обычно отвечают люди на уровне аспирантуры, как правило в научных областях. Чтобы усложнить бенчмарк, исследователи сосредоточились на вопросах, в которых неспециалисты часто ошибаются. Термин «Google-proof» означает, что на вопросы нельзя легко ответить с помощью поисковой системы.
MMLU-Pro
Бенчмарк MMLU-Pro развивает датасет Massive Multitask Language Understanding, чтобы проверять понимание модели в широком наборе научных знаний. Он включает более 12 000 вопросов по общим научным областям, таким как биология, химия, экономика и право.
MBPP
Google создала MBPP (Mostly Basic Python Problems), чтобы оценивать, насколько хорошо модель решает задачи по coding. Каждая задача содержит условие, эталонное решение и несколько похожих тестовых случаев. Количество правильных ответов на эти задачи — хороший показатель того, насколько хорошо модель будет решать многие более простые Python-задачи, которые задают пользователи.
SWE-bench
Эта подборка из нескольких тысяч задач по software engineering оценивает, насколько хорошо модель решает программные проблемы. Создатели сформировали ее, выбрав ряд issues и соответствующих pull requests из примерно дюжины Python-проектов. После того как выявились некоторые ограничения, набор расширили, создав SWE-Bench+, SWE Bench Verified и SWE-Bench Pro.
LMSYS Chatbot Arena
Вместо фиксированного набора тестовых промптов Large Model Systems Organization’s Chatbot Arena использует динамическую систему, которая отправляет один и тот же промпт разным моделям, а затем просит людей выбрать лучший результат. Такие очные сравнения дают рейтинг, похожий на Elo, который используется для оценки шахматистов.
Цена
Остальные метрики полезны, но, как говорят агенты по недвижимости, три самых важных числа в объявлении — это цена, цена и цена. Для оценки ИИ стоимость немного менее важна, но лишь немного. Цена может радикально изменить проект: будет ли он прибыльным или станет денежной ямой. Если стоимость каждого inference чуть завышена, компенсировать это объемом невозможно.
Ключевая оговорка в том, что более дешевая модель — не лучший выбор, если она выдает ответы, набитые галлюцинациями, или хуже. Качество ответов может сильно различаться, и сэкономить несколько центов иногда оказывается ошибкой. Ситуацию усложняет взрывное разнообразие стилей и подходов. Иногда имеет смысл заплатить немного больше за модель, которая выдает ответы с нужным вайбом.
Материал — перевод статьи с английского.
Оригинал: 33 LLM metrics to watch closely