Структурированные выводы LLM: Output Parser

Node Output Parser в n8n принудительно приводит ответы LLM к структурированному JSON вместо того, чтобы полагаться на свободный текст: он задаёт схему, которой должна следовать языковая модель, а Basic LLM Chain или ИИ-агент затем возвращают результат именно в этом формате. Для компаний, которые хотят автоматически передавать ответы LLM в CRM, ERP или базы данных, это разница между надёжно обрабатываемыми полями и трудоёмкой ручной доработкой текстовых ответов. По состоянию на: июль 2026.

Почему обычный свободный текст не подходит для автоматизаций

Без дополнительных указаний языковая модель выдаёт ответы на естественном языке. Для чат-интерфейса это желательно, но для шага рабочего процесса, который должен передать ответ в следующую систему, это проблема. Без фиксированной структуры приходится работать с текстовыми шаблонами, регулярными выражениями или дополнительными промежуточными шагами, чтобы извлечь отдельные значения, и любое небольшое изменение формулировки модели может нарушить это извлечение. Именно здесь и работает node Output Parser: он задаёт модели схему и обеспечивает, чтобы ответ возвращался в виде валидного JSON с чётко именованными полями, готовыми к дальнейшей обработке в следующих node.

Structured Output Parser: принудительная JSON-схема

Согласно документации n8n по Structured Output Parser, node возвращает поля на основе JSON-схемы и соответствующим образом структурирует вывод LLM. Для определения схемы доступны два способа:

• Generate from JSON Example: Вы вводите пример JSON, и node автоматически выводит из него схему. При этом используются только типы и имена свойств объекта, а фактические значения в примере не имеют значения. В этом режиме все поля считаются обязательными.
• Define using JSON Schema: Вы создаёте схему вручную. В документации отдельно отмечается, что ссылки через `$ref` в этой схеме не поддерживаются.

Важно для практического использования: sub-node, такие как этот Output Parser, обрабатывают выражения иначе, чем обычные node. При нескольких входных items, согласно документации, выражение всегда разрешается только для первого item, а не для каждого item по отдельности. Это может приводить к неожиданным результатам при пакетной обработке нескольких записей и должно быть протестировано заранее.

Подключение к Basic LLM Chain или ИИ-агенту

Чтобы Output Parser вообще заработал, в соответствующем корневом node, например в Basic LLM Chain, нужно включить опцию "Require Specific Output Format". Только после этого появляется точка подключения, к которой можно присоединить Structured Output Parser, Item List Output Parser или Auto-fixing Output Parser. Для ИИ-агентов документация делает открытую оговорку: структурированный парсинг вывода у агентов часто ненадёжен. В качестве альтернативы рекомендуется использовать отдельную LLM Chain, которая принимает необработанные данные от агента и лишь затем приводит их к целевому формату. Для промежуточных шагов внутри рабочего процесса агента документация в любом случае не рекомендует использовать parser, а вместо этого советует описывать нужное форматирование прямо в System Message. Тем, кто планирует такие рабочие процессы с агентами, стоит подробнее ознакомиться с разделом ИИ-агенты.

Обработка ошибок: если LLM не возвращает валидный JSON

Ни одна языковая модель не соблюдает заданную схему со стопроцентной гарантией; особенно при более сложных структурах или длинных ответах может случиться, что поле отсутствует, кавычка стоит неправильно или вокруг JSON есть лишний текст. Именно для этого случая, согласно документации n8n по Auto-fixing Output Parser, существует отдельное решение: node действует как обёртка вокруг существующего Output Parser. Если первая попытка парсинга не удаётся, n8n автоматически вызывает дополнительную LLM, которая исправляет некорректный вывод и снова приводит его к нужному формату. Это заметно повышает надёжность, но не заменяет обработку ошибок в самом рабочем процессе. Тем, кто хочет действовать наверняка, всё же стоит добавить проверку после parser, например путь error-trigger или условие, которое срабатывает, если и попытка исправления не удалась. Автоматизация, которая молча продолжает работать с пустыми или неверными полями, наносит больше вреда, чем аккуратно зафиксированный случай ошибки.

Часто задаваемые вопросы о структурированных выводах LLM в n8n

В чём разница между Structured Output Parser и Auto-fixing Output Parser?

Structured Output Parser задаёт целевую схему и проверяет по ней ответ. Auto-fixing Output Parser добавляется поверх как дополнительный уровень защиты: он использует другой parser, например Structured Output Parser, и при неудачной попытке парсинга вызывает дополнительную LLM, чтобы исправить вывод.

Могу ли я парсить несколько items структурированно одновременно?

Технически да, на практике с ограничением. Поскольку sub-node, такие как Output Parser, разрешают выражения только для первого входного item, при нескольких записях стоит тщательно проверить, выглядит ли результат для каждого item так, как ожидается, а не слепо полагаться на пакетную обработку.

Гарантирует ли Output Parser стопроцентно валидный JSON?

Нет. Он значительно повышает вероятность структурированного, валидного ответа, а Auto-fixing Parser дополнительно перехватывает многие ошибки, но ни одна языковая модель не даёт стопроцентной гарантии. Поэтому чистый путь обработки ошибок в рабочем процессе по-прежнему имеет смысл.

Работает ли Output Parser надёжно и с ИИ-агентами?

Согласно документации n8n, менее надёжно, чем с простой LLM Chain. Для рабочих процессов с агентами рекомендуется либо управлять форматированием через System Message, либо передавать необработанный ответ в отдельную, последующую LLM Chain с Output Parser.