๐ŸŽ“Iris Courses
โ† AI App Building (No-Code & Low-Code)
Day 10 of 14

Vector Databases and RAG

What RAG Is and When You Need It

Retrieval-Augmented Generation (RAG) is a pattern for giving LLMs access to information that's not in their training data: your documents, your product's data, your customer's history. Instead of trying to cram everything into the context window, you retrieve the most relevant pieces at query time and include only those. The mechanics: (1) Embed your documents (convert them to vectors โ€” numerical representations of semantic meaning) using an embedding model. (2) Store these vectors in a vector database. (3) At query time, embed the user's question, find the nearest vectors (most semantically similar document chunks), and retrieve the source text. (4) Include the retrieved text in the Claude API call as context: 'Based on the following relevant information from our documentation, answer this question.' For BathCheck: a RAG system over NDIS pricing guide, aged care standards, and building compliance regulations would allow BathCheck to answer 'What are the NDIS funding rules for bathroom modifications?' with accurate, current information pulled from the actual documents โ€” not from Claude's potentially outdated training data.

Implementing RAG with Supabase and pgvector

Supabase's pgvector extension makes your existing Postgres database a vector store โ€” no separate infrastructure needed. The implementation: 1. Enable pgvector: `CREATE EXTENSION vector;` 2. Create embeddings table: `CREATE TABLE documents (id bigint primary key, content text, embedding vector(1536));` (1536 dimensions for OpenAI's text-embedding-3-small; 1024 for Anthropic's voyage-2) 3. Generate embeddings for your documents using the Voyage API (Anthropic's embedding models) or OpenAI's embedding API 4. Store embeddings: INSERT into documents with the content and its embedding vector 5. Query: `SELECT content, 1 - (embedding <=> query_embedding) AS similarity FROM documents ORDER BY similarity DESC LIMIT 5;` This returns the 5 most semantically similar document chunks to the user's query. Feed these 5 chunks into your Claude API call as context. The whole system can be built in a day with this stack and provides meaningful intelligence over domain-specific knowledge that LLMs alone can't provide accurately. For ShowerBuddy, a RAG system over shower safety research papers, falls prevention guidelines, and equipment specifications would allow a conversational feature: 'What shower configuration is safest for someone with Parkinson's disease?' โ€” answered accurately from the embedded research documents.

โšก Today's Action

Pick one domain-specific document that's relevant to one of your apps (NDIS pricing guide, building code relevant to bathroom modifications, OT assessment guidelines). Break it into chunks, generate embeddings using the OpenAI or Voyage API, and store them in a Supabase pgvector table. Test five queries. This is your first RAG system.

๐Ÿ’ก Pro Tip

Chunk your documents carefully before embedding โ€” 300โ€“500 token chunks with 50-token overlap between chunks gives the best retrieval quality for most use cases. Too small and you lose context; too large and each chunk covers too many topics to match a specific query accurately.