结合Agent的RAG技术梳理【详细版】

Agent的RAG技术

研究时间：2026年4月15日 | 所属领域：人工智能 | 研究对象类型：技术概念/技术范式

文章目录

Agent的RAG技术

什么是RAG

Agent的RAG（Retrieval-Augmented Generation）技术是一种将检索增强生成与智能体（Agent）相结合的AI范式，它让Agent能够自主判断何时检索、如何检索、以及如何将检索结果整合到推理过程中，从而突破大语言模型的知识边界，实现更准确的问答和更可靠的决策。

关键节点

起源：一个看似简单的想法

RAG的故事要从2020年说起。

那时候，大语言模型已经展现出惊人的能力，但一个致命的问题始终困扰着研究者------模型的"幻觉"。模型会一本正经地胡说八道，因为它所依赖的知识都"记忆"在参数中，而这些参数有截止日期，有模糊边界，更有可能是错的。

Patrick Lewis当时在Facebook AI Research（现在的Meta AI）工作。他和团队思考的问题是：能不能让模型像人类一样，在不确定的时候去"查资料"？

这想法听起来很简单，甚至有点朴素。但要把它变成一个可工作的系统，需要解决一连串技术难题。比如：怎么判断什么时候该查？查什么？查到的东西怎么用？用什么查？

这些问题，Lewis他们在2020年的论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》里给出了答案。这篇论文发表在NeurIPS 2020，正式确立了RAG这个范式。

但RAG不是凭空出现的。它站在好几个巨人的肩膀上。

前置技术：层层积累的基石

要理解RAG为什么在2020年诞生，需要往前看几年。

2013年，Google的Tomas Mikolov发布了Word2Vec。这个看似简单的词向量技术，实际上开启了"词语到数字"的转换，为后来的embedding技术奠定了基础。没有这个，就没有后面的密集检索。

2018年是关键的一年。Google发布了BERT。双向上下文表示，革命性的预训练范式------这让语言模型理解语义的能力大幅提升。BERT证明了一件事：大规模预训练+微调，可以处理各种各样的NLP任务。

2019年，两件事发生。Facebook发布了FAISS，这是一个高效向量相似度搜索库；Nils Reimers发布了Sentence-BERT，专门用于句子级别的embedding。这两个东西凑在一起，就是"把句子变成向量"然后"快速查找相似向量"的完整链路。

还有一个重要的前置技术是2019年的DPR（Dense Passage Retrieval），同样来自Facebook团队。DPR证明了用双编码器做密集检索，效果可以远超传统的BM25稀疏检索。这直接成为后续RAG系统的标准检索范式。

这些技术都不是为了RAG发明的，它们各自有自己的目标。但当它们被组合在一起，RAG的可能性就出现了。

第一阶段：理论基础建立期（2018-2020）

2020年出现了三篇重要论文，奠定了RAG的理论基础。

第一篇是Google的REALM。REALM的全称是"Retrieval-Augmented Language Model"，它首次将检索预训练与语言模型结合。核心思想是在预训练阶段就让模型学习"什么时候该检索"。这比RAG更进一步，因为它不是在推理时检索，而是在训练时就学好了检索策略。

但REALM有个问题------训练成本太高。它需要在大规模语料上做检索预训练，这可不是谁都能搞定的。

第二篇是Facebook的DPR。刚才提到了，它解决了"怎么高效检索"的问题。传统的BM25用词频匹配，但很多时候语义相似的关键词不一样。DPR用双编码器把文档和查询都变成向量，然后计算余弦相似度。这样就能找到语义相关的文档，即使关键词完全不同。

第三篇是Lewis团队的RAG论文。这才是真正把所有东西串起来的工作。

RAG的核心架构其实很清晰：一个检索器（Retriever），基于DPR；一个生成器（Generator），基于预训练的Seq2Seq模型如BART。检索器从知识库里找到相关文档，生成器根据这些文档生成答案。

论文里还设计了两种变体：RAG-Sequence和RAG-Token。前者是对整个序列检索一次，然后生成；后者是每生成一个token就检索一次，更灵活但也更慢。

这时候的RAG，还是"学术实验"性质。它证明了概念可行，但离真正能用还有距离。

第二阶段：架构完善期（2020-2021）

这一阶段的关键是解决"多文档融合"问题。

