研发知识问答答非所问，通常不是模型本身能力不足，而是回答依据与问题没有对上：知识库里缺少对应的规范、接口或项目历史文档，文档切分和元数据让正确片段检索不到，问题中的项目名、版本、模块等限定词没有被识别，或者检索到的旧版本片段被优先采用。排查时先确认知识是否存在，再验证检索命中的片段，最后检查问题表述与版本口径，逐层排除后再判断是否为生成环节的问题。
要点总览（TL;DR）
- 答非所问先分两类：检索到但答偏，以及检索不到后自由发挥；前者查切分、元数据、限定词与版本，后者查知识是否存在、是否可检索、权限是否可见。
- 排查按层推进：知识是否存在→检索是否命中→问题限定词是否被利用→版本口径是否一致→生成是否偏离，每层都要拿到命中片段原文、文档更新时间、权限配置等可观察证据再下结论。
- 处置按原因对应：补文档并确认入库、调整切分与标签后小范围重建索引、提问带上项目与版本限定词、归档过期规范、要求回答附引用。
- 批量改文档结构或重建索引前先备份，选一个小项目空间或小批文档验证，命中片段无明显改善就暂停并回到切分层重新分析。
- 用排查初期记录的问题清单回归验证，看命中片段是否对应、回答是否附引用；建立典型问题集与文档入库归档责任人，把每次答偏回流为文档补充或切分规则调整。
答非所问的典型表现与影响范围
“答非所问”是一个笼统感受，落到可排查的层面，需要先把它拆成几种可观察的症状。不同症状指向的原因层不同，混在一起讨论会让排查失去方向。
常见的症状可以归为四类。第一类是答成通用概念：问的是“本项目的接口鉴权规范”，回答却讲了一遍鉴权的一般原理，没有落到项目实际约定。第二类是答成其他项目或旧版本：内容本身是真实的规范，但属于另一个项目空间或上一版接口。第三类是答成相邻模块：问订单服务的超时配置，回答给了支付服务的重试策略，两者在文档结构上相邻。第四类是检索为空后自行编造：知识库里没有对应内容，回答却给出了看似完整、实际无出处的结论。
这四类症状背后其实是两类现象。前三类属于“检索到但答偏”，系统确实召回了片段，只是片段与问题不匹配；第四类属于“检索不到”，没有可用依据，回答退化为生成模型的自由发挥。区分这两类现象是后续排查的分水岭：前者要查切分、元数据、限定词和版本，后者要查知识是否存在、是否在可检索范围内、权限是否可见。
影响范围同样需要记录清楚，它决定了排查的起点。可以按四个粒度确认：是单个问题偶发，还是某一类文档（如接口文档）普遍答偏；是某个项目空间内的问答异常，还是全部问答都出现偏差。单个问题偶发，优先怀疑问题表述和该问题的知识覆盖；某类文档普遍答偏，优先怀疑这类文档的切分与元数据；某个项目空间异常，优先怀疑该空间的文档入库状态与权限；全部问答偏差，则需要检查索引整体状态与问答配置。
建议在排查开始前做一份简单记录：问题原文、期望答案、实际回答、是否给出引用、影响范围判断。这份记录既是症状分类的依据，也是后续回归验证的基线。
按层排查：从知识缺失到生成偏差的原因与证据
排查的基本顺序是：知识是否存在 → 检索是否命中 → 问题表述是否被利用 → 版本口径是否一致 → 生成是否偏离。每一层都要拿到可观察的证据再下结论，避免把猜测当成原因。
下表把各层的原因假设、可观察证据和排除方法并列，便于逐项核对。
| 排查层 | 原因假设 | 可观察证据 | 排除方法 |
|---|---|---|---|
| 知识层 | 目标文档未入库、不在可检索范围、权限不可见 | 知识库中检索不到该文档；文档列表有但问答无命中；不同角色提问结果不同 | 用文档标题关键词直接搜索；核对文档所属空间与索引状态；用有权限账号复测 |
| 切分层 | 切分粒度过大或过小，标题与元数据缺失，正确片段难以召回 | 命中的片段是整篇长文或残缺半句；片段缺少项目、模块、版本标签 | 查看命中片段原文及其所在章节；检查文档标题层级与标签 |
| 表述层 | 问题中的项目名、模块、版本、时间等限定词未被识别利用 | 去掉限定词后回答反而更准；同一问题加上项目名后结果改变 | 对比带限定词与不带限定词的提问结果 |
| 版本层 | 新旧规范、接口变更记录并存，命中过期片段 | 命中片段来自已归档或旧版本文档；文档更新时间早于当前规范 | 核对命中片段的文档版本与更新时间；检查是否存在同主题多版本 |
| 生成层 | 检索片段正确，回答仍偏离或缺少引用 | 命中片段与问题相关，但回答加入片段外内容；回答未标注来源 | 对照命中片段逐句核对回答；检查是否要求附引用 |
知识层是排查的第一站，因为知识不存在时，后面所有环节都无从谈起。验证方法是绕开问答，直接用文档标题或关键术语在知识库中搜索：搜得到，说明知识存在，问题在检索或生成；搜不到，说明文档未入库或不在可检索范围。还要注意权限因素，同一问题由不同角色提问结果不同，往往说明部分文档对提问者不可见，此时回答可能基于不完整的可见范围生成。
切分层的问题常被忽略。文档切分粒度过大，一个片段里混着多个主题，检索命中后模型容易抓住其中次要内容作答；粒度过小，片段缺少上下文，回答会显得断章取义。标题与元数据的作用同样关键：一份接口文档如果没有标注所属项目、模块和版本，检索时很难把它和具体问题精确对应。可观察证据是命中片段的原文——如果片段本身与问题只沾边，答偏的根源就在切分而非生成。
表述层的验证最直接：把同一个问题分别带上和不带项目名、模块名、版本号提问，对比结果。如果带上限定词后回答明显更准，说明系统能够利用这些限定词，此前答偏是因为问题过于笼统。这一层也解释了为什么研发人员用自然语言随口提问时更容易答偏——口语化问题常省略了关键的限定信息。
版本层在接口和规范类知识上尤其常见。同一接口经历多次变更，新旧文档并存，如果旧文档没有被归档或标注有效期，检索可能优先命中旧片段。证据是命中片段的文档版本号和更新时间，与当前实际规范比对即可确认。
生成层排在最后，是因为只有前面几层都排除后，才轮到怀疑生成环节。判断依据是：命中片段确实与问题相关且内容正确，但回答加入了片段之外的内容，或者没有按要求标注引用来源。这时问题出在回答约束上，而非知识或检索。
处置步骤：按排查结论修复
每一类确认的原因对应不同的处置动作，动作之前要看清前置条件，涉及批量操作时先设好停止点。
知识缺失。补齐缺失的规范、接口文档与项目历史记录，确认文档完成入库并进入索引。前置条件是明确缺失范围——是整类文档缺失，还是某几个具体条目缺失。补齐后不要立即全量重问，先用原问题验证是否已能命中。在文档与工作项管理上，ONES 可以把需求、任务与对应文档关联在同一项目空间内，文档更新与工作项状态变化保持同步，减少“文档写了但没人知道在哪”的情况；知识入库后是否可被问答检索，仍以实际索引状态为准。
切分与元数据问题。调整文档结构，把长文档按主题拆成章节清晰的段落，补充标题层级，并为文档打上项目、模块、版本标签，然后重建索引。重建索引属于影响面较大的操作，操作前备份现有文档与配置，先选一个小项目空间或一小批文档验证效果，确认命中改善后再扩大范围。停止点是：小范围验证后命中片段仍无明显改善，应暂停批量操作，回到切分层重新分析切分规则。
表述问题。在提问中带上项目、模块、版本等限定词，例如把“鉴权怎么配”改为“订单服务 v2 接口的鉴权怎么配”。团队层面可以统一提问模板，把常用限定词固化为提问习惯。这一处置不需要改动系统，成本最低，适合作为日常先行动作。
版本冲突。为文档标注有效期与适用版本，把过期规范归档并从默认可检索范围中移出，保留历史版本供追溯。前置条件是确认哪些版本仍在生效，避免误归档当前规范。
生成偏差。要求回答附引用来源，并在无依据时明确说明“未找到相关内容”，而不是给出推测性结论。这一约束需要在使用侧形成习惯：看到没有引用的回答，先当作待核实内容处理。
验证恢复与复发预防
处置完成后，用同一批问题做回归验证，是确认问题真正解决的可靠方式。验证看两个指标：命中片段是否与问题对应，回答是否标注了引用来源。两项都满足，才算该类问题恢复；只满足其一，说明还有一层没有处理干净。
回归验证建议保留排查初期记录的问题清单，逐条复测并记录结果。对于知识缺失类问题，重点看原问题能否命中新补文档；对于切分与版本类问题，重点看命中片段是否已切换到正确版本；对于生成类问题，重点看回答是否附引用、无依据时是否如实说明。
复发预防依靠日常机制，而不是一次性修复。可以从四个方面建立习惯：
- 建立典型问题集，覆盖高频规范、接口和项目历史问题，定期抽查问答命中与回答质量，发现偏差及时回流排查。
- 明确文档入库、更新、归档的责任人与时效要求，规范变更时同步更新文档并标注版本，过期内容及时归档。
- 记录每一次答非所问的案例，标注属于哪一层原因，定期汇总，用于补充文档覆盖和调整切分规则。
- 把提问带上项目、模块、版本限定词纳入团队日常习惯，减少因表述笼统导致的答偏。
这些机制的价值在于把偶发问题转化为可积累的改进：每一次答偏都对应一条文档补充或一条切分规则调整，知识库的覆盖与结构随之逐步完善，同类问题的复发概率随之下降。
常见问题
同一个问题，不同研发同事问出来的结果不一样，是什么原因？
常见原因是权限可见范围不同。知识库中部分文档对提问者不可见时，问答只能基于可见范围内的片段作答，结果自然有差异。验证方法是换用有相应文档权限的账号复测同一问题，对比命中片段是否变化。
另一种可能是提问表述不同，一方带了项目名或版本号，另一方只说了笼统概念。可以固定问题原文，分别用带限定词和不带限定词的方式各问一次，看结果差异落在哪一层。
知识库里明明有这份接口文档，问答却答不出来，该先查什么？
先绕开问答，直接用文档标题或关键术语在知识库中搜索，确认文档本身能被搜到。搜得到而问答无命中，问题多半在切分与元数据：文档是否按主题拆分、标题层级是否清晰、有没有标注项目与版本标签。搜不到则要核对文档所属空间、入库与索引状态，以及提问账号是否具备查看权限。
确认属于切分与元数据问题后，调整文档结构并补充标签，再小范围重建索引验证，不要一次性对全部文档操作。
回答内容看起来是对的，但引用了上一版接口规范，怎么处理？
这属于版本层问题：新旧规范并存，旧文档没有被归档或标注有效期，检索优先命中了旧片段。先核对命中片段的文档版本号与更新时间，与当前实际规范比对确认。
处置上为文档标注适用版本与有效期，把过期规范归档并移出默认可检索范围，保留历史版本供追溯。归档前要确认哪些版本仍在生效，避免误归档当前规范。之后用原问题复测，看命中片段是否已切换到正确版本。
要求回答附引用之后，仍然出现没有出处的结论，还能做什么？
先对照命中片段逐句核对回答，确认片段本身是否与问题相关。片段相关而回答加入片段外内容，说明约束还不够明确，可以在提问或使用规范中要求：无依据时直接说明未找到相关内容，不给出推测性结论。
使用侧也要形成习惯，看到没有引用的回答先当作待核实内容处理。若多次出现同类情况，把案例记录下来，回流到文档补充与切分规则调整。
小范围重建索引后效果没有改善，应该继续扩大范围吗？
不建议继续扩大。小范围验证后命中片段仍无明显改善，说明切分规则或标签设计本身可能有问题，扩大范围只会把同样的问题复制到更多文档。
此时应暂停批量操作，回到切分层重新分析：片段粒度是否合适、标题层级是否反映文档主题、项目与版本标签是否足以区分同类文档。调整规则后重新选一小批文档验证，确认命中改善再逐步扩大。
