# VGO 效果验证：从引用率到可核查证据
**摘要：** 对 SEO、AEO 与 GEO 的优化进行评估，需要区分抽样表现、平台报告、业务关联和因果增量。本文以 VGO——面向机器世界的有效可见度持续增长优化与治理体系——为方法背景，给出范围快照、指标分母、证据谱系和业务归因的设计原则，并用一个可运行的合成示例说明：提及率上升可能来自样本缺失，而非实际表现改善。文章进一步讨论可比趋势、数据管道与实验设计，帮助构建能够解释结论的优化成效报告。
**关键词：** VGO、GEO、数据分析、效果评估、可观测性、数据治理
## 一、为什么“引用率涨了”还不是完整结论
假设某份报告写道：“优化后，品牌提及率从 60% 提升到 75%。”
这个结论至少缺少五项信息：测了哪些问题、哪些请求成功、前后是否使用相同入口、回答如何判定，以及这次变化与执行动作是什么关系。
如果后一次采集恰好失败了部分原本不提及品牌的问题，那么分母变小，也可能得到更高比例。数据没有造假，报表仍然可能误导。
这正是 VGO 效果验证要处理的事情。VGO（Visibility Growth Optimization）的正式定位是：**面向机器世界的有效可见度持续增长优化与治理体系。** 在这一体系中，“有效”要求目标明确、事实正确、证据可核查和结果可评估；“持续增长”是长期目标，不能被解释为每条曲线必须向上。
本文聚焦测量设计。下面的数字全部来自合成示例，不是任何客户、云平台或产品的真实优化结果。
## 二、先把四种结论分开
| 层次 | 可以表达什么 | 不应直接推出什么 |
|---|---|---|
| 抽样观察 | 固定条件下，多少回答提及、推荐或引用目标 | 第三方平台真实用户的全量曝光 |
| 平台报告 | 平台在其报告口径内提供的展现、点击等结果 | 所有平台的统一受众覆盖 |
| 业务关联 | 按声明规则识别到的访问、咨询和成交 | 全部业务结果均由这次优化带来 |
| 因果增量 | 在合理比较设计下估计干预造成的变化 | 跨市场、跨平台普遍有效 |
GEO 研究为生成式回答中的可见度评估提供了研究基础。[1] 但研究中的一次实验、模型 API 的一次调用，以及消费者产品里的真实使用，不是同一个观测对象。即使模型名称相同，检索、会话与个性化条件也可能不同。
一个可靠的数据产品应该允许这几类数据并排观察，同时始终保留各自的来源和解释范围。
## 三、为每条趋势冻结一个范围
比较前后变化之前，先定义范围快照。至少包括组织、品牌或产品、市场、语言、问题集版本、入口、时间窗口和判定规则。
```json
{
"scope_version": "demo-v1",
"entity": "demo-product",
"market": "declared-market",
"language": "zh-CN",
"question_set_version": "questions-v1",
"surface": "declared-surface",
"session_policy": "fresh-session",
"evaluation_rule_version": "rules-v1"
}
```
这是示意数据，不是平台接口规范。实际采集还应记录请求时间、采集器版本，以及平台公开的模型标识。平台没有披露的信息写为未知。
如果后窗口增加了大量容易提及品牌的问题，应把它视为范围扩展，而不是直接与旧窗口拼成一条增长曲线。可以同时提供“全部新样本”和“前后可比子集”两个视图，但必须解释它们回答的是不同问题。
## 四、一个分母变化造成的假象
设前一次有 10 个有效回答，其中 6 个提及品牌。后一次仍有 6 个提及，但两个未提及问题的采集失败了。
按照有效回答计算，提及率从 6/10 变成 6/8，即 60% 到 75%。这时更高的比例并不意味着被提及的问题增加。
下面的 Python 示例只使用标准库，可直接运行：
```python
# 合成数据：每个问题在每个窗口只安排一次观察。
# None 表示采集失败；False 表示有效回答没有提及。
before = {f"q{i}": i <= 6 for i in range(1, 11)}
after = dict(before)
after["q9"] = None
after["q10"] = None
def summary(batch):
scheduled = len(batch)
valid = {q: value for q, value in batch.items()
if value is not None}
mentions = sum(valid.values())
return {
"scheduled": scheduled,
"valid": len(valid),
"failed": scheduled - len(valid),
"mentions": mentions,
"coverage": len(valid) / scheduled if scheduled else None,
"mention_rate": mentions / len(valid) if valid else None,
}
common = [q for q in before
if before[q] is not None and after.get(q) is not None]
paired_before = {q: before[q] for q in common}
paired_after = {q: after[q] for q in common}
print("before:", summary(before))
print("after:", summary(after))
print("paired before:", summary(paired_before))
print("paired after:", summary(paired_after))
```
主要输出可以整理为：
| 比较范围 | 前窗口提及率 | 后窗口提及率 | 应如何解释 |
|---|---:|---:|---|
| 各自有效回答 | 60%（6/10） | 75%（6/8） | 比例上涨，但采集覆盖从 100% 降到 80% |
| 共同有效问题 | 75%（6/8） | 75%（6/8） | 在这 8 个可比问题上没有变化 |
共同子集分析也有局限：它不能恢复两个失败问题的真实后测结果。缺失若与问题类型相关，共同子集仍可能偏离完整任务。正确做法是展示覆盖下降、补采或说明不确定性，而不是把子集结果当成真实市场全貌。
## 五、指标字典比综合评分更早建立
一个指标不应只有名称和数值，还需要分子、分母、判定规则、版本和不可计算条件。
**提及率**：有效回答中出现目标实体的比例。别名匹配需避免同名品牌和缩写误识别。
**推荐率**：有效回答中存在符合预先规则的明确推荐的比例。“列举某品牌”不自动等于推荐。
**链接引用率**：有效回答中存在符合定义的来源链接的比例。品牌被引用与客户自有域名被引用，应分别记录。
**事实准确性**：对可核验陈述进行判断，同时报告正确、错误和无法判定的数量。不能把无法判断的内容全部当作正确。
**采集覆盖率**：有效观察数与计划观察数的关系。重试请求不应被当作新的计划样本反复计数；同一计划观察只能选定一个正式结果，额外重复采样则需事先登记。
多组数据聚合时，应先合计分子分母。例如，一个样本的组达到 100%，另一个九个样本的组达到 0%，总体是 10%，不是 50%。若采用权重，权重来源和适用人群需要独立解释；没有真实需求分布时，不把等权问题集说成真实用户份额。
## 六、让数据管道保留每次计算的来路
建议把数据分为四层：
```text
原始层：请求计划、采集状态、回答、来源链接
判定层：实体识别、提及/推荐/引用、事实核验
聚合层：范围、时间桶、分子、分母、规则版本
报告层：趋势、执行标记、业务观察与限制说明
```
原始响应可放入受权限保护的对象存储，元数据和关系保存到数据库。内容哈希帮助识别变化，但哈希本身不证明采集来源真实，也不能代替访问控制。
一个聚合记录至少应能找到它使用的原始批次和判定规则。判定算法更新时，生成新版本指标；若对历史重算，应明确标注，而不是无声改写昨天的曲线。
迟到事件也需要处理。平台报告可能延迟，订单可能退款，咨询记录可能合并。可以使用可重算时间桶，并为修订保留原因。数据未完整到达的日期要显示为暂定，不能与完整日期作同等比较。
展示层缓存不能成为唯一事实来源。缓存更新失败时，用户应能看到最后更新时间；连接过期不能表现成品牌指标突然归零。
## 七、行动时间线不等于因果归因
把内容发布标在趋势图上很有价值：用户可以看到发生了什么、何时执行，以及之后观察到了什么。但图上的先后关系不能单独证明因果。
同期可能发生搜索平台更新、模型切换、品牌广告投放或季节性需求变化。同一站点多处修改也可能相互影响。
因此，一条行动记录应同时关联：优化前范围、具体差异、执行回执、复测窗口和观察结论。报告可以写“发布后复测观察到变化”，但只有具备合适研究设计与条件时，才进一步解释为干预的增量效果。
如果采用处理组与对照组，可以计算变化差：
```text
变化差 =（处理组后 − 处理组前）−（对照组后 − 对照组前）
```
这个计算式不是因果结论的自动生成器。平行趋势、组间干扰和分组可比性都需要评估。模型升级或全站信号变化可能同时影响两组；这些因素必须进入研究记录。
## 八、业务结果接入需要单独的数据契约
访问、咨询和成交可以帮助判断商业价值，但需要先确定归因与去重规则。
访问来源可能丢失，所以直接访问不能全部归为 AI。用户自报“从某个 AI 产品了解到品牌”可以作为补充，但应标为自报来源。咨询到订单的关联需要适当授权和稳定标识，不应为了追踪效果而收集不必要的个人信息。
订单统计应声明状态、币种、金额口径与退款处理。费用也要区分预计和已结算。仅当数据完整且口径明确时，才展示对应比率；“已追踪收入/已记录成本”仍不等于增量投资回报。
对于样本少、链路长的业务，暂时无法判断商业效果也是合理结论。用可见度评分填补缺失收入，只会使报告更难核查。
## 九、一份值得交付的成效报告
成效首页可以按下面顺序组织：
1. **范围和健康状态：** 本次观察哪些入口，覆盖怎样，有哪些数据缺失。
2. **当前表现：** 原始指标及分子分母，而非只有一个综合分。
3. **实际执行：** 修改了什么，是否完成，费用与失败如何。
4. **可比变化：** 改善、下降、未见变化与证据不足分别呈现。
5. **业务观察：** 能识别的访问、咨询和成交，以及未归因部分。
6. **下一步：** 继续、调整、暂停或补充数据，并说明理由。
每个结论都应该能追到定义与证据。负责人先看判断，执行者再展开数据和任务，二者使用同一份事实。
## 十、结论
VGO 的效果验证首先是一项数据治理工作。它要求系统区分真实零值与缺失，区分样本变化与表现变化，区分行动完成与效果改善，也区分业务关联与因果增量。
本文的合成示例说明了一个具体问题：即使提及次数没有增加，分母变化也能制造增长曲线。工程上的应对是同时保留范围、覆盖、分子分母、规则版本及原始证据，让报告中的每个数字都有可解释的来路。
当数据尚不足以支持增长结论时，报告应指出下一项验证工作。持续积累可信证据，才能让“持续增长”成为可以检验的目标。
## 参考资料
[1] Aggarwal 等，*GEO: Generative Engine Optimization*，KDD 2024。[论文与版本信息](https://arxiv.org/abs/2311.09735v3)。本文不将其研究结果当作 VGO 的实验效果。
[2] VGO，[指标与测量边界](https://github.com/vgoframework/vgo-framework/blob/main/METRICS.md)。
[3] VGO，[体系定义与研究初稿](https://github.com/vgoframework/vgo-framework/blob/main/papers/VGO-MACHINE-WORLD-SYSTEM.zh-CN.md)。以上项目文档属于方法设计来源，不构成独立实证验证。
