中高级 RAG 与工作流编排 - 以 LangGraph 为例

用 Codex 实现

这节更适合把 Codex 当成“工作流编排助手”和“图结构实现代理”。

推荐先让它拆出：

Graph 节点
状态对象
检索与工具节点
评测与 tracing

可直接这样说：

text

请先为一个中高级 RAG 系统设计 LangGraph 工作流：
1. 节点和边如何划分
2. 状态里需要保存什么
3. 检索、重排、工具调用分别放在哪
4. 如何做评测和可观测性
先给图结构设计，再开始写代码

建议配合：

图示：中高级 RAG 和 LangGraph 更适合用多线程方式推进，把检索、工作流、评测拆成并行子任务。

这节课的核心目标

当一个普通 RAG 已经不够用时，你通常会遇到这些问题：

查询意图复杂，不能只检索一次
需要在检索、重排、工具调用之间反复决策
希望加入人工确认、失败回退或多阶段评测

这时就适合进入 LangGraph 这类“有状态工作流”框架。

一个中高级 RAG 常见会有哪些节点

节点类型	作用
Query 解析节点	理解用户问题、拆分子任务
Retrieval 节点	检索知识库或外部文档
Rerank 节点	对候选内容重新排序
Tool 节点	调用搜索、数据库或业务接口
Judge 节点	判断证据是否足够、是否需要重试
Answer 节点	汇总证据、生成最终回复

状态对象建议至少保存什么

原始问题
当前子任务
检索结果摘要
工具调用结果
重试次数
最终引用依据

推荐的教学路径

先画出图结构，不急着写代码
明确哪些节点会修改状态
为“证据不足”设计回退路径
再补日志、评测和 tracing

适合课堂展示的 3 个升级点

从单次检索升级为“检索 + 判断 + 再检索”
从固定答案升级为“带引用与证据摘要”
从单一成功路径升级为“可重试、可回退、可人工接管”

验收标准

图结构是否清晰
状态设计是否足够支撑多轮流转
是否考虑失败、超时与证据不足
是否有评测思路，而不只是“感觉答案更好了”

常见卡点

图结构太复杂，节点拆得过细
状态对象设计混乱，后面很难调试
没有日志和可观测性，出了错不知道卡在哪