给 AI 工程师的 8 种 RAG 架构：
（含用法详解）
1) Naive RAG (基础 RAG)
- 纯粹基于查询 embedding 和存储 embedding 之间的向量相似度进行检索。
- 最适合语义匹配就能搞定的简单事实类查询。
2) Multimodal RAG (多模态 RAG)
- 通过跨模态嵌入和检索，处理多种数据类型（文本、图片、音频等）。
- 适合跨模态任务，比如同时用文本和图片上下文来回答问题。
3) HyDE (假设文档嵌入)
- 针对查询与文档语义不相似的情况。
- 在检索前先根据问题生成一份“假设性答案文档”。
- 用这份生成文档的 embedding 去找更相关的真实文档。
4) Corrective RAG (纠偏 RAG)
- 通过与可信源（如网页搜索）对比来验证检索结果。
- 确保信息准确且不过时，在交给 LLM 之前先过滤或修正内容。
5) Graph RAG (图 RAG)
- 将检索内容转为知识图谱，捕捉实体间的关系。
- 通过提供结构化上下文和原始文本，增强 LLM 的推理能力。
6) Hybrid RAG (混合 RAG)
- 在同一个 pipeline 中结合向量检索和图检索。
- 当任务同时需要非结构化文本和结构化关系数据时非常管用。
7) Adaptive RAG (自适应 RAG)
- 动态判断查询是需要直接检索，还是需要多步推理链。
- 将复杂问题拆解成子查询，以提升覆盖率和准确性。
8) Agentic RAG (智能体 RAG)
- 利用具备规划、推理（ReAct、CoT）和记忆能力的 AI Agent 来协调多源检索。
- 适合需要工具调用、外部 API 或组合多种 RAG 技术的复杂工作流。
这里的大多数架构都涉及检索时的决策逻辑。但它们都是跑在已有的索引之上的。
如果索引阶段切出来的 chunk 很乱，那所有架构都会受影响。优化索引是独立于这 8 种架构之外的另一个课题。
我写了一篇关于优化索引单元的文章。该技术：
- 语料库体积缩小 40 倍。
- 单次查询 token 消耗降低 3 倍。
- 向量搜索相关性提升 2.3 倍。
而且完全不需要改动检索算法、重排序（reranker）或 embedding 模型。
点击下方引用的文章阅读全文。
（含用法详解）
1) Naive RAG (基础 RAG)
- 纯粹基于查询 embedding 和存储 embedding 之间的向量相似度进行检索。
- 最适合语义匹配就能搞定的简单事实类查询。
2) Multimodal RAG (多模态 RAG)
- 通过跨模态嵌入和检索，处理多种数据类型（文本、图片、音频等）。
- 适合跨模态任务，比如同时用文本和图片上下文来回答问题。
3) HyDE (假设文档嵌入)
- 针对查询与文档语义不相似的情况。
- 在检索前先根据问题生成一份“假设性答案文档”。
- 用这份生成文档的 embedding 去找更相关的真实文档。
4) Corrective RAG (纠偏 RAG)
- 通过与可信源（如网页搜索）对比来验证检索结果。
- 确保信息准确且不过时，在交给 LLM 之前先过滤或修正内容。
5) Graph RAG (图 RAG)
- 将检索内容转为知识图谱，捕捉实体间的关系。
- 通过提供结构化上下文和原始文本，增强 LLM 的推理能力。
6) Hybrid RAG (混合 RAG)
- 在同一个 pipeline 中结合向量检索和图检索。
- 当任务同时需要非结构化文本和结构化关系数据时非常管用。
7) Adaptive RAG (自适应 RAG)
- 动态判断查询是需要直接检索，还是需要多步推理链。
- 将复杂问题拆解成子查询，以提升覆盖率和准确性。
8) Agentic RAG (智能体 RAG)
- 利用具备规划、推理（ReAct、CoT）和记忆能力的 AI Agent 来协调多源检索。
- 适合需要工具调用、外部 API 或组合多种 RAG 技术的复杂工作流。
这里的大多数架构都涉及检索时的决策逻辑。但它们都是跑在已有的索引之上的。
如果索引阶段切出来的 chunk 很乱，那所有架构都会受影响。优化索引是独立于这 8 种架构之外的另一个课题。
我写了一篇关于优化索引单元的文章。该技术：
- 语料库体积缩小 40 倍。
- 单次查询 token 消耗降低 3 倍。
- 向量搜索相关性提升 2.3 倍。
而且完全不需要改动检索算法、重排序（reranker）或 embedding 模型。
点击下方引用的文章阅读全文。
8 RAG architectures for AI Engineers:
(explained with usage)
1) Naive RAG
- Retrieves documents purely based on vector similarity between the query embedding and stored embeddings.
- Works best for simple, fact-based queries where direct semantic matching suffices.
2) Multimodal RAG
- Handles multiple data types (text, images, audio, etc.) by embedding and retrieving across modalities.
- Ideal for cross-modal retrieval tasks like answering a text query with both text and image context.
3) HyDE (Hypothetical Document Embeddings)
- Queries are not semantically similar to documents.
- This technique generates a hypothetical answer document from the query before retrieval.
- Uses this generated document’s embedding to find more relevant real documents.
4) Corrective RAG
- Validates retrieved results by comparing them against trusted sources (e.g., web search).
- Ensures up-to-date and accurate information, filtering or correcting retrieved content before passing to the LLM.
5) Graph RAG
- Converts retrieved content into a knowledge graph to capture relationships and entities.
- Enhances reasoning by providing structured context alongside raw text to the LLM.
6) Hybrid RAG
- Combines dense vector retrieval with graph-based retrieval in a single pipeline.
- Useful when the task requires both unstructured text and structured relational data for richer answers.
7) Adaptive RAG
- Dynamically decides if a query requires a simple direct retrieval or a multi-step reasoning chain.
- Breaks complex queries into smaller sub-queries for better coverage and accuracy.
8) Agentic RAG
- Uses AI agents with planning, reasoning (ReAct, CoT), and memory to orchestrate retrieval from multiple sources.
- Best suited for complex workflows that require tool use, external APIs, or combining multiple RAG techniques.
Most architectures here involve some form of retrieval-time decision. But they all run on top of whatever was already indexed.
If that indexing step outputs messy chunks, every architecture inherits them. Improving it is a separate problem from the 8 above.
I wrote about a better unit for the indexing step. The technique:
- cuts corpus size by 40x.
- reduces tokens per query by 3x.
- improves vector search relevance by 2.3x.
And it doesn't alter the retrieval algorithm, the reranker, or the embedding model.
Read it in the article quoted below.
(explained with usage)
1) Naive RAG
- Retrieves documents purely based on vector similarity between the query embedding and stored embeddings.
- Works best for simple, fact-based queries where direct semantic matching suffices.
2) Multimodal RAG
- Handles multiple data types (text, images, audio, etc.) by embedding and retrieving across modalities.
- Ideal for cross-modal retrieval tasks like answering a text query with both text and image context.
3) HyDE (Hypothetical Document Embeddings)
- Queries are not semantically similar to documents.
- This technique generates a hypothetical answer document from the query before retrieval.
- Uses this generated document’s embedding to find more relevant real documents.
4) Corrective RAG
- Validates retrieved results by comparing them against trusted sources (e.g., web search).
- Ensures up-to-date and accurate information, filtering or correcting retrieved content before passing to the LLM.
5) Graph RAG
- Converts retrieved content into a knowledge graph to capture relationships and entities.
- Enhances reasoning by providing structured context alongside raw text to the LLM.
6) Hybrid RAG
- Combines dense vector retrieval with graph-based retrieval in a single pipeline.
- Useful when the task requires both unstructured text and structured relational data for richer answers.
7) Adaptive RAG
- Dynamically decides if a query requires a simple direct retrieval or a multi-step reasoning chain.
- Breaks complex queries into smaller sub-queries for better coverage and accuracy.
8) Agentic RAG
- Uses AI agents with planning, reasoning (ReAct, CoT), and memory to orchestrate retrieval from multiple sources.
- Best suited for complex workflows that require tool use, external APIs, or combining multiple RAG techniques.
Most architectures here involve some form of retrieval-time decision. But they all run on top of whatever was already indexed.
If that indexing step outputs messy chunks, every architecture inherits them. Improving it is a separate problem from the 8 above.
I wrote about a better unit for the indexing step. The technique:
- cuts corpus size by 40x.
- reduces tokens per query by 3x.
- improves vector search relevance by 2.3x.
And it doesn't alter the retrieval algorithm, the reranker, or the embedding model.
Read it in the article quoted below.
33
57
384
25.9K
