Как проводить бенчмаркинг LLM

Выбирайте модели на основе входных и выходных данных вашего приложения. Запускайте идентичные задачи через OpenRouter и сравнивайте оцененную точность, стоимость запроса и время выполнения. На наших 60 синтетических задачах модель GPT-6.1 Sol прошла 180/180 попыток за три повторения в рамках протестированных контрактов и настроек.

Кратко (TL;DR)

• Проверка кодом измеряет правильность и соответствие вывода.

Проверка кодом измеряет правильность и соответствие вывода.

• Sol прошла 180/180 попыток на нашем синтетическом наборе; DeepSeek показал самую низкую стоимость ответа при 157/180 прохождениях.

Sol прошла 180/180 попыток на нашем синтетическом наборе; DeepSeek показал самую низкую стоимость ответа при 157/180 прохождениях.

• Совпадение с публичным рейтингом оказалось слабым: коэффициент корреляции Спирмена составил 0.109.

Совпадение с публичным рейтингом оказалось слабым: коэффициент корреляции Спирмена составил 0.109.

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

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

Сначала определите поведение, а затем проверки для него.

Шаг 1. Напишите задачи с ответами, которые может проверить скрипт

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

Мы написали все 40 базовых задач и 20 сложных задач до финального запуска.

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

Шаг 2. Оценивайте с помощью кода и проверяйте саму систему оценки

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

Проверьте корректные, ошибочные и некорректно сформированные ответы. Для порога возврата средств укажите ровно $200 и 30 дней, а затем значения чуть выше каждой границы.

Наш инструмент проверки для разработки отклонил валидный код на Python, так как в нем отсутствовали ord и type. Мы исправили это перед финальным исследованием, указав CPython 3.12.10/WASI с ограничениями ресурсов. В противном случае сбои проверщика засчитались бы моделям.

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

Шаг 3. Запустите пример на Python из трех задач

Скачайте сопутствующий ZIP-архив. Перед его распаковкой сравните его контрольную сумму SHA-256 со следующим значением:

PowerShell:

Linux или macOS:

Если значения различаются, остановитесь и проверьте загрузку. После их совпадения распакуйте ZIP-архив. Вам потребуется Python 3.12 или более поздней версии. Входящие в комплект учебный модуль запуска, пример с JSON и сравнения прошли автономные проверки на Windows x64 и Linux. macOS пока не тестировалась. Поставляемая песочница для полного исследования и нативная настройка Ori поддерживают только Windows x64.

Из извлеченной папки:

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

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

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

Настройте и изучите план

Используйте предоставленную конфигурацию Luna для задания модели, количества повторений, лимита токенов и ограничений провайдера:

Конфигурация Sol сохраняет настройки повторений и токенов, но использует собственные ограничения по цене:

models выбирает кандидатов, repeats задает количество запросов на задачу, а max_tokens устанавливает лимит генерации. Рассуждения могут исчерпать этот лимит до появления видимого вывода. Автономные проверки не делают API-вызовов. Платные запуск требуют явного флага —live. Ответы с усеченной длиной завершаются неудачей без повторной попытки.

Ценовые ограничения указаны в USD за миллион токенов; лимит промпта для Luna составляет примерно $0.10. Если провайдер больше не поддерживает сохраненные настройки, средство запуска должно остановиться, а не изменять их молчаливо. Резервный провайдер не подменяет модели и не отправляет инференс повторно.

Фактический автономный вывод:

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

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

Сделайте небольшой платный запуск

Создайте ключ в настройках API-ключей, пополните баланс и настройте подходящий лимит ключа. Установите переменную локально в терминале.

PowerShell:

Bash или Zsh:

Используйте существующую переменную, если она настроена. Пакет не загружает файл .env. Для поставляемой конфигурации Luna из трех задач:

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

Результаты в режиме реального времени различаются. Приведенные ниже синтетические примеры иллюстрируют отчетность, а не измерения моделей.

Шаг 4. Добавьте собственную задачу и средство проверки

Прилагаемый файл custom-tasks.json демонстрирует формат задач:

Скрипт custom_task.py check независимо вычисляет эталон с использованием Decimal и тестирует корректные, ошибочные и некорректно сформированные ответы. Для пользовательских идентификаторов денег используется средство проверки с двумя десятичными знаками. Другой контракт требует собственного валидатора и проверок.

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

Одной синтаксиса JSON недостаточно. Отклоняйте дублирующиеся ключи и недопустимые числовые значения, а затем проверяйте схему перед сравнением полей с эталоном.

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

Фактический вызов main(…) связывает задачи, оценку и проверки эталона с модулем запуска. Адаптируйте исходные факты и ожидаемые поля, а затем запустите:

Ожидаемый вывод проверки:

Используйте отдельные папки. Эти лимиты применяются только к поставляемым планам для отдельных сценариев.

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

