Owain Lewis RAG Retrieval Strategy Selector

Last updated: 28 August 2026

Given any AI data-retrieval problem, select and implement the correct RAG strategy from six production-tested approaches so the LLM gets exactly the right information to answer any question.

// TL;DR

The Owain Lewis RAG Retrieval Strategy Selector is a decision framework for choosing the correct RAG (Retrieval Augmented Generation) approach from six production-tested strategies: Document Loading, Full-Text Search, Vector Search, Hybrid Search, SQL RAG, and Agentic RAG. Use it whenever you're building an AI agent or LLM feature that needs to connect to business data — documents, databases, or both. Instead of defaulting to Vector Search for everything, you diagnose your data shape and question type, then apply a decision tree to pick the strategy that actually fits, avoiding wrong results from mismatched retrieval methods.

Framework

// When should you use the RAG Retrieval Strategy Selector?

Use this skill whenever you are building or designing an AI agent or LLM-powered feature that needs to connect to business data — documents, databases, or both. Trigger it the moment someone asks 'how should my AI find information?' or 'which retrieval approach should I use?'

// What do you need before selecting a RAG strategy?

Question or query typerequired
What kind of question will users be asking? (e.g. policy lookup, product search, compound question)
Data shaperequired
Where does the information live? Options: flat documents (PDFs, text files), structured SQL database, or both.
Scale of datarequired
Roughly how many documents or records? A handful vs. thousands changes the viable strategies.
Latency tolerance
Is this customer-facing (low latency required) or internal tooling (latency more acceptable)?
Filter requirements
Does the query involve exact filters like price, brand, date, or rating?

// What core principles guide RAG strategy selection?

Retrieve, Augment, Generate

RAG means: go get some information (Retrieve), add that information to a prompt (Augment), then produce an answer (Generate). The most important part is the retrieval — everything else is downstream of getting the right information.

No Perfect Strategy

There is no single perfect RAG strategy. Every approach has different pros, cons, and tradeoffs. Choose the strategy that makes sense for your particular problem and your particular data.

Underrated Reliability of Simple Approaches

Document Loading is often dismissed as naive or not scalable, but it is surprisingly reliable and relatively underrated. Always consider whether the simplest approach solves the problem before adding complexity.

Keyword Search vs. Meaning Search

Full-Text Search finds what you said; Vector Search finds what you meant. Full-Text Search breaks down when synonyms or semantics matter. Vector Search breaks down when exact values (price, brand) are the filter.

Hybrid Search as the Safe Default

If you are not sure which approach to use in production, Hybrid Search — combining Full-Text Search and Vector Search via Reciprocal Rank Fusion — is a commonly used default that covers both keyword precision and semantic breadth.

SQL RAG is Underrated

Most information in a typical business lives in a database, not in documents. SQL RAG — querying a structured database — is a really powerful and reliable strategy that does not get talked about enough.

Agentic RAG for Compound Questions

When a single question requires information from multiple data sources or multiple retrieval types, give an AI agent all the retrieval tools and let it decide which to invoke. The tradeoff is latency and non-determinism.

// How do you select and implement a RAG strategy step by step?

