过去几个月，我累计保存和处理的 GEO 相关采样已经超过 2 万条。

这些数据最初并不是为了研究“应该怎么提问”。

我真正想解决的问题一直是：

当用户表达的是同一个需求时，为什么有时候 AI 会想到一个品牌，有时候却完全不会？

随着采样量增加，我越来越确定一个现象：

语义接近，不代表检索路径相同。

有时只是调整语序、替换一个限定词，甚至改变一句话的表达结构，AI 在检索阶段产生的 Query Rewrite 就可能不同。

而一旦 Query Rewrite 改变，后面的来源、实体、候选对象和最终答案，都可能跟着改变。

我现在更愿意把这条链写成：

用户原始问题
      ↓
Query Understanding
      ↓
Query Rewrite / Expansion / Fan-out
      ↓
Retrieval
      ↓
Candidate Sources / Entities
      ↓
Reranking
      ↓
Generation
      ↓
Mention / Citation / Recommendation

这意味着，我们过去把“一道问题”作为 GEO 的最小测量单位，可能还不够。

真正需要观察的，是：

一个用户意图经过不同自然语言表达以后，会不会进入不同的检索路径。

先说明：下面的例子经过脱敏重构

为了不公开真实项目、真实品牌和内部采样题集，下面涉及律所行业的例子是根据真实实验结构进行的等价脱敏重构。

它用于解释实验机制，不是原始采样记录的逐字公开。

真实原始 Question、Observation、Query Rewrite 和 Sampling Run 仍保留在内部研究数据中。

假设用户只是想找一家成都律所

从人的角度看：

A：成都推荐一家律所

B：成都律所推荐

这两个问题表达的需求非常接近。

用户都是在寻找：

成都有哪些值得考虑的律所？

如果只从“语义理解”出发，我们很容易认为：

A ≈ B

所以最终结果应该差不多。

但在真实的 AI 搜索系统里，中间还有一层经常被忽略：

Retrieval Planning。

AI 并不一定直接拿用户原句去搜索。

它可能重新组织问题、拆分意图、补充实体，然后产生多个检索 Query。

例如，下面只是为了说明机制而构造的脱敏示意：

成都推荐一家律所
        ↓
可能展开为
├─ 成都靠谱律师事务所
├─ 成都法律服务推荐
├─ 成都律师事务所口碑
└─ 成都专业律所

而：

成都律所推荐
        ↓
可能展开为
├─ 成都律所推荐
├─ 成都律所排名
├─ 成都律师事务所哪家好
└─ 成都知名律师事务所

两组 Query 在人看来仍属于同一个需求。

但它们进入搜索系统以后，已经开始访问不同的信息空间。

真正发生变化的可能不是答案，而是答案之前

如果只保存最终回答，我们看到的可能只是：

A → 推荐了律所甲

B → 推荐了律所乙

然后得出一句很容易传播但几乎没有研究价值的话：

“你看，换个语序答案就变了。”

这个结论远远不够。

因为生成式 AI 本身存在随机性。

即使完全不修改问题，两次回答也可能不同。

所以真正值得研究的不是：

Answer A ≠ Answer B

而是能不能进一步观察：

Query A
↓
Rewrite Set A
↓
Source Set A
↓
Entity Set A
↓
Answer A

和：

Query B
↓
Rewrite Set B
↓
Source Set B
↓
Entity Set B
↓
Answer B

如果差异从 Query Rewrite 就开始出现，随后 Retrieval Source、候选实体和最终推荐继续发生变化，那么这就不再只是一次随机答案波动。

它变成了一条可以测量的检索链。

2万多条采样真正给我的，不是一个营销数字

这里我也想把边界讲清楚。

我累计保存和处理的 GEO 相关采样已经超过 2 万条。

但我不会说：

“我做了2万次严格的语序对照实验。”

不是。

这些数据来自不同时间、平台、题集和实验任务。

并不是每一条都拥有完整的 Query Rewrite。

真正重要的是，大量长期采样让我逐渐能够区分：

普通生成波动

和：

值得继续追踪的结构性异常

数据足够多以后，一次答案改变已经不会让我马上得出结论。

我更关心的是：

Question有没有变化？
↓
Query Rewrite有没有变化？
↓
检索来源有没有变化？
↓
候选实体有没有变化？
↓
最后的推荐才有没有变化？

这可能才是 GEO 从“看答案”走向“测系统”的分界线。

在目前能够完整回溯的数据里，我已经开始记录中间层

现在我的采样系统不再只保存：

AI 最后回答了什么。

而是尽可能把整个链路拆下来。

包括：

Question
↓
Observation
↓
Sampling Run
↓
Query Rewrite
↓
Source
↓
Competitor / Entity
↓
Final Answer

在目前具有完整 Query Rewrite 链路的数据中，我已经能够把 Sampling Question 和 Query Rewrite 通过真实 ID 回溯。

这件事情对我来说，比最终某一次“排第一”重要得多。

因为它第一次让：

AI为什么得到这个答案

开始变得部分可观测。

一个意思，为什么可能走进不同的网络世界？

回到律所这个脱敏例子。

除了语序，词本身也可能改变检索规划。

例如：

“推荐”

可能把系统推向：

候选生成
评价
列表
排名

“靠谱”

可能增加：

口碑
案例
资质
评价
风险

“律所”

可能强化：

Organization Entity

“律师”

则可能强化：

Person Entity

“成都”

还可能增加：

本地来源
地域实体
Local intent

所以“一字之差”真正值得研究的地方，并不是：

AI 是不是像传统关键词搜索一样少一个字就不认识。

恰恰相反。

问题可能在于：

