企业知识库问答助手从 0 到 1（DEMO 复盘）

示例内容（DEMO） — 本文为站点功能验证用的占位内容，发布前将整体替换。

背景

这是一个虚构的示例场景，用于演示案例复盘的写法。设定如下：一家中型 B 端企业，内部文档分散在网盘、Wiki 和聊天记录里，新员工找一条报销规则平均要问三个人。管理层希望用一个知识库问答助手把"找答案"的成本降下来。项目从 0 开始，由一名产品经理（也就是这个示例里的"我"）牵头。

约束

数据不能出内网，只能私有化部署，可选的模型和算力都受限。
团队很小：一名产品、两名工程师，没有专职算法。
文档质量参差不齐：大量过期版本、互相矛盾的规定、扫描件。
预期是一个季度内看到可用版本。

约束决定了打法：不可能追求技术上限，只能追求在限定条件下"可信且可用"。

核心问题

立项时大家讨论的是"用哪个模型"，但真正的核心问题是另一个：用户敢不敢信这个系统的答案。 企业场景里一次自信的错误回答（比如答错一条休假政策），比十次"我不知道"造成的伤害都大。所以问题被重新定义为：在文档质量不可控的前提下，如何让系统的每一个回答都可追溯、可验证。

判断过程

决策点一：先灌全量文档，还是先治理一小批

备选项有两个：把所有文档一次性灌进去快速出效果；或者先选一个高频域（如人事制度）做文档清洗后小范围上线。前者演示效果好，后者上线慢。我选了后者。理由是：垃圾进垃圾出在 RAG 上体现得最直接，全量灌入换来的"快"是借来的，错误答案造成的信任损失要花数倍时间偿还。

决策点二：检索方案选型

纯向量检索对企业文档里大量的专有名词、编号、表格并不友好。当时对比了三个方向：

方案	优点	缺点	结论
纯向量检索	语义泛化好，实现简单	专名、编号、缩写命中差	不采用
纯关键词检索	精确匹配强，结果可解释	用户换个说法就查不到	不采用
混合检索加重排	兼顾语义与精确匹配	链路复杂，调参成本高	采用

取舍理由：企业问答里"查准"优先于"查全"，混合检索的复杂度是为可信度付的成本，值得。

决策点三：答案生成允不允许"拒答"

备选项：让模型尽量给出答案，保证体验流畅；或者强制每个答案附带原文引用，检索置信度不足时直接拒答并转人工。我选了带拒答的方案。工程同学一度反对，认为拒答率高会让产品显得"笨"。我的判断是：拒答在企业场景是功能而非缺陷，一个诚实说"不知道"的系统才有机会积累信任；体验问题可以靠后续补文档解决，信任崩塌没法靠迭代挽回。

解决方案

最终方案可以概括为四层：

文档治理先行：按高频域分批接入，每批先做去重、版本清理和负责人确认。
混合检索：关键词与向量双路召回，重排后再进入生成环节。
引用与拒答机制：每条回答强制带原文出处；置信度不足时拒答并给出转人工入口。
反馈闭环：用户对答案点踩会进入待办，由文档负责人修订源文档，而不是去改提示词。

灰度策略上，先对一个部门开放，用两周收集真实问句扩充评测集，再逐步放量。

结果

以下为占位写法，具体数字以真实项目数据替换：

检索命中率从基线提升至可接受水平——具体数字以真实项目数据替换。
高频域的重复人工咨询量出现可感知的下降——具体数字以真实项目数据替换。
拒答率随文档补全持续走低，且未发生因错误回答引发的责任事故。

定性看，最重要的结果不是指标，而是业务部门开始主动要求接入自己的文档域——系统赢得了最初的信任。

复盘

数据治理比模型选型重要一个量级。 这个示例项目里大部分体验提升来自删掉过期文档，而不是更换检索算法。
拒答是设计出来的能力。 敢于不回答，反而是 B 端问答产品建立信任的起点。
评测集是最值钱的资产。 真实问句加人工标注的对错，比任何离线榜单都更能指导迭代。
没做好的地方：早期低估了文档负责人机制的推动成本，跨部门确认文档归属花的时间远超预期。下次会在立项阶段就把这件事写进合作约定。