1
Identify the data shape and question type
Ask: Is the data in documents (unstructured text) or a database (structured/SQL), or both? Is the question a simple lookup, a semantic search, a filter query, or a compound question spanning multiple sources? This diagnosis drives every subsequent decision.
2
Apply the Strategy Selection Decision Tree
Work through these gates in order: 1. Is the full content of a document needed to answer correctly (e.g. step-by-step runbook, checklist, recipe, policy)? → Use DOCUMENT LOADING. 2. Is the data in a SQL database and does the query involve exact filters (price, brand, category, rating)? → Use SQL RAG (predefined queries for customer-facing; dynamic LLM-generated queries for internal/analytics). 3. Is the query purely keyword-based with no synonym requirement? → Use FULL-TEXT SEARCH. 4. Is the query semantic — searching by meaning, not exact words? → Use VECTOR SEARCH. 5. Does the query mix keywords AND meaning (e.g. brand name + comfort descriptor)? → Use HYBRID SEARCH (Full-Text + Vector via Reciprocal Rank Fusion). 6. Is the question compound — requiring information from multiple sources or multiple retrieval types? → Use AGENTIC RAG.
3
Configure Document Loading (if selected)
Choose between two sub-strategies: (a) Naive — read the file directly and insert full content into the prompt. Simple, accurate, uses more tokens. (b) Index-based — maintain an index of filenames + descriptions, use an LLM to select the right document first, then load it. Slower but scales to larger document sets. Use Naive when documents are few; use Index when documents are many.
4
Configure Full-Text Search (if selected)
Use the database's built-in full-text search engine (e.g. TS Vector / TS Query in PostgreSQL — no extra infrastructure needed). Convert query terms to root forms (stemming) so 'running' matches 'runner' and 'runs'. Use the contains operator to filter records. Warn the user: this breaks down when synonyms or semantic meaning matter.
5
Configure Vector Search (if selected)
Pipeline: (1) Parse documents using a document loader (e.g. Docling). (2) Break documents into smaller parts called chunks. (3) Embed each chunk into a vector using an embedding model (e.g. OpenAI embeddings). (4) Store vectors in a vector database (e.g. PGVector extension on PostgreSQL). (5) At query time, embed the user query, measure distance between query vector and stored vectors (smaller distance = more similar meaning), return the closest matches. Warn the user: Vector Search cannot handle exact value filters like price or brand — it may return a $200 shoe when asked for shoes under $100.
6
Configure Hybrid Search (if selected)
Run Full-Text Search and Vector Search in parallel on the same query. Combine results using Reciprocal Rank Fusion (RRF) to produce a single ranked list. This is the recommended default when unsure, because it captures both keyword precision and semantic breadth.
7
Configure SQL RAG (if selected)
Choose between two sub-strategies: (a) Predefined queries — write parameterised SQL queries ahead of time (e.g. 'find products where brand = ? AND price < ?'), extract parameters from the natural language question, inject them, execute. Reliable and deterministic. Preferred for customer-facing products. (b) Dynamic LLM-generated queries — pass the database schema to an LLM and let it write the SQL at runtime. Very powerful for ad hoc analysis, internal dashboards, and reporting. More non-deterministic and risky — avoid on customer-facing surfaces.
8
Configure Agentic RAG (if selected)
Give the AI agent access to all relevant retrieval tools: Document Loading, Full-Text Search, Vector Search, SQL RAG (predefined and/or dynamic). Provide the agent with the database schema so it understands the data structure. The agent inspects the question, decides which tool(s) to invoke, executes them, evaluates results, and self-corrects if needed (e.g. searches one place, realises it is wrong, retries elsewhere). Accept the latency tradeoff. Prefer this pattern for internal tooling or complex multi-source questions; be cautious on customer-facing products due to non-determinism.
9
Validate the chosen strategy against known failure modes
Before finalising: (1) Document Loading — do you know which document to load? If the document set is large and undifferentiated, use the index sub-strategy or switch to Vector Search. (2) Full-Text Search — are synonyms or paraphrases likely in the query? If yes, add Vector Search (Hybrid). (3) Vector Search — does the query include exact value filters? If yes, add SQL RAG or Full-Text. (4) SQL RAG dynamic — is this customer-facing? If yes, strongly prefer predefined queries. (5) Agentic RAG — is latency a hard constraint? If yes, consider pre-selecting the right single strategy instead.

// What are real examples of each RAG strategy in action?

A SaaS company wants its support chatbot to answer questions about its refund and shipping policies stored in two PDF documents.

Use Document Loading. Since there are only two documents and the full policy text is needed to answer correctly, load the entire relevant document into the prompt. Add an index sub-strategy (filename + description) so the LLM can select the right document (refund policy vs. shipping policy) before loading, avoiding unnecessary token usage.

An e-commerce store wants users to search for products by brand name (e.g. 'Show me Nike shoes').

Use Full-Text Search. Brand name is an exact keyword match. PostgreSQL's built-in TS Vector / TS Query handles this without additional infrastructure. Apply stemming so 'running' also matches 'runner'. No need for vector embeddings here.

A shoe retailer wants to surface products semantically relevant to 'comfortable shoes for long-distance running' even when product descriptions use words like 'cushioned midsole' or 'marathon-ready'.

Use Vector Search. Chunk the product catalogue, embed chunks with an embedding model, store in PGVector. At query time, embed the user query and retrieve chunks by vector distance. The system finds 'cushioned midsole, designed for marathon training' even though the word 'comfortable' never appears.

A retailer's search bar must handle queries like 'Nike running shoes comfortable for distance' — requiring both brand-name precision and semantic comfort matching.

Use Hybrid Search. Run Full-Text Search to find records containing 'Nike', run Vector Search to find semantically comfort/distance-related records, combine both result sets using Reciprocal Rank Fusion to produce the final ranked list.

A customer asks 'Show me running shoes under $100 with at least four stars.' Products live in a SQL database.

Use SQL RAG with predefined queries. Define a parameterised SQL query: SELECT * FROM products WHERE category = ? AND price < ? AND rating >= ?. Extract parameters (category=running, max_price=100, min_rating=4) from the natural language query using an LLM, inject into the template, execute. Deterministic and reliable.

