Что я делаю, если AI-помощник начинает ошибаться
Как ограничить последствия, сохранить пример ошибки, найти причину и проверить исправление. Разбираю порядок действий на условном сценарии помощника для ответов клиентам.
Сообщение «помощник стал ошибаться» для меня — повод сначала уточнить, что произошло. Он неправильно понял вопрос, взял старый документ, не получил ответ от системы или выполнил действие, которого не должен был выполнять? Внешне эти ситуации могут выглядеть одинаково: сотрудник больше не доверяет результату.
Я предлагаю разбирать такие случаи в определённом порядке: ограничить последствия, сохранить пример, проверить причину и только затем возвращать сценарий в работу. Это продолжение разговора о том, что нужно проверить между прототипом и рабочей системой.
Ниже — учебный пример помощника, который готовит черновики ответов на вопросы о товарах. Письма отправляет менеджер. Описанный сбой и его обстоятельства вымышлены; это способ показать порядок действий, а не клиентский кейс.
Сначала выясняю, что уже затронуто
Представим: менеджер заметил, что помощник подставил устаревший срок поставки. Прежде чем менять инструкцию модели, я хочу получить ответы на несколько вопросов. Это один черновик или похожие ответы повторялись? Менеджеры уже использовали их в письмах? Какие товары и источники могли быть затронуты?
До выяснения причины проблемный сценарий можно временно передать человеку: сотрудник сам проверяет срок в утверждённом источнике. Если границы сбоя пока неизвестны, ограничение придётся выбрать шире. Конкретный объём остановки зависит от возможных последствий и доступного запасного порядка работы.
При этом нужно назвать того, кто принимает решение, и сообщить команде, как работать дальше. Запись «разработчик смотрит» не помогает менеджеру понять, можно ли использовать следующий черновик.
Такой порядок согласуется с принципами управления инцидентами Google SRE: сначала ограничить ущерб и восстановить работу, сохранив сведения для последующего разбора причины. Для небольшого процесса это может быть короткая договорённость, без большого аварийного штаба.
Сохраняю конкретный пример до изменений
Мне нужен исходный запрос, фактический ответ и объяснение, в чём именно ошибка. Фраза «текст какой-то странный» оставляет слишком много места для разных трактовок.
В нашем примере стоит зафиксировать товар, указанный помощником срок, правильное условие и документ, который подтверждает правильный ответ. Отдельно — время запроса и версии инструкции, источника и решения, если они известны.
Важно сохранить сведения, доступные помощнику в тот момент. Актуальная страница каталога сегодня может отличаться от того, что система получила вчера. По нынешнему состоянию не всегда получится восстановить прошлое поведение.
В рабочий журнал включаю только необходимое и разрешённое для такого разбора. Лишние персональные данные и закрытые условия убираю. Если создаю обезличенную копию, проверяю, что она всё ещё воспроизводит существенную часть проблемы.
Прохожу путь от источника до результата
Я не считаю смену модели первым обязательным исправлением. Сначала полезно увидеть цепочку: какие данные получили, что нашли, что передали модели и что показали сотруднику.
| Наблюдение | Что проверяю первым |
|---|---|
| Старое условие есть в самом источнике | Кто обновляет документ и какая версия считается действующей |
| Источник верный, но найден другой товар | Как выбрали документ и распознали товар |
| Нужный фрагмент найден, а в ответе другое условие | Что попало в контекст и какие инструкции действовали |
| Источник не ответил, но черновик выглядит уверенно | Как система обрабатывает недоступность и отсутствие данных |
| Правильный черновик связан с чужим обращением | Как сопоставлены запрос, результат и карточка в рабочем интерфейсе |
| Ответ корректен, но сотрудник ожидал другое | Совпадают ли правила оценки и договорённости о задаче |
Это направления проверки, а не готовые диагнозы. Например, устаревший срок может прийти из старой копии каталога, из неверно найденного документа или появиться уже при подготовке текста. Исправления в этих случаях будут разными.
Я также смотрю, что менялось перед появлением ошибки: документы, доступы, настройки, интерфейс или состав входящих задач. Совпадение по времени помогает выбрать гипотезу, но само по себе её не доказывает.
Отделяю временную меру от исправления
Передать ответы менеджеру вручную — способ продолжить работу. Исключить сомнительный источник — возможное временное ограничение. Но ни одно из этих действий ещё не объясняет, почему появилась ошибка.
Поэтому в карточке разбора нужны две отдельные строки: что сейчас сдерживает последствия и что устраняет проверенную причину. Для временной меры назначаю ответственного и момент пересмотра. Иначе она незаметно превращается в постоянный процесс, о котором знают только несколько человек.
Если рассматриваем откат, проверяю, что именно он восстановит: инструкцию, модель, справочник или весь набор настроек. Возврат прежней версии программы сам по себе не отменяет уже отправленные письма и не исправляет записи, изменённые в другой системе.
Такие последствия разбираются отдельно с владельцем процесса. В учебном сценарии менеджеру может понадобиться проверить уже использованные черновики. Нельзя считать эту работу завершённой только потому, что новый тестовый ответ стал правильным.
Проверяю исправление на нескольких уровнях
Первый уровень — исходный пример ошибки. Второй — похожие ситуации с другой формулировкой или соседним товаром. Третий — прежние рабочие сценарии, которые изменение могло задеть.
Например, запрет использовать любой срок поставки может убрать неверное обещание, но одновременно сделать бесполезными ответы, для которых точный срок есть в разрешённом источнике. Мне нужно увидеть обе стороны изменения.
Подтверждённый пример добавляю в контрольную выборку. Anthropic в руководстве по оценке AI-агентов рекомендует превращать найденные пользователями ошибки в проверочные задачи и отдельно следить, не ухудшились ли прежние возможности после исправлений.
Перед прогоном фиксирую версию решения и ожидаемое поведение. Сохраняю все попытки: один удачный ответ после нескольких неверных не даёт основания объявить проблему устранённой. Число повторов и критерии результата согласовываются заранее для конкретного риска.
Если помощник выполняет действия через инструменты, проверяю фактическое состояние рабочей системы. Сообщение «готово» ещё не подтверждает, что правильная операция действительно произошла.
Возвращаю сценарий в работу с понятными условиями
После проверки я предлагаю ограниченный возврат: заранее выбранный участок процесса, ответственный наблюдатель и критерий повторной остановки. Объём такого этапа зависит от задачи; универсальная доля обращений здесь не поможет.
Смотрю на те признаки, которые связаны с обнаруженной ошибкой: неверные условия, расхождения с источником, долю исправляемых черновиков, передачи человеку и время проверки. Средняя оценка текста может остаться хорошей и при этом скрывать проблему с одним важным полем.
Команде нужно сообщить, какая версия снова доступна, какое ограничение снято и что остаётся под наблюдением. Для критических случаев заранее определяю, кто вправе приостановить сценарий, — это часть границ полномочий AI-агента.
Заканчиваю разбор короткой записью
Я хочу, чтобы после исправления остался документ, который сможет понять человек, не участвовавший в обсуждении:
- что наблюдали и какие результаты могли быть затронуты;
- какое временное ограничение применили;
- какая причина подтверждена и чем;
- что изменили, кто проверил и на какой версии;
- какие задачи добавили в контрольную выборку;
- что ещё нужно исправить в последствиях сбоя;
- кто и на каких условиях разрешил возврат в работу.
Если причину пока не удалось подтвердить, так и записываю. «Не повторилось» и «нашли причину» — разные результаты расследования.
Для меня хороший разбор заканчивается понятным изменением рабочего процесса: команда знает, как распознать повторение, кто принимает решение и как продолжить работу при ограничении помощника. Именно это делает систему управляемой после первой удачной демонстрации.
Учебный протокол проверки перед возвратом помощника
Это дополнительное учебное упражнение с вымышленными карточками товаров A и B. Оно не описывает реальный инцидент или опыт автора. Карточка A2 утверждена вместо A1; карточка B1 остаётся действующей. Помощник готовит только черновики, отправку выполняет человек.
Сохраните условия проверки до изменения
Запишите ID теста, текст запроса, разрешённую версию карточки, ожидаемый результат и версию проверяемого решения. Для каждой попытки сохраните фактический черновик и итог проверки. Удаляйте лишние персональные данные; обезличивание не должно скрывать саму ошибку.
Принимайте решение по всем сохранённым попыткам
Заполните таблицу по фактическим результатам, а не по последнему удачному ответу. Количество повторов и допустимые исходы определите до прогона. Неизвестный источник и работающий соседний сценарий проверяются отдельно: общий отказ на любой вопрос не считается исправлением.
| Проверочный вход | Ожидаемое поведение | Основание для решения |
|---|---|---|
| Исходный запрос о товаре A; в поиске осталась A1 | Не выдавать условие A1 как действующее. Сверить ответ с утверждённой A2 или передать вопрос человеку. | Сохранены использованный фрагмент и сравнение с A2. |
| Другой запрос о товаре B; доступна действующая B1 | Подготовить полезный черновик по B1 без подстановки сведений о A. | Соседний рабочий сценарий сохранил смысл и правильный источник. |
| Запрос о A; источник не ответил | Явно показать отсутствие подтверждённых данных и передать проверку менеджеру. | Нет уверенного ответа, составленного из устаревшей карточки. |
| Два обращения R1 и R2 проходят одновременно | Каждый черновик связан со своим обращением и его исходными данными. | Проверены пары request ID → draft ID, а не только тексты. |
| Старая ошибка повторилась при ограниченном возврате | Остановить затронутый сценарий по согласованному правилу и вернуть ручной порядок. | Сохранены пример повторения, версия и решение ответственного. |
К записи о возврате приложите результаты всех попыток, оставшиеся ограничения и имя ответственного за наблюдение. Проверка черновиков не закрывает отдельно выявленные последствия ранее использованных ответов.