Naive-RAG-First
Reaching for a vector store before checking whether the answer lives in a database, API, or system prompt.
Intent & Description
🎯 Intent
Defaulting to semantic search over a vector index because it’’s the field’’s go-to architecture — before checking where the answer-bearing knowledge actually lives.
📋 Context
Teams build knowledge-grounded agents and reach for RAG first. Often the real source is a database, an internal API, a search service, or a small stable document set that would fit in the system prompt. The vector index gets built anyway.
💡 Solution
Ask first — does the knowledge live in a tool (database, API, search service)? In a scoped system prompt? In a small inlinable document? Only adopt RAG when those options genuinely don’’t work. See tool-use, naive-rag.
Real-world Use Case
- Never use this; check whether the knowledge belongs in a tool, database, or scoped prompt before adopting RAG.
- Use tool-use when the knowledge lives behind an API or database query.
- Adopt naive-rag only when simpler retrieval stores genuinely don’’t work.
Source
📌 TL;DR
Check if knowledge belongs in a tool, prompt, or database before paying for the complexity of a RAG pipeline.
Disadvantages
- Architectural complexity that pays for nothing
- Retrieval misses that a SQL query would not
- Embedding pipeline maintenance burden for knowledge that barely changes