一个词改变了系统对任务的理解，从而改变 Retrieval Planning。

这两个解释完全不同。

所以我不再把Query当成一个点

以前做 GEO Benchmark，我们很容易这样设计：

Question 01
Question 02
Question 03
...

然后固定问题，重复采样。

这依然非常重要。

但它测出来的是：

固定表达下的稳定性。

真实用户不会永远使用同一句话。

所以我现在更愿意把测量单位拆成三层：

Intent
  ↓
Query Family
  ↓
Query Variant

例如：

Intent：
寻找法律服务提供者

Query Family：
成都律所发现

Variant：
├─ 成都推荐一家律所
├─ 成都律所推荐
├─ 成都有哪些靠谱律所
├─ 成都律师事务所哪家好
└─ 成都找律所推荐

这些 Variant 对人来说可能属于同一个任务。

但真正的实验应该继续向后比较：

Variant
↓
Rewrite Set
↓
Source Set
↓
Entity Set
↓
Final Answer

这时候我们测量的才不再是一句话。

而是一个需求空间。

这会改变GEO Benchmark应该怎么设计

假设企业真正关心的是：

用户找律师事务所时能不能想到我？

只固定：

成都律所推荐

每天测试100遍，

最终我们可能得到非常稳定的推荐率。

但它只能说明：

在这一种语言表达下，这个品牌的可见度如何。

真实用户可能使用另外十几种表达。

如果不同 Variant 产生不同 Rewrite Set，那么单一 Question 的稳定结果并不足以代表整个 Intent。

所以一个更成熟的 Benchmark 应该逐渐区分：

Question Stability

和：

Intent Coverage

前者回答：

这一句话重复问，结果稳定不稳定？

后者回答：

用户换一种自然说法以后，这个品牌还能不能进入候选？

我认为这两项指标未来都应该存在。

但千万不要把这个研究变成“一个Query建一个页面”

这是我最不希望这个发现被误用的地方。

最容易出现的 GEO 做法会是：

成都推荐一家律所
→ 一个页面

成都律所推荐
→ 一个页面

成都靠谱律所
→ 一个页面

成都律师事务所哪家好
→ 一个页面

然后批量制造几百个近义 URL。

我认为这是错误方向。

Query Variant 应该扩大的是：

测量空间。

而不是：

页面数量。

正确方向反而应该是：

多个 Query Variant
        ↓
理解共同 User Task
        ↓
建设一个真正完整的信息资产
        ↓
覆盖用户需要的事实、实体和证据
        ↓
让不同 Retrieval Path 最终都可能找到它

所以：

Query Family 是研究单位，不一定是页面单位。

这点对 SEO 和 GEO 都重要。

SEO和GEO在这里其实开始汇合了

传统 SEO 经常问：

这个页面应该优化哪个关键词？

而做了这些实验以后，我越来越愿意换一个问题：

这个页面应该解决哪个信息任务？

关键词仍然重要。

但越来越像用户进入某个信息空间的不同入口。

真正稳定的内容资产仍然需要：

清晰的 User Task
+
完整的信息覆盖
+
明确的实体
+
可靠的证据
+
可抓取的结构

这也是为什么我现在很难再把：

SEO

和：

GEO

理解成完全独立的两套技术。

它们最终都在解决：

信息如何被找到、理解、验证和使用。

只是生成式搜索在用户 Query 和最终答案之间，增加了更多概率性的：

Rewrite
Retrieval
Rerank
Synthesis

过程。

我真正想留下的是一条可复验的研究链

关于这个发现，我不会主张：

“我是世界上第一个发现AI会受措辞影响的人。”

这个命题没有意义。

我也不会说：

“换一个字，AI结果一定会改变。”

它显然不是确定性的。

我真正希望公开并持续验证的是一个更具体的工程问题：

在中文GEO环境中，同一用户意图的不同自然语言表达，可能触发不同的 Query Rewrite；这种差异可以继续传导到 Retrieval Source、候选实体和最终 Brand Visibility。

我认为真正值得记录的不是一句：

“AI对语序敏感。”

而是：

Query Variant
      ↓
Query Rewrite
      ↓
Retrieval Source
      ↓
Entity Candidate
      ↓
Brand Visibility

这条链能不能被持续观察、重新运行和反复验证。

在AI搜索里，同义不一定意味着同路

这是目前这些数据让我越来越确定的一点。

两个问题在人看来完全可能是一回事。

但如果不同语言表达让系统选择了不同的检索路径，那么从那一步开始：

它们看到的互联网，可能就已经不是同一个互联网。

而我接下来真正想继续测量的，

就是发生在：

用户问题

和：

最终答案

之间，

那条过去几乎完全看不见的路。

研究说明与证据承诺

为保护真实研究对象、内部采样题集及执行参数，本文涉及律所行业的 Query 示例均为基于真实实验结构进行的等价脱敏重构，并非原始采样记录逐字公开。

本文所述机制判断来自长期 GEO Sampling 数据。作者累计保存的相关采样数据已超过 2 万条，但本次 Evidence Bundle 仅冻结与本研究主张直接相关的证据子集，并不包含全部累计样本。

Evidence ID：

GEO-QUERY-SENSITIVITY-V1

Public Commitment Date：

2026-09-17T21:22:15+08:00

Earliest Verified Internal Record：

2026-09-08

Root SHA-256：

7f0aec0047760023bb484cb1d85ced7bc7997bc953350b07bdef0c2a8fd25e63

原始研究证据由作者私有保存。

该 Hash 用于证明在 Public Commitment Date 时，作者已经对一组固定证据建立完整性承诺；它本身不构成更早日期的密码学时间证明。