Every business we work with has the same problem: they want an AI chatbot or support agent, but the moment it's asked something specific — a refund policy, a product spec, an internal process — it either hallucinates or falls back to "I don't have that information." That's a fine-tuning problem that nobody needs. What they actually need is RAG.

Retrieval-Augmented Generation (RAG) is the pattern where, instead of baking knowledge into a model, you pull the right chunks of information at query time and hand them to the LLM as context. The model reasons over real data. No hallucinations about your return policy. No outdated specs. Just accurate answers — updated whenever your source docs change.

The good news: n8n has first-class RAG support via its Vector Store nodes. You don't need LangChain, Python, or a data engineer. You need a Supabase (or Pinecone, or Qdrant) account, an embeddings model, and about 45 minutes.

What You're Actually Building

A RAG pipeline has two distinct flows. Most people conflate them and get confused. Keep them separate in your head from the start:

That's it. Two workflows. One database in the middle. Let's build both.

Step 1: Choose Your Vector Store

n8n supports Pinecone, Qdrant, Supabase (pgvector), Weaviate, and a handful of others. For most small-to-mid businesses, Supabase is the easiest entry point — you probably already have a Postgres instance, and pgvector is a one-line extension away. Pinecone is better if you're hitting millions of vectors and need managed scaling.

For this walkthrough, we'll use Supabase + OpenAI embeddings. Swap in your preferred store — the n8n node structure is identical.

-- Run once in your Supabase SQL editor create extension vector; create table documents ( id bigserial primary key, content text, metadata jsonb, embedding vector(1536) ); create index on documents using ivfflat (embedding vector_cosine_ops) with (lists = 100);

The vector(1536) dimension matches OpenAI's text-embedding-3-small. If you switch to a different embeddings model, update this number.

Step 2: Build the Ingestion Workflow

This workflow runs on a schedule (or on-demand via webhook) to keep your vector store current. Here's the node chain:

The metadata field is more important than people realise. When the LLM cites sources or you want to filter retrieval by document type (e.g., only search pricing docs for pricing questions), that metadata is what you filter on.

⚠ Chunking Strategy Matters

Step 3: Build the Query Workflow

This is the workflow your chatbot or support agent calls on every user message:

The system prompt is where most RAG implementations fail. Don't just dump context and hope. Be explicit:

System prompt template: You are a support agent for [Company Name]. Answer the user's question using ONLY the context below. If the answer is not in the context, say "I don't have that information — let me connect you with a human." Do not make up information. Do not draw on general knowledge about competitor products or industry norms. Context: {{ $json.context }} User question: {{ $json.userMessage }}

Filtering by Metadata (The Power Move)

Once you have metadata on your chunks, you can do filtered retrieval — only search relevant document categories based on the query intent. This dramatically improves precision.

In n8n's Supabase Vector Store query node, you can pass a filter JSON. For example, if you detect the user is asking about pricing (via a classification step or keyword match), filter to only search the category: "pricing" documents:

// Metadata filter in Vector Store query node { "category": "pricing" }

This means your support bot searching 50,000 chunks of product documentation won't accidentally return irrelevant warranty text when someone asks about upgrade pricing.

Keeping the Knowledge Base Fresh

A RAG system is only as good as its data. You need a maintenance strategy:

In n8n, you can wire a Delete → Insert pattern in your ingestion workflow: before inserting fresh chunks, filter-delete all existing chunks with the same source_file metadata value.

Real-World Use Cases We've Built

To make this concrete, here's what RAG pipelines actually look like in production for our clients:

⚡ What to Do First

Costs to Expect

RAG is one of the cheapest AI patterns to run at scale. A typical 5,000-page knowledge base costs under $2 to embed with text-embedding-3-small. Each query (embed + retrieve + LLM call with 2K context) runs about $0.003–0.008 with GPT-4o-mini. A support bot handling 1,000 queries/day costs roughly $3–8/day in API fees — usually well under the cost of a single additional support rep hour.

The main ongoing cost is re-embedding when documents change significantly. Track which docs actually change and you'll keep this minimal.

Related reading: AI customer support automation end-to-end, n8n AI agent workflow patterns, and combining multiple agents with orchestration.

Want this built for your business? We build and maintain RAG pipelines for clients — from ingestion to monitoring, with no Python required on your end.