RAG — retrieval-augmented generation — is the technique that lets an AI answer questions about your own documents: it searches them first, then reads the best matches to compose an answer. Most teams build this the hard way, jumping straight to vector databases and reranking pipelines. Rafael Pierre’s essay argues that’s usually backwards: a plain keyword search handles a surprising share of real queries, and you should only climb the complexity ladder when you have data proving you need to.

He lays out six architectures, from minimal to elaborate:

  • Full-text search only. Classic keyword matching (BM25, Elasticsearch, Postgres full-text). Zero ML, fast, easy to debug, no chunking headaches. Underrated — handles many use cases outright.
  • LLM query rewriting. A cheap AI rewrites messy user questions into clean keyword searches (“how do I fix bugs” → “debugging”). Most “semantic search” problems are really query formulation problems. Iterate by editing a system prompt instead of re-embedding everything.
  • Hybrid search. Keyword search pulls 50-100 candidates, embeddings pick the top 10. Covers both exact-match and meaning-based queries. The real cost is latency (200-500ms), not money.
  • On-the-fly embedding. Embed documents at query time instead of pre-indexing. Perfect freshness, and switching embedding models is a one-line change — pre-indexed systems get stuck re-embedding millions of documents when a model is deprecated.
  • Hot/cold tiers. Pre-embed the 20% of documents that get 80% of traffic; embed the rest on demand. Best balance for most real systems.
  • Full pre-embedding. The scale play for huge, stable corpora at high query volume — and the most painful when your embedding model is retired.

His rough 80/20 rule: about 60% of systems should stop at full-text plus query rewriting. Only 5% genuinely need custom solutions. “Don’t be the person who builds the 5% solution for a 60% problem.”

The piece is a useful counterweight to the default move of reaching for AI machinery first. The decision framework — data freshness, how often documents change, query patterns, scale, team skills — gives you concrete reasons to pick each level, and the cost math (roughly 15x cheaper to decompose a compound query into sub-queries than to throw it whole at an LLM) grounds the advice in numbers. Worth reading before your next “we need a vector database” conversation.