«Модель тупит» — почему этот диагноз почти всегда ложный
Знакомая картина: агент долго отвечал чисто, а на очередном диалоге выдал дичь. Первая реакция у всех одинаковая: модель поглупела, давайте менять на что посильнее. Это удобный диагноз — он снимает ответственность с обвязки и перекладывает её на поставщика весов.
Проблема не в том, что модель плоха. Проблема в том, что «виновата модель» почти никогда не значит «чинить дообучением». Почти всегда модель честно ответила ровно на то, что ей дали на вход. Просто дали не то, или её валидный ответ дальше по конвейеру никто не смог прочитать.
Проверяется это за одну минуту. Возьмите тот самый упавший диалог и посмотрите не на финальный ответ, а на то, что реально пришло модели на вход конкретного шага. Чаще всего там уже видно поломку: обрезанный контекст, чужой формат, ошибка инструмента, которую приняли за пустой результат. Модель здесь — не подсудимый, а свидетель.
Таксономия из 41 режима: у каждого отказа есть адрес
Свежая таксономия отказов агентов от исследователей Scale AI — работа «Model or Harness? An Interaction-Centric Taxonomy for Localizing Agent Failures» (arXiv, июль 2026) — разложила сбои на 41 режим. Ценно в ней не число, а принцип: каждому отказу дали адрес. Не «модель плохая» вообще, а конкретная точка в системе, где всё разъехалось.
Это ровно то, что мы видим руками. У сбоя всегда есть место жительства:
- модель отдала валидный ответ, но не в том формате, которого ждал следующий шаг;
- инструмент вернул ошибку, а агент не отличил её от пустого ответа;
- контекст не доехал до нужного шага, и решение принималось вслепую;
- роутер увёл диалог не в ту ветку с самого начала.
Когда у отказа есть адрес, спор заканчивается. Не нужно гадать про «интеллект» — нужно пойти по адресу и посмотреть, что там сломалось. Это переводит разговор из плоскости веры («эта модель умнее, давайте её») в плоскость инженерии («порвалось вот здесь, чиним вот так»).
Ломается не компонент, а ребро между компонентами
Вот главная мысль, ради которой всё затевалось. Мы привыкли думать про систему как про набор кубиков: модель, база, инструменты, интерфейс. И когда что-то падает, ищем плохой кубик. А рвётся почти всегда не кубик — рвётся ребро между кубиками. Шов.
Модель увидела запрос — модель вернула ответ — парсер ждал другой формат — шаг упал. Модели не в чем себя упрекнуть, она отработала. Инструмент не в чем упрекнуть, он вернул структуру. Порвалось на стыке между ними, там, где один компонент передаёт эстафету другому и никто не проверил, что палочку взяли правильно.
Поэтому смена модели тут бесполезна. Она станет сильнее — а шов, на котором рвётся, останется прежним. Более умная модель точно так же отдаст ответ парсеру, который не умеет его читать. Вы заплатите за интеллект, которого хватало и раньше, и не почините ровно ту точку, из-за которой прод лёг.
Это расходится с интуицией руководителя, и в этом вся ловушка. Кажется логичным: плохой результат — берём инструмент помощнее. Но контур держит не мощность отдельных деталей, а качество стыков между ними.
Наша коллекция сбоев за год: что отказывало на самом деле
За год у меня накопилась своя коллекция отказов. Почти все они жили в обвязке, а не в весах. Расскажу без хайпа, потому что честнее показать, что ломается и как чиню, чем делать вид, что всё летает само.
- Формат. Модель выдала валидный ответ, а парсер ждал другой формат и уронил шаг. Классика. Модель права, шаг мёртв.
- Ошибка против пустоты. Инструмент вернул ошибку, а агент не отличил её от пустого результата и пошёл дальше как ни в чём не бывало. Дальше он строит выводы на дырке в данных — и делает это уверенно.
- Недоехавший контекст. До нужного шага не доехало то, что решало всё. Модель честно ответила на то, что ей дали, просто дали не то. Со стороны выглядит как галлюцинация, а по факту — недоставка на входе.
- Роутер. Диалог с первого хода ушёл не в ту ветку. Дальше всё внутри ветки работало идеально — идеально не туда.
Общий знаменатель один: сменить модель ни в одном из этих случаев не помогло бы. Все четыре шва живут ниже уровня весов, в том слое, который каждый норовит назвать «мелочью». А держит контур именно эта мелочь.
Как чинить: промпт, контекст и оркестрация вместо дообучения
Порядок разбора у нас всегда один, и дообучение в нём даже не первая мысль — оно почти никогда не нужно.
- Воспроизвести отказ ровно на этом шве. Не «в целом бывает глючит», а конкретный шаг, который порвался. Пока сбой не ловится руками стабильно, чинить нечего.
- Добавить проверку формата. На стыке модель → парсер поставить контроль: пришло не то — не роняем шаг молча, а ловим и обрабатываем.
- Научить агента отличать ошибку инструмента от пустого ответа. Это разные вещи, и вести себя на них надо по-разному. Ошибка — повод остановиться или переспросить, пустота — валидный факт «ничего не нашлось».
- Зафиксировать вход шага. Явно закрепить, что именно приходит на вход, чтобы контекст доезжал целиком, а не по остаточному принципу.
- Проверить маршрут. Убедиться, что роутер уводит диалог в ту ветку, а развилки не срабатывают наугад.
Это уровень промпта, контекста и оркестрации — то есть обвязки. Скучная инженерия. Не привычный «успешный успех» с новой волшебной моделью, а работа по швам. Зато она даёт то, чего смена модели не даёт: сбой перестаёт повторяться, потому что вы починили причину, а не заглушили симптом мощностью.
Чек-лист диагностики для руководителя
Вам не нужно лезть в код, чтобы задать команде правильные вопросы. Когда агент упал, спросите по порядку:
- На каком ребре порвалось? Не «какая модель», а между какими двумя шагами. Если ответа нет — инцидент ещё не разобран.
- Что реально пришло на вход этого шага? Не что мы думали, что придёт, а что пришло по факту.
- Модель ответила валидно, но её ответ не прочитали — или ответила плохо? Это две разные починки.
- Агент отличил ошибку инструмента от пустого результата? Или пошёл дальше по дырке в данных?
- Сбой воспроизводится руками? Если нет — сначала ловим, потом чиним.
- Предложение «давайте сменим модель» закрывает конкретный шов или просто дороже? Чаще второе.
Если на эти вопросы есть ответы — вы уже не спорите про «интеллект», вы чините систему. Инженерная честность, без обещаний: не всякий сбой лечится за вечер, но почти всякий лечится по адресу, а не заменой весов. Хотите посмотреть, как контур ведёт себя вживую и где у него швы — видно открыто.
Частые вопросы
01Значит, модель вообще ни при чём и менять её никогда не надо?
Бывает, что и надо — под новую задачу или язык. Но это осознанное решение, а не рефлекс на падение прода. Сначала находим шов; если после починки швов упирается именно в потолок модели — тогда меняем, зная зачем.
02У нас нет своей команды разработки. Как мы это вообще проверим?
Начните с одного вопроса на разборе: «на каком ребре порвалось». Он не требует кода и мгновенно показывает, разобрались в инциденте или просто ищут виноватого. Дальше по чек-листу выше — его хватает, чтобы не дать увести себя в спор про интеллект.
03Почему подрядчики так любят диагноз «модель тупит»?
Он снимает ответственность и звучит солидно. Проверить обвязку — значит признать, что шов не доделали у себя. Списать на модель проще: виноват абстрактный поставщик весов, а не конкретный парсер, который забыли прикрыть проверкой.
04Как понять, что проблема в недоехавшем контексте, а не в галлюцинации?
Посмотреть вход шага. Если на входе не было нужных данных, а модель что-то придумала — это недоставка контекста, чинится в обвязке. Если данные были, а ответ всё равно мимо — тогда уже разговор про сам шаг и промпт.
05С чего начать наводить порядок, если агент уже на проде и периодически падает?
Завести журнал входов на каждом шаге, чтобы отказ можно было воспроизвести ровно на шве. Дальше — по порядку из раздела про починку. Если хотите разобрать свой конкретный случай — [напишите мне в личные сообщения](https://maksim-trofimov.ru), обсудим по швам, без хайпа.

