AI知识回答出现幻觉，处理顺序比“换个模型”更重要：先把笼统的“答错了”拆成可核查的症状，再逐条对照知识来源与版本找出原因，针对原因修正知识源或回答约束，最后用同一批问题回归验证。本文给出一套从症状记录、证据排查到处置与复发预防的可操作路径，适用于团队内部知识问答、制度查询和研发文档检索等场景。
要点总览（TL;DR）
- 先按症状分类记录：编造条款、引用旧版本、概念混答、答非所问、无来源的确定结论，影响面分为单点、同类批量、跨域系统性偏差。
- 按“检索是否命中—来源是否有效—表述是否歧义—生成是否越界”的顺序用证据排除，每步保留检索关键词、版本号与复测问法。
- 处置与原因一一对应：补条目写清适用范围与生效时间、下线过期版本、补术语表、要求标注来源并对关键结论人工复核；批量改动先备份小范围试运行。
- 用原问题加同类问题组成验证集回归，通过标准为关键事实有出处、版本正确、无依据时明确说明无法确认。
- 把高频问题抽检、条目责任人与复审周期、错误案例回流固化为日常机制，降低复发。
先判断幻觉属于哪一类症状
“AI答错了”本身无法直接排查，需要先落到具体症状。常见表现包括：编造不存在的制度条款或流程节点；引用已经失效的旧版本；把名称相似但适用范围不同的概念混在一起回答；答非所问，回答内容与提问对象错位；在没有来源支撑时仍给出语气确定的结论。症状不同，后续排查方向差别很大，例如编造条款通常指向知识缺失或生成越界，引用旧版本则优先怀疑来源版本管理。
症状记录还应标注影响面，便于决定处置优先级。单点错误指个别问题答错，通常修正对应知识条目即可；同类问题批量出错说明某一类知识或某一种问法普遍失效，需要检查该类知识的覆盖与表述；跨知识域系统性偏差则可能涉及权限配置、知识范围设定或回答约束，影响范围更大，处置前应暂停对外使用相关回答。
记录症状时至少保留四项信息：原始问题、回答原文、涉及的知识条目、发生时间。原始问题要保留用户实际输入的措辞，便于复测；回答原文要完整截取，避免只记结论；涉及的知识条目用于后续对照来源；发生时间用于判断当时生效的知识版本。下表可作为记录模板直接使用。
| 原始问题 | 回答原文 | 涉及知识条目 | 影响范围 |
|---|---|---|---|
| 示例：试用期转正需要提前多久提交申请 | 示例：回答称“提前3个工作日”，并给出制度名称 | 示例：《员工转正管理办法》v2.1 | 示例：单点错误，仅该问题答错 |
| 示例：报销发票抬头填写规则 | 示例：回答引用了已废止的旧版财务制度 | 示例：《财务报销制度》v1.8（已过期） | 示例：同类问题批量出错，涉及全部报销类提问 |
表格中的示例为演示情景，用于说明记录方式，不代表真实业务数据。记录完成后，再进入原因排查，避免凭印象直接修改知识库。
四类常见原因与对应排除证据
原因排查的原则是先提出假设，再用证据排除，不能把猜测直接当成结论。建议按“检索是否命中—来源是否有效—表述是否歧义—生成是否越界”的顺序推进，前一类原因排除后再进入下一类，避免同时改动多个环节导致无法判断哪项修改起了作用。
检索缺失。知识库中没有对应条目，或条目存在但未被召回。验证方式是直接到原始知识源中检索关键词，确认条目是否存在、是否在回答所覆盖的知识范围内。如果原始知识源中确实没有该内容，问题出在知识覆盖；如果条目存在却未被引用，则需要检查知识范围配置与条目可检索性。
来源过期或冲突。同一问题存在多个版本的答案，AI引用了旧版本或相互矛盾的条目。验证方式是对比版本号与生效时间，列出该问题涉及的全部相关条目，确认哪一版为当前有效版本。这类原因在制度频繁修订、流程多次调整的团队中较常见，排查时应以生效时间为准，而不是以条目创建时间或更新时间判断。
上下文与表述问题。问题本身存在歧义，或术语同名不同义，导致AI理解了错误的对象。验证方式是换一种问法复测，例如补充适用部门、业务场景或时间范围，观察回答是否随之变化。如果换问法后回答正确，说明问题出在提问口径或术语定义，而非知识本身错误。
生成越界。知识中没有依据，AI却给出了确定结论。验证方式是要求回答附出处，并逐条核对引用内容是否真实存在、是否支持该结论。若引用条目不存在，或条目内容与结论不符，即可判定为生成越界。这类原因与前三类的区别在于：知识源本身可能没有问题，问题出在回答环节缺少依据约束。
| 排查顺序 | 原因假设 | 验证证据 | 判定结论 |
|---|---|---|---|
| 1 | 检索缺失 | 直接检索原始知识源，确认条目是否存在 | 条目不存在或未被召回 |
| 2 | 来源过期或冲突 | 对比版本号与生效时间，列出全部相关条目 | 引用了非当前有效版本 |
| 3 | 上下文与表述问题 | 换一种问法复测，补充限定条件 | 换问法后回答正确 |
| 4 | 生成越界 | 要求附出处，逐条核对引用与结论 | 引用不存在或与结论不符 |
排查过程中应保留每一步的验证记录，包括检索关键词、对比的版本号、复测的问法。这些记录既是归因依据，也是后续回归验证的输入。
按原因处置：修正知识源与回答约束
原因确认后，处置动作应与原因一一对应，避免“全面重建知识库”这类过度操作。每项处置都应明确责任人、完成标志和风险控制点，处置完成后再进入验证环节。
知识缺失的处置。补充缺失条目，并在条目中写明适用范围、生效时间与责任人。适用范围要具体到部门、岗位或业务场景，生效时间用于后续版本判断。补充完成后，用原问题复测，确认回答能够引用到新条目。
版本冲突的处置。下线或标注过期条目，确保同一问题只保留一个有效版本。下线前先确认没有其他流程仍在引用旧条目；如果无法立即下线，至少在条目中显著标注“已过期”并指向新版本。处置后重新检索该问题，确认AI引用的是当前有效版本。
表述歧义的处置。补充术语表与同义词，规范提问与回答口径。例如为同名不同义的术语分别写明定义和适用场景，把常见口语化问法映射到标准术语。处置后换用多种问法复测，确认不同表述都能得到一致回答。
生成越界的处置。要求回答标注来源，无依据时明确说明无法确认，关键结论进入人工复核。复核点应设在对外发布、制度执行和流程变更等高风险场景，普通查询可按抽检方式覆盖。处置后重点验证回答是否在缺少依据时停止给出确定结论。
涉及批量修改或删除知识条目时，先备份当前知识库，再选择小范围条目试运行，确认修改效果符合预期后再扩大范围。试运行期间保留回滚方案，出现异常时能够恢复到修改前状态。批量操作的责任人应与知识条目责任人分离，形成复核关系。
| 原因 | 处置动作 | 责任人 | 风险控制点 |
|---|---|---|---|
| 知识缺失 | 补充条目，写明适用范围、生效时间、责任人 | 对应知识域负责人 | 补充后复测原问题 |
| 版本冲突 | 下线或标注过期条目，保留唯一有效版本 | 制度或流程维护人 | 确认无其他流程引用旧条目 |
| 表述歧义 | 补充术语表与同义词，规范问答口径 | 知识库维护人 | 多种问法复测一致性 |
| 生成越界 | 要求标注来源，无依据时说明无法确认，关键结论人工复核 | 业务复核人 | 高风险场景设置复核点 |
在研发团队中，知识条目维护、复核任务和抽检记录需要有承载位置，否则处置动作容易停留在个人文档里。ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，基于项目数据和团队知识回答问题；其支持基于指定 Wiki 页面组回答并附引用来源，也支持在 Wiki 页面、附件等范围内建立统一知识上下文并保障权限边界。团队可以把知识条目修正、复核任务和抽检记录放在同一套工作项与文档体系中流转，让处置结果可追踪、可审计。具体交互与配置方式以实际产品为准。
验证恢复与防止复发
处置完成后，需要用可重复的方式确认问题已解决，而不是凭一次复测通过就结束。验证集由原问题与同类问题组成，覆盖本次涉及的每个原因类别，逐条核对回答与来源是否一致。验证集规模可按影响面确定：单点错误至少覆盖原问题和若干相近问法；批量出错应覆盖该类问题的典型问法与边界问法；系统性偏差则需要跨知识域抽样。
通过标准建议明确为三条：关键事实有出处，即回答中的制度条款、流程节点、时间要求等都能对应到具体知识条目；版本正确，即引用的是当前有效版本；无依据时不作确定结论，即知识中没有相关内容时，回答明确说明无法确认，而不是给出看似合理的推断。三条标准同时满足才算通过，任何一条不满足都应回到对应原因继续处置。
复发预防依赖日常机制，而非一次性修复。高频问题应定期抽检，抽检结果记录在案；知识条目设置责任人与复审周期，制度或流程变更时同步更新条目并标注生效时间；错误案例回流到知识维护清单，作为下一轮抽检和条目修订的输入。抽检频率可按知识变更频率设定，变更频繁的知识域缩短周期。
验证与抽检记录本身也应可查。把验证集、通过标准、抽检结果和错误案例放在团队可访问的位置，新成员接手知识维护时能够看到历史问题和处置方式。ONES 基于自身权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，适合承载这类需要留痕的复核与抽检流程。团队在落地前可先梳理研发流程、现有数据与高频协作问题，再确定AI知识问答的应用范围和推进路径，避免一开始就覆盖全部知识域而难以定位问题。
常见问题
知识库里确实没有对应条目，但业务上又需要AI能回答，应该先补知识还是先限制回答范围？
两件事可以并行，但顺序上建议先限制回答范围。知识补充需要时间，在条目补齐之前，让AI对超出知识范围的问题明确说明无法确认，可以避免继续输出编造内容。补充条目时写明适用范围、生效时间和责任人，补齐后用原问题复测，确认回答能引用到新条目，再放开该范围的回答。
同一份制度有多个版本，旧版本还在被其他流程引用，能直接下线吗？
不建议直接下线。先梳理旧版本还被哪些流程、文档或模板引用，确认替换方式后再处理。如果短期内无法全部切换，至少在旧条目上显著标注已过期并指向新版本，同时把仍在引用旧版本的流程列入整改清单。处置后重新检索该问题，确认AI引用的是当前有效版本。
要求AI标注来源之后，回答里仍然出现来源与结论对不上的情况，怎么处理？
这类情况属于生成越界，处置重点在回答约束与复核环节。逐条核对引用条目是否真实存在、内容是否支持该结论；对制度执行、对外发布、流程变更等高风险场景设置人工复核点，普通查询用抽检覆盖。同时检查知识条目本身是否存在表述模糊、一段内容包含多个结论的情况，条目越清晰，引用与结论的对应关系越容易核对。
验证集要多大才算够，一次复测通过就能结束吗？
验证集规模按影响面确定：单点错误至少覆盖原问题和若干相近问法；同类批量出错覆盖该类问题的典型问法与边界问法；跨知识域的系统性偏差需要抽样覆盖多个知识域。一次复测通过不足以结束，应确认三条通过标准同时满足——关键事实有出处、版本正确、无依据时不作确定结论，任何一条不满足都回到对应原因继续处置。
团队没有专人维护知识库，抽检和复审机制怎么落地？
可以按知识域指定责任人，由最熟悉该领域制度或流程的人兼任，复审周期按知识变更频率设定，变更频繁的领域缩短周期。抽检不必覆盖全部条目，优先抽高频问题和近期修订过的条目。把验证集、抽检结果和错误案例放在团队可访问的位置，让接手的人能看到历史问题与处置方式。ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，基于项目数据和团队知识回答问题，并支持基于指定 Wiki 页面组回答并附引用来源，知识修正与复核任务可在同一套工作项与文档体系中流转。
