一个团队让 API 推荐供应商，把答案存下来，加到一个标着“ChatGPT 可见性”的看板里。请求成功了。响应里有一些能认出来的公司。看板看起来可信。
问题出在那个标签上。API 响应是关于某一次具体请求及其配置的观察结果。它本身并不显示某人在使用 ChatGPT 搜索时看到了什么。把两者混为一谈，会让产品团队去优化错误的系统，让市场团队报告一个它从未测量过的曝光。
对与多个模型打交道的开发者来说，这种区分不只关乎品牌监测。模型名只是应用的一部分。所提供的上下文、指令、检索工具以及周边产品行为，共同决定用户收到的答案。
在比较答案之前先定义系统
当一个 API 测试的输入是明确的，它才最容易解读。你可以记录所请求的模型、messages、工具定义、可用文档以及受支持的生成参数。你也能控制应用在展示响应之前如何处理它。
消费级产品有它自己的配置和界面。其中一些行为可能是可见的；另一些可能没有被记录到足以复现的程度。即使两种体验指的是同一个模型家族，prompt 相同也不能证明它们使用了完全相同的上下文或检索。
这不是放弃 API 测试的理由，而是准确命名结果的理由。“我们的应用在开启网页检索的情况下返回了这些供应商”是一个有用的观察。“ChatGPT 向买家推荐这些供应商”是另一个主张，需要来自那个被点名产品的证据，以及一组定义明确的买家任务。
把它们当作两个独立的测试项目。应用测试回答的是你的产品行为是否正确。产品观察测试回答的是在外部体验中、在你记录的条件下显示了什么。两者都不能自动替代对方。
生成的答案不是发生过搜索的证明
模型可以在那次请求中完全不打开某公司的网站，就产出关于这家公司的答案。认出一个名字不能确立信息的新鲜度，而普通生成文本里的一个 URL 本身也不是检索痕迹。
当你的应用需要最新信息时，配置一条合适的检索路径，并检查它是否真的被用上。OpenAI 的网页搜索文档描述了在 Responses API 中启用相关选项的情况，包括 web_searchsearch-call 输出项以及 URL 引用注解。它还指出，启用该工具后，模型可以根据 prompt 自行决定是否搜索。[2]
这意味着“工具可用”和“工具被使用”在测试记录里应该是两个不同字段。保存返回的工具调用信息，而不是从自信的措辞去推断发生过搜索。如果请求失败、返回不完整结果，或者没有走预期的检索路径，也要把这个结果保留下来。
在渲染有搜索支持的答案时，保留引用注解。OpenAI 的文档要求，在向用户展示其网页结果中的信息时，必须提供清晰可见、可点击的行内引用。[2] 把所有内容压成一个纯文本字符串，可能会丢掉你的界面需要展示的证据。
引用仍然需要检查。看被引用的页面是否支撑它所附着的陈述，而不是仅仅因为答案里有个链接就给它质量分。
把供应商调研与可见性测量分开
假设一个团队在研究人们如何找到 geo agency singapore。开发测试可能会让一个由 API 驱动的助手识别服务、解释选择标准，或比较提供的服务商页面。这些测试可以揭示应用是否检索到了有用的证据，以及是否准确地描述了它。
可见性研究问的是另一件事：在一组相关的用户任务中，某个服务商是否、以及以何种方式出现在某个指定的 AI 产品里。观察结果应当区分三种情况：答案提到了这个品牌、有一处引用链接到它的网站、以及给出带明确理由的推荐。被用于某个事实点的来源，不一定就是被推荐的供应商。
如果测试 prompt 明确问的是某一家公司，那么在答案里找到这家公司，几乎说明不了它在一次不带品牌的发现类任务中出现的可能性。带品牌和不带品牌的 prompt 都可能有用，但它们属于不同组。
不要把一次缺席的提及变成一次事故，或变成一个对服务商可见性的终局判决。把它保存为既定测试条件下的一个结果。同样，也不要把一个漂亮的答案变成对每个买家体验的主张。
保留一份你能复现、或能诚实描述的记录
对你自己应用来说，一份有用的测试记录包括：
- 确切的用户输入，以及随它一起发送的任何应用指令；
- 端点、请求的模型标识符，以及返回的版本信息；
- 提供给该请求的文档或对话上下文；
- 哪些工具可用，哪些真正运行了；
- 可能影响答案的受支持设置，包括所用到的检索过滤或位置配置；
- 请求时间、返回的答案、引用、错误以及重试历史；
- 用于给输出打分的规则，以及对此分数的任何人工修正。
存足够的细节，以便在调查差异时用得上，同时不要随意保留敏感的客户数据。使用经批准的测试素材，限制日志的访问权限，并决定原始输入需要保留多久。
对于外部产品的观察，记录产品、可见的模式、查询措辞、时间、对话设置、你能观察到的相关设置，以及显示出来的答案。把未知的配置标为未知。把一次测试称作可复现，并不会让隐藏的产品设置变得可用。
把失败的观察与有效但未提及的答案区分开。页面加载失败或响应中断不是干净的阴性结果。把这两类结果混在一起，会让可靠性问题看起来像是品牌可见性的变化。
一次只改应用的一个部分
评估新模型时，保持证据包和评审标准不变。评估检索时，尽可能保持模型和其他受支持设置稳定。如果你同时改动 prompt、模型、文档和搜索配置，你比较的是整套工作流，而不是隔离出某一个原因。
两类比较都合理，关键是标对名字。完整的工作流比较帮助团队决定上线什么；受控的组件测试帮助解释为什么某种配置表现不同。
把有代表性的任务跑不止一次，并保留差异。在报告比例时，记录尝试次数和有效观察次数。来自一个有意挑选的测试集的结果描述的是那个集合；它们不会自动成为所有用户看到某品牌频率的估计。
不要把模型之间的一致当作验证。多个系统可能重复同一个来自同一来源的说法，或者共享一个没有依据的假设。就事实准确性而言，决定性的证据仍然是底层材料和任务本应满足的标准。
既要测模型，也要测网关
String AI 记录了一个共享的 API 入口，以及面向受支持集成的 OpenAI 兼容认证。[1] 这对通过统一连接方式来比较模型的团队很有用。但它不应被理解为承诺：每个上游功能、托管搜索工具或响应对象在每条路径上都完全一致地工作。
在依赖检索或引用处理之前，测试你应用实际会用的那个端点与模型组合。确认预期的工具受支持、请求保留了它的配置、响应暴露了你界面需要的信息。并决定功能不可用时怎么办：返回明确的限制说明、使用显式配置的替代方案，或者停止任务。静默退回一个没有检索的答案，会改变应用能主张的东西。
API 评估可以既严谨又有商业价值，而不必假装复现一个消费级产品。命名你测试的系统，保留它的配置，把它的证据附着在结果上。这样开发者拿到的是可以改进的东西，市场团队拿到的是可以解释的测量。
来源
[1] https://www.string.ink/docs
[2] https://developers.openai.com/api/docs/guides/tools-web-search