知识库上线即死，错在没做用户测试

一、核心结论：你的知识库不是“不好用”，是“根本不是给人用的”

去年我帮一家中型 SaaS 公司做知识库诊断，他们技术负责人开场第一句话就把我震住了：“我们 RAG 系统的上下文精确率已经做到 92% 了，但用户满意度评分只有 2.1。”

我问他：“这 92% 是在什么环境测的？”

他说：“我们内部用 200 条测试问句跑的，每条都标了标准答案。”

我又问：“你们找过真实用户，让他在不被告知答案的情况下，用自己习惯的提问方式测过吗？”

他停顿了大概五秒钟，说：“没有。”

这不是个例。过去 18 个月，我先后接触过 14 个企业知识库项目，从金融合规到电商售后，从医疗文献到政务办事指南。一个反复出现的模式是：技术团队对自己搭建的系统信心满满，上线三个月后访问量断崖下跌，最终变成“只维护不迭代”的僵尸项目。

根因只有一个：他们在“上线”之前做的所有测试，本质上都是期末考试，用预设的标准答案，考系统能不能复述教材。但用户从来不按教材提问。

知识库上线即死，错在没做用户测试，注意，我说的不是“没做测试”，而是“没做用户测试”。这两者之间的鸿沟，就是 92% 精确率和 2.1 分满意度的鸿沟。

二、你所谓“测过了”，在用户眼里一文不值

在深入拆解之前，我需要先把一个概念说清楚：绝大多数知识库项目团队所说的“测试”，和本文主张的“用户测试”，根本不是同一件事。

这张表我建议你截屏保留。因为它解释了为什么“我们明明测过了啊”是知识库项目里最危险的幻觉。

技术测试的逻辑是：系统正确映射了输入 A 到输出 B，通过。

用户测试的逻辑是：用户带着真实困惑进来，带着明确下一步行动离开，才算通过。中间的认知摩擦越小越好，最好为零。

三、拆开看看：用户到底是怎么“用死”一个知识库的

我最近做的一个案例是某连锁零售企业，他们的内部知识库面向 3000 多名门店员工，内容涵盖排班规则、退货流程、促销政策、工伤申报等。

技术团队很用心，Embedding 模型选的是当时社区评分最高的，切片策略调到 512 token，检索阶段加了重排序模型。测试集上跑出来准确率 89%。

上线第一周，数据就崩了。不是系统崩，是用户行为崩：

• 搜索转化率（搜了之后点击答案的比例）：从第一天的 61% 跌到第七天的 19%
• 人工客服转接率：比上线前反而上升了 8 个百分点
• 最触目惊心的数据：后台显示用户输入的搜索词里，有 47% 是纯口语或情绪表达，比如“那玩意咋退”“什么鬼排班老子看不懂”

技术团队在做测试时，从来没有设想过用户会说“那玩意咋退”。他们只测过“请描述退货流程”。

这不是 RAG 系统的失败，这是提问假设的失败。

四、你以为用户在“检索”，其实用户在“求助”

这里有必要引入一个我自己的判断框架。我把企业知识库的用户场景分为三个层级：

L1：图书馆模式，用户明确知道自己在找什么，能用精准关键词描述。比如“2024 版《反洗钱合规操作指引》”。这类用户占比通常不超过 15%。

L2：导航模式，用户知道自己的目标是“办成一件事”，但不知道这件事在系统里叫啥。比如“我要报销上次去杭州的差旅”，但他不知道标准说法是“差旅费用报销申请”。这类用户占比最大，通常在 60%-70%。

L3：无助模式，用户遇到突发问题，情绪焦躁，连“自己想干嘛”都说不利索。比如“客户说他卡里扣了钱但没到账我该怎么办这也不是我部门的事啊”。这类占比约 15%-20%。

传统知识库测试只测了 L1 场景。因为测试人员拿着标准问题集，天然就是 L1 型用户。

但真实流量 80% 以上来自 L2 和 L3。

