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

Почему отчёты об ошибках ИИ путают команды

Большинство команд начинают с симптома. Бот дал неверный ответ, поэтому в отчёте пишут «галлюцинация» и на этом останавливаются. Это кажется аккуратным, но скрывает причину.

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

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

И обратное тоже случается. Команда видит короткие, расплывчатые или не по теме ответы и обвиняет инструмент. На деле ассистент мог потерять данные о пользователе, которые ему были нужны. Продуктовые команды пропускают пробелы в правилах по той же причине. Если ответ кажется запутанным, они могут винить отсутствие контекста, тогда как настоящая проблема — никто не сказал системе, что делать.

Полезная таксономия ошибок отделяет симптом от источника. Это звучит незначительно. Но меняет триаж.

Вместо вопроса «Был ли ответ плох?» спросите: «Какой слой сломался первым?»

Это изменение экономит время, потому что каждая метка указывает на другого владельца. Промпты и извлечение идут к одной команде. Проблемы с инструментами — к другой. Вопросы правил и соответствия — к владельцам продукта или политики. Чистое поведение модели остаётся в отдельной корзине.

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

Четыре метки, с которых стоит начать

Большинство отчётов начинается одинаково: «бот дал неправильный ответ». Эта единственная фраза может скрывать очень разные проблемы. Чистая таксономия отделяет ошибки модели от пробелов в данных, проблем с инструментами и проблем с правилами.

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

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

Сбой инструмента означает, что проблема находится на уровне действий. Ассистент мог вызвать неправильный инструмент, пропустить нужный вызов или получить плохой результат и продолжить. Представьте чат‑бота, который должен проверить биллинг перед ответом, но отвечает по памяти. Модель не обязательно выдумывает факты — она может работать с сломанным или отсутствующим результатом от инструмента.

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

Выбирайте одну основную метку, даже если в отчёте видно несколько проблем. Начинайте с того слоя, который сломался первым. Если бот пропустил поиск по аккаунту и потом догадался ответ, пометьте «сбой инструмента» как основной, а «галлюцинация» — как вторичный. Этот простой выбор помогает сначала правильной команде исправить главное.

Сопоставьте каждую метку с упавшим слоем

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

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

Если ответ кажется тонким, потому что модель не увидела уровень аккаунта, историю, текущую страницу или недавнее сообщение, отправьте отчёт тем, кто контролирует контекст. Это может быть слой памяти, пайплайн данных или UI, который собирает ввод. Часто исправление простое: передать ещё одно поле, сохранять краткое резюме сессии или открыть доступ к отсутствующей записи.

Сбой инструмента — это отдельная область. Когда ассистент выбрал правильное действие, но оно не выполнилось, завершилось по таймауту, попало на неправильный endpoint или вернуло устаревшие данные, проблема в интеграции. Такие отчёты отправляйте владельцам API, интеграций или workflow агентов. Если бот планирования ответил «Я забронировал», а вызов бронирования не сработал, путь инструмента сломался.

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

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

Что собирать в каждом отчёте

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

Начните с цели пользователя. Одного предложения достаточно: «пользователь хотел сводку по возвратам по трём письмам поддержки» или «пользователь попросил бота забронировать follow‑up звонок». Эта строка сразу говорит команде, каким было успешное поведение, прежде чем они начнут читать остальное.

Минимальный пакет для отчёта

Обычно отчёт достаточно силён для триажа, если он включает пять вещей:

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

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

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

Положите ожидаемый и фактический вывод рядом. Не пишите «плохой ответ» или «неверный результат». Опишите, что система должна была сделать, и что она сделала вместо этого. Короткие сравнения экономят время.

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

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

Как помечать проблему

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

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

Простой рабочий поток проверки хорошо работает:

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

Этот порядок важен. Если модель никогда не получила политику доставки, помечайте «отсутствие контекста», даже если итоговый ответ кажется выдуманным. Если lookup в support вернул ошибку, помечайте «сбой инструмента» прежде, чем обсуждать формулировку.

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

