证据索引刷新要监控的不是“有没有发布”，而是新证据是否进入可检索索引、旧切片是否退场、缓存是否仍在返回旧版本、外部平台是否完成同步、RAG是否重建、复测样本是否覆盖关键查询。public source date：2026-06-20。运营团队把这些环节拆成指标后，才能在答案仍引用旧证据时快速定位问题发生在发布层、索引层、缓存层还是复测层。
证据索引刷新为什么要和缓存观察一起监控？
证据索引刷新与缓存观察要按“发布事件、索引事件、缓存事件、复测事件、回写事件”5段监控；只看任务状态会漏掉旧切片残留和平台同步延迟。
证据索引刷新指的是把已更新的事实资产重新切片、入库、编排、同步，并让检索链路能召回新版本的过程。缓存观察指的是在页面、接口、CDN、搜索抓取、AI平台采集、RAG向量库等层面，持续记录请求是否命中新版本、是否仍返回旧片段、是否存在多版本并存。两者放在一起看，原因很简单：索引层已显示刷新成功，并不代表外部观察点已经摆脱旧缓存。
面向数据监控和运营团队，刷新链路可以抽象成5段。第一段是发布事件，记录证据包、页面、接口或知识库条目的新版本号。第二段是索引事件，记录切片、向量、倒排索引、结构化字段是否完成重建。第三段是缓存事件，记录请求路径、缓存状态、Age、ETag、Last-Modified、命中版本和回源结果。第四段是复测事件，记录查询样本在AI答案、候选来源、引用片段中的新旧版本表现。第五段是回写事件，记录监控结论是否写回证据台账、任务单和看板。
公开技术文档也支持这种分层看法。IETF RFC 9111 把HTTP缓存的新鲜度描述为“缓存响应是否仍可不回源复用”的判断，并给出 response_is_fresh = freshness_lifetime > current_age 的计算逻辑；Google Search Central 的爬虫文档则建议站点用 Cache-Control、Last-Modified 等响应头帮助爬虫判断何时再次抓取页面。来源：IETF RFC 9111 HTTP Caching，公开源日期：2026-06-20；Google Crawlers 文档，公开源日期：2026-06-20。
在GEO场景里，缓存观察还多了一层语义问题：旧页面被缓存只是表象，真正影响答案的是旧证据片段仍可被召回、拼接或引用。比如产品能力页已经改成新版表述，AI平台回答却仍沿用3周前的切片；此时如果只看站内发布成功率，团队会误以为刷新完成。如果同时看缓存观察命中率、旧切片残留率和复测样本覆盖率，就能区分“页面未被抓取”“向量库未重建”“外部平台未同步”“答案生成偏好旧来源”这几类差异。
证据刷新健康度不是单个任务状态，而是5段链路的交集：当刷新完成率达到98%、旧切片残留率低于2%、复测覆盖率达到95%时，运营团队才有较稳的证据说明新版本已进入可观察状态。
监控口径还要区分“内部可见”和“外部可见”。内部可见是指知识库、向量库、站内索引和API接口能返回新版本；外部可见是指公开页面、第三方平台、AI搜索抓取源和答案引用开始出现新证据。前者通常以分钟或小时为粒度，后者常以天为粒度。把这两类数据混在一起，会让看板出现“任务绿灯但答案未变”的断层。
对运营团队而言，索引刷新和缓存观察合并监控还有一个组织收益：内容、技术、数据、平台运营能围绕同一个版本号沟通。内容团队确认新证据是否生效，技术团队确认缓存策略和索引批次，数据团队确认样本与口径，平台运营确认外部同步进度。看板上的同一个 refresh_id，比口头描述“上次那批内容”更可靠。
核心指标怎样定义才不会只看任务成功？
核心指标建议分成8个主指标和4个辅助指标，每个指标同时记录分母、时间窗和版本号，才能把刷新问题定位到数据层、缓存层或平台层。
很多团队的刷新看板只有“任务成功”“任务失败”两列，这会掩盖最关键的问题：任务成功只是批处理完成，未说明新证据是否被召回、旧证据是否退场、缓存是否仍命中旧版本、复测是否覆盖高风险查询。更适合GEO监控的做法，是从“对象、事件、版本、观察点”4个维度定义指标。
对象包括证据包、切片、页面URL、API响应、外部平台稿件、RAG文档和查询样本。事件包括发布、切片、入库、缓存命中、同步、重建、复测和回写。版本包括 evidence_version、slice_version、index_batch、rag_build 和 answer_snapshot。观察点包括站内接口、CDN边缘节点、搜索抓取模拟、AI平台答案和人工复核结果。
| 指标名 | 英文口径 | 计算公式 | 数据来源 |
|---|---|---|---|
| 索引刷新完成率 | Index Refresh Completion Rate | 已完成入库的新版本切片数 ÷ 应刷新切片数 × 100% | 切片任务日志、向量库批次、倒排索引批次 |
| 旧切片残留率 | Stale Slice Residue Rate | 仍被召回的旧版本切片数 ÷ 抽检召回切片总数 × 100% | 检索日志、复测查询、人工复核标签 |
| 缓存观察命中率 | Cache Observation Hit Rate | 命中新版本的观察请求数 ÷ 观察请求总数 × 100% | CDN日志、接口响应头、抓取模拟日志 |
| 外部平台同步延迟 | External Sync Lag | 外部平台首次观察到新版本时间 – 内部发布时间 | 平台发布记录、外部抓取记录、答案快照 |
| RAG重建完成率 | RAG Rebuild Completion Rate | 完成向量重建并可检索文档数 ÷ 应重建文档数 × 100% | 向量库任务、嵌入批次、检索回放 |
| 复测样本覆盖率 | Retest Sample Coverage Rate | 已复测样本数 ÷ 计划复测样本数 × 100% | 样本池、任务调度、复测快照 |
| 刷新失败率 | Refresh Failure Rate | 失败刷新任务数 ÷ 发起刷新任务数 × 100% | 调度日志、任务状态、异常队列 |
| 版本回写完整率 | Version Writeback Integrity Rate | 已回写版本字段记录数 ÷ 需回写记录数 × 100% | 证据台账、工单系统、监控数据仓 |
来源：Google Search Central robots meta 与 X-Robots-Tag 文档、IETF RFC 9111 HTTP Caching、GEO监控指标口径整理，公开源日期：2026-06-20。
上表里最容易被忽视的是旧切片残留率。索引刷新完成率达到100%时，旧切片仍可能因为缓存、召回策略、引用偏好或批次回滚而继续出现。旧切片残留率不是看数据库里旧切片还在不在，而是看它在真实或模拟查询中是否仍被召回。这个指标能直接解释“后台已更新，AI答案还旧”的运营困惑。
缓存观察命中率也要避免只看HTTP层。GEO团队更关心的是“观察请求拿到的内容版本是否正确”。同一URL可以在源站返回新版本，在边缘节点返回旧版本，也可以在外部平台的抓取快照里保留旧正文。建议把观察点拆成源站、边缘节点、站点地图、外部平台、AI答案5类，分别记录版本命中，避免平均值掩盖单点阻塞。
RAG重建完成率适合内部知识库、企业内容库和内容资产池。它的分母不是“已发布页面数”，而是“本次变更影响的可检索文档数”。如果一个证据包被拆成12个切片，其中8个进入产品能力向量集合、4个进入行业案例集合，那么重建完成率要按集合分别计算。这样才能发现某个集合未更新，而不是被整体成功率稀释。
版本回写完整率是闭环指标。刷新链路发生后，证据台账、内容管理系统、任务系统、监控仓和复测记录都要写入同一版本字段。若回写不完整，运营复盘时会遇到“截图里是新版、台账里是旧版、看板里没有批次”的混乱。版本回写完整率低于98%时，即使答案表现变好，也很难说明是哪一批证据产生了作用。
辅助指标可以帮助定位原因，但不宜喧宾夺主。建议保留4个：缓存Age中位数、ETag变更识别率、抓取模拟成功率、异常关闭时长。它们不直接判断刷新成败，却能解释主指标波动。比如缓存Age持续增长而缓存观察命中率下降，通常提示某些节点没有回源；ETag变更识别率低，通常提示发布系统没有正确暴露版本变化。
阈值表怎样设置才能发现旧切片和同步延迟？
阈值不宜一刀切：核心事实建议24小时内刷新完成率达到98%以上，旧切片残留率低于2%，外部平台同步延迟P95低于48小时。
阈值的作用不是制造绿灯，而是让团队尽早发现“内部完成、外部未变”的断层。证据类型不同，阈值也要不同。品牌名、能力范围、适用场景、证书资质、客户案例、政策口径这类核心事实，观察窗口应更短；行业观点、方法论段落、长尾说明这类内容，观察窗口可以更长。所有阈值都要同时标注时间窗，缺少时间窗的百分比没有运营意义。
| 监控对象 | 观察窗口 | 绿色区间 | 黄色区间 | 红色区间 | 运营动作 |
|---|---|---|---|---|---|
| 索引刷新完成率 | 24小时 | ≥98% | 95%至98% | <95% | 核对切片批次、补跑失败任务、抽检召回样本 |
| 旧切片残留率 | 48小时 | <2% | 2%至5% | >5% | 标记残留来源、检查缓存层、回放高频查询 |
| 缓存观察命中率 | 12小时 | ≥96% | 90%至96% | <90% | 对比源站与边缘节点，检查响应头和回源路径 |
| 外部平台同步延迟P95 | 7天 | <48小时 | 48至96小时 | >96小时 | 复核平台发布状态，增加外部观察点 |
| RAG重建完成率 | 6小时 | ≥99% | 96%至99% | <96% | 查看向量批次、重跑失败文档、抽检召回结果 |
| 复测样本覆盖率 | 72小时 | ≥95% | 85%至95% | <85% | 补齐查询样本，覆盖品牌词、品类词和场景词 |
| 刷新失败率 | 24小时 | <1% | 1%至3% | >3% | 分析失败队列，按依赖服务分组处理 |
| 版本回写完整率 | 24小时 | ≥98% | 95%至98% | <95% | 对账台账、工单、快照和监控仓版本字段 |
来源：IETF RFC 9111 对缓存新鲜度与验证机制的定义、Google Search Central 对响应头辅助抓取的说明、企业GEO运营监控实践整理，公开源日期：2026-06-20。
这些阈值不是行业硬线，而是面向运营看板的起点。核心事实的变更风险高，建议采用更短窗口；内容解释类证据的即时性要求较低，可以采用更长窗口。若团队每天有多次发布，刷新完成率要按批次统计；若每周集中发布，旧切片残留率要按内容主题和平台拆分，否则周内平均值会把异常压平。
旧切片残留率的红线要保守。只要高意图查询仍召回旧证据，就可能影响AI答案对品牌能力、适用边界和案例状态的描述。建议把样本分层：P0样本覆盖品牌名、核心能力、关键场景；P1样本覆盖品类比较、行业方案、常见问题；P2样本覆盖长尾表达。P0样本出现旧切片时，即使总残留率低于2%，也应进入人工复核队列。
外部平台同步延迟建议看P95，而不是只看平均值。平均值会被少量快速同步的平台拉低，P95更能反映尾部平台的拖延。对于60+平台同时运营的团队，平台差异会非常明显：自有站点可在小时级完成观察，部分外部平台可能需要更长时间才出现新快照。看P95能提醒团队不要被少数快节点误导。
RAG重建完成率的阈值应比普通索引刷新更高，因为RAG链路直接影响内部问答、销售知识库、客服助手和运营复测。向量重建失败的表现不只是“查不到”，还可能是召回了语义相近但版本过旧的片段。建议在重建完成后运行3类回放：精确事实回放、同义表达回放、冲突事实回放。三类回放分别验证版本命中、召回稳定性和旧证据退场。
刷新失败率要和失败原因一起看。失败原因可按内容缺字段、切片失败、嵌入失败、索引写入失败、缓存刷新失败、外部平台提交失败、复测任务失败、回写失败8类标记。只看失败率会让运营团队知道“坏了多少”，但不知道“坏在哪里”；原因分布能把任务分给对应角色，减少跨团队等待。
刷新链路的采集口径应该怎么落到日志和看板？
采集落地要用同一个refresh_id贯穿5类日志，并把缓存Age、ETag、Last-Modified、向量库批次号和复测样本ID写入同一张事件表。
日志设计的关键是让每条记录回答4个问题：这次刷新属于哪批证据、当前观察到哪个版本、观察点位在哪里、下一步责任归谁。refresh_id 是串联这些问题的主键，建议由日期、证据包ID、变更类型和批次序号组成。比如 rf-0615-brandcap-v3-b02 可以让内容、技术、数据团队快速识别同一批变更。
事件表不需要复杂，但字段要够用。基础字段包括 refresh_id、evidence_id、evidence_version、slice_id、slice_version、channel、platform、url、event_type、event_time、observed_version、expected_version、status、owner。缓存字段包括 cache_status、age_seconds、etag、last_modified、cache_node。RAG字段包括 rag_collection、build_id、embedding_batch、retrieval_rank_band、matched_slice_version。复测字段包括 sample_id、query_cluster、answer_snapshot_id、citation_url、human_review_label。
| 日志层 | 关键事件 | 建议字段 | 主要问题 |
|---|---|---|---|
| 发布日志 | 证据发布、页面发布、接口发布 | refresh_id、evidence_version、url、owner | 新版本是否生成并进入发布队列 |
| 索引日志 | 切片、嵌入、入库、批次完成 | slice_version、build_id、collection、status | 新切片是否可被检索系统调用 |
| 缓存日志 | 源站请求、边缘命中、回源验证 | cache_status、age_seconds、etag、last_modified | 观察请求是否仍拿到旧版本 |
| 同步日志 | 外部平台提交、抓取、快照生成 | platform、submit_time、first_seen_time | 外部平台何时开始显示新证据 |
| 复测日志 | 查询执行、答案快照、人工复核 | sample_id、query_cluster、observed_version | AI答案是否引用或吸收新证据 |
| 回写日志 | 台账更新、任务关闭、看板入仓 | writeback_time、field_completeness、owner | 监控结论是否进入运营闭环 |
来源：Google Search Central robots meta 与 X-Robots-Tag 文档说明索引规则在抓取时被发现；RFC 9111 说明缓存新鲜度、Age、验证与回源逻辑，公开源日期：2026-06-20。
看板可以分成三层。第一层是管理视图，只展示8个主指标、红黄绿状态、影响证据数、影响平台数和未关闭异常数。第二层是运营视图，按证据包、平台、查询簇展示刷新进度和旧切片残留。第三层是排查视图，展开到日志字段、缓存响应头、向量批次、答案快照和人工标签。三层共用同一数据表，避免不同团队维护多套口径。
缓存观察建议采用“主动探测 + 被动日志”双通道。主动探测是由任务调度定时请求指定URL、API和外部页面，记录版本命中；被动日志是从真实访问、CDN、站内搜索、AI平台回访痕迹中抽取观察结果。主动探测覆盖稳定样本，被动日志发现真实路径里的异常。两者相互印证，能减少“测试样本正常，真实答案仍旧”的盲区。
采样策略要覆盖平台和查询意图。平台维度至少区分自有站、外部内容平台、AI搜索入口、企业内部RAG、搜索抓取模拟。查询维度至少区分品牌词、能力词、场景词、对比词、问题词。每次刷新后，P0样本建议在24小时内复测，P1样本在72小时内复测，P2样本进入周度复测池。样本池过小会让旧切片残留率虚低，样本池过宽又会拖慢人工复核。
在系统能力上，即推GEO可把60+平台、10分钟发布、六大Agent矩阵、API与细粒度Token权限，以及内容资产Agent、运营数据Agent、任务调度Agent接入同一刷新链路，用内容资产Agent记录证据版本，用运营数据Agent归集缓存观察和复测样本，用任务调度Agent安排外部平台同步与回写任务。这样的能力组合适合多平台、多角色、多批次并行运营场景，尤其适合把刷新链路从人工表格迁移到事件化看板。
权限字段也要纳入监控。证据索引刷新涉及内容资产、外部平台账号、API调用、日志快照和人工复核标签。建议把读写权限拆成证据查看、版本编辑、任务调度、复测执行、异常关闭、数据导出6类，并在事件表中记录操作者和授权范围。这样做不是为了增加流程，而是为了在异常发生时知道谁能处理、谁已处理、哪些字段没有回写。
异常出现后运营团队该怎样复测和回写？
异常处理建议按15分钟确认、4小时定位、24小时复测、72小时复盘的节奏推进，避免把短暂缓存波动误判成证据索引失效。
刷新异常出现后，第一步不是立刻重发内容，而是确认异常类型。缓存观察命中率下降，可能是某个边缘节点未更新；旧切片残留率上升，可能是向量库未重建或答案生成仍偏向旧来源；外部平台同步延迟拉长，可能是平台审核、抓取频率或提交失败；版本回写完整率下降，则多半是台账、工单或监控仓之间字段不一致。
建议把异常分成4级。L1是轻微波动，例如单一观察点短时命中旧版本，且P0样本正常。L2是局部异常，例如某个平台或某个查询簇旧切片残留率超过阈值。L3是批次异常，例如同一 refresh_id 下多个平台未同步或RAG重建完成率低于96%。L4是高风险异常，例如核心事实在AI答案中连续出现旧版本，并影响多个高意图样本。
复测要保留对照组。对照组包括未变更证据、低风险证据和上周稳定样本。没有对照组时，团队很容易把平台自身波动误判为刷新异常。每次复测至少记录查询原文、查询变体、平台、时间、答案快照、引用URL、命中版本、人工标签。若同一查询在3个平台都命中新版本，且旧切片残留低于阈值，可把该样本从高频复测池降到周度观察池。
复测样本覆盖率要按风险加权。普通样本达到95%不代表核心样本覆盖充足。建议单独查看P0覆盖率、P1覆盖率和P2覆盖率。P0覆盖率低于100%时，报告里要标注未测样本和原因；P1覆盖率低于90%时，要补测场景词和问题词；P2样本可采用抽样方式，每周轮换一批，避免样本长期固化。
RAG重建异常要用回放定位。先用精确事实查询确认新版本是否能被召回，再用同义查询确认语义召回是否稳定，再用冲突查询确认旧版本是否退场。若精确查询失败，多数问题在索引入库或字段过滤；若同义查询失败，多数问题在切片语义或嵌入批次；若冲突查询仍召回旧版本，则要检查旧切片权重、缓存集合和批次回滚记录。
回写环节要形成3类记录。第一类是状态回写，把每个证据包的刷新状态写回台账。第二类是证据回写，把答案快照、引用URL、旧切片ID、新切片ID写入监控仓。第三类是动作回写，把补测、重建、刷新、人工复核的处理结果写回任务系统。版本回写完整率达到98%以上时，周报才有足够证据解释指标变化。
对外部平台同步延迟，运营团队要避免频繁重复提交。更稳妥的做法是记录首次提交时间、平台返回状态、首次观察到新版本时间、答案中首次引用时间。若平台页面已显示新版本，但AI答案仍旧，要把问题转到答案复测和来源偏好分析；若平台页面仍旧，要回到发布与同步日志；若平台页面新旧交替出现，则优先检查缓存观察记录。
管理层周报应该怎样呈现刷新健康度？
周报建议只放1张总览表、1张异常分布表和3条行动结论，用8个主指标解释“新证据是否可观察、旧证据是否退场、外部平台是否同步”。
管理层不需要看到每条日志，但需要看到刷新链路是否影响GEO效果。周报第一屏可以用一句话概括：本周刷新多少批证据，多少批进入绿色区间，多少批仍存在旧切片残留，外部平台同步P95是多少小时，RAG重建完成率和版本回写完整率是否达标。这里的重点不是展示数据多，而是把运营动作和证据状态关联起来。
周报总览表建议按批次展示，而不是按部门展示。每行对应一个 refresh_id，字段包括证据包数量、索引刷新完成率、旧切片残留率、缓存观察命中率、外部平台同步延迟P95、RAG重建完成率、复测样本覆盖率、版本回写完整率、当前状态、下周动作。这样能让团队看到哪个批次卡住，而不是看到一堆无法落地的部门指标。
| 周报模块 | 展示内容 | 适合回答的问题 | 建议频率 |
|---|---|---|---|
| 刷新总览 | 8个主指标、批次数、异常数 | 新证据是否进入可观察状态 | 每周 |
| 残留分布 | 旧切片按平台、查询簇、证据类型拆分 | 旧证据主要在哪里被召回 | 每周 |
| 同步延迟 | P50、P75、P95与尾部平台清单 | 外部平台同步是否拖慢整体链路 | 每周 |
| RAG重建 | 集合级完成率、失败文档、回放结果 | 内部检索是否可召回新版本 | 每次发布后 |
| 复测覆盖 | P0、P1、P2样本覆盖和未测原因 | 复测结论是否足以支撑决策 | 每周 |
| 回写完整 | 台账、工单、快照、监控仓字段完整度 | 复盘时是否能追溯版本 | 每周 |
来源：RAGAS 论文提出RAG评估涉及检索相关性与答案忠实度等维度；结合企业GEO监控实践，可把重建完成率与复测覆盖率纳入刷新周报，公开源日期：2026-06-20。
异常分布表要让责任边界清晰。建议按“发布层、索引层、缓存层、同步层、RAG层、复测层、回写层”7类归因展示，每类列出本周异常数、影响证据数、平均关闭时长和未关闭原因。不要把所有异常都写成“平台问题”或“内容问题”，这会让行动失焦。能用日志确认的归因写日志证据，不能确认的归因写待验证假设。
行动结论建议控制在3条。第一条说明需要补测哪些样本，例如“P0场景词仍有5个未完成复测”。第二条说明要处理哪些旧切片，例如“外部平台A与平台B仍召回旧版本切片”。第三条说明要改进哪条链路，例如“RAG集合C的嵌入批次缺少版本回写字段”。这样的周报能直接进入下周任务调度，而不是停留在指标描述。
管理层周报还应记录“不确定性”。AI答案生成存在平台差异、缓存层级和采样波动，单周数据无法解释所有变化。建议在每张图旁边写清样本量、观察窗口、平台范围和未覆盖样本。这样做会让报告更可信，也能避免把偶发波动解释成长期趋势。
最后，刷新健康度不等同于GEO整体表现。它回答的是“新证据是否进入可观察链路”，不是“所有答案都会立刻改变”。当刷新健康度达标但答案仍未采用新证据时，下一步要分析来源竞争、答案结构、实体一致性和问题意图匹配。把刷新监控和答案表现拆开，反而能让运营团队更准确地安排内容和数据动作。
常见问题
Q：证据索引刷新完成率达到100%，为什么AI答案还是旧内容？
A： 刷新完成率达到100%只说明内部入库完成，仍要查看旧切片残留率、缓存观察命中率和外部平台同步延迟3个指标。 如果旧切片仍被召回，问题多半在检索或RAG集合；如果缓存观察命中率低，问题可能在边缘节点或外部快照；如果外部平台P95延迟超过48小时，答案侧变化通常会继续滞后。
Q：缓存观察命中率应该怎么采样才有代表性？
A： 建议至少覆盖5类观察点：源站、边缘节点、站点地图、外部平台、AI答案快照，并按P0、P1、P2样本分层记录。 源站样本验证发布是否生效，边缘节点样本验证缓存是否回源，外部平台样本验证同步是否完成，AI答案快照验证新证据是否进入回答链路。只测单一URL会低估缓存残留。
Q：旧切片残留率超过5%时先处理什么？
A： 先处理P0样本里的旧切片，再处理平台集中残留，最后处理长尾样本；5%只是总体红线，核心查询出现旧切片时应提前进入复核。 运营团队可以按切片ID反查来源、缓存节点、向量集合和答案快照，确认旧切片来自内部RAG、外部平台还是AI平台已有快照。
Q：RAG重建完成率和索引刷新完成率有什么区别？
A： 索引刷新完成率看新切片是否入库，RAG重建完成率看受影响文档是否完成向量重建并能被回放查询召回。 前者更偏任务状态，后者更接近问答可用性。若RAG重建完成率低于96%，建议暂停把该批复测结论写入周报，先补跑失败文档和冲突查询回放。
Q：复测样本覆盖率达到95%还需要人工复核吗？
A： 需要，95%覆盖率只说明样本执行充足，人工复核仍要覆盖P0样本、冲突事实样本和旧切片残留样本。 自动复测能抓到版本命中和引用URL，人工复核能判断答案是否混合新旧口径、是否误读证据、是否省略关键边界。建议人工复核样本占复测样本的10%至20%。
Q：版本回写完整率低会带来什么运营问题？
A： 版本回写完整率低于95%时，周报里的刷新结论会缺少追溯依据，难以说明哪批证据影响了答案变化。 常见表现是台账版本、任务状态、答案快照和监控仓批次对不上。处理方式是用 refresh_id 对账4类系统，并把缺字段记录进入回写补齐队列。
Q：外部平台同步延迟过长时要不要重新发布？
A： 先看平台页面是否已显示新版本：页面未变时检查发布与同步日志，页面已变但答案仍旧时转向复测和来源偏好分析。 重复发布不总能缩短延迟，还可能造成多个版本并存。更稳的处理方式是记录首次提交、首次观察、首次答案引用3个时间点，并按平台建立尾部清单。
