Как выбрать модель для ИИ-агента: качество, цена, контекст и tools

Что получится в результате

Соберем практическую схему выбора модели для ИИ-агента. Не будем выбирать модель по рекламному названию или общему бенчмарку. Вместо этого сделаем короткий тестовый контур: список задач агента, требования к tool calling, контексту, скорости, цене, безопасности, качеству ответов, fallback и мониторингу. На выходе будет не одна "лучшая модель", а понятная модельная конфигурация: быстрая модель для простых шагов, сильная модель для сложных решений, отдельная модель для embeddings и резервный маршрут.

В результате будет рабочий MVP:

1. сценарии агента описаны в `agent_task_catalog`;
2. требования к модели лежат в `model_requirements`;
3. кандидаты моделей хранятся в `candidate_models`;
4. capability matrix лежит в `model_capabilities`;
5. тестовые задачи лежат в `eval_cases`;
6. эталонные ответы лежат в `expected_outputs`;
7. результаты прогонов пишутся в `eval_runs`;
8. стоимость запросов пишется в `cost_log`;
9. задержки фиксируются в `latency_log`;
10. качество tool calling пишется в `tool_call_results`;
11. ошибки JSON и schema validation пишутся в `schema_validation_log`;
12. правила маршрутизации лежат в `model_routing_rules`;
13. fallback-настройки лежат в `fallback_policy`;
14. лимиты токенов лежат в `context_budget`;
15. guardrails лежат в `safety_rules`;
16. все prompts, ответы и решения пишутся в `audit_log`;
17. ошибки провайдера и повторы пишутся в `error_log`.

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

Что понадобится

Минимальный набор:

1. описание одного ИИ-агента и его задач;
2. 30-50 реальных или синтетических тестовых кейсов;
3. список инструментов агента;
4. схема ожидаемых JSON-ответов;
5. бюджет на 1000 задач;
6. допустимая задержка ответа;
7. список запрещенных действий;
8. 3-6 моделей-кандидатов от разных провайдеров или разных классов;
9. embeddings-модель, если агент использует RAG;
10. таблица или база для логов тестирования;
11. человек, который проверит спорные ответы.

Для первого запуска достаточно трех кандидатов: `fast_model`, `balanced_model`, `reasoning_model`. Конкретные `model_id` храните в `candidate_models`, чтобы можно было обновить их без переписывания логики агента.

Шаг 1. Опишите агента как набор задач

Не выбирайте модель до того, как описаны задачи.

Создайте `agent_task_catalog`.

Колонки:

id
agent_name
task_code
task_name
input_type
output_type
risk_level
frequency
requires_tools
requires_reasoning
requires_long_context

Пример задач:

support_agent | classify_ticket | классифицировать обращение | text | json | low | high | no | low | no
support_agent | draft_reply | подготовить ответ | text+kb | text | medium | high | yes | medium | medium
support_agent | refund_decision | предложить возврат | text+crm | json | high | low | yes | high | medium
support_agent | escalate_case | передать оператору | text | action | medium | medium | yes | low | no

Проверка: у каждой задачи есть риск, частота, тип входа и формат выхода.

Шаг 2. Разделите задачи по классам моделей

Один агент не обязан работать на одной модели.

Типовая схема:

1. `fast_model` для классификации, маршрутизации, коротких ответов;
2. `balanced_model` для обычных диалогов, RAG-ответов и summary;
3. `reasoning_model` для сложных решений, многошаговых задач и спорных кейсов;
4. `embedding_model` для поиска по документам;
5. `local_model` для приватных или дешевых внутренних задач;
6. `fallback_model` на случай ошибки провайдера.

Проверка: задача `classify_ticket` не уходит в дорогую reasoning-модель без причины.

Шаг 3. Сформулируйте требования в `model_requirements`

Создайте `model_requirements`.

Колонки:

id
agent_name
task_code
must_have_json
must_have_tool_calling
must_have_vision
must_have_audio
min_context_tokens
max_latency_ms
max_cost_per_1000_tasks
min_quality_score
data_residency
safety_level

Пример:

draft_reply | yes | yes | no | no | 32000 | 6000 | 8.00 | 0.82 | any | medium
refund_decision | yes | yes | no | no | 64000 | 12000 | 15.00 | 0.90 | restricted | high

Проверка: если задача требует JSON и tools, модель без стабильного structured output не попадает в shortlist.

Шаг 4. Создайте `candidate_models`

Не храните model id в коде агента.

Колонки:

