Что делать, если ИИ вернул данные не по заданной структуре

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

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

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

Полезно разделить ошибки на три класса.

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

Что именно проверять до записи

Проверки удобно выполнять от технических к смысловым:

1. Можно ли разобрать ответ.
2. Получен ли объект ожидаемого типа.
3. Присутствуют ли обязательные поля.
4. Соответствуют ли значения нужным типам.
5. Соблюдены ли форматы дат, идентификаторов и других полей.
6. Не противоречат ли поля друг другу.
7. Выполнены ли правила конкретного процесса.

В актуальной документации n8n для узла Information Extractor описаны три способа задать желаемый формат: перечень атрибутов с описаниями, JSON-пример и JSON Schema. При генерации схемы из JSON-примера n8n считает обязательными все поля этого примера. Поэтому такой режим нельзя применять механически, если часть сведений действительно может отсутствовать.

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

Как остановить маршрут и не потерять диагностические сведения

Развилку нужно поставить перед внешним действием:

1. Маршрут получает ответ ИИ.
2. Отдельная проверка разбирает объект и применяет правила.
3. Корректный результат переходит к следующему этапу.
4. Некорректный результат попадает в контролируемую ветку ошибки без записи в целевую систему.

Документация n8n подтверждает, что узел Stop And Error может завершить выполнение с ошибкой, показать собственное сообщение и передать собственный объект ошибки в error workflow. Это средство остановки и передачи сведений об ошибке. Оно не доказывает автоматическое сохранение исходного письма, создание очереди для сотрудника или предотвращение дублей.

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

Какие данные сохранить в карточке ошибки

Карточка должна позволять восстановить контекст без догадок. В неё можно включить:

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

Как передать результат сотруднику

Сотруднику нужно показать рядом три элемента: исходный материал, ответ ИИ и конкретное нарушение. Сообщение «не прошла валидация» не помогает понять, какое решение допустимо.

В интерфейсе проверки можно разрешить ограниченный набор действий:

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

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

Как продолжить обработку после исправления

Возобновление — отдельная операция, а не продолжение с произвольного места. Перед записью система должна:

1. Получить актуальную карточку ошибки.
2. Проверить полномочия сотрудника.
3. Повторно применить действующую схему.
4. Проверить смысловые правила процесса.
5. По устойчивому идентификатору установить состояние внешнего действия.
6. Записать исправленный объект, только если прежняя запись не подтверждена.
7. Сохранить фактический результат операции.

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

Идемпотентность, подтверждение записи и механизм возобновления — требования будущей реализации. Их нельзя считать встроенной гарантией модели, n8n или CRM.

Учебный пример: пропущена валюта, сумма имеет неверный тип

Ниже — синтетическая демонстрация проектируемого маршрута. Это не клиентский кейс, не выполненный тест и не описание встроенной функции продукта.

Из входящего письма и вложенного документа ИИ должен подготовить объект с идентификатором обращения, названием компании, суммой и валютой. Модель возвращает сумму текстом «уточнить», а обязательную валюту пропускает.

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

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

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

Особенности структурированного ответа в агентном маршруте

Парсер итогового ответа не следует автоматически считать средством форматирования каждого промежуточного шага агента. Документация n8n указывает, что Structured Output Parser предназначен для итогового ответа, а не для промежуточных данных, передаваемых другим инструментам или этапам.

Для workflow с агентами n8n рекомендует направлять данные агента в отдельную LLM-chain и разбирать их там: документация описывает этот вариант как более стабильный, чем прямой разбор внутри агентного маршрута. Это рекомендация продукта, а не гарантия корректного формата и не обязательная архитектура для любого процесса.

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

Как проверить аварийный маршрут и определить ограничения

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

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

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

Что подготовить для обсуждения внедрения

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

Switch On AI разрабатывает ИИ-агентов и автоматизацию под конкретные операции: помогает описать границу остановки, карточку ошибки, ручное решение, повторную проверку и подтверждение внешней записи. Сначала команда разбирает процесс и готовит требования и предложение, затем показывает бесплатный прототип ключевого сценария. Прототип не равен внедрению; рабочие подключения, испытания и эксплуатацию согласуют отдельно.

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