别让 AI 靠“记忆”回答：给团队资料加上查证能力的 RAG 入门

原文链接

让 AI 先翻资料再开口：RAG 知识库问答实战

很多人第一次接触 RAG（Retrieval-Augmented Generation，检索增强生成）时，会把它理解成：

“把公司文档喂给 AI，让它记住。”

这不够准确。

更贴切的说法是：RAG 让 AI 在回答问题前，先去你的知识库里查资料，再根据查到的内容组织答案。

它解决的不是“模型有没有背下资料”，而是“回答时能不能找到正确、当前且有权限查看的依据”。

这对职场人尤其重要。真正棘手的问题，往往不缺一个会写字的 AI，而是缺一个能回答下面这些问题、并说清依据在哪里的助手：

• 最新报销标准是什么？
• 这个项目的接口字段为什么这样设计？
• 客户遇到某个错误码，应该走哪套处理流程？
• 去年的制度还有效吗，还是已被新版文件替代？

如果 AI 只凭通用知识和语言能力回答，它可能写得很像那么回事；如果它先查内部资料，并附上引用片段，你才有机会核对它是否靠谱。

一句话理解：RAG 是“先查后答”，不是“永久记住”

RAG 可以拆成两件事：

• Retrieval（检索）：从文档、Wiki、制度库、产品手册、代码库等外部资料中，找出与问题最相关的片段。
• Augmented Generation（增强生成）：把这些片段连同用户问题一起交给大语言模型，让模型基于资料生成回答。

它把信息检索系统和生成式模型连起来：检索系统负责找依据，模型负责理解、归纳、解释和表达。[1]

它和几个常见做法有什么区别？

做法	核心动作	适合什么	不擅长什么
提示词	在对话里说明任务、格式和边界	规定“怎么答”	无法持续管理大量资料
普通文件上传	临时把文件放进一次对话上下文	阅读、摘要单个或少量文件	可复用、更新和检索能力取决于具体产品
RAG	回答前自动检索知识库，再生成答案	制度库、项目文档、客服知识、代码说明	不能保证原始资料本身正确
模型微调	用数据继续训练，让模型权重改变	固定任务风格、分类规则、特定输出模式	不适合频繁更新的事实资料

可以把它们记成一句话：

提示词规定任务，RAG 提供依据，微调改变模型习惯。

当资料经常更新时，通常不需要为了新增一份制度或发布一个版本说明而重新训练模型；更新知识库并让系统重新索引，往往更符合 RAG 的使用方式。[2]

用一个职场问题，看懂 RAG 怎样工作

假设团队有两份文件：

1. 《差旅报销制度（2025 年版）》：住宿上限为每天 800 元。
2. 《差旅报销制度（2026 年 4 月修订版）》：一线城市住宿上限调整为每天 1,000 元，并明确旧版废止。

员工问：“我下周去上海出差，酒店最多能报多少？”

没有 RAG 的普通聊天模型，可能依据常见经验给出一个数字，也可能混淆旧资料。

一个设计较完整的 RAG 系统，理想流程则是：

1. 接收问题：识别“上海”“出差”“酒店”“报销上限”等信息。
2. 检索资料：从制度库中找相关段落，同时按地区、文档日期和版本状态筛选。
3. 重排结果：把最可能直接回答问题的片段排到前面，降低无关内容混入上下文的概率。
4. 组装上下文：将新版制度中的关键条款、文档标题、日期和版本信息交给模型。
5. 生成回答：模型输出“上海属于一线城市，住宿标准上限为每天 1,000 元”，并标明依据文件。
6. 展示来源：用户可打开引用片段，核对“1,000 元”是否真在原文中，以及文件是否仍有效。

重点不在于模型“变得更聪明”，而在于它被要求先获得可核对的上下文，再回答。准备资料、切分、索引、检索、上下文组装和评测，都是 RAG 落地中需要分别设计的环节。[3]

RAG 最适合解决哪些问题？

判断标准很简单：答案是否主要藏在一批特定资料里，而且资料需要持续更新、追溯和治理。

1. 团队制度与流程问答

• 问题：请假、采购、报销、入职、信息安全流程怎么走？
• 资料：员工手册、制度文件、流程图、FAQ。
• 价值：减少反复咨询行政、人事和业务负责人，也降低“口口相传版本不一致”的问题。

2. 项目文档与产品知识问答

• 问题：某接口为什么弃用？某功能的边界条件是什么？
• 资料：需求文档、技术设计、会议纪要、变更记录、API 文档。
• 价值：帮助新成员快速定位结论及其背景，而不是只靠搜索关键词和询问资深同事拼凑上下文。

3. 客服与支持知识检索

• 问题：客户反馈某功能不可用，应如何排查？
• 资料：帮助中心、产品手册、故障公告、工单处理规范。
• 价值：让回复更一致；但例外情况、高风险承诺和实际处置仍需要人工判断。

4. 代码库辅助理解

