> For the complete documentation index, see [llms.txt](https://doc.duaer.com/zh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.duaer.com/zh/guides/enterprise-rag-knowledge-base-build.md).

# 企业RAG知识库搭建：2027年多数项目为何答不准

本文整理自 Duaer 文档站，围绕企业 RAG 知识库为何「演示可用、日常不敢用」展开，从知识治理、切块检索、评测回归到权限合规，给出可以逐步落地的排查顺序。

## 从演示到日常：问题出在哪里

很多企业在过去一两年里搭起了第一个 RAG 知识库：把制度手册、产品文档和客服话术切块、向量化，接上大模型，演示时问答很顺畅。可一旦放进真实业务，同事很快会发现问题。问「报销标准现在是哪一版」，它引用的是两年前的旧文件；问「这个客户的合同能不能打折」，它会自信地给出一段看似合理、实际不存在的条款。项目于是停在「演示可用、日常不敢用」的尴尬状态。问题往往不在模型本身，而在知识的底座和检索链路。

企业的知识散落在共享盘、Wiki、邮件、工单系统，还有某位资深员工的脑子里。把文件批量导入，只完成了「收集」这一步，离「可用」还差很远。文件之间常有版本冲突，同一项制度可能同时存在三份草稿；有效期不清楚，已经废止的文件仍留在库里；权限也没有同步，导入之后，不该看到薪酬或合同细节的人，可能通过检索拿到敏感内容。RAG 的回答质量上限，很大程度上由这些底层条件决定，模型再强也无法凭空校正错误的源文件。

我们此前写过一篇关于企业知识库 AI 化的文章，核心观点同样是先治理数据、再谈问答。如果你的团队还没有想清楚哪些文件才是现行版本，可以先读一读那篇内容，把治理的顺序排清楚。

## 两个常见误区

误区一：把「上传文档」当成「建知识库」。不少团队的验收标准是「文档数量多少、向量化是否完成」。这些指标容易量化，却与业务价值关系不大。更关键的问题是：每份文档有没有明确的负责人，多久更新一次，适用于哪个业务线，能否判断它是不是现行版本。

一个更务实的做法是，入库前先做一次轻量盘点。让业务负责人列出最常被问到的几十个核心问题，然后倒推每个问题应该由哪份文档回答。对于找不到对应文档、或者对应文档已经无人维护的问题，先标记为「知识缺口」，而不是急着把所有材料都塞进去。知识库的第一版，宁可小而准，也不要大而乱。

误区二：只调模型，不调切块与检索。很多团队遇到答不准的情况，第一反应是换一个更大的模型。但切块方式（按固定字数硬切，还是按章节语义切）、元数据设计（部门、生效日期、产品线）、以及检索策略（纯向量检索还是关键词加向量的混合检索），这些环节对准确率的影响，往往比换模型更直接。

一个典型现象是：正确答案其实已经被检索到了，但切块时把关键条款拆在两段，模型只拿到半句话，于是它只能「补全」，幻觉就这样产生。这种错误换模型解决不了，需要回到切块规则和元数据上去修。

## 怎么做才对：先建评测集，再谈优化

在调任何参数之前，先由业务人员整理一批真实问题，数量可以从几十条起步，逐步扩充到一两百条。每条问题标注标准答案和依据出处。这份评测集就是团队的尺子。之后每次修改切块、更换嵌入模型、调整提示词，都用同一批问题回归测试，看命中率和答案正确率是上升还是下降。

没有评测集，团队只能凭感觉说「好像变好了」，这种判断很难经得起管理层追问。评测集还有一个附带收益：它会逼着业务方把「什么算对」讲清楚，这往往比技术本身更耗时，也更有价值。

如果你希望把「文档治理、切块入库、评测回归」串成一条可以反复执行的流程，可以直接到 Duaer 里把这套流程跑起来，把文档、问题集和评测记录放在同一个工作台中。这是产品推荐，你可以对照自己的团队规模和现有系统，判断它是否适合你。

## 权限与合规：答得对，还要答得「该答」

企业知识库不是对所有人开放的公共问答。部门权限、客户数据、敏感合同需要在检索层过滤，而不是寄希望于模型「自觉不说」。正确的做法是把权限校验放在模型生成之前，只让有权限的用户检索到有权限的文档。同时，记录每次回答引用了哪些文件，既方便审计，也便于在出现错误时追溯源头。

对于涉及敏感数据的场景，还需要提前确认部署位置和数据流向，明确哪些内容允许进入外部模型服务，哪些必须留在内部环境。这些问题越早厘清，后期返工的成本越低。

## 怎么衡量：别只看「用户满意」

满意度调研容易失真，用户可能因为「这个工具很新」就给高分，也可能因为一次糟糕的回答而全盘否定。建议至少跟踪四个更具体的指标：检索命中率（正确文档是否进入候选集）、答案准确率（抽样人工判定）、引用可追溯率（回答是否附带可核对的依据）、无答案拒答率（知识库里没有相关内容时，系统是否老实说不知道）。

此外，还可以关注「被纠正次数」。当用户反复指出某类回答有误时，通常说明知识库中存在过时内容或切块缺陷，这是修复优先级最清晰的信号。

## 本周就做这一件事

不必急于选型或采购。请业务负责人从一个业务域出发，拉出最常被问到的三十个问题，逐一找到目前认定的现行版本文档，并标出每份文档的责任人和最近更新时间。找不到的，单独列成「知识缺口」清单。这一步不需要任何技术投入，却能让后续的切块、检索和评测都有据可依。

如果你已经完成了这份清单，想尽快验证知识库的回答效果，欢迎到 https://www.duaer.com 注册试用，用你们自己的问题和文档跑一轮评测，看看结果是否与你的判断一致。企业 RAG 知识库真正难的，不是把文件变成向量，而是让知识本身变得可信、可更新、可追溯。把这件事想清楚，模型只是最后一步。

## 常见问题

### 企业 RAG 知识库回答不准，应该先换模型还是先改数据？

通常应先检查数据与检索链路。先确认文档是否为现行版本、有效期和负责人是否清楚，再检查切块是否把关键条款拆散、元数据和检索策略是否合理。很多幻觉源于正确答案已被检索到却因切块被截断，这类问题换更大的模型无法解决。

### 上线前需要准备哪些评测指标？

建议至少跟踪检索命中率、答案准确率、引用可追溯率和无答案拒答率。评测集应由业务人员标注标准答案和依据出处，每次修改切块、嵌入模型或提示词后用同一批问题回归测试，而不是只依赖用户满意度。

### 如何保证知识库只把内容提供给有权限的人？

应在检索层做权限过滤，并在模型生成之前完成校验，而不是依赖模型自行判断是否应该回答。同时要记录每次回答引用的文件，便于审计和追溯。涉及敏感数据时，还需提前确认部署位置和数据流向。