考察点
这道题考的是知识库的「脏数据治理」意识。真实知识库一定有冲突：新旧版本制度并存、不同部门口径不一致、爬虫抓来的内容互相矛盾。面试官想听到你怎么在入库侧、检索侧、生成侧分层处理冲突，以及版本控制怎么做才不至于让旧文档污染检索。追问常往「冲突怎么自动发现」「权威源怎么定义」「用户问到冲突内容怎么答」走。
参考答案
先把冲突分类，不同冲突不同打法
实践里冲突大致三类：
- 版本型冲突：同一主题的新旧文档并存——2022 版和 2024 版的报销制度都在库里。这是最高频的，解法是版本管理，不是「容忍冲突」；
- 来源型冲突：不同来源口径不一致——官网说支持某功能，旧手册没提。解法是来源权威性分级；
- 事实型冲突：两篇文档对同一事实给出矛盾数据，且无法靠时间或来源判定。这类最少但最难，需要检测 + 人工仲裁。
入库侧：元数据是冲突治理的地基
冲突处理的前提是文档入库时带齐元数据：doc_version、effective_date（生效时间）、source、authority_level（权威级别）、supersedes（取代哪个文档）、status（生效/废止）。很多团队的教训是后期想治理冲突时发现元数据根本没存，只能回炉重导。
版本控制设计上，推荐「逻辑版本 + 检索过滤」而不是「物理删除旧版」：旧版本标记 status=deprecated 留在库里（审计、追溯、回答「以前是什么规定」都需要它），但默认检索只查 status=active 的 chunk。只有用户明确问历史版本时才放开过滤。删除是最后手段，废弃标记才是常态。
检索侧：优先级排序与去重
同一主题召回多个版本时，按规则排序而不是交给向量分数：
- 生效时间新的优先（注意是 effective_date 不是入库时间）；
- 权威来源优先——官方制度 > 部门 wiki > 个人笔记，authority_level 在入库时按来源映射好；
- 同优先级多版本同时命中时，只保留最高优先级版本进入上下文，其余折叠，避免互相矛盾的内容一起进 prompt 把模型搞糊涂。
工程实现上可以检索后加一层「版本归并」：按 topic_id/doc_family_id 分组，组内只取生效版本。这要求入库时把同一文档的历代版本归到同一个 family，通常靠文档 ID 规则或标题相似度聚类。
冲突检测：能自动发现的别靠用户反馈
版本型冲突靠元数据就能解决，事实型冲突需要主动检测。可行的做法：定期离线任务，对高相似 chunk 对（向量相似度很高、主题相同）让 LLM 判断「这两段是否对同一事实给出矛盾陈述」，命中的进人工审核队列。量级上不用全库两两比对——按主题分组后组内比对，百万级 chunk 也能跑。这个机制的价值不只是修数据，更是发现上游流程问题（哪个部门又传了过期文档）。
生成侧：别替用户做沉默的裁判
检测不到、过滤不掉的冲突最终会漏到生成环节，这层的原则是「显式呈现，不擅自裁决」：上下文里存在矛盾信息时，prompt 里明确指示模型列出不同说法及其来源和时间（「A 文档（2023 年）称 X，B 文档（2024 年）称 Y，后者更新」），并倾向引用生效日期新、权威级别高的来源。比冲突本身更糟的是模型把两个矛盾说法杂糅成一个看似流畅的答案——那个答案必然是编的。
引用溯源（每个事实标注来源文档和版本）在这里不只是体验功能，是冲突暴露的必要条件——没有来源标注，用户发现不了冲突，也无从判断该信谁。
版本控制的完整闭环
一套能跑的版本管理流程长这样：新文档入库 → family 匹配（是不是已有文档的新版）→ 是则旧版标记 deprecated、新版 active，记录 supersedes 链 → 检索默认过滤 deprecated → 定期对账（active 状态同一 family 出现多个版本时告警）。回滚也是免费的：新版内容有误，把状态切回去就行，因为旧版从来没被删过。
可能的追问
- 两份文档发布时间相近、来源同级，内容矛盾，怎么判？——自动化手段到此为止，进人工仲裁队列，仲裁结果（哪个为准）落成元数据规则，同类冲突以后自动处理。别指望 LLM 替你判，它没有你的业务上下文。
- 用户问「以前的规定是什么」怎么支持？——这正是保留 deprecated 版本的原因：识别查询里的时间意图（「去年」「修订前」），检索时放开版本过滤并锁定对应时间段生效的版本。
- 权威级别怎么落地，谁来定？——按来源系统自动映射初值（官方系统 > wiki > 上传文件），业务 owner 可以在管理后台调。它是排序权重不是硬过滤，避免误杀有效信息。
- 冲突检测的 LLM 判断准吗？——召回优先（宁可多报），准确率靠人工审核兜；实测下来「高相似但数值/日期不一致」的 chunk 对用规则先过滤一遍，能让 LLM 判断量降一个数量级，准确率也高不少。