Agentic RAG：用LangGraph打造会自动修正检索错误的 RAG 系统

标准 RAG 流水线有个根本性的毛病：检索到的文档一旦与用户意图对不上号，模型照样能面不改色地输出一堆看似合理的胡话，既没有反馈机制也谈不上什么纠错能力。

而Agentic RAG 的思路截然不同，它不急着从检索结果里硬挤答案，而是先判断一下拿回来的东西到底有没有用，如果没用则会重写查询再来一轮。这套机制实际上构建了一条具备自我修复能力的检索链路，面对边界情况也不至于直接崩掉。

本文要做的就是用 LangGraph 做流程编排、Redis 做向量存储，搭一个生产可用的 Agentic RAG 系统。涉及整体架构设计、决策逻辑实现，以及状态机的具体接线方式。

传统 RAG 的"一锤子买卖"

假设知识库里有一篇《大语言模型的参数高效训练方法》，用户问的是"怎么微调 LLM 效果最好"。

语义相似度确实存在但不够强。检索器拉回来的可能是模型架构相关的内容虽然沾边但答非所问，LLM 本身没法意识到上下文是错的，照样能生成一段貌似专业实则离题万里的回答。

传统 RAG 对这种失败模式完全没有办法。查询文档、生成答案，整个过程是单向的没有任何质量把关环节。

Agentic RAG 的解法是在流程中插入检查点：智能体先判断要不要检索；检索完了有评分环节确认相关性；不相关就重写查询再试；如此循环直到拿到合格的上下文，或者把重试次数耗尽为止。

系统架构拆解

整个系统拆成六个模块：

配置层负责环境变量和 API 客户端的初始化工作。Redis 连接串、OpenAI 密钥、模型名称全部归拢到这里统一管理。

检索器模块承担文档摄取的全套流程，文档经过

复制代码

WebBaseLoader

加载后用

复制代码

RecursiveCharacterTextSplitter

切块，再通过 OpenAI Embedding 向量化，最后存进

复制代码

RedisVectorStore

。检索器本身会被包装成 LangChain 工具供智能体调用。

智能体节点是决策入口。拿到用户问题后先做判断：这个问题需要查资料还是直接能答？需要查就调检索器，不需要就直出答案。

评分（Grade Edge）决定检索结果的去向。相关性够就往生成环节走；不够就触发重写。这是整个系统里最关键的质量关卡。

重写节点把原始问题改写成更适合检索的形式，用户表述太口语化、缺少关键词，这些问题都在这里修正。

生成节点只有在评分环节确认上下文合格后才会执行，基于检索到的文档产出最终答案。

流程图和代码

关键在于从"重写"回到"智能体"这条反馈路径。系统不会因为一次检索失败就直接给出一个牵强附会的答案，它会调整策略重新尝试。

复制代码

 src/  
├── config/  
│   ├── settings.py      # 环境变量  
│   └── openai.py        # 模型名称和 API 客户端  
├── retriever.py         # 文档摄取和 Redis 向量存储  
├── agents/  
│   ├── nodes.py         # 智能体、重写和生成函数  
│   ├── edges.py         # 文档评分逻辑  
│   └── graph.py         # LangGraph 状态机  
 └── main.py              # 入口点

职责划分很清晰：配置归

复制代码

config/

，智能体相关的都在

复制代码

agents/

，向量存储操作全在

复制代码

retriever.py

。这种结构调试起来方便，单测也好写。

配置模块设计

配置层解决两个问题：环境变量加载和 API 客户端复用。

复制代码

settings.py

集中读取 Redis 连接信息、OpenAI API Key、索引名称，不用满项目找配置。

复制代码

openai.py

负责实例化 Embedding 模型和 LLM 客户端。切换到别的模型、调整 Embedding 维度等等配置也只要一处

这个设计在生产环境里很实用，因为模型会迭代、Key 会轮换、服务商可能换掉，集中管理意味着改动成本可控。

检索器实现

检索器负责整条数据摄取链路：抓文档、切块、向量化、入库。

语料选的是 Lilian Weng 关于 Agent 和 Prompt Engineering 的博客文章。

复制代码

WebBaseLoader

负责抓取，

复制代码

