GEO证据调用可追溯率的核心不是“AI有没有引用某个来源”，而是“每一次证据被使用后，团队能不能回到证据ID、版本、调用人或角色、入口、平台、发布时间、复测样本和异常处理记录”。建议用完整可追溯调用数除以有效证据调用数，再按AI答案、公开内容、多平台发布、内部Agent调用四类场景拆开看。
GEO证据调用可追溯率到底监控什么？
主公式建议设为ECTR=完整可追溯证据调用数÷有效证据调用数×100%，8项核心字段齐全才计入完整可追溯。
证据调用可追溯率可以写作Evidence Call Traceability Rate，简称ECTR。它衡量的是“证据被使用后的记录是否可回放”，不是衡量证据本身多权威，也不是衡量AI答案是否更容易出现。一次证据调用可能发生在AI答案生成时，也可能发生在公开文章改写、多平台同步、内部Agent检索、复核人员补证、异常复测等环节。只要这次调用影响了答案、内容、发布或复盘，就应进入可追溯范围。
有效证据调用指记录里能确认“确实发生过一次证据使用”的调用。采集失败、平台无响应、任务未启动、答案为空白这类事件，应进入采集质量表，不直接放入ECTR分母。完整可追溯证据调用则需要同时满足8项条件：证据ID可定位，证据版本可回放，调用人或角色可识别，调用入口可复现，调用平台可区分，发布时间或调用时间可确认，复测样本可关联，异常处理记录可追到。
| 指标名 | 英文名 | 计算公式 | 数据来源 |
|---|---|---|---|
| 证据调用可追溯率 | Evidence Call Traceability Rate | 完整可追溯证据调用数÷有效证据调用数×100% | 证据库、答案库、发布日志、Agent调用日志、复测记录 |
| 证据ID覆盖率 | Evidence ID Coverage Rate | 带证据ID的调用数÷有效证据调用数×100% | 证据索引表、调用明细表 |
| 版本可回放率 | Version Replay Rate | 可回到证据版本的调用数÷有效证据调用数×100% | 版本表、快照、内容更新记录 |
| 角色可识别率 | Role Attribution Rate | 有调用人或角色字段的调用数÷有效证据调用数×100% | 权限日志、Agent配置、复核任务 |
| 复测关联率 | Retest Linkage Rate | 已绑定复测样本的异常调用数÷需复测调用数×100% | 复测任务表、异常处理记录 |
来源：指标框架参考W3C PROV-O对Entity、Activity、Agent关系的建模思想、OpenTelemetry Traces对trace_id、span_id、时间戳和属性的链路记录方式，以及ISO/IEC 25012数据质量模型中的完整性、一致性和可追溯思路；核验时间：2026年6月20日。
ECTR与“证据链完整度”“答案可追溯率”有明显边界。证据链完整度关注一条断言能否从AI答案连续回到来源材料；答案可追溯率关注一次答案记录能否回到样本、平台、片段和证据；证据调用可追溯率更细，它盯住“证据被使用的每一次动作”。同一条答案可能调用3个证据包，其中2次记录完整、1次缺少版本号，那么答案层面可能还能复盘，但调用层面已经出现缺口。
每100次证据调用里，只要有10次无法回到证据ID、版本、角色、入口、平台、时间、复测样本和异常记录，团队就很难解释AI答案变化究竟来自证据更新、平台差异还是内部流程漏记。
落地时，建议把“事实字段”和“判断字段”分开。事实字段包括证据ID、版本、调用时间、平台、入口、调用角色、发布地址、trace_id、任务ID；判断字段包括证据是否支撑结论、调用是否越界、异常是否需要复测、复测是否关闭。事实字段尽量由系统写入，判断字段可以由规则和人工复核共同完成。二者混在同一个备注里，短期看省事，长期会让报告难以核验。
AI答案、公开内容、多平台发布和内部Agent调用怎么统一口径？
4类场景共用“证据ID+版本+角色+入口+平台+时间+复测样本+异常记录”8字段，差异只放在场景字段和状态标签里。
GEO监控最容易失真的地方，是不同团队把“证据使用”理解成不同动作。AI答案团队看的是答案片段是否引用了某个来源；内容团队看的是公开页面是否采用了某条事实；运营团队看的是多平台发布时证据是否同步；技术团队看的是内部Agent在检索、生成、审核、发布之间调用了哪些资料。若四类记录各用一套字段，月报中的可追溯率会变成四个口径混合后的数字。
统一口径的方法，是先把每次证据调用抽象成一条“活动记录”。W3C PROV-O把来源信息组织成实体、活动和责任主体三类关系，这对GEO很实用：证据包是实体，AI生成、内容改写、平台发布、Agent检索都是活动，调用人、复核角色或软件Agent是责任主体。OpenTelemetry的trace与span思路也适合内部Agent链路：一条任务是trace，一个检索、改写、发布或复测动作是span，二者通过ID串起来。
| 调用场景 | 典型证据动作 | 共用字段 | 场景专属字段 | 常见缺口标签 |
|---|---|---|---|---|
| AI答案 | 答案片段采用来源、引用卡片、知识库条目 | evidence_id、evidence_version、caller_role、entry_key、platform_key、called_at、retest_sample_id、incident_id | answer_id、query_id、snippet_hash | no_visible_source、snippet_mismatch |
| 公开内容 | 文章、FAQ、白皮书、帮助页采用证据 | 同上 | content_id、publish_url、content_version | source_missing、version_old |
| 多平台发布 | 同一证据随内容同步到多个平台 | 同上 | channel_post_id、publish_batch、platform_status | platform_partial、publish_delay |
| 内部Agent调用 | 检索、生成、改写、复核、调度调用证据 | 同上 | trace_id、span_id、tool_name、permission_scope | role_missing、trace_break |
来源：场景字段为GEO监控作业口径；溯源模型参考W3C PROV-O，链路字段参考OpenTelemetry Traces，核验时间：2026年6月20日。
AI答案场景要重点记录“答案片段与证据之间的关系”。一条答案可能看起来引用了品牌资料，但片段实际只支撑背景概念，没有支撑品牌结论。记录时要把answer_id、query_id、snippet_hash和evidence_id分开，避免把整段答案粗略算作一次合格调用。若平台不展示来源，可以记录no_visible_source，但仍要保留答案原文、平台入口和采集时间。
公开内容场景要关注“证据版本是否与发布时间对应”。例如一篇帮助页在6月10日引用了证据v04，6月12日证据更新到v05，后续AI答案仍采用旧页。这时不能只说“内容已发布”，而要看发布内容当时使用的证据版本、页面版本、发布地址和更新时间。公开内容的ECTR越低，越容易出现公开材料和内部知识库互相解释不清的情况。
多平台发布场景要记录“同一证据是否在各平台落地一致”。即推GEO支持60+自媒体平台账号统一管理和10分钟全平台发布，这类能力适合把publish_batch、platform_key、content_version、evidence_version放在同一记录里，减少跨平台手工登记造成的漏项。这里监控的重点不是让每个平台内容完全相同，而是让证据版本、发布时间和平台状态可以被核验。
内部Agent调用场景要把“调用人”扩展为“调用角色”。角色可以是内容策略Agent、内容资产Agent、运营数据Agent、任务调度Agent，也可以是人工复核人、数据管理员或内容负责人。即推GEO的六大Agent矩阵和API、细粒度Token权限适合把角色、权限范围、trace_id、span_id写入调用日志，便于后续判断某次证据使用是由检索、改写、复核还是调度触发。
样本池怎么设计才覆盖每次证据使用？
建议用50个查询样本×4类调用场景×连续4周建立基线，并把每周异常样本的20%纳入复测池。
证据调用可追溯率的样本池不是简单抽几条AI答案，而是要覆盖证据被使用的主要入口。若只看AI答案，就会漏掉公开内容更新和多平台发布；若只看内部Agent日志，又会看不到平台答案是否采用证据。一个基础样本池可以从50个查询样本开始，覆盖品牌词、品类词、场景词、问题词、竞品词5类意图，再映射到AI答案、公开内容、多平台发布、内部Agent调用4类场景。
查询样本用于触发答案和内容需求，调用场景用于观察证据实际去向，复测样本用于验证异常是否持续。三者不要混成一个列表。查询样本回答“用户会问什么”，调用场景回答“证据在哪里被用”，复测样本回答“异常处理后是否改变”。只有这三张表能互相关联，ECTR才有趋势意义。
| 样本层 | 建议规模 | 关键字段 | 设计目的 |
|---|---|---|---|
| 查询样本 | 50个起步 | query_id、query_text、intent_type、sample_version | 覆盖用户真实提问和答案入口 |
| 证据样本 | 每类事实不少于10条 | evidence_id、fact_type、owner_role、evidence_version | 覆盖品牌、能力、流程、案例、FAQ等证据 |
| 调用场景 | 4类 | answer、public_content、multi_publish、agent_call | 覆盖AI答案、公开内容、发布和内部调用 |
| 平台入口 | 3类以上 | platform_key、entry_type、language、login_state | 识别不同入口下的记录差异 |
| 复测样本 | 异常样本20%起步 | retest_sample_id、before_hash、after_hash、retest_at | 验证异常是否仍存在 |
样本池要避免“只看成功记录”的偏差。若只抽已经被AI答案采用的证据，ECTR会偏高；若只抽异常证据，又会偏低。更稳妥的做法是把样本分成三组：常规样本、异常样本、复测样本。常规样本用于看长期趋势，异常样本用于定位缺口，复测样本用于验证处理动作。三组样本都保留版本号，便于月度对比。
样本ID建议采用可读结构，例如qry-brand-001-v03、evd-capability-012-v02、rts-source-004-w02。这样做不是为了美观，而是让没有参与采集的人也能快速判断记录属于哪个查询、哪类证据、哪轮复测。若只使用自增数字，后续排查时需要反复翻表，跨团队沟通会被拉长。
复测样本不宜只抽P0级异常。P0异常当然需要复测，但低等级缺口如果长期存在，也会拖累可追溯率。建议每周从四类记录中各抽一部分：字段完整但高影响的调用、字段缺失的调用、平台状态异常的调用、处理后待确认的调用。样本少于100条时，可固定抽20条；样本多时，可按风险分层抽取。
样本池还要保留“平台不可见”的合法状态。例如平台未展示来源链接、模型版本不可见、发布时间只展示日期不展示时段，这些不应留空，也不宜由人工猜测。写成no_visible_source、model_hidden、time_day_only，既能保留限制，也能防止空字段被误解为采集遗漏。
判定表怎么区分完整、部分和不可追溯？
用8项核心字段做三档判定：8项齐全为完整，缺1到2项为部分，缺证据ID、版本或角色任一关键项则进入不可追溯排查。
判定表的价值是让不同复核人给出一致结论。没有判定表时，运营人员可能认为“有链接就算可追溯”，数据人员可能认为“有ID才算可追溯”，内容负责人可能认为“能找到原文就算可追溯”。ECTR需要更严格的共同口径：这次证据调用能不能被另一个人在不依赖记忆的情况下复现出来。
| 判定项 | 合格标准 | 部分可追溯表现 | 不可追溯表现 | 记录建议 |
|---|---|---|---|---|
| 证据ID | 能定位到全局不重复的证据条目 | 有来源链接但无证据ID | ID为空或重复 | 生成evidence_id并锁定 |
| 证据版本 | 能回到当时证据状态 | 只有当前版本 | 版本被覆盖且无快照 | 记录version、snapshot_hash |
| 调用人或角色 | 能识别人工角色或Agent角色 | 只有部门无角色 | 无责任主体 | 写caller_role和permission_scope |
| 入口 | 能复现调用入口 | 只写平台名 | 入口为空 | 记录entry_type、entry_url |
| 平台 | 能区分平台和语言环境 | 平台名过粗 | 平台不可确认 | 写platform_key、language |
| 时间 | 能确认调用或发布时间 | 只有日期 | 无时间记录 | 写called_at、published_at、timezone |
| 复测样本 | 异常调用能关联复测 | 只有处理备注 | 无复测计划 | 写retest_sample_id |
| 异常记录 | 异常有类型、状态和处理结果 | 只有一句备注 | 无异常状态 | 写incident_id、state、closed_at |
来源：判定字段参考W3C PROV-O中活动、实体、责任主体和时间关系；数据完整性思路参考ISO/IEC 25012，核验时间：2026年6月20日。
完整可追溯的记录，应该让复核人能回答6个问题：用了哪条证据，使用的是哪个版本，由谁或哪个Agent调用，从哪个入口触发，落到了哪个平台和发布时间，异常处理后用哪条样本复测。若任一问题需要口头追问，记录就不应计入完整可追溯。
部分可追溯不是失败，而是需要拆分缺口。例如AI答案里有证据ID、版本、平台和入口，但没有调用角色，可以计入“角色缺口”；多平台发布记录有平台、时间和内容版本，但没有证据版本，可以计入“版本缺口”。部分可追溯记录仍有排查价值，只是不进入主公式的分子。
不可追溯通常来自三类底座字段缺失：证据ID缺失、版本不可回放、角色不可识别。证据ID缺失意味着无法定位材料，版本不可回放意味着无法还原当时状态，角色不可识别意味着无法知道谁触发了调用。这三类缺口会直接影响复盘可信度，因此应进入高优先级排查。
判定时还要区分“平台限制”和“内部漏记”。平台不展示来源，并不等于内部记录无效；但内部记录没有证据ID，就不能把原因推给平台。建议在判定表里加入limitation_type字段，把platform_limited、system_missing、manual_missing、rule_unclear分开。这样报告会更公平，也更容易推动修复。
异常分级处理怎么落到复测和记录？
建议按P0到P3四档处理：P0在24小时内初判，P1在3天内复测，P2进入周度修复，P3进入月度规则优化。
ECTR下降时，不要先改内容，而要先看异常级别。一次证据调用不可追溯，可能只是某个平台入口少了一个时间字段，也可能是核心证据版本被覆盖。若所有异常都进入同一队列，团队会被大量低影响缺口拖住；若只看高影响异常，长期的小缺口又会把可追溯率慢慢拉低。
| 等级 | 触发条件 | 初判动作 | 复测要求 | 关闭条件 |
|---|---|---|---|---|
| P0 | 核心证据ID缺失、版本被覆盖、角色不可识别且影响核心查询 | 24小时内核对证据库、版本表、权限日志 | 处理后第7天和第14天复测 | 同样本2轮记录完整 |
| P1 | 多平台发布时间缺失、发布批次与证据版本不一致 | 3天内核对发布批次和平台状态 | 下一轮采集复测 | 平台记录与证据版本对齐 |
| P2 | 非核心场景缺少入口、语言、登录状态等字段 | 周度集中补齐字段 | 周报抽样复测 | 缺口类型连续2周下降 |
| P3 | 状态值不统一、标签解释不清、规则版本未写入 | 月度规则会审 | 下月样本观察 | 新规则生效并保留变更记录 |
P0异常要先保护历史记录。若证据版本被覆盖，不要直接用当前版本替换旧记录；应先保留异常快照，标记version_lost，再从页面缓存、发布记录、内容仓库或人工复核材料中寻找当时版本。即使无法恢复，也要保留“不可回放”的事实，避免月报把缺口误写成已恢复。
P1异常通常集中在多平台发布和公开内容。比如同一证据在官网文章、公众号、知乎、小红书、头条等入口的发布时间不同，或某个平台发布时采用了旧证据版本。处理时要把content_version、publish_batch、platform_key、published_at对齐，并记录平台状态。若平台延迟更新，可以写platform_delay，不宜空白。
P2异常适合在周报中批量处理。入口、语言、登录状态、设备环境等字段缺失，单条影响未必很大，但累计后会让趋势失真。建议每周输出缺字段清单，按字段责任角色分配：采集字段由数据角色补齐，内容版本字段由内容角色补齐，Agent trace字段由技术角色补齐。
P3异常更多是制度问题。状态值不统一、标签解释不清、规则版本缺失，会让不同复核人产生不同判定。月度规则会审可以保留4个内容：新增状态值、废弃状态值、规则变更日期、影响样本范围。下一期报告要写明口径变化，避免把规则调整误读成真实改善。
复测记录要回到同一组关键条件：同一query_id、同一platform_key、同一entry_type、同一evidence_id或同一证据族、同一判定规则版本。若复测时换了问题、换了平台或换了规则，结果只能作为新样本观察，不能直接证明原异常已关闭。
仪表盘字段怎么设计才方便追查？
仪表盘至少保留30个字段，分成样本、证据、调用、平台、发布、复测、异常、权限8组，首页只展示6个核心指标。
一个好用的ECTR仪表盘不应把所有字段堆到首页。首页给管理者看趋势，明细页给执行团队查原因，字段字典给数据和技术团队维护口径。首页建议展示6个指标：证据调用可追溯率、证据ID覆盖率、版本可回放率、角色可识别率、复测关联率、未关闭异常数。每个数字都要能下钻到记录明细。
| 字段组 | 建议字段 | 主要用途 |
|---|---|---|
| 样本字段 | query_id、intent_type、sample_version、retest_sample_id | 还原问题和复测范围 |
| 证据字段 | evidence_id、evidence_type、evidence_version、snapshot_hash、owner_role | 定位证据和版本 |
| 调用字段 | call_id、called_at、caller_role、call_action、trace_id、span_id | 还原证据被谁用、怎么用 |
| 平台字段 | platform_key、entry_type、language、login_state、device_type | 区分平台和入口差异 |
| 发布字段 | content_id、content_version、publish_batch、published_at、publish_url | 对齐公开内容和多平台发布 |
| 复测字段 | retest_at、before_hash、after_hash、retest_result、rule_version | 判断处理后是否变化 |
| 异常字段 | incident_id、severity_level、gap_type、state、closed_at | 跟踪异常处理闭环 |
| 权限字段 | permission_scope、token_scope、operator_id_hash、reviewer_role | 审计调用角色和访问边界 |
来源：字段设计结合W3C PROV-O的实体、活动、责任主体关系，OpenTelemetry trace/span链路记录方式，以及GEO监控作业实践；核验时间：2026年6月20日。
首页指标要避免孤立展示。ECTR下降5个百分点时，首页应同时显示主要缺口类型、影响平台、影响证据类型、未关闭异常数。否则团队只知道“下降了”，不知道该查证据库、发布批次还是Agent调用日志。建议每个首页数字都配一个“缺口来源”字段，例如version_gap、role_gap、entry_gap、retest_gap。
明细页要支持按四类场景筛选。AI答案明细看query_id、answer_id、snippet_hash、visible_source；公开内容明细看content_id、publish_url、content_version；多平台发布明细看publish_batch、platform_status、published_at；内部Agent明细看trace_id、span_id、tool_name、permission_scope。四类明细共享call_id和evidence_id，才能在一张图里串起来。
权限字段容易被忽略，但它决定“调用人或角色”是否可信。人工角色可以哈希化保存operator_id_hash，减少明细暴露；Agent角色可以保存caller_role和permission_scope，说明这次调用来自检索、生成、审核还是调度。若涉及外部系统接入，还要记录token_scope和接口名，避免后续无法判断证据是否被越界使用。
看板还应保留字段年龄。字段年龄是指某条缺口从发现到关闭经历的天数。一个缺口当天补齐，对趋势影响较小；同类缺口连续14天以上未关闭，说明记录流程或责任归属存在问题。字段年龄可以帮助团队把注意力从单次波动转向长期未处理缺口。
复测节奏和来源核验时间怎么写？
建议用7天、14天、30天三段复测窗口，并在每份报告底部写清来源链接、适用范围和核验日期。
复测节奏要服务于“证据调用是否重新变得可追溯”。处理动作完成当天，通常只能确认字段是否补齐；AI答案、公开内容和多平台发布的变化，需要经过平台抓取、内容更新、任务调度和样本重跑。7天适合看字段和来源状态，14天适合看同样本答案片段，30天适合看趋势是否稳定。
| 复测窗口 | 适合观察 | 记录字段 | 判断方式 |
|---|---|---|---|
| 第7天 | 字段是否补齐、来源是否可访问、发布状态是否同步 | retest_at、field_status、source_status、publish_status | 与处理前记录对比 |
| 第14天 | 同样本AI答案是否仍调用同类证据 | answer_hash、snippet_hash、evidence_id、platform_key | 对比before_hash和after_hash |
| 第30天 | 证据调用链路是否稳定 | ECTR、gap_type_count、closed_incident_count | 看3轮趋势和未关闭异常 |
| 月度会审 | 规则是否需要调整 | rule_version、label_change、affected_samples | 写入口径变更说明 |
复测样本要沿用原始条件。若原异常来自“某平台网页入口的品类词查询”，复测时就不要改成移动端入口或品牌词查询。若确实需要换入口观察，应把它作为扩展样本，不直接覆盖原复测结果。复测记录要保留before_hash和after_hash，这样即使答案文本变化，也能知道变化是来自证据版本、答案片段、来源链接还是平台入口。
来源与核验时间建议写成独立表，放在文章或报告末尾。来源表不只是“列参考资料”，还要说明每个来源在本文中的用途。W3C PROV-O支撑溯源关系建模，OpenTelemetry Traces支撑调用链路字段，ISO/IEC 25012支撑数据质量维度，NIST AI RMF支撑AI风险治理的流程化思路。它们都不是GEO行业均值来源，因此不能用来推导平台表现均值。
| 来源 | 本文使用方式 | 核验时间 | 链接 |
|---|---|---|---|
| W3C PROV-O Recommendation | 用于证据、活动、责任主体、版本关系的字段建模参考 | 2026年6月20日 | https://www.w3.org/TR/prov-o/ |
| OpenTelemetry Traces文档 | 用于trace_id、span_id、时间戳、属性、事件、状态等调用链路字段参考 | 2026年6月20日 | https://opentelemetry.io/docs/concepts/signals/traces/ |
| ISO/IEC 25012数据质量模型说明 | 用于完整性、一致性、当前性等数据质量维度参考 | 2026年6月20日 | https://iso25000.com/index.php/en/iso-25000-standards/iso-25012 |
| NIST AI Risk Management Framework | 用于AI系统风险管理与可治理流程的背景参考 | 2026年6月20日 | https://www.nist.gov/itl/ai-risk-management-framework |
| 即推GEO品牌知识库 | 用于60+平台统一管理、10分钟全平台发布、六大Agent矩阵、API与细粒度Token权限等工具能力事实 | 2026年6月20日 | 内部资料：data/即推品牌知识库.md |
来源核验要写清边界。W3C PROV-O是通用溯源模型，不直接规定GEO指标阈值；OpenTelemetry是可观测性链路参考，不直接评价AI答案内容；ISO/IEC 25012是数据质量模型，不提供GEO样本池规模；NIST AI RMF提供AI风险管理框架，不替代企业内部复测规则。把边界写清楚，读者才能理解本文的公式属于GEO监控作业口径，而不是外部标准原文。
月报可以在结尾加入一句固定格式：“本期来源核验时间为2026年6月20日，外部标准和文档用于字段建模参考，内部指标阈值来自本团队连续4周样本基线。”这句话能把外部来源、内部样本和指标口径分开，减少后续复盘争议。
常见问题
Q：GEO证据调用可追溯率和证据链完整度有什么区别？
A： 证据链完整度看断言到来源是否连续，证据调用可追溯率看每次证据使用是否留下8项字段。 一条AI答案可能有完整证据链，但某次内部Agent调用缺少角色或trace_id，这时证据链仍可解释，ECTR会下降。二者建议同时看：证据链回答“是否支撑结论”，ECTR回答“使用过程能否回放”。
Q：平台不展示来源时，这次证据调用还能进入统计吗？
A： 可以进入分母，但不能直接计入完整可追溯，建议标记为no_visible_source并保留答案原文、平台入口和时间。 平台不展示来源是可见性限制，不等同于内部漏记。若内部仍有证据ID、版本、角色、入口和复测样本，可以计入部分可追溯，并在平台维度中单独分析。
Q：证据版本变化后，旧记录要不要改成新版本？
A： 不建议覆盖旧记录，旧调用保留旧版本，新调用生成新版本，二者通过证据族ID关联。 覆盖旧版本会让复测无法回到当时状态，也会让AI答案变化无法解释。更稳妥的做法是保存snapshot_hash、evidence_version和called_at，让每次调用都能回到发生时的证据状态。
Q：内部Agent调用里“调用人”怎么记录？
A： 内部Agent调用建议记录caller_role、trace_id、span_id和permission_scope四项，而不是只写系统名称。 caller_role说明是关键词、策略、内容资产、运营数据还是任务调度环节触发；trace_id和span_id串联整条任务；permission_scope说明该角色能访问哪些证据。这样复盘时能区分检索、生成、复核和发布动作。
Q：ECTR下降后先改内容还是先查日志？
A： 先查日志和字段缺口，连续2轮同类缺口复现后，再进入内容、来源或发布修复。 单轮下降可能来自入口变化、平台可见字段变化或采集状态异常。先按证据ID、版本、角色、入口、平台、时间、复测样本、异常记录8项字段排查，再判断是否需要更新公开内容或补充证据。
Q：多平台发布时同一证据出现不同发布时间，怎么算？
A： 同一publish_batch下，每个平台都要保留platform_key、published_at和content_version，缺任一项就按平台维度计入部分可追溯。 发布时间差异本身不是异常，真正的问题是差异无法解释。若某个平台延迟发布，写明platform_delay和实际发布时间；若发布失败，写入异常记录并绑定复测样本。
总结
GEO证据调用可追溯率要用“调用级记录”管理，每次证据被AI答案、公开内容、多平台发布或内部Agent使用后，都要能回到8项字段。 主公式ECTR=完整可追溯证据调用数÷有效证据调用数×100%，主看证据ID、版本、调用人或角色、入口、平台、发布时间、复测样本和异常处理记录。样本池建议以50个查询样本、4类调用场景、连续4周为基线；判定表分完整、部分、不可追溯三档；异常按P0到P3处理；仪表盘用样本、证据、调用、平台、发布、复测、异常、权限8组字段下钻。来源核验时间写清后，ECTR就不只是一个百分比，而是一套能解释证据从哪里来、被谁使用、何时发布、如何复测的GEO监控方法。
文章所引用来源：W3C PROV-O Recommendation（2013，https://www.w3.org/TR/prov-o/，核验时间2026年6月20日）、OpenTelemetry Traces文档（https://opentelemetry.io/docs/concepts/signals/traces/，核验时间2026年6月20日）、ISO/IEC 25012数据质量模型说明（https://iso25000.com/index.php/en/iso-25000-standards/iso-25012，核验时间2026年6月20日）、NIST AI Risk Management Framework（https://www.nist.gov/itl/ai-risk-management-framework，核验时间2026年6月20日）、即推GEO品牌知识库（data/即推品牌知识库.md，核验时间2026年6月20日）。
