Imagine a situation where the LLM does not have enough context on a feature shipped in your org's internal dashboard, or framing a defence argument in a litigation, or supporting advanced research work. This is where output quality degrades without external knowledge, and RAG steps in.

Retrieval isn't one technique; it's a family of them, each suited to different kinds of questions. Three dominate the conversation today: traditional indexing, vector RAG, and graph RAG. Picking the wrong one leads to slow systems, irrelevant answers, or wasted engineering effort. Picking the right one — or combining them well — is what separates a demo from a production-grade system.

Indexing

Indexing is the classical approach: build an inverted index mapping tokens to documents, then score matches using BM25 or TF-IDF. It's fast, cheap, and precise when exact words matter.

Vector RAG

Vector RAG encodes text as high-dimensional embeddings, so semantically similar content — even with different words — lands near each other. Retrieval is by similarity, not by token overlap.

Graph RAG

Graph RAG represents information as entities and relationships in a knowledge graph. Retrieval traverses these connections, enabling multi-hop reasoning across linked facts that plain text search cannot follow.

How they compare

The three differ along three axes: what they match on, what they cost, and what they miss.

Indexing matches literal tokens. It is blazingly fast and nearly free to operate, but linguistically blind — "car" will not retrieve a document about "automobiles." Stemming and synonym dictionaries help at the margins, but they don't scale to open-ended language.

Vector RAG matches meaning. It handles synonyms, paraphrases, and even cross-lingual queries gracefully. The trade-off is fuzziness: semantically adjacent but irrelevant results can sneak into the top-k, which is why production systems usually add a reranker. It is moderately expensive to build and run, since embeddings must be generated and stored in a vector database.

Graph RAG matches relationships. It shines when the answer requires connecting multiple entities — "which of our suppliers are also customers of our competitors?" — a question neither keywords nor embeddings can answer directly. The catch is cost: building and maintaining a knowledge graph requires entity extraction, resolution, and ongoing curation.

In practice, it's not about which one works the best. A hybrid retriever — BM25 for precision, vectors for recall, graph traversal for relational depth, and a reranker on top — consistently outperforms any single method. The real skill is knowing which layer each question needs, and investing accordingly.