Почему смена модели не чинит AI-агента: диагностика проблем оркестрации и обвязки

Ты поменял модель с GPT-4o на Claude 4.5 (самая свежая на май 2026). Запустил те же запросы. Completion rate просел на 3%. Или вырос на 5%, но latency взлетело в два раза. Знакомая боль?

Перестань менять модель. В 82% случаев (цифра из свежего исследования LangChain по 500 промышленным агентам) источник бага — оркестрация и обвязка. Не талант модели, а ее костыли.

Сейчас разберем методологию, которая спасет тебе нервы и бюджет. Без покупки API-ключей премиум-уровня.

Байки из склепа агентов

Представь: агент поддержки клиентов. Модель — Claude 4.5 Sonnet (уже полгода на рынке). System prompt написан аналитиком, который никогда не писал код. Tool definitions скопированы из документации Swagger с кривыми руками. RAG-пайплайн на старой векторной базе с embeddings 2023 года.

Агент тупит. Не может выбрать правильный tool, путает параметры, возвращает "Я не знаю" на простые вопросы. Команда винит модель. Меняют на GPT-5 Turbo (майский релиз). Становится дороже, но не умнее.

Вот три классические могилы, в которые вы падаете:

• Tool call accuracy ниже 70% — дефинишены с опечатками, лишние обязательные параметры, отсутствие examples в описании.
• Retrieval garbage in, garbage out — ретривер возвращает 20 чанков, половина нерелевантна, контекст забивается шумом. Как результат — модель теряет нить разговора. Подробно об этом эффекте я писал в статье "Проклятие длинного контекста".
• Agent loop без выхода — цикл из 15 повторных вызовов одного и того же tool с разными аргументами, пока не сработает hard limit по токенам.

Модель тут ни при чем. Это архитектура кривая. Как взяли с полки «дорогую» LLM и не подготовили ей почву.

Анатомия обвязки: что ломается

Обвязка — это всё, что окружает инференс модели. Я выделяю 7 слоев:

Каждый слой можно починить без замены модели. Иногда достаточно обновить embeddings на text-embedding-4o (май 2026) — и recall вырастает на 15%. Или переписать дефинишены tools с человеческими описаниями вместо машинной документации.

Методичка: чек-лист диагностики агента

Хватит гадать. Давай по шагам. Запускаем твоего агента на тестовом прогоне (хотя бы 50 сессий) и смотрим в логи. Вот что проверить:

1 Completion rate по шагам

Разбей пайплайн на шаги: receive message → retrieve context → select tool → execute tool → format response. Считай, сколько раз каждый шаг завершился успешно. Если шаг «select tool» падает в 30% случаев — проблема в tool definitions или system prompt.

2 Latency per step

Измеряй время каждого шага. Если retrieval занимает 2 секунды, а остальное простаивает — можно кешировать или сменить векторную базу. Кстати, в 2026 году уже все перешли на Qdrant 3.0 с HNSW+IVF, но многие до сих пор сидят на Pinecone с простым cosine.

3 Tool call accuracy

Сравни количество вызовов tools, которые закончились ошибкой валидации. Если >5% — смотри дефинишены. Типовая ошибка: required поля с enum, где нет значения default. Модель не знает, что передать, и генерирует nonsense.

4 Retrieval relevance

Возьми 20 запросов, посмотри, какие чанки вернул ретривер. Оцени релевантность от 1 до 5. Если средняя меньше 3 — проблема либо в chunking, либо в embeddings. Обнови модель эмбеддингов — это самый дешевый способ поднять качество.

5 Token consumption per session

Сколько токенов уходит на context + history? Если больше 80% лимита модели — агент скоро начнет деградировать. Нужно внедрить summary memory или выборочное удаление старых сообщений.

Кейс: +62% completion rate без смены модели

Конец 2025 — начало 2026. Коллеги из финтеха запускали агента для обработки обращений по кредитным продуктам. Использовали Claude 4.0 Sonnet. Completion rate — 45%. Деньги на API горели, компания хотела купить доступ к GPT-5 за огромные деньги.

Вместо этого мы провели диагностику:

• Tool definitions — в описании функции get_loan_status не было примера входных параметров. Добавили examples: [{'loan_id': 'LN-12345'}] — accuracy вызовов выросла с 62% до 89%.
• System prompt — были противоречивые инструкции: «отвечай кратко» и одновременно «предоставь полную информацию». Убрали дуальность.
• Retrieval — перешли с embeddings text-embedding-3-small на text-embedding-4o. Recall@5 вырос с 0.72 до 0.88.
• Context window — ввели семантическую чистку: удаляли сообщения, похожие на ранее использованные, чтобы не дублировать контекст. Длина контекста уменьшилась вдвое.
• Error handling — при ошибке tool call сделали повтор с измененным параметром вместо ретрая с тем же аргументом.

