RAG 系统架构专题

概览

RAG（Retrieval-Augmented Generation，检索增强生成）不是“把文档塞给大模型”这么简单，而是一套由数据处理、Embedding、检索、重排、生成和服务治理共同组成的系统架构。

在企业知识库场景里，RAG 的目标通常不是替代大模型本身，而是把企业内部资料、业务规则、产品文档和权限边界接入到大模型服务中，使回答更贴近当前业务事实。

官方可确认的信息

根据 NVIDIA 对 RAG 的官方说明，RAG 的关键价值在于把外部数据源连接到大语言模型，让模型能够基于领域数据或更新数据生成回答。NVIDIA RAG Blueprint 也把 RAG 视为一套可部署的流水线，而不是一个单独模型。

因此，RAG 架构至少应拆成三类问题：

• 数据如何进入系统；
• 信息如何被检索和排序；
• 检索结果如何进入大模型并稳定服务用户。

推荐架构分层

1. 数据接入层

负责接入企业内外部数据源，包括：

• PDF / Word / Markdown / HTML 文档
• 产品资料、FAQ、售后记录
• 数据库、工单、CRM、ERP
• 代码仓库和内部 Wiki

这一层的重点不是“能不能读文件”，而是数据来源、更新频率、权限归属和版本追踪是否清楚。

2. 文档处理层

负责把原始资料转成可检索的知识单元，常见步骤包括：

• 文档解析
• 清洗去噪
• 分段切块
• 元数据抽取
• 去重和版本标记

切块策略会直接影响召回质量。切得太碎会丢上下文，切得太大又会增加检索噪声和生成成本。

3. Embedding 与索引层

负责把文本片段转成向量，并写入向量库或混合检索系统。

这一层需要关注：

• Embedding 模型是否适合中文和行业语料；
• 索引是否支持增量更新；
• 是否需要关键词检索与向量检索混合；
• 是否要保留文档、段落、权限、时间等元数据。

4. 检索与重排层

检索层负责召回候选知识片段，重排层负责进一步提高相关性。企业 RAG 中，重排通常是提升准确率的重要环节，但也会带来额外时延。

如果系统对响应速度要求很高，应单独评估：

• Top-K 召回数量；
• 重排模型耗时；
• 多路检索合并策略；
• 缓存命中率。

5. 生成层

生成层负责把用户问题、系统指令和检索结果组织成 Prompt，再交给大模型生成答案。

这里的关键不是只选更大的模型，而是控制：

• 上下文长度；
• 引用片段数量；
• Prompt 模板；
• 输出格式；
• 幻觉和拒答策略。

6. 服务治理层

生产级 RAG 必须有服务治理，而不能只停留在 Demo。至少要包含：

• 用户鉴权
• 文档权限过滤
• 调用日志
• 敏感信息处理
• 版本管理
• 失败回退
• 监控与审计

企业知识库项目真正上线后，很多问题不是模型能力问题，而是权限、日志、更新和回溯问题。

工程估算说明

以下不是官方固定配置，而是 RAG 项目规划时应采用的估算口径：

• 离线建库和在线问答要分开估算，前者关注批量吞吐，后者关注响应时延和并发；
• Embedding、检索、重排和生成要分别压测，不能只看主模型显存；
• 文档量、更新频率、平均 chunk 数、Top-K、重排策略和上下文长度都会影响最终资源需求；
• 生产环境应预留索引重建、模型升级、权限变更和异常回滚空间。

最低输入应包含：文档规模、日更新量、在线并发、目标响应时间、权限复杂度、是否需要重排、主模型规模和最大上下文长度。

发布复核说明

本条目已按官方资料和本地架构图做发布前复核，可作为企业 RAG 项目的一级入口。

• 官方依据：NVIDIA RAG 术语说明、NVIDIA RAG 主题页和 NVIDIA RAG Blueprint 文档。
• 本地资产：assets/diagrams/rag-system-architecture.md。
• 发布边界：本文解释系统架构和工程拆层，不给出固定服务器配置；容量估算应继续参考 faq-rag-compute-sizing。

常见误区

误区 1：把 RAG 等同于向量数据库

向量数据库只是 RAG 的一部分。没有文档处理、重排、权限和生成控制，单独的向量库无法保证企业知识问答质量。

误区 2：只优化生成模型

很多 RAG 失败案例不是因为模型不够大，而是检索不到、检索错、文档切块差或权限过滤不正确。

误区 3：离线和在线混用同一资源池

夜间批量重建索引和白天在线问答的资源模式不同。混在一起容易导致服务抖动。

RAG 落地评估

正在规划企业 RAG 知识库？

从文档接入、权限边界、向量库、Embedding、重排和模型推理评估落地路径。

评估 RAG 落地方案查看相关方案