Метка «галлюцинация» используется только когда ассистент имел всё необходимое, ни один инструмент не сломался, никакое правило не исказило вывод, и модель всё равно выдумала детали. Это даёт команде модели реальную проблему для исправления.

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

Простой пример для чат‑бота

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

Предположим, клиент просит поддержку перенести дату доставки и сменить адрес. Бот отвечает: «Ваш заказ уже отправлен, поэтому я не могу изменить его.» Человеческий агент проверяет систему заказов и видит, что посылка всё ещё на упаковке.

Это выглядит как одна ошибка, но исправление зависит от того, что произошло за кулисами.

Если бот вообще не сделал lookup заказа, пометьте «сбой инструмента». Возможно, вызов API заказа завершился ошибкой, таймаутом или бот пропустил шаг lookup. Команда должна исправлять путь инструмента, а не переписывать текст ответа.

Если бот запросил систему заказа, но получил устаревшие данные или пропустил последнее обновление статуса, пометьте «отсутствие контекста». Модель ответила, опираясь на неполные факты.

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

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

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

Клиент видит только неправильный ответ. Команда должна увидеть, какой слой сломался первым, иначе она потратит день на исправление не той причины.

Когда одному инциденту нужны две метки

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

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

Выбирайте первый разрыв

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

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

Несколько часто встречающихся пар:

• отсутствие контекста + галлюцинация: модель не имела данных аккаунта и потом догадала
• сбой инструмента + галлюцинация: инструмент завис, затем модель заполнила пробел выдуманным ответом
• нарушение политики + сбой инструмента: ассистент попытался действие, которого не должен был пытаться

Пример поддержки проясняет это. Бот пытается проверить заказ, но lookup возвращает пусто из‑за ошибки инструмента. Затем бот отвечает: «Ваша посылка придёт завтра.» Первичный тег: сбой инструмента. Вторичный тег: галлюцинация.

Если двум командам нужны отдельные исправления, разделите тикеты. Один тикет может покрывать сломанный lookup. Другой — поведение ассистента при отсутствии данных. Свяжите их, но не заставляйте одну команду ждать очереди другой.

Добавьте короткую заметку, объясняющую, почему обе метки присутствуют. Например: «Primary tag — сбой инструмента, потому что CRM lookup вернул пусто. Secondary — галлюцинация, потому что ассистент всё равно ответил с фейковым статусом заказа.»

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

Ошибки, которые тратят время на триаж

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

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

Другой источник потерь — чтение только видимой переписки. Видимый ответ — лишь часть истории. Логи инструментов, трассы извлечения, версия промпта и события политики часто показывают, что действительно произошло. Бот, который говорит «Не могу найти ваш заказ», может выглядеть запутанным, но реальная проблема — таймаут в lookup по заказу.

Рецензенты также теряют время, когда в отчёте нет ожидаемого результата. «Ответ плохой» заставляет кого‑то догадываться, каким должен быть хороший ответ. Короткое предложение помогает: что ассистент должен был сделать, какой источник использовать или какое действие выполнить.

Несколько привычек быстро создают хаос:

• смешивать жалобы на политику с багами продукта в одном тикете
• давать расплывчатые метки вроде «плохой ответ» или «неверный отклик»
• создавать отчёт без логов, версии промпта или вывода инструмента
• описывать только, что произошло, а не что должно было произойти

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

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

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

Быстрые проверки для чистого отчёта

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

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

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

Малые детали важнее, чем многие думают. «Пользователь попросил краткое содержание» часто недостаточно. «Пользователь попросил: ‘Прочитай эту ветку поддержки и составь вежливый ответ по возврату’» даёт рецензенту что‑то, что он реально может протестировать.

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

Небольшой пример показывает разницу. «Бот придумал число» — это расплывчато. «GPT-4.1 с отключённым инструментом таблиц, промпт ниже, вернул итог дохода, не совпадающий с приложенной таблицей. Ожидаемый вывод: просуммировать только перечисленные значения» — это тикет, с которым можно сразу работать.

Следующие шаги для вашей команды

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

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

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

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

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

Здесь многие команды теряют время. Они сначала правят промпты, потому что это кажется быстрым. Часто настоящая проблема — в другом месте.

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

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