Пошаговая отладка ошибочных ответов в федеративном стеке

Почему команды обвиняют не тот шаг

Когда команда видит неверный ответ, обычно начинают с последнего вывода на экране. Звучит логично: финальная модель сгенерировала слова — значит, ей и достаётся вина.

В федеративном стеке это часто неверная отправная точка.

Один ответ проходит через несколько шагов прежде, чем пользователь его увидит. Извлечение подтягивает исходный материал. Маршрутизация выбирает модель, промпт или рабочий поток. Инструменты делают живые запросы или запускают действия — например, проверяют заказ или опрашивают базу данных. Рецензент или постобработка могут переписать черновик перед отправкой.

Значит, видимая ошибка могла начаться гораздо раньше. Саппорт-ассистент получает вопрос о цене, подтягивает старую страницу с прайсом, маршрутизатор направляет запрос в общий поток вместо биллингового, вызов инструмента срывается из‑за отсутствия ID аккаунта, а в финальной правке модель «заглаживает» неопределённость. Ответ выглядит отшлифованным. Он всё ещё неверен.

Команды привыкли обвинять последнюю модель, потому что её легче всего проверить. Логи извлечения, решения маршрутизатора и трассы инструментов часто хранятся в разных местах. Правки рецензентов — ещё где‑то. Люди идут за тем, что они видят, а не за шагом, где ответ впервые ушёл в сторону.

Это меняет задачу. Ваша цель — не найти последнюю видимую ошибку. Ваша цель — найти первый сломанный шаг.

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

Когда команда трассирует ответ по порядку, обсуждение становится гораздо яснее. Вместо «модель плохая» можно сказать: «этот шаг сломал ответ, и вот доказательства».

Картируйте путь ответа

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

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

Для большинства систем путь выглядит так:

1. Пользователь присылает промпт.
2. Маршрутизатор выбирает модель или workflow.
3. Извлечение, память или поиск добавляют контекст.
4. Инструменты выполняются и возвращают данные.
5. Рецензент, guardrail или редактор изменяет ответ перед отправкой.

Теперь замените общие ярлыки реальными именами. Запишите версию модели, название ретривера, очередь или раннер задач, конкретный инструмент и любой человеческий контакт. «LLM» слишком расплывчато. «Рецензент» тоже слишком общо, если этот шаг может означать движок правил, агента поддержки или скрипт очистки.

Затем укажите, где хранится доказательство. Рядом с каждым шагом запишите источник логов, Trace ID, имя события или дашборд, который показывает, что шаг действительно произошёл. Если след обрывается после маршрутизации — укажите это. Отсутствие логов тоже часть бага. Многие команды обвиняют последнюю модель, потому что это единственная часть, где ещё остался читаемый след.

Простой пример делает это конкретным. Если ответ поддержки прошёл через Claude для маршрутизации, PostgreSQL search для извлечения, Python-инструмент для статуса аккаунта и человека‑рецензента в очереди — запишите эти четыре шага в таком порядке. Если рецензент видел только переписанный черновик, включите и это.

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

Проследите один ответ от начала до конца

Выберите один плохой ответ и идите по нему, пока не найдёте поломку. Не смешивайте его с тремя другими похожими ошибками. Команды часто так делают и начинают спорить о несуществующих паттернах.

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

Добавьте временные метки ко всем шагам. Секунды имеют значение. Если извлечение вернуло неверный документ в 10:14:02, а рецензент изменил тон в 10:14:09, то рецензент не создавал фактическую ошибку. Таймлайн сохраняет честность.

Полезная трасса обычно требует всего нескольких полей:

• имя шага
• время
• что шаг получил на вход
• что шаг вернул
• любая правка или оверрайд человеком

Затем сравните каждый шаг как пару вход‑выход. Читайте их рядом. Отправил ли маршрутизатор запрос не тому инструменту? Пропустил ли ретривер документ с нужной датой? Вернул ли инструмент пустой результат, который модель превратила в догадку?

Остановитесь, как только найдёте первое несоответствие. Назовите его простыми словами. «Retrieval вернул статью о ценах, а пользователь спрашивал про политику возврата» — гораздо лучше, чем «путаница модели» или «плохое качество ответа».

Простой кейс: пользователь спрашивает «Можно ли экспортировать журналы аудита за март?» Финальный ответ говорит, что экспорт недоступен. На первый взгляд кажется, что модель ошиблась. Трасса же показывает другое: ретривер отправил старую страницу помощи, инструмент проверял не тот workspace, а рецензент лишь сократил ответ. Ошибка началась задолго до того, как модель написала слово.

Такой трейс обычно занимает минуты. Он может сэкономить дни бесплодных споров.

Смотрите извлечение до того, как читать ответ

Большинство команд начинают с финального ответа. Это обычно ошибка. Если извлечение подложило модели плохие материалы, у ответа не было шансов.

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

Обычная ошибка проста. Клиент спрашивает про 30‑дневное окно возврата, а извлечение приносит прошлый FAQ с правилом 14 дней. Модель звучит уверенно, потому что на входе у неё действительно была политика — просто неправильная.

