Модель или обвязка: где искать причину сбоя

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, стоимость токенов и немного продуктовых сигналов вроде удовлетворённости. Когда такая метрика меняется, модель и обвязка неразличимы.

Решение — покомпонентные проверки и трассировка: Наблюдаемость показывает, что произошло внутри запроса, Покомпонентные evals закрепляют это в повторяемых проверках.

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

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

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

• Почему ломается ваш AI-агент — и почему смена модели обычно его не чинит — Артем Тарасов
• Evals: что должен знать каждый AI-инженер в 2026 — Артем Тарасов, раздел о сигналах «модель или обвязка»
• Anthropic: Demystifying evals for AI agents
• Anthropic: A statistical approach to model evaluations