Выбор LLM-модели: от бенчмарков к успешному

Три столпа выбора модели

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

Совет: Правильная модель — та, что даёт нужное качество при минимальной стоимости успешного результата, а не просто самая дешёвая.

Приватные эвалюации: почему нужны и как строить

Почему публичные бенчмарки недостаточны

Публичные бенчмарки (SWE-bench, MMLU, MATH) дают лишь общее направление, но не отражают специфику вашей рабочей нагрузки. Они не учитывают:

• Ваши инструменты и интеграции
• Реальный формат данных в продакшене
• Специфические критерии успеха
• Паттерны ошибок вашего бизнеса

Структура приватной эвалюации

Эвалюация — это набор атомарных задач (test cases), каждая содержит:

1. Входные данные (input) — промпт, контекст, параметры
2. Ожидаемый результат — правильный ответ или последовательность шагов
3. Критерии успеха — как判定 правильность (точное совпадение, LLM-судья, код-проверка)

Способы проверки результатов

Важно: Создание репрезентативного набора тестовых данных — одно из самых эффективных вложений времени в автоматизацию с помощью ИИ.

Типичные ошибки и диагностика проблем

Четыре главных ошибки при построении эвалюаций

1. Шум вместо сигнала: Если результаты сильно «плавают» при повторных запусках, возможно:
   • Задача плохо определена
   • Критерии оценки не выровнены
   • Недостаточно тестовых примеров
2. Инфраструктурные сбои вместо ошибок модели: Падение метрик может быть вызвано:
   • Ошибками API инструментов
   • Сбоями сетевых вызовов
   • Временными ограничениями
   Решение: Анализируйте логи (transcripts), чтобы отделить инфраструктурные проблемы от проблем модели.
3. «Тихое насыщение» (Silent saturation): Набор данных не растёт вместе с реальными запросами.
   • Старые эвалюации перестают ловить новые ошибки
   • Метрики стабилизируются на ложном плато
   Решение: Создавайте петлю обратной связи — собирайте трейсы, анализируйте ошибки продакшена и добавляйте их в эвалюацию.
4. Игнорирование особенностей моделей: Каждая модель (даже разные версии Claude) имеет нюансы в промптировании и поведении.
   • При смене модели необходимо читать руководства
   • Переадаптировать промпты под API конкретной версии

Как анализировать логи (Transcripts)

Настройте инструменты для наблюдения (observability), чтобы видеть:

• Системные промпты, отправленные модели
• Вызовы инструментов и их результаты
• Полные трейсы выполнения агента

Только «закопавшись» в логи, можно обнаружить реальные паттерны ошибок, например:

• Модель «подсматривает» ответ из истории предыдущих попыток
• Неправильный формат вызова инструмента
• Стратегическая ошибка в цепочке рассуждений

Thinking и Effort: параметры для настройки компромиссов

Современные модели (Claude) поддерживают параметры, которые позволяют тонко управлять балансом между качеством, латентностью и стоимостью:

Контр-интуитивный вывод о более умных моделях

Ключевая идея: Opus может выполнять задачи быстрее и дешевле, чем Haiku, потому что действует стратегически. Opus делает меньше лишних шагов, избегает тупиков и генерирует оптимальное число токенов. Дешёвая модель часто требует больше попыток и переделок.

Это означает, что выбор модели по цене за токен часто ведёт к ложной экономии.

Сдвиг кривой эффективности: три рычага

Можно не просто двигаться по кривой «качество-стоимость», а сдвинуть её целиком. Три основных рычага:

1. Кэширование промптов (Prompt Caching)

• Сохраняемый префикс промпта стоит в 10 раз дешевле обычного контекста
• Позволяет использовать возможности более умных моделей в бюджете дешёвых:
  • Качество Opus по цене Sonnet
  • Качество Sonnet по цене Haiku

2. Контекстный инжиниринг (Context Engineering)

Оптимизируйте формат данных, которые передаются модели:

Результат контекстного инжиниринга: Сокращение токенов на 65–77%, снижение стоимости и часто — повышение точности модели за счёт более чистых данных.

3. Итеративная оптимизация промптов

Анализируйте логи, выявляйте паттерны ошибок и корректируйте промпты под особенности конкретной модели.

Практический эксперимент: запуск sweep-эвалюации

Цель: На реальном примере (например, авиа-агент или техподдержка) запустить эвалюацию с разными конфигурациями и увидеть результаты на графиках.

Конфигурация sweep-эксперимента

• Модели для сравнения: Haiku, Sonnet, Opus
• Параметры thinking: вкл./выкл.
• Параметры effort: low, medium, high
• Размер кэша: без, с кэшированием префикса

Метрики на выходе

Результаты визуализируются на трёх графиках:

1. Pass rate vs. выходные токены — видна эффективность: какая модель даёт макс качество при минимальных выходах
2. Pass rate vs. стоимость — финансовая целевая функция: какая конфиг дешевле за правильный ответ
3. Pass rate vs. латентность (P50/P95) — для пользовательских приложений

Интерпретация результатов

Обычная картина:

• Haiku solo: 60–75% pass rate, дешево, медленно учится
• Sonnet + thinking: 85–92%, хороший баланс
• Opus + кэш: 95%+ по цене Sonnet

После такого эксперимента решение принимается на данных, а не на интуиции или маркетинге модели.

Чек-лист: от теории к практике

Используйте этот чек-лист, чтобы структурировать свой процесс выбора модели:

1. Определите метрики успеха
   • Какой процент задач должна решать модель? (pass rate, accuracy, F1)
   • Какая максимальная латентность приемлема?
   • Какой бюджет на токены/месяц?
2. Соберите репрезентативный набор тестов
   • Минимум 20–50 примеров вашего реального кейса
   • Включите edge cases и трудные задачи
   • Определите критерии успеха для каждого теста
3. Запустите базовый эксперимент
   • Протестируйте хотя бы 2–3 модели: Haiku, Sonnet, Opus
   • Сравните без оптимизаций (plain prompting)
   • Соберите метрики: pass rate, avg tokens, latency
4. Включите параметры thinking/effort
   • Попробуйте thinking на лучшей модели из шага 3
   • Варьируйте effort (low/medium/high) на Sonnet/Opus
   • Обновите таблицу результатов
5. Оптимизируйте контекстный инжиниринг
   • Упростите формат данных, которые передаёте модели
   • Включите полезные метаданные
   • Перезапустите эвалюацию, смотрите улучшение pass rate и снижение токенов
6. Апробируйте prompt caching
   • Если у вас есть большой неизменяемый системный промпт, кэшируйте его
   • Добавляйте только динамические данные в каждый запрос
   • Соберите метрики по стоимости (cost per successful outcome)
7. Внедрите мониторинг ошибок в продакшене
   • Создайте обратную связь: падение метрик = добавить тест в эвалюацию
   • Регулярно перезапускайте sweep, чтобы видеть, улучшаются ли результаты
8. Примите решение, основанное на данных
   • Выберите модель и конфигурацию с лучшим балансом качества и стоимости под вашу задачу
   • Документируйте выбор и причины (для следующего пересмотра через 2–3 месяца)