• 问题：这个服务为什么依赖某个队列？某个错误码在哪里处理？
• 资料：代码、README、架构说明、构建日志、历史故障复盘。
• 价值：帮助开发者更快建立上下文；但不能替代代码审查、测试和真实运行验证。

公开案例中，Morgan Stanley 将内部 AI 助手用于帮助顾问检索内部知识，并在上线前使用评测框架验证具体场景。[4] 对高要求知识场景来说，能答不等于可以直接投入使用。

RAG 为什么仍然会答错？

RAG 能降低部分无依据生成的风险，但不能消除幻觉，更不能自动修复混乱的资料库。

1. 检索错了：找到了“相似内容”，却不是答案

员工问“上海住宿上限”，系统却找到了“上海交通补贴”或“北京住宿标准”。模型拿到的上下文不对，写得再流畅也没有意义。

2. 切分坏了：关键条件被拆散

长文档通常会被拆成多个片段后建立索引。若一个片段只保留“上限为 1,000 元”，却把“仅限一线城市”和“2026 年 4 月起执行”拆到别处，模型可能遗漏限制条件。

固定长度切分实现简单，但可能切断语义；按标题、段落或句子结构切分，通常更有利于保留上下文。复杂 PDF、表格和扫描件还可能在解析阶段就丢失信息。[5]

3. 资料旧了：系统认真引用了过期文件

RAG 不会自动理解“旧制度已经失效”。如果旧版和新版都在库里，却没有版本、发布日期、有效状态等元数据，系统可能把旧文件排在前面。

所以，RAG 不是知识治理的替代品，而是会放大知识治理质量的系统。

4. 版本冲突：两份文件都像是真的

同一规则可能同时存在于公告、部门补充说明和正式制度中。若没有权威来源优先级，模型会面对冲突上下文，并可能擅自“折中”。

更可靠的做法是预先规定规则：正式制度优先于聊天记录，新版本优先于旧版本，指定部门文件优先于非正式转载。

5. 权限漏了：不该看见的内容被检索出来

企业知识库的权限控制不能只放在聊天页面。用户的问题一旦触发检索，系统就可能把无权查看的文档片段交给模型。

更稳妥的做法是把用户身份、部门、项目、地域或文档密级等信息带入检索过滤，让“不能检索到”发生在生成回答之前。[6]

6. 模型多说了：资料只说 A，它却推到 B

检索片段可能只说明“此政策适用于正式员工”，模型却补充出“实习生也适用”。这是看似合理、实则没有依据的推断。

因此，RAG 回答最好明确区分：

• 原文明确写了什么；
• 根据原文可以做什么有限解释；
• 资料没有覆盖什么，系统应当说“不知道”。

关键词、向量、混合检索：不必懂算法，也该知道怎么选

RAG 的“查资料”不只有一种方式。对普通使用者而言，理解三种检索逻辑就足够了。

检索方式	它怎么找	更适合的问题	常见短板
关键词检索	找名称、词语、编号的直接匹配	错误码、制度编号、产品型号、人名、接口字段	换一种说法，可能找不到
向量检索	找语义相近的表达	同义提问、自然语言描述、概念解释	容易找“意思相近但不够精确”的内容
混合检索	同时运行关键词与语义检索，再合并排序	大多数企业文档问答	配置和评测复杂度更高

例如，“ERR-429 如何处理”更需要关键词精确命中；“请求太频繁导致服务被拒绝怎么办”则适合补充语义检索。混合检索的价值，就是同时照顾术语精确性和自然语言表达差异。[7]

如果结果很多，还可以加入“重排”：先广泛找候选片段，再用更针对问题的方式排序，最后只把少数高相关片段交给模型。这能减少无关资料挤占上下文，但通常也会增加一定的延迟和成本。

不要只问“答案对不对”：用这 5 步检查可信度

一个 RAG 系统最容易制造的错觉是：它带了引用，所以一定可靠。

其实，引用存在不等于引用支持结论。你可以用下面这套检查法：

1. 看引用片段是否直接回答问题：不要只看标题相关，要看原文是否包含关键条件、数字或结论。
2. 回到原文核对：确认系统没有断章取义，尤其是表格脚注、例外条款和适用范围。
3. 确认时间与版本：询问文档的发布日期、版本号和生效状态。
4. 识别模型推断：要求它标注“原文事实”和“基于原文的解释”，不要把推断伪装成规定。
5. 测试无答案问题：故意问资料库没有覆盖的问题，观察系统会不会诚实回答“当前知识库没有足够依据”。

评估 RAG 不能只看最终回答是否流畅。还应分别检查：检索结果是否相关、上下文是否足够、回答是否忠实于资料、回答是否真正解决问题，以及引用能否支撑对应结论。[3]

一个普通人也能完成的低成本试验

不需要先采购企业级平台，也不需要一开始就导入全公司的文件。

先做一个小实验，目标不是“证明 AI 很厉害”，而是回答：这批资料是否值得做成可检索知识库？

试验材料