An internal analytics team wants to ask ad hoc questions like 'Which product categories have average ratings below 3.5 this quarter?' against a large product database.

Use SQL RAG with dynamic LLM-generated queries. Provide the database schema to the LLM, let it construct the SQL at runtime. Acceptable here because this is an internal tool where non-determinism is manageable and the power of flexible querying outweighs the risk.

A customer asks: 'I want running shoes under $150 — and what's your return policy if they don't fit?'

Use Agentic RAG. This is a compound question requiring two different retrieval types: SQL RAG (product filter by price/category) and Document Loading (returns policy document). Give the agent both tools. The agent analyses the question, invokes the product filter SQL tool for the shoe search, invokes the document loader for the returns policy, combines both results into a single coherent answer.

// What mistakes should you avoid when choosing a RAG strategy?

Dismissing Document Loading as naive — it is surprisingly reliable and underrated, especially for full policy documents, runbooks, checklists, or recipes where partial retrieval breaks the answer.
Using Vector Search for exact value filters (price, brand, date) — it may return semantically similar but factually wrong results (e.g. a $200 shoe when the user asked for under $100).
Using Full-Text Search when synonyms or semantic meaning matter — 'comfortable' will not match 'cushioned' or 'supportive', causing missed results.
Deploying dynamic LLM-generated SQL queries on customer-facing products — this is non-deterministic, harder to control, and carries risk. Reserve dynamic SQL RAG for internal tooling and analytics.
Defaulting to Vector Search for every problem — it is the most well-known approach but is the wrong tool when keyword precision or structured filters are required.
Ignoring Hybrid Search — when unsure which single strategy to use in production, Reciprocal Rank Fusion over Full-Text + Vector is the recommended default, not a coin-flip between the two.
Underestimating Agentic RAG latency — the agent must make multiple tool-selection decisions and may retry on failure; do not use this pattern where response speed is a hard constraint.
Failing to give the agent the database schema in Agentic RAG — without schema context, the agent cannot construct useful queries or select the right tools.

// What are the key RAG terms you need to know?

RAG (Retrieval Augmented Generation): The pattern of Retrieving information from a data source, Augmenting a prompt with that information, and then Generating a response with an LLM. The retrieval step is the most important part.
Document Loading: A RAG strategy where an entire document is read and inserted directly into the LLM prompt. Can use a naive (load all) or index-based (LLM selects the right document first) sub-strategy.
Full-Text Search: A keyword-based retrieval strategy using the database's built-in search engine (e.g. TS Vector / TS Query in PostgreSQL). Searches by exact words and stems; does not understand meaning.
Vector Search: A semantic retrieval strategy where documents are broken into chunks, embedded into vectors, and stored in a vector database. Queries are also embedded and matched by vector distance — finding meaning, not just words.
Chunks: The smaller parts that a document is broken into before embedding for Vector Search. Each chunk is independently embedded and stored.
Embeddings: Numerical vector representations of text produced by an embedding model. Similar meanings produce vectors that are close together in vector space.
PGVector: A PostgreSQL extension that adds vector storage and similarity search to a standard PostgreSQL database, enabling Vector Search without a separate vector database.
Hybrid Search: A RAG strategy that runs Full-Text Search and Vector Search simultaneously and combines their results using Reciprocal Rank Fusion. The recommended default when the best single strategy is unclear.
Reciprocal Rank Fusion (RRF): An algorithm used in Hybrid Search to merge ranked result lists from Full-Text Search and Vector Search into a single, unified ranked list.
SQL RAG: A RAG strategy that retrieves information by querying a structured SQL database. Can use predefined parameterised queries (deterministic, customer-safe) or dynamic LLM-generated queries (powerful, non-deterministic, internal use).
Predefined Queries: SQL queries written ahead of time with parameter placeholders (e.g. price, brand, category). The LLM extracts parameter values from the natural language question; the query structure never changes. Preferred for customer-facing products.
Dynamic LLM-generated Queries: SQL queries constructed at runtime by an LLM given the database schema. Powerful for ad hoc and analytical use cases but non-deterministic; recommended for internal tools only.
Agentic RAG: A RAG strategy where an AI agent is given multiple retrieval tools (Document Loading, Full-Text Search, Vector Search, SQL RAG) and autonomously decides which tool(s) to invoke based on the question. Suited to compound questions requiring multiple data sources.
Compound Question: A question that requires retrieving information from more than one data source or using more than one retrieval strategy to answer fully (e.g. 'Find me shoes under $150 AND tell me the returns policy').
Docling: A document parsing library referenced by the creator for breaking documents into chunks prior to embedding in a Vector Search pipeline.

