项目记录：用一批公开技术文档做问答测试，我整理的三类失败案例

背景

想给内部资料加一个“直接提问”的入口，动手之前先做了一次小规模测试：拿一批公开技术文档当语料，准备 30 个真实问题，看看哪些问题会答错、错在哪里。语料主要来自 前端 Wiki 的分层教程 和 万象云档按主题聚合的文档，前者概念密集、后者文档体量差异大，正好覆盖两种典型情况。

结论有点出乎意料：真正“完全答错”的很少，大部分问题出在答得不全、答得含糊、或者答案无法追溯。整理下来是三类。

第一类：跨文档才能回答，却只给了一半

典型问题：“静态页面要做哪些事才能更容易被收录？” 相关资料分散在三处：静态化实践、站点结构、以及一份收录优化指南。系统往往只抓到其中一两处，给出的答案看起来完整，实际漏掉了关键一项。

成因：检索按单段相似度取前几条，而答案天然分布在多个文档里。

处理方式：对这类问题，先在提示里显式要求“列出你参考了哪几篇文档、各自贡献了什么”，让缺失变得可见；比直接追问“还有吗”有效得多。

第二类：版本与适用范围被抹平

问某个属性怎么用，答案是对的，但没说它属于哪个版本、在哪些环境下不适用。教程站里同一主题常有新旧两篇，检索命中了旧的那一篇，模型也不会主动提示“这里可能存在版本差异”。

成因：语料缺少统一的版本标记，切片之后上下文里没有时间线索。

处理方式：入库时给每段加上来源标题与版本/日期字段，并在输出模板里固定一栏“适用前提”。这一栏强制存在后，宁可写“未标注”，也比悄悄省略安全。

第三类：答案正确但无法核对

第三类最隐蔽：内容没错，但没告诉人来自哪里。用户想复核时只能自己再去搜一遍，等于把检索成本又还给了用户。

成因：生成阶段把引用信息当作“解释性文字”省略了。

处理方式：把引用从“可选补充”改成“输出结构的必填字段”，每条结论后面跟一个来源链接。这一步做完，前面两类的排查也顺了——因为你能直接看到它到底读了哪几篇。

测试之外的一点收获

30 个问题里，失败案例的分布很不均匀：概念型问题几乎全对，操作型与跨文档型问题占了失败的绝大部分。这直接改变了后面的设计优先级：与其继续调模型，不如先把语料的元数据、切片边界和引用结构做好。

还有个附带发现——准备测试题这件事本身很值钱。为了让问题“真实”，我不得不去翻 BackendWiki 里那些带具体参数的实践条目，结果把不少模糊需求提前问清楚了。

小结与后续

这轮没上线任何功能，只产出了三份东西：30 道测试题、一张失败分类表、以及一张改动优先级清单。但比直接开做省了很多返工。如果只能留一条经验，那就是：先把“怎么算答错了”定义清楚，再谈怎么让它答对。