这意味着什么呢？你在测一个和你真实用户完全不重叠的场景。你测出来的精确率、召回率，是实验室里的风洞数据，不是路上跑的油耗。

五、不是不做 RAG 评测，而是要先做“用户提问行为测试”

我并不是要否定技术评测的价值。RAG 系统的链路评测，包括检索的精确率和召回率、生成答案的忠实度和相关性，当然要做，而且要做到位。

但问题出在顺序上。

绝大多数项目的节奏是：搭好系统→内部技术评测→上线→等用户反馈→（通常是）等来一片沉默或差评。

我建议的节奏是反过来的：

第一步：在技术团队还没开始写评测脚本之前，先找 5-8 个真实用户，不做任何培训，让他们在自然工作状态下，讲讲他们最近遇到的几个需要查制度、查流程、查知识的场景。录音，转文字，然后仔细看，他们到底是怎么说话的。

你会发现，用户从来不关心你的知识库叫“企业智慧大脑”还是“智能问答引擎”。他们只关心：“我现在这个事儿，你给我一句准话，告诉我下一步按哪个按钮。”

第二步：基于用户的原声，构建真实提问集，而不是标准提问集。

我在那个零售企业的项目里做了这件事。我把用户原话抄下来，包括那些带脏字、带情绪、句子结构被打断的，直接喂给系统测。精确率从 89% 掉到了 51%。

技术负责人脸都白了。

但这个 51% 才是真实的 51%。测出 89% 一点用没有，因为你上线那天面对的不是那 200 条标准问句，而是 3000 个精疲力尽、只想赶紧下班的店员。

第三步：用“一句话准则”重构答案标准。

用户不需要一个完整的知识条目被复述。他们需要的是一个可直接执行的行动指令。

不是告诉他：“根据《门店退货管理规范》第 2.3 节，顾客如要求退货需满足以下三个条件：……”

而是告诉他：“告诉顾客，拿着小票和没拆封的商品到收银台，三分钟内办完。”

测试标准也应该随之改变。不要用“答案是否涵盖了知识库中的相关内容”来打分，要用“用户看完之后是否能准确说出下一步操作”来打分。我把它叫“行动触发率”。

六、用户测试不是什么玄学，是可以工程化的

我理解，一说“用户测试”，很多技术团队会觉得这是产品经理那些玄乎的“定性研究”，无法量化，不好考核。

其实完全可以工程化。我在实际项目里用的是一套“轻量化用户可用性量化表”，很简单，但足够用：

环节 1：理解成功率

用户问完问题，系统返回答案。测试员（或者后面做自动化）看用户的第一反应。如果用户需要再看一遍、眉头皱起、或者喃喃自语“啥意思”，判定为理解失败。

• 目标：低于 2 秒的表情犹豫，即为理解成功。
• 测量方式：录屏 + 回放，或用眼动仪（预算允许时），最省钱的做法是事后立刻追问用户：“你能用你自己的话说一遍刚才系统告诉了你什么吗？”

环节 2：操作转化率

用户看完答案后，是否能立刻执行下一步。这一步最关键，因为企业知识库的终极价值不是“知道”，而是“做到”。

• 测试方式：给定场景，如“请根据系统指引完成这张报销单的填写”，看用户能否在不回头再问的情况下独立完成。

环节 3：追问率 / 负面情绪表达率

记录用户在看完答案后，是否选择：

• 再次输入新的问题（追问）
• 切换到人工客服
• 直接关掉页面（可能意味着放弃）
• 或者在对话中表达出明显负面情绪（如“什么鬼”“算了”“没用”）

这三个环节的数据，比任何技术评测指标都更接近老板真正关心的那个东西，这个系统到底有没有让人更省力。

我在两个项目里把“完成任务所需时间”做为核心考核指标提给管理层，结果都获得了比技术报告更大的信任和更多预算支持。因为管理层听不懂精确率，但他们听得懂“员工平均处理一次退货的时间从 6 分钟降到了 90 秒”。