早期RAG只能处理单个检索文档。但很多复杂问题需要看多个文档才能回答，甚至需要在这些文档之间做推理。比如问"某某公司的CEO是谁？他之前在哪家公司工作？"这需要两个步骤：先查CEO，再查他之前的工作经历。

2020年底，Facebook的Gautier Izacard和Edouard Grave提出了FiD（Fusion-in-Decoder）。这个架构很巧妙：编码器独立处理每个检索到的文档，每个文档有自己的编码结果；解码器同时拿到所有编码结果，在生成时可以"融合"这些信息。

这个简单的设计，让多文档推理成为可能。而且FiD在多项开放域问答任务上达到了SOTA（当时最佳），证明了检索增强确实有效。

2021年，DeepMind发表了RETRO。这是一次规模上的飞跃------检索数据库有2万亿token。论文里说，一个760亿参数的RETRO模型，能达到GPT-3（1750亿参数）级别的性能。换句话说，检索让参数效率提升了25倍。

这背后的逻辑是：不用把所有知识都塞进模型参数里，很多知识可以放在外部。需要的时候再查。这样模型可以更小，但效果更好。

这些工作让RAG从"概念验证"变成了"有潜力的技术方案"。

第三阶段：从研究到应用（2021-2022）

这一阶段的转折点是GPT-3的发布。

2020年，OpenAI发布了GPT-3。论文里展示了一个现象：In-Context Learning（上下文学习）。模型不需要微调，只需要给几个示例，就能学会新任务。

这对RAG有重要影响。早期的RAG思路是"检索-微调"------检索到文档后，需要把文档和问题一起训练一个特定模型。但GPT-3证明，给模型足够的上下文，它就能自己学会怎么用这些上下文。

于是RAG的思路变了。不再需要针对每个场景微调，而是"检索-提示"。检索到相关文档后，直接把它们塞进prompt，让大模型自己想办法。

这个变化大大降低了部署成本，也让RAG变得更容易用。

2022年是一个关键年份。ChatGPT在11月发布，瞬间引爆了整个领域。每个人都想用LLM做点什么，但都遇到同一个问题------模型的知识有截止日期，而且会胡说八道。

RAG正好解决这个问题。

但这时候还没有一个好用的框架。想用RAG得自己拼凑各种组件：embedding模型、向量数据库、检索逻辑、prompt设计......对开发者来说门槛很高。

第四阶段：框架化时代（2022-2023）

2022年底到2023年，几个关键框架相继出现。

LangChain在2022年10月开源，2023年1月正式推出。它最初的想法很简单------把各种LLM、工具、数据源都抽象成统一的接口，让开发者可以像搭积木一样构建应用。

但LangChain很快就发现，RAG是最重要的应用场景之一。于是它开始往这个方向发展，集成了各种向量数据库、检索策略、重排序工具。到2023年，LangChain已经变成一个RAG开发的"瑞士军刀"。

几乎同时，LlamaIndex在2023年2月发布。它的定位更明确------专注于RAG，特别是数据连接和索引。创始人Jerry Liu和Simon Suo意识到，RAG的核心不是框架本身，而是怎么把各种数据源变成可检索的知识库。

LlamaIndex的创新在于"索引系统"。不只是简单的向量索引，还有树状索引、图状索引、知识图谱索引。不同索引适合不同场景，这让RAG更灵活。

Haystack的2.0版本也在2023年发布。这个由deepset公司维护的框架，从一开始就定位为"生产级"。它的特点是管道（Pipeline）可视化，让开发者可以直观地看到整个RAG流程，方便调试和监控。

这些框架的出现，让RAG从一个"研究课题"变成了"可用技术"。

第五阶段：Agent化（2023-2024）

但早期RAG有一个局限------它是"被动"的。

流程是固定的：查询→检索→生成。不管问题是什么，都要检索一遍。但有些问题根本不需要检索，比如问"1+1等于几"；有些问题需要多次检索，比如多跳推理；有些问题需要根据检索结果再决定下一步怎么办。

这些问题，静态RAG解决不了。

这时候"Agent"的概念开始流行。Agent不只是按流程执行，而是能够自主决策。它可以根据情况决定是否检索、检索什么、检索几次、什么时候停止。

LangChain在2023年推出了Agent抽象，配合ReAct（Reasoning + Acting）框架，让模型可以"思考-行动-观察"的循环。比如：

