RAG Architectures

Language models speak with confidence even when they are wrong. Retrieval-Augmented Generation grounds them in verified sources — but the right architecture depends on the questions you need answered.

Before you reach for exotic RAG variants, master the foundation. Standard RAG is the simplest pipeline and the benchmark every more advanced pattern is measured against.

Standard RAG treats every question in isolation — and stumbles the moment a user asks a follow-up. Conversational RAG adds a memory layer that pulls the running dialogue into every retrieval call.

Standard RAG blindly trusts whatever the vector search returns — and hallucinates the moment the matches are weak. Corrective RAG slots a quality check in between, before anything reaches the language model.

Not every question deserves the same effort. Adaptive RAG sorts queries by difficulty and sends each one down the cheapest path — from a direct LLM reply to multi-step research.

External evaluators only catch errors after the answer is already written. Self-RAG moves the critique into the model itself — through reflection tokens that let the LLM assess its own output while generating it.

Short questions and long documents live in different regions of embedding space — and that makes vector search brittle. HyDE bridges the gap by drafting a fictional answer first, then searching for real documents that resemble it.

Vector search finds similar text but never explicit relationships. GraphRAG models entities and their connections as a graph — and answers questions that require multiple hops through structured knowledge.

Users rarely phrase their questions the way the stored documents do. Fusion RAG works around this by splitting every query into several variants, searching them in parallel, and fairly merging the hits.

Comparative questions like "How does RAG variant X differ from Y?" break standard RAG. Agentic RAG splits them into sub-investigations — here is how our rag-service implementation handles that, step by step.