id
provider
model_id
model_role
status
input_price_unit
output_price_unit
context_window
supports_json
supports_tools
supports_vision
supports_audio
notes
updated_at

`model_role`:

1. `fast`;
2. `balanced`;
3. `reasoning`;
4. `embedding`;
5. `reranker`;
6. `local`;
7. `fallback`.

Проверка: заменить модель можно обновлением строки в `candidate_models`, а не изменением кода workflow.

Шаг 5. Заполните capability matrix

Создайте `model_capabilities`.

Колонки:

id
model_id
capability
score
evidence
tested_at

Оценивайте:

1. следование system prompt;
2. стабильный JSON;
3. tool calling;
4. работа с длинным контекстом;
5. RAG-ответы с citations;
6. отказ от ответа без данных;
7. качество русского языка;
8. устойчивость к prompt injection;
9. скорость;
10. стоимость;
11. качество reasoning;
12. качество summary;
13. качество классификации;
14. мультимодальность;
15. доступность API.

Проверка: у каждого score есть тест или наблюдение, а не впечатление "модель умная".

Шаг 6. Сделайте тестовый набор `eval_cases`

Без evals выбор модели будет угадыванием.

Создайте `eval_cases`.

Колонки:

id
agent_name
task_code
case_name
input_json
expected_behavior
risk_level
tags
is_active

Соберите минимум:

1. 10 обычных кейсов;
2. 5 сложных кейсов;
3. 5 кейсов с неполными данными;
4. 5 кейсов с prompt injection;
5. 5 кейсов с ошибками инструментов;
6. 5 кейсов, где нужно отказаться от ответа;
7. 5 кейсов с большим контекстом;
8. 5 кейсов на точный JSON.

Проверка: тесты покрывают реальные действия агента, а не только чатовые вопросы.

Шаг 7. Опишите эталон в `expected_outputs`

Эталон не всегда должен быть буквальным текстом.

Колонки:

id
eval_case_id
expected_json_schema
must_include
must_not_include
allowed_actions
forbidden_actions
human_review_notes

Пример:

must_include | "requires_approval": true
must_not_include | "refund_sent": true
allowed_actions | create_refund_draft
forbidden_actions | send_refund, delete_ticket

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

Шаг 8. Проверьте structured output

Если агент работает с действиями, JSON важнее красивого текста.

Тестируйте:

1. валидный JSON;
2. соответствие schema;
3. отсутствие лишних ключей;
4. правильные enum;
5. числовые типы;
6. даты в ISO;
7. пустые значения как `null`;
8. отказ от выдуманных полей.

Создайте `schema_validation_log`.

Колонки:

id
eval_run_id
model_id
schema_name
is_valid
errors_json
raw_output_hash
created_at

Проверка: модель, которая часто ломает JSON, не подходит для агента с tools.

Шаг 9. Проверьте tool calling

Создайте `tool_call_results`.

Колонки:

id
eval_run_id
model_id
tool_name
expected_tool
actual_tool
arguments_valid
dangerous_call_detected
result_status
created_at

Проверяйте:

1. модель выбирает правильный tool;
2. аргументы соответствуют schema;
3. модель не вызывает tool без разрешения;
4. модель не повторяет tool бесконечно;
5. модель корректно обрабатывает ошибку tool;
6. модель просит недостающие данные, если их нет.

Проверка: на кейсе "вернуть деньги клиенту" модель создает `refund_draft`, а не вызывает `send_refund`.

Шаг 10. Проверьте RAG и citations

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

Проверяйте:

1. использует ли модель retrieved chunks;
2. указывает ли citations;
3. не добавляет ли факты из памяти;
4. говорит ли "не найдено", если ответа нет;
5. не путает похожие документы;
6. выдерживает ли длинный контекст;
7. не раскрывает документы без доступа.

Проверка: если retrieval пустой, ответ не должен содержать уверенный факт.

Шаг 11. Проверьте reasoning

Reasoning нужен не всем задачам.

Используйте сильную модель для:

1. сложного планирования;
2. анализа противоречий;
3. выбора последовательности tools;
4. диагностики ошибок;
5. SQL-планирования;
6. юридических рисков;
7. финансовых проверок;
8. спорных customer support решений;
9. генерации тестовых сценариев;
10. проверки safety cases.

Не используйте дорогой reasoning там, где достаточно классификации или шаблонного summary.

Проверка: routing отправляет сложный кейс в `reasoning_model`, а простую классификацию в `fast_model`.

Шаг 12. Проверьте контекстное окно

