RAG 系统架构

RAG 系统架构解决的是把内容源、检索、生成和日志连成一条可运行链路的问题。RAG 的目标不是让模型显得更懂，而是让回答建立在可追溯、可更新、可评估的外部知识之上。

在 Way To Agent 的知识体系里，这篇文章关注的是服务边界、数据流和关键表设计。它要回答的不是“RAG 有哪些名词”，而是“内容从哪里来，怎么进索引，怎么进回答，怎么被追踪”。

为什么要拆离线和在线

RAG 架构之所以要分层，通常是因为你会同时面对这些压力：

• 内容源会持续变化，不能依赖模型训练时的旧知识。
• 用户需要的不只是答案，还要知道答案来自哪篇文档、哪个标题、哪个片段。
• 一次错误回答可能来自解析、切片、召回、Rerank、Prompt 或模型生成任一环节。
• 离线链路负责内容解析、切片、Embedding 和入库。
• 在线链路负责问题改写、召回、Rerank、Prompt 拼接和生成。
• 业务链路负责权限、额度、日志和反馈。

这些压力汇到一起时，核心问题就不再是“能不能回答”，而是“内容更新、在线问答和系统治理分别由谁负责”。

一条回答怎么走完

RAG 架构的工作方式是先把内容变成可检索的结构，再把问题转成可召回的上下文，最后把上下文交给模型生成答案。

用户输入
  -> 业务上下文与权限判断
  -> 数据、检索、Prompt 或工具编排
  -> 模型调用或确定性服务执行
  -> 结构化校验、引用、日志和反馈

真正关键的，不是模块拆得越多越好，而是让失败能被迅速定位。把离线索引和在线问答拆开，是为了让内容更新、问题回答和故障排查都有明确边界。

链路里有哪些模块

从工程实现看，RAG 架构通常会牵涉以下组件：

• 文档解析与元数据提取
• 标题感知切片与 chunk 管理
• Embedding 与向量库写入
• 召回、过滤、Rerank 与上下文拼接
• 引用溯源、日志和效果评估

这些组件不一定都要在第一天完整引入。更稳妥的做法是先用最小闭环验证业务价值，再沿着质量、成本、权限和可观测性逐步补齐能力。

边界为什么这样切

不要把 RAG 简化成“向量数据库加大模型”。向量检索只是链路中的一段，解析质量、片段结构、引用字段和评估闭环同样决定最终效果。

以 Way To Agent 当前版本为例，公开文档阅读、分类、标签、文章详情和基础搜索应能静态独立运行；会调用 LLM、Embedding、Rerank 或外部工具的能力，必须登录后限量使用，并记录调用日志和额度消耗。这个例子说明：不是所有知识库能力都应该变成模型调用，成本、权限和部署复杂度必须被单独约束。

最常见的误解

• 只看模型效果，不看权限、日志、成本和失败恢复。
• 只堆框架名，不说明框架在链路中的职责。
• 把 Demo 的成功当成生产系统的可靠性证明。
• 在没有评估样例和调用记录的情况下讨论“效果好不好”。

怎么排查

当 RAG 架构相关功能表现不稳定时，不要先猜模型不好。更有效的排查顺序是：

输入是否明确
上下文是否正确
权限与数据范围是否匹配
Prompt / 工具 / 检索配置是否符合预期
模型调用是否超时、限流或输出不合规
日志、引用和评估样例是否能复现问题

这个顺序的好处是把问题从“玄学调参”拉回工程事实。只要每一步都有记录，就能判断是输入、数据、配置、模型还是展示层的问题。

一句话结论

RAG 系统架构的核心不是记住一个名词，而是理解它在 AI 应用链路中的责任边界。把离线索引和在线问答拆开，是为了让内容更新、问题回答和故障排查都有明确边界。

画图时先标什么

1. 用一张图画出“RAG 架构”在你的 AI 应用链路中的位置。
2. 标注哪些步骤是确定性工程逻辑，哪些步骤会调用模型或检索服务。
3. 为一次失败结果写出排查字段：输入、上下文、配置、模型、日志和用户反馈。

继续阅读

04-rag/001-what-is-rag.md
04-rag/003-document-parsing.md
04-rag/004-chunking-strategy.md