При проверке извлечения проверьте несколько базовых вещей. Появился ли правильный источник вообще? Если да, не оказался ли он под рыхлым материалом? Пришли ли результаты из устаревших документов, архивных заметок или неправильной продуктовой области? Блокировали ли нужный источник фильтры по тегам, правам доступа или дате?

Дубликаты фрагментов — ещё одна проблема. Три похожих сниппета могут многократно повторить одно и то же устаревшее утверждение и создать иллюзию сильного доказательства. Модель начинает воспринимать повторение как подтверждение.

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

Чрезмерный контекст мешает так же, как и его нехватка. Если нужный фрагмент лежит рядом со старыми тикетами, протоколами встреч и обширными продукт‑доками, модель может ответить общим сюжетом, а не точным фактом.

Прежде чем судить модель, прочитайте извлечённый текст. Отметьте, какой фрагмент должен был ответить на вопрос, какие фрагменты были шумом и какие никогда не должны там были быть. Этот первый проход быстро сузит круг поиска.

Проверьте маршрутизацию и вызовы инструментов

Неверный ответ часто начинается до того, как модель написала предложение. Маршрутизатор мог отправить запрос не той модели, пропустить инструмент или перейти на более слабый путь после тайм‑аута. Если вы читаете только финальный ответ, вы упускаете реальную причину.

Начните с лога маршрутизации и восстановите последовательность. Какой модели пришёл запрос? Какие инструменты система вызвала? Сколько времени занял каждый шаг? Были ли повторные попытки, тайм‑ауты или переключения путей под нагрузкой?

Читайте лог маршрута как таймлайн, а не сводку. Многие системы маршрутизируют по теме, стоимости, задержке или размеру токенов. Это нормально — пока, например, финансовый вопрос не пометят как casual chat и не отправят в общую модель.

Затем проверьте входы инструментов, а не только выходы. Инструмент может работать идеально и всё равно вернуть не то, если модель передала неверные параметры. Если пользователь просит «открытые счета за март», а вызов инструмента запросил все счета, поломка произошла до ответа инструмента.

Короткий обзор обычно даёт достаточно:

• прочитать решение маршрутизатора и правило или счёт, стоящий за ним
• сопоставить каждый вход инструмента с точными словами пользователя
• отметить повторы, тайм‑ауты и fallback-маршруты
• проверить, вернул ли инструмент частичные, кэшированные или устаревшие данные
• отметить первый шаг, где трасса перестаёт соответствовать запросу

Простой пример: пользователь спрашивает остаток на складе на сегодня. При пиковой нагрузке маршрутизатор выбирает более дешёвый fallback. Эта модель вызывает инструмент инвентаризации по правильному product ID, но инструмент тайм‑аутит, делает одну ретраю и отдаёт кэш вчерашнего дня. Финальный ответ звучит уверенно. Модель не корень проблемы: она ответила на основе старых данных, потому что путь к инструменту сломался.

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

Сравните черновики и правки рецензентов

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

Начните с простого diff'а. Поставьте черновик модели рядом с финальным ответом и отметьте каждое изменение. Маленькие правки имеют значение. Одно удалённое предложение может убрать условие, предупреждение или ограничение, которые сохраняли ответ верным.

Большинство ошибок при ревью попадают в несколько паттернов. Рецензент добавляет формулировку, которая звучит увереннее, чем черновик. Он удаляет оговорку, чтобы сократить текст. Переписывает фразу так, что она читается лучше, но меняет смысл. Или по ошибке вставляет внутреннюю заметку в финальный ответ.

Последние два случаются чаще, чем думают. Переписанная фраза может звучать чище и при этом потерять деталь, которая делала её истинной. Внутренняя заметка вроде «проверить источник» или «возможно, старая политика» может просочиться в ответ и запутать пользователей.

Следите за потерей охвата. Если черновик говорил «это относится только к платным аккаунтам, созданным после запуска новой биллинговой системы», а рецензент вычеркнул это для краткости, финальный ответ теперь неверен для большого числа пользователей. Модель там ни при чём — правка изменила смысл.

Помечайте правки по типу, а не только по человеку. Это помогает быстро заметить шаблоны. Если рецензенты постоянно удаляют оговорки или заменяют точные формулировки широкими утверждениями, исправляйте руководство по ревью, а не перенастраивайте модель.

Также полезно хранить заметки рецензентов отдельно от текста ответа. Внутренние комментарии, метки одобрения и подсказки по копирайту не должны храниться в том же поле, что и сообщение, доходящее до пользователя.

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

Простой пример ошибки

Пользователь спрашивает у бота поддержки базовый биллинговый вопрос: «Что входит в текущий Pro‑план и сколько он стоит в месяц?» Ответ кажется спокойным, отшлифованным и уверенным. Проблема: он использует детали плана прошлого года.

Первый сбой произошёл до того, как модель что‑то написала. Извлечение подтянуло старую страницу с прайсом из архива вместо актуального биллингового документа. Если никто не проверяет логи извлечения, финальный ответ выглядит как ошибка генерации, хотя плохой вход пришёл первым.

