Что делать, если нейросеть ошиблась

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

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

Что делать в первые пятнадцать минут

Два действия, оба без обсуждений.

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

Второе: зафиксировать состояние. Сохранить текст проблемного ответа, время, идентификатор модели и текущую версию инструкции — до того, как кто-то начнёт что-либо править. Через двадцать минут восстановить это будет нечем.

Всё остальное — расследование, переписка, объяснения — начинается после этих двух действий, а не вместо них.

Почему первым делом правят промпт и почему это худшее

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

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

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

Как оценить масштаб по журналу

Масштаб считается по журналу, а не по количеству жалоб. В личном кабинете KeyDealer видно расход по запросам и идентификатор модели, которой они ушли, — это даёт границы периода и объём. Тексты запросов и ответов хранит ваша сторона, и без них масштаб сводится к числу обращений.

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

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

Что ответить клиенту

Три пункта и ничего сверх того: что произошло, что уже сделано, что будет с его вопросом.

Чего в ответе быть не должно. Объяснений про то, как работают языковые модели: клиент не спрашивал. Перекладывания на поставщика или подрядчика: для клиента отвечает компания. И обещаний, которые вы не готовы выполнить прямо сейчас, — второе невыполненное обещание дороже первой ошибки.

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

Из-за чего это могло произойти

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

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

Когда виновата инструкция, а когда вход

Признак простой: воспроизводимость. Если на одном и том же входе ошибка повторяется в девяти прогонах из десяти — дело в инструкции. Если она появляется только на части записей — дело во входе.

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

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

Что происходит, когда сменилась модель

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

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

Отдельно проверьте, не стоит ли в боевом сценарии позиция в режиме проверки. В каталоге 55 позиций, 42 доступны, а две сейчас именно в проверке — gemini-3-6-flash и fable-5. «В проверке» означает, что мы не подтверждали её поведение, и в боевом канале ей не место.

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

Почему проверка на выходе важнее самой модели

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

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

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

Как починить, не сломав остальное

Одно изменение за раз, на копии, с замером после каждого.

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

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

Как проверить на выборке перед возвратом потока

На 50–100 примерах, в которые обязательно включены случаи, вызвавшие происшествие.

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

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

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

Какие ошибки делают в самом разборе

Пять повторяющихся.

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

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

Чего мы не утверждаем

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

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

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

Что нужно, чтобы попробовать

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог.

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

Прогон выборки — самая дешёвая часть починки. Пять текстовых позиций после первого пополнения не тарифицируются, а сотня примеров на дешёвой позиции вроде deepseek-v4-flash за 1 ₽ за миллион токенов стоит меньше рубля.

Что держать в голове

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

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

Ошибка, дошедшая до клиента, чаще говорит об отсутствии проверки на выходе, чем о плохой модели. Как мы проверяем факты и почему у каждой цифры стоит дата — на странице о проекте. Завести ключ и прогнать свою выборку: keydealer.ru/login.