把大模型直接接到企业知识库上，最常见的结局是“演示很惊艳、上线就翻车”：回答流畅但引用了错误版本的文件，或者把两个部门的流程混在一起。RAG 的难点不在调用模型，而在检索质量与工程可控性。
一、文档处理：RAG 最脏也最值钱的环节
大部分 RAG 项目效果不佳，根源在文档层。企业文档的现实是：PDF 带双栏、扫描件、带合并单元格的表格、多版本共存、大量无结构正文。
建议的处理原则：
- 保留结构信息。切分时带上标题层级、表格边界、页码，这些元数据在回答“具体在哪个章节”时必不可少。
- 表格不要按字符切。表格被拦腰切断后会变成毫无意义的片段，建议以行为最小单位或转成结构化描述。
- 带版本与生效日期。同一份制度可能有多个版本，检索时必须能过滤到当前有效版本，否则必然回答错。
- 扫描件先 OCR，并在元数据中标出“文本来自 OCR”，提示可能存在识别错误。
二、检索策略：单一向量检索往往不够
纯向量检索的长处是语义匹配，短板是专有名词、产品型号、编号这类字符串——它们的语义表示很接近，但实际完全不同。可行的组合方案：
| 方式 | 优势 | 适合的问题 |
|---|---|---|
| 向量检索 | 语义相近也能召回 | “如何处理客户退款” |
| 关键词检索 | 精确命中专有名 | 型号 A-2300 的参数 |
| 混合 + 重排序 | 兼顾两者 | 生产环境推荐默认方案 |
实践中最有效的单项改动是加一个重排序模型：先用向量或混合检索召回 50–100 条，再用重排模型精选前 5–10 条。代价是几十毫秒的额外延迟，但准确率提升通常相当明显。
三、生成环节：把“不确认”变成可交付行为
企业场景比生成质量更重要的是可控性。三项建议：
- 强制引用。要求输出带来源（文档名 + 章节 / 页码），前端可点击跳转。用户能验证，才敢用。
- 允许回答不知道。检索结果置信度低时应该直接说“未找到相关制度”，而不是让模型自由发挥。建议在提示中明确这条规则并单独评测。
- 权限过滤前置到检索层。不能先检索全文再靠提示词让模型“不要说出来”——权限必须在向量库或元数据过滤阶段就生效。
四、评测：没有评测就无法迭代
RAG 项目最容易被跳过也最不该跳过的就是评测。建议建一个 100–200 题的评测集，包含：
- 事实型问题（答案在单一文档中）
- 需多文档综合的问题
- 边界问题（知识库中确实没有）
- 容易混淆的问题（版本不同、部门不同）
指标上建议分开评两块：召回是否命中与回答是否忠实于召回内容。混在一起评测，出问题时无法定位是检索环节还是生成环节。
五、上线后的持续运营
知识库不是建完就不管的。需建立文档更新与索引重建的联动机制，否则新制度发布后机器人仍在回答旧版本。建议将索引重建纳入文档发布流程，并在界面上显示知识库的最后更新时间。
另外要准备一个低成本的人工反馈入口（点赞/纠错）。真实使用中暴露的错误问题列表，比任何自动评测集都更有价值。
