Вопрос «куда в воркфлоу поставить LLM модель» почти всегда задают с неправильного конца: сначала человек видит демо агента, потом ищет у себя задачу, в которую этот агент поместится. Результат предсказуем — автоматизация, которая иногда работает не так, как вчера, и счёт за токены там, где хватило бы условия в ноде.
Эта инструкция про обратный порядок. Сначала описать работу, потом найти в ней места, где модель даёт то, чего детерминированная логика не даёт вообще, и только потом обвязать эти места проверками. На выходе — воркфлоу, в котором вы знаете, какой шаг может соврать, что произойдёт дальше и кто это заметит раньше пользователя.
Основа — пост Luca_Tomasino в разделе Tips & Tricks на форуме n8n Community: он разбирает паттерны, к которым возвращается сам, и прямо говорит, что в половине случаев агент в середине автоматизации не нужен. Шаги ниже я расставил в том порядке, в котором работу приходится делать на практике; названия настроек привожу так, как они называются в n8n.
Что понадобится
- Описание воркфлоу до сборки: что приходит на вход, какие решения принимаются, что происходит на выходе — письмо, запись в базу, вызов внешнего сервиса.
- Доступ к n8n и ключ к провайдеру модели. Оплата у LLM-провайдеров идёт по токенам, и лишние вызовы видны в счёте; актуальные цены смотрите на странице тарифов провайдера — в материале форума их нет, и придумывать я их не буду.
- Тестовая выборка реальных входов — не три примера, придуманных руками, а нормальные обращения, письма или заявки, включая кривые.
- Разметка «правильных» ответов хотя бы для части выборки: без неё нечего считать на этапе проверки.
- Место, куда складываются входы и выходы модели: лог исполнений, таблица, база — что угодно, что можно потом пересмотреть глазами.
- Живой человек, который согласует рискованные действия, и понимание, что именно считается рискованным.
Отдельный пункт про данные. Как только текст уходит в облачный API, он покидает ваш контур. Обращения клиентов, персональные данные, внутренние документы — это решение, которое принимается до сборки воркфлоу, а не после первого инцидента. Luca_Tomasino приводит поиск PII как один из сильных сценариев модели, и здесь есть очевидная петля: чтобы модель нашла персональные данные, их сначала надо ей отдать. Это не аргумент против сценария, это причина заранее решить, какой модели и где вы это отдаёте.
Шаг 1. Описать работу и проверить, нужна ли здесь LLM модель
Разложите воркфлоу на шаги и напротив каждого напишите, откуда берётся решение. Если решение выводится из полей, справочника или регулярного условия — это детерминированная нода, и ей место в воркфлоу без вариантов. LLM модель имеет смысл там, где на входе неструктурированный текст, а на выходе нужно значение, которого в тексте прямо не написано.
Паттерны, которые в посте названы рабочими:
| Задача | Что делает модель | Детерминированная альтернатива |
|---|---|---|
| Классификация интента и маршрутизация | читает обращение и определяет область: техника, UX, аутентификация, биллинг | ключевые слова — ломаются на формулировках, которых вы не предусмотрели |
| Извлечение структурированных данных | из текста возвращает чистый JSON | регулярки: работают, но их надо угадывать заранее и латать каждые пару дней |
| Поиск по своему корпусу | в паре с RAG находит похожие прошлые случаи — например, тикеты из истории | полнотекстовый поиск, если запросы формулируются одинаково |
| Проверки политик и комплаенса | находит в тексте персональные данные, классифицирует или маскирует их по правилам | списки шаблонов — для форматных данных работают, для свободного текста нет |
| Генерация артефактов | документы, саммари, код для дальнейших шагов или для команды | шаблон, если вариативность низкая |
Критерий простой: если задачу закрывает детерминированная логика, она сделает это быстрее, дешевле и одинаково каждый раз. Каждая модель в воркфлоу добавляет вероятность сбоя, которой у обычной ноды нет. Автор поста оценивает, что примерно в половине случаев так и есть — агент не нужен. Проверка на этом шаге стоит полчаса, а экономит месяцы обслуживания нестабильного узла.
Как понять, что шаг пройден: у вас есть список мест, где стоит модель, и для каждого — фраза «детерминированно это не решается, потому что…». Если фраза не пишется, ноду надо убрать.
Шаг 2. Заставить модель отвечать заданной схемой
Свободный текст на выходе модели — это то, что потом разбирает следующая нода, и разбирает она его до первого неожиданного оформления. Поэтому первое, что включается в любом операционном сценарии, — жёсткая форма ответа.
В n8n это делается в ноде AI Agent: включите Require Specific Output Format. Появится подключение для сабноды, где выбирается structured output parser и задаётся JSON-схема — после этого агент обязан отвечать в указанной форме. Там же есть авто-исправление: если ответ схеме не соответствует, к модели уходит второй промпт с просьбой исправиться.
Авто-исправление работает, но стоит дополнительного вызова — это и токены, и задержка. Включайте его там, где оно окупается: на редких, но критичных шагах. На горячем шаге, который выполняется тысячи раз в сутки, второй вызов на каждом сбое заметен в счёте.
Второй вариант — валидировать схему самому в Code-ноде. Так делают, когда проверок больше, чем описывает JSON-схема: диапазоны, справочники, взаимная согласованность полей.
И про температуру: для операционных задач держите её в районе 0–0.3, максимум 0.4. Вам нужен заземлённый ответ, а не изобретательный.
Как понять, что шаг пройден: прогон тестовой выборки не даёт ни одного ответа, который следующая нода не может распарсить.
Шаг 3. Поставить проверку между шагами и человека на рискованные действия
Галлюцинации не убираются настройками. Новые модели ошибаются реже, но «реже» — не «никогда», и это свойство той же архитектуры, которая делает модель полезной. Арифметика простая: при вероятности 0,1% на один запуск и продакшен-объёме в тысячи исполнений сбой перестаёт быть возможностью и становится расписанием. Задача не в том, чтобы его исключить, а в том, чтобы поймать до пользователя.
Поэтому между шагами ставится проверка, а не прямая передача результата дальше:
- Валидация схемы — прошёл ответ формат или нет.
- Порог уверенности, если модель возвращает оценку: ниже порога — не продолжаем, а уводим в отдельную ветку.
- Решение о продолжении как отдельный узел. Именно здесь перехватывается сбой — до вызова инструмента, до отправки письма, до записи в базу.
- Ветка «не прошло»: в очередь на человека, а не в тишину.
Рискованные действия уходят на согласование человеку без исключений. Farhan95 в ответе на тот же пост добавляет важное: человеческая проверка обязательна на всём, что касается комплаенса и денег. Он же называет типичный краевой случай — ответ выглядит валидным JSON, а downstream-логику ломает. Схема проверяет форму, а не смысл, и это разные проверки.
В нашем конвейере тот же принцип: финальное решение о публикации принимает человек кнопкой, машина только готовит вариант. Это не недоверие к моделям, это разделение: обратимые шаги отдаём автоматике, необратимые — нет.
Как понять, что шаг пройден: для каждого действия в воркфлоу вы можете сказать, обратимо оно или нет, и у всех необратимых есть либо валидация с порогом, либо человек.
Шаг 4. Маршрутизировать до генерации, а не после
Частая схема — один большой агент с широким набором инструментов на все входящие запросы. Она дорогая и плохо предсказуемая: самая мощная модель обрабатывает и сложный разбор, и запрос, который решается одним справочником.
Правильный порядок обратный: сначала оценить запрос дешёвым шагом классификации, потом динамически выбрать, какая модель его возьмёт, какой агент и какие права этому агенту выдаются. Не каждый запрос заслуживает самой дорогой модели и самого широкого набора инструментов.
Практически это выглядит так:
- Первый узел — только классификация: категория, приоритет, признак «нужен человек».
- Ветвление по категории.
- В каждой ветке — своя модель и свой набор инструментов. Где-то это вообще не модель, а детерминированная ветка из шага 1.
- Права выдаются по ветке: доступ на запись есть только там, где он нужен.
Farhan95 отмечает, что паттерн маршрутизации интентов встречается у клиентов постоянно — когда нужно сортировать входящий поток, не расширяя команду. Это и самая понятная точка входа для LLM: ошибка в классификации ловится следующим шагом, а не уходит клиенту письмом.
Как понять, что шаг пройден: в логах видно, какая ветка и какая модель обработали каждый запрос, и запросы простых категорий не попадают к дорогой модели.
Как проверить результат
Считать надо на реальной выборке, а не на демонстрационных примерах. Минимальный набор метрик:
- Доля ответов, прошедших схему с первого раза. Считается на 100–200 реальных входах. Всё, что ушло в авто-исправление, — это ваша будущая строка в счёте и задержка ответа.
- Точность классификации на размеченной части выборки: сколько обращений попало в правильную ветку. Сравнивать нужно не с идеалом, а с тем, как сортировал человек или старая логика.
- Доля запросов, ушедших на человека. Если она близка к нулю, порог, скорее всего, слишком мягкий. Если близка к половине — автоматизация не экономит время.
- Цена одного прохода. Токены на вход и выход по логу провайдера, отдельно — расход на повторные вызовы авто-исправления.
- Инциденты на объёме. Прогон 1000 исполнений покажет то, чего не показывает прогон десяти: 0,1% на тысяче — это уже один случай.
Ориентир, дошли вы или нет: воркфлоу считается готовым к продакшену, когда для каждого из этих чисел у вас есть значение, а не ощущение.
Что делать, если не работает
Ответ валиден по схеме, а дальше всё падает. Форма проверена, смысл — нет. Добавьте содержательные проверки в Code-ноду: диапазоны, значения из справочника, согласованность полей между собой. Именно этот случай называет Farhan95.
Авто-исправление стало постоянным. Это не проблема парсера, а сигнал, что схема или промпт неоднозначны. Упрощайте схему, сокращайте число полей, добавляйте примеры ожидаемого ответа. Держать второй вызов как норму — значит платить дважды за каждый запуск.
Ответы «плывут» от запуска к запуску. Проверьте температуру: для операционных сценариев она должна быть у нуля. Если разброс остался — модели не хватает контекста, и она его достраивает сама.
RAG находит не то. Luca_Tomasino отдельно оговаривает, что поиск по корпусу работает при условии правильной индексации. Farhan95 добавляет к этому свой опыт: на больших корпусах у более легковесных векторных хранилищ результаты получались неровные. Начинать разбор стоит с того, как нарезаны и чем проиндексированы документы, а не с замены модели.
Модель уже что-то сделала, прежде чем её проверили. Порядок узлов неправильный: валидация должна стоять до вызова инструмента, а не после. Все необратимые шаги — за проверкой или за человеком.
Что с этим делать
- Пройдите по существующему воркфлоу и для каждой модели напишите, почему задача не решается детерминированно. Ноды, где фраза не пишется, уберите — они дороже и менее предсказуемы.
- Включите Require Specific Output Format везде, где результат модели читает следующая нода. Авто-исправление — только на редких критичных шагах.
- Опустите температуру до 0–0.3 на всех операционных узлах.
- Разделите действия на обратимые и необратимые. Необратимые закройте валидацией с порогом или согласованием человека — особенно там, где речь о деньгах и комплаенсе.
- Поставьте классификацию первым узлом и распределите запросы по ветвям с разными моделями и разными правами.
И главный вывод из поста Luca_Tomasino, с которым сложно спорить: демо агента выглядит впечатляюще, потому что это задача демо. Перед тем как ставить агента в середину автоматизации, стоит проверить, не сделает ли обычная детерминированная логика то же самое быстрее, дешевле и одинаково каждый раз. Автор честно оценивает, что в половине случаев — сделает.
Источник: How to integrate LLMs into workflow automation? - Tips & Tricks - n8n Community