Gnosnay 和他的硅基搭子

2025 RAG 方案回顾与展望

· Gnosnay

前段时间在给项目里的问答 agent 做 RAG 方案选型，期间调研了很多方案，这里做个回顾和总结。（可恶，和 ChatGPT 的 co-research 总结不如人意，还是得自己写。

这篇回顾我会先从「RAG 是什么」开始，介绍什么是经典 RAG、经典 RAG 的难点与挑战；然后再介绍什么是 Agentic RAG，并给出一个我目前理解里比较靠谱的 Agentic RAG 方案。

什么是 RAG

RAG（Retrieval-Augmented Generation）的目标是为 LLM 提供私域内容，规避模型幻觉。基本流程如下：

graph LR %% 定义节点样式 classDef greenBox fill:#d4edda,stroke:#333,stroke-width:1px,rx:5,ry:5; classDef yellowCyl fill:#fff3cd,stroke:#333,stroke-width:1px; classDef pinkUser fill:#f8d7da,stroke:#333,stroke-width:1px; classDef docIcon fill:#e2e6ea,stroke:#333,stroke-width:1px; classDef outputShape fill:#f3e5f5,stroke:#333,stroke-width:1px; %% 上半部分：数据入库流程 Docs[Dataset / Documents]:::docIcon EmbModel1[Embeddings<br/>Model]:::greenBox VecStore[(Vector<br/>Store)]:::yellowCyl %% 下半部分：检索与生成流程 User((User)):::pinkUser EmbModel2[Embeddings<br/>Model]:::greenBox SumModel[Summarization<br/>Model]:::greenBox FinalResult>Response]:::outputShape %% 连接线与标签 Docs -->|Content| EmbModel1 EmbModel1 -->|Document embeddings| VecStore User -->|query| EmbModel2 EmbModel2 -->|Query embeddings| VecStore VecStore -->|Relevant facts| SumModel SumModel --> FinalResult

离线阶段：

  1. 对各种文档进行 embedding 向量化
  2. 将 embedding 向量存储到向量数据库中

在线阶段：

  1. 当用户输入问题时，将问题转换为 embedding
  2. 在向量数据库中根据 embedding 向量搜索出相关文档
  3. 将检索出的文档作为上下文输入到 LLM 中，让 LLM 生成回答

这里的向量技术就是把文本变成一串数字，然后通过计算来判断相似度，类似通过向量距离的远近来判断相似与否。

经典 RAG 与传统搜索

相似之处

无论是搜索还是 RAG，线上基本都包含：

  • 数据接入 → 文本处理 → 建索引
  • Query 处理（分词/改写/扩展等）→ 召回（topN）→ 排序/重排（topK）
  • 输出（给人看 or 给模型用）

「召回 + 重排（re-rank）」是通用范式：先用高吞吐模型拿候选，再用更贵的模型精排 1 2 3 4

核心差异

索引形态与表示方式侧重点不同

传统搜索（词法为主）

  • 典型主索引是倒排索引：term → postings list（包含 docid、term 频次、位置等），用来高效做布尔检索、短语/邻近、BM25 打分等。5
  • 排序常用 BM25, 典型实现: Lucene/Elasticsearch 6

一句话介绍:

倒排索引: 构建单词 -> 文章的映射关系，用于快速检索包含某个单词的文章。

BM25 (Best Matching 25): 关键词检索算法。会根据词频（文章中出现了多少次搜索词）、IDF（逆文档频率，越少见的词权重越高）、DLN（Document Length Normalization：文档长度归一化，长文章天生更容易命中更多词，需要对过长的文档做惩罚）等指标来计算相关性。对精确匹配很有效，对语义相似度效果一般。输入是查询词 + 文档等参数，输出是相关性分数。

RAG（向量/段落为主）

  • 更常把知识库切成 chunks/passages，为每个 chunk 计算 embedding，建**向量索引（ANN）**做语义召回；也常同时保留 BM25 词法索引用于 hybrid。7

直观理解：传统搜索更像“词匹配+相关性”，RAG 更像“语义相似+证据片段”。

搜索结果目标不同

传统搜索的输出目标

  • 输出是“文档/网页列表”，最多加摘要/snippet；最终相关性由用户阅读判断。

