从普通 RAG 到企业级 RAG：完整架构复盘

上一篇文章里我们讨论了 RAG 上线后怎么排查问题。一个重要结论是RAG 系统一旦进入真实业务就不能只看最终答案。你必须知道问题出在文档解析、数据清洗、Chunk 切分、Embedding、召回、Rerank、Prompt、权限过滤还是模型生成。这篇文章作为 RAG 实战进阶系列的收官不再展开单个技术点而是回到整体架构。我们讨论一个更完整的问题一个 RAG 系统从普通 Demo 走向企业级应用到底需要补齐哪些能力很多人第一次做 RAG 时会把它理解成上传文档 ↓ 向量化 ↓ 相似度检索 ↓ 把检索结果塞给大模型 ↓ 生成答案这个理解没有错。但它只是普通 RAG 的最小闭环。真正的企业级 RAG需要的不只是“能回答”而是数据可管理 检索可优化 答案可约束 权限可控制 成本可估算 效果可评测 问题可追踪 系统可演进如果缺少这些能力RAG 很容易停留在 Demo 阶段。能演示但不好上线。能回答几个样例问题但无法支撑长期业务。普通 RAG 的价值是什么先不要急着否定普通 RAG。普通 RAG 仍然很重要。它解决了大模型应用里一个核心问题模型本身不知道你的私有知识。比如企业内部制度、产品文档、项目资料、客服知识、技术手册、合同模板、运维记录这些内容不会天然存在于通用大模型里。RAG 的基本思路是不把所有知识都训练进模型 而是在回答前先检索相关资料 再让模型基于资料生成答案这样做有几个明显好处。第一知识可以更新。文档变了只需要重新入库或更新索引不一定要重新训练模型。第二答案可以引用来源。用户不仅能看到答案还能知道答案来自哪份资料。第三私有知识可以接入。企业不用把所有内容放进模型训练流程也能让模型使用这些资料。所以普通 RAG 是 AI 知识库问答的基础。问题在于普通 RAG 跑通以后并不等于企业级 RAG 可用。Demo 可用和生产可用的差距Demo 阶段通常只有几个特点文档数量少 问题类型简单 用户数量少 权限边界弱 失败成本低 可以人工解释问题但生产环境完全不同。真实系统会面对大量文档 多种格式 持续更新 多个部门 多个租户 复杂权限 高并发查询 成本压力 错误追责 用户信任问题这时RAG 不再只是一个模型调用流程而是一个完整的信息访问系统。它既要像搜索系统一样重视召回质量也要像知识管理系统一样重视数据治理还要像在线业务系统一样重视权限、安全、成本和稳定性。所以企业级 RAG 的架构重点不是堆更多工具。而是把各个关键环节做成可维护的系统能力。数据层决定 RAG 的上限企业级 RAG 的第一层是数据层。很多 RAG 问题表面看是模型回答不好实际根因在数据层。比如PDF 解析错乱 表格结构丢失 页眉页脚反复出现 旧版本文档没有下线 重复内容太多 无效段落进入知识库 标题层级丢失 图片中的关键信息没有识别这些问题会直接影响后面的所有环节。如果数据本身不干净Embedding 再好也救不了。如果 Chunk 切得混乱Retriever 很难召回正确上下文。如果旧文档和新文档混在一起模型就可能给出过期答案。所以企业级 RAG 的数据层至少要考虑文档解析 数据清洗 重复内容去重 版本管理 文档状态管理 Chunk 切分 原文和 Chunk 的映射 数据删除和重建索引这里最重要的是可追溯。每一个 Chunk 最好都能追溯到tenant_id space_id doc_id chunk_id source_url version created_at updated_at status这样后面才能做权限过滤、引用来源、问题排查、数据删除和版本回滚。数据层不是辅助模块。它是企业级 RAG 的地基。检索层不要只依赖向量检索普通 RAG 经常只做向量检索。但真实场景里只靠向量检索很容易漏召回。尤其是这些内容编号 代码 专有名词 产品型号 接口名称 错误码 人名 表格字段 短关键词向量检索擅长语义相似但不一定擅长精确匹配。所以企业级 RAG 通常需要更完整的检索层。一个更稳的检索链路可以是用户问题 ↓ Query Rewrite ↓ 关键词检索 向量检索 ↓ 结果合并 ↓ Metadata Filter ↓ Rerank ↓ 上下文压缩 ↓ 交给生成层这里有几个关键点。第一Hybrid Search 很重要。关键词检索和向量检索不是谁替代谁而是互补。第二Metadata Filter 必须前置。权限、租户、空间、文档状态这些过滤条件不应该等生成后再判断。第三Rerank 不能省。召回结果不等于最终上下文。Rerank 可以帮助系统从候选内容里挑出更适合回答当前问题的片段。第四上下文要控制。不是把 TopK 全部塞给模型就更好。上下文过长会增加成本也会引入噪声。检索层的目标不是“召回越多越好”。而是在可控成本内把最有价值、最可信、最有权限的资料交给模型。生成层不要让模型自由发挥生成层看起来是大模型的事情但在企业级 RAG 中生成层也必须工程化。很多错误答案不是因为没有检索到资料而是因为 Prompt 没有约束好。比如模型把资料外内容补进去 模型没有说明不知道 模型引用来源不清楚 模型把多个文档观点混在一起 模型没有区分事实和推测 模型输出格式不稳定所以 RAG 的 Prompt 需要明确规则。比如只能基于给定资料回答 资料不足时说明无法确定 需要引用来源 不要编造不存在的条款 冲突内容要提示冲突 输出结构要稳定生成层还要处理复杂问题。有些问题不是一次检索就能回答。这时可以引入查询改写 问题拆分 多步检索 多轮补充检索 答案校验 引用检查生成层不是简单调用模型。它更像是把检索结果转成可信答案的最后一道工程边界。权限和多租户企业级 RAG 的硬要求如果 RAG 用在个人知识库里权限问题可能不明显。但企业场景一定绕不开权限。不同用户能看到的文档不一样。不同部门能访问的知识空间不一样。不同租户的数据不能混在一起。所以企业级 RAG 必须把权限和多租户设计进检索链路。一个基本原则是先限定可见范围 再做检索和生成不要先全库召回再事后过滤。因为一旦越权内容进入候选集就已经产生了风险。比较合理的流程是身份认证 ↓ 识别 tenant_id ↓ 加载用户角色和权限 ↓ 构造 tenant filter 和 permission filter ↓ 在可见范围内检索 ↓ 生成答案 ↓ 记录审计日志多租户解决“属于谁”的问题。权限控制解决“谁能看”的问题。两者必须一起设计。否则系统要么容易串租户要么容易内部越权。成本层能跑不等于敢用RAG 上线后成本会变成非常现实的问题。成本不仅来自最终的大模型生成还来自Embedding 向量检索 关键词检索 Rerank 多轮检索 长上下文 多模态解析 日志存储 评测任务如果没有成本控制系统可能会出现小问题也触发大模型 重复问题反复检索和生成 长文档每次都塞进上下文 Rerank 候选过多 无效请求消耗大量 token企业级 RAG 需要设计成本层。常见方法包括Query Cache Embedding Cache 摘要缓存 分层检索 TopK 控制 上下文压缩 小模型预处理 租户级配额 请求级成本统计成本控制不是简单省钱。它决定系统能不能长期运行。如果一个系统每次查询都很贵业务方最后就会不敢用。评测层不要只靠感觉判断效果RAG 系统最怕只靠人工感觉。开发者问几个问题觉得回答还不错就认为系统可用。但真实用户的问题会复杂得多。企业级 RAG 至少要建立一套评测集。评测内容可以包括问题 标准答案 期望引用文档 用户角色 租户信息 问题类型 难度等级评测指标可以包括检索命中率 引用准确率 答案正确率 幻觉率 拒答准确率 权限过滤正确率 平均延迟 平均成本这样每次改 Chunk 策略、Embedding 模型、Rerank 模型、Prompt 模板或检索参数时都能知道效果是变好了还是变差了。没有评测RAG 优化就会变成玄学。有了评测RAG 才能持续迭代。可观测性层出问题时要能复盘企业级 RAG 不可能永远不出问题。关键是出问题时能不能查。一次 RAG 请求最好记录这些信息request_id user_id 的脱敏标识 tenant_id query query rewrite 结果 召回文档 召回分数 rerank 分数 最终上下文 Prompt 版本 模型名称 生成答案 引用来源 token 成本 延迟 错误信息当然日志不能无脑记录所有敏感内容。企业环境里要考虑脱敏、访问控制和日志保留周期。但如果完全没有日志问题就很难复盘。用户说“这个答案不对”你必须能知道是没有召回正确文档 还是召回了但排序靠后 还是 Prompt 没约束住 还是资料本身过期 还是用户没有权限看到正确资料可观测性不是上线后的装饰。它是 RAG 系统能够被维护的前提。GraphRAG 和 Agentic RAG 放在哪里GraphRAG 和 Agentic RAG 不是普通 RAG 的替代品。它们更像是在特定场景下的增强能力。GraphRAG 更适合处理实体关系复杂 跨文档关联明显 需要全局知识结构 需要回答整体性问题比如组织关系、产品依赖、知识图谱、政策关系、项目网络。Agentic RAG 更适合处理问题复杂 需要多步检索 需要工具调用 需要动态规划 需要根据中间结果继续追问比如复杂分析、诊断排查、跨系统查询、流程型任务。但不管是 GraphRAG 还是 Agentic RAG都不能跳过基础能力。如果数据层混乱、权限层缺失、评测层没有、日志层不可查那么再复杂的 RAG 形态也会变得不稳定。所以更合理的理解是普通 RAG 是基础闭环 Hybrid Search 和 Rerank 提升检索质量 GraphRAG 强化关系理解 Agentic RAG 强化动态决策 企业级能力保障上线运行企业级 RAG 的完整分层把前面内容合起来一个企业级 RAG 系统可以分成几层。数据接入层 文档解析、清洗、切分、版本管理 索引层 Embedding、向量索引、关键词索引、metadata 检索层 Query Rewrite、Hybrid Search、Filter、Rerank、上下文压缩 生成层 Prompt 模板、引用、拒答、答案结构化、复杂问题处理 权限层 用户、角色、部门、租户、知识空间、ACL 评测层 测试集、检索评测、答案评测、回归测试 观测层 日志、指标、链路追踪、成本统计、错误分析 运营层 知识更新、文档下线、租户配额、人工反馈、持续优化这套分层不是要求一开始全部做完。而是告诉你RAG 从 Demo 到生产会逐渐遇到这些问题。系统越早把边界设计清楚后面越容易扩展。从 Demo 到企业级的演进路线一个比较稳妥的演进路线可以是第一步跑通最小闭环。先完成文档入库、Embedding、检索和生成。第二步优化文档切分和数据清洗。解决脏数据、重复数据、格式丢失和 Chunk 混乱问题。第三步提升检索质量。引入 Hybrid Search、Rerank、Query Rewrite 和上下文压缩。第四步加强生成约束。管理 Prompt 模板加入引用、拒答和输出格式规范。第五步补齐企业能力。加入权限、多租户、成本统计、配额和数据删除机制。第六步建立评测和可观测性。让每次优化都有指标让每次问题都能复盘。第七步根据场景引入 GraphRAG 或 Agentic RAG。不是为了追新而是为了解决普通 RAG 确实解决不好的问题。常见误区第一个误区是以为换一个更强模型就能解决所有问题。模型很重要但如果检索不到正确资料模型再强也只能猜。第二个误区是只关注向量数据库。向量数据库只是索引和检索的一部分不等于整个 RAG 系统。第三个误区是忽略权限和租户边界。企业知识库最怕的不是回答慢而是回答了不该看的内容。第四个误区是没有评测。没有评测系统优化只能靠感觉。第五个误区是没有日志。没有日志系统出问题后只能猜。第六个误区是过早复杂化。不是所有场景都需要 GraphRAG 或 Agentic RAG。先把普通 RAG 的基础能力做好再根据真实问题扩展。总结RAG 的核心价值是让大模型能够使用外部知识回答问题。但企业级 RAG 的核心价值不只是回答问题。它还要让知识可管理、检索可优化、答案可约束、权限可控制、成本可计算、效果可评测、问题可追踪。普通 RAG 解决“能不能回答”。企业级 RAG 解决“能不能长期、稳定、可信地服务真实业务”。这也是整个 RAG 实战进阶系列想表达的主线不要只把 RAG 当成一个模型调用技巧。要把它当成一个完整的 AI 应用工程系统。当数据、检索、生成、权限、评测、成本和可观测性这些能力逐步补齐之后RAG 才真正从 Demo 走向生产。