知识层真正让团队紧张的，不一定是搜不到东西，而是搜到了太多看起来都像东西的东西。法务规则说 A，培训材料说 B，区域例外说明又说 C，模型甚至还能把三者组织成一段非常通顺的回答。问题从来不是语言组织能力，而是系统根本还没有回答：当多来源 evidence 互相冲突时，谁有权赢、在什么范围内赢、什么时候必须停下，而不是继续用最像答案的那条片段把流程往前推。
很多团队在这里会下意识相信 reranker 或模型“综合判断”的能力。可只要冲突进入的是审批、价格、权限、流程边界这类高风险事实，靠语义相似度或文本流畅度去仲裁，本质上就是把治理外包给概率模型。模型当然可以帮助归纳冲突，但它不该单独决定冲突解决。真正成熟的 Knowledge Plane，必须把 conflict resolution 做成一套显式协议。
这套协议至少要回答三件事：冲突属于哪一类，默认按什么顺序裁决，以及在什么条件下必须升级人工。没有这三条，系统表面上像在“综合多来源知识”，实际上却是在把证据冲突包装成一次更有自信的输出。
建议配合 AI agent Canonical Fact Registry、AI agent Knowledge Source Onboarding Contract、AI agent Evidence Provenance 可信度分层 和 AI agent Human Review Console 一起看。
先给结论：Evidence conflict 不是一种错误信息，而是一类必须被系统显式建模的运行状态
| 冲突类型 | 例子 | 默认动作 |
|---|---|---|
| 权威冲突 | canonical 规则与培训材料结论相反 | 优先权威来源，低权重来源降为背景说明 |
| 范围冲突 | 全局制度与区域例外同时存在 | 先判断当前租户 / 地区 / 流程是否命中局部范围 |
| 新旧冲突 | 新版本政策与历史 FAQ 不一致 | 按 freshness 和生效时间决定是否允许继续回答 |
| 数值冲突 | 价格、阈值、日期等关键信息不一致 | 高风险数字冲突默认阻断，进入人工或 live tool 核验 |
这张表最重要的意义，不是给团队一个“万能裁决器”，而是把冲突从文本层拉回运行时层。系统先知道自己处于冲突状态，后面才有资格决定继续、阻断还是升级。否则所谓“解决冲突”通常只是让模型替你隐藏冲突。
决策顺序最值钱：先看 authority 和 scope，再看 freshness，最后才看语言相似度
一个更稳的冲突解决顺序通常是：
- authority：来源的 truth level 和 owner 级别谁更高。
- scope：当前租户、地区、流程是否命中局部例外。
- freshness：谁的生效时间、同步水位和索引时效更可靠。
- structural consistency：和 canonical fact registry、当前 tool state 是否一致。
- semantic fit：在前面都不分胜负时，才允许比较文本相似度和上下文相关度。
很多系统恰恰是把这个顺序倒过来了。它们先按语义相关度选出“最像答案”的证据，再在结果层附一点解释。这在低风险说明类问题上或许还能容忍，一旦进入高风险事实，顺序倒置就会让系统先天偏向“说得顺”的证据，而不是“应该被信”的证据。
冲突解决不能只产出最终结论，还要产出冲突记录和被拒绝理由
知识冲突之所以难排查，很大一部分原因是系统只留下最终答案，没有留下“它为什么没选另一个来源”。一个可运营的 conflict resolver，至少应该保留：
| 字段 | 用途 |
|---|---|
| conflictClass | 这是 authority、scope、freshness 还是 numeric 冲突 |
| candidateEvidence | 本次参与裁决的证据集合 |
| winningReason | 为什么当前这条 evidence 被保留 |
| rejectedReasons | 其他证据为什么被降权、屏蔽或转背景说明 |
| escalationFlag | 是否达到必须人工升级的阈值 |
这份记录不是附属日志，它是后续复盘、客户解释和策略迭代的基础。没有 rejected reason，团队每次都只能事后猜“是不是 reranker 又偏了”。而真正成熟的系统，应该能直接告诉你：这次不是 reranker 偏，而是 canonical source 胜了 scope exception，或者 freshness proof 不足所以被强制阻断。
Numeric 和 policy conflict 绝不能被当成普通文本冲突
知识层有一类非常危险的误判，就是把数值冲突和政策冲突当成普通段落差异。比如两份文档里的金额阈值不同、履约时间不同、审批条件不同。模型很擅长把这种差异组织成貌似合理的综合表达，但对业务来说，综合表达往往正是最危险的。金额不是“折中一下”，审批规则也不该“综合理解”。
一个更稳的默认规则是：
- 关键数字冲突：必须先回到 canonical source 或 live tool 核验。
- policy 冲突：若 authority 和 scope 仍无法单边裁决，直接阻断自动继续。
- 解释型冲突：可允许系统先展示冲突存在，再提示用户缩小范围或请求人工。
只有这样，Knowledge Plane 才不会在最需要明确边界的地方，反而因为语言能力太强而把边界抹糊。
失败案例：区域例外说明和全局制度同时命中，agent 因为“全局制度更完整”直接忽略了例外
某团队的采购 agent 在回答审批门槛时，同时检索到了总部制度和一个区域例外备忘录。因为总部制度写得更系统、上下文也更完整，reranker 把它排在前面，模型随之给出了全局规则下的答案。结果这个区域客户被错误地引导走了不适用的审批路径。
真正的问题不在于模型没读懂例外，而在于系统根本没把 scope conflict 显式建模。它只把两份证据当成普通候选，任由相关度决定顺序。后来团队修正冲突 resolver 时，先把区域、租户和业务域 scope 提前纳入判断：只要当前请求明确命中局部例外，局部来源就先拥有裁决优先级；若当前 scope 信息不完整，则系统不继续给最终结论，而先追问或转人工。
这个变化的价值很大。它让 system 停止把“更完整的全局制度”误当成“更适用的答案”，也让冲突解决第一次变得可解释。
真正成熟的 conflict governance，不是把所有冲突都推给人工，而是把只有人能拍板的那部分精确筛出来
很多团队意识到冲突危险后，会一口气把所有 evidence conflict 都扔给人工。短期看风险下降，长期看吞吐和组织成本会迅速崩。更成熟的做法，是用 conflict taxonomy 把冲突分成：
| 等级 | 场景 | 默认去向 |
|---|---|---|
| L1 | authority 清晰、scope 清晰、只是说明差异 | 系统自动裁决并保留记录 |
| L2 | authority 清晰但 freshness 或 structure 有疑点 | 系统保守回答，附带风险说明 |
| L3 | numeric、policy、responsibility 等关键冲突 | 强制升级人工或 live tool 对账 |
这样人工接到的不是所有“看起来不太一样”的文本，而是那些真正会改变高风险事实、且系统无法单边证明自己正确的冲突。这才是冲突治理应该服务的方向：减少盲目自动化，同时也减少无意义的人海兜底。
如果你现在只能先补一层，先让系统在 numeric 和 policy conflict 时学会显式停下
很多平台会先从更复杂的信任打分、图谱融合或模型仲裁开始。更值钱的第一步，反而是非常朴素的规则：只要命中关键数字和政策冲突，就默认不继续自动给最终结论。因为这类冲突最贵，也最不适合靠语言模型做“看起来合理”的综合。
AI agent 成熟的一个标志，不是它能把冲突讲得更顺，而是它已经知道哪些冲突不能靠自己讲顺。把这一层守住，Knowledge Plane 才算真正拥有了治理底线。
Checklist
- evidence conflict 是否被按 authority、scope、freshness、numeric 等类型显式分类
- 冲突裁决顺序是否先看 authority 和 scope，再看 freshness 和语义相关度
- numeric 和 policy conflict 是否默认进入更保守的处理路径
- conflict resolver 是否同时记录 winningReason 和 rejectedReasons
- 是否只把 L3 高风险冲突升级人工，而不是把所有冲突都扔给人
- support 和 audit 是否能直接查看本次冲突的分类和裁决记录
延伸阅读：
