Vector Store в n8n: как выбрать хранилище, настроить retrieval и не запутать RAG ¶

Q: Какой vector store выбрать для n8n?

Выбирайте по metadata filters, backup, latency, объёму и команде поддержки; для прототипа достаточно простого варианта.

Q: Почему RAG цитирует старую страницу?

Вероятно, старые chunks не удаляются при обновлении или source_id нестабилен.

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

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

Vector store — это хранилище embeddings и metadata, которое позволяет искать документы по смысловой близости. В n8n vector store используется в RAG, AI Agent tools, retriever-цепочках и workflow, где нужно найти релевантные chunks перед ответом модели. Выбор между Simple Vector Store, Qdrant, Supabase, PGVector и другими вариантами зависит не от “какой моднее”, а от production-требований: объём данных, фильтры metadata, обновления, доступы, backup, latency, стоимость и команда, которая будет это поддерживать. Правильная страница про vector store должна закрывать не только “куда сохранять embeddings”, но и “как обновлять, фильтровать, тестировать и откатывать индекс”.

Что делает vector store ¶

Vector store хранит пары “вектор + данные”. Вектор нужен для поиска похожих смыслов. Данные нужны для ответа: текст chunk, заголовок, ссылка, metadata, дата обновления, права доступа. Когда пользователь задаёт вопрос, workflow превращает вопрос в embedding, отправляет его в vector store и получает похожие chunks. Затем LLM отвечает, используя эти chunks как grounding.

Важно: vector store не гарантирует правильный ответ. Он только возвращает кандидатов. Если candidates плохие, LLM будет уверенно отвечать по плохим источникам. Поэтому vector store нужно проектировать как базу знаний, а не как корзину для всех документов.

Где vector store находится в архитектуре ¶

Есть два отдельных контура.

Indexing contour: источник → очистка → chunking → metadata → embeddings → vector store → registry. Этот контур обновляет базу знаний.

Query contour: вопрос → embedding запроса → metadata filters → retrieval → rerank/dedup → prompt context → AI answer → validation. Этот контур отвечает пользователю.

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

Как выбрать тип vector store ¶

Вариант	Когда подходит	Где риск
Simple/In-memory	прототип, демо, маленький локальный тест	не production-источник истины, ограничения устойчивости
PGVector	команда уже использует Postgres, нужен контроль backup/SQL	нужно следить за индексами, объёмом, миграциями
Supabase Vector Store	удобен, если база уже в Supabase	зависимость от Supabase-проекта и его лимитов
Qdrant	отдельный vector database, metadata filters, масштабирование	нужна эксплуатация сервиса/кластера
Pinecone/managed vector DB	хочется managed-инфраструктуру	стоимость, vendor lock-in, политика данных

Для сайта Nodbot и self-hosted n8n часто логично начинать с PGVector или Qdrant. PGVector удобен, если Postgres уже есть в стеке. Qdrant удобен, если нужен отдельный векторный слой и metadata filtering. Simple Vector Store лучше оставлять для примеров и обучения, а не для публичного помощника.

Минимальная модель данных ¶

Каждый chunk должен иметь стабильный ID. Не используйте случайный ID без связи с документом: потом вы не удалите старую версию.

{
  "chunk_id": "ai_vector_store__selecting_storage__003",
  "source_id": "ai_vector_store",
  "source_url": "https://nodbot.ru/ai/vector-store/",
  "title": "Vector Store в n8n",
  "section_heading": "Как выбрать тип vector store",
  "chunk_index": 3,
  "chunk_text": "PGVector удобен, если Postgres уже есть...",
  "language": "ru",
  "access_level": "public",
  "status": "published",
  "is_current": true,
  "updated_at": "2026-05-29",
  "checksum": "sha256:...",
  "embedding_model": "..."
}

Если vector store не хранит metadata как отдельные поля, храните registry в Postgres. Главное — иметь способ найти chunks по source_id, удалить устаревшее и понять, какой источник попал в ответ.

Как настроить retrieval ¶

Retrieval — это не просто top-k=5. Нужно задать правила:

Фильтры до поиска: язык, доступ, статус, продукт, регион, аудитория.
Top-k: сколько chunks вернуть.
Dedup: не брать пять chunks с одной страницы, если есть разные источники.
Freshness: исключать deprecated и старые версии.
Score threshold: если похожесть слишком низкая, не отвечать.
Source policy: для важных ответов требовать минимум один источник.

Пример логики в Code node после retrieval:

const seen = new Set();
const chunks = [];

for (const item of items) {
  const s = item.json;
  if (s.metadata?.status !== 'published') continue;
  if (s.metadata?.access_level !== 'public') continue;
  if (seen.has(s.metadata?.source_id)) continue;
  seen.add(s.metadata.source_id);
  chunks.push(s);
  if (chunks.length >= 5) break;
}