Большой context window полезен, но не заменяет RAG.

Создайте `context_budget`.

Колонки:

id
task_code
system_tokens
developer_tokens
user_tokens
retrieval_tokens
tool_tokens
reserved_output_tokens
max_context_tokens

Правила:

1. оставляйте резерв на output;
2. не отправляйте всю базу знаний;
3. режьте длинные цепочки сообщений;
4. summary старого диалога храните отдельно;
5. tables и документы передавайте фрагментами;
6. большие файлы обрабатывайте pipeline, а не одним prompt.

Проверка: запрос не падает из-за переполнения контекста.

Шаг 13. Проверьте скорость

Создайте `latency_log`.

Колонки:

id
model_id
task_code
input_tokens
output_tokens
ttfb_ms
total_ms
status
created_at

Измеряйте:

1. time to first token;
2. полное время ответа;
3. время tool call loop;
4. время retry;
5. p50;
6. p90;
7. p95;
8. p99.

Проверка: модель для онлайн-чата укладывается в UX-лимит, а тяжелые задачи уходят в фоновую очередь.

Шаг 14. Проверьте стоимость

Создайте `cost_log`.

Колонки:

id
model_id
task_code
input_tokens
output_tokens
cached_tokens
estimated_cost
created_at

Считайте:

1. стоимость одного запроса;
2. стоимость 1000 задач;
3. стоимость retry;
4. стоимость tools;
5. стоимость embeddings;
6. стоимость reranking;
7. стоимость fallback;
8. стоимость логирования и хранения.

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

Шаг 15. Проверьте безопасность

Создайте `safety_rules`.

Колонки:

id
agent_name
rule_code
description
severity
action
is_active

Проверяйте:

1. prompt injection;
2. jailbreak;
3. раскрытие system prompt;
4. вызов запрещенного tool;
5. вывод персональных данных;
6. уверенный ответ без данных;
7. обход approval;
8. попытки удалить данные;
9. внешнюю отправку;
10. работу с секретами.

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

Шаг 16. Проверьте русский язык и стиль

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

Проверяйте:

1. естественный русский;
2. отсутствие машинной канцелярщины;
3. корректные термины;
4. сохранение тона бренда;
5. правильное обращение к пользователю;
6. способность писать коротко;
7. отсутствие лишней воды;
8. корректные даты, суммы и единицы.

Проверка: ответ можно отправить пользователю без переписывания человеком.

Шаг 17. Запустите eval run

Создайте `eval_runs`.

Колонки:

id
eval_case_id
model_id
prompt_version
output_text
output_json
quality_score
latency_ms
estimated_cost
passed
failure_reason
created_at

Алгоритм:

1. выберите активные `eval_cases`;
2. прогоните каждую модель;
3. провалидируйте JSON;
4. проверьте tools;
5. посчитайте latency;
6. посчитайте cost;
7. сохраните score;
8. отметьте failed cases;
9. отправьте спорные ответы человеку.

Проверка: решение по модели основано на `eval_runs`, а не на одном ручном тесте.

Шаг 18. Посчитайте итоговый score

Сделайте простую формулу.

Пример весов:

quality_score | 40
tool_call_score | 20
schema_score | 15
safety_score | 15
latency_score | 5
cost_score | 5

Для рискованных агентов увеличьте вес safety и schema. Для массовых дешевых задач увеличьте вес latency и cost.

Проверка: модель с отличным текстом, но плохим tool calling не выигрывает у агента, который должен выполнять действия.

Шаг 19. Создайте правила маршрутизации

Создайте `model_routing_rules`.

Колонки:

id
agent_name
task_code
condition_json
primary_model_role
fallback_model_role
max_retries
requires_human_review
is_active

Примеры:

classify_ticket | any | fast | balanced | 1 | no
draft_reply | kb_context_exists | balanced | fallback | 1 | no
refund_decision | risk_level=high | reasoning | balanced | 0 | yes
sql_generation | database_write=true | reasoning | none | 0 | yes

Проверка: high-risk задача не идет в дешевую модель только из-за экономии.

Шаг 20. Настройте fallback

Создайте `fallback_policy`.

Колонки:

id
model_role
fallback_order_json
retry_on_errors_json
do_not_retry_on_json
human_handoff_on_fail

Fallback нужен при:

1. timeout;
2. rate limit;
3. provider error;
4. invalid JSON;
5. tool call loop;
6. safety uncertainty;
7. low confidence;
8. context overflow.

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

Шаг 21. Настройте human review

