案例 03 · DocuMind:给 500 人公司用的企业 RAG 知识库
一句话点题:本案例练的是「可信 AI 问答」——RAG 不是把文档丢给 AI,而是把可授权、可检索、可引用、可评测的证据交给 AI,让它基于资料回答,不知道就说不知道。
🧪 案例篇第 3 篇 · 本案例只练一件事
练企业 RAG 知识库下的架构判断:什么时候该用 RAG 而不是长上下文 / 微调,文档怎么切块和入库,向量 / 关键词 / 知识图谱检索怎么配合,以及如何控制幻觉、权限泄露、提示注入和 token 成本。
读完你应该能 本案例靠什么练 说清 RAG 系统为什么不是简单聊天框 拆开离线文档入库和在线检索生成两条链路 判断切块、向量检索、关键词检索、知识图谱检索、重排怎么配合 用混合检索 + Graph RAG + 重排 + 引用兜住答案质量 把权限和引用放进架构,不是事后补丁 在块级元数据里保存 ACL,生成时强制引用来源 看懂 AI 系统怎么做质量回归 用评测集、检索指标、引用命中率、拒答率持续压住退化 重要提醒:下面是教学化案例,不是某个企业知识库产品的内部图纸。 数字用于数量级推理,目的是练判断,不是给出唯一答案。
开场:为什么企业知识库不是「接个大模型」就完了
因为企业里最常见的 AI 需求,不是写一个万能机器人,而是让员工少翻文档、少问同事、少踩旧坑。
DocuMind 是一家 500 人公司的内部知识库助手。公司有产品手册、客服 SOP、销售方案、合同模板、技术 Runbook、人事制度、会议纪要。员工希望直接问:「企业版退款规则是什么?」「这个客户能不能走特殊折扣?」「线上故障升级流程怎么走?」
第一眼看,这像是一个聊天框:
- 用户输入问题;
- 系统查一查文档;
- 大模型生成答案;
- 页面展示结果。
但真正上线后,最危险的不是「回答慢一点」,而是:
AI 一本正经地答错,引用不存在的资料,或者把 HR / 法务 / 客户私密文档泄露给没有权限的人。
所以这一章不写「怎么调一个模型 API」。它问一个更具体的问题:
如何让 AI 只基于当前用户有权限看到的资料回答,并且每个关键结论都能指回原文?
这章和前两章的压力源完全不同:
读前小词典
这篇会反复出现几个词,先用人话对齐一下:
| 词 | 人话解释 |
|---|---|
| RAG | Retrieval-Augmented Generation,检索增强生成。先查资料,再让大模型基于查到的资料回答。 |
| LLM | Large Language Model,大语言模型。可以理解成负责读材料、组织答案的模型。 |
| Token | 模型处理文本的基本单位。字越多、资料塞得越多,token 越多,成本和延迟越高。 |
| Embedding | 把一段文字变成一串数字向量,让系统能按语义相似度搜索。 |
| Chunk | 文档块。把长文档切成小段,每段独立建索引和检索。 |
| 向量库 | 专门存向量并找「语义最相近」内容的数据库。 |
| 知识图谱 | 把知识整理成「实体 + 关系」的网。比如「客户 A 属于集团 B」「合同 C 包含条款 D」。 |
| 实体 / 关系 | 实体是人、产品、客户、合同、系统等对象;关系是它们之间的连接,比如「负责」「依赖」「适用」「属于」。 |
| Graph RAG / 知识图谱 RAG | 先在知识图谱里找相关实体和关系,再结合文档块生成答案。它擅长回答「谁和谁有关」「规则怎么传导」「这个客户是否适用某条政策」这类关系问题。 |
| 关键词检索 / BM25 | 传统搜索方式。BM25 是一种常见排序算法,对人名、产品型号、合同编号这类精确词很有用。 |
| 混合检索 | 向量检索 + 关键词检索一起用。一个懂语义,一个懂精确词。 |
| 重排 / Rerank | 先召回一批候选文档块,再用更精细的模型重新排序,挑真正能回答问题的几块。 |
| Top-K | 最终取前 K 个结果。比如 top-6 就是只把最相关的 6 个文档块交给模型。 |
| 引用 / Citation | 答案后面标出依据来自哪份文档、哪一段。没有引用的企业问答很难信。 |
| 幻觉 | 模型编出看起来合理但没有依据的内容。 |
| 提示注入 | 文档或用户输入里藏着「忽略之前规则」之类的恶意指令,诱导模型越权或乱答。 |
| ACL | Access Control List,访问控制列表。记录谁能看哪份文档。 |
| 评测集 | 一批标准问题、标准资料和期望答案,用来检测系统改动后有没有变差。 |
一、起始状态:先跑通可信问答,别先造大平台
DocuMind 的第一版目标很朴素:让员工问常见政策、产品和流程问题时,能得到带来源的答案。
起始阶段的约束大概是这样:
| 维度 | 起始阶段 |
|---|---|
| 试点用户 | 50～100 人 |
| 文档规模 | 5,000～20,000 份 |
| 文档来源 | 网盘、内部 Wiki、PDF、Word、网页 |
| 每日问答 | 500～2,000 次 |
| 峰值问答 | 1～3 QPS |
| 团队规模 | 3～5 名工程师 |
| 核心目标 | 证明员工愿意用,且答案有据可查 |
| 最不能错 | 无权限资料不能被检索进答案;没有依据时不能编 |
这时最合理的架构不是自研大模型,也不是一开始就搞复杂 Agent,而是托管大模型 API + 简单 RAG 管线 + 清晰权限元数据 + 评测集:
文档源
│
▼
┌────────────────────────────────────────────┐
│ 离线入库管线 │
│ 解析 → 清洗 → 切块 → 权限元数据 → 向量化 │
└──────────────┬─────────────────────────────┘
▼
┌──────────────────┐
│ 知识索引 │
│ 向量 + 关键词 + 元数据│
└────────┬─────────┘
│
用户提问 ▼
│ ┌──────────────────┐
└────▶│ 在线问答服务 │
│ 鉴权 → 检索 → 重排 │
│ 组装上下文 → LLM │
│ 引用校验 → 返回答案 │
└──────────────────┘这不是「简单套壳」。RAG 的难点不在聊天框,而在聊天框后面的证据链。
二、量化假设:它不是被 QPS 压垮,而是被质量压垮
先算一笔账。假设 DocuMind 在公司内部推广半年后:
员工数:500
活跃用户:300
文档总数:80,000
活跃知识源:产品文档、客服 SOP、法务模板、销售资料、技术 Runbook、人事制度
平均每份文档:3,000～8,000 tokens
切块大小:500～800 tokens,重叠 80～120 tokens
文档块数量:40 万～100 万
每日新增 / 更新文档:500～1,500 份
每日问答:5,000～15,000 次
峰值问答:5～10 QPS
检索目标:800ms 内完成召回 + 重排
检索质量:Recall@20 ≥ 85%,重排后 top-5 命中率 ≥ 75%
回答目标:首字 < 2s,完整答案 P95 < 10s
质量目标:高频问题引用命中率 > 95%,无依据问题拒答率 > 90%
安全目标:未授权 chunk 进入模型上下文次数 = 0
成本目标:每次回答只喂必要证据,不把整篇文档塞进上下文这个 QPS 对普通 Web 服务并不高。真正会拖垮系统的是另外四件事:
- 检索不准:明明有答案,却没找到正确文档块。
- 上下文污染:找到了相似内容,但不是能回答问题的内容,模型被噪音带偏。
- 权限错误:用户没有权限看的内容被检索出来,最终出现在答案里。
- 质量不可见:换了模型、改了切块、调了 prompt 后,答案变差却没人知道。
所以 DocuMind 的架构重心不是「怎么抗 10 万 QPS」,而是:
把答案质量、证据来源、权限边界和成本预算做成系统结构,不要指望模型自己永远乖。
三、触发信号:什么时候说明第一版开始不够用
第一版跑起来后,不要凭感觉升级。看这些信号:
| 信号 | 表现 | 为什么这是架构问题 |
|---|---|---|
| 答案没有引用 | 用户问政策,AI 给出一段很像真的话,但没有来源 | 企业场景里,不可核验的答案很难信 |
| 引用是错的 | 引用了 A 文档,但答案其实来自模型猜测 | 生成和证据没有绑定,需要引用校验 |
| 精确词搜不到 | 产品型号、合同编号、人名经常搜偏 | 纯向量检索不擅长精确匹配,需要关键词检索 |
| 权限过滤太晚 | 先检索出敏感块,再在前端隐藏 | 敏感内容已经进入模型上下文,泄露已经发生 |
| 文档更新后仍答旧规则 | 新政策上传了,系统还引用旧版本 | 入库管线缺少版本、增量更新和索引新鲜度指标 |
| 提示注入生效 | 文档里写「忽略系统规则」,模型真的照做 | 检索内容被当成可信指令,没有隔离外部文本 |
| token 成本上涨 | 每次回答塞 20 个大块,账单快速膨胀 | 缺少 top-K、摘要、缓存和模型路由 |
| 改动后质量变差 | 换了切块策略后,没人知道召回率掉了 | 没有评测集和回归门禁 |
这些信号不是在说「模型还不够强」。它们在说:证据链和控制面还没有架构化。
四、核心矛盾:AI 会说话,但企业要证据
DocuMind 的核心对象不是「聊天消息」这么简单,而是三组东西:
- 文档 / 文档块 / 版本:资料从哪里来、现在是哪一版、切成了哪些块。
- 权限 / 元数据 / 来源:谁能看、属于哪个部门、引用时能不能回到原文。
- 问题 / 检索结果 / 答案 / 评测记录:用户问了什么、找到了什么、模型基于什么回答、结果好不好。
如果只看最简单路径,它像这样:
用户问题 → 向量检索 → 找几段文档 → 塞给 LLM → 返回答案但真实系统必须在每一步都回答:
- 这个用户有权限看哪些文档?
- 文档块是不是最新版本?
- 这几块真的能回答问题,还是只是语义相似?
- 答案里的每个关键结论能不能指回引用?
- 检索到的文档里如果有恶意指令,模型会不会照做?
- 这次回答花了多少 token,值不值得?
所以新的架构命题变成:
不要把 RAG 当成「向量搜索 + 大模型」,而要把它当成一条证据生产线。
证据生产线有两条链路:
离线链路:文档 → 解析 → 切块 → 权限元数据 → 向量 / 关键词索引
在线链路:问题 → 鉴权 → 检索 → 重排 → 组装证据 → 生成 → 引用校验 → 记录评测离线链路决定「资料能不能被正确找到」。在线链路决定「找到的资料能不能被安全、节制、可核验地交给模型」。
五、方案推演:检索到底怎么做
这是本案例最重要的决策。很多 RAG 原型失败,不是模型不够强,而是检索路线太天真。
方案 A:长上下文,把相关文档整篇塞给模型
用户问题 + 整篇产品手册 + 整篇政策文档 → LLM| 优点 | 代价 |
|---|---|
| 实现最简单,不用维护复杂索引 | 文档一多就塞不下,成本和延迟迅速上升 |
| 小规模演示效果可能不错 | 噪音多,模型容易忽略真正关键段落 |
方案 B:纯向量检索
问题向量 → 向量库 top-K → LLM| 优点 | 代价 |
|---|---|
| 能按语义找相近内容,搭建快 | 对编号、人名、产品型号、条款号不稳定 |
| 适合问法和文档表达不完全一致的场景 | 「相似」不等于「能回答」,容易召回看起来像但不够准的块 |
方案 C:混合检索 + 重排 + 引用约束
问题
├─▶ 向量检索:找语义相近
├─▶ 关键词检索:找精确词
└─▶ 合并候选 → 重排 → top-K 证据块 → LLM → 引用校验| 优点 | 代价 |
|---|---|
| 兼顾语义和精确词,生产质量更稳 | 组件更多,需要调参和评测 |
| 重排能把「像」筛成「真相关」 | 延迟和成本会增加,要控制候选数量 |
| 引用约束让答案可核验 | 需要保存块 ID、文档版本、来源位置 |
方案 D:知识图谱 RAG,先找实体和关系,再找证据文档
问题:这个客户能不能走企业版特殊折扣?
├─▶ 实体识别:客户、集团、合同、产品线、地区、销售 owner
├─▶ 图谱查询:客户 → 所属集团 → 合同 → 适用条款 → 审批规则
├─▶ 文档检索:围绕这些实体和条款找原文证据
└─▶ LLM:基于图谱关系 + 文档引用生成答案| 优点 | 代价 |
|---|---|
| 擅长跨文档、多跳关系问题,比如客户归属、系统依赖、政策适用范围 | 建图成本高,要做实体抽取、关系抽取、消歧和持续更新 |
| 能把「为什么适用 / 不适用」讲清楚,不只返回相似文档 | 图谱错了会把答案带偏,而且错误更隐蔽 |
| 对权限、版本、血缘追踪更清楚 | 图谱节点和边也要有权限与来源,否则照样会泄露 |
知识图谱 RAG 不是「比向量 RAG 更高级,所以一定要上」。它适合这些信号出现之后再加:
- 用户经常问「A 和 B 有什么关系」「这个客户归哪个集团」「这个服务依赖哪些系统」。
- 答案需要跨多份文档推理,单个 chunk 很难直接回答。
- 组织里已经有比较稳定的主数据,比如客户、合同、产品、系统、人员、部门。
- 业务更关心关系链和适用性,而不只是找一段原文。
把几条路线并排看:
| 方案 | 擅长 | 不擅长 | 什么时候上 |
|---|---|---|---|
| 向量 RAG | 问法不同但意思相近 | 精确编号、复杂关系 | MVP 和大多数普通文档问答的起点 |
| 混合 RAG | 语义 + 精确词 | 跨文档关系推理 | 生产级企业知识库主线 |
| Graph RAG | 实体关系、政策适用、依赖链、影响分析 | 图谱构建成本高,关系抽错会误导答案 | 关系问题变多、人工排查成本高、评测证明普通 RAG 到顶后再上 |
DocuMind 第一阶段选择:混合检索 + 重排 + 强制引用;知识图谱 RAG 作为关系密集场景的第二阶段增强,不一开始全量建图。
关键不在「有没有向量库」,而在于:
检索结果必须同时满足相关性、权限、版本、关系正确性和成本预算。只满足语义相似,不够。
六、关键架构决策:用 ADR 把为什么留下来
ADR 是 Architecture Decision Record,可以理解成「架构决策记录」。AI 系统最容易在后面被人问:「为什么不微调?为什么不用长上下文?为什么必须引用?为什么要做评测?」这些都应该提前写下来。
ADR-01:采用 RAG,不把企业知识写进模型参数
- 背景:公司文档经常更新,很多内容有权限边界,并且答案必须可溯源。
- 选择:用 RAG。文档保存在企业侧,提问时只检索当前用户有权限的相关片段,再交给模型生成。
- 放弃:放弃第一阶段微调模型来记住企业知识;也放弃每次把整篇资料塞进长上下文。
- 换来:资料可更新、答案可引用、权限可控制、成本更可控。
- 风险:回答质量高度依赖检索质量。检索错,模型也会错。
- 复审条件:如果只是固定语气 / 格式问题,可以考虑微调;如果知识量极少且固定,可以考虑长上下文;如果知识快速变化且要引用,RAG 仍是主线。
ADR-02:文档入库必须可重放,并保存块级权限、来源和版本
- 背景:企业文档不是所有人都能看,而且同一政策可能有多个版本。
- 选择:文档解析后按结构切块;每个 chunk 保存
source_id、doc_id、doc_version、chunk_version、source_url、section、acl、updated_at、parser_status等元数据;解析、切块、embedding、索引都可以按版本重放;解析失败的文档进入隔离队列,不进线上索引。 - 放弃:放弃只存一段裸文本和向量的简单做法。
- 换来:检索时可以先按权限和版本过滤,引用能回到原文,旧版本可以下线;如果切块策略或 embedding 模型变了,可以可靠重建索引。
- 风险:入库管线更复杂,解析、切块、权限同步都可能出错。
- 复审条件:如果权限模型变复杂,要把 ACL 同步和索引更新做成独立可靠管线,并增加权限回归测试。
ADR-03:答案必须经过引用约束、拒答策略和评测回归
- 背景:企业不怕 AI 说「不知道」,怕它没有依据却说得很肯定。
- 选择:生成 prompt 明确要求只基于证据块回答;每个关键结论带引用;没有足够证据时拒答;每次改模型、prompt、切块、检索参数前跑评测集。
- 放弃:放弃「只要回答自然就行」的体验优先路线。
- 换来:答案可核验,质量退化可发现,高风险问题更安全。
- 风险:拒答率可能上升,用户会觉得系统不够聪明。
- 复审条件:当拒答过多时,先查检索召回和文档覆盖,不要直接放宽模型约束。
ADR-04:知识图谱 RAG 只先覆盖关系密集领域
- 背景:DocuMind 后期会遇到很多关系型问题,比如「这个客户属于哪个集团」「某系统故障会影响哪些产品」「某条政策适用于哪些合同」。这些问题靠单个相似文档块很难稳定回答。
- 选择:先在客户、合同、产品、系统依赖这几类稳定主数据上建轻量知识图谱;图谱节点和边必须保存来源、版本、ACL 和置信度;在线检索时先用图谱找实体关系,再回到原文 chunk 做引用。
- 放弃:放弃第一天从所有文档里自动抽取全公司知识图谱。
- 换来:跨文档关系问题更稳,答案能解释「为什么相关」,也能追溯关系来自哪份资料。
- 风险:实体抽取和关系抽取会错;图谱过期后会系统性误导答案。
- 复审条件:当关系型问题占比高、主数据稳定、并且普通混合检索经常答不清关系链时,再扩大图谱范围。
七、演进后的结构与数据流
下面只画 DocuMind 的核心结构。它不是一个聊天框,而是一套离线 + 在线的证据系统。
起始路径
用户问题
└─▶ 生成问题向量
└─▶ 向量库 top-5
└─▶ 拼进 prompt
└─▶ LLM 回答问题是:权限、版本、精确词、引用、评测都没有被固定住,一旦文档和用户多起来就会失控。
演进后的结构
════════════ 离线:把文档变成可检索证据 ════════════
文档源
PDF / Word / Wiki / 网页 / 表格
│
▼
┌──────────────────────────────────────────────┐
│ 入库管线 │
│ 解析 / OCR → 清洗 → 结构化切块 → 权限元数据 │
│ → embedding → 实体/关系抽取 → 写索引 │
└───────────────┬──────────────────────────────┘
▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 原始文档存储 │ │ 向量索引 │ │ 关键词索引 │ │ 图谱索引 │
│ 文件 + 版本 │ │ chunk + ACL │ │ chunk + ACL │ │ entity/edge │
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘
════════════ 在线:把问题变成可引用答案 ════════════
用户问题
│
▼
┌──────────────────────────────────────────────┐
│ 在线问答服务 │
│ 鉴权 → 查询改写 → 实体识别/图谱扩展(可选) │
│ → 权限过滤检索 → 混合召回 │
│ → 重排 → 证据组装 → LLM 生成 → 引用校验 → 记录日志 │
└───────────────┬──────────────────────────────┘
▼
带引用答案 / 拒答这张图的核心变化不是「多接了一个模型」,而是结构变清楚了:
- 入库管线负责把不同格式文档变成干净、可检索、带权限的证据块。
- 向量索引负责语义召回,解决「问法和文档措辞不同」。
- 关键词索引负责精确词召回,解决「型号、编号、人名、条款号」。
- 图谱索引负责关系召回,解决「客户属于谁、政策适用于谁、系统依赖谁」。
- 重排器负责从一批候选里挑真正能回答问题的块。
- 证据组装器控制 top-K、token 预算、来源格式,避免把噪音塞给模型。
- 引用校验和评测日志让答案质量可检查、可回归。
跟一次「企业版退款规则」提问走到底
1. 员工问:企业版客户退款规则是什么?
2. 在线问答服务完成鉴权,拿到 user_id、部门、角色、可访问文档范围。
3. 查询改写把问题补成更适合检索的形式,比如「企业版 退款 政策 合同 取消」。
4. 向量检索召回语义相近的政策 / 合同块。
5. 关键词检索召回包含「企业版」「退款」「取消」的精确命中文档块。
6. 两路候选合并去重,并且只保留当前用户有权限看的 chunk。
7. 重排器从几十个候选里选出最能回答问题的 5～8 个证据块。
8. 证据组装器把块 ID、文档标题、版本、段落位置和正文一起放进 prompt。
9. LLM 只允许基于这些证据回答,每个关键结论必须带引用。
10. 引用校验确认引用 ID 真实存在,且来自本次检索结果。
11. 如果证据不足,系统返回「当前资料中没有找到足够依据」,而不是编。
12. 系统记录问题、检索结果、引用、token、延迟、用户反馈,进入评测和排障。这里的关键点:
- 权限过滤要发生在检索和组装上下文之前,不能等答案生成后再遮。
- 引用必须指向真实 chunk 和文档版本,不能让模型自由编来源。
- 检索到的文档内容是证据,不是指令。文档里的「忽略系统规则」不能生效。
- 没有证据时拒答是正确行为,不是失败。
- 每次回答都要留下检索和生成日志,否则质量问题无法复盘。
八、坏了怎么办:故障场景与兜底
| 故障 | 直接后果 | 检测方式 | 架构兜底 |
|---|---|---|---|
| 文档解析丢表格 | 价格、限制、例外条款丢失 | 解析抽样检查、表格覆盖率 | 对表格单独抽取;关键文档人工验收 |
| 解析失败文档仍入库 | 乱码或半截内容被当成证据 | parser_status、乱码率、抽样检查 | 失败文档进入隔离队列,修复后重放入库 |
| 切块太大 | 检索块噪音多,模型抓错重点 | 命中块人工评审、token 异常 | 按标题 / 段落结构切块,限制块大小 |
| 切块太小 | 召回片段缺上下文,答案断章取义 | 答案引用不完整、用户反馈 | 加重叠,为块补充标题和父级章节 |
| 纯向量检索漏掉精确词 | 合同编号、产品型号、人名搜不到 | 精确查询评测集召回率低 | 加关键词检索 / BM25,再做混合召回 |
| 权限过滤太晚 | 敏感文档进入模型上下文 | 权限穿透测试、日志审计 | 检索阶段按 ACL 过滤;chunk 级保存权限 |
| 文档版本过期 | AI 引用旧政策 | 索引新鲜度、旧版本命中率 | 文档版本化,旧 chunk 下线,增量重建索引 |
| 提示注入生效 | 文档诱导模型越权或乱答 | 红队测试、注入样本评测 | 将检索内容标注为不可信证据;系统指令和证据隔离 |
| 实体抽取错误 | 把客户、产品、合同关系连错 | 图谱抽样验收、实体消歧评测 | 低置信关系不入线上图谱;关键实体人工审核 |
| 图谱关系过期 | 政策适用关系引用旧规则 | 关系更新时间、旧版本命中率 | 关系带版本和来源 chunk;文档下线时同步下线关系 |
| 图谱权限过滤遗漏 | 用户通过关系路径看到无权实体 | 权限穿透测试、图谱查询审计 | 图谱节点和边都带 ACL;检索前过滤,不是生成后遮挡 |
| 图谱路径无原文证据 | 答案看似有推理链但无法核验 | 路径引用校验失败率 | 每条关系必须能回到来源 chunk;缺来源只能作为线索,不能作为答案依据 |
| 引用被编造 | 答案看似有来源但查不到 | 引用 ID 校验失败率 | 只允许引用本次检索 chunk;生成后校验 |
| 没证据还硬答 | 幻觉造成错误决策 | 无答案问题评测、用户反馈 | 证据不足就拒答;提高召回而不是放松约束 |
| 成本突然上涨 | token 账单失控、延迟变高 | 每问 token、top-K、上下文长度 | 限制 top-K,缓存热门问答,简单问题走小模型 |
| 超过预算仍硬生成 | 单次问题烧穿预算,还可能很慢 | 单问预算、用户 / 部门配额 | 超预算时返回相关资料列表、走小模型摘要或转人工 |
| 改动后质量退化 | prompt / 模型 / 切块升级后答案变差 | CI 跑评测集、线上 A/B | 评测不过不发布;保留回滚版本 |
| 向量索引不可用 | 问答失败或大量超时 | 检索错误率、依赖健康检查 | 降级到关键词搜索;必要时只返回资料列表不生成答案 |
企业 RAG 的成熟度,不是看回答多像人,而是看它错的时候能不能被发现、被限制、被修复。
📌 拿模板验证这次推演
本案例不是重写 RAG 模板,而是把「企业内部知识库」里最容易被低估的几条边界拿出来细推。
| 可复用模板 / 章节 | 本案例复用什么 | 本案例重点补什么 |
|---|---|---|
| RAG 知识库 | 文档入库、切块、向量化、检索、重排、引用 | 用企业权限、版本、新鲜度和评测把 RAG 讲成可上线系统 |
| AI 对话产品 | LLM 编排、上下文组装、token 成本、安全护栏 | 说明聊天框只是入口,证据链才是核心 |
| 向量数据库 | 向量索引、相似度检索、元数据过滤 | 强调相似不等于相关,必须配合关键词和重排 |
| 搜索引擎 | 关键词检索、排序、权限过滤 | 把 BM25 这类传统搜索能力拉回 RAG 主链路 |
| 大模型时代的架构判断 | 非确定性、上下文工程、成本 / 延迟 / 质量三角 | 把这些抽象判断落到企业知识库问答 |
| 评测驱动 | 用评测集定义「够好」 | 让检索、引用、拒答都能回归 |
读法建议:先读本章,再回看 RAG 知识库模板。你会更容易看懂:RAG 的重点不是「模型更聪明」,而是「证据更可靠」。
🎯 随堂检验
企业 RAG 知识库最应该优先保证什么?
- A回答听起来越自然越好,有没有来源不重要
- B只基于当前用户有权限看到的资料回答,并且关键结论能引用到原文
- C把所有文档都塞进模型上下文,让模型自己判断
为什么生产级 RAG 通常不只用纯向量检索?
- A因为向量检索完全没用
- B因为向量擅长语义相似,但对编号、人名、产品型号、条款号这类精确词不稳定,需要关键词检索和重排补上
- C因为关键词检索一定比向量检索更智能
检索到的文档片段里如果写着「忽略系统规则」,系统应该怎么处理?
- A照做,因为文档是知识库内容
- B把检索内容当作不可信证据,只允许它提供事实,不能覆盖系统指令
- C直接删除所有包含命令语气的文档
Graph RAG 和普通向量 RAG 的关系,更准确的说法是?
- AGraph RAG 会替代所有向量检索
- BGraph RAG 是在 RAG 里增加实体关系检索,适合关系型问题,但仍要回到原文证据和引用
- CGraph RAG 只要建好图谱,就不需要权限和评测
本案例小结
- RAG 不是把文档丢给 AI,而是搭一条证据生产线。 离线链路负责把文档变成可检索证据,在线链路负责把问题变成可引用答案。
- 它不会先被 QPS 压垮,会先被质量压垮。 检索不准、引用错误、权限越界、评测缺失,比 10 QPS 更危险。
- 纯向量检索不够。 企业知识库里有大量编号、人名、条款号和专有名词,混合检索 + 重排通常更稳。
- Graph RAG 是增强检索,不是银弹。 当问题核心从「找相似段落」变成「找实体关系和适用路径」时,知识图谱能补上普通 RAG 的短板;但它同时引入抽取、更新、权限和评测成本。
- 权限要在检索前生效。 敏感块一旦进入模型上下文,就不能靠前端隐藏来补救。
- 没有证据就拒答。 企业 AI 的成熟不是永远有话说,而是在证据不足时敢于说不知道。
- 评测是架构的一部分。 切块、模型、prompt、重排任何一处改动,都可能让质量退化;没有评测集就无法稳定演进。
承上启下:这一章把 RAG 知识库模板 落到一个企业内部产品。下一章如果继续写实时聊天 / 协同系统,压力会再次变化:重点会从答案可信,转向长连接、消息时序、离线投递和多人编辑冲突。
相关链接
- 模板对照:RAG 知识库 · AI 对话产品 · 向量数据库 · 搜索引擎
- 方法论:02 · 架构师的思考框架 · 17 · 大模型时代的架构判断 · 22 · AI 原生系统设计
- 硬骨头:16 · 安全与多租户架构 · 25 · 评测驱动
💬 评论