先复述现象：用户提出一个业务问题，系统却返回另一份制度文件的内容，或者干脆答成通用常识；有时同一个问题换个说法，答案质量明显不同。这类「答非所问」通常不是单点故障，而是知识切分、检索召回、上下文组织和数据范围几层叠加的结果，需要按顺序逐层缩小范围。

排查前先固定对比口径：用同一批问题在改动前后各跑一遍，记录答案是否命中正确文档、是否引用了错误段落。这个基线比凭感觉判断「好像变好了」更有用，也是后续验收的依据。

第一步：确认答非所问是召回问题还是生成问题

大多数问答质量问题可以先用一个动作定位：把系统检索到的原文段落打印出来，人工判断正确答案是否在其中。如果正确段落根本没有被召回，问题在检索层；如果正确段落在召回结果里，答案却依然偏离，问题在上下文组织或生成环节。

这一步值得写成固定流程，而不是临时抽查。建议在测试环境保留一次检索结果快照，包含命中的文档标题、段落位置和排序，便于复现。

现象是答案引用错文档：检查文档切分与元数据

切分粒度是知识库问答里最容易被忽略的一环。段落切得过长，一段里混着多个主题，检索命中后带给生成环节的信息是噪声；切得过短，一句话被拆断，语义不完整，检索也很难准确匹配。常见做法是按标题层级和自然段切分，对表格、制度条款这类结构化内容单独处理。

元数据同样关键。文档所属部门、适用版本、生效日期如果没有随内容一起入库，检索时就无法按范围过滤，旧版制度与新版制度会同时进入候选，答案自然互相矛盾。

排查时可以先挑几条典型问题，反向查看命中的文档是否符合预期，再看切断位置是否破坏了语义。某条答案引用了完全不相关的文件，往往就是切分后片段主题漂移导致的。

需要落地方案时，可以参考我们的软件定制开发与系统集成服务，知识库通常不是独立系统，而是与原有管理系统共用文档来源和权限。

检索层的问题通常表现为两类：专有名词和编号查不到，以及近义表达查不准。前者偏向关键词匹配，后者依赖语义检索，单一策略很难覆盖。常见做法是把两路结果合并再排序，具体的权重与截断数量视语料规模而定，需要实测。

还要注意同义词与业务黑话。企业内部对同一份制度的叫法可能不止一种，如果用户常用说法在语料中没有出现，语义检索也未必稳定命中。可以考虑维护一份受控词表，与业务流程梳理一并完成。

下面是一个可以照着走的排查顺序，每一步只改一个变量，避免多因素混在一起判断：

如果答非所问表现为「给出了别的部门的规定」或「引用了已废止的文件」，问题一般不在检索算法，而在数据治理。知识库的权限模型通常需要与原系统保持一致，至少要做到检索前过滤，而不是生成后再拦截。

在政府与国企场景中，这类要求更明确。集团、分公司、部门之间的文档范围要事先梳理清楚，职责与组织同步之后再上线问答。具体做法可参考政府与国企国产化改造案例中的组织与权限梳理思路。

另外，多版本并存的知识库建议保留生效时间和失效标记，检索时默认只取当前生效版本，历史版本仅在明确查询时返回。

生成环节的常见问题是上下文过杂。塞入过多片段后，回答容易把不同文档的条款拼接在一起，或者用通用常识替代企业规定。常见做法是控制上下文数量，优先保留与问题直接相关的段落，并在回答要求中明确「仅依据给定资料作答，资料不足时应说明无法回答」。

回答格式也影响观感。要求给出出处，例如文档标题与章节位置，用户和运维人员都能据此核对，排查效率会高很多。若系统支持引用回溯，建议默认开启。

知识库来源往往分散在文件服务器、OA 附件和业务系统中，集成方式直接影响更新时效。更多实现细节可以看技术文章栏目中的实践整理，我们通常建议先打通文档来源，再谈问答效果调优。

调优工作如果没有固定的评测集，很容易变成反复微调。建议从真实咨询记录中整理一批问题，覆盖高频问法、专有名词、跨部门权限、无答案四类情况，每次改动后用同一批问题回归。

评价维度不必复杂，能回答「是否命中正确文档」「答案是否与原文一致」「是否给出出处」三项就足够支撑决策。具体通过标准由业务方确认，本文不设统一阈值。

以下清单适合在知识库问答上线前逐项确认，也适合作为运行期巡检的基础项：

知识库问答的调优更多是数据治理与工程细节的积累，而不是一次性配置。若需要从文档梳理、系统集成到上线运维整体推进，可以了解我们的服务范围与交付流程，或直接联系我们沟通具体场景。