Почему публичные рейтинги LLM обманчивы: лабораторный опыт выбора модели
Обычно выбор большой языковой модели (LLM) основывается на популярных рейтингах, но они часто не отражают реальной эффективности модели на специфических задачах. Исследователи лаборатории Habr AI разработали собственный бенчмарк, который продемонстрировал огромную разницу в качестве ответов и стоимости между моделями на идентичном наборе из 24 вопросов. В статье разбирается, как создать свой набор тестов, почему «честность» модели критически важна и почему DeepSeek показал неожиданно высокие результаты.
# Почему рейтинги LLM вводят в заблуждение: опыт создания собственного бенчмарка
Выбор подходящей модели искусственного интеллекта часто сводится к поиску самых высоких баллов в независимых рейтингах. Однако для предприятий с уникальными задачами эти общепринятые метрики могут оказаться бесполезными или даже вредными. В статье авторов из лаборатории Habr AI рассказывается о создании собственного тестового стенда, результаты которого заставили пересмотреть представление о соотношении качества и цены в сегменте LLM.
Проблема публичных метрик
Публичные бенчмарки, такие как MMLU или GSM8K, проверяют общие эрудиции модели: понимание грамматики, решение математических задач из учебников и способность ответить на вопросы по предоставленному тексту. Проблема заключается в том, что для реальных производственных задач модель должна взаимодействовать с динамичной базой данных, содержащей ошибки, и выполнять сложные цепочки действий.
В рассматриваемом случае модель использовалась как ассистент для анализа лабораторного журнала. Её задача включала навигацию по данным, чтение прикрепленных файлов и проведение расчетов. На таком этапе даже одна ошибка в интерпретации сырых данных может привести к серьезным последствиям. Авторы отмечают, что для их целей важнее не просто получить ответ, а сделать это честно: модель должна явно сказать, если она не может выполнить задачу, вместо того чтобы выдумывать правдоподобные, но ложные цифры.
*"Мы используем электронное лабораторное — базу данных, куда записываются данные всех экспериментов... Публичные рейтинги ответа не давали, так что мы собрали свой бенчмарк."* — koreec, автор оригинальной статьи.
Методология тестирования: 24 вопроса и 450 прогона
Для оценки моделей был создан набор из 24 вопросов, основанных на реальных рабочих задачах. Эксперимент включал 19 комбинаций различных моделей (Claude, GPT-4, DeepSeek) и уровней вычислительных усилий (reasoning effort). Всего было проведено около 450 независимых прогонов.
Вопросы были разделены на несколько категорий: * Навигация: поиск нужного образца и определение его местоположения в базе. * Извлечение: чтение данных из прикрепленных файлов (например, времени подгонки). * Рассуждение: многошаговые вычисления, например, сравнение толщины пленки с записанной скоростью процесса. * Ловушки: ситуации, где данные могут ввести в заблуждение (например, артефакты измерения или несоответствие единиц измерения). * Честность и отказ: тестирование реакции модели на пустые результаты или запросы, нарушающие правила (например, попытки записи данных в режиме только для чтения).
Оценка ответа проходила по трем строгим критериям: «верно» (правильный ответ), «со ссылкой» (указание источника данных) и «честно» (признание неуверенности или невозможности). Задача считалась пройденной только при полном совпадении всех трех параметров.
Ключевые категории: ловушки и честность
Самая сложная часть теста заключалась в группе «ловушек», которые проверяли способность модели анализировать сырые данные, а не полагаться на поверхностное понимание.
Одной из задач было определение температуры подложки. Сырые данные канала температуры содержали странные скачки между фиксированными кодами, что указывало на отказ датчика. Модель, игнорирующая эти аномалии, могла привести ложные значения, тогда как правильный ответ требовал назвать канал ненадежным и воздержаться от использования этих данных.
Другой пример — чтение значений из файлов подгонки рефлектометрии. Два файла с похожими именами содержали данные по разным образцам. Правильный ответ должен был содержать значение из нужного файла и отметить наличие второго файла, который был проигнорирован. Ошибка в десятикратном пересчете единиц измерения (нанометры против ангстрем) также входила в список критических ошибок.
Авторы подчеркивают, что на таком наборе данных результаты варьировались от 75% до 100%. Более того, стоимость выполнения одной и той же задачи различалась в 40 раз — от 12 центов до почти 5 долларов за 24 вопроса. Это означает, что в масштабах бизнеса экономическая эффективность может стать решающим фактором.
Результаты: победа экономичных моделей
Итоги эксперимента оказались неожиданно демократичными. Модели с высокими публичными рейтингами, такие как Opus 5.5, действительно показывали отличный результат, но достигая его, требовали значительных инвестиций. Напротив, более экономичные версии моделей продемонстрировали сопоставимое или даже лучшее соотношение цены и качества.
В частности, модель DeepSeek Flash 4.1 на максимальном уровне усилий (max) достигла идеальных 24 правильных ответов из 24, обойдясь в $0.63 за задачу. Это дешевле, чем аналогичный результат от Opus 5.5, который стоил около $3.19.
Другие интересные находки: * Модель Haiku 4.5 набрала только 18 баллов, проиграв в тестах на честность. * GPT-6-Astra на максимальном уровне усилий оказалась самой дорогой опцией ($4.94 за 24 вопроса), но не продемонстрировала преимуществ перед более дешевыми настройками. * Усиление вычислений (reasoning effort) не всегда приводило к улучшению результатов. Например, для модели GPT-6.1-Sol увеличение усилий не дало прироста в количестве правильных ответов.
Авторы отмечают, что после добавления правил о необходимости читать сырые строки и открывать полные файлы, все конфигурации Claude смогли пройти группу ловушек с идеальным результатом. Однако разрыв по критерию «честности» между разными моделями сохранился.
Как собрать свой бенчмарк
Для тех, кто хочет воспроизвести подобный опыт, авторы предлагают четкий алгоритм действий:
1. Составьте набор задач: Возьмите 20–30 вопросов из реальной рабочей среды, которые вы разбирали в последнее время. 2. Актуализируйте данные: Запишите правильные ответы с текущей системы, так как данные в живой базе могут меняться. 3. Оценивайте строго: Используйте трехбалльную шкалу (верно/со ссылкой/честно) и требуйте выполнения всех критериев. 4. Добавьте ловушки: Включите задачи с противоречивыми данными или запросы на действия, запрещенные политикой безопасности (например, попытку записи). 5. Заморозьте параметры: Используйте фиксированный системный промпт, один диалог на задачу и только инструменты для чтения. 6. Не выбирайте лучший ответ вручную: Оценивайте результат только по первому ответу модели, независимо от его качества. Это позволяет измерить способность модели давать правильные ответы самостоятельно. 7. Логируйте вызовы: Записывайте все вызовы инструментов и их стоимость. Анализ логов часто показывает, где именно модель упала, даже если текст ответа кажется приемлемым.
Для удобства повторения эксперимента авторы разместили универсальную версию бенчмарка на GitHub в репозитории ToolBench. Там можно найти готовые вопросы, промпты и конфигурацию MCP для интеграции со своими задачами.
Изучение результатов показывает, что выбор LLM не должен основываться исключительно на абстрактных рейтингах. Понимание конкретных ограничений, стоимости и требований к «честности» модели позволяет бизнесу найти оптимальное решение, которое будет не только качественным, но и экономически эффективным.