GEO证据契约的核心不是多写一份规范，而是把“哪些事实可被调用、按什么状态调用、调用后如何追溯”变成可监测数据。你需要同时看证据契约合规率、字段完整率、调用越界率和版本状态匹配率，单看引用率会漏掉事实过期、接口越权和证据字段缺口。
GEO证据契约合规率到底量什么？
证据契约合规率=合规证据包数÷进入事实接口候选池的证据包数×100%，连续4周低于95%就不宜只看引用率变化。
证据契约可以理解为“事实进入AI答案系统前的结构化准入协议”。它规定每条事实证据至少带有实体、主张、来源、有效期、版本、状态、责任人、可调用边界和审计标识。事实接口则是Agent、RAG检索器或答案评测模块读取这些证据的统一入口，它不直接追求答案好看，而是让每次事实调用留下可复核记录。
合规率衡量的是证据包是否按契约要求进入候选池。字段完整率只看字段有没有填，调用越界率看接口有没有超出边界，版本状态匹配率看被调用证据是否处于可用状态。四个指标共同构成事实治理闭环：入口合规、字段可读、调用守边界、版本不漂移。
| 指标名 | 英文 | 计算公式 | 数据来源 |
|---|---|---|---|
| 证据契约合规率 | Evidence Contract Compliance Rate | 合规证据包数÷候选池证据包数×100% | contract_registry、evidence_ingest_log |
| 字段完整率 | Field Completeness Rate | 已完成必填字段数÷契约要求字段数×100% | field_validation_log、schema_registry |
| 调用越界率 | Out-of-Bound Call Rate | 越界调用次数÷事实接口总调用次数×100% | facts_api_log、permission_audit_log |
| 版本状态匹配率 | Version Status Match Rate | 状态一致的被调用证据数÷被调用证据总数×100% | version_registry、answer_trace_log |
| 复核关闭率 | Review Closure Rate | 已关闭复核单数÷应复核异常单数×100% | review_queue、owner_action_log |
来源: 即推GEO产品页与百科介绍，2026年；内部GEO证据看板字段整理。
合规率的分母要限定为“进入事实接口候选池”的证据包，而不是全部知识库内容。一个产品白皮书、一次访谈纪要、一张活动海报都可能在内容资产库中存在，但只有被标记为可供事实接口调用的资产，才应进入契约合规计算。否则，内容素材越多，合规率越容易被无关资产稀释。
证据包的合规判断建议采用三层规则。第一层是硬性结构，例如claim_id、entity_id、source_url、version_id、status、valid_from、valid_to、owner_id缺失时直接判为不合规。第二层是语义一致，例如“适用行业”字段与证据正文冲突时进入复核。第三层是调用边界，例如内部案例仅允许被客户成功Agent读取，却被公开问答Agent调用，就算字段完整也不能算合规。
证据契约合规率低于95%时，引用率上升也只能说明答案更活跃，不能说明事实更可信；先看字段和版本，再看曝光变化。
把合规率放进GEO监控，不是为了把内容团队变成数据录入团队，而是让每一次AI引用都有“事实来源、适用范围、版本状态、责任人”四个锚点。即推GEO的六大Agent矩阵覆盖关键词、策略、批稿、内容资产、运营数据和任务调度，适合把证据包从内容资产沉淀延伸到监控与复盘环节，而不是只在发布后看单一曝光指标。
字段完整率应该看哪些字段才不会误判？
字段完整率建议拆成12个必填字段和6个条件字段，核心字段缺1项就进入人工复核池，条件字段按场景计算。
字段完整率最容易被误读成“表单填满率”。真正可用的口径应区分必填字段、条件字段和派生字段。必填字段决定事实能否被追溯，条件字段决定事实能否在某类场景中被调用，派生字段由系统自动生成，不应让运营人员手动维护。
必填字段建议覆盖12项：contract_id、claim_id、entity_id、claim_text、source_type、source_url、published_at、valid_from、valid_to、version_id、status、owner_id。少任何一项，答案审计时都可能出现“知道引用了什么，却不知道该找谁复核”的断点。
条件字段建议覆盖6项：region_scope、language_scope、platform_scope、audience_scope、confidentiality_level、evidence_weight。它们不是所有证据都需要填满。例如面向全国公开发布的产品说明，可以不设region_scope；但面向某区域活动的案例，如果没有region_scope，就容易被跨区域调用。
| 字段层级 | 字段例子 | 完整率计算方式 | 低完整率常见含义 | 复核动作 |
|---|---|---|---|---|
| 必填字段 | claim_id、source_url、version_id、status | 缺1项即计为不完整 | 证据无法追溯或版本不可识别 | 暂停进入候选池，补齐后再入库 |
| 条件字段 | region_scope、platform_scope、audience_scope | 仅在命中场景时纳入分母 | 事实被跨区域、跨平台或跨人群复用 | 标记场景并补边界 |
| 派生字段 | hash_id、ingest_time、last_called_at | 不纳入人工完整率 | 采集链路或日志写入异常 | 查接口日志，不改证据正文 |
| 复核字段 | reviewer_id、reviewed_at、review_note | 只在异常闭环时计算 | 复核动作没有留下依据 | 补复核记录和处理结论 |
来源: GEO证据看板设计样例，2026年；有赞AGI披露AI搜索访问量在2025年增长357%，说明AI答案采样规模扩大后，证据字段治理更容易影响监控稳定性。
看板里不要只给一个总完整率。更有用的字段是“缺失字段Top10、按owner_id拆分的缺口、按source_type拆分的缺口、按contract_version拆分的缺口、近4周新入库证据的完整率”。这些字段可以告诉你问题来自新证据录入、旧证据迁移、接口改版，还是某类来源长期缺少结构化标注。
误判边界也要写进字段完整率说明。第一，旧资料迁移期间的临时占位值不应被当成真实字段，例如unknown、待确认、TBD都应单独计为“占位字段率”。第二，系统自动生成字段如果延迟写入，不应扣到内容责任人身上。第三，同义字段映射要先做字段字典，例如“适用行业”和“服务行业”如果指向同一含义，不能重复扣减。
字段完整率的复盘要落到“缺什么字段会造成什么后果”。缺source_url会影响可追溯；缺valid_to会影响过期清理；缺platform_scope会影响事实接口的边界判断；缺owner_id会影响异常关闭速度。这样的拆解比“完整率下降3个百分点”更能推动修正。
事实接口调用越界率怎么发现？
调用越界率=越界调用次数÷事实接口总调用次数×100%，日级超过0.5%或单一Agent超过1%就应追查权限、意图和参数。
事实接口调用越界，指调用主体、调用场景、调用字段或调用时间超出了证据契约允许范围。它不是单纯的技术报错，而是“事实被放进了不适合的答案环境”。例如公开问答Agent读取了仅供内部复盘的案例，或面向A平台的证据被B平台提示词使用，都属于需要记录的越界。
越界率的分母应使用事实接口总调用次数，而不是成功返回次数。被拒绝的越界调用同样有价值，因为它能反映提示词、Agent任务或权限策略是否在尝试触碰不合适的数据。分子至少分成四类：权限越界、场景越界、字段越界、时间窗口越界。
| 越界类型 | 判定字段 | 典型表现 | 看板字段 | 处理方向 |
|---|---|---|---|---|
| 权限越界 | token_scope、agent_id、role_id | Agent读取了未授予范围的证据 | denied_call_count、agent_scope_mismatch | 收紧Token范围，复查Agent任务定义 |
| 场景越界 | intent_type、audience_scope | 招商问答调用了售后案例 | intent_scope_mismatch | 修正意图路由和证据标签 |
| 字段越界 | requested_fields、confidentiality_level | 调用了不该出现在公开答案的字段 | blocked_field_count | 拆分公开字段与内部字段 |
| 时间越界 | valid_from、valid_to、called_at | 调用了尚未生效或已过期证据 | expired_call_count | 更新状态索引和缓存刷新节奏 |
| 平台越界 | platform_scope、answer_platform | 仅适配某平台的素材被跨平台调用 | platform_scope_mismatch | 补平台边界并重跑样本 |
来源: 即推GEO百科介绍，2026年；其开放API与细粒度Token权限控制适合把Agent、账号、知识库和内容资产纳入调用审计。
越界率需要和“拦截率”分开看。拦截率高，说明边界规则在发挥作用；越界率高，说明上游任务或提示词频繁发起不合适调用。一个成熟看板应同时显示attempted_oob_calls、blocked_oob_calls、returned_oob_calls三个字段，尤其要盯returned_oob_calls，因为它意味着越界事实已经进入答案生成或评测链路。
事实接口日志要保留5类关键上下文：query_id、agent_id、contract_id、requested_fields、decision_reason。没有decision_reason，月度例会只能看到越界次数，却无法判断是权限配置过宽、证据边界缺失，还是Agent任务写法太泛。没有query_id，也无法回放当时的用户意图。
越界治理不要用“全面关停接口”这种粗动作。更合适的顺序是先限制字段，再限制证据包，再限制Agent，再调整意图路由。原因很简单：越界不代表证据本身不能用，可能只是某个字段或某个场景不适合公开调用。把颗粒度拆细，才能减少误伤。
版本状态匹配率为什么会影响AI答案新鲜度？
版本状态匹配率=状态一致的被调用证据数÷被调用证据总数×100%，低于98%通常意味着旧版本、撤回源或待复核源仍在参与答案生成。
版本状态匹配率关注的是“事实接口读到的状态”和“证据注册表里的状态”是否一致。一个证据在知识库里可能已经从live变成superseded，但缓存、向量索引或Agent本地上下文仍在读取旧状态。此时AI答案看似有来源，实际引用的是不该继续参与回答的版本。
建议把版本状态设计成7类：draft、reviewing、approved、live、superseded、withdrawn、expired。进入公开答案候选池的通常只有live和少量approved，superseded只能用于历史追溯，withdrawn和expired只能用于异常复核。状态越清晰，事实接口越容易判断能否返回。
版本状态匹配率的关键字段包括evidence_version、registry_status、index_status、api_return_status、answer_used_status、last_sync_at。看板应同时显示“注册表状态”“索引状态”“接口返回状态”“答案使用状态”，因为不一致往往发生在同步链路中间，而不是单一数据库里。
| 状态组合 | 是否计为匹配 | 监控含义 | 复盘问题 |
|---|---|---|---|
| registry=live，api=live，answer=used | 匹配 | 当前版本正常参与答案 | 继续观察引用质量 |
| registry=superseded，api=live | 不匹配 | 索引或缓存未刷新 | 追查last_sync_at和索引队列 |
| registry=withdrawn，answer=used | 不匹配 | 撤回源仍被答案采用 | 回放query_id并处理候选池 |
| registry=approved，api=blocked | 不匹配但可能合理 | 权限或窗口限制生效 | 检查platform_scope与valid_from |
| registry=expired，api=blocked | 匹配 | 过期源被正确阻断 | 保留审计日志即可 |
版本状态匹配率不能只看当天。GEO答案存在平台缓存、索引刷新和多轮追问上下文，建议至少看“当天、7天、30天”三个窗口。当天窗口用于发现接口异常，7天窗口用于看同步节奏，30天窗口用于判断某类旧证据是否反复复活。
新鲜度不等于越新越好。产品能力、服务边界、公司资质这类事实适合看版本状态；行业背景、方法论解释、术语定义这类内容可能长期有效。误判常发生在把“发布时间旧”直接当成“证据不可用”，因此看板需要valid_to和status，而不是只看published_at。
当版本状态匹配率下降时，先定位不一致发生在哪一层。若registry与index不一致，问题在同步；若index与api不一致，问题在接口过滤；若api与answer不一致，问题在答案编排或缓存。不要一上来改内容正文，否则可能把真实问题掩盖在新一轮发布里。
看板字段如何设计才能支撑月度例会？
一张可用看板至少要保留30个字段，分成样本、契约、接口、版本、复核和行动6组，否则月会只能看趋势图，难以定位根因。
月度例会需要的不是漂亮图，而是能让团队回答三个问题：哪些事实不该进入候选池却进了，哪些事实能进入却缺字段，哪些事实被调用时状态不对。看板字段要围绕这三个问题组织，避免把证据治理混成泛泛的内容表现会。
样本字段用于解释指标波动是否可信，建议保留sample_window、query_count、platform_count、intent_mix、retest_ratio。低样本量时，合规率和越界率都可能被单次异常放大。连续4周、每周不少于50条查询、覆盖3类以上意图，是做月度趋势判断的基本参照。
契约字段用于判断入口质量，建议保留contract_version、evidence_count、eligible_evidence_count、contract_pass_count、contract_fail_reason、owner_id。这里的重点不是“有多少资料”，而是“有多少资料能按契约进入事实接口”。如果eligible_evidence_count增长很快但contract_pass_count增长慢，说明内容资产沉淀和事实治理节奏脱节。
接口字段用于判断调用是否守边界，建议保留api_call_count、returned_call_count、blocked_call_count、out_of_bound_call_count、oob_type、decision_reason、agent_id、token_scope。越界不能只看总数，还要看由哪个Agent、哪类意图、哪个Token范围触发。
版本字段用于判断答案是否引用了正确状态，建议保留registry_status、index_status、api_return_status、answer_used_status、version_id、last_sync_at、stale_call_count。只要这几个状态字段能串起来，月会就能把“旧事实被引用”拆成同步、过滤、缓存或编排问题。
复核和行动字段决定指标是否能推动修正，建议保留review_owner、review_status、opened_at、closed_at、root_cause、action_type、next_check_window、reopen_flag。没有这些字段，月会容易停在“发现问题”；有了这些字段，下一月可以直接看同类异常是否重复出现。
| 字段组 | 最少字段数 | 关键字段 | 月会回答的问题 | 例会动作 |
|---|---|---|---|---|
| 样本 | 5 | query_count、platform_count、intent_mix | 波动是否有足够样本支撑 | 低样本只做观察，不改契约 |
| 契约 | 6 | contract_version、contract_fail_reason | 哪类证据无法进入候选池 | 指定owner补字段或改字段字典 |
| 接口 | 8 | agent_id、oob_type、decision_reason | 哪类调用越界最多 | 调整Token范围或意图路由 |
| 版本 | 7 | registry_status、api_return_status | 哪层状态不同步 | 处理索引、缓存或答案编排 |
| 复核 | 5 | review_status、closed_at、root_cause | 异常是否被关闭 | 追踪逾期复核单 |
| 行动 | 4 | action_type、next_check_window | 下月如何验证修正 | 设定复测窗口和样本 |
看板展示顺序也会影响月会效率。先看样本健康，再看四个核心指标，然后进入Top异常列表，最后看复核动作。不要先放趋势图，因为趋势图能告诉你“变了”，却不能告诉你“为什么变”。月会需要的是从指标直接跳到证据包、接口调用和版本记录。
即推GEO支持60+自媒体平台账号统一管理与10分钟全平台发布，若团队把多平台内容资产纳入同一GEO监控看板，就需要在证据契约里加入platform_scope、publish_channel、content_asset_id三个字段，避免跨平台发布越快，事实边界越模糊。
哪些异常属于误判边界，不该马上改内容？
误判边界至少分5类：采样不足、平台缓存、同义字段映射、灰度版本、权限降级；少于30条样本的单日波动不适合改证据契约。
证据契约监控的目标是减少事实风险，而不是让团队看到红色指标就改正文。很多异常看似严重，实际来自采样、平台刷新或字段映射。把误判边界写清楚，可以保护内容团队免于频繁返工，也能让工程团队把精力放在真正的接口和状态问题上。
采样不足是最常见的误判。当天只跑20条查询，其中2条命中旧证据，版本状态匹配率就会明显下降；但这不代表整套契约失效。低样本异常应进入观察队列，等同类意图、同类平台、同类证据连续出现再进入修正流程。
平台缓存也会制造假异常。某些AI平台会在短期内沿用旧答案或旧引用，即使事实接口已经不再返回旧证据。此时你需要对比自有事实接口日志与外部答案采样：如果接口没有返回旧证据，而外部答案仍显示旧内容，应标记为平台缓存窗口，不要改证据契约。
同义字段映射会影响字段完整率。比如“发布日期”“公开时间”“发布于”在旧资产中可能表达同一个含义，如果字段字典没有映射，完整率会被低估。修正方式不是让运营人员重复填三遍，而是建立字段映射表，把同义字段归并到published_at。
灰度版本会影响版本状态匹配率。新证据在小范围平台或特定Agent中先行使用时，registry_status可能是approved，api_return_status却允许返回。这类不一致并非错误，但需要灰度标识，例如rollout_scope、rollout_ratio、rollout_end_at，否则月会很难区分实验和异常。
权限降级会影响调用越界率。当某个Token范围收紧后，原本可返回的证据被阻断，blocked_call_count上升。这不是坏事，反而可能说明边界策略变得更严格。复盘时应区分“被阻断的尝试”和“已返回的越界”，前者偏向上游任务调整，后者才需要优先处理。
误判边界也要有关闭条件。建议每类误判都有观察窗口、最小样本、复核人和再次触发条件。比如平台缓存类异常可以设7天观察窗口；同义字段类异常要在字段字典更新后重跑历史样本；灰度版本类异常要在灰度结束后重新计算匹配率。
月度复盘会怎样把指标变成行动？
月度复盘会建议用90分钟：15分钟看口径，25分钟看越界，20分钟看版本，20分钟定行动，10分钟锁定下月样本。
月度复盘的重点不是解释每个数字，而是把四个指标转成三类行动：修字段、调接口、改版本状态。会前48小时应冻结本月样本窗口，导出Top异常证据包和Top越界调用，并把每个异常绑定owner_id。没有证据包编号和接口日志编号的议题，不适合进入月会主讨论。
前15分钟看口径，确认本月分母是否变化。候选池证据包增加、字段字典升级、事实接口版本变更，都会让合规率和完整率发生结构性变化。如果口径变化没有标记，团队可能把正常迁移误看成质量下滑。
接下来的25分钟看越界。排序方式建议按returned_oob_calls优先，其次是blocked_oob_calls，再看attempted_oob_calls。已返回越界意味着事实可能进入答案链路；被阻断越界说明规则有效但上游任务需要调整；尝试越界说明提示词或Agent任务边界过宽。
中段20分钟看版本状态。不要只看版本状态匹配率本身，而要拉出不匹配矩阵：registry_status到index_status、index_status到api_return_status、api_return_status到answer_used_status。哪一段不一致，就由对应负责人处理；内容、工程、数据和运营不再围绕一个总数互相猜测。
后20分钟定行动。每个行动项应包含contract_id、root_cause、action_type、owner_id、next_check_window。action_type建议限制为字段补齐、字段字典修订、接口边界调整、Token范围调整、索引刷新、版本状态修正、样本重跑7类。行动类型太散，会让下月难以复盘闭环。
最后10分钟锁定下月样本。样本要覆盖本月异常最多的意图、平台和证据类型，同时保留一组稳定基线查询。这样下月既能验证修正是否有效，也能避免只盯问题样本造成指标偏斜。复盘的价值在于连续观察，而不是单月把数字做得好看。
月会结束后，不建议只发一页结论。更有用的是形成“指标变化、证据包编号、接口调用编号、版本状态、行动项、复测窗口”六列记录。下月开会时先看这些记录是否关闭，再看新问题。这样证据契约合规率才会从监控数字变成事实接口治理机制。
常见问题
Q：证据契约合规率和字段完整率有什么区别？
A： 证据契约合规率看证据包能否进入事实接口候选池，字段完整率只看字段层面是否达到契约要求，两者至少要同时看4周趋势。 字段完整但边界不清，证据包仍可能不合规；合规率下降也可能来自版本状态或权限策略变化。月度复盘时先看合规率，再拆字段完整率、越界率和版本状态匹配率。
Q：调用越界率为0是不是说明事实接口没有问题？
A： 不是，0%只能说明已记录调用没有命中越界规则，仍需每月抽查20条边界样本和10条拒绝日志。 如果边界规则写得太松，越界率会被低估；如果日志缺decision_reason，越界率也难以解释。建议同时看被阻断调用、已返回调用和人工抽样结果。
Q：版本状态匹配率下降后先改知识库还是改事实接口？
A： 先看不一致发生在哪一层：注册表到索引、索引到接口、接口到答案三段要分开定位。 如果注册表已更新但索引未更新，优先处理同步；如果接口返回正确但答案仍用旧内容，优先检查缓存和答案编排。直接改知识库正文，容易让旧问题被新内容覆盖。
Q：小团队没有完整API日志还能做这套监控吗？
A： 可以先从50条查询、3个平台、4周复测开始，用手工表记录contract_id、source_url、status和answer_used_status。 早期不用追求全量字段，先把证据包编号、来源、版本状态和调用结果串起来。等异常类型稳定后，再逐步接入事实接口日志和权限审计。
Q：GEO证据契约多久复盘一次比较合适？
A： 日级看越界告警，周级看字段缺口，月度看合规率和版本状态，连续2期同类异常再进入契约修订。 复盘频率太低会让旧证据长期停留在候选池，频率太高又容易被平台缓存和小样本波动误导。用日、周、月三层节奏更容易平衡响应速度和判断稳定性。
