基于企业知识的 RAG AI 聊天机器人：依据您自己的文档给出准确答案

许多企业尝试用通用 AI 聊天机器人回答客户或员工的问题，结果往往失望。答案听起来很有说服力，却与公司的退货政策不符，引用已经变动的价格，或者编造从未存在的流程。原因很简单：大语言模型是用通用数据训练的，而不是用您的内部文档训练的，而且即使不知道答案，它也倾向于作答。

检索增强生成（RAG）是解决这一问题最常用的方法。系统不依赖模型的记忆，而是先检索与问题相关的公司文档片段，再让模型依据这些片段组织答案。这样得到的助手会基于您自己的资料作答，并能说明答案出自何处。

本文用通俗的语言说明 RAG 的工作原理、适合中小企业的应用场景、搭建步骤、常见错误，以及如何保护数据和衡量答案质量，帮助您判断 RAG 是否值得尝试，以及开始之前需要准备什么。

摘要

• RAG 先检索相关文档，再让模型只依据这些文档回答
• 答案质量在很大程度上取决于源文档的质量和整洁程度，而不只是模型
• 较安全的起步场景：客户帮助中心、内部 SOP 问答、产品文档检索
• 每个答案都显示来源，并在系统不确定时转交人工
• 按用户权限限制数据访问，并用固定的测试问题集衡量质量

为什么通用 AI 聊天机器人常答错业务问题

语言模型的工作方式是根据训练数据中的规律预测下一个词。除非把信息提供给它，否则它无法接触您的价格表、最新的保修政策或经销商折扣结构。没有信息时，模型仍会设法组织出听起来合理的答案。这种现象常被称为“幻觉”，在客户服务中是真实的风险。

第二个问题是知识过时。模型内部的知识停留在某个时间点，而企业不断变化：新产品、季节性促销、修订后的流程。每次文档变动都重新训练模型，对大多数公司而言既昂贵又不现实。

RAG 把这两件事分开。知识存放在易于更新的文档库中，模型只用来理解问题并组织语言。退货政策变更时，只需更新文档，下一次回答就会立即跟进。

用通俗的话说明 RAG 的工作原理

想象一位聪明但尚未熟记公司规定的新员工。每次收到问题，他会打开档案柜，抽出最相关的几页，读完后作答，并注明依据的页面。RAG 用三个步骤模仿这个习惯。

1. 01准备：把文档切分成小块，例如几个段落，再把每一块转换成称为嵌入（embedding）的数字表示，存入向量数据库或搜索索引
2. 02检索：用户提问时，问题以同样方式转换，系统取出含义最接近的片段，通常还会结合普通的关键词搜索
3. 03生成答案：把选出的片段与问题和明确的指令一起发送给模型，即只依据上下文作答，上下文中没有答案时要承认不知道

按含义搜索不同于关键词搜索。“用过的商品还能退吗”这样的问题，即使措辞不完全相同，也能找到标题为“退货条件”的部分。因此许多系统采用混合搜索，即含义与关键词相结合，使产品编码等特定术语仍能被准确找到。

适合企业的应用场景

客户帮助中心是常见的起点。关于服务时间、运费、保修申请方式或订单状态的重复问题，可以根据现有帮助文章作答。客服团队的负担减轻，客户在非工作时间也能得到答案，无需排队等待。

内部问答同样有价值。新员工经常问相同的问题：如何请假、差旅费用上限是多少、谁审批采购。依据员工手册和 SOP 作答的助手能加快入职适应，减少对人事和直属主管的打扰。

产品与技术文档检索对销售团队和技术人员有帮助。在数百页目录或手册中查找规格可能很耗时。能找到正确章节并附上链接的助手，让员工更快地用正确信息回答客户。

相反，应避免从高风险场景起步，例如提供法律或医疗建议、自动信贷决策。先从答案容易核实、出错代价小的场景开始，待了解系统的行为后再扩展。

搭建 RAG 助手的步骤

1. 确定范围和权威来源

选择一个狭窄的领域，例如关于配送与退货的问题。确定哪些文档是事实依据、由谁负责、上次检查是什么时候。没有负责人的文档容易过时并产生误导。

2. 准备并清理文档

把文档转换为干净的文本。删除重复内容，修改标题使其具有描述性，并标注生效日期。表格和图片附件需要特别留意，因为转换为文本时常常出错。类别、语言和访问级别等元数据有助于在检索阶段筛选。

3. 合理切分文档

