--- title: "AI search agent в n8n: как отвечать по базе знаний, — Nodbot" source_url: "https://nodbot.ru/ai/ai-search-agent/" canonical_url: "https://nodbot.ru/ai/ai-search-agent/" language: "ru" content_type: "AIGuide" section: "ai" generated_at: "2026-05-30" word_count_source: 1220 --- # AI search agent в n8n: как отвечать по базе знаний, показывать источники и не выдумывать ## AI summary Полное руководство по AI search agent в n8n: RAG, metadata filters, permissions, no-answer policy, source citations, evals и production-мониторинг. ## Best used for Страница объясняет «AI search agent в n8n: как отвечать по базе знаний, — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ - Когда нужен search agent - Архитектура workflow - Как индексировать базу знаний - Как выбирать retrieval strategy - Prompt для ответа с источниками - No-answer policy - Permissions и безопасность ## Source outline # 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.ruWebhook production checklist n8n", "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": "Webhook production checklist n8n" }, { "title": "Diagnostics: webhook", "url": "Диагностика Webhook в n8n" } ] } ``` ## Типовые ошибки - Нет metadata filters. Агент смешивает внутренние и публичные документы. - Ответ без sources. Невозможно проверить факты. - Vector store вместо API. Статусы заказов и сделок нужно брать из source of truth. - Слишком большие chunks. Ответы становятся размытыми. - Нет no-answer. Агент начинает заполнять пробелы фантазией. - Не тестируется stale index. Документы обновились, а vector store остался старым. ## Контроль качества AI-workflow AI-workflow по теме «AI search agent в n8n» должен иметь измеримый контракт: что модель получает, какие действия ей разрешены, какой JSON она обязана вернуть и при каких условиях включается human review. Без этого качество нельзя отличить от удачного демо. Отдельно фиксируйте версию prompt, модель, источники контекста и причину fallback. Главный риск — получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry. - Слой | Что зафиксировать | Зачем - Вход | нормализованный prompt, контекст, список источников, версия промпта и ожидаемый JSON-ответ | позволяет повторить проблему без доступа к production-секретам - Контроль | validation_error_rate, token_cost, fallback_usage, human_review_rate, source_coverage | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «AI search agent в n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "request_id": "req_demo_001", "prompt_version": "2026-05-29", "input": "краткое нормализованное сообщение пользователя", "allowed_actions": ["read", "draft", "classify"], "forbidden_actions": ["send_without_review", "change_payment"], "expected_output": { "intent": "technical|support|sales|unknown", "confidence": 0.0, "needs_human_review": true, "sources": [] } } ``` ### Критерий готовности - определён JSON-контракт ответа и validation step после модели - опасные действия проходят через approval или создают только draft - логируются prompt_version, model, sources, cost и fallback_reason - есть eval-набор минимум для happy path, low confidence и prompt injection ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.