// FREQUENTLY ASKED QUESTIONS

What is RAG and how does it work?

RAG (Retrieval Augmented Generation) means retrieving information from a data source, augmenting an LLM prompt with that information, then generating an answer. The retrieval step is the most important part — everything downstream depends on getting the right information in front of the model. If retrieval returns wrong or incomplete data, the LLM's answer will be wrong too.

What are the different types of RAG strategies?

There are six production-tested RAG strategies: Document Loading (insert full documents), Full-Text Search (keyword matching), Vector Search (semantic meaning), Hybrid Search (Full-Text plus Vector combined via Reciprocal Rank Fusion), SQL RAG (querying structured databases), and Agentic RAG (an agent picks tools autonomously). There's no single perfect strategy — each has tradeoffs, so you choose based on your data shape and question type.

How do I choose the right RAG strategy for my project?

Diagnose two things first: your data shape (documents, SQL database, or both) and your question type (lookup, semantic search, filter query, or compound). Then apply a decision tree: full document needed → Document Loading; exact filters in SQL → SQL RAG; keyword-only → Full-Text; meaning-based → Vector; mixed keyword and meaning → Hybrid; multi-source → Agentic RAG.

How do I implement Vector Search for my documents?

Parse documents with a loader like Docling, break them into chunks, embed each chunk into a vector using an embedding model, and store vectors in a vector database like PGVector. At query time, embed the user's query and return the chunks with the smallest vector distance. Warning: Vector Search can't handle exact filters like price or brand — it may return a $200 shoe when asked for shoes under $100.

How does Vector Search compare to Full-Text Search?

Full-Text Search finds what you said; Vector Search finds what you meant. Full-Text matches exact keywords and stems (so 'running' matches 'runner') but breaks down when synonyms matter — 'comfortable' won't match 'cushioned.' Vector Search understands meaning but breaks down on exact value filters like price or brand. When you need both, use Hybrid Search combining them via Reciprocal Rank Fusion.

When should I use SQL RAG instead of Vector Search?

Use SQL RAG when your data lives in a structured database and queries involve exact filters like price, brand, category, date, or rating. Most business information actually lives in a database, not documents, making SQL RAG underrated. For customer-facing products use predefined parameterised queries; for internal analytics, dynamic LLM-generated queries offer flexible ad hoc reporting.

What is Hybrid Search and why is it the recommended default?

Hybrid Search runs Full-Text Search and Vector Search in parallel on the same query, then merges results using Reciprocal Rank Fusion (RRF) into one ranked list. It's the recommended default when you're unsure which single strategy to use in production because it captures both keyword precision and semantic breadth, covering queries like 'Nike running shoes comfortable for distance.'

What is Agentic RAG and when do I need it?

Agentic RAG gives an AI agent access to all retrieval tools — Document Loading, Full-Text, Vector, SQL RAG — and lets it decide which to invoke based on the question. Use it for compound questions spanning multiple sources, like 'Show me shoes under $150 and what's your return policy?' The tradeoff is latency and non-determinism, so be cautious on customer-facing surfaces.

Is Document Loading too naive to use in production?

No — Document Loading is surprisingly reliable and underrated, especially for full policy documents, runbooks, checklists, or recipes where partial retrieval breaks the answer. For small document sets, load the full content directly. For larger sets, use an index sub-strategy where an LLM first selects the right document by filename and description before loading it. Always consider the simplest approach first.

What results can I expect from picking the right RAG strategy?

You'll get an LLM that receives exactly the right information to answer accurately, avoiding common failures like returning a $200 shoe when asked for under $100, or missing 'cushioned' results when searching 'comfortable.' Matching strategy to data shape reduces wrong answers, controls latency for customer-facing features, and keeps token usage efficient compared to defaulting to Vector Search for everything.

Why shouldn't I just use Vector Search for everything?

Vector Search is the most well-known approach but it's the wrong tool when keyword precision or structured filters matter. It can't handle exact values like price, brand, or date — it may return semantically similar but factually wrong results. It also misses purely keyword queries where Full-Text is cleaner. Defaulting to Vector Search for every problem causes avoidable retrieval failures.

What information do I need before choosing a RAG strategy?

You need the question or query type (policy lookup, product search, compound question), the data shape (flat documents, SQL database, or both), and the scale of data (a handful versus thousands of records). Optionally, know your latency tolerance (customer-facing versus internal) and whether queries involve exact filters like price, brand, date, or rating.

// GET THIS SKILL — FREE