Не все нужно автоматизировать.

Отправляйте на человека:

1. high-risk решения;
2. финансовые действия;
3. юридические выводы;
4. отправку внешних писем;
5. изменение данных;
6. низкую confidence;
7. конфликтующие источники;
8. нарушение schema;
9. повторные ошибки tool;
10. жалобы пользователей.

Проверка: задача с `risk_level = high` не завершается автоматическим действием.

Шаг 22. Версионируйте prompts

Создайте `prompt_versions`.

Колонки:

id
agent_name
task_code
prompt_role
version
content
status
created_at

Правила:

1. не меняйте prompt без версии;
2. eval run должен хранить `prompt_version`;
3. сравнивайте модель и prompt вместе;
4. не выкатывайте новый prompt без регрессионного теста;
5. системные правила отделяйте от пользовательского контента.

Проверка: можно понять, модель ухудшилась или prompt изменился.

Шаг 23. Сделайте наблюдение в production

Создайте мониторинг.

Метрики:

1. pass rate;
2. invalid JSON rate;
3. tool error rate;
4. fallback rate;
5. human review rate;
6. average cost;
7. p95 latency;
8. safety flags;
9. user correction rate;
10. answer satisfaction.

Проверка: если invalid JSON rate вырос, вы видите это до жалоб пользователей.

Шаг 24. Проведите контрольный тест

Прогоните 5 типов задач.

Тест:

1. простая классификация обращения;
2. RAG-вопрос по документу;
3. tool call с безопасным действием;
4. high-risk действие с approval;
5. prompt injection внутри пользовательского текста.

Ожидаемый результат:

1. классификация идет в `fast_model`;
2. RAG идет в `balanced_model`;
3. сложное решение идет в `reasoning_model`;
4. опасное действие идет в `approval_queue`;
5. prompt injection блокируется guardrails;
6. все события есть в `audit_log`.

Проверка: выбранная модельная схема проходит тест целиком, а не только отвечает красиво в чате.

Шаг 25. Минимальный результат для запуска

MVP выбора модели готов, если выполнены условия:

1. есть `agent_task_catalog`;
2. есть `model_requirements`;
3. есть минимум 3 кандидата в `candidate_models`;
4. есть 30-50 `eval_cases`;
5. проверены JSON и tools;
6. посчитана стоимость;
7. измерена latency;
8. проверен RAG;
9. проверен prompt injection;
10. настроены routing rules;
11. настроен fallback;
12. high-risk задачи уходят на human review;
13. production-логи пишутся в `audit_log`, `cost_log`, `latency_log` и `error_log`.

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

Что нельзя автоматизировать в первой версии

В первой версии не автоматизируйте:

1. выбор модели только по публичному бенчмарку;
2. автоматическую замену модели без evals;
3. high-risk действия без human review;
4. tool calls без schema validation;
5. работу без fallback;
6. ответы по RAG без citations;
7. отправку персональных данных в непроверенную модель;
8. использование одной модели для всех задач;
9. работу без cost limit;
10. работу без latency monitoring;
11. обновление prompts без версий;
12. обработку prompt injection только надеждой на модель;
13. хранение API keys в prompt;
14. выбор локальной модели без теста качества;
15. production-запуск без audit log.

Сначала выберите модельную схему для одного агента, прогоните evals и только потом переносите подход на другие агенты.

Частые вопросы

Можно ли выбрать одну модель для всего агента?

Можно для простого MVP, но чаще выгоднее разделить задачи: быстрая модель для классификации, сбалансированная для обычных ответов, сильная reasoning-модель для сложных решений и отдельная embedding-модель для RAG.

Что важнее: качество или цена?

Зависит от задачи. Для массовой классификации цена и скорость важны сильнее. Для финансового, юридического или action-агента важнее safety, structured output, tool calling и human review.

Нужна ли модель с большим контекстом?

Да, если агент работает с длинными документами, переписками или логами. Но большое окно не заменяет RAG, фильтрацию, summary и контекстный бюджет.

Как понять, что модель подходит для tool calling?

Прогоните eval cases: правильный tool, валидные аргументы, отсутствие опасных вызовов, корректная обработка ошибки tool и стабильный JSON. Если модель ломает schema, она плохо подходит для агентных действий.

Когда нужна локальная модель?

Локальная модель полезна для приватных данных, дешевых внутренних задач и автономной работы. Но ее нужно тестировать так же, как облачную: качество, JSON, tools, latency, стоимость инфраструктуры и безопасность.