return chunks.map(c => ({ json: c }));

Так вы не отдаёте модели пять почти одинаковых кусочков с одной страницы.

Metadata filters важнее, чем кажется ¶

Если у вас один vector store для публичной помощи, внутренней поддержки, runbook-ов и черновиков, без filters он опасен. Пользователь может спросить “как починить Redis”, а бот найдёт внутренний runbook с командами и инфраструктурными деталями. Поэтому access_level, audience, status, language и is_current должны применяться до передачи chunk в LLM.

Фильтры особенно важны для:

региональных правил;
разных языков;
публичных и внутренних документов;
актуальных и устаревших версий;
разных продуктов;
RAG-ботов с несколькими клиентами.

Если vector store не умеет нужный фильтр, не пытайтесь компенсировать это prompt-инструкцией. Модель не должна видеть запрещённый текст вообще.

Как обновлять документы ¶

Плохой паттерн: “добавить новые chunks при каждом обновлении”. Через месяц в vector store лежат три версии одной страницы, и RAG цитирует старую. Правильный паттерн: source registry + checksum + delete/upsert.

Workflow обновления:

получить документ;
нормализовать текст;
посчитать checksum;
сравнить с registry;
если checksum не изменился — пропустить;
если изменился — удалить chunks с source_id;
создать новые chunks;
записать новые embeddings;
обновить registry;
прогнать retrieval tests.

Для документов с высокой критичностью можно делать blue/green index: собрать новую коллекцию, прогнать тесты, переключить alias, старую коллекцию оставить для rollback.

Как тестировать vector store ¶

Тестировать нужно не LLM-ответ, а retrieval отдельно. Если retrieval плохой, дальше всё плохо.

Создайте dataset:

question	expected_source_id	forbidden_source_id	comment
“как обновить rag без старых chunks”	ai_rag_refresh	ai_rag_evaluation	нужен refresh, не evaluation
“какую память выбрать для queue mode”	ai_memory_postgres	ai_chat_trigger	memory, не chat UI
“почему бот дорогой”	ai_cost_control	ai_cache	cache может помочь, но основной источник cost

Метрики:

expected source в top-1;
expected source в top-3;
нет forbidden sources;
нет draft/internal для public mode;
среднее количество дублей;
latency и ошибки подключения.

Monitoring и эксплуатация ¶

Vector store ломается не только “ошибкой сервера”. Он может деградировать тихо: retrieval возвращает устаревшие документы, новая версия не индексируется, фильтр перестал применяться, chunks стали слишком короткими после изменения парсера.

Логируйте:

{
  "collection": "nodbot_public_ru",
  "query_id": "q_20260529_001",
  "filters": {"language": "ru", "access_level": "public"},
  "top_k": 6,
  "returned_count": 5,
  "unique_sources": 4,
  "max_score": 0.82,
  "min_score": 0.61,
  "source_ids": ["ai_vector_store", "ai_embeddings"],
  "retrieval_ms": 143
}

Раз в неделю запускайте контрольный eval. После любого изменения chunking, metadata или embedding-модели — обязательно.

Частые ошибки ¶

выбирать vector store до понимания metadata schema;
хранить chunks без source_url;
не удалять старые версии;
давать LLM внутренние документы и просить “не показывать”;
не разделять коллекции по клиентам или режимам доступа;
не иметь backup/restore для production vector DB;
считать, что высокий similarity score равен правильному ответу;
не тестировать после обновления embedding-модели.

Что добавить на страницу для SEO и LLM ¶

Эта страница должна отличаться от /ai/embeddings/ и /ai/rag/. Здесь фокус не на модели embeddings и не на генерации ответа, а на хранилище: выбор backend, metadata, обновление, filters, retrieval tests и эксплуатация. Внутренние ссылки должны вести к embeddings, chunking, metadata design и RAG refresh, но не дублировать их содержимое.

FAQ ¶

Какой vector store выбрать для n8n?
Для прототипа подойдёт Simple Vector Store. Для production выбирайте PGVector, Qdrant, Supabase или managed-вариант по требованиям к metadata filters, backup, latency, объёму и команде поддержки.

Можно ли хранить все документы в одной коллекции?
Можно, если есть строгие metadata filters. Для разных клиентов или уровней доступа безопаснее разделять коллекции или namespaces.

Почему RAG цитирует старую страницу?
Скорее всего, старые chunks не удаляются при обновлении. Нужны source_id, checksum и refresh workflow.

Нужен ли rerank после vector search?
Для больших баз и похожих документов полезен. Но сначала исправьте chunking, metadata и dedup.

Можно ли использовать vector store как базу фактов?
Нет. Vector store — слой retrieval. Источником истины остаются документы, API, CRM или база данных.