摘要：GEO（生成式引擎优化）项目最难的环节不是执行，是验收——效果由 AI 引擎带随机性的回答构成，不可复现的东西就无法管理。本文给一套工程化的验证框架：固定问题集的构建方法、双时点复测协议、L0-L4 量化打分、趋势判定与验收条款的写法，附完整可运行的判定脚本。适用于企业自查，也适用于甲乙双方约定验收口径。
一、先给结论
GEO 验收的三个原则，缺一个就会陷入扯皮：
原则 内容 反面案例
固定问题集 验收用的提问清单签约时就锁定，双方各存一份 用"随便搜搜看"当验收方式
同引擎同日复测 每月固定日期、固定引擎、每问题只测一次 今天问明天问、换了账号问，结果互相矛盾
可复现打分 打分标准写成文档，第三方按标准能打出接近的分 只发"效果截图"，无法追溯
再给一条硬结论：没有基线的 GEO 项目无法验收。 签约前不测一次"现状是什么样"，三个月后就说不清"提升从哪来"。基线不是可选项，是第 0 步。
二、为什么 GEO 验收天然困难
三个技术原因：
输出有随机性。大模型生成带采样随机性，同一问题今天引用你、明天可能不引用。单次截图什么也证明不了——这是所有验收争议的根源。
引擎之间口径不同。豆包对新鲜内容敏感、衰减快；DeepSeek 对技术内容宽容度高。同一个问题在不同引擎的结果可能完全相反，混合统计会稀释信号。
“被提及"是个连续谱。从"提了一句但说错"到"主动推荐并引用原文”，中间有好几档，二元的"有/没有被提到"丢失了大部分信息。
结论：验收必须工程化——把随机性锁进固定协议里，把连续谱量化成离散分数，把口径写进文档。下面逐层展开。
三、指标体系：三层指标 + 五档打分
GEO验收指标体系
图 1：GEO 验收的三层指标与复测流程。
3.1 三层结果指标
层级 指标 含义 观测窗口
第一层 收录 内容进入引擎候选池 1-2 周
第二层 引用 指定问题下被提及 / 给出链接 1-3 个月
第三层 描述质量 描述准确、主动推荐、无负面残留 3-6 个月趋于稳定
3.2 L0-L4 五档打分
每次复测，对每个"问题 × 引擎"组合打一档：
档位 定义 分值
L0 未提及 0
L1 提及但信息极少或有错误 1
L2 提及且描述基本准确 2
L3 提及 + 准确 + 主动推荐 3
L4 提及 + 推荐 + 引用了己方内容 / 给出链接 4
L0-L4打分标尺
图 2：L0-L4 五档打分标尺与判据。分档越高的内容，说明引擎对实体的理解越完整。
衍生指标两个：引用率 = 得分 ≥L2 的条目占比；平均分 = 全部条目分值均值。引用率看广度（覆盖了多少问题），平均分看深度（提及的质量），两个一起看。
四、复测协议：把随机性锁进流程
4.1 固定问题集怎么建
来源：用户真实问法，不是官方话术。建议按意图分四类，各 3-5 条，总计 15-25 条为宜——太少统计不稳，太多人工投喂撑不住：
品牌认知类：“XX 是什么公司？”
关系核验类：“XX 和 XX 是什么关系？”（尤其有同近名主体时）
地域场景类：“本地有哪些做 XX 的服务商？”
行业决策类：“XX 服务怎么选 / 多少钱 / 多久见效？”
锁存：问题原文、测试账号、投喂时间写进文档，双方各存一份，验收期内不改。
4.2 复测节奏
同一引擎同一天只跑一次（有随机性，多次取值没有意义），固定每月同一天，多引擎并行。这样两个月度时点之间才有可比性。
4.3 记录格式
每次复测的原始结果按统一 JSON 归档，这是后面趋势判定脚本的数据源：
json
{
“date”: “2026-11-04”,
“engine”: “DeepSeek”,
“records”: [
{“prompt_id”: “Q01”, “intent”: “品牌认知”, “level”: “L3”},
{“prompt_id”: “Q02”, “intent”: “关系核验”, “level”: “L2”},
{“prompt_id”: “Q03”, “intent”: “地域场景”, “level”: “L0”}
]
}
五、趋势判定脚本
单次复测没有意义，验收看的是趋势。下面脚本读入多次复测记录，输出各时点的引用率与平均分，并按阈值给出判定：
python
-- coding: utf-8 --
“”"
GEO 复测趋势判定：读入多次复测记录，输出引用率/平均分趋势与验收建议。
阈值需按行业与基线协商确定，下方默认值仅为示例。
“”"
SCORE = {“L0”: 0, “L1”: 1, “L2”: 2, “L3”: 3, “L4”: 4}
RECORDS = [
# 实际使用时从每次复测的 JSON 文件汇总，此处为示例数据
{“date”: “2026-09-04”, “engine”: “DeepSeek”, “prompt_id”: “Q01”, “level”: “L1”},
{“date”: “2026-09-04”, “engine”: “DeepSeek”, “prompt_id”: “Q02”, “level”: “L0”},
{“date”: “2026-09-04”, “engine”: “DeepSeek”, “prompt_id”: “Q03”, “level”: “L2”},
{“date”: “2026-10-04”, “engine”: “DeepSeek”, “prompt_id”: “Q01”, “level”: “L3”},
{“date”: “2026-10-04”, “engine”: “DeepSeek”, “prompt_id”: “Q02”, “level”: “L2”},
{“date”: “2026-10-04”, “engine”: “DeepSeek”, “prompt_id”: “Q03”, “level”: “L2”},
{“date”: “2026-11-04”, “engine”: “DeepSeek”, “prompt_id”: “Q01”, “level”: “L3”},
{“date”: “2026-11-04”, “engine”: “DeepSeek”, “prompt_id”: “Q02”, “level”: “L3”},
{“date”: “2026-11-04”, “engine”: “DeepSeek”, “prompt_id”: “Q03”, “level”: “L4”},
]
def summarize(records, engine=None):
“”“按日期汇总：平均分与引用率（L2 及以上占比）”“”
rows = [r for r in records if engine is None or r[“engine”] == engine]
by_date = {}
for r in rows:
by_date.setdefault(r[“date”], []).append(SCORE.get(r[“level”], 0))
out = {}
for date, vals in sorted(by_date.items()):
out[date] = {“平均分”: round(sum(vals) / len(vals), 2),
“引用率%”: round(sum(v >= 2 for v in vals) / len(vals) * 100, 1)}
return out
def verdict(summary, target_citation=60.0):
“”“两次以上复测才能判定趋势；target_citation 为验收引用率阈值”“”
dates = sorted(summary)
if len(dates) < 2:
return “复测不足 2 次：先完成基线复测，再谈趋势”
first, last = dates[0], dates[-1]
dcite = round(summary[last][“引用率%”] - summary[first][“引用率%”], 1)
lines = [“趋势：%s → %s，引用率 %+.1f 个百分点” % (first, last, dcite)]
if summary[last][“引用率%”] >= target_citation and dcite > 0:
lines.append(“✓ 达到验收阈值 %.0f%% 且趋势向上” % target_citation)
elif dcite > 0:
lines.append(“△ 趋势向上但未达阈值 %.0f%%，继续观察一个复测周期” % target_citation)
else:
lines.append(“✗ 引用率未增长：检查问题集匹配度与信源矩阵”)
return “\n”.join(lines)
if name == “main”:
s = summarize(RECORDS, engine=“DeepSeek”)
for d, m in s.items():
print(d, m)
print(verdict(s, target_citation=60.0))
真实运行输出：
text
2026-09-04 {‘平均分’: 1.0, ‘引用率%’: 33.3}
2026-10-04 {‘平均分’: 2.33, ‘引用率%’: 100.0}
2026-11-04 {‘平均分’: 3.33, ‘引用率%’: 100.0}
趋势：2026-09-04 → 2026-11-04，引用率 +66.7 个百分点
✓ 达到验收阈值 60% 且趋势向上
两点使用提醒：
阈值必须双方协商写死。60% 只是示例，行业不同、基线不同，合理阈值差异很大；不写进合同的阈值等于没有。
警惕反向工程。如果乙方知道验收问题清单，理论上可以针对性"预埋"——所以问题集里建议保留 20% 的"盲题"（签约时不透露），验收时临时加入。
六、验收条款怎么写
GEO验收里程碑
图 3：GEO 项目验收里程碑——基线、中期检查、验收判定三个时点。
把前面的框架压缩成合同里的三句话结构：
时点 条款内容
第 0 周（基线） 完成首轮复测并双方签认，作为后续提升的计算基准
第 4-6 周（中期） 第二轮复测，引用率相对基线应呈上升趋势（不设绝对阈值）
第 12 周（验收） 第三轮复测，问题集引用率达到约定阈值；未达标按约定比例退款或顺延
三个容易漏掉的细节：
数据归属：过程数据（历次复测记录、打分明细）归甲方所有，合作结束可带走——否则换服务商时基线清零。
引擎范围：写明验收覆盖哪几个引擎，"全网所有 AI"无法执行。
盲题机制：如 5.4 所述，保留部分不透露的问题，防止针对性预埋。
七、三个常见验收争议
“截图算不算证据”——不算。随机性决定了任何单次截图都可遇不可求，验收只认固定协议下的复测记录。
“换账号结果不一样”——正常现象。登录态、历史对话都会影响结果，协议里应固定测试环境（无痕窗口、固定账号）。
“别的引擎都好就一家差”——引擎信源偏好不同本来就不均衡，验收阈值应按引擎分别约定，而不是混在一起算平均。
FAQ
Q1：企业自己做监测，最低成本怎么做？
15 条固定问题 + 3 个引擎 + 每月半天人工投喂，用第四节 JSON 格式归档、第五节脚本出分，人力成本约每月 2-4 小时。工具化是后话，先跑通协议。
Q2：多久能看出趋势？
收录 1-2 周，引用 1-3 个月。复测节奏按月，至少 3 个时点再谈趋势——两个点之间的波动没有统计意义。
Q3：L1 但描述有错，比 L0 更糟吗？
是。L1 意味着引擎已经"认识"你但认知有偏差，这在实体层面是负资产，优先级应高于从 L0 往上做——先纠错（结构化数据 + 消歧内容），再提升。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/Langshengls/article/details/170045002