RecursiveCharacterTextSplitter

切分成适当大小的块，OpenAI Embedding 完成向量化。

向量存储用

复制代码

RedisVectorStore

。检索器通过

复制代码

create_retriever_tool

封装成 LangChain 工具形态。这一步的意义在于让智能体能够"调用"检索而不是被动触发，意味着它有权决定什么时候需要查资料、什么时候直接回答。

为什么用Redis？因为够快，够简单。向量相似度搜索本身 Redis 就能做，不用额外引入专门的向量数据库。对于已经跑着 Redis 的技术栈来说，加 RAG 能力几乎零额外运维负担。

智能体节点

复制代码

nodes.py

里有三个核心函数。

智能体函数接收当前状态（用户问题、历史对话等），判断下一步怎么走。它能调用包括检索器在内的工具集。问题需要外部知识就调检索，不需要就直接生成回答。

重写函数处理那些被评分环节打回来的查询。它会让 LLM 把原始问题改写成检索友好的形式，用词更精准、关键信息更突出。改写后的查询再交回智能体重新发起检索。

生成函数产出最终答案。输入是原始问题加上已确认相关的文档，输出是基于这些上下文的回答。

三个函数都是无状态的。状态走图，不走函数内部变量。这对测试和排查问题都有好处。

文档评分逻辑

复制代码

edges.py

里的

复制代码

grade_documents

是整个 Agentic 机制的核心。

检索完成后它会逐个审视返回的文档：这东西跟用户问的相关不相关？能不能帮上忙？

评分本身是通过一次 LLM 调用完成的，Prompt 设计成要求模型返回二元判断------相关或者不相关。

判定相关就返回

复制代码

"generate"

，流程走向答案生成；判定不相关则返回

复制代码

"rewrite"

，触发查询改写。

这个环节的价值在于拦截那些本会导致标准 RAG 胡说八道的情况，与其硬着头皮从不靠谱的上下文里编答案，不如给系统一次修正查询的机会。

状态机接线

复制代码

graph.py

用 LangGraph 的状态机原语把所有节点串起来。

图结构定义了节点（智能体、检索、生成、重写）和边（节点间的连接关系，包括基于评分结果的条件路由）。

接线逻辑如下：查询先到智能体节点，智能体决定调检索器的话流程就到检索节点，检索完进评分，评分过了走生成，没过走重写，重写完的查询再回智能体重新来过。生成节点执行完流程结束。

LangGraph 接管状态流转的细节。每个节点只管接收当前状态、返回状态更新，具体消息怎么路由由图引擎根据边的条件逻辑处理。

运行时流程

复制代码

main.py

是入口，做三件事：构建图、接收问题、流式输出结果。

复制代码

build_graph()

在启动时执行一次，完成 LangGraph 状态机的构建和检索器工具的初始化.

问题进来之后的流转过程：智能体接收问题决定调检索 → Redis 返回文档 → 评分环节判断相关性 → 相关就生成答案，不相关就重写查询继续循环。

脚本会把各节点的输出实时打到控制台，方便观察决策过程------什么时候触发了检索、评分结果如何、有没有走到重写环节，一目了然。

架构的优势

自校正能力：检索质量差能发现并修复，不会闷头输出一个基于垃圾上下文的错误答案然后假装没事发生。

决策透明：状态机让每个分支点都是显式的。路由决策可以全量记录，想排查为什么系统选择了重写而不是直接生成，日志里全有。

模块解耦：每个组件职责单一。想把 Redis 换成 Pinecone？改检索模块。想把 OpenAI 换成 Anthropic？改配置层。其他部分不受影响。

总结

标准 RAG 把检索当黑盒，查询丢进去、文档出来，至于相不相关全凭运气。Agentic RAG 打开这个黑盒在关键位置加了质量控制。

LangGraph 加 Redis 的组合提供了一个可以直接上生产的骨架。流程编排的复杂度 LangGraph 消化掉了，向量检索的性能 Redis 兜住了，剩下的评分和重写逻辑负责兜底那些简单系统搞不定的边角案例。

代码：

https://avoid.overfit.cn/post/a45e19af576a4826a605807d8fcfe298

作者：Kushal Banda