AI search agent в n8n: как отвечать по базе знаний, показывать источники и не выдумывать ¶

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

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

AI search agent в n8n — это агент, который ищет информацию в базе знаний, документации, runbook-ах, CRM notes или внутренних источниках и формирует ответ только на основе найденного контекста. В отличие от простого RAG-чата, search agent может выбирать tool, применять metadata filters, проверять права доступа, задавать уточняющий вопрос и возвращать no_answer, если источника нет. Production-схема: query normalization → permission context → retrieval → source filtering → answer generation with citations → faithfulness check → fallback/escalation → logging/evaluation.

Когда нужен search agent ¶

Search agent нужен, когда пользователи задают вопросы не по одной странице, а по большой базе: “как настроить webhook за Cloudflare?”, “почему RAG отвечает старым текстом?”, “какой runbook при Redis unavailable?”, “что делать, если клиент просит возврат?”. Обычный keyword search часто не находит ответ из-за разных формулировок. RAG помогает найти похожие chunks, а агент добавляет логику: какие источники разрешены, нужно ли уточнение, какой tool вызвать, можно ли отвечать.

Но search agent не должен заменять source of truth. Если вопрос “какой статус заказа ORD-1042?”, нужно идти в API/CRM, а не искать похожий документ. Если вопрос “какая цена по договору?”, нужен CRM/ERP с правами доступа. Vector search подходит для знаний, инструкций и объяснений, но не для актуальных транзакционных данных.

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

Trigger — Chat Trigger, Slack, Telegram, Webhook или internal UI.
Query normalizer — очищает вопрос, определяет язык, intent, entities.
Permission context — роль пользователя, team, customer_id, access level.
Source router — выбирает knowledge base: public docs, internal runbooks, customer docs, CRM notes.
Retriever — vector store, keyword search или hybrid search.
Metadata filter — audience, product, language, version, status, access_level.
Rerank / source selection — оставляет самые полезные chunks.
Answer generator — отвечает только по переданным источникам.
Faithfulness check — проверяет, есть ли ответ в sources.
No-answer/fallback — уточнить вопрос, показать ссылки или эскалировать.
Logging/evals — сохраняет query, retrieved sources, answer, feedback.

Если убрать permission context, агент может ответить публичному пользователю внутренним runbook-ом. Если убрать no-answer, он будет выдумывать.

Как индексировать базу знаний ¶

Search agent хорош настолько, насколько хорош индекс. Для каждой страницы/документа храните metadata:

{
  "source_id": "playbook_webhook_production_checklist",
  "url": "https://nodbot.ru/playbooks/webhook-production-checklist/",
  "title": "Webhook production checklist",
  "audience": "public",
  "product": "n8n",
  "topic": "webhook",
  "language": "ru",
  "status": "published",
  "updated_at": "2026-05-29",
  "access_level": "public",
  "chunk_id": "playbook_webhook_production_checklist#h2-response-mode"
}

Metadata не менее важна, чем embedding. Она позволяет не смешивать устаревшие документы, внутренние инструкции, разные продукты и языки.

Как выбирать retrieval strategy ¶

Тип вопроса	Лучший поиск
“почему webhook не работает после активации”	vector/hybrid
“страница /ai/rag-refresh/”	exact URL/keyword
“заказ ORD-1042”	API/SQL
“что делать при Redis down”	vector + topic filter
“какие документы доступны клиенту X”	permissioned SQL + vector
“последний статус сделки”	CRM API

Хороший search agent умеет выбрать не только “искать в vector store”, но и “это точный запрос, нужен API”.

Prompt для ответа с источниками ¶

Запретите агенту отвечать по памяти модели. Он должен использовать только sources.

Ты отвечаешь только на основе блока SOURCES.
Если ответа нет в SOURCES, верни no_answer и предложи уточнение.
Каждое важное утверждение должно иметь source_id.
Не используй знания модели для фактов о продукте, ценах, SLA и настройках.
Если источники противоречат друг другу, укажи конфликт и выбери более свежий updated_at.