Второй сбой — маршрутизация. Систему направили через общий поток поддержки вместо биллингового потока. Это важно: общая модель может отвечать из того контекста, что получила, а биллинговый поток обычно имеет более строгие правила источников и фильтры для актуальных цен.

Далее ответ попадает к рецензенту. Рецензент сглаживает тон, убирает грубую фразу и делает сообщение более полезным. Он не замечает, что месячная цена неверна. После этой правки ответ выглядит ещё более доверительным, и ошибку сложнее заметить.

Затем приходит жалоба. Команда открывает последний вывод модели, видит неправильную цифру и обвиняет последнюю модель. Это обычная картина, и она тратит время. Модель действительно ответила неверно, но она сделала это на основе устаревшего извлечения и неверной маршрутизации.

Поэтому порядок проверки важен. Начинайте с того, что спросил пользователь, затем смотрите, что вернуло извлечение, затем — какой путь обработал запрос, какие инструменты сработали, и только потом — что изменил рецензент. Если вы аудитируете только финальный текст, вы исправите стиль и оставите реальную ошибку на месте.

Ошибки, которые скрывают реальную причину

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

Одна распространённая ошибка — смешение логов из разных запросов. Чат поддержки, повторная попытка, фоновая проверка и ручной перезапуск могут казаться связанными, особенно если происходят в пределах нескольких минут. Если request ID изменился, рассматривайте это как другую историю.

Ещё одна ловушка — зелёная метка «успех». Пайплайн мог завершиться ровно так, как задумано, и при этом выдать бессмыслицу. «Успех» часто значит «ничего не упало», а не «ответ верный».

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

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

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

• сначала сопоставьте request ID, временную метку и ход пользователя
• сравните сырые входы с опубликованным ответом
• отметьте любые человеческие правки после генерации
• рассматривайте «успех» как сигнал доставки, а не качества

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

Быстрые проверки для вашей команды

Хорошая трассировка должна казаться скучной. Если один плохой ответ превращается в долгий спор, вероятно, команда не видит полный путь запроса в одном месте.

Выберите один реальный запрос и заставьте всех следовать по одной и той же тропе. Начните с сообщения пользователя. Идите через извлечение, маршрутизацию, вызовы инструментов, черновики и ручные правки в том порядке, в котором они произошли.

Простой чек‑лист лучше ещё одного огромного дашборда. Спросите:

• Может ли один человек открыть один запрос и увидеть каждый шаг в порядке, не перескакивая между пятью инструментами?
• Может ли команда сопоставить каждый вывод с точным входом, промптом, фрагментом документа и результатом инструмента, который его породил?
• Есть ли у правок рецензентов временные метки, имена авторов и ясный before/after diff?
• Логируют ли fallback‑маршруты, повторы, тайм‑ауты и ошибки инструментов, чтобы никто не принял их за нормальное поведение?
• Может ли новый член команды повторить трассу за десять минут и прийти к тому же выводу?

Если на любой из этих вопросов ответ «нет», ваш процесс приглашает к обвинениям. Люди будут указывать на финальную модель, потому что это последнее, что они могут увидеть, а не потому что она вызвала ошибку.

Одна привычка очень помогает: храните запрос как таймлайн, а не как кипу логов. Таймлайн делает причину и следствие очевидными. Вы увидите, что извлечение вернуло старый документ, маршрутизатор выбрал дешёвый fallback, или рецензент смягчил корректный ответ до расплывчатого.

Команды обычно учатся этому тяжёлым путём. Если трейс грязный, исправления идут медленно и дорого.

Что править следующим шагом

Не пытайтесь трассировать все ошибки сразу. Выберите один тип отказа, который больше всего мешает, и добавьте трассировку именно для этого пути на этой неделе. Хорошая стартовая точка — распространённая ошибка: извлечение подтягивает слабые документы, маршрутизатор выбирает неверный инструмент или рецензент правит черновик без объяснения.

Держите масштаб маленьким. Небольшое узкое исправление даёт более чистые доказательства и часто вскрывает соседние проблемы, которые вы не видели раньше.

Единый шаблон трассы полезнее ещё одного дашборда. Если каждая модель, инструмент и шаг ревью логируют разные поля, люди тратят время на ручное сопоставление событий и угадывание порядка. Используйте одинаковый минимум полей везде: request ID, временная метка, имя шага, использованная модель или инструмент и короткое резюме входа‑выхода.

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

Это меняет тон работы. Люди перестают спорить о том, какая модель «провалилась», и начинают чинить ту часть, которая действительно сломала ответ.

Если ваш стек охватывает несколько моделей, инструментов и ручных шагов, внешний взгляд может помочь. Oleg Sotnikov на oleg.is работает в роли Fractional CTO и консультирует стартапы, строящие AI‑ориентированные продукты; такого рода проблемы трассировки близки к его работе по AI‑first разработке и бережливым производственным системам.

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