Когда ИИ-агент в n8n выдает неверные данные счета без сообщения об ошибке

Самая дорогая ошибка при извлечении данных счетов с помощью ИИ-агента в n8n — та, при которой ничего не становится красным. Workflow проходит до конца, JSON валиден, каждое обязательное поле заполнено. Только в поле суммы указана сумма нетто вместо суммы брутто, или номер счета, которого нет нигде на документе. Сообщения об ошибке при этом не возникает: ошибка содержательная, а не техническая.

Почему n8n не сообщает об ошибке, если значение неверно по содержанию?

n8n проверяет форму ответа, а не его правильность. Structured Output Parser принудительно задает JSON-схему, то есть имена полей, типы данных и обязательные поля. Соответствует ли сумма тому, что указано на счете, он знать не может. Документация n8n описывает этот узел именно так: он предоставляет поля „based on a JSON Schema“.

Auto-fixing Output Parser не закрывает этот пробел. Согласно документации, он вызывает вторую языковую модель, если первая не справляется. Это исправляет сломанный JSON, а не неверные числа. Аккуратно отформатированный, но содержательно неверный набор данных считается успехом для обоих узлов.

Как часто ИИ-агент выдает содержательно неверные поля счета?

Хорошие модели показывают ошибку на уровне документа около одного процента, и этот один процент не заявляет о себе сам. В магистерской диссертации в Technische Hochschule Brandenburg Florian Pruß (18 сентября 2025, научный руководитель Prof. Dr. Emanuel Kitzelmann) проверил LLM-извлечения на независимом слепом наборе данных из 10 000 реально обработанных счетов компании aifinyo AG (TH Brandenburg, Masterarbeit). Измерялась Document Accuracy: документ считается корректным только тогда, когда номер счета, дата счета и сумма совпадают полностью.

• Claude 3 Sonnet, Few-Shot с Chain-of-Thought: 99,36 процента Document Accuracy, лучший измеренный показатель.
• GPT-4.1, Few-Shot: 99,02 процента.
• Gemma 3 27B-IT, Few-Shot: 97,61 процента, интересный вариант как открытая модель для сценариев с повышенными требованиями к защите данных.
• Gemma 3 1B-IT: 24,97 процента. Небольшие локальные модели для этой задачи не являются бюджетным вариантом, а просто непригодны.
• Для сравнения, используемая в продакшене OCR-система: 87,24 процента.

99,36 процента звучат как решенная задача. На 10 000 счетов это около 64 документов с как минимум одним неверным ключевым полем, которые проходят совершенно незаметно. Качество исходного текста при этом весит почти так же много, как и выбор модели: та же стратегия с той же моделью достигла 99,77 процента Overall Accuracy через чистый текстовый слой PDF и лишь 97,87 процента через цепочку Tesseract-OCR.

По каким признакам распознать неверные данные счета от ИИ-агента?

По противоречиям с данными, которые у вас уже есть. Отдельное поле нельзя проверить на правильность, а полный набор полей — можно, потому что поля счета связаны друг с другом арифметически и по существу. Шесть перекрестных проверок должны присутствовать в каждом workflow обработки счетов:

• Проверка расчета: Сумма позиций плюс указанный НДС должна давать сумму брутто. Выявляет путаницу нетто и брутто, а также потерянные строки позиций.
• Проверка налога: указанная сумма НДС сверяется с суммой нетто, умноженной на налоговую ставку. Если не получается ни одна из стандартных ставок, документ подлежит проверке.
• Сверка мастер-данных: название поставщика, идентификационный номер НДС и IBAN сверяются с базой кредиторов. Измененный IBAN у известного поставщика всегда подлежит проверке.
• Проверка на дубликаты: номер счета, кредитор и сумма сверяются с уже проведенными документами.
• Правдоподобие дат: дата счета не в будущем и не вне открытого периода учета, срок оплаты равен дате счета плюс срок платежа.
• Сверка с заказом: сумма и количество сверяются с заказом и поступлением товара с заданным допуском.