Output schema:

{
  "answer": "Короткий ответ пользователю",
  "sources": [
    { "source_id": "ai_rag_refresh#h2-stale-index", "url": "https://nodbot.ru/ai/rag-refresh/" }
  ],
  "confidence": 0.82,
  "no_answer": false,
  "needs_escalation": false,
  "follow_up_question": null
}

Если sources пустой, answer не должен быть обычным ответом. Это no-answer.

No-answer policy ¶

No-answer — это не провал, а защита качества. Агент должен честно сказать, что не нашёл подтверждённый источник, если:

retrieval вернул нерелевантные chunks;
источники противоречат;
документ устарел;
вопрос требует private data без прав;
пользователь спрашивает про цену/договор/статус, а source of truth не подключён;
вопрос не относится к базе.

Хороший no-answer:

{
  "no_answer": true,
  "answer": "В доступной базе нет подтверждённой инструкции по этому сценарию. Могу уточнить продукт и окружение или передать вопрос специалисту.",
  "follow_up_question": "Вы спрашиваете про self-hosted n8n, n8n Cloud или другой сервис?",
  "needs_escalation": false
}

Плохой no-answer: “Я не знаю”. Пользователю нужен следующий шаг.

Permissions и безопасность ¶

Search agent должен фильтровать источники до генерации ответа. Нельзя сначала дать модели все chunks, а потом попросить “не показывай внутреннее”. Если пользователь public, retrieval должен искать только access_level=public. Если сотрудник support, можно добавить internal runbooks. Если запрос относится к клиенту, нужно проверить customer_id.

Минимальный permission context:

{
  "user_id": "u_1042",
  "role": "support_agent",
  "allowed_access_levels": ["public", "internal_support"],
  "customer_id": null,
  "locale": "ru-RU"
}

Для публичного чата вообще не индексируйте internal secrets в тот же vector store без строгой фильтрации.

Как проверять качество retrieval ¶

Нужно тестировать не только финальный answer, но и sources. Если retrieval вернул плохие chunks, хороший ответ невозможен.

Eval case:

{
  "question": "Почему webhook работает в test URL, но не работает после активации workflow?",
  "expected_sources": ["webhook_production_checklist", "diagnostics_webhook"],
  "forbidden_sources": ["telegram_ai_bot", "billing_payment"],
  "must_contain": ["production URL", "активировать workflow"],
  "must_not_contain": ["создайте новый Telegram bot"]
}

Метрики:

top-k source recall;
source precision;
answer faithfulness;
citation accuracy;
no-answer accuracy;
stale source rate;
permission violation count;
latency;
cost.

Как отвечать с цитатами без перегруза ¶

Пользователю не нужен список из 12 chunks. Дайте короткий ответ и 2–4 источника. Внутри системы храните chunk_id, но в UI показывайте заголовок/URL. Если ответ операционный, добавьте steps. Если ответ справочный, добавьте summary и ссылки.

Пример:

{
  "answer": "Для production webhook в n8n нужно использовать Production URL, а не Test URL. Workflow должен быть активирован, а WEBHOOK_URL корректно настроен за reverse proxy.",
  "steps": [
    "Проверьте, активирован ли workflow",
    "Сравните Test URL и Production URL",
    "Проверьте WEBHOOK_URL и proxy headers"
  ],
  "sources": [
    { "title": "Webhook production checklist", "url": "/playbooks/webhook-production-checklist/" },
    { "title": "Diagnostics: webhook", "url": "/diagnostics/webhook/" }
  ]
}

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

Нет metadata filters. Агент смешивает внутренние и публичные документы.
Ответ без sources. Невозможно проверить факты.
Vector store вместо API. Статусы заказов и сделок нужно брать из source of truth.
Слишком большие chunks. Ответы становятся размытыми.
Нет no-answer. Агент начинает заполнять пробелы фантазией.
Не тестируется stale index. Документы обновились, а vector store остался старым.