七、上线后的反馈闭环：把用户当老师，而不是当 bug 制造机

用户测试不是一锤子买卖。上线后按照“用户吐槽→理解需求→快速修正→再验证”循环持续优化。这是需要工程化支撑的，不是靠产品经理手动翻日志。

我在项目里推动过一个很简单的闭环机制：

1. 异常信号抓取：系统自动标记三类行为，短时间内重复提问（30 秒内同一用户再次提问）、直接转人工、用户输入中出现否定词或情绪词。

2. 人工抽检 + 归因：每周从标记池中随机抽取 50 条，由业务和产品同事一起归因。是意图识别偏了？是切片切到半句看不懂？还是答案本身在业务规则上已经过时？

3. 修复优先级排序：按影响面（高频问题优先）和修复成本（改答案 > 改切片 > 改检索策略 > 改模型）排优先级，纳入当周迭代。

这个循环跑起来之后，追问率会在 2 个月内出现肉眼可见的下降。我在零售那个项目里，追问率从上线初期的 44% 降到了第 6 周的 16%。这个过程没有任何模型升级，纯靠“用户行为驱动的答案改写和切片微调”。

八、一个让你不舒服但必须面对的现实：有时候“不给答案”比“给错答案”更好

我知道这听起来像个悖论，但我在医疗知识库和政务办事指南两个项目里反复验证过：

当系统对用户意图的置信度低于一定阈值时，直接承认“我不确定，但我建议你这样做……”，主动引导转人工或提供替代路径，比硬塞一个似是而非的答案要安全得多，用户满意度反而更高。

原因很简单。用户对“错误的、但看起来像正确答案”的容忍度，远低于“系统说我暂时处理不了这个”。

在政务办事指南项目里，我们有几类“疑难问题”是模型几乎必然会出错的，比如“我在 A 省交的社保，现在在 B 省生孩子，怎么报销”。这种问题涉及多地政策叠加、个人参保状态、具体时间节点，光靠知识库里的条文无法准确回答。

我们当时的做法是：对这类问题不强行生成答案，而是识别意图后，直接给出 B 省社保局经办窗口的电话、地址和所需材料清单，并提示“具体报销比例需以经办机构核算为准”。

用户调研反馈是：他们认为这个回复“专业且负责”，远好过之前试图给一个通用解释但经常说错。

所以用户测试的终极价值并不仅仅是“优化答案”，更是识别出系统能力的边界。知道什么时候该闭嘴，是一个成熟知识库产品的标志，而不是缺陷。

九、怎么开始？如果你现在手里就有一个“快死”的知识库

我建议你本周就做三件事：

第一，去后台拉一份最近 100 条用户真实提问记录。 不要清洗，不要转写，就用原始输入。然后一条条读，把自己当成一个疲惫的、焦虑的、手忙脚乱的人，去感受这些提问背后的真实场景。

第二，对照本文第四节的 L1/L2/L3 分层，手动给这 100 条提问打标签。 看看 L2+L3 占比是多少。如果超过 60%，你就找到了“上线即死”的第一个确定性原因。

第三，抽 10 个问题，用系统给出的答案，找 3 个不熟悉你们业务流程的同事做“操作转化测试”。 就看一件事：他们看完答案后，能不能独立完成任务。如果 10 个里面超过 5 个做不到，你的答案就不是答案，是障碍。

这三件事不需要任何技术开发成本，不需要立项评审，只需要你花半天时间。

但半天之后你会获得一个大多数人永远没有的东西，关于你用户到底是谁、他们怎么说话、他们为什么进来又离开的真实认知。

知识库上线即死，从来不是因为技术选错了模型或者切片策略不够优。是因为从一开始，所有测试都面向代码，没有面向人。而知识库存在的唯一理由，就是让人少费一点脑子。

把这个逻辑调过来，你会发现之前 90% 的优化动作都打在了棉花上；剩下那 10% 打在用户身上的，才是真正能让知识库活下来的。