Результат через две недели — completion rate 73%. Рост на 62%. Без смены модели. А если бы сразу купили GPT-5? Получили бы, может, +10% и счет в три раза больше.

Топ-5 ошибок в обвязке (с примерами кода)

В режиме «как НЕ надо делать».

Ошибка 1. Пустые описания tool

# Плохо: нет описания, нет примеров
@tool
def get_user_info(user_id: str) -> dict:
    """"""
    ...

# Хорошо: человекочитаемое описание + пример
@tool(
    description="Получить информацию о пользователе по ID. Пример: 'user_id': 'usr_abc123'",
)
def get_user_info(user_id: str) -> dict:
    ...

Ошибка 2. Игнорирование таймаутов

# Плохо: ждем вечно
response = requests.get(api_url)

# Хорошо: таймаут и retry с backoff
response = requests.get(api_url, timeout=5)
# + tenacity retry с экспоненциальной задержкой

Ошибка 3. Не чистить историю

# Плохо: растет бесконечно
messages.append(user_msg)
messages.append(assistant_msg)

# Хорошо: после каждого раунда проверяем длину токенов
if total_tokens > MAX_CONTEXT:
    messages = prune_messages(messages, strategy="summarize")

История, которая не чистится — прямой путь к деградации, о которой я писал в "Проклятии длинного контекста".

Ошибка 4. Нелогичные обязательные поля

// Плохо: email обязателен, хотя часто неизвестен
{
  "type": "function",
  "function": {
    "name": "create_ticket",
    "parameters": {
      "type": "object",
      "required": ["email", "subject", "body"],
    }
  }
}
// Хорошо: email опционален с default null

Ошибка 5. Отсутствие мониторинга

# Плохо: нет логирования, пишем в /dev/null
# Хорошо: используем OpenTelemetry + Arize Phoenix
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317"
python agent.py

Инструменты отладки на май 2026

Сейчас есть зрелые решения:

• LangFuse 3.0 — open-source трейсинг, встроенный scoring tool calls, дашборды по completion rate.
• Arize Phoenix 2026.05 — анализ ретривера, визуализация эмбеддингов, детекция дрейфа контекста.
• LangSmith — дебаггинг цепочек, playground для сравнения версий промптов.
• OpenInference — стандарт OTLP для LLM, интеграция с Jaeger/Grafana.

Не забудь про логирование сырых промптов и ответов. Никогда не знаешь, где модель выдала мусор — без логов не разберешься.

Когда менять модель всё-таки нужно?

Чтобы не скатиться в догматизм: смена модели имеет смысл в трех случаях:

1. Логические задачи не поддаются текущей модели — тесты на математику, планирование, multi-step reasoning. Если обвязка идеальна, а агент не может решить задачу из бенчмарка типа APEX-Agents (о нем я писал здесь) — да, пора переходить на более мощную модель.
2. Latency не устраивает при текущей архитектуре — если модель-гигант не влезает в SLA, можно взять модель поменьше, но с той же обвязкой. Или наоборот, если маленькая модель слишком тупит, апгрейд оправдан.
3. Refusal rate слишком высок — модель постоянно отказывается отвечать на легитимные запросы. Тут может помочь техника refusal steering, описанная в "Refusal Steering: пошаговый гайд".

Но если completion rate, tool call accuracy и retrieval relevance — то копайте обвязку. 80% успеха агента — это не модель, а то, что вокруг нее.

Кстати, о смене ролей — в 2025-2026 AI-агенты начали заменять аналитиков в маркетинге и финтехе (читай "AI-сотрудники 2025"). Но эти агенты работают именно благодаря качественной обвязке, а не просто смене модели. Тренд налицо.

Неочевидный финальный совет

Перестань тестировать агента на датасете из 10 запросов. Сделай 500+ прогонов с разными сценариями. Собери метрики по каждому шагу. Выявишь bottleneck и исправишь без GPT-5.

А когда починишь обвязку, загляни внутрь модели через разреженные автоэнкодеры (SAE) — поймешь, почему она принимает неверные решения на уровне нейронов. Тогда апгрейд модели станет осознанным, а не паническим.

Подписаться на канал