ChatGPT、Gemini、Perplexity 结果不同，究竟该信哪个？

不同答案可能对应不同产品条件

你拿到报告，发现某个品牌没有被提到；同事打开手机问一遍，却看到了它。两份记录不一定有一份是假的，也不一定说明平台忽然改变了排名。更常见的问题是，两次请求虽然使用相似模型名称，却经过不同的产品界面、搜索工具、账号上下文和执行时间。比较之前，应先确认它们到底测了什么。

模型是生成系统的一部分，消费者应用则把模型、工具、界面与产品策略组合起来。开发者调用某个 API，可以控制一部分参数并取得结构化输出；网页产品可能提供自动搜索、会话记忆、位置相关内容和多步任务。即使底层模型来自同一家供应商，也不能由此宣称两条路径输出必然相同。

企业真正要选择的不是“相信哪个品牌的 AI”，而是“哪种观察更贴近目标客户的实际决策场景”。如果客户主要通过手机上的消费者应用寻找旅游服务，只有开发者 API 的监测是不完整的；如果产品面向用 API 构建流程的工程团队，结构化接口测试又具有直接价值。两种证据可以互补，但需要各自清楚命名。

把五个容易混用的名称拆开

第一层是产品，例如网页对话、移动应用或开发者接口。第二层是请求中的模型标识，它可能是具体版本，也可能是会变化的别名。第三层是实际提供服务的供应商与路由；通过聚合平台时，请求名称未必等于最终执行端点。第四层是检索、浏览、文件读取等工具。第五层是最终展示，包括普通正文、来源卡片、图片和追问建议。

记录只写“测试了某某模型”，相当于拍照只写相机品牌。你仍不知道使用了什么镜头、拍摄场景和处理过程。对于 GEO，最关键的差异可能发生在模型之前：搜索有没有启用、哪些来源可用、问题是否被拆解；也可能发生在模型之后：平台显示哪些链接、是否隐藏来源细节，以及用户是否要展开才能看到。

本文不维护一份容易过期的“最新模型推荐榜”。更稳妥的记录是请求标识、返回标识、实际端点信息、公开可见产品模式与采集时间。若某字段没有返回，写“未公开”或“未返回”，不能根据名称猜出版本。如果接口只暴露别名，就保留别名和原响应，不把推测补进报告。

搜索开关与实际检索不是一回事

把搜索工具列入请求，表示允许或请求使用某种能力；是否真的发生检索，需要看提供方实际返回的证据。可能有明确的工具调用步骤、查询文本、来源注释或使用量计数，也可能只看到笼统的路由说明。字段的语义应按当前接口文档解释，不能让一个通用适配器里的布尔值替代完整证据。

Gemini API 的 Google Search grounding 文档展示了搜索工具、调用步骤和引用注释等公开返回结构。它可以说明这一接口怎样暴露搜索证据，但不能直接证明同名消费者应用执行相同流程。通过其他供应商兼容层访问时，字段还可能被重组或省略，因此需要保存原始响应与转换规则。

一种合理状态写法是“请求开启搜索；返回原生路由元数据；未返回调用次数，实际检索未单独证实”。这比把未知写成零次更准确。反过来，正文带有网址也不单独证明平台刚刚访问了该网页：链接可能来自生成文本、已有上下文或其他来源。只有当返回结构和对应文档支持时，才把它作为平台返回来源记录。

同一公司的接口也有不同用途

搜索接口可以只返回检索结果，回答接口可以把结果组织成文本，代理接口还可能执行多步工具任务。它们的评估对象不同：返回候选网址多，不代表给消费者的最终答案提及更多品牌；一段答案很短，也不一定表示检索不充分。需要先读接口用途，再设计相应指标。

二〇二六年九月核验的 Perplexity API 官方说明明确区分 Search、Agent 与 Embeddings 等接口用途。即使文档说明某些接口共享基础设施，也不能推出原始搜索结果等同于网页最终推荐。共享底层能力与完整产品体验一致，是两种不同层级的主张。

