Выбор модели для ИИ-агента - это не поиск “самой умной модели вообще”. Агент работает в конкретном сценарии: отвечает по RAG, вызывает tools, пишет в CRM, ведет чат поддержки, работает с кодом или документами. Поэтому модель нужно выбирать по задаче, стоимости, задержке, контексту, structured output, качеству tool calling и требованиям к данным.
Короткая версия: соберите eval dataset, выберите 2-4 кандидата, проверьте их на своих сценариях, сравните качество, tool calls, latency, стоимость, контекст и безопасность. Часто лучший вариант - не одна модель, а model routing: быстрая модель для простых запросов и сильная для сложных.
Что мы собираем
Соберем практический процесс выбора модели для ИИ-агента. Он подойдет для OpenAI, Claude, Gemini, локальных моделей через Ollama/LM Studio и гибридных стеков.
- Формулируем задачи агента.
- Определяем требования к модели.
- Готовим eval dataset.
- Сравниваем модели на одинаковых сценариях.
- Считаем стоимость и latency.
- Проверяем tool calling, RAG и structured output.
- Выбираем основную модель, fallback и правила routing.
Шаг 1. Опишите сценарий агента
Одна и та же модель может быть хороша для анализа документов и средне работать в коротком support-чате. Начните не с названия модели, а с задач.
- Агент поддержки: точность, тон, источники, handoff.
- CRM-агент: structured output, tool calling, аккуратность с данными.
- RAG-агент: groundedness, работа с источниками, длинный контекст.
- Coding agent: код, тесты, работа с файлами, понимание репозитория.
- Локальный агент: приватность, скорость на вашем железе, качество на русском.
- Multi-agent система: стабильность на коротких специализированных шагах.
Если сценариев несколько, возможно, вам нужны разные модели для разных этапов.
Шаг 2. Выпишите обязательные требования
У модели есть не только “качество”. Для агента важны прикладные свойства.
- Поддержка function/tool calling.
- Structured output или стабильный JSON.
- Длина context window.
- Скорость ответа и p95 latency.
- Цена input/output tokens.
- Качество на русском языке.
- Работа с RAG-контекстом.
- Мультимодальность, если нужны изображения, аудио или видео.
- Политика данных и возможность enterprise-контуров.
- Доступность API и лимиты.
Список требований помогает не переплачивать за флагманскую модель там, где нужна быстрая классификация.
Шаг 3. Соберите eval dataset
Не выбирайте модель по ощущениям из 5 вопросов. Нужен маленький, но реальный dataset.
[
{
"input": "Клиент хочет вернуть оплату через 40 дней",
"expected": "не обещает возврат, ищет policy, предлагает handoff",
"tags": ["support", "policy", "risk"]
},
{
"input": "Создай лид: Анна, +79990000000, нужен агент для сайта",
"expected": "вызывает create_crm_lead с валидными аргументами",
"tags": ["crm", "tool_calling"]
}
]Для старта хватит 30-50 примеров. Включите обычные вопросы, edge cases, плохие формулировки, prompt injection, RAG, tools и отказы.
Шаг 4. Сравнивайте модели одинаково
Каждую модель нужно запускать на одном и том же наборе сценариев, с одним системным промптом, одинаковыми tools и одинаковым RAG-контекстом. Иначе сравнение будет нечестным.
Фиксируйте:
- версию модели;
- prompt version;
- temperature и другие параметры;
- список tools;
- RAG индекс и top_k;
- дату теста;
- результаты evals.
Модель, которая победила сегодня, может проиграть после изменения промпта или индекса. Поэтому сравнение нужно хранить.
Шаг 5. Проверяйте tool calling отдельно
Для ИИ-агента мало красивого текста. Модель должна правильно выбирать tools и передавать аргументы.
- Вызывает нужный tool.
- Не вызывает tool без необходимости.
- Передает валидные аргументы.
- Умеет уточнить недостающие поля.
- Не вызывает опасный tool при prompt injection.
- Корректно реагирует на ошибку tool.
Если модель отлично пишет ответы, но плохо вызывает tools, она может не подойти для агентного сценария.
Шаг 6. Проверяйте structured output
Для CRM, классификации, routing, multi-agent и evals часто нужен строгий JSON. Проверьте, насколько модель держит схему.
{
"route": "support",
"confidence": 0.88,
"needs_human": false,
"reason": "Пользователь спрашивает инструкцию по настройке"
}Даже при structured output backend должен валидировать ответ. Но если модель постоянно ломает схему, вы потратите много сил на repair logic.
Шаг 7. Не переоценивайте длинный контекст
Большое context window полезно для документов, кода и длинных диалогов. Но оно не заменяет RAG, фильтрацию и хороший отбор контекста.
- Длинный контекст дороже.
- Нерелевантный контекст может ухудшить ответ.
- Большой prompt увеличивает latency.
- Модель может не одинаково хорошо находить все факты в огромном контексте.
- Для часто используемых данных может помочь caching.
Правило простое: сначала отдавайте модели нужный контекст, а не весь доступный.
Шаг 8. Считайте стоимость на сценарий
Цена за токены сама по себе мало что говорит. Важна стоимость одного полезного результата.
cost_per_run =
input_tokens * input_price
+ output_tokens * output_price
+ tool_cost
+ retry_cost
+ reviewer_costСравнивайте:
- стоимость одного ответа;
- стоимость успешного ответа;
- стоимость с RAG и без RAG;
- стоимость с QA/reviewer;
- стоимость multi-agent run;
- стоимость на 1000 обращений.
Иногда более дорогая модель выгоднее, если она реже ошибается и требует меньше повторов.
Шаг 9. Сравните latency
Пользователь в чат-виджете и backend-задача терпят разную задержку. Для support-чата важна скорость первого ответа, для аналитического отчета важнее качество.
- Chat widget: лучше короткая задержка и streaming.
- Telegram: можно чуть дольше, если есть “думаю...”.
- CRM summary: можно выполнять в фоне.
- Batch-анализ документов: latency не критична.
- Tool calling: задержка модели плюс задержка внешних API.
Смотрите не только среднее время, но и p95: редкие долгие ответы часто портят UX сильнее.
Шаг 10. Проверьте русский язык и доменную лексику
Если агент работает на русском, не полагайтесь на англоязычные benchmarks. Проверьте ваши реальные формулировки.
- короткие запросы с опечатками;
- смешение русского и английских терминов;
- отраслевые слова;
- тон поддержки;
- юридически аккуратные формулировки;
- инструкции и списки;
- summary для менеджера.
Локальная модель может быть достаточно хороша для черновиков, но слабее в тонких отказах, юридических ограничениях и сложном tool calling.
Шаг 11. Добавьте model routing
Часто не нужно выбирать одну модель навсегда. Можно маршрутизировать задачи.
fast_model:
- классификация;
- простые ответы;
- summary;
- routing.
strong_model:
- сложные вопросы;
- risky cases;
- финальная проверка;
- длинные документы;
- tool planning.
local_model:
- приватные черновики;
- локальные документы;
- офлайн-сценарии.Model routing снижает стоимость и latency, но добавляет сложность. Его нужно тестировать так же, как multi-agent маршрутизацию.
Шаг 12. Назначьте fallback
У API бывают лимиты, ошибки и задержки. Для production-агента нужен fallback.
- Если сильная модель недоступна, перейти на резервную.
- Если fallback слабее, отключить risky tools.
- Если structured output ломается, передать человеку или вернуть безопасную ошибку.
- Если локальная модель не справляется, предложить cloud mode.
- Если превышен бюджет, ограничить дорогие сценарии.
Fallback должен быть безопаснее, а не просто “любой ценой ответить”.
Мини-чеклист
- Сценарии агента описаны.
- Требования к модели выписаны.
- Есть eval dataset из реальных задач.
- Проверены tool calling и structured output.
- RAG tested отдельно от обычных ответов.
- Посчитаны cost per run и p95 latency.
- Проверен русский язык и доменная лексика.
- Есть основная модель и fallback.
- Для простых/сложных задач продуман model routing.
- Решение сохранено с версией модели, промпта и датой теста.
Частые вопросы
Какая модель лучше для ИИ-агента?
Та, которая лучше проходит ваши сценарии. Для одного агента важнее tool calling, для другого - длинный контекст, для третьего - цена и скорость. Универсального ответа без eval dataset нет.
Нужно ли всегда брать самую сильную модель?
Нет. Сильная модель может быть дороже и медленнее. Для классификации, routing, коротких summary и простых ответов часто достаточно более быстрой и дешевой модели.
Когда нужна локальная модель?
Когда важны приватность, офлайн-режим, контроль над инфраструктурой или эксперименты с open-source моделями. Но локальные модели нужно отдельно проверять на качестве, скорости и tool calling.
Длинный контекст лучше RAG?
Не всегда. Длинный контекст полезен, когда нужно дать много данных сразу. RAG полезен, когда база большая, обновляется и нужно выбирать только релевантные фрагменты. На практике их часто комбинируют.
Как часто пересматривать выбор модели?
После изменения задач, промпта, tools, RAG-индекса, бюджета или появления новой версии модели. Но менять модель без regression evals не стоит: новая модель может улучшить одни сценарии и сломать другие.
