同义不等于同路:我在2万+条GEO优化采样里看到的Query敏感性

简介: 本文基于2万+条GEO采样数据,揭示AI搜索中“同义不等于同路”的核心现象:语义相近的用户提问(如“成都推荐一家律所”vs“成都律所推荐”),可能触发不同的Query Rewrite,进而导致检索路径、候选实体与品牌曝光显著分化。研究主张将GEO评估从“单问稳定度”升级为“意图覆盖度”,推动SEO与GEO在信息任务层面融合。(239字)

同义不等于同路:我在2万+条GEO优化采样里看到的Query敏感性

过去几个月,我累计保存和处理的 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 时,作者已经对一组固定证据建立完整性承诺;它本身不构成更早日期的密码学时间证明。

引用来源:改文章摘录自GEO优化专家王涛个人官网:https://taomir.cn/articles/geo-query-sensitivity/

相关文章
|
20天前
|
人工智能 自然语言处理 机器人
程序员节限时福利:21元拿下好域名
项目写到一半,域名还没定?1024开发者节推出专属后缀:`.chat`(AI/客服)、`.run`(运行环境)、`.team`(开发团队),首年统一21元,直降40%–58%!支持万网CLI自然语言查域名、比价、下单。
程序员节限时福利:21元拿下好域名
|
2月前
|
数据采集 人工智能 搜索推荐
GEO服务商怎么选——交付形态、能力深度与风险承担三维评估框架
王涛(成都GEO专家)提出GEO服务商三维评估框架:一比交付形态(工具/服务/咨询型),二看能力深度(以可验证交付物与题集结果为证),三查风险承担(承诺是否定义清晰、口径可复盘)。强调不比综合分,而要逐项核验基础、结构、战略、风控四层能力的交付物,推动行业标准化。(239字)
|
2月前
|
人工智能 自然语言处理 API
觉得阿里云大模型价格太高怎么办?四种便宜购买与使用方法分享
本文针对阿里云大模型“能力强但调用成本高”的普遍痛点,梳理了一套可落地的全链路省钱方案。从开通百炼领取超7000万Tokens新人免费额度起步,叠加夜间错峰4折起的Night Plan活动,再搭配Token Plan订阅与AI通用型节省计划,四层优惠叠加后,实际调用成本可降至普通按量付费的三到五成,帮助个人开发者与团队大幅降低大模型落地的综合开支。
912 17
|
2月前
|
人工智能 缓存 数据库
常青翻新|Mock 不是万能替身:Dummy/Stub/Spy/Mock/Fake 五种 Test Double 的边界与踩坑
本文厘清测试替身的五大分类(Dummy/Stub/Spy/Mock/Fake),指出滥用“万能Mock”导致测试脆弱或假绿的根源:混淆“提供数据”与“验证交互”。强调选型核心原则——**先明确断言对象(数据?交互?真实行为?),再决定替身类型**,并结合AI场景(如Agent轨迹验证、假模型替代)赋予经典模式新生命力。
|
2月前
|
机器学习/深度学习 前端开发
发动机故障诊断智能体(三):特征可分性优化与加权对比投影层
在基础时序编码网络完成对正常工况的压缩表征后,尽管模型具备了提取稳态规律的能力,但在面对多种不同类型的微量气路故障时,潜在空间中的特征分布仍可能存在相互交叠的现象。该组件致力于通过引入度量对比学习机制,在特定的低维投影空间内重塑特征拓扑结构,系统性优化不同故障模式之间的几何可分性。
|
2月前
|
人工智能 中间件 API
LangChain+Llama.cpp 本地模型与Agent工具调用
本文介绍如何用LangChain对接本地llama.cpp服务:通过`llama-server`启动Qwen量化模型,配置OpenAI兼容接口;安装LangChain生态包;实现基础对话与自定义工具Agent(如查天气、时间),全程离线运行,零依赖云端API,适合私有化AI原型开发。(239字)
305 3
|
2月前
|
SQL 测试技术 数据库连接
我用ChatGPT把回归测试从3天压到3小时,提示词全公开
本文分享如何用ChatGPT优化电商后台回归测试:通过提示词引导,实现用例梳理、自动化脚本生成与日志分析三步提效,将3天人工测试压缩至3小时。强调其辅助定位而非替代人力,聚焦释放工程师精力于高价值工作。
|
2月前
|
机器学习/深度学习 算法 前端开发
发动机故障诊断智能体(二):基础时序压缩与长短期记忆编码网络
在智能体完成气路多航段时序数据的采集与规整后,高维度的原始时序信号需要经过深度表征与降维处理,以消除高频测量噪声并提炼本质物理趋势。采用长短期记忆自编码器架构,在脱离人工标签监督的情况下,利用海量正常运行数据进行自监督重构训练,构建出能够压缩并表征发动机稳态工况与退化趋势的时序特征提取模型。
|
4月前
|
人工智能
Qwen3.8抢先体验!正式版即将发布并开源!
千问Qwen3.8即将开源,参数达2.4T,进化速度以“天”计,实力媲美Fable 5。预览版Qwen3.8-Max已上线阿里Token Plan等平台,限时优惠:日间Credits低至1折,夜间更优,个人/团队版月付仅35元起!
6434 223

热门文章

最新文章