采购报告时，可以要求服务方说明“使用哪个产品或端点、怎样触发搜索、返回什么、哪些字段可核查”。不必要求公开无法获得的内部提示词，也不应相信可以从外部准确还原所有商业平台内部流程的说法。公开文档、实际请求和原始响应应能互相对照；未知部分则保持未知。

会话历史会改变买家问题的含义

一句“哪个更适合我”，必须结合前文才能理解。用户可能已经说过预算、国家、团队规模、隐私要求，也可能提过品牌名字。网页里的回答于是带有很强的上下文条件。把它截成单独一屏，再与完全没有历史的 API 请求比较，会把上下文差异误认为模型偏好。

新会话测试适合固定条件，真实使用情境测试则适合观察多轮决策。两者应分开记录。新会话也不必然意味着完全没有账号级设置或产品记忆；测试者能够看到什么就记录什么，无法验证的背景不要自称已经清空。涉及客户个人资料时，保存必要的条件摘要即可，不要为诊断复制无关私人聊天。

提示方式同样属于处理条件。直接问一句、附上两个示例、要求逐项列证据或把任务拆成连续步骤，都会改变请求。把品牌介绍当作系统指令加进去，再把最终答案当自然发现测试，是严重的口径错误。若目标是测试改进后的文案能否被理解，可以明确提供材料，但必须称为受控理解测试，不能冒充平台自行检索到了它。

语言、地区、账号和设备怎样记录

语言不仅影响答案语言，也影响问题本身的业务含义。例如中文“获客”可能指销售线索，也可能指开户流程；英文 acquisition 还可能被误读为并购。翻译时应先固定买家任务，再由熟悉当地市场的人确认表达自然。机械逐词翻译无法保证两题属于同一种需求，更不能把语言差异自动归因于品牌在某国的影响力。

地区可以记录测试者真实所在地、界面提供的位置设置、浏览器语言和时区，但 API 机房地区不等于消费者搜索地区。代理路由元数据中的区域通常描述服务处理位置，不能据此宣称“测试了美国用户”。账号可记录登录与否、可见订阅档位及公开设置，避免记录密码、令牌或个人身份细节。

设备影响可见布局和交互，有时也影响默认入口。手机上折叠的来源在桌面可能直接显示；一张截图看不到某链接，不一定表示响应没有该链接。保存完整回答和必要的展开状态，比只截第一页更可靠。如果为了测试使用了特殊网络或地区配置，应如实记录，不把它写成当地真实消费者的自然体验。

建立条件矩阵再比较答案

一个跨平台观察表可以包含：问题编号与原文、用途、目标语言、产品路径、可见模式、模型与版本字段、搜索设置、会话状态、账号条件、时间、地区信息、最终状态及证据编号。不同产品没有的字段应填“不适用”，产品不公开的字段填“未知”，请求没有设置的字段填“省略，使用默认值”。这三个状态不能混为一谈。

教学例子比较八项条件：问题、意图、语言与空白历史相同；搜索设置、来源集合、模型快照与账号背景不同或未知。因此只有四项可以确认匹配。这是记录完整性的提示，不是两产品“相似度百分之五十”。条件并非等权，一项关键的品牌注入就足以改变整个实验问题。

for field in comparison_fields:
    if both_observed(field) and left[field] == right[field]:
        label = "匹配"
    elif either_unknown(field):
        label = "未知"
    else:
        label = "不同"

这个伪代码的变量 field 指一项条件，both_observed 表示两边都有真实证据。它不尝试填补隐藏配置。读者可以在表格里加入“是否提供目标网址”作为高优先级字段；如果一边有网址、一边没有，先拆成两个测试目的，而不是继续计算谁表现更好。

一个不联网的答案差异教学示例

我们人为设定 API 路径返回候选甲、乙、丙，网页路径返回乙、丙、丁。共同候选为乙、丙，并集为甲、乙、丙、丁。集合交并比 J 等于交集数量除以并集数量，即二除以四为零点五。脚本已经执行这一计算，但这些名称与结果纯属教学设定，不代表任何真实平台调用。

交并比只描述候选集合的重叠，不能评价哪个候选适合客户，也不能说明谁更准确。若甲不支持必要的离线部署，而丁支持，较低重叠可能伴随更好的答案；若两个集合都漏掉关键限制，高重叠也只是稳定地共享错误。分析时应再加功能适配、事实准确性、来源支持与建议条件四个维度。

