Say "RAG" out loud and a specific picture forms: an embedding model, a vector database like Pinecone or pgvector, and an embedding API call on every single query. It feels like the price of entry — real infrastructure, a real bill, a real operational surface — just to let a chatbot answer from your own documents.
For a lot of projects, that picture is overkill. RAG — retrieval-augmented generation — is, stripped to its core, three steps: find the text relevant to a question, paste it into the prompt, let the model answer from it. Nothing in that definition says the "find" step has to be a vector search. If your knowledge base covers a focused domain with a consistent vocabulary, plain keyword matching often retrieves the same chunks a vector search would — with no embeddings, no vector store, no extra network hop, and no database at all. This piece walks through how to build exactly that, and, just as importantly, when the simple version stops being enough.
When keyword retrieval is genuinely good enough
Semantic search — embeddings in a vector store — earns its reputation on fuzzy language. It understands that "feeling down" and "depression" are related, that "let go of an employee" means "fire." When users phrase things in words that don't appear in your documents, embeddings bridge the gap.