RAG 的输出目标

  • 输出是“答案文本”；检索到的 passages 不直接展示（或部分展示），而是作为外部记忆被 LLM 消费，参与生成。RAG 的经典定义就是“检索增强生成”。7

这会带来两个实现上的必备环节：

  • Context 构建（prompt/上下文拼装）：选哪些 chunk、怎么截断、按什么顺序放入上下文窗口。
  • Grounding/引用约束：为了减少“看起来像真的”幻觉，RAG 往往要求答案可追溯到检索证据（比如强制引用、逐句引用证据）。

RAG 中 rerank 更关键

传统搜索也会用 LTR/神经重排，但 RAG 的正确性更依赖 topK 证据质量：证据错了，LLM 就会开始一本正经地胡说八道。因此 RAG 里常见：

  • bi-encoder 召回（高吞吐）→ cross-encoder 重排（高精度）8 1
  • 或 hybrid 召回后再重排（Elastic 也把这作为典型高级检索/重排管线来描述）。2 4

系统成本、延迟与数据安全

  • 成本/时延：搜索主要成本在检索与排序；RAG 还要多一段 LLM 推理（token 成本、延迟、并发压力）。
  • 数据安全：RAG 需要把检索到的文本发给模型（可能是外部服务），因此权限过滤、脱敏、审计通常更刚需；而传统搜索只要在系统内返回结果给用户即可。

RAG 中的挑战和难点

文档处理

文档格式有很多，比如 txt、pdf、docx、html、markdown 等。不同的文档格式处理方式不同。PDF 的格式不是很标准，所以处理起来比较麻烦。另外还有文档中的表格、图片等信息，都不太容易被处理。

解决方案是使用更专门的文档处理模型做针对性处理。这一步有点类似数据清洗。

chunking（文档切分）

一篇文章太长，不利于处理，所以需要把文章切分成多个 chunk。这里的挑战是：

  1. 切分之后 chunk 的上下文不完整，质量可能会降低
  2. 切分有可能会拆断一个句子

目前没有很好的解决方案来处理 chunking。一般是通过设置 chunk size 来控制 chunk 的长度。9 10

Anyscale 11 的评估中发现，chunk size 对 RAG 的性能影响非常大。但无限制调大 chunk size 会导致结果变差。

Retrieval 召回质量

召回质量毫无疑问是 RAG 中最重要的环节。召回质量决定了 RAG 的回答质量，召回质量的提升可以显著提升 RAG 的回答质量。

目前有一些方案尝试提高召回的质量：

  • LangChain 的 contextual compression 12
  • Anthropic 的 contextual retrieval 13

数据安全

目前 RAG 要求把数据集中在一起统一处理，把分散数据集中进向量库会绕过原系统访问控制，带来安全与治理负担。14 15

目前有一些方案尝试通过 Agentic RAG 的方式来进行处理，即动态从各个数据库中获取数据。

意图理解

意图理解是 RAG 中的一个重要环节，它决定了如何把用户的问题转换为 RAG 的查询。但是用户的意图可能非常复杂，或者非常隐晦，意图理解会变成一个很难的任务。

信息更新

被向量化的数据需要定期从原数据源进行更新。这一步通常是离线进行。

上下文过长

最后答案整合时，我们仍然会面临上下文过长的问题，LLM 可能会出现 lost in the middle 的问题。16

结果评估

如何衡量一个 RAG 结果的质量？这是一个非常难的问题。目前没有很好的解决方案。这个问题同样困扰着 Agent。17 18

多模态 RAG 的支持

目前 RAG 主要支持文本数据，但很多场景下需要支持多模态数据，比如图片、视频、音频等。19 20

RAG terminologies

离线输入端:

  • Corpus: 语料库，就是一堆文档、PDF、网页
  • Document: 语料库中的单个文本文件
  • Chunk: 文档切分后的文本单元。数据处理和检索的基本单位。检索、embedding 的对象都是它。
  • Text Splitter: 文本切分器，把文档切分成 chunk

离线/在线处理端:

  • Token: LLM 计数的最小单位。Chunk size 的单位就是 token 数。Token 和单词不一定是一一对应的，ChatGPT 中 1000 tokens 对应 750 个英文单词 / 400–500 汉字。
  • Embedding: Chunk 送到 Bi-Encoder 中后生成的数字向量。一个 Chunk 对应一个 Embedding。