同样的原则适用于来源集合。两个平台都引用官网，可能引用不同版本、不同语言页或不同段落。先保留原始 URL，再记录规范化策略和内容日期。网页显示为跳转链接时，如果无法合法访问目标，就保留跳转地址与标签，不凭标题猜出具体文档。完整保留未知，比补成一个“看起来应该是”的链接更利于复核。

重复采样和失败应如何安排

只做一次跨平台提问，适合演示差异，不适合概括长期表现。可以先固定少量高价值题目，在预先约定的时间批次重复采集，并交错平台顺序，减少某个时段独占一组的影响。重复不是为了不断刷新直到品牌出现，而是观察同一条件下的分布，所以完整结果与失败都要保存。

提供方拒答、浏览器加载失败、模型输出截断与登录要求应分别记录。网页产品需要升级或当前不可访问时，不应把它填成“该平台未提及品牌”；API 配额错误也不是消费者回答。重试要遵循统一规则，并区分新的观察与原失败恢复。对成功集合的比较，应同时展示各路径完成率。

模型更新是另一种变化来源。别名背后版本改变后，可以继续监测，但图表应标出配置断点。不要把新版后的首次提升全部归为网站内容效果。具体如何区分采样波动与系统变化，可阅读模型随机性与 GEO 波动，再决定是否需要建立新的基线。

用目标客户决定测试组合

测试组合应从真实客户任务出发。面向工程采用者，可以把接口与文档理解放在较高优先级；面向旅行预订或本地服务，真实语言、地区和消费者界面更重要；面向电商，还要核对图片、价格和规格是否显示完整。这些是业务选择，不是全行业统一的三平台套餐。

在预算有限时，可以先用结构化 API 观察形成可复算基线，再由人工在目标消费者界面验证重要差异。也可以先从真实客户反馈出发，针对“手机端反复误述价格”安排具体任务，再用接口测试定位材料问题。两种顺序都可以，关键是报告不能把不同证据折叠成没有限定的总排名。

一份有用的结论可以这样写：“在保存的无历史中文选型题中，两条路径返回不同候选；网页路径强调地区服务，接口路径强调技术栈。我们将先补齐地区服务条件，并在原题下分别复测。”它比“某平台更相信你”更容易审查，也直接连接到业务信息改进。

从差异记录走向可验收的工作

还应检查人工测试有没有改变任务。测试人员为了让平台“给个答案”，可能追加一句“请一定列三个产品”，或先告诉它目标官网。这些追问能够用于分析交互，但已经不同于原始单轮问题。保存时应把首轮与后续追问分开，让客户知道品牌是在自然首答中出现，还是在明确引导之后才被补充。

跨平台的失败处理也必须对称。不能给一个产品三次机会，只给另一个一次，再比较最终成功截图。如果某产品允许的任务方式不同，可以采用各自真实的使用流程，但结果应称为产品情境观察，并说明步骤差异。所谓公平，不是强迫所有产品使用不适合自己的接口，而是让比较目的、机会与限制都对读者透明。

证据保留还要区分原始记录与公开交付。内部可以保存必要执行标识用于排查，客户报告只需要解释条件、问题、答案与来源。不要把密钥、账号标识或无关聊天历史混进附件；删除这些私人字段并不损害对最终答案的核验，反而能让证据更容易被客户安全地分享给产品与市场团队。

读者可以运行 python3 part-b-run-examples.py，在 P12-result.json 查看八项条件和两个候选集合，再自行修改未知字段或候选名单，观察计数如何变化。这只验证记录与集合运算，不验证现实平台能力。正式测试另需明确范围、授权和实际执行证据；消费者网页测试还应保存对应截图与完整答案。

NiubiGEO 可以用自动采集保存可追溯接口结果，并通过人工测试核查目标市场的消费者体验。实施前应约定产品路径、题目、语言、采样窗口与交付证据，发生无法执行的情况也如实记录。服务价值在于解释不同观察各能支持什么，并把反复的事实缺口转成行动，而不是替用户挑一张最漂亮的截图。