Document Ingestion: Loading Data for RAG

What Is RAG?

RAG stands for Retrieval-Augmented Generation. Instead of relying solely on an LLM's training data, RAG workflows first retrieve relevant content from a knowledge base, then pass it to the model as context. The result: accurate, grounded answers that reference your specific documents — not generic knowledge that may be outdated or simply hallucinated.

RAG Uses Two Separate Workflows

A complete RAG system in n8n runs as two workflows with distinct jobs:

• Ingestion workflow — loads your documents, splits them into chunks, converts each chunk into a vector embedding, and stores everything in a vector database. This workflow runs once to build the knowledge base and again whenever your documents change.
• Query workflow — receives a user question, retrieves the most relevant document chunks from the vector database, and passes them to an AI Agent or LLM Chain to generate a grounded response.

This lesson covers the ingestion workflow. The query side is covered in lesson 9.

Step 1: Load Your Documents

The ingestion workflow starts with a document loader. n8n provides several options:

• Default Data Loader — accepts binary files passed as workflow input (PDF, DOCX, TXT, HTML, Markdown).
• Google Drive node — fetch files from a specific folder, making it easy to trigger re-ingestion when content is updated.
• HTTP Request node — fetch a web page or documentation URL and pass the HTML or text content to the loader.

Step 2: Split into Chunks

After loading, add a Recursive Character Text Splitter sub-node. This splits each document into smaller chunks that fit within the embedding model's token limit and provide focused, relevant context during retrieval. Key settings:

• Chunk Size — target 500 to 1000 tokens per chunk. Too small: each chunk loses surrounding context. Too large: each chunk contains too many unrelated topics, diluting the semantic signal.
• Chunk Overlap — set to 10 to 20% of the chunk size (for example, 100 tokens for a 500-token chunk) to preserve context across chunk boundaries.

Step 3: Generate Embeddings

Add an Embeddings sub-node (OpenAI Embeddings, Google Gemini Embeddings, or Ollama Embeddings). This model converts each text chunk into a numerical vector that captures its semantic meaning. The model choice matters permanently: you must use the exact same embedding model for ingestion and retrieval. Switching models later requires re-ingesting all documents from scratch.

Step 4: Store in a Vector Database

Add a Vector Store node in insert mode. n8n supports Pinecone, Qdrant, Supabase pgvector, Postgres pgvector, Weaviate, and Milvus. Configure the credentials and the index or collection name (for example, support-docs). When the workflow runs, each chunk, its embedding vector, and the source document's metadata are all stored together — ready for semantic retrieval.