Эти проверки не изобретение эпохи ИИ, они прописаны в тексте закона, вышедшем задолго до нее. GoBD в абзаце 100 прямо называют „контроль ввода (указания на ошибки, проверки на правдоподобие)“, „контроль сверки при вводе данных“ и „контроль обработки“ частью системы внутреннего контроля, а абзац 40 требует „содержательных проверок на правдоподобие“ (циркуляр BMF от 28 ноября 2019 года). Тот, кто при переходе на ИИ-агента рационализирует этот шаг проверки, устраняет контроль, который раньше существовал.

Какие пороговые значения должны быть в слое валидации?

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

• Зеленый: все расчетные проверки сходятся, кредитор и IBAN известны, дубликатов нет, сумма ниже вашего лимита утверждения. Проходит автоматически дальше.
• Желтый: одно отдельное мягкое отклонение, например новый кредитор или превышенный допуск по заказу. Попадает в список проверки, человек подтверждает или исправляет.
• Красный: расчетная проверка не сходится, IBAN отличается, подозрение на дубликат или пустое обязательное поле. Никогда не проводится автоматически.

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

С какой суммы утверждение должен давать человек?

Установленного законом лимита в евро не существует. GoBD предписывают контроль и разделение функций, а их конкретное оформление, согласно абзацу 100, прямо зависит от сложности хозяйственной деятельности и организационной структуры. Границу вы устанавливаете сами, и правильной отправной точкой служит уже существующий у вас регламент подписей: если в компании начиная с 5.000 евро подписывает руководство, то агенту выше этой границы нечего решать в одиночку.

Пример из собственной бухгалтерии, который не решить промптом: два заказчика NordFlux рассчитываются по процедуре самовыставления счетов (Gutschriftsverfahren) согласно § 14 Abs. 2 UStG, то есть клиент сам выставляет счет за нас. На документе указано „Gutschrift“, NordFlux является выставителем счета, а отправитель — получателем услуги. Извлечение, которое отображает это слово по его обычному коммерческому значению, превращает его в корректировку счета с отрицательным знаком и переводит реальную выручку в минус. Документ прочитан корректно, каждое поле верно, но смысл перевернут. Против этого помогает правило в слое валидации: если в поле выставителя счета указан собственный идентификационный номер НДС, это исходящий счет, независимо от того, что написано в заголовке.

Как построить слой валидации в n8n?

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

• Инкапсулировать извлечение: отдельный суб-workflow, возврат данных строго через Structured Output Parser, никаких полей свободного текста.
• Проверять в Code-Node, а не в LLM: расчетные проверки — это арифметика. Языковая модель, которая пересчитывает, добавляет второй источник ошибок.
• Сохранять результат проверки: пройденные и нарушенные правила в виде отдельного поля в наборе данных. Без этого списка позже нельзя будет сказать, какое правило и как часто срабатывает.
• Switch-Node по светофору: три пути: зеленый — в систему бухгалтерского учета, желтый — в список проверки, красный — в workflow ошибок с уведомлением.
• Вести протокол в отдельной таблице: входящий документ, извлеченные значения, результат проверки, решение и лицо, принявшее решение. У executions в n8n ограниченный срок хранения, и они не заменяют протокол проверки.

Абзац 100 GoBD требует, чтобы контроли не только были внедрены и выполнялись, но и протоколировались, а согласно абзацу 102 описание системы контроля должно входить в документацию процедур. Таким образом, слой валидации без протокола выполняет лишь половину своей задачи. Как выглядит весь процесс в целом, мы показываем в разделе Автоматизация обработки входящих счетов и в разделе Автоматизация бухгалтерии.

Часто задаваемые вопросы

Может ли вторая языковая модель взять на себя проверку?

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

Разве более качественная модель не решает проблему галлюцинаций?

Она измеримо помогает, но не решает проблему. Даже лучший показатель в 99,36 процента оставляет на 10 000 документах около 64 ошибочных, а качество исходного текста весит почти так же много, как и выбор модели.

Чем это отличается от ошибки в Output Parser?

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

Решится ли это само собой с введением электронного счета?

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

Насколько трудоемко добавить слой валидации задним числом?

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