Venkatesh Murthy N S

n8n RAG Workflow Automation

Detail	Description
The Big Picture	Built a complete Retrieval Augmented Generation (RAG) system using n8n to understand how AI agents retrieve and generate context-aware responses. Created a personal knowledge base that transforms saved articles, posts, and notes into an intelligent chat interface—going from concept to working prototype in one weekend to deeply understand AI product architecture and tradeoffs.
Key Skills Showcased	Workflow Automation, RAG Architecture, AI Integration, Vector Databases, Prompt Engineering

n8n RAG workflow architecture showing document ingestion, vector processing, and query response pipeline

The Challenge

🎯 Why Build This?

The Product Manager's Dilemma: As a PM working on AI products, I was making decisions about RAG systems, vector databases, chunking strategies, and embedding models—but only understanding them conceptually. I could read documentation and talk to engineers, but I didn't truly grasp the constraints, tradeoffs, and technical realities that impact product decisions.

The Learning Goal

I wanted to answer critical product questions that can't be learned from documentation alone:

How do token limits actually constrain user experience? What happens when a user's query context exceeds limits?
What's the real tradeoff between chunk size and retrieval accuracy? How does this affect response quality?
How expensive are embedding operations at scale?What does this mean for product pricing and margins?
Why do engineers push back on certain feature requests? What are the technical guardrails I need to respect?
How fast can a RAG system actually respond?What's realistic for user expectations?

The Personal Use Case: "What if I could chat with all those LinkedIn posts, Medium blogs, and subreddit answers I've saved over the years? For me, this wasn't just a tech experiment—it was a way to understand how AI systems really work behind the scenes so I can make better product decisions."

The Solution

Built a complete RAG pipeline using n8n (low-code automation platform) that ingests documents from Google Drive, processes them into semantic vectors, stores them in a vector database, and enables natural language querying with AI-generated responses grounded in my personal knowledge base.

What is RAG?

Retrieval Augmented Generation (RAG) combines large language models with a retrieval system that fetches relevant external data in real-time, feeding it into the model to generate accurate, context-aware responses. Instead of relying solely on the LLM's training data, RAG grounds responses in your specific documents.

RAG Pipeline Architecture

1. Data Ingestion & Trigger: Google Drive files trigger the workflow automatically when added or updated. The system monitors specified folders and kicks off processing for new documents.

2. Text Extraction: n8n nodes extract text from various file formats (PDFs, docs, markdown, text files). Metadata like filename, creation date, and source are preserved for context.

3. Chunking Strategy: Recursive character splitting breaks large documents into manageable chunks. Each chunk maintains semantic coherence while staying within token limits for embeddings. Chunk overlap ensures context isn't lost at boundaries.

4. Embeddings Generation: Google's embedding model converts text chunks into high-dimensional semantic vectors (768 dimensions). These vectors capture meaning, allowing similarity search based on concepts rather than keywords.

5. Vector Storage: Embeddings are stored in Supabase with pgvector extension, enabling fast similarity search. Each vector is linked to its source chunk and metadata for retrieval.

6. Query & Similarity Match: User query is vectorized using the same embedding model. Supabase performs cosine similarity search to find the most relevant chunks from the knowledge base. Top-K results are retrieved based on similarity scores.

7. Context-Aware Response: Retrieved chunks are injected into Gemini's context window as grounding information. The LLM generates a response that synthesizes the retrieved knowledge, citing sources and providing relevant context from the original documents.

Why n8n?: Speed to prototype mattered more than perfect architecture. As a PM, I needed to test ideas and understand concepts quickly without deep coding. n8n's visual workflow editor let me focus on understanding RAG mechanics rather than debugging infrastructure. The lesson: in early product stages, choose tools that maximize learning velocity, not engineering purity.

What I Learned

💡 Hands-On Building Demystifies Complex Concepts

Reading about RAG in documentation versus building one are completely different experiences. Building forced me to understand: How do embeddings actually work? Why does chunk size matter? What's the real latency in vector search? These aren't academic questions—they directly impact product decisions about features, UX, and performance expectations.

💡 Technical Constraints Shape Product Decisions

Token limits, embedding costs, chunking rules, and memory constraints aren't just engineering problems—they're product constraints. When engineers say "we can't do that," it's often because of real limitations I now understand viscerally. This experience makes me a better partner to engineering teams because I can anticipate constraints and design within guardrails.

💡 Mapping Before Building Prevents Chaos