在线检索端:

  • Context window: LLM 一次可以处理的最大 token 数。你检索出的 Top-K 个 Chunks 的总长度不能超过这个窗口限制。
  • Hit / Node：在某些框架（如 LlamaIndex）中，检索到的 Chunk 有时被称为 Node 或 Hit。

Agentic RAG

我们选择 Agentic RAG 的方式主要出于几个原因：

  • 公司内部已经有了一个 RAG 的平台了
  • 我们的数据是比较热的数据，静态的 RAG 平台不够合适
  • 我们希望可以控制用户访问数据的范围

总的来说，Agentic RAG 和 Agent 没有本质区别，都是通过 Agent 的方式来处理问题。在线流程大概是：21 22 23

  1. 意图理解: 理解用户的问题
  2. Agent 通过 Tool use 来在线 retrieve 数据
  3. Agent 分析数据进行评估, 如果评估不通过, 重新取数据进行评估, 直到评估通过为止 24 25
  4. Agent 生成回答

其中每个步骤都有海量天坑等着你踩。这里简单谈一下。传统 RAG 遇到的一些挑战，Agentic RAG 也同样会有：

  • Retrieval: Agent 中选择一个好的 Tool 来获取数据非常重要，但这一点并不简单。有些方案通过构建 multi-agent 的方式来处理 26，但这里有很多细节，比如：如何协调多个 agents？多个 agents 如何共享上下文？每个 agent 是否要重新理解意图？等等。一旦接入到 Tool，我们又会面临 Tool 的治理问题：海量 tools 如何高效选择？如何治理海量 Tool？如何接入外部系统？等等。
  • 意图理解: 老大难问题了。
  • Context management
  • Result evaluation
  • Performance: Tokens 的成本？ROI 能否打平？Latency 能否兜得住？等等。

References

  1. Using Cross-Encoders as reranker in multistage vector search. ↩︎ ↩︎

  2. Elastic：Re-ranking overview. ↩︎ ↩︎

  3. NVIDIA：Enhancing RAG Pipelines with Re-Ranking. ↩︎

  4. Advanced RAG Techniques: Hybrid Search and Re-ranking（dasroot）. ↩︎ ↩︎

  5. Pyserini BM25（DeepWiki）. ↩︎

  6. Apache Lucene Similarities（BM25 等）. ↩︎

  7. arXiv：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. ↩︎ ↩︎

  8. Sentence-Transformers：Retrieve & Re-Rank. ↩︎

  9. Weaviate：Late Chunking. ↩︎

  10. arXiv：Rethinking Chunk Size for Long-Document Retrieval. ↩︎

  11. Anyscale：A Comprehensive Guide for Building RAG-based LLM Applications Part 1. ↩︎

  12. LangChain：Contextual Compression. ↩︎

  13. Anthropic：Contextual Retrieval. ↩︎

  14. Microsoft：Enterprise-ready RAG（Azure AI Foundry Blog）. ↩︎

  15. TechRadar：RAG is dead? enterprises shifting to agent-based architectures. ↩︎

  16. arXiv：Long Context vs. RAG for LLMs. ↩︎

  17. Promptfoo：Evaluating RAG pipelines. ↩︎

  18. AIMultiple：RAG Evaluation Tools. ↩︎

  19. ACL Anthology：Multimodal Retrieval-Augmented Generation（MAGMaR 2025）. ↩︎

  20. mRAG: Elucidating the Design Space of Multi-modal Retrieval-Augmented Generation. ↩︎

  21. Azure SQL：Improve the “R” in RAG and embrace Agentic RAG. ↩︎

  22. Microsoft：Bonus Journey — Agentic RAG（Azure AI Foundry Blog）. ↩︎

  23. arXiv：Agentic Retrieval-Augmented Generation（Survey）. ↩︎

  24. arXiv：Corrective Retrieval Augmented Generation（CRAG）. ↩︎

  25. arXiv：Self-RAG. ↩︎

  26. arXiv：A Collaborative Multi-Agent Approach to RAG Across Diverse Data. ↩︎