思考：这个问题需要查资料吗？
行动：调用检索工具
观察：检索结果是......
思考：还需要更多信息吗？
行动：再查一下
观察：......
思考：信息够了，可以回答了

这种动态决策，让RAG变聪明了。

2023年8月，LangChain团队又推出了LangGraph。这个新项目专注于"状态化Agent"，也就是需要长期运行、保持状态的Agent。比如一个法律咨询Agent，可能需要多轮对话、多个步骤、甚至人工介入，才能完成一个复杂任务。LangGraph用图的方式表示这些状态流转，让复杂的Agent变得可管理。

这一时期，RAGAS（RAG Assessment）框架也出现了。它解决了另一个问题------怎么评估RAG好不好？传统的BLEU、ROUGE指标不适合，因为它们只看表面相似度。RAGAS提出了faithfulness（忠实度）和answer_relevance（答案相关性）等指标，真正关注RAG的质量。

第六阶段：多Agent与Agentic时代（2024-2025）

到了2024-2025年，RAG的发展进入了一个新阶段。

第一个趋势是"Agentic RAG"。这个概念的论文在2025年发表，系统性地研究了Agent驱动的RAG系统。它的核心是：不是简单的"检索-生成"，而是把整个检索过程变成一个Agent的行为。

这意味着RAG可以：

自我反思：检查检索结果的质量
迭代精炼：如果结果不满意，就重新检索
动态规划：根据问题类型选择不同的检索策略
工具集成：不只是检索向量库，还可以调用搜索引擎、数据库、API

这种Agentic RAG在多跳查询上表现出色。2025年的FAIR-RAG论文在HotpotQA上达到了F1=0.453，比之前的方法提升了8.3个百分点。

第二个趋势是"多Agent协作"。

一个Agent可能不够用，那就用多个。每个Agent负责不同的任务，协同工作。

MAIN-RAG是一个多Agent过滤框架，2025年的研究显示它在多个任务上准确率提升了2-11%。SPD-RAG是分层多Agent框架，不同Agent处理不同层次的信息，效率提升显著。

多Agent的优势是分工明确、容错性好、可以并行执行。但代价是系统复杂度大幅提升，协调成本也高。

第三个趋势是"领域专业化"。

通用RAG在专业领域往往效果不佳，因为专业术语多、知识结构复杂。于是出现了针对特定领域的RAG框架：

Telco-RAG：针对电信行业，专门处理3GPP标准文档
Fintech RAG：针对金融行业，处理专业术语、缩略语、监管规则
MedRAG：针对医疗行业，在医学语料库上测试了41种配置

这些专业化RAG的共同特点是：针对领域特点优化检索策略、索引结构、prompt设计。效果往往比通用方案好很多。

第七阶段：当前前沿（2025-2026）

站在2026年的视角看，RAG已经从一个"有趣的实验"变成了"AI基础设施"。

但发展并没有停止。当前有几个前沿方向值得关注。

第一个是GraphRAG。传统RAG用向量索引，但向量只能捕捉语义相似度，无法表示复杂的结构关系。知识图谱可以表示实体之间的关联，这在某些任务上很重要。

GraphRAG在2024-2025年成为热点，但也有一些争议。有研究发现，Agentic搜索可以部分弥补GraphRAG的高成本，而且GraphRAG在某些任务上表现不如预期。这意味着GraphRAG不是"银弹"，需要根据场景选择。

第二个是多模态RAG。传统的RAG处理文本，但现实世界的数据是多样的。图像、音频、视频、结构化数据......这些都需要能检索。

2025年的综述论文《Ask in Any Modality》系统性地讨论了多模态RAG的挑战和解决方案。Embodied-RAG把RAG扩展到机器人领域，用"语义森林"来组织层次化记忆。

第三个是长上下文与RAG的结合。现在很多模型已经支持128K甚至更长的上下文窗口，有人觉得"不需要RAG了，直接把所有资料塞进去"。但研究发现，上下文窗口越长，"迷失在中间"（Lost in the Middle）效应越明显------模型可能忽略中间的内容。

RAG的价值不在于"放得下多少内容"，而在于"选择性"------只检索真正相关的内容。长上下文+RAG，可能是更优的方案。

七年演进：从理念到基础设施

回顾这七年的发展，RAG的演进路径是清晰的：

复制代码

理论基础(2020) → 架构完善(2020-2021) → 框架化(2022-2023) → Agent化(2023-2024) → 多Agent化(2024-2025)

