为什么知识库第一轮测试不该只用演示问题?
因为演示问题通常过于标准,测不出真实用户问法、跨文档问题和越界回答这些真正会上线后暴露的问题。
围绕真实问题清单、回源能力和边界问题测试,整理知识库上线前最该先做的一轮验证。
知识库刚搭好时,最容易出现一种假象:你问它几个自己早就知道答案的问题,它答得还行,于是就以为可以上线了。真正的问题通常会在真实用户提问里暴露出来,比如问法不标准、上下文不完整、问题跨了两个文档,或者答案里看起来像对,其实没回到原文。第一轮测试如果不做真问题,后面上线基本就是把问题留给用户。
所以测试起点应该是“真实问题清单”,而不是“系统演示样例”。把客服常见问法、业务同事最常问的问题、用户留言、历史搜索词先拉一批出来,再开始测。
第一轮最先看的,不是答案写得漂不漂亮,而是它到底有没有回到正确来源。无论你用的是 NotebookLM、Dify 还是别的知识库产品,只要回答里缺少稳定的回源依据,后面看起来再顺都不够稳。
测试时可以先问最基础的事实型问题,比如价格、规则、步骤、版本差异、支持范围。然后看两件事:回答是否来自正确文档,引用位置是否真能支撑当前结论。回源一旦不稳,后面继续调 prompt 通常只是在表面润色。
回源没问题以后,再开始测边界。边界测试重点不是刁难系统,而是确认它什么时候该答、什么时候该收。比较值得先测的有三类:
这三类最容易把一个“演示时还不错”的知识库打回原形。只要边界一测就开始乱答,说明上线前还需要继续补资料、调切片或收窄回答范围。
第一轮真实问题最好别混在一起。可以先分成基础事实题、流程题、定位题和边界题。基础事实题用来测回源,流程题看步骤有没有漏,定位题看它能不能把你带到正确资料,边界题看它会不会瞎补。分层以后,你更容易判断问题到底出在召回、切片还是回答策略。
如果你已经在用 Dify,这一步可以直接接它的 retrieval testing 思路去做;如果你用的是 NotebookLM,也一样要保留这份问题清单,因为工具不同,测试逻辑并不会变。
最少要留四样东西:问题原文、回答结果、引用或来源判断、你的处理结论。处理结论最好也别只写“对”或“错”,而是标清楚是资料缺失、切片问题、回答越界,还是提问本身含糊。
只有这份记录留住了,后面你才知道下一轮该补资料、改结构还是改提示词。否则每一轮看起来都像重新来过。
知识库上线前最该做的,不是再多堆几篇资料,而是先拿真实问题把回源和边界打清楚。第一轮测得越扎实,后面上线后越不容易被几个看似简单的问题直接击穿。
因为演示问题通常过于标准,测不出真实用户问法、跨文档问题和越界回答这些真正会上线后暴露的问题。
最先看回源能力,也就是回答有没有回到正确文档和正确位置;这一层不稳,后面的答案再流畅也不可靠。
13 分钟阅读