AI知识回答出现幻觉，往往是知识来源缺失或过期、检索召回不准、上下文拼接失当、模型在证据不足时仍被要求给出确定答案这几类问题叠加的结果。排查时先固定可复现的提问样本，再逐层验证知识库覆盖、检索命中、上下文引用和回答约束，最后用带出处的回答与回归问题集确认恢复效果。本文给出一条从症状记录到复发预防的诊断路径。
要点总览（TL;DR）
- 先把“AI乱答”拆成事实编造、张冠李戴、过期信息、答非所问四类症状，记录提问原文、期望答案、实际答案与频次，再判断错误是集中在特定知识域还是普遍出现。
- 排查按知识层、检索层、上下文层、生成层逐层进行，每层先找可观察证据再下结论；一次只改一层，改完立即用同一批样本复测。
- 处置动作对应已确认的原因：补齐或更新知识源并标注生效范围与责任人，调整切分与召回后小样本复测，在提示中要求引用来源并允许说明资料不足，高风险问题设人工复核。
- 知识库批量改动前先备份并保留回滚版本，切分与召回调整先在测试文档组验证，再应用到生产知识库。
- 用覆盖高频与高风险问题的回归问题集验证效果，同时看答案正确率、引用可追溯率和拒答合理性；新错误样本回流问题集，知识库、模型或提示变更后触发复测。
幻觉在什么范围内出现：先分清症状类型
“AI乱答”是一个笼统描述，直接拿去排查很难定位。第一步是把用户感知到的错误拆成可观察的症状类型，让每个样本都能对应到后续的某一层原因。常见的表现可以归为四类：
- 事实编造：答案中出现知识库中不存在的制度条款、接口名称、版本号或人员分工，表述流畅但无出处。
- 张冠李戴：信息本身存在，但被安到了错误的项目、模块、团队或时间点上，例如把A项目的发布流程说成B项目的。
- 过期信息：答案对应的是旧版文档或已废止的规范，与当前生效内容不一致。
- 答非所问：回答内容与提问意图偏离，或只覆盖了问题的一部分，用户需要追问才能得到真正想要的结论。
分类之后要建立样本记录。每条样本至少记录五项信息：原始提问、期望答案及其依据文档、实际答案、出现频次、提问人所属知识域。记录时保留原始提问措辞，不要事后改写，否则复现时会失真。
样本积累到十几条后，观察分布。如果错误集中在某一两个知识域，说明问题更可能出在知识覆盖或文档质量上；如果跨多个知识域普遍出现编造，则要优先怀疑生成层的回答约束或检索层的整体召回质量。这个判断决定了后续排查从哪一层切入，但此时只形成方向，不下结论。
建议用一张简单的表维护症状记录，字段如下：
| 样本编号 | 提问原文 | 期望答案与依据 | 实际答案 | 症状类型 | 频次 | 知识域 |
|---|---|---|---|---|---|---|
| S-001 | （原样记录） | （结论＋文档链接或标题） | （原样记录） | 事实编造／张冠李戴／过期／答非所问 | 3次/周 | 如：发布规范 |
原因假设与排除证据：逐层验证而不是直接下结论
症状分类完成后，按知识层、检索层、上下文层、生成层逐层提出原因假设。每一层都要先找到可观察的证据，再决定是否排除。排查顺序建议从知识层开始，因为知识缺失会同时污染后面三层的判断。
知识层：知识库是否覆盖、是否过期、版本是否混乱
验证方法是拿样本问题去知识库中人工检索，确认是否存在能回答该问题的文档。如果文档不存在，属于覆盖缺口；如果存在多份内容冲突的文档，属于版本混乱；如果只有旧版文档，属于内容过期。这一步的证据是文档标题、版本号和最后更新时间，可以直接核对，不需要借助模型输出。
检索层：召回片段是否相关、切分是否破坏语义
知识存在但回答仍出错时，检查检索实际召回了哪些片段。可观察证据包括：召回片段与问题的相关性、片段是否来自正确的文档版本、切分后是否把一张表格或一段条件说明拆散。切分粒度过细会让模型只看到半条规则，粒度过粗则会引入大量无关内容。判断标准是召回片段单独阅读时，能否支撑期望答案。
上下文层：拼接顺序、截断与冲突信息
当召回片段本身正确、回答却仍偏离时，检查送入模型的上下文组织方式。常见证据是：关键条件被截断在窗口之外、多份文档的冲突结论同时进入上下文而模型选择了错误的一份、拼接顺序让次要信息排在主要依据之前。验证方法是调整上下文后复测同一批样本，观察错误是否随上下文变化而消失。
生成层：提示是否强制作答、是否缺少引用要求
如果前三层都排除，问题可能出在回答约束上。典型证据是：提示词要求“必须给出明确答案”，模型在证据不足时只能编造；提示未要求标注来源，用户无法判断答案依据；提示未允许表达不确定，模型倾向于用肯定语气覆盖知识空白。这一层的验证方式是修改提示后复测，观察编造型错误是否下降。
四层假设与验证证据对照如下：
| 层级 | 原因假设 | 可观察证据 | 排除方法 |
|---|---|---|---|
| 知识层 | 知识库未覆盖、文档过期、多版本冲突 | 人工检索无结果；文档更新时间早于规范变更；同一主题存在多份结论不同的文档 | 补齐文档或明确唯一有效版本后复测 |
| 检索层 | 召回片段不相关、切分破坏语义 | 召回内容与问题无关；表格或条件说明被拆散；召回了旧版本片段 | 调整切分粒度与召回范围，小样本复测 |
| 上下文层 | 关键信息被截断、冲突信息并存、顺序误导 | 期望依据未出现在上下文中；多份冲突结论同时进入；次要信息排在前面 | 调整拼接顺序与截断策略后复测 |
| 生成层 | 提示强制作答、缺少引用与不确定表达 | 提示含“必须回答”类要求；答案无来源标注；证据不足时仍用肯定语气 | 修改提示约束后复测 |
排查时一次只改一层，改完立即用同一批样本复测。多层同时调整会让错误率变化无法归因，反而延长定位时间。
按场景处置：从知识治理到回答约束的修复动作
原因确认后，处置动作按层对应展开。每项动作都要交代适用范围和停止点，涉及知识库批量改动时尤其如此。
知识源补齐与更新
针对覆盖缺口，补充缺失文档；针对过期内容，更新到当前生效版本；针对版本混乱，明确唯一有效文档并在旧文档上标注废止。每份关键文档应标注生效范围和责任人，让后续更新有明确归属。批量替换或删除文档前先备份，保留可回滚的历史版本，确认新版本在小样本上复测通过后再扩大范围。
切分与召回策略调整
针对切分破坏语义的问题，把表格、条件说明、操作步骤调整为完整片段，避免在关键条件中间断开。针对召回不准，收窄或扩大召回范围后用小样本复测。这类调整的影响面较广，建议先在测试用的文档组上验证，再应用到生产知识库。
回答约束与引用要求
在提示中明确要求回答附上引用来源，让用户能核对依据；允许模型在资料不足时说明“现有资料不足以回答”，而不是强行给出结论；对需要确定结论的问题，要求模型区分“文档明确写明”和“根据上下文推断”。这些约束能直接降低编造型错误，但也会带来拒答率上升，需要在验证阶段一并观察。
高风险问题的人工复核
涉及合规、对外承诺、发布决策等高风险问题时，设置人工复核环节或转人工入口。判断哪些问题属于高风险，可以按知识域和维护人约定，不必对所有问答都加复核，否则会抵消效率收益。
处置清单与风险边界：
| 已确认原因 | 处置动作 | 风险边界与停止点 |
|---|---|---|
| 知识覆盖缺口 | 补充文档并标注生效范围与责任人 | 新增文档需经维护人确认，避免引入未审内容 |
| 文档过期或版本冲突 | 更新至有效版本，旧版标注废止 | 批量改动前备份，保留回滚版本 |
| 切分破坏语义 | 调整片段边界，保持条件说明完整 | 先在测试文档组验证，再应用到生产库 |
| 召回不准 | 调整召回范围与排序，小样本复测 | 复测未通过不扩大调整范围 |
| 提示强制作答 | 允许表达资料不足，要求附引用 | 同步观察拒答率，避免过度拒答 |
| 高风险问题 | 设置人工复核或转人工入口 | 按知识域约定范围，不全量加复核 |
在团队协作层面，知识源更新、问题样本回流和复测安排需要落到具体的工作项和文档上，否则处置动作容易停留在口头。ONES Assistant 智能助手可以基于指定的 Wiki 页面组回答问题并附上引用来源，也能理解项目、工作项、迭代和 Wiki 页面等工作上下文；结合 ONES 的权限体系，问答过程可追踪、结果可审计。把复测任务、文档更新责任人和问题样本记录在 ONES 的工作项与 Wiki 中，可以让每次修复都有对应的状态和交接记录，便于后续追溯是哪次改动解决了哪类错误。
验证恢复与复发预防：用问题集确认效果
处置完成后，用回归问题集确认效果，而不是凭个别提问的观感判断。问题集应覆盖高频问题和已出现过错误的高风险问题，每条包含提问、期望答案、依据文档和可接受的回答范围。
验证指标建议关注三类：
- 答案正确率：回归问题集中回答与期望一致或落在可接受范围内的比例。
- 引用可追溯率：回答附带的来源能对应到真实存在的文档，且文档内容确实支撑该结论的比例。
- 拒答合理性：资料不足时说明无法回答、资料充足时正常作答的比例，重点看是否出现该答不答或不该答硬答。
三类指标要一起看。只盯正确率，可能通过放宽回答约束把编造压下去却换来大量拒答；只看引用率，可能忽略了引用文档本身已经过期。
复发预防依赖两个机制。一是错误样本回流：上线后新发现的错误，按S1的记录格式补入回归问题集，标注症状类型和发现时间，让问题集随使用持续增长。二是复测触发条件：知识库发生批量更新、模型或提示词变更、业务流程调整后，都要用回归问题集重跑一遍，确认原有正确回答没有被破坏。复测结果记录在案，与对应的变更关联，便于出现回退时快速定位。
把回归问题集、复测记录和知识更新任务放在同一套协作工具中管理，可以让“发现问题—修复—验证”形成闭环。ONES 支持在 Wiki 页面、附件等位置建立统一知识上下文，并提供全局知识检索；问题样本和复测任务可以作为工作项跟踪状态，知识更新作为文档变更留痕。这样每次模型或提示调整后，团队能按同一份问题集复测，并把新错误继续回流，逐步把幻觉控制在可管理的范围内。
常见问题
知识库里明明有正确文档，AI回答还是编造，应该先查哪一层？
这种情况说明知识层大概率不是主因，但仍要先用人工检索确认召回的片段是否来自正确版本、是否被切分拆散。如果召回片段单独阅读就能支撑期望答案，问题更可能出在上下文层或生成层：关键条件被截断、冲突结论同时进入上下文，或者提示要求必须给出确定答案。验证方式是保持知识库不动，先调整上下文组织或提示约束，用同一批样本复测，观察错误是否随之下降。
要求AI必须附引用来源后，拒答变多了，怎么判断是否过度？
把拒答分成两类看：资料确实不足时说明无法回答，属于合理拒答；资料充足却仍拒答，属于过度拒答。用回归问题集分别统计这两类的比例，重点检查后者。如果过度拒答集中在某几个知识域，通常是召回没有命中有效文档，或切分把条件说明拆散导致模型看不到完整依据，此时应回到检索层调整，而不是放宽引用要求。引用要求和拒答率需要一起观察，单独压低其中一项都可能掩盖另一项的问题。
知识库批量更新后，怎么确认没有把原来答对的问题改坏？
批量更新前先备份并保留可回滚的历史版本，更新后用回归问题集完整重跑一遍，对比更新前后的答案正确率、引用可追溯率和拒答合理性。重点看原本答对的样本是否出现回退，以及引用是否仍指向真实存在且内容支撑结论的文档。发现回退时，先定位是哪些文档变更引起的，必要时回滚到上一版本再小范围重试。复测结果与对应的变更记录关联保存，便于后续追溯。
团队规模不大，是否有必要为每个知识域都设人工复核？
不必全量加复核。可以先按知识域和维护人约定高风险范围，例如涉及合规、对外承诺、发布决策的问题，只对这些问答设置人工复核或转人工入口。范围约定后写入处置清单，随业务变化定期调整。全量复核会抵消问答带来的效率收益，而完全不设复核又会让高风险错误直接流出，按知识域圈定范围是折中的做法。
把问题样本和复测任务放进协作工具管理，实际能解决什么？
幻觉处置的难点往往不在单次修复，而在于修复动作散落在聊天记录和个人笔记里，过一段时间无法确认哪次改动解决了哪类错误。把问题样本、文档更新责任人和复测任务作为工作项跟踪状态，知识更新作为文档变更留痕，可以让每次修复都有对应的记录和交接。ONES Assistant 智能助手可以基于指定的 Wiki 页面组回答问题并附上引用来源，也能理解项目、工作项、迭代和 Wiki 页面等工作上下文；结合 ONES 的权限体系，问答过程可追踪、结果可审计。这样在模型或提示调整后，团队能按同一份问题集复测，并把新错误继续回流。
