Retrieval-augmented generation (RAG) means your application fetches relevant documents before asking the model to answer. Instead of hoping the model "knows" your pricing, policies, or internal runbooks, you inject the right passages into the prompt. Startups hear "RAG" and picture Pinecone clusters, embedding pipelines, and sync jobs. Often v1 is much smaller.
This guide describes a minimal RAG architecture that works with any REST AI API — including a single flat-rate endpoint — and scales only when your corpus forces you to.
When you need RAG
You need retrieval when:
- Answers must cite your data (docs, tickets, contracts)
- The knowledge changes weekly and retraining is impossible
- Hallucinated policy answers create legal or support risk
You might not need RAG when:
- The feature is creative writing or code generation with no private corpus
- You have fewer than ~50 FAQ entries (a static prompt or keyword router may suffice)
Minimal v1 pipeline
1. Ingest — Split docs into chunks (~300–800 tokens) with headings preserved.
2. Embed — Call an embedding model or use a hosted embeddings API; store vectors.
3. Retrieve — On each user question, embed the query, cosine-search top *k* chunks (start with *k* = 4).
4. Generate — Send system instructions + retrieved chunks + user question to your chat model.
User question → embed query → vector DB top-k → prompt assembly → AI API chatKeep chunk text in object storage; store only ids, metadata, and vectors in the database.
Vector store choices
| Stage | Option |
|---|---|
| Prototype | SQLite + sqlite-vss or pgvector on a small Postgres |
| Early SaaS | Managed pgvector (Supabase, Neon) |
| Large corpus | Dedicated vector DB when p95 search latency or recall degrades |
Do not pick infrastructure before you measure recall on real user questions.
Prompt template that reduces hallucinations
You answer using ONLY the provided context. If the context is insufficient, say you do not know.
Context:
---
{retrieved_chunks}
---
Question: {user_message}Log when the model refuses — those queries are your content gaps.
Cost and latency
RAG adds embedding calls + search + a fatter chat prompt. Token billing charges for every retrieved chunk on every turn. Teams routinely underestimate how fast context windows fill in multi-turn chat. Read The true cost of AI APIs before assuming retrieval is "cheap."
If RAG is core to your SKU, flat-rate API access (GPT-5, Claude Sonnet 4, and Gemini 2.5 Pro) simplifies finance: you optimize recall, not invoice variance. See flat-rate vs pay-per-token.
Security
Retrieved chunks may contain secrets if your corpus is messy. Scrub PII at ingest, enforce ACLs per tenant in multi-tenant SaaS, and never let the browser call the vector index directly.
Upgrade path
1. v0 — Static FAQ in prompt (no vectors)
2. v1 — pgvector + nightly ingest
3. v2 — Hybrid search (BM25 + vectors), reranker, eval set
4. v3 — Per-tenant isolation, observability, human feedback loop
Related reading
- Building AI-powered internal tools — RAG shines for support and ops copilots
- Production-ready AI SaaS features — evals, fallbacks, and monitoring
Summary
Startups win RAG by shipping a thin retrieve-then-generate loop and measuring answer quality on real questions. Add infrastructure when recall or latency fails — not when a blog post says you need a dedicated vector platform on day one.