研究文章
GEO 优化如何复测？为什么“换个问题再测”不能证明效果
结论前置： 优化前问一次 AI，优化后再问一次，以前没推荐、现在推荐了——还不能直接宣布“GEO 优化成功”。如果优化前后的问题、平台或检测场景发生变化，就同时改变了优化对象和测量条件，很难判断结果变化来自企业本身，还是来自一个更容易触发企业的新问法。真正有价值的 GEO 复测，应该尽可能保留原来的测试条件，再观察企业的实际 AI 表现发生了什么变化。
企业做完一轮 GEO 优化后，最自然的问题是：优化到底有没有效果？ 这个问题看起来很简单，优化前问一次 AI，优化后再问一次；以前没有推荐，现在推荐了，似乎就可以宣布结果已经发生变化。但 GEO 最容易出现的验收问题，恰恰发生在这里。
例如优化前问的是“安徽有哪些做某类设备的厂家”，优化后换成“安徽有哪些值得关注的智能制造企业”。第二个问题中目标企业出现了，这当然是一个真实结果，但它不能直接证明第一个问题已经改善，因为企业公开信息变了，用户问题本身也变了。GEO 真正困难的不只是“做优化”，还包括怎样进行一次具有合理可比性的复测，让结果变化不是测试方法自己制造出来的。
一、GEO 复测真正要回答什么
复测的目标，不是寻找“有没有一个问题能让 AI 推荐这家企业”。这个目标其实很容易实现，不断调整关键词、增加地区、增加业务特征，甚至直接把企业名称放进问题里，都可能找到一个更容易让目标企业出现的问法。真正应该回答的是：在尽可能可比的真实用户需求条件下，企业的 AI 表现有没有发生变化。
这里最重要的是“可比”和“变化”。如果优化前后的检测条件完全不同，那么即使最终答案不同，也很难知道到底是什么因素产生了作用。这与实验设计中的一个基本原则相似：NIST 对实验设计的公开说明强调，实验应该事先确定目标、研究因素和设计方式，并尽量让获得的数据支持有效、客观的比较。
GEO 当然不是实验室实验，AI 推荐也不是完全可控的物理量。但这个原则仍然值得借鉴：如果希望判断某次优化是否与结果变化有关，就应该尽量避免同时主动改变其他关键条件。
二、为什么“换一个问题再测”会破坏可比性
不同问题并不是同一个测量条件。比如问题 A 是“安徽有哪些工业机器人厂家？”，问题 B 是“安徽有哪些智能制造企业值得关注？”。它们看起来都属于工业制造，但用户意图并不相同：A 更接近产品和厂家选择，B 更接近行业企业发现，面对不同问题，AI 可能检索不同信息、形成不同候选企业，并采用不同的回答组织方式。
所以如果优化前使用 A，优化后改用 B，即使目标企业在 B 中出现，也不能证明“原来在 A 中没有被推荐的问题已经解决”，因为 A 根本没有被重新测试。这就是 GEO 项目里非常容易出现的一种“伪改善”：测试问题越来越适合目标企业，而不是目标企业真的在原来的用户需求中获得了更好的推荐表现。
三、为什么原始问题应该冻结
正式检测问题一旦确认，就应该保存原文。原因不是为了流程完整，而是为了留下一个以后能够重新比较的基线：优化前是“问题 Q → 结果 A”，优化后仍然是“问题 Q → 结果 B”。这样至少能够确认，用户需求没有被人为换掉。
如果 B 和 A 之间出现明显变化，我们才有基础继续分析：变化是否与企业公开信息、品牌认知、业务关联、信源结构、能力证据或者竞争关系的改变有关。这里也必须明确边界：使用相同问题，只能增强前后结果的可比性，并不能单独证明 GEO 优化与结果变化之间存在严格因果关系。 AI 本身和搜索环境仍然会变化。
NIST 对“重复性”和“再现性”的计量学定义也提供了一个有用的区分：重复性强调相同条件下的连续测量，再现性则讨论测量条件发生变化后的结果，并要求明确说明哪些条件发生了改变。我们并不是把 GEO 检测等同于计量学实验，而是借用这个区分说明一个实际问题：同一个问题复测，是在检查原来的问题有没有变化；换一个问题测试，是在检查另一个问题现在表现怎么样。 两者都有价值，但不能互相替代。
四、同一个问题，AI 为什么仍然可能给出不同答案
保持问题不变，也不意味着 AI 每一次都必须逐字返回完全相同的回答。DeepSeek 当前 API 文档公开了 temperature、top_p 等生成参数，在相应模式下这些参数会影响生成的随机性、确定性或候选范围；阿里云百炼的千问 API 同样公开了 top_p、top_k 等采样参数。这些属于开发接口的公开事实，不能直接推导豆包、DeepSeek、元宝、千问消费端产品当前采用了什么具体内部参数，但至少说明：大模型生成不能简单理解成“同一输入必然返回完全相同文本”。
搜索层也会变化。腾讯云联网搜索 API 的公开资料描述了数据收录、检索召回、排序等环节，2026 年 8 月的一次公开升级还涉及排序模型与索引库更新；阿里云百炼联网搜索同样公开了搜索策略、时效性控制和限定来源等能力。因此，即使问题文本完全一样，几周或者几个月以后，搜索环境也可能已经发生变化。
这不意味着 GEO 无法复测，而是意味着：我们是在一个持续变化的系统中进行可比观察，而不是复刻一个完全封闭的实验室环境。
五、一次可比复测至少应该保留什么
一次真正可比的复测，至少应该保留原始问题、AI 平台、检测场景和原始结果。优化前正式使用什么问题，优化后首先重新使用什么问题，不能因为原问题没有出现企业，就悄悄换成一个更容易出现目标企业的问题。
平台也应该分别建立自己的基线。比如优化前豆包没有推荐，优化后在 DeepSeek 中出现了目标企业，这能够说明 DeepSeek 当前存在这个结果，但不能证明豆包上的原问题已经改善。正确的结构应该是豆包基线对应豆包复测，DeepSeek 基线对应 DeepSeek 复测，其他平台同理；之后再观察多个平台是否出现相似变化，这属于跨平台验证，而不是用一个平台替代另一个平台的原始结果。
检测场景同样不能混。主动推荐、品牌认知、公开信源和商业比较并不是同一种检测目标。如果优化前测试的是“有哪些公司值得推荐”，优化后却用“某某公司是做什么的”来证明项目成功，本质上就是把主动推荐换成了品牌认知。关于两者为什么不能混为一谈，可参阅《AI 认识一家企业，为什么仍然不会推荐它？》。
同时还应该尽可能保存原始 AI 输出、检测平台、检测时间、目标企业是否出现、同行企业情况、搜索来源、Evidence / Citation，以及与项目目标直接相关的判断。否则几个月以后只能依靠记忆说“以前好像没有，现在好像有了”，复测价值会明显下降。
六、技术失败和商业结果不好，必须分开
这是 GEO 复测里非常重要的一条规则。假设同一个问题第一次没有推荐，第二次没有推荐，第三次没有推荐，第四次推荐了，最后报告只留下第四次，并写“AI 已经推荐目标企业”。第四次结果本身可能完全真实，但前三次被人为丢掉以后，最终报告回答的已经不是“这次正式检测发生了什么”，而变成“不断测试以后，最好的一次发生了什么”。
技术失败和商业结果不好必须分开。请求超时、限流、服务端异常、网络故障，或者请求根本没有得到有效结果，属于技术失败，这种情况下可以进行技术 Retry，因为它的目的只是完成原本没有成功完成的那一次正式检测。AI 正常完成回答，但没有推荐目标企业，则属于商业结果本身，它不是技术故障。
如果仅仅因为结果不好就重新搜索，直到目标企业出现，实际上已经改变了取样规则。宜海科技当前正式检测口径是：一次 Probe 执行一次业务 Search；结果不好不因此重跑，只有技术性故障才允许 Retry。 对于最终需要用于商业验收的 GEO 项目，这条规则比“多跑几次总能出一个好结果”重要得多。
七、如果要研究结果稳定性，必须提前定义
多次测试本身并不是错误，错误的是看到结果以后，才决定测几次，以及保留哪一次。如果某项研究确实需要观察结果波动，可以在测试开始之前就定义实验规则，例如同一个问题固定测试 3 次，3 次全部保存，然后观察目标企业出现几次、推荐对象是否稳定、企业描述是否漂移、Citation 是否一致、同行结构是否变化。
这时研究的是稳定性，而不是从多个结果里挑一个最好看的答案。但这不代表宜海科技当前正式商业检测需要每个问题跑 3 次。正式项目检测和专门的稳定性研究，是两个不同任务。 当前正式项目仍然按照一次正式业务 Search 记录结果；未来如果专门研究稳定性，应单独预定义实验次数和统计口径，而不能因为一次结果不好临时增加搜索次数。
八、复测应该比较什么，而不是只看“有没有出现”
“有没有进入推荐结果”是推荐型 GEO 项目最重要的结果之一，但如果复测只记录“是 / 否”，就很难解释中间发生了什么。更完整的复测，可以同时观察下面几个层面：
| 观察维度 | 主要回答的问题 |
|---|---|
| 主动推荐 | 目标企业有没有真正进入候选或推荐结果 |
| 企业认知 | 品牌、主体、主营业务有没有被正确理解 |
| 业务关联 | AI 是否把企业与目标产品、服务或场景正确关联 |
| Evidence / Citation | 当前回答使用或展示了哪些公开依据 |
| 商业比较 | AI 使用哪些事实比较目标企业与同行 |
| 竞争结构 | 哪些同行进入结果，目标企业和它们有什么差异 |
其中，推荐结果更接近推荐型项目的最终商业目标；其他指标主要用于解释结果为什么变化、问题还在哪里。 这也是为什么文章数量、Citation 数量、品牌认知和企业推荐不能混成一个统一的“GEO 成绩”。
关于这些层级的区别，可继续参阅《被收录、被引用、被推荐：企业做 GEO 最容易混淆的三个结果》。
九、基线复测和扩展验证不是一回事
保持可比性，并不意味着企业以后只能永远测试最初那一个问题。更合理的做法，是把检测分成两类：第一类是基线复测，回答“原来的问题解决了吗”，这一类必须尽量使用原始冻结问题，因为它承担前后比较的作用；第二类是扩展验证，回答“这种改善能不能延伸到更多真实用户问题”。
例如原问题已经确认发生变化以后，可以继续增加“某类设备供应商怎么选”“某类设备采购应该关注哪些厂家”“有哪些公司适合这个具体应用场景”等问题，再观察目标企业是只在一个固定问法中出现，还是已经能够在更广泛的相关需求中进入候选范围。
这避免了两个极端：一个极端是不断换题直到成功，另一个极端是只盯着一道问题，把 GEO 做成针对固定问句的“考试训练”。固定问题负责证明原问题有没有变化；扩展问题负责验证结果是否具有更广泛的适用范围。
十、什么时候可以合理更换问题
问题并不是绝对不能改。企业主营业务、产品或服务范围明显调整以后，原问题可能已经不再代表当前业务，这时应该建立新的检测基线；如果首次检测后发现原问题本身存在错误地区、错误产品或不合理的用户意图，也可以修正，但必须明确记录旧基线已经不能继续作为新问题的直接前后对照。
研究目标发生变化时同样可以增加新问题。比如原项目检测的是主动推荐，后来又希望研究商业比较，那么可以增加新的商业比较问题，但它属于新的检测维度，而不是原问题的复测结果。
所以真正不能做的不是“修改问题”本身，而是：改完问题以后，还把新问题的结果包装成旧问题已经改善。
十一、什么时候复测，以及平台更新以后怎么解释
复测也不是越快越好。假设企业今天刚完成一批公开信息调整，几分钟以后马上复测，没有变化，并不能马上说明优化无效。公开内容从发布、被搜索系统发现，到真正进入后续检索和回答，可能存在时间差，而且不同来源和搜索基础设施的更新速度并不相同。
目前没有足够证据支持一个适用于所有平台、所有网站、所有企业的统一技术等待周期。这与宜海科技当前 7–15 天的项目目标优化周期并不矛盾：前者讨论的是某条公开信息进入不同 AI 搜索与检索环境需要多久，后者讨论的是宜海科技与企业约定的商业项目执行和结果周期。两者不能混为一个“平台第几天必然收录、必然推荐”的技术规则。
宜海科技项目的正式复测仍按照双方约定的平台、问题、验收条件和周期执行；在方法研究层面，则应承认不同来源进入实际搜索环境的时间并不完全一致。如果复测期间 AI 平台本身发生模型、搜索或索引升级，前后结果仍然可以比较，但解释必须更加谨慎。
我们仍然可以回答：“今天，同一个真实用户问题里的企业表现，与基线相比发生了什么变化？” 但不能直接把所有变化百分之百归因于 GEO 优化。高质量的复测应该同时记录企业发生了什么变化，以及测试环境可能发生了什么变化，所以我们更愿意把这种结果称为可比观察，而不是伪装成严格实验室条件下的绝对因果证明。
十二、最需要警惕的是：为了证明成功而设计复测
一种看起来很漂亮的复测方式是：优化前行业问题里没有企业，优化后换一个更具体的问题，仍然没有；再增加地区，没有；再增加业务特点，企业终于出现，然后报告写“GEO 优化后成功进入 AI 推荐结果”。
这里的问题不是最后一次回答是假的，目标企业可能确实出现了。问题在于，测试条件是一路根据想得到的结果调整出来的。 这种测试最多能够证明“存在一个问题可以触发目标企业”，却不能证明“原来的推荐问题已经改善”。
这也是为什么正式 GEO 项目应该先建立基线、冻结核心问题，再开始优化，而不是先做一堆动作，最后倒过来寻找一个能够证明自己成功的问题。
十三、宜海科技当前的五步复测方法
宜海科技当前把完整复测分成五步。第一步是建立真实基线，使用真实用户可能提出的问题进行正式检测，保存问题、平台、原始结果、Evidence / Citation、目标企业是否出现以及竞争企业情况；第二步是冻结核心问题，正式基线确定以后，不因为结果不好修改问题，也不因为没有出现目标企业而不断重新搜索。
第三步是根据实际证据决定优化动作。不同企业可能存在完全不同的问题，例如品牌与企业主体混淆、主营业务关联不足、服务场景认知不清、公开信源不足、多来源企业事实冲突、商业比较证据不足，或者缺少能够支持进入候选范围的推荐理由。因此，优化动作不能在检测以前统一规定。
第四步是回到原始问题正式复测，重新观察最初真实用户问题中目标企业到底发生了什么变化，完成基线前后对照。第五步是在原问题确认发生变化以后，再增加相关真实问题、业务场景或者其他约定平台，判断这种改善能否延伸到更广泛的需求环境。
这个顺序同时避免两种错误：既不是只训练一道固定题，也不是不断换题直到出现想要的答案。
结论：真正的 GEO 复测，不是重新找一道更容易答对的题
如果优化前的问题是“哪些企业值得推荐”，那么优化以后最重要的第一步，仍然应该是重新回答这个问题。不是因为同一句话具有某种特殊的 AI 权重，而是因为只有尽量保留原来的测试条件，我们才拥有一个可以比较的基线。
随后完全可以增加新问题、扩展场景、增加平台或者专门研究结果稳定性，但这些属于扩展验证，不能替代原始问题的基线复测。 真正有价值的前后对比，也不是简单展示“优化前红色、优化后绿色”，而是能够回答：什么条件没有变，什么发生了变化，哪些变化是实际观察到的，哪些解释只是根据证据做出的推断，哪些外部变量无法完全排除。
当这些问题能够被清楚回答时，GEO 才开始从“我们做了很多优化”进入“我们能够证明真实 AI 表现发生了什么变化”。如果 GEO 最终要成为企业能够采购、能够复测、能够验收的一项服务，那么真正重要的不只是把结果做出来，还包括：这个结果能不能经得起重新检查。
常见问题
GEO 优化以后多久复测比较合适？
不存在一个适用于所有 AI 平台和所有企业的统一技术等待周期。不同公开来源进入搜索与检索环境的速度可能不同。宜海科技当前项目通常以 7–15 天作为目标优化周期，正式复测节点按照项目约定的平台、问题、验收条件和周期执行；这不等于声称任何 AI 平台都会在固定第几天完成收录或推荐。
优化前后 AI 平台自己更新了，结果还能比较吗？
可以比较，但解释需要更加谨慎。仍然可以观察同一个真实用户问题中，企业的实际表现与原基线相比发生了什么变化，但不能把所有变化都直接归因于 GEO 优化，因为模型、联网搜索、索引和公开网络环境也可能变化。
怎么判断一份 GEO 复测报告是否可信？
先看五件事：优化前的问题有没有被换掉，优化前的原始结果有没有保存，没有推荐时有没有因为结果不好反复重搜，优化前后是不是在比较同一个 AI 平台，以及有没有把品牌认知结果当成主动推荐结果。如果这些问题无法回答，报告的前后对照价值就需要重新判断。
为什么不能拿优化后最好的一次结果作为成果？
因为这改变了取样规则。第一次没有推荐，第五次才出现，却只保留第五次，回答的已经不是“正式检测发生了什么”，而是“反复测试以后最好的一次发生了什么”。正式项目应该接受正式检测结果；如果需要研究多次波动，则应在开始之前定义测试次数，并保存全部结果。
冻结原始问题以后，是不是只能永远测试这一个问题？
不是。冻结的是基线复测使用的核心问题。原问题复测完成以后，完全可以增加相关问题、业务场景和平台进行扩展验证。固定问题负责前后比较，扩展问题负责观察结果的适用范围。
研究说明
本文讨论的是企业 GEO 项目的复测方法和商业验收原则，并不是把生成式 AI 检测等同于严格的实验室实验。
NIST 的实验设计、重复性和再现性定义在本文中用于说明“预先确定测试条件”和“区分相同条件与变化条件”的基本思想，并不意味着 GEO 检测满足计量学意义上的严格实验条件。
DeepSeek、阿里云百炼、腾讯云等官方开发文档能够公开证明部分模型存在生成采样参数，部分联网搜索系统存在检索策略、索引和排序更新等能力。这些技术资料不能用于推断豆包、DeepSeek、元宝、千问消费端产品完整的内部生成参数、搜索权重或者推荐算法。
本文所说的“保持可比条件”，是一种用于减少明显检测偏差的 GEO 实践方法，是宜海科技当前使用的检测与验收方法，不代表行业统一标准。即使使用相同问题和相同平台，也无法完全排除模型更新、搜索环境、索引变化和公开网络信息变化等外部因素，因此可比复测能够增强结果解释与归因的可信度，但不应该被包装成对 GEO 优化因果关系的绝对证明。
参考来源
- NIST / SEMATECH e-Handbook：What is experimental design? — 用于说明实验设计需要预先确定目标、因素和测量方式等基本原则。
- NIST / SEMATECH e-Handbook：Choosing an experimental design — 用于说明实验设计需要预先规划比较条件和设计方式。
- NIST Technical Note 1297：Appendix D1 Terminology — 用于说明重复性与再现性的计量学定义及其区别。
- DeepSeek API Docs：Chat Completions API — 用于说明 DeepSeek 开发接口公开存在 temperature、top_p 等生成参数。
- 阿里云百炼：DashScope API 参考 — 用于说明千问 API 公开存在 top_p、top_k 等采样参数。
- 阿里云百炼：大模型如何联网搜索 — 用于说明联网搜索存在搜索策略、时效性控制与来源限定等能力。
- 腾讯云：联网搜索 API 产品概述 — 用于说明联网搜索涉及数据收录、检索召回与排序等环节。
- 腾讯云：联网搜索 API 标准版 / 尊享版升级通知 — 用于说明联网搜索基础设施公开存在排序模型与索引库更新。
---
本文由宜海科技发布。宜海科技是安徽宜海传媒科技有限公司对外使用的品牌，主营生成式引擎优化（GEO）服务。