Путь AI-инженера в n8n ¶

Обновлено: 2026-05-29

Короткий ответ ¶

AI-инженеру в n8n нужно начинать не с выбора модели, а с границ задачи: какие данные доступны агенту, какие tools он может вызвать, какой формат ответа считается правильным и кто подтверждает рискованные действия. Первый production-ready маршрут: простой AI Agent с одним безопасным tool, structured output, тестовым набором вопросов, логом промптов и human approval для действий, которые меняют внешние системы. RAG стоит добавлять только после того, как понятно, какие документы нужны и как проверять качество ответа.

Почему AI-маршрут нельзя делать как обычный workflow ¶

Классический workflow обычно детерминирован: пришёл payload, сработали условия, ушёл результат. AI workflow добавляет вероятностный слой: модель может неверно понять задачу, выбрать не тот tool, вернуть текст вместо JSON, сослаться на неподходящий документ или уверенно ответить без источников. Поэтому AI-страница должна отличаться от обычного маршрута: здесь главный акцент на eval, guardrails, форматах ответа и наблюдаемости.

Если вы просто подключите AI Agent к CRM, почте и базе знаний, вы получите не помощника, а трудноотлаживаемый слой между пользователем и бизнес-системой. Надёжный AI workflow сначала ограничивает полномочия, потом измеряет качество, и только потом получает доступ к действиям.

Маршрут на 7 дней ¶

Такой маршрут снижает риск «магического» внедрения, где сначала всё выглядит впечатляюще, а потом команда не может объяснить ошибочный ответ.

Выбор первого AI-сценария ¶

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

Оцените сценарий по таблице:

Tools: меньше прав, больше контроля ¶

Tool в AI Agent должен быть узким. Не давайте агенту один универсальный HTTP Request «в любую систему». Лучше несколько маленьких tools: найти клиента, получить статус заказа, создать черновик задачи, проверить базу знаний. Для каждого tool опишите вход, выход, ограничения и пример.

Пример описания tool:

Tool: get_order_status
Input: order_id string
Output: status, paid_at, delivery_status, crm_url
Never: change order, create refund, send message to client

Такое описание помогает и модели, и человеку, который будет разбирать ошибку. Если tool меняет данные, добавьте human approval или хотя бы отдельную ветку подтверждения.

Structured output: не просите «ответь JSON», задайте контракт ¶

Для production важен не красивый текст, а стабильный формат. Если следующий node ждёт поля category, priority, summary, confidence, модель должна вернуть именно их. Добавьте схему, fallback и ветку ошибки. Если ответ невалиден, workflow не должен молча отправлять письмо или менять статус заявки.

Пример минимального результата:

{
  "category": "billing",
  "priority": "high",
  "summary": "Клиент сообщает о повторном списании",
  "confidence": 0.82,
  "needs_human_review": true
}

Поле needs_human_review лучше делать явным. Не пытайтесь выводить его только из уверенности модели: добавьте правила, например «платёж, возврат, юридическая претензия или негативный отзыв всегда требуют человека».

RAG: качество начинается с документов ¶

RAG не чинит плохую базу знаний. Если документы устарели, противоречат друг другу или не имеют metadata, агент будет находить не то и отвечать убедительно, но неверно. Перед подключением vector store подготовьте документы: удалите дубли, добавьте дату, тип документа, продукт, регион, статус актуальности и источник.

Минимальная схема RAG workflow:

question -> rewrite/search query -> vector search -> source filtering -> answer with citations -> quality checks -> response

Для русскоязычной базы знаний отдельно проверьте морфологию, смешанные термины, английские названия сервисов и аббревиатуры. Один и тот же вопрос может звучать как «возврат», «рефанд», «отмена оплаты» и «деньги вернулись». Без тестового набора вы не поймёте, что retrieval пропускает такие варианты.

Eval-набор вместо ощущения качества ¶

Соберите 20–50 вопросов до запуска. Для каждого вопроса укажите ожидаемый ответ, допустимые источники, запрещённые утверждения и критерий успеха. Примеры:

Eval нужно повторять после изменения prompt, модели, chunking, базы знаний или tools. Иначе каждое улучшение может незаметно ухудшить другой кейс.

Стоимость, latency и журналирование ¶

AI workflow должен логировать не только ошибку, но и контекст: модель, prompt version, tools used, latency, token usage, confidence, source IDs и итоговую ветку. Не логируйте персональные данные и секреты без необходимости; вместо полного текста можно хранить ID запроса, категорию и ссылку на защищённый журнал.

Для контроля расходов добавьте лимиты: максимальная длина входа, отсечение вложений, кэширование повторных FAQ-вопросов, fallback на более дешёвую модель для простых классификаций и ручную эскалацию при длинном контексте.

FAQ ¶

С чего начинать AI-инженеру в n8n?
С одного безопасного сценария: классификация, черновик ответа, поиск в базе знаний или извлечение полей. Сразу давать агенту права на изменения опасно.

Когда нужен RAG?
Когда ответ должен опираться на конкретные документы или базу знаний. Если задача решается правилами или простым API-запросом, RAG может быть лишним.

Что важнее: модель или eval?
Eval. Без тестового набора вы не поймёте, стала ли новая модель лучше именно для ваших сценариев.

Как уменьшить hallucination в n8n AI workflow?
Ограничить tools, требовать источники, использовать structured output, добавлять human approval для рискованных действий и проверять ответы на eval-наборе.

Можно ли подключать AI Agent к CRM?
Да, но сначала лучше разрешить только чтение. Создание задач, изменение статусов и отправка сообщений должны проходить через подтверждение или строгие правила.