这个演进不是线性的，而是有多个分支和转折。但每个阶段都有其核心问题：

理论基础阶段：能不能做？
架构完善阶段：怎么做更好？
框架化阶段：怎么让更多人用？
Agent化阶段：怎么更聪明？
多Agent化阶段：怎么解决复杂任务？

现在的问题变成了：RAG会走向哪里？

RAG框架与向量库

RAG框架：百花齐放的市场

RAG框架的市场是典型"百花齐放"的格局。没有一家独大，但每个产品都有自己的定位和用户群体。

LangChain是这个领域最显眼的玩家。133,000+ GitHub stars，22,000+ forks，这些数字说明了一切。LangChain的优势在于生态------它集成了最多的LLM、向量数据库、工具库。开发者想用什么，LangChain基本都支持。

但LangChain的问题也很明显：概念太多，学习曲线陡峭。Chain、Agent、Runnable、Message、Memory......这些概念都有各自的含义和用法，对新手来说很复杂。而且API变化频繁，今天写的代码下个版本可能就不工作了。

LlamaIndex是另一个重要玩家。48,000+ stars虽然不如LangChain，但它的定位更聚焦------专门做RAG优化。LlamaIndex的优势是"索引系统"设计精妙，树状索引、图状索引、知识图谱索引，各种索引类型适合不同场景。还有一个杀手级功能是LlamaParse，这个付费的商业产品可以解析130+种文档格式，在业界口碑很好。

Haystack走的是另一条路------生产就绪。由deepset公司维护，有Apple、Meta、Netflix等大厂客户。Haystack的特点是管道可视化，整个RAG流程一目了然，方便调试和监控。这对生产环境来说很重要。

Semantic Kernel来自微软。27,000+ stars，但它的优势不在于数量，而在于"企业级"。微软背书，Azure深度集成，符合企业安全和合规要求。对于微软生态的企业，这是自然的选择。

LangGraph是LangChain团队的新项目，29,000+ stars。它专注解决一个问题：状态化Agent。长期运行的Agent需要保持状态、支持人工介入、能够恢复错误执行。这些用传统的Chain很难做，但用图的方式表示就很自然。

向量数据库：没有绝对领导者

向量数据库市场的情况和RAG框架不同------没有绝对领导者，各家各有优势。

FAISS是性能王者。39,000+ stars，来自Facebook。它不是一个完整的数据库，而是一个向量相似度搜索库。但它的性能是业界领先的，特别是GPU加速版本。需要极致性能的场景，FAISS是首选。

但FAISS的问题也很明显------它不提供数据管理功能，没有持久化，没有查询语言，就是一个搜索库。要把它变成完整的向量数据库，需要自己做很多工作。

Pinecone是托管服务的代表。它没有开源，但提供了完全托管的向量数据库服务。零运维，开箱即用，这是它的卖点。但价格较高，而且有厂商锁定风险。

Chroma走的是"简单"路线。27,000+ stars，Rust实现，4个核心函数就搞定所有操作。5分钟上手，对开发者非常友好。但功能相对简单，大规模场景的经验较少。

Qdrant用Rust实现，性能优秀。30,000+ stars，分布式的HNSW索引，强大的过滤能力。Cohere等公司在用。问题是生态相对新，案例经验不多。

Milvus是规模最大的。43,000+ stars，支持数十亿向量，完整的分布式架构。但部署复杂，学习曲线陡峭。对于需要大规模部署的企业，Milvus是选择之一，但得准备好专业团队来运维。

Weaviate的特色是"向量化集成"。内置多种向量化模型，开箱即用。GraphQL API也很优雅。16,000+ stars，多模态支持不错。但性能不如纯Rust实现，配置也比较复杂。

用户口碑：真实的反馈

GitHub stars只能反映关注度，不能反映用户满意度。要了解真实的口碑，需要看社区讨论。

在Reddit、Hacker News、Twitter等社区，用户对RAG框架的评价有一些共识：

LangChain被叫做"RAG开发的瑞士军刀"，但也有用户抱怨"概念太多，学习成本高"、"代码太复杂，过度设计"、"API变化太快，难以维护"。这些负面评价都指向同一个问题------易用性。

LlamaIndex的正面评价集中在"RAG专家，性能优秀"、"索引系统设计精妙"。负面则是"商业功能收费，成本高"、"生态不如LangChain"、"复杂场景配置困难"。