Шаг 5. Сравните сохраненные запуск и обработайте отсутствующие ответы

Для ваших сохраненных запусков JSON:

Это запишет файлы comparison.md и comparison.json без выполнения инференса или повторной оценки. Происходит проверка контрактов, настроек и идентификаторов; несовместимые запуски требуют расследования, а не молчаливого создания рейтинга.

Сначала репетируйте офлайн:

Таблица включает следующие значения синтетических фикстур, показанные с сокращенными столбцами:

В фикстуре Sol отсутствует ответ и не подтвержден счет. Ее оценка 5/5 не имеет полного покрытия. Эти показатели не измеряют ни одну модель.

Сохраните неопределенный запуск и его резерв. Устраните проблемы с доступом или ограничением частоты запросов, затем возобновите работу с неизмененными конфигурацией, источником и лимитом:

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

Чтобы сравнить случаи, на которые ответили все участники:

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

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

Какая модель показала лучший результат в нашем бенчмарке?

Каждая модель получила 40 базовых и 20 сложных задач три раза, что составило 120 базовых и 60 сложных оценок. Эти результаты описывают 60 синтетических задач при наших фиксированных настройках, выполненных 20 октября 2026 года. AA обозначает индекс Artificial Analysis Intelligence Index из нашего датированного публичного снимка.

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

Три вывода определяют выбор для этого набора.

• Наивысший процент прохождения. Sol прошла 180/180 примерно за $0.2449 на 100 ответов.

Наивысший процент прохождения. Sol прошла 180/180 примерно за $0.2449 на 100 ответов.

• Наименьшая стоимость ответа. DeepSeek стоил около $0.00394 за 100, пройдя 157/180 с 14 усечениями. Luna прошла 162/180 примерно за $0.01848. Выбирайте с учетом требуемого процента прохождения и последствий сбоев.

Наименьшая стоимость ответа. DeepSeek стоил около $0.00394 за 100, пройдя 157/180 с 14 усечениями. Luna прошла 162/180 примерно за $0.01848. Выбирайте с учетом требуемого процента прохождения и последствий сбоев.

• Соответствие вывода влияет на оценку. 66 некорректных ответов Sonnet охватывают 21 тестовый случай с инвойсами, 30 с датами и 15 с возвратами средств. Необработанные ответы включают пояснения там, где промпты требовали только число или JSON. Оценка измеряет соответствие контракту, а не только правильность ответов, и не отражает чистые способности к рассуждению.

Соответствие вывода влияет на оценку. 66 некорректных ответов Sonnet охватывают 21 тестовый случай с инвойсами, 30 с датами и 15 с возвратами средств. Необработанные ответы включают пояснения там, где промпты требовали только число или JSON. Оценка измеряет соответствие контракту, а не только правильность ответов, и не отражает чистые способности к рассуждению.

Каждая строка модели в сумме дает 180. Последняя строка суммирует все 1800 ответов. Категории фиксируют неудачные проверки, а не их первопричины.

Все 53 усеченных ответа остались неудачными.

В исследовании запрашивалось 8 192 токена и низкий уровень рассуждений там, где это поддерживалось. Шестнадцать тестов потребовали запросов на замену, поскольку их предыдущие попытки не вернули ответа. Одна замена также не вернула ответа и потребовала еще одной отправки, в результате чего получилось 17 отправок на замену для 16 выбранных ответов. Ни один возвращенный ответ не был перезапущен. Сопутствующие материалы сохраняют каждую попытку.

Известные счета исследования составили $5.1032 плюс $0.5383, зарезервированные для нерешенных счетов. Планы читателя оценивают в $0.97 180 тестовых случаев исследования для Luna и в $19.46 для Sol. Маршрутизация, даты и исходное параллельное или возобновленное планирование ограничивают сравнения с последовательным средством запуска чтения.

Как общедоступные бенчмарки LLM соотносятся с вашими собственными?

Мы получили снимок Artificial Analysis через наш API бенчмарков 20 октября 2026 года в 10:03 UTC, что соответствует точным каноническим версиям моделей.

Корреляция Спирмена сравнивает порядок ранжирования: от −1 для обратного ранжирования до +1 для совпадающего. По десяти моделям:

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

Сколько раз следует запускать каждую задачу?

В 68 из 600 пар «модель-задача» модель прошла некоторые повторы и провалила другие. Сохраняйте каждый повтор. Это повторяющиеся наблюдения 60 кейсов, а не 180 различных кейсов для каждой модели. Близкие результаты ранжирования требуют большего количества отложенных кейсов и повторов.

Часто задаваемые вопросы

Сколько тестовых кейсов мне нужно?

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

Могу ли я использовать LLM в качестве судьи?

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

Следующие шаги

Создайте репрезентативный набор на основе вашего приложения, используя наше руководство по золотому датасету оценки. Сравните кандидатов, а затем настройте блокировку запросов на объединение (pull requests) по результатам проверок.