• 选取 10—20 份主题明确、允许处理的资料，例如公开产品文档、个人项目笔记，或已脱敏的团队流程样本。
• 只聚焦一个主题，例如“新人入职流程”或“某产品售后规则”。
• 为每份资料补上标题、日期、版本、来源和适用范围。

设计 10 个测试问题

测试题不要全是能直接复制原文的简单题。建议至少包括：

• 直接事实题：标准金额、步骤、负责人是谁？
• 同义表达题：不用原文关键词提问，能否找到相同规则？
• 跨文档整合题：需要同时参考两份资料才能回答的问题。
• 版本题：新版与旧版存在差异时，能否优先引用正确版本？
• 无答案题：资料里根本没有的信息，系统会不会拒答或提示补充资料？

记录四个结果

检查项	你要记录什么
检索命中	找到的片段是否真的包含答案
回答完整	是否遗漏条件、例外或步骤
引用准确	引用是否支持这句话，而不是只“看起来相关”
版本正确	是否使用当前有效的资料

再把同一批问题分别交给“无检索的普通对话”和“带资料检索的对话”回答。重点不是追求一个漂亮总分，而是找出失败集中在哪里：资料质量、切分方式、检索策略，还是模型表述越界。

可复用：知识库搭建与维护清单

资料准备

• [ ] 明确知识库要回答什么问题，而不是先把所有文件一股脑导入。
• [ ] 为每类资料指定权威来源和负责人。
• [ ] 删除重复、失效、无法确认来源的文件。
• [ ] 把扫描件、截图型 PDF、缺失表格的文档单独标记，避免误以为已被完整解析。

切分与元数据

• [ ] 尽量按标题、章节、段落等业务结构切分，而不是只按字数硬切。
• [ ] 让每个片段保留足够上下文：标题、所属章节、文件名。
• [ ] 至少记录日期、版本、部门、文档状态、适用范围。
• [ ] 对制度类内容标记“现行”“废止”“草案”等状态。

权限与安全

• [ ] 明确哪些人可以检索哪些资料。
• [ ] 在检索阶段过滤权限，而非只在界面层做隐藏。
• [ ] 对敏感字段、个人信息、客户数据建立脱敏或排除规则。
• [ ] 在接入外部模型或第三方平台前，确认数据留存、使用范围和组织审批要求。

更新与版本

• [ ] 新文件发布时有增量更新流程。
• [ ] 文件废止或修订时，旧版本能被下架、标记或降权。
• [ ] 定期检查高频问题对应的引用是否仍然有效。
• [ ] 记录“最后更新时间”，让用户知道答案的新鲜度。

评测与失败反馈

• [ ] 保留一组固定测试题，覆盖事实、同义、版本、跨文档和无答案问题。
• [ ] 每次调整切分、检索或模型后重复测试。
• [ ] 给用户提供“引用不对”“答案过期”“资料缺失”的反馈入口。
• [ ] 将高频失败问题回流到资料治理或检索优化，而不是只靠改提示词遮掩。

什么时候不该用 RAG？

RAG 不是“只要有 AI 就该加”的组件。以下情况，先别急着建知识库：

1. 资料很少：如果只有一两页稳定内容，直接放进提示词或对话上下文可能更简单。
2. 问题主要依赖实时数据：例如库存、订单状态、账户余额、当天价格。应优先直接连接数据库、搜索服务或业务 API，让模型解释结果，而不是依赖静态文档。
3. 问题主要是计算或执行：例如税费计算、排班优化、审批动作。需要确定性规则、计算引擎或工作流系统，而不是只做文档检索。
4. 资料本身没有治理：来源混乱、版本不明、权限不清时，RAG 只会更快地传播混乱。
5. 不能接受“有依据但仍可能答错”：在高风险场景中，RAG 应作为辅助检索与解释层，仍需人工复核、规则校验和正式流程兜底。

结语：RAG 的价值，是把“回答”变成可核对的工作流

RAG 不会让 AI 自动变成你公司的专家，也不会替你整理混乱的资料。

但当资料范围清晰、版本可控、权限正确、检索能命中、回答带来源，并且系统经得起测试时，它能把很多“到处找人问”的问题，变成一次可追溯的自助查询。

所以，评估 RAG 时不要先问：

“它能不能回答所有问题？”

而要问：

“它是否能在该查资料的问题上，找到正确版本、给出真实依据，并在不知道时停止编造？”

这才是一个知识库型 AI 助手真正值得投入的标准。

参考资料

1. Google Cloud：Retrieval-augmented generation（RAG）
2. Google Cloud：Fine-tuning LLMs and AI models
3. Microsoft Learn：Design and Develop a RAG Solution on Azure
4. OpenAI：Morgan Stanley uses AI evals to shape the future of financial services
5. Microsoft Learn：Develop a RAG Solution — Chunking Phase
6. Microsoft Learn：RAG and Generative AI — Azure AI Search
7. Microsoft Learn：Develop a RAG Solution — Information-Retrieval Phase