Haystack最常听到的正面评价是"生产环境最稳定"、"技术团队专业可靠"。负面是"生态不够丰富"、"学习资源较少"。

LangGraph作为较新的项目，反馈两极分化。正面的评价是"状态化Agent的最佳方案"、"图可视化太棒了"。负面的则是"学习成本高"、"生态系统待完善"。

向量数据库的用户口碑更分化一些。

FAISS的正面评价很直接："性能之王"、"GPU加速太强大"。负面也很直接："不是完整的数据库"、"部署复杂"、"功能太单一"。

Pinecone的用户说"最省心的选择"、"上手最快"。但也有人说"价格太贵"、"迁移成本高"。

Chroma的"最简单的向量数据库"、"上手速度最快"很受欢迎。但也有"功能不够丰富"、"大规模经验少"的担心。

References

学术论文来源

Lewis et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" - NeurIPS 2020

来源：https://arxiv.org/abs/2005.11401

访问时间：2026-04-15
Guu et al. "REALM: Retrieval-Augmented Language Model Pre-Training" - ICML 2020

来源：https://arxiv.org/abs/2002.08909

访问时间：2026-04-15
Karpukhin et al. "Dense Passage Retrieval for Open Domain Question Answering" - EMNLP 2020

来源：https://arxiv.org/abs/2004.04906

访问时间：2026-04-15
Izacard & Grave. "Leveraging Passage Retrieval with Generative Models" - EMNLP 2020

来源：https://arxiv.org/abs/2005.11401

访问时间：2026-04-15
Borgeaud et al. "Improving language models by retrieving from trillions of tokens" - ICML 2022

来源：https://arxiv.org/abs/2112.04426

访问时间：2026-04-15
Es et al. "Ragas: Automated Evaluation of Retrieval Augmented Generation" - 2023

来源：https://arxiv.org/abs/2309.15217

访问时间：2026-04-15
Tang & Yang. "MultiHop-RAG: Benchmarking Retrieval-Augmented Generation for Multi-Hop Queries" - 2024

来源：https://arxiv.org/abs/2403.01892

访问时间：2026-04-15
Singh et al. "Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG" - 2025

来源：https://arxiv.org/abs/2502.03817

访问时间：2026-04-15

开源项目来源

LangChain - https://github.com/langchain-ai/langchain

GitHub数据：133,589 stars, 22,071 forks

访问时间：2026-04-15
LlamaIndex - https://github.com/run-llama/llama_index

GitHub数据：48,601 stars, 7,197 forks

访问时间：2026-04-15
Haystack - https://github.com/deepset-ai/haystack

GitHub数据：24,833 stars, 2,718 forks

访问时间：2026-04-15
Semantic Kernel - https://github.com/microsoft/semantic-kernel

GitHub数据：27,705 stars, 4,549 forks

访问时间：2026-04-15
LangGraph - https://github.com/langchain-ai/langgraph

GitHub数据：29,291 stars, 5,020 forks

访问时间：2026-04-15
FAISS - https://github.com/facebookresearch/faiss

GitHub数据：39,730 stars, 4,328 forks

访问时间：2026-04-15
Chroma - https://github.com/chroma-core/chroma

GitHub数据：27,438 stars, 2,194 forks

访问时间：2026-04-15
Qdrant - https://github.com/qdrant/qdrant

GitHub数据：30,341 stars, 2,170 forks

访问时间：2026-04-15
Milvus - https://github.com/milvus-io/milvus

GitHub数据：43,804 stars, 3,964 forks

访问时间：2026-04-15
Weaviate - https://github.com/weaviate/weaviate

GitHub数据：16,007 stars, 1,255 forks

访问时间：2026-04-15

社区讨论来源

Reddit r/LangChain - https://www.reddit.com/r/LangChain/

访问时间：2026-04-15
Hacker News RAG相关讨论 - https://news.ycombinator.com/

访问时间：2026-04-15
Twitter/X 开发者社区

访问时间：2026-04-15

官方文档来源

LangChain官方文档 - https://python.langchain.com/
LlamaIndex官方文档 - https://docs.llamaindex.ai/
Haystack官方文档 - https://docs.deepset.ai/
Pinecone官方文档 - https://docs.pinecone.io/
Milvus官方文档 - https://milvus.io/docs