I sketched out the entire pipeline workflow before building—identifying each step, data transformation, and integration point. This upfront mapping prevented last-minute surprises and architectural backtracking. The parallel to PM work is obvious: scoping features clearly before development keeps projects focused and teams sane.

💡 Real-World Tradeoffs Require Ruthless Prioritization

Every decision had tradeoffs: Larger chunks = better context but slower search. More embeddings = better recall but higher costs. Higher K in retrieval = more comprehensive but noisier. These forced prioritization decisions based on the use case—exactly like balancing user needs, technical realities, and business constraints in product work.

💡 Prototype Speed > Perfect Architecture (Early Stage)

Using n8n meant I could build and test in hours rather than days. The system isn't production-ready, but it taught me more in one weekend than weeks of reading documentation. As a PM, this reinforces that early-stage validation requires speed, not perfection. Build to learn, then architect for scale.

Key Technical Insights for Product Decisions

What This Means for AI Product Management

Chunk Size Strategy: Learned that 500-1000 token chunks balance context preservation with retrieval precision. Too small = loss of context; too large = irrelevant information in retrieval.
Embedding Costs: Embedding generation is the expensive operation—affects product pricing. Retrieval (similarity search) is cheap. Design features accordingly.
Latency Expectations: End-to-end response takes 2-5 seconds (embedding query + vector search + LLM generation). Can't promise instant responses—set user expectations correctly.
Quality vs. Quantity: More retrieved chunks ≠ better responses. Top 3-5 most relevant chunks usually outperform top 10. Quality of retrieval matters more than quantity.
Cold Start Problem: RAG systems need sufficient content to be useful. Minimum viable corpus size is a real product constraint for launch planning.

Outcome & Impact

What I Built

A working RAG system that can intelligently search and synthesize information from my personal knowledge base—answering questions by retrieving relevant context from years of saved articles, posts, and notes.

✅ Technical Achievements

Processed 100+ documents into searchable vector embeddings
Implemented semantic similarity search with 90%+ relevance in top results
Built end-to-end RAG pipeline with 2-3 second average response time
Learned practical constraints around token limits, chunking, and embedding costs

Impact on My Product Work

This hands-on experience fundamentally changed how I approach AI product decisions:

🎯 More Effective Product Conversations

With Engineers: Can discuss technical tradeoffs intelligently—understand why certain features are expensive or slow
With Designers: Can set realistic UX expectations based on actual system latency and capabilities
With Stakeholders: Explain technical constraints and tradeoffs in business terms they understand
With Customers: Demonstrate and explain AI features with confidence because I've built them myself

"Building this pipeline practically demystified RAG concepts and workflows. I went from conceptual understanding to visceral knowledge of how these systems actually work—and more importantly, where they struggle and why."

Personal Knowledge Base Use Case

Beyond the learning, I now have a functional tool that helps me:

Quickly find insights from articles I saved months or years ago
Get synthesized answers that pull from multiple sources in my collection
Rediscover forgotten knowledge by asking questions instead of keyword searching
Test new RAG techniques and optimizations on real data I care about

Key Takeaways for Product Managers

💡 Build to Understand, Not Just to Ship

The goal wasn't to create a production system—it was to deeply understand how RAG works. This learning-focused building gave me insights that reading documentation never could. As PMs, we should regularly build prototypes to maintain technical intuition and credibility with engineering teams.

💡 Technical Empathy Creates Better Products

Understanding real constraints (token limits, embedding costs, latency) makes me a better product partner. I can design features that work with technical realities rather than against them. This empathy for engineering challenges improves collaboration and reduces friction.

💡 Low-Code Tools Accelerate PM Learning

You don't need to be a senior engineer to build AI systems anymore. Tools like n8n, Make, or Zapier let PMs prototype and validate ideas quickly. The barrier to hands-on AI learning has never been lower—take advantage of it.

💡 Every AI Product Has the Same Core Challenges

Through building this, I recognized patterns that apply to any RAG-based product: data quality matters more than model size; retrieval precision beats recall; user expectations need careful management; cold start is always a challenge. These insights transfer directly to commercial product decisions.

📚 Recommendation for PMs Working on AI Products

Build something yourself. It doesn't need to be production-ready or even good. The act of building forces you to confront real constraints and make real tradeoffs. Your conversations with engineering will be better, your product decisions will be sharper, and you'll spot opportunities others miss.

Start small: Build a simple RAG system, fine-tune an open-source model, or create a basic AI agent. The technical depth you gain will compound across every AI product you work on.

Interested in Learning More? Email or Connect on LinkedIn.