片段太小会丢失上下文，太大则带来噪声并浪费模型容量。按自然结构，即标题和子标题来切分，通常优于按固定长度截断。保留少量重叠，避免重要句子被切断。

4. 设计指令以及不知道时的行为

给模型的指令必须明确：只依据提供的上下文作答，注明来源，如果没有相关信息，就坦率说明并提出转接人工。诚实的“我不知道”远胜于令人信服的编造答案。

5. 构建界面和转人工通道

显示来源引用，方便用户核对。提供评价答案的按钮和联系人工的按钮。对客户服务而言，这一转接通道很重要，避免复杂或带有情绪的对话被机器卡住。

常见错误

• 不加筛选地一次性索引所有文档，导致过时文档和草稿成为答案来源
• 不保存文档的日期和版本，导致系统引用旧政策
• 以为更大的模型能弥补糟糕的检索，而问题往往出在取出片段这一环节
• 缺乏持续评估，文档变更后质量下降无人察觉
• 把本应受限的文档，如薪资数据或合同，向所有用户开放
• 向客户承诺助手“无所不知”，而其范围仅限于特定领域

数据安全与隐私

公司文档常含敏感信息。把文档内容发送给第三方模型服务之前，先了解服务商关于数据存储和使用的政策，以及您的数据是否会被用于训练模型。选择与敏感程度相称的配置，必要时包括在自有环境中部署的选项。

在检索阶段实施访问控制，而不只是在显示层。也就是说，系统只能取出提问用户有权阅读的片段。否则，即使用户无权访问原始文档，助手也可能通过答案泄露受限文档的内容。

还要警惕提示注入，即文档或用户消息中的文字试图指示模型违反规则。把文档内容视为数据而不是命令，限制助手可执行的操作，未经人工批准不要赋予写入或删除权限。涉及个人数据时，请参照现行有效的数据保护规定，并咨询您的法律顾问。

衡量答案质量

整理一组测试问题，例如来自客服团队的 50 到 100 个真实问题，附上正确答案和参考文档。每次更改文档、文本切分方式或模型指令时都运行这组问题并比较结果。没有固定基准，改进只是印象。

分别评估两件事。第一，检索是否找到了正确的片段。第二，答案是否忠实于这些片段。这种区分有助于定位问题：检索失败通过文档和切分来修复，答案偏离则通过指令和模型选择来修复。

投入使用后，监控未回答的问题、负面评价，以及对话转给人工的频率。失败的问题提示了缺少哪些文档。简短的每周复盘通常足以让质量持续提升。

成本与自建还是购买

RAG 的成本由几部分组成：模型调用、存储与检索、前期工程，以及整理文档的持续工作。模型使用量通常按处理的文本量计费，因此成本随提问数量和上下文长度而变化。请根据自己的提问量估算，并在投入之前先做小规模试点。

自建还是使用现成产品取决于需求。对帮助中心这类标准场景，现成产品又快又便宜。当您需要直接连接 ERP、CRM 或订单数据、访问规则复杂，或需要通用产品不提供的工作流时，定制开发才合理。

把助手连接到业务系统

最有价值的下一步是把 RAG 与交易数据结合。“我的订单在哪里”这类问题不是靠文档回答，而是靠订单系统。可以通过 API 给助手有限的 ERP 或 CRM 只读权限，让它准确回答订单状态、库存或发票余额。先从只读访问开始，并在显示个人数据之前进行用户认证。

对于会更改数据的操作，如取消订单或修改地址，应增加明确确认和审计记录。授予的权限越大，所需的测试和监督就越严格。

一个简单的示意例子

作为假设的画面，一家家居用品店收集了 30 篇关于配送、退货、保修和付款的帮助文章。团队整理文章、加上生效日期，然后搭建一个依据这些文章作答并显示来源链接的助手。范围之外的问题，如复杂的投诉，会自动连同对话摘要转给员工。

每周团队查看未能回答的问题清单，为反复出现的空白撰写新的帮助文章，并重新运行测试集。几个月后，助手变得更有用，不是因为换了模型，而是因为文档越来越完整、整洁。这才是现实的模式：价值来自管理知识的纪律。

结语

RAG 不是魔法，也不只是把模型接到一个文档文件夹上。它是一个结合知识管理、检索、明确指令、访问控制和持续评估的系统。设计得当，就能得到一个依据您的资料作答、展示出处、不知道时坦诚相告的助手。

从小处开始：一个领域、整理好的文档、一组测试问题和转人工通道。衡量结果，改进文档，再逐步扩展。这样既能获得实际收益，又不必拿声誉去冒险依赖编造的答案。