Chat Trigger в n8n: виджет, embedded chat, CORS, память и production-бот ¶

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

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

Chat Trigger в n8n нужен, когда workflow должен начинаться с сообщения пользователя в чат-интерфейсе: hosted chat, embedded widget или внутренний AI assistant. Для production важно настроить Allowed Origin/CORS, понятный response mode, session_id, память, RAG/no-answer, PII-редакцию, human fallback и ограничения на tools. Если оставить чат как “публичный prompt к AI Agent”, он быстро превращается в источник утечек, дорогих запросов и непредсказуемых действий.

Где использовать Chat Trigger ¶

Chat Trigger подходит для AI-виджетов на сайте, внутреннего helpdesk-бота, поискового ассистента по базе знаний, onboarding-чата, pre-sales ассистента, RAG-чата по документации и операционного интерфейса для сотрудников. Его сильная сторона — готовый chat entrypoint, который можно связать с Agent, memory, vector store, API tools и approval steps.

Не используйте Chat Trigger как замену webhook API для машинных интеграций. Если источник — CRM, платёжная система, форма или backend, чаще нужен Webhook node. Chat Trigger — это пользовательский диалог, где важны session, UX, текст ответа, задержка, история и fallback.

Hosted или embedded chat ¶

Если чат встраивается на публичный сайт, нельзя полагаться только на “сложную ссылку”. Нужны ограничения origin, rate limits, input limits и политика данных. Для B2B-личного кабинета лучше передавать signed user context с backend, а не спрашивать email в свободном тексте.

Response mode: когда отвечать последней нодой, а когда Response nodes ¶

У Chat Trigger есть режимы ответа. Простая схема — отвечать результатом последней ноды. Это удобно для демо: пользователь написал, Agent ответил, last node вернул текст. Но для production чаще нужен явный ответ через Chat node или Respond to Webhook-style логику: так проще контролировать формат, ошибки и несколько сообщений.

Используйте When Last Node Finishes, если:

• workflow короткий;
• нет фоновых действий;
• ответ всегда один;
• нет сложных ошибок.

Используйте Using Response Nodes, если:

• нужно отправлять разные ответы по веткам;
• есть human fallback;
• часть workflow работает дольше;
• нужно показать “заявка принята”, а обработку продолжить;
• нужно скрыть технический JSON последней ноды.

Сессии и память ¶

Production-чат должен понимать, где заканчивается один диалог и начинается другой. Минимальный ключ: session_id. Для authenticated пользователей лучше связывать session_id с user_id, account_id, ролью и consent. Для анонимного сайта задайте срок жизни cookie/session и не храните лишние персональные данные.

Память делите на три слоя:

1. Short-term chat history — последние N сообщений.
2. Conversation summary — краткое резюме длинной переписки.
3. User facts — только явно разрешённые данные: язык, выбранный продукт, роль, тариф.

Не смешивайте память разных пользователей. Не сохраняйте в memory токены, пароли, API keys, номера карт, документы и чувствительные данные. Если пользователь прислал такие данные, отредактируйте их до LLM или отправьте в защищённый канал обработки.

Архитектура workflow ¶

Рабочая схема:

1. Chat Trigger — принимает сообщение.
2. Session resolver — проверяет session_id, user_id, origin, auth context.
3. Input sanitizer — режет длину, удаляет опасные вложения, маскирует PII.
4. Intent classifier — вопрос, поиск, лид, support, dangerous action.
5. RAG retrieval — только если вопрос требует базы знаний.
6. AI Agent / Chain — генерирует ответ или вызывает tool.
7. Safety checker — проверяет sources, PII, policy, output schema.
8. Human fallback — если confidence низкий или запрос рискованный.
9. Chat response — возвращает понятный ответ пользователю.
10. Logs/evals — сохраняет trace для качества.

JSON-контракт ответа ¶

Даже если пользователь видит текст, внутри workflow полезно держать структурированный результат.

{
  "reply": "Короткий ответ пользователю",
  "intent": "knowledge_question",
  "requires_human": false,
  "confidence": 0.84,
  "sources": [
    { "title": "Webhook production checklist", "url": "/playbooks/webhook-production-checklist/" }
  ],
  "next_action": "show_sources",
  "safety_flags": []
}

Такой контракт помогает не отправить пользователю внутренние поля, но сохранить их для логов, QA и аналитики.

CORS и Allowed Origin ¶

Если чат встроен на сайт, настройте Allowed Origin. Для локальной разработки wildcard допустим, но production-виджет лучше ограничить доменами, где чат действительно должен работать: https://nodbot.ru, https://app.example.com. Если оставить *, чат проще встроить куда угодно, а вы потеряете часть контроля над источником запросов.

CORS не заменяет аутентификацию. Он только ограничивает браузерные cross-origin обращения. Для приватного ассистента нужна auth-логика: signed session, токен личного кабинета, allowlist или серверная проверка пользователя.

RAG и no-answer policy ¶

Чат по базе знаний должен отвечать только на основе найденных источников. Если retrieval ничего не нашёл, правильный ответ — “в базе нет точного ответа” плюс предложение уточнить запрос или обратиться к человеку. Нельзя просить модель “ответить по общим знаниям”, если пользователь ожидает ответ по вашим документам.

Добавьте в prompt правило:

Отвечай только по переданным sources. Если sources не подтверждают ответ, верни no_answer и задай один уточняющий вопрос. Не выдумывай ссылки, цены, SLA и технические параметры.

Human fallback ¶

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

• пользователь просит договор, счёт, возврат, удаление данных;
• AI не нашёл источник;
• confidence низкий;
• пользователь недоволен ответом;
• вопрос связан с персональными данными;
• tool call опасен.

Fallback не обязан быть live chat. Можно создать тикет, отправить email, уведомить Telegram/Slack-канал или показать форму обратной связи. Главное — явно сказать пользователю, что произойдёт дальше.

Метрики качества ¶

Отслеживайте не только “сколько сообщений обработано”. Важнее:

• доля no-answer;
• доля human fallback;
• средняя задержка ответа;
• стоимость на диалог;
• retrieval hit rate;
• source accuracy;
• CSAT/полезность;
• доля повторных вопросов;
• количество safety flags;
• количество tool errors.

Если no-answer слишком низкий, чат может галлюцинировать. Если human fallback слишком высокий, база знаний или prompt недостаточно хороши. Если latency растёт, смотрите retrieval, модель, tools и размер контекста.

Типовые ошибки ¶

1. Embedded chat оставлен с Allowed Origin: * без необходимости.
2. Session_id не связан с пользователем, память смешивается.
3. Ответ строится по последней ноде и случайно показывает технический JSON.
4. Нет no-answer policy для RAG.
5. Public chat имеет доступ к tools с записью.
6. Нет ограничений длины сообщения и rate limits.
7. Logs содержат PII без маскирования.
8. Нет понятного fallback к человеку.

Production rollout ¶

Запускайте по этапам:

1. Internal demo на тестовой базе.
2. Закрытая группа пользователей.
3. Read-only режим без dangerous tools.
4. Human review для всех actions.
5. Автоматизация низкорисковых запросов.
6. Регулярные evals и пересмотр prompt/sources.

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