---
title: "Модель или обвязка: где искать причину сбоя"
description: Почему смена модели обычно не чинит агента, как отличить потолок возможностей модели от сбоя обвязки и что проверить раньше, чем вырастет счёт за инференс.
---

## Как выглядит ложный диагноз

Внутренний агент ищет документы и управляет ими. Он работает, пока 12–15% запросов не начинают падать: возвращается не тот документ, редактируется не тот файл, система молча умирает или уверенно ссылается на несуществующий файл. Ошибки размазаны по пользователям и функциям.

Первое действие — поменять модель на верхушку лидерборда. Счёт за инференс вырастает в 4–5 раз, доля ошибок падает с 12% до 9%. Пользователи пишут о том же. Следующий квартал бюджета сгорает ради трёх процентных пунктов, а причина так и не найдена.

## Система, а не модель

Модель живёт внутри обвязки, и итог складывается из обеих частей:

```text
качество системы ≈ возможности модели × качество обвязки
```

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

- слой оркестрации и терминальные условия;
- ретраи — к провайдеру и внутри рутин обвязки;
- retrieval и переранжирование;
- описания и схемы инструментов;
- управление контекстом;
- валидацию вывода.

Промпт-инжиниринг — только часть обвязки, и обычно не главная. Одна и та же модель в разных харнессах показывает разный результат: разница в том, как среда подаёт контекст и что запрещает — см. [Ассистенты и среды разработки](https://wpcraft.ru/kb/ai/coding/harnesses.md).

## Три сигнала в пользу модели и три — в пользу обвязки

| Сигнал | Что означает |
|---|---|
| Ошибки не сдвигаются при итерации промпта, ретраев и механизмов retrieval | Узкое место, вероятно, в модели |
| Характер ошибки совпадает с известным capability gap: планирование на длинном горизонте, глубокое рассуждение в узкой нише | Модель не дотягивает до задачи |
| Контролируемый A/B на одной и той же обвязке показывает явное улучшение | Модель действительно сильнее |
| Ошибки кластеризуются вокруг конкретных инструментов, сценариев или состояний | Сбой в обвязке |
| Ретраи делают ошибки менее наблюдаемыми и маскируют их | Сбой в обработке ошибок |
| Та же модель на другой обвязке даёт существенно другой результат на тех же входах | Сбой в обвязке |

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

## Порядок работы: сначала доказать решаемость

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

Обратный путь — стартовать на дешёвой и наращивать при неудаче — ловушка. Вы тратите дни, не понимая, что перед вами: баг обвязки или потолок модели. Если передовая модель не решает задачу, более слабая не поможет, сколько ни вкладывай в обвязку.

## Что попробовать до смены модели

Большинство шагов стоит несколько часов инженерного времени и ничего не добавляет к счёту за инференс.

1. **Логируйте каждый вызов инструмента, ретрай и терминальное состояние.** Не воспроизводится сбой — не найдётся причина.
2. **Разделите transient и структурные ошибки** в политике ретраев: лечить их одинаково нельзя.
3. **Измерьте точность retrieval** на маленьком размеченном наборе, прежде чем винить генерацию.
4. **Тестируйте каждое описание инструмента изолированно** — не весь агент, а один контракт.
5. **Разрешите агенту ответить «не знаю».** Большинство обвязок этот валидный ответ не предусматривает.
6. **Зафиксируйте размер контекста** и измерьте качество в строгом лимите: рост окна маскирует проблему управления контекстом.
7. **Валидируйте структурированный вывод** и возвращайте ошибку агенту на следующий ход в явном виде.
8. **Поменяйте модель на следующий тир на той же обвязке.** Небольшой разрыв в метриках — узкое место в обвязке.

## Model swap как измерение

Смена модели полезна не как лечение, а как тест. Один и тот же набор задач прогоняется на разных моделях без изменений в коде обвязки:

```python
import pytest
from harness import run_suite

MODELS = ["frontier-model", "cheap-model"]


@pytest.mark.parametrize("model", MODELS)
def test_suite_on_same_harness(model):
    result = run_suite(model=model, dataset="evals/agent-tasks.jsonl")
    assert result.metrics["task_completion"] >= 0.8
    # Печатаем разбивку, а не только общий success rate
    print(result.breakdown_by_component())
```

Читать результат нужно так:

- **Резкий и чистый прирост** на всех компонентах — вероятно, упёрлись в потолок модели, и апгрейд оправдан.
- **Небольшой прирост при росте цены** — узкое место в обвязке; деньги уходят в шум.
- **Прирост только на части компонентов** — модель решает конкретный capability gap, остальное надо чинить отдельно.

## Без раздельного наблюдения этого не видно

Все шаги выше предполагают, что вы умеете локализовать источник сбоя. У большинства команд есть одна end-to-end метрика — success rate, стоимость токенов и немного продуктовых сигналов вроде удовлетворённости. Когда такая метрика меняется, модель и обвязка неразличимы.

Решение — покомпонентные проверки и трассировка: [Наблюдаемость](https://wpcraft.ru/kb/ai/agents/observability.md) показывает, что произошло внутри запроса, [Покомпонентные evals](https://wpcraft.ru/kb/ai/evals/component-evals.md) закрепляют это в повторяемых проверках.

## Что проверить в проекте

- **Известно ли, на каком шаге падает запрос.** Если ответ «модель плохая», это не диагноз.
- **Есть ли лог ретраев.** Тихие повторы скрывают структурные ошибки.
- **Проверялся ли retrieval отдельно.** Большая часть «галлюцинаций» — это неверный контекст.
- **Есть ли у агента право не отвечать.** Отсутствие отказа гарантирует уверенную выдумку.
- **Сравнивались ли модели на одной обвязке.** Иначе решение об апгрейде принимается по впечатлению.

## Материалы и источники

- [Почему ломается ваш AI-агент — и почему смена модели обычно его не чинит](https://habr.com/ru/articles/1039292/) — Артем Тарасов
- [Evals: что должен знать каждый AI-инженер в 2026](https://habr.com/ru/articles/1050736/) — Артем Тарасов, раздел о сигналах «модель или обвязка»
- [Anthropic: Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
- [Anthropic: A statistical approach to model evaluations](https://www.anthropic.com/research/statistical-approach-to-model-evals)