# How to Choose the Right RAG Approach 6 ways to select RAG architecture based on data and needs - **Source:** [Hacker News (news.ycombinator.com)](https://brifing.si/source/13c923cd-6d99-442b-9b8b-1181f4d8cd91) - **Published:** 2026-08-26 - **Topic:** [Data & AI](https://brifing.si/c/data-ai) - **Original article:** - **On Brifing:** https://brifing.si/s/0e5a54b1-d01d-43ab-9698-54bab660ad00 ## Core Principle of RAG Retrieval-Augmented Generation (RAG) systems enhance AI responses by finding the most relevant documents for user queries. Today, many teams use unnecessarily complex vector databases and reranking pipelines. Simple approaches often suffice for many scenarios. For basic queries like 'how to reset my password', complex systems are overkill. ## Data Freshness Factor How frequently data updates is crucial when choosing RAG architecture. Real-time updates (news, social media) favor approaches with easy re-indexing. Weekly or monthly updates work well with hybrid methods. Stable datasets benefit from pre-computed embeddings. For example, technical documentation updated monthly justifies preprocessing. ## Dataset Characteristics The variability rate of your dataset directly impacts RAG strategy. Avoid full pre-embedding for content with >10% daily changes. Preprocessing works for stable documents. Long-tail distributions (where 90% of content is rarely accessed) favor on-the-fly processing. Archive documents rarely accessed are ideal candidates for real-time approaches. ## Query Patterns The nature of user queries determines architectural choices. Keyword-heavy queries ('pandas merge dataframe') should start with full-text search. Semantic or conversational queries ('How do I...?') benefit from embeddings. Mixed patterns require hybrid approaches. Exact matches like 'invoice #12345' absolutely need keyword search. ## Scale Performance Daily query volume dictates architectural complexity. Under 1K queries/day, simple approaches suffice. 1K-10K queries justifies selective optimization. 10K+ queries warrants full optimization. Small teams' internal document search systems often don't need complex solutions. ## Team Capabilities Teams without ML expertise should stick to full-text search with query rewriting. Some ML knowledge makes hybrid search manageable. Full ML teams can implement advanced approaches. Small startups can achieve 80% success using GPT-4o-mini for query rewriting. ## BM25: The Simplest Approach BM25 algorithm (Elasticsearch, Postgres full-text search) was the powerful solution pre-embeddings era. Ideal for keyword queries, exact matches, and proprietary terminology cases. Offers zero ML complexity, sub-10ms response times, and easy debugging. Exact matches like 'invoice #12345' don't need embeddings. ## BM25 Advantages BM25 has no API costs, works with full documents, and is easy to evaluate. No model deprecation risk (BM25 doesn't change). Perfect for proprietary terms (internal framework names). But misses synonyms ('car' vs 'automobile') and fails on semantic queries. Can't understand intent like 'how to speed up code?' ## Query Rewriting Using LLMs to transform messy user queries into clean keyword searches is effective. Most 'semantic search' problems are actually query formulation issues. At ~$0.001 per query, it removes stopwords, adds synonyms, and translates domain terms. For example, 'speed up code' becomes 'optimize performance'. ## Effective Query Rewriting With query rewriting, poor results only require system prompt adjustments for immediate testing. With embeddings, you must change chunking strategy and reprocess the entire corpus. For example, you can protect proprietary terms like internal 'Atlas' framework. General embedding models fail on proprietary terms while rewriting ensures exact matches. ## Hybrid Search Approach Using BM25 to find candidates (top 50-100) then reranking with embeddings (top 10) is powerful. BM25 excels at fast keyword matching while embeddings understand semantics. Ideal for semantic questions ('alternatives to X'), 100-500ms latency tolerance, and stable corpora. Mixed query patterns benefit from both methods' strengths. ## Choosing the Right RAG Strategy Selecting RAG architecture requires considering data characteristics, query patterns, scale, and team capabilities. Progress from simple to complex, increasing complexity only when proven necessary. In many cases, simple full-text search with query rewriting outperforms expensive complex systems. Using the right tool for the right problem applies to RAG too. ## Sources covering this story - https://www.lighthousenewsletter.com/p/rag-is-simpler-than-you-think — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._