Building a RAG System from Scratch — Wrap-up and What Comes Next

A developer built a complete RAG system from scratch using pgvector, Gemini embeddings, and MCP, covering setup, indexing, ingestion, search, and multi-step agents. The series concluded with deployment on Render and Supabase, and outlined next steps including evaluation, observability, security, and governance.

In this final article, we'll recap what we built across the series, consolidate the design decisions, and point to where to go next. Starting from a blank Python project, we built a complete AI system step by step: 01 setup db.py pgvector table + extension 02 create index.py HNSW index m=16, ef construction=64 03 ingest.py Embed documents → store in pgvector 04 search.py Cosine similarity search 05 rag.py Full RAG pipeline 06 tool basic.py LLM decides whether to search 07 tool multi.py LLM routes between multiple tools 08 tool agent.py Multi-step agentic loop 09 agent basic.py ReAct pattern 10 agent memory.py Persistent memory across sessions 11 agent planner.py Plan → Execute → Evaluate mcp server/ server.py MCP server stdio, Claude Desktop server http.py MCP server HTTP server render.py MCP server Render deployment 12 mcp agent.py Agent via MCP local 13 mcp http agent.py Agent via MCP cloud pgvector integrates with existing PostgreSQL, supports SQL + vector in one query, and handles millions of documents comfortably. Start here and migrate only when you have evidence you need to. gemini-embedding-001 outputs 3072 dims by default, but pgvector's HNSW index has a 2000-dim hard limit. 768 dims stays well within bounds with negligible quality loss. task type Use RETRIEVAL DOCUMENT when storing, RETRIEVAL QUERY when searching. The Gemini embedding model is trained to map queries toward documents, not to the same point. Using the same task type for both degrades retrieval accuracy. HNSW requires no training data, delivers consistent recall at scale, and is faster at query time. IVFFlat is only worth considering under tight memory constraints. The LLM selects tools based on their description field. Precise, distinguishing descriptions produce correct tool selection. Vague descriptions produce random behavior. Each tool call and result gets appended to contents . The LLM reads the full history on every step — this is how multi-step reasoning works. MCP turns hardcoded functions into a standalone server. Claude Desktop, Gemini agents, and any future client can connect to the same server without duplicating tool definitions. Render's free web service hosts the MCP server. Supabase's free tier hosts pgvector. The Connection Pooler port 6543 is mandatory — Render doesn't support the IPv6 used by Supabase's standard port 5432. Local: Claude Desktop ↓ stdio mcp server/server.py ↓ psycopg2 pgvector Docker Cloud: Python agent 13 mcp http agent.py ↓ HTTPS Render server render.py ↓ PostgreSQL + SSL port 6543 Supabase pgvector ↓ Gemini Embedding + LLM This series focused on getting a production-ready RAG system off the ground. Several important topics are out of scope here: Evaluation Evals — How do you know if your RAG is actually working? You need automated quality measurement: Context Recall, Answer Relevancy, and Faithfulness scoring. Observability — When something goes wrong in production, how do you debug it? Tracing each step with a tool like Langfuse tells you exactly where latency or quality issues originate. Security — How do you handle adversarial inputs? Prompt injection, jailbreaks, and PII leakage are real threats in any public-facing RAG system. MLOps / LLMOps — How do you ship changes safely? Prompt versioning, CI/CD quality gates, and API cost tracking become essential when the system is in production. Fine-tuning — When the base model doesn't behave the way you need, LoRA fine-tuning lets you adapt it to your domain with surprisingly little data and compute. Multi-Agent Systems — When a single agent isn't enough, orchestrator-worker patterns distribute work across specialized agents. Governance — The EU AI Act is now fully in force. Compliance for a chatbot system means AI disclosure notices, audit logging, and a documented risk assessment. All of these are covered in Vol.2 of this series. The second series picks up where this one leaves off — taking a working RAG system and making it production-grade. AI Production Operations Guide https://zenn.dev/hkame/books/ai-architect-production Japanese — English Dev.to series coming soon | Chapter | Topic | |---|---| | 1 | What "production" actually means | | 2 | Evals — automated quality measurement | | 3 | Observability with Langfuse v4 | | 4 | Security — guardrails and prompt injection defense | | 5 | MLOps / LLMOps — CI/CD pipeline | | 6 | Fine-tuning with LoRA | | 7 | Multi-Agent: orchestrator-worker pattern | | 8 | Governance — EU AI Act compliance | | 9 | Wrap-up | Everything built in this series is in one repository: github.com/qameqame/pgvector-tutorial https://github.com/qameqame/pgvector-tutorial The README covers setup, directory structure, and the reasoning behind each design decision. Thanks for following along. If you found this useful, the GitHub repo and Vol.2 are the best places to continue.