企业知识库与 RAG：让组织知识可问、可引、可追溯

写在前面 "我们有几千份文档，想做个 AI 问答"——这是我们听到最多的开场白。但把文档丢进向量库，接个大模型，做出来的东西通常在演示时很惊艳，在真用时很难受。差距在哪，本文逐条拆开讲。

一、RAG 解决的到底是什么问题

RAG（检索增强生成）的本质很朴素：先找到相关资料，再让模型基于这些资料回答，而不是让模型凭训练时的记忆自由发挥。

它带来两个企业最在意的性质：

1. 答案有依据。 每句话都能追到具体文档的具体段落。
2. 知识可更新。 制度改了，换掉文档即可，不需要重新训练模型。

第二点常被低估。企业知识是活的——价格表在变、流程在变、组织在变。任何需要"重新训练才能更新知识"的方案，在企业里都活不长。

RAG 和"把文档全塞进上下文"的区别

有人问：现在上下文窗口这么大，直接把所有文档塞进去不就行了？

区别有三：

• 成本：每条请求都把所有文档送进去，token 消耗是指数级的。一个 50M 的文档库，每次提问花几百块的 token 费用，不现实。
• 噪声：上下文里 99% 的内容和当前问题无关，模型在噪声里找信号，准确率反而下降。
• 速度：上下文越大，推理越慢。用户等 30 秒才有答案的体验是不可接受的。

RAG 的价值是"精准定位"——从海量文档中找到和当前问题最相关的几个片段，只送这几段给模型。检索决定了 RAG 的上限。

二、切片：最不起眼、也最影响效果的一步

文档要先被切成片段才能建索引。这一步的质量直接决定了后面所有环节的上限。

常见的坑：

• 按固定字数切。一刀切在句子中间，检索出来的片段读起来是断的，模型只能猜。
• 忽略文档结构。一份制度文件的"第三章第二条"和它的标题层级是有关系的，扔掉标题只留正文，片段就失去了语境。
• 表格被压平。表格转成纯文本后，行列关系全丢，模型看到的是一堆无意义的数字。

我们的处理方式是先把各种格式统一转成结构化的 Markdown，保留标题层级、列表和表格结构，再按语义边界切片，并且给每个片段带上它所属的章节路径。这一步在我们自己的产品里由文档中台完成，支持 PDF、Word、Excel、PPT、EPUB 等格式。

切片粒度怎么定

没有"最佳字数"这个说法。粒度的选择应该基于你的内容类型：

• 制度类文档：以"条"或"款"为单位，因为一条制度就是一个完整的意思
• 技术手册：以"小节"为单位，一节说明一个功能
• FAQ 类内容：以"一个问-答对"为单位，不需要再切
• 长篇报告：以"段落组"为单位，3-5 个段落为一个切片

切片太细和太粗都伤效果，但二者的伤害方式不同。 太细：检索出来的片段信息不完整，模型基于残缺信息作答。太粗：检索出来的片段包含太多无关内容，干扰模型判断。一个好的切片应该让"看懂这一段不需要翻上下文"——这就是边界判断的基准。

三、召回：找得准比找得多重要

检索回来的片段会占满模型的上下文。塞得越多，噪声越大，模型越容易被无关内容带偏，同时成本还更高。

实际工程中需要权衡的几个点：

• 召回数量：不是越多越好。宁可少而准。我们通常从 Top-5 开始，根据实际问答效果调整。
• 语义检索 vs 关键词：产品型号、错误码、条款编号这类精确匹配的内容，纯语义检索经常会漏。混合检索（语义 + BM25 关键词）能补上这块。
• 权限过滤要在检索层做，不能在生成后再过滤。否则模型已经"看过"了不该看的内容，从答案里抹掉也来不及。

混合检索的权重怎么调

语义检索擅长"意思差不多"的匹配——"退钱"和"退款"、"取消订阅"和"终止服务"能被正确关联。关键词检索擅长精确匹配——"型号 A-200B"和"A200b"在关键词层面是两回事。

实际场景中，对于产品型号、错误码、法律条款编号，给关键词检索更高的权重；对于业务流程说明、方法论描述，给语义检索更高的权重。

四、引用溯源不是装饰

我们坚持要求所有基于知识库的回答都必须带出处，并且在系统层面做校验：回答中引用的片段编号必须真实存在，且不能越界。校验不通过的回答会被拦截。

这个机制在我们自有的知识助手产品里跑了很久，它解决的是一个很现实的问题——模型有时会"编造"一个看起来很合理的引用。没有校验，你根本不知道它编了。

对企业来说，这条的价值是：当 AI 答错时，你能快速判断责任在哪一层。是知识库里的文档本身写错了，还是检索没找对，还是模型理解偏了。三种问题的修复方式完全不同：

• 文档写错了 → 改文档、重建索引
• 检索没找对 → 调切片策略和召回参数
• 模型理解偏了 → 调提示词，或在检索结果中加入更多上下文

五、权限：企业场景绕不开的一关

个人用知识库和企业用知识库，最大的差别就是权限。

需要在设计之初就明确的问题：

• 谁能看到哪些文档？按部门、按角色、还是按项目？
• 同一份文档的不同章节是否有不同密级？
• 检索时如何保证越权内容根本不进入候选集？
• 查询行为是否需要留痕审计？

这些问题的答案会直接影响索引结构的设计。等系统建好了再补权限，通常意味着重做。

两种权限过滤方案

方案一：集中索引 + 检索后过滤。一个统一的向量索引，检索返回 Top-N 后按用户权限过滤。优点：实现简单；缺点：如果用户应该能看到的文档刚好排在 N+1 位，就被误过滤了。

方案二：分租户索引 + 检索前过滤。每个权限组建独立索引，检索在用户有权访问的索引子集内进行。优点：精度高；缺点：维护成本高，权限变更时需要重新组织索引。

选择哪个取决于权限变更的频率和复杂度。权限体系相对稳定的企业用方案一足够，权限频繁变动且粒度细的建议方案二。

六、知识运营：上线后的真正工作

知识库不是一次性工程。我们建议企业在项目开始时就确定：

没有这套机制，知识库大概三到六个月就会开始失准，然后被弃用。

一个实用的"知识健康度"指标

每月检查一次：随机抽取 50 个用户提问，人工判断 AI 的回答是否合格。合格率的变化趋势比绝对数值更能说明问题——如果连续两个月下降，说明知识库在老化。

七、典型交付流程

资料归集  →  文档解析与切片  →  向量索引构建
    →  召回与引用链路调优  →  权限与审计接入
    →  小范围试用与知识补充  →  上线与持续迭代

八、什么情况下不建议做

坦率地说，以下情况我们会建议先别急着上 RAG：

• 文档本身混乱、版本冲突、大量过期内容——先治理文档，再做 AI。
• 高频问题其实只有十几个——一个整理好的 FAQ 页面成本更低、效果更好。
• 核心需求是精确的数据查询（如"上季度华东区销售额"）——那是 Text2SQL 的活，不是 RAG 的活。

想判断你的知识现状适不适合做这件事，欢迎联系我们。我们会先看文档，再谈方案。