EP220: RAG vs Graph RAG vs Agentic RAG
TL;DR · AI 摘要
RAG、Graph RAG 和 Agentic RAG 是三种不同的 LLM 数据连接方式，各有适用场景和优缺点。
核心要点
- 标准 RAG 快速但容易因错误检索导致错误答案。
- Graph RAG 适用于结构化知识，但构建和更新成本高。
- Agentic RAG 更灵活但更慢、更难调试，适合多步骤推理场景。
结构提纲
按章节快速跳转。
- §引言
介绍 RAG、Graph RAG 和 Agentic RAG 的基本概念和应用场景。
标准 RAG 通过向量数据库匹配查询，快速但容易出错。
Graph RAG 利用知识图谱进行本地和全局搜索，适用于结构化数据。
Agentic RAG 使用推理代理进行多步骤推理和自我修正，但更慢且更难调试。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- RAG vs Graph RAG vs Agentic RAG
- 标准 RAG
- 快速但容易出错
- 适用于文档中答案明确的场景
- Graph RAG
- 利用知识图谱进行搜索
- 适用于结构化数据
- Agentic RAG
- 多步骤推理和自我修正
- 更慢、更难调试
金句 / Highlights
值得收藏与分享的关键句。
标准 RAG 快速但容易因错误检索导致错误答案。
Graph RAG 适用于结构化知识，但构建和更新成本高。
Agentic RAG 更灵活但更慢、更难调试，适合多步骤推理场景。
EP220: RAG vs Graph RAG vs Agentic RAG
2026年6月27日
✂️ 使用 QA Wolf 将 QA 周期缩短至分钟（赞助）
如果缓慢的 QA 流程成为你或软件工程团队的瓶颈，并且因此导致发布速度变慢，那你需要了解一下 QA Wolf。
QA Wolf 的 AI 原生服务支持 Web 和移动应用，几周内即可实现 80% 的自动化测试覆盖率，帮助团队通过将 QA 周期缩短至分钟，实现发布速度提升 5 倍。
QA Wolf 将测试工作从你的工作中解放出来。他们可以为你提供：
- 移动和 Web 应用的无限并行测试运行
- 24 小时维护和按需测试创建
- 经人工验证的错误报告直接发送给你的团队
- 零不稳定性的保证
好处？不再需要手动的端到端测试。不再有缓慢的 QA 周期。不再有错误进入生产环境。
使用 QA Wolf，Drata 的 80 多名工程师团队实现了测试用例数量增加 4 倍，QA 周期速度提升 86%。
安排一次演示以了解更多
本周的系统设计复习：
- RAG vs Graph RAG vs Agentic RAG
- 每位工程师都应该了解的 Redis 数据结构
- API 安全最佳实践
- 设计模式速查表
- 测试金字塔
RAG vs Graph RAG vs Agentic RAG
RAG 将大语言模型（LLM）连接到你的数据，并且有三种不同的方式可以实现。
标准 RAG
- 查询被转换为嵌入，并与向量数据库进行匹配。
- 提取最接近的前 K 个片段，并将它们作为上下文传递给 LLM。
- LLM 仅使用检索到的内容生成一个基于事实的答案。
Graph RAG
- 查询被分类：具体问题路由到本地搜索，广泛问题路由到全局搜索。
- 本地搜索：查询嵌入 → 向量数据库找到匹配的实体 → 管道在知识图谱中遍历，收集链接的上下文 → LLM 合成最终答案。
- 全局搜索：无向量搜索，无图遍历 → 批量加载社区报告 → LLM 对每个报告进行相关性评分 → 最高排名的上下文 → LLM 合成最终响应。
Agentic RAG
- 一个推理代理读取查询，将其拆分为子问题并选择来源。
- 根据子查询检索多个来源的上下文。
- 另一个代理检查检索到的上下文是否回答了问题。如果没有，它会重新检索。
- 一旦满意，LLM 根据提示合成最终答案。
标准 RAG 快速且便宜，但如果检索到错误的片段，答案就会错误，而且没有机制可以捕捉到。当答案存在于你的文档中且速度至关重要时使用它。
Graph RAG 构建成本高，更新速度慢。适用于结构化知识，如法律、合规或生物医学数据。
Agentic RAG 更加强大和灵活，但速度更慢、成本更高、调试更困难。当问题需要多步骤推理和自我纠正时使用它。现在轮到你了：你正在生产环境中使用哪些？
每位工程师都应该了解的 Redis 数据结构
- 字符串：每个键存储一个值。适用于计数器、会话令牌和缓存的有效载荷。
- 哈希：在一个键下存储对象的字段。可以更新一个字段而无需重写其余部分。
- 列表：有序序列，两端的推送和弹出操作速度快。适用于队列、信息流和最近项目列表。
- 集合：存储唯一成员，支持交集、并集和差集。适用于标签、关注者重叠和去重。
- 有序集合：根据数字评分对成员进行排序。适用于排行榜、优先队列和 top-N 或按评分范围查询。
- 流是一个仅追加的日志，支持消费者组。每个消费者跟踪自己的位置，服务器跟踪未确认的消息。
- JSON 存储嵌套文档，并支持通过 JSONPath 访问。你可以无需读取-修改-写入操作，直接更新文档中的深层字段。
- 地理空间功能提供基于经纬度的索引，支持半径和矩形查询。其底层实现是一个带有 geohash 分数的有序集合。
- 向量集在嵌入向量上执行近似最近邻搜索。这是大多数 RAG 管道中的检索步骤。
- 时间序列存储带有内置保留期、降采样和标签的时间戳样本。它适用于指标、遥测和物联网数据。
轮到你了：从 Redis 8 开始，这十个功能都是内置的。除了缓存之外，你最常使用的是哪一个？
API 安全最佳实践
大多数 API 泄漏是由于授权机制损坏、密钥泄露或缺少速率限制。让我们来看看一些基本做法。
- 使用现代的 OAuth/OIDC + MFA：对于公共客户端使用 PKCE，使用短生命周期令牌，并对任何敏感操作使用增强的 MFA。隐式授权和密码授权方式现在应该已经被淘汰了。
- 强制执行细粒度授权：在每个请求中检查对象、函数和字段级别的权限。BOLA 仍然是 API 的首要漏洞。
- 最小化作用域和数据：为每个客户端提供最小的令牌作用域和最少的数据。只返回调用者实际需要的字段。
- 加密每一步通信：对外部流量使用 TLS，服务之间使用 mTLS。只要数据跨越网络边界，就进行加密。
- 保护密钥和令牌：将签名密钥存储在基于 HSM 的保险库中。定期轮换它们。
- 使用模式验证请求：在网关处拒绝未知字段、过大负载和可疑 URL。不要让恶意输入到达你的业务逻辑。
- 限制速率并控制资源使用：按用户设置配额、限制负载大小和执行超时。没有这些措施，一个行为异常的客户端可能会导致整个系统崩溃。
- 保护敏感的业务流程：使用反爬虫、幂等性密钥和增强认证来保护登录、结账和 OTP 流程。
- 控制出站和第三方调用：白名单你的 API 可以调用的地址，并阻止内部元数据端点。你的安全程度取决于最弱的集成。
- 加强配置和错误处理：默认情况下拒绝 CORS、方法和调试端点。返回通用错误，永远不要返回堆栈跟踪。
- 清点 API 和版本：跟踪每个端点、版本和影子 API。你无法保护你不知道存在的内容。
- 日志记录、检测和响应：将授权决策和异常推送到 SIEM。在 401 错误激增之前发出警报。
轮到你了：在你的服务中，这些最佳实践中哪一项最难实施？
设计模式速查表
速查表简要解释了每个模式及其使用方法。
包含哪些内容？
- 工厂模式
- 构建器模式
- 原型模式
- 单例模式
- 责任链模式
- 还有更多！
测试金字塔
测试是可靠软件的支柱。测试金字塔是一种广泛接受的策略，用于将测试分为三个关键层次：
- 单元测试：这是金字塔的基础。单元测试快速、独立且易于编写和维护。它们测试单个函数、方法或组件。
- 集成测试：这些测试验证组件之间的交互，例如 API、数据库和外部服务。它们比单元测试慢，需要更多的设置。
- E2E 测试：这些测试模拟从开始到结束的完整系统中的真实用户流程。编写和维护这些测试的成本较高，而且执行速度通常较慢。
随着你向上移动测试金字塔，测试开发、执行和维护的成本会逐渐增加。
轮到你了：在你的测试策略中，你认为哪一层最有价值，为什么？