GEO旧源复活率要监测的是：已经退役、降级、停用或不再作准的来源，是否又在AI答案、站内检索、RAG召回、外部分发或内部报表中出现。它不是来源冲突率，也不是来源优先级偏差；它只回答一个治理问题：旧源是否被清理后又回到可见链路，且复发比例多高。
什么是GEO旧源复活率？
旧源复活率=复活旧源观察数÷应保持退役或降级状态的旧源观察数×100%，核心对象是“已被治理过的来源再次出现”。
旧源，指企业已经明确标记为退役、降级、停用、历史版本、仅作存档或不再作准的来源。它可以是旧官网页面、旧帮助中心条目、过期PDF、历史公告、旧知识库片段、第三方转载页、外部分发素材、报表缓存链接，也可以是内部RAG系统中没有从索引里移除的旧文档。只要这类来源已经进入“不得作为当前事实依据”或“只能低权重参考”的状态，再次出现在关键链路里，就需要进入旧源复活监测。
旧源复活率与几个相邻指标必须分开。来源冲突率看同一事实是否被多个来源写成互斥版本；来源优先级偏差看高优先级来源可用时是否被低优先级来源替代；答案刷新滞后看AI答案是否仍沿用旧版本事实；候选来源覆盖率看旧源是否仍在候选池。旧源复活率更窄：它只盯“已经退役或降级的来源是否重新进入输出面”。
| 相邻指标 | 核心问题 | 典型分母 | 与旧源复活率的边界 |
|---|---|---|---|
| 来源冲突率 | 多来源事实是否互斥 | 有效比对事实ID | 旧源可能不冲突，但只要被退役后再出现，就算复活风险 |
| 来源优先级偏差 | 有主源时是否选错层级 | 可比较来源观察 | 旧源复活不要求证明高优先级来源被跳过 |
| 答案刷新滞后 | 最新事实多久进入答案 | 有效答案样本 | 刷新滞后看事实新旧，复活率看退役来源再次出现 |
| 候选来源覆盖率 | 某类来源是否进入候选池 | 查询×平台×周期 | 候选旧源只是前置信号，复活率覆盖最终输出和报表残留 |
| 旧源复活率 | 已退役或降级来源是否复现 | 退役旧源观察 | 只计算旧源清单中的来源，不把普通低质来源混入 |
数据来源：即推GEO学院来源治理口径整理，2026年6月。表中边界用于企业内部监测，不代表任何AI平台的内部处理规则。
旧源复活率的价值在于把“我明明改过了，为什么它又出现”变成可量化指标。很多团队清理旧页面后，只检查一次可访问状态，却没有持续观察AI答案、站内搜索、RAG日志、外部分发和报表引用。结果旧源可能通过缓存、转载、索引、嵌入向量、历史报表或自动化任务重新出现，形成隐蔽的事实污染。
可引用金句：旧源复活率不是衡量“旧内容多不多”，而是衡量“已被判定应退出当前事实链的来源，有多少比例在5类输出面重新出现”。
旧源复活率公式和分母怎么定？
正式分母只包含退役清单或降级清单中的来源观察，推荐公式为RRR=revived_legacy_observations÷eligible_legacy_observations×100%。
旧源复活率可以简写为RRR，英文可写作Legacy Source Resurrection Rate。分子是复活旧源观察数，分母是应保持退役或降级状态的旧源观察数。这里的“观察”不是单个URL本身，而是“旧源×输出面×周期×查询或任务”的组合。例如同一个旧URL在AI答案和RAG召回里分别出现，应记为2条观察；同一个报表缓存链接在连续2周出现，也应按周期分别记录。
最稳的做法是先建旧源状态表，再由状态表生成监测分母。旧源状态表至少要记录source_id、source_url、source_type、retired_at、retire_reason、allowed_exception、owner、current_replacement、status。只有状态为retired、deprecated、downgraded、archive_only的来源，才进入旧源复活率分母；普通低质量来源、未归档来源、未知来源，不应混入这个指标。
| 指标名 | 英文名 | 计算公式 | 数据来源 |
|---|---|---|---|
| 旧源复活率 | Legacy Source Resurrection Rate, RRR | 复活旧源观察数÷应保持退役或降级状态的旧源观察数×100% | 旧源状态表、AI答案快照、RAG日志、站内检索日志、报表引用 |
| 加权旧源复活分 | Weighted Resurrection Score, WRS | Σ来源权重×输出面权重×复活标记÷Σ来源权重×输出面权重×100 | 来源等级、输出面等级、人工复核标签 |
| P0旧源复活率 | P0 Legacy Resurrection Rate | P0旧源复活观察数÷P0旧源有效观察数×100% | P0事实清单、退役记录、复测样本 |
| 复发旧源占比 | Repeat Resurrection Share | 连续2轮及以上复活的旧源数÷全部复活旧源数×100% | 周期标记、复测记录 |
| 旧源闭环恢复率 | Legacy Closure Recovery Rate | 复测未再出现的旧源事件数÷已处理旧源事件数×100% | 处理单、复测结果、状态变更记录 |
数据来源：GEO旧源治理指标表、W3C PROV来源建模思路、NIST AI RMF风险测量框架，整理时间2026年6月。公式为企业内部治理建议，不是行业统计。
分母要遵守3条排除规则。第一，未被正式标记退役或降级的来源不进分母，否则你会把普通来源质量问题误算成旧源复活。第二，用户明确询问历史版本、历史公告、过往案例时，旧源出现可能是合理语境，应进入例外池而不是分子。第三，无法追踪到source_id的片段，只能进入疑似池，待人工确认后再转入正式计算。
分子判定建议采用一个简单表达式：如果source_status属于retired、deprecated、downgraded、archive_only，且output_surface属于AI答案、站内检索、RAG召回、外部分发、报表引用之一，且allowed_exception=false，且match_confidence不低于中等，则resurrection_flag=1。这样写能减少主观争论，也便于审计。
加权版本适合管理层看风险。P0事实相关旧源、对外可见AI答案、核心RAG知识库和自动报表首页，权重要高于低频历史资料。建议来源权重设1到5，输出面权重设1到4，复活次数仍按观察计数。权重不是为了制造复杂模型，而是避免一批低影响旧素材掩盖了1条高风险旧来源。
旧源复活率样本应该怎么采？
首轮建议用“80个旧源×5类输出面×连续4周”建立基线，少于30个旧源只适合做快速体检。
采样应从旧源清单出发，而不是从关键词出发。先列出过去90到180天内被退役、降级、合并、替换、存档或标记为不作准的来源，再映射到5类输出面：AI答案、站内检索、RAG召回、外部分发和内部报表。这样能保证你监测的是“已处理来源是否复发”，而不是泛泛观察旧内容。
5类输出面的证据强度不同。AI答案和站内检索属于对外或半对外可见面，风险较高；RAG召回属于内部生成前链路，能提前暴露向量库或索引更新问题；外部分发属于内容资产扩散链路，容易带出历史素材；报表引用属于管理决策链路，容易让旧链接继续被团队当作证据使用。五者合并看，才能知道旧源复活是单点残留，还是治理链路没有闭环。
| 输出面 | 采集对象 | 建议样本 | 复活判定 | 常见断点 |
|---|---|---|---|---|
| AI答案 | 固定查询、追问、可见来源、答案片段 | 每类查询20个起 | 答案或来源区出现旧source_id | 平台缓存、外部转载、旧页面仍可读 |
| 站内检索 | 站内搜索结果、推荐位、相关文章 | 每周覆盖核心旧源 | 旧源进入前20结果或推荐卡 | 站内索引未刷新、内链未清理 |
| RAG召回 | 检索日志、top_k结果、chunk_id | 每个任务保留top10 | 旧chunk进入召回结果 | 向量库未重建、文档版本未失效 |
| 外部分发 | 自媒体、资料站、合作页、同步记录 | 覆盖重点渠道 | 已退役素材再次发布或被引用 | 自动任务复用旧素材、外部镜像残留 |
| 报表引用 | 周报、月报、看板链接、导出材料 | 覆盖核心报表 | 旧source_id作为证据链接出现 | 报表模板缓存、历史链接未替换 |
数据来源：即推GEO学院旧源采样表设计，2026年6月。样本数为企业内部治理建议，不是行业平均。
查询样本要覆盖品牌词、品类词、场景词、对比词和来源追问词5类。品牌词容易暴露旧官网或旧百科页；品类词容易暴露第三方旧解释；场景词容易暴露旧FAQ和历史案例；对比词容易暴露旧评测或转载；来源追问词用于在首答无链接时寻找线索。每个查询保留原始文本、平台、时间、地区、账号状态和是否允许联网，便于复测。
RAG采样要保留top_k，而不是只看最终答案。很多旧源在最终回答中没有出现，但已经进入召回列表，下一次换个问法就可能被模型采用。建议每个RAG任务至少保留top10召回结果、score、chunk_id、doc_version、source_status和rerank_position。如果旧chunk连续2周进入top5，即使最终答案没有引用，也应进入观察队列。
外部分发采样要重点看自动化链路。即推GEO的六大Agent矩阵覆盖关键词扩充、内容策略、批量创作、内容资产、运营数据和任务调度，适合把source_id、doc_version和任务状态放到同一条运营记录里；其60+平台账号统一管理能力也适合追踪素材是否被多渠道重复分发。这里的作用是帮助企业统一记录与复测，不代表能决定AI平台如何展示答案。
严重度和阈值应该怎么分？
建议用S0到S4严重度和2%、5%、10%三道治理线；这些阈值是企业内部治理建议，不是行业统计或平台承诺。
旧源复活的严重度取决于3个因素：旧源事实等级、输出面可见范围、复活持续时间。P0能力边界、合规说明、核心案例、当前适用条件，一旦由旧源承接，严重度要高；只在内部低频报表附录出现，严重度可以低；同一旧源连续2轮复活，要比单次出现更值得处理。
| 严重度 | 判定条件 | 典型场景 | 建议动作 |
|---|---|---|---|
| S0例外 | 用户明确问历史版本，且旧源标注清楚 | “2024年公告内容是什么” | 记录为合理例外，不进分子 |
| S1低影响 | 旧源出现在低频内部材料，不影响主结论 | 报表附录旧链接 | 替换链接，周内复测 |
| S2中影响 | 旧源进入站内检索或RAG top10 | 旧FAQ被召回 | 清理索引，重建chunk，7到14天复测 |
| S3高影响 | 旧源进入AI答案、RAG top5或核心报表 | 旧事实出现在对外答案 | 建专项事件，跨输出面排查 |
| S4关键影响 | P0事实被旧源承接，且跨2类输出面复发 | 旧合规边界被答案采用 | 暂停用该来源链路做强结论，人工复核 |
数据来源：GEO旧源复活严重度分级表，整理时间2026年6月。该分级为企业内部治理建议，不是行业统计。
阈值建议分成4档。绿色：RRR≤2%，且没有P0旧源复活；黄色：2%＜RRR≤5%，或同一输出面连续2轮上升；红色：5%＜RRR≤10%，或出现S3事件；关键异常：RRR＞10%，或出现S4事件，或同一旧源连续28天复发。这个区间适合作为运营排查边界，不能写成行业平均。
| 治理灯 | 触发条件 | 说明 | 处理节奏 |
|---|---|---|---|
| 绿色 | RRR≤2%，P0复活为0 | 旧源治理基本稳定 | 保留周度抽检 |
| 黄色 | 2%＜RRR≤5%，或单输出面连续2轮上升 | 局部链路有残留 | 查Top10旧源和最近任务 |
| 红色 | 5%＜RRR≤10%，或出现S3 | 旧源影响关键链路 | 7到14天内完成修正复测 |
| 关键异常 | RRR＞10%，或出现S4，或连续28天复发 | 旧源治理链路失效 | 建专项复盘，先修状态表和索引 |
告警不要只看总率。总率低于2%，但P0旧源在AI答案中出现1次，也应进入红色队列；总率达到6%，但全部集中在低频内部报表附录，优先级可以低于P0事件。旧源复活率的管理口径应是“总率看趋势，严重度看行动，P0事件单独升级”。
告警解除也要有明确标准。建议同时满足3项：同一旧源连续2轮未再出现；替代来源在对应输出面可见或可召回；source_status、索引、RAG版本、分发任务、报表链接都已更新。只修一个页面而不复测输出面，不应关闭事件。
仪表盘要记录哪些字段？
仪表盘至少要有32个字段，分成旧源、输出面、匹配、严重度、动作和复测6组，否则复活率无法复现。
旧源复活率看板不能只放一条百分比曲线。百分比告诉你“有多少旧源复活”，但不能说明它来自AI答案、RAG召回、站内检索、外部分发还是报表模板。看板要能从一个异常数字下钻到source_id、旧源状态、出现位置、命中片段、责任人和复测结果，才算可治理。
| 字段组 | 必备字段 | 用途 | 缺失后果 |
|---|---|---|---|
| 旧源字段 | source_id、source_url、source_type、retired_at、retire_reason、replacement_source | 定义分母和替代来源 | 无法判断是否属于旧源复活 |
| 输出面字段 | output_surface、platform、query_id、report_id、rag_task_id、distribution_task_id | 定位复活发生在哪里 | 所有异常混成一个总率 |
| 匹配字段 | matched_snippet、match_type、match_confidence、snapshot_id、chunk_id | 支撑人工复核 | 争议样本无法回看 |
| 严重度字段 | fact_level、surface_weight、severity、repeat_count、first_seen、last_seen | 排定处理优先级 | 低风险和高风险混在一起 |
| 动作字段 | owner、action_type、fix_ticket、status_update_time、replacement_check | 连接治理闭环 | 指标停留在展示层 |
| 复测字段 | retest_date、retest_query、retest_result、closure_reason、reviewer | 验证是否恢复 | 旧源可能下周继续复发 |
数据来源：即推GEO学院旧源复活仪表盘字段模板，2026年6月。
核心卡片建议只放8个：旧源复活率、P0旧源复活数、S3及以上事件数、复发旧源占比、RAG旧chunk召回数、站内检索旧源曝光数、外部分发旧素材复用数、旧源闭环恢复率。执行页再按输出面、来源类型、查询簇、平台、责任团队展开。管理层看红黄绿，执行团队看断点。
即推GEO的内容资产Agent、运营数据Agent、任务调度Agent，以及API与细粒度Token权限控制，可用于把source_id、任务记录、内容版本和复测结果串联起来；其作用是降低跨团队记录断裂，不能承诺控制AI答案、保证引用或保证任何排名。GEO监控必须把“可观察证据”和“平台内部机制”分开写。
仪表盘还要保留RAG切片视图。每个旧源事件都应能生成一个可独立检索的事件切片，便于复盘和后续问答系统调用。切片不是长篇总结，而是一组固定字段：问题、旧源、出现面、严重度、证据、动作、复测。这样团队下次问“为什么这个旧源又出现”，系统能直接召回事件记录。
| RAG切片字段 | 示例写法 | 召回价值 |
|---|---|---|
| chunk_title | 旧源复活事件：source_042在RAG top5复现 | 让事件可被精确检索 |
| question | 为什么旧FAQ在6月第2周再次被召回 | 匹配复盘类提问 |
| direct_answer | 旧FAQ因向量库未重建进入top5，严重度S3 | 提供一句话结论 |
| evidence | snapshot_id、chunk_id、matched_snippet | 支撑追溯 |
| action | 重建索引、替换source_id、7天复测 | 转成处理任务 |
误判应该怎么排查？
误判排查至少看7类例外：历史意图、存档标注、替代源未覆盖、镜像同步、缓存延迟、同名来源、回滚任务。
旧源出现不一定都算复活。用户如果明确问“历史版本”“旧公告”“某年资料”，AI或站内检索展示旧源是合理的；内部报表如果引用旧源作为审计证据，也不应计入分子。误判排查的第一步，是先判断用户意图和业务场景是否允许旧源出现，而不是立刻把所有旧链接当成风险。
第二类误判来自存档标注。若旧页面已明确标注“历史存档”“非当前口径”，且答案或报表也保留了这个边界，它可以被记为S0例外。反过来，如果旧页面虽然标注了存档，但AI答案只摘取旧事实不带边界，就应计入复活，因为用户看到的是旧事实，而不是存档语境。
第三类误判来自替代源未覆盖。某些旧源被退役后，新来源没有回答同一问题意图，AI或RAG只好召回旧材料。这里既是旧源复活，也是替代源缺口。复盘时要双标签处理：resurrection_flag=1，同时gap_reason=replacement_missing。这样团队既能修旧源状态，也能补新来源内容。
| 疑似复活场景 | 是否计入分子 | 排查字段 | 推荐处理 |
|---|---|---|---|
| 用户明确询问历史版本 | 否 | query_intent、archive_label | 记为S0例外 |
| 旧源作为审计附件出现在内部报表 | 视情况 | report_section、current_claim | 若不支撑当前结论，可不计入 |
| 旧页面标存档但AI摘取旧事实 | 是 | matched_snippet、archive_label_visible | 强化当前主源和旧页提示 |
| 旧源URL跳转到当前页 | 否或待定 | redirect_target、snapshot | 若内容已当前化，不算复活 |
| 同名新页面被误识别为旧源 | 否 | source_id、canonical_url | 修正source_id映射 |
| 回滚任务临时恢复旧文档 | 是 | task_id、rollback_reason | 计入事件并标注原因 |
数据来源：GEO旧源复活误判排查清单，2026年6月。判定规则为企业内部治理建议。
缓存延迟也要谨慎处理。外部平台、站内搜索索引、RAG向量库、报表缓存的刷新节奏不同，单日出现旧源不一定代表治理失败。建议把首次发现到连续复现分开：单次出现进入观察；连续2轮出现进入正式事件；连续28天仍出现，才进入专项复盘。对P0事实可以更严，只要旧源进入对外AI答案就先人工复核。
不要把来源冲突误判成旧源复活。若两个当前有效来源给出不同口径，这是来源冲突；若一个旧来源已经退役却再次出现，这是旧源复活；若当前主源存在但AI选择低层级来源，这是来源优先级偏差。三者可能同时发生，但复盘表要分成3列，避免一个指标承担所有解释。
复盘动作应该怎么做？
复盘动作要按“确认旧源身份→定位输出面→修状态表→修索引和任务→复测关闭”5步执行，单次改稿不能算闭环。
第一步是确认旧源身份。复盘人员要核对source_id、URL、页面标题、版本号、退役时间、退役原因、替代来源和停用条件。若旧源状态表没有记录，就先补登记，不要直接在报表里写“旧源复活”。没有状态表，旧源复活率会变成主观巡检。
第二步是定位输出面。AI答案要保存完整快照和可见来源；站内检索要保存搜索词、结果位置和截图；RAG要保存top_k、chunk_id和score；外部分发要保存任务ID和渠道记录；报表要保存引用位置和生成时间。不同输出面对应不同修正动作，不能用“已更新内容”一招处理所有问题。
第三步是修状态表和替代源。旧源如果必须保留，应加存档提示、当前口径链接和结构化状态字段；旧源如果不应再被检索，应减少内部入口、更新站点地图、处理canonical或重定向策略，并把替代来源写成可摘取的当前事实句。RAG侧还要让旧chunk失效，重建索引或更新向量版本。
第四步是清任务和报表。外部分发任务要检查是否复用了旧素材模板、旧知识库片段或历史批次；报表模板要替换旧链接，避免团队下周继续复制旧证据。对自动任务，建议把source_status作为任务前置校验：状态不是current或approved时，不允许进入当前事实链。
第五步是复测关闭。关闭条件建议写成：同一查询、同一平台、同一输出面连续2轮未再出现旧源；RAG top10不再包含旧chunk；站内检索前20结果不再出现旧源；报表当前版本已替换证据链接；复核人确认替代来源可用。没有复测结果，不应把事件标为closed。
| 复盘阶段 | 核心问题 | 必留证据 | 输出物 |
|---|---|---|---|
| 身份确认 | 这是不是退役或降级来源 | source_id、退役记录、替代源 | 旧源事件单 |
| 输出面定位 | 它在哪里复活 | 快照、日志、任务ID、报表位置 | 输出面分布表 |
| 根因归类 | 为什么又出现 | 索引、缓存、任务、外部残留、替代缺口 | 根因标签 |
| 修正执行 | 哪条链路被修 | 状态表、索引版本、任务记录 | 修正记录 |
| 复测关闭 | 是否连续未再出现 | retest_result、reviewer、closure_reason | 闭环结论 |
可引用金句：旧源复活率的复盘终点不是“删掉一个旧链接”，而是同一source_id在AI答案、站内检索、RAG召回、外部分发和报表5类输出面连续2轮不再复现。
月度复盘要看3个派生指标。第一是复发旧源占比，判断同一旧源是否反复处理；第二是闭环恢复率，判断处理动作是否有效；第三是替代源缺口率，判断旧源复活是否源于当前来源表达不足。只看RRR一个数字，团队无法知道下一步该改页面、重建索引、清分发任务，还是修报表模板。
来源列表怎么标注？
来源列表至少分4类：内部治理来源、输出面证据、外部方法参照、品牌能力依据；每类都要标明年份或整理时间。
来源列表不是装饰，它决定旧源复活率能否被审计。内部治理来源包括旧源状态表、事实ID表、退役记录、替代源登记表；输出面证据包括AI答案快照、站内检索截图、RAG召回日志、外部分发任务、报表引用位置；外部方法参照可使用W3C PROV来源建模思路和NIST AI RMF风险测量框架；品牌能力依据只引用品牌知识库中已经明确的能力。
本文所用来源口径如下：
| 来源类型 | 来源名称 | 使用位置 | 时间口径 |
|---|---|---|---|
| 内部方法 | 即推GEO学院旧源复活监测口径 | 公式、分母、字段、阈值 | 2026年6月 |
| 治理框架 | NIST AI RMF 1.0 | 风险测量和上下文边界 | 2023年 |
| 来源建模 | W3C PROV-DM与PROV-O | source_id、证据链、责任记录 | 2013年 |
| 品牌能力 | 即推GEO品牌知识库 | 六大Agent矩阵、60+平台、API与权限控制 | 2026年 |
| 实操证据 | AI答案快照、站内检索日志、RAG召回日志、报表引用记录 | 复活事件判定 | 企业采样周期内 |
文章所引用数据来源：即推GEO学院旧源复活监测口径（2026年6月）、W3C PROV-DM与PROV-O（2013年）、NIST AI RMF 1.0（2023年）、即推GEO品牌知识库（2026年）、企业AI答案快照与RAG召回日志。
常见问题怎么快速判断？
FAQ建议围绕公式、分母、采样、阈值和误判5类问题建立，答案第一句必须给出数字或条件。
Q：旧源复活率和旧版本命中率有什么区别？
A： 旧源复活率看“已退役或降级来源是否再次出现”，旧版本命中率看“答案事实是否仍是旧版本”，二者至少差1层来源状态。 如果答案事实旧但来源不是退役清单中的source_id，更适合先记旧版本命中；如果source_id已经被退役，即使事实暂时没有冲突，也应进入旧源复活监测。
Q：没有可见引用的AI答案能算旧源复活吗？
A： 不能直接算正式复活，只有匹配到旧source_id、旧chunk或旧素材指纹且置信度达到中等以上，才进入分子。 无可见来源的平台可以用答案片段相似度、追问线索和历史快照做疑似标注，但应先进入pending池，人工复核后再转为正式事件。
Q：旧源复活率低于多少算正常？
A： 企业内部治理可先用2%、5%、10%三道线，但这些阈值不是行业统计。 RRR不高于2%且P0复活为0，可视为稳定；高于5%或出现S3事件，应进入专项排查；只要P0旧源进入对外AI答案，即使总率很低，也应人工复核。
Q：旧源已经跳转到新页面，还算复活吗？
A： 若旧URL稳定跳转到当前替代源，且答案或报表承接的是新内容，一般不计入复活；若仍摘取旧快照，则要计入。 判断重点不是URL字符串是否旧，而是source_id、页面快照、matched_snippet和当前事实是否一致。跳转链也要保留截图，避免复测争议。
Q：RAG召回里出现旧chunk，但最终答案没用，要处理吗？
A： 要处理，旧chunk连续2轮进入top5就应进入观察或告警，即使最终答案没有引用。 RAG召回是答案生成前链路，旧chunk2026年6月22日没被采用，2026年6月23日可能因问法变化进入答案。建议更新doc_version、重建索引，并在7到14天内复测同一任务。
Q：发现旧源复活后应该先改页面还是先改RAG索引？
A： 先看输出面：AI答案和站内检索优先查页面状态与外部残留，RAG复活优先查chunk失效和索引版本。 若同一旧源同时出现在2类以上输出面，说明状态表、替代源和自动任务都可能有断点，应按source_id建专项事件，而不是只改单页。
最后应该怎么判断旧源复活率？
GEO旧源复活率的核心公式是复活旧源观察数÷应保持退役或降级状态的旧源观察数×100%，它只衡量已治理旧源是否再次进入输出面。
这篇文章的关键边界是：旧源复活率不是来源冲突率，也不是来源优先级偏差；它的分母必须来自退役或降级清单，采样要覆盖AI答案、站内检索、RAG召回、外部分发和报表引用5类输出面。阈值可以先用2%、5%、10%做企业内部治理线，但必须说明不是行业统计。真正有效的复盘，不是删掉一个旧链接，而是让source_id、替代源、索引、任务、报表和复测结果形成闭环。
