ИИ-гайды

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

Разбор от редакции «ИИ для чайников» · Обновлено 21 мая 2026

💡 О чём гайд
Гайд о том, как выбрать LLM-модель, которая решит вашу задачу не самой дешёвой, а самой эффективной по цене успешного результата. Вы узнаете, почему публичные бенчмарки недостаточны, как построить приватную эвалюацию, какие параметры (thinking, effort, prompt caching) помогают сдвинуть кривую качества-стоимости, и получите практические приёмы анализа логов для обнаружения реальных ошибок моделей.

📢 Больше разборов — в канале «ИИ для чайников»

📄 Скачать гайд (PDF) 📢 Канал ИИ для чайников

Правильная модель — та, что дешевле за успешный результат, не за токен

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

Prompt caching сохраняемый префикс стоит в 10 раз дешевле и даёт доступ к возможностям более умных моделей в бюджете дешёвых

Контекстный инжиниринг сокращает токены на 65-77% и часто повышает точность чистых данных

Thinking и effort — параметры для тонкой настройки компромисса между качеством, латентностью и стоимостью

Более умные модели (Opus) работают стратегически и генерируют меньше лишних шагов, экономя токены

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

При выборе модели для продукта нужно оценивать три ключевых параметра:

Качество модели — точность и процент успешного выполнения задачи
Латентность — критично для пользовательских (customer-facing) сценариев
Стоимость — ключевой фактор для многих проектов

Создание собственной эвалюации (Eval)

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

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

Входные данные (input)
Критерии успеха (success criteria)

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

Способы проверки:

LLM как судья (judge): Гибкая проверка итогового ответа или корректности шагов (например, SQL-запросов)
Детерминированные проверки (code-based): Точная проверка обязательных действий (например, вызов конкретного инструмента)

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

Типичные ошибки при построении эвалюаций

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

Важность анализа логов (Transcripts)

Обязательно настройте удобную observability (LangSmith, BrainTrust и др.), чтобы видеть:

Системные промпты
Вызовы инструментов агентом
Результаты инструментов

Только «закопавшись» в логи, можно обнаружить реальные паттерны и ошибки (например, модель, подсматривающая ответ из истории предыдущих попыток).

Инструменты для управления компромиссами

Используйте параметры Claude для тонкой настройки:

Thinking (Мышление): Даёт модели «черновик» для размышлений перед действием (System 2 thinking). Может быть адаптивным (модель решает сама) или фиксированным
Effort (Усилие): Указывает модели, сколько «работы» вложить в задачу (влияет на длину reasoning, tool calls и ответов)

Контр-интуитивный вывод: Более умные модели (Opus) могут выполнять задачи быстрее и с меньшим числом токенов, так как действуют стратегически и делают меньше «лишних» шагов.

Сдвиг кривой эффективности

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

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

Сохраняемый префикс промпта стоит в 10 раз дешевле
Позволяет получить качество Opus по цене Sonnet, а Sonnet — по цене Haiku
Стратегия: Используйте подход «append-only». Системный промпт должен быть неизменным (immutable), динамические данные добавляются только в конец

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

Оптимизируйте ответы инструментов, которые передаются модели
Примеры оптимизаций:
- Используйте Markdown вместо JSON
- Упрощайте форматы дат
- Добавляйте полезные метаданные (день недели)
- Дедуплицируйте данные (например, статьи из веб-поиска)
Результат: Сокращение токенов на 65-77%, снижение стоимости и часто — повышение точности модели за счёт более чистых данных

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

Цель: Запустить эвалюацию (на примере Tao Bench для авиа-агента) с разными конфигурациями:

Модели: Haiku, Sonnet, Opus
Параметры: thinking on/off, разный уровень effort

Результаты (на примере прогона) наглядно показывают на графиках:

Pass rate vs. выходные токены
Pass rate vs. стоимость
Pass rate vs. латентность

Это позволяет принять взвешенное решение, основанное на данных, а не на интуиции.

Выбор модели — это не вопрос опубликованных рейтингов, а взвешенное решение, основанное на приватных эвалюациях вашего кейса. Комбинируйте правильный выбор модели с параметрами thinking, effort, prompt caching и контекстным инжинирингом — это даст вам доступ к качеству более умных моделей в бюджете дешёвых и откроет новые сценарии автоматизации.

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

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

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

Как выбирать модель — по цене за токен или по цене успеха?

Правильный критерий — стоимость успешного результата (cost per successful outcome). Более дорогая модель часто экономит токены благодаря стратегическому подходу и может быть дешевле в сумме. Используйте параметры thinking и effort, кэширование промптов и контекстный инжиниринг, чтобы не просто двигаться по кривой качества-стоимости, а сдвинуть её целиком.

Как контекстный инжиниринг помогает сэкономить?

Контекстный инжиниринг оптимизирует формат данных, которые передаются модели: Markdown вместо JSON, упрощённые даты, полезные метаданные, дедупликация. Это сокращает количество токенов на 65-77%, снижает стоимость и часто повышает точность, так как модель получает более чистые и структурированные данные.

Почему нужно анализировать логи (transcripts)?

Логи помогают отделить реальные проблемы модели от инфраструктурных сбоев (ошибки API, инструментов). Анализируя системные промпты, вызовы инструментов и результаты, вы обнаруживаете настоящие паттерны ошибок и можете корректировать промпты под особенности конкретной модели.