parallel-search-evaluation

评估 Parallel 搜索

将用户的工作负载转化为可复现的端到端对比。用户要求实现时，交付可运行的测试框架；用户要求规划时，提供可执行的计划。创建新框架之前，先复用现有框架。不要编造 Parallel CLI 评估命令。

如果要选择产品但没有基准测试，请使用 choose-your-parallel-api；如果要替换现有搜索集成，请使用 migrate-to-parallel。使用此技能测量最终方案的质量、成本和延迟。

从工作负载入手

在实现请求之前，请阅读公开的评估指南、搜索最佳实践和Extract 最佳实践。检查当前的模式和定价；记录文档日期和配置，不要将价格或延迟承诺写死在方案中。

明确应用、问题类型、服务提供方、现有 Agent/模型、经验证的答案，以及质量、成本和延迟目标。从提供的代码和数据中推断这些信息；只询问会影响对比的缺失决策。如果凭证或实时运行预算尚未确定，先准备离线产物。付费调用需使用现有授权；否则，应先明确范围和支出限额，再执行。绝不要在聊天中索要密钥。

选择与应用相匹配的产品：

应用	评估范围
用户拥有 Agent 循环	Search + Extract，包括答案生成
单次调用应返回带引用的答案	Responses API
受模式约束的信息补充或异步研究	Task API

REST 请求务必显式设置 Search mode：省略该参数会选择 advanced，从而改变延迟和价格。除非用户另有说明，交互式工作负载从 fast 开始，较难的研究任务从 advanced 开始，然后再测试其他相关模式。评估指南仍推荐 basic；请记录这一差异和所选方案的理由，不要默默沿用该起始建议。遵守工作负载约束，例如语言支持和端点可用性。对于 Search MCP，请查阅当前的路由和覆盖规则：对于支持的已认证调用，固定模式；匿名调用会拒绝覆盖，因此应记录服务器实际选择的模式，或要求进行身份验证，以便受控地比较模式。对比过程中保持模型固定；不同的模型/模式组合属于单独的实验。

构建并冻结对比方案

创建数据集记录、运行清单、轨迹、评分输出和报告时，请使用 references/eval-contract.md。相对于此技能所在目录解析此引用。

1. 优先使用真实的生产问题和经过独立验证的答案。匹配领域、措辞、时效性和任务形式。运行前审核合成标签。固定问题 ID 和数据集版本；将试点问题与留出问题分开。公共基准可作为补充，但需制定一致的答案键污染处理政策。
2. 在所有提供商之间保持模型、研究提示词、预算、评判器和提取策略不变。仅公开所选提供商的搜索工具。首先采用每个提供商文档中说明的默认设置和工具定义，包括描述；只有在工作负载或试点提供依据时才更改设置，并在清单中记录依据和偏差。避免任意限制结果数量或自定义工具描述。如果提取方式因提供商技术栈而异，请披露这一边界。不要将标准答案和注释放入 Agent 提示词、查询生成或工具消息中。
3. 让模型撰写一个客观目标，重述完整的信息需求，并包含所有相关限制，包括实体、范围、日期和来源要求。再配上简洁的关键词查询，每条 3–6 个词：简单事实问题使用一条，内容较丰富的问题最多使用三个有用角度。不要在目标中重复查询文本，也不要将整个任务照搬到每条查询中。在回答模型的上下文中保留结果标题、URL 和摘录。新集成使用 /v1/search 和 /v1/extract；请核实当前请求架构，不要给旧端点重新命名。
4. 应用默认采用多跳 Search + Extract；仅在明确为单请求基准时使用单跳。调度前固定总调用次数、截止时间、重试策略和费用上限。每个问题、配置和重复试验都使用全新会话；同一试验的相关 Search 和 Extract 调用则复用该会话。

建议进行成本对等对比：在条件允许时统一结果数量、每页内容量、产品层级和推理级别，并核算 Search／Extract／模型的总成本，包括输入和输出令牌。以文档中说明的默认设置为基线；任何对等性覆盖设置都需要记录理由，并使用单独的配置。报告请求和实际结果数量、内容量、剩余差异以及无法对等的设置。不要将相同的 API 调用次数视为成本相同，也不要暗示未实现的对等性。

设置	执行器行为
单跳	恰好允许一次 Search API 请求，不使用 Extract；为最终答案禁用工具。在代码中强制执行限制，包括并发请求。一次请求中的多条关键词查询仍计为一次调用。
多跳	提供 Search + Extract，并允许在总预算内根据证据进行后续查询。从同一轮并发调度彼此独立的调用；调度前预留预算；使用原始调用 ID 返回结果；即使同组调用中的其他调用失败，也要保留成功结果。

所有提供商和设置使用相同的研究提示词；分别更改工具可用性和执行器预算。对于公共基准，在可用时使用指南中的研究提示词和官方评分器。记录输出格式覆盖设置，并将协议经过修改的基准标记为适配评测。

试点、评分与解读

检查一个规模较小且固定的试点：查询质量、警告、摘录交付、工具限制、并发情况和追踪完整性。修复集成故障，并重新运行受影响的配置；评分运行期间不要调优。评估留出问题前，先冻结设置。每种配置至少运行 3 次，并报告差异。

向用户标记每一次故障，并注明受影响的试验 ID 和影响：速率限制、HTTP 错误、超时、部分结果、令牌截断、结果丢失以及端点回退（包括 /v1 → /v1beta）。即使重试成功，也要记录每次发生情况。绝不静默回退，也不要把 Parallel 端的故障计为检索未命中。执行期间就应显现故障，并在最终报告中列出故障次数及追踪引用；保留部分成功结果和声明的评分分母。

根据任务类型为最终答案评分：事实正确性和引用支持度；列表精确率和召回率；结构化字段准确率；或明确的研究评分标准。要求评审者说明推理过程。对于自定义评分标准，将诚实承认无法检索到内容排在自信传播错误信息之上。至少人工核查已评分试验的 10%，且涵盖成功和失败案例。引用审计应与官方基准分数分开。

根据追踪对故障分类：未发起搜索调用、证据充足但合成失败、提供商错误，或查询合理但仍未检索到内容。不要把摘录缺失或其他测试框架故障归咎于检索质量。区分账户速率限制与提供商能力限制。

根据声明的评分政策，将故障和超时纳入主要结果。限制重试次数，并计入重试所花费的全部时间和成本。报告 Search/Extract/模型费用、令牌数、调用次数、预算耗尽情况，以及搜索和端到端延迟的 p50/p95/p99。以墙钟时间衡量整个任务，包括查询改写和答案生成；不要累加并发调用的时长。每个已解决任务的成本应包含未成功试验的支出；如果没有任何任务得到解决，则将其报告为未定义。

提供可复现的配置、数据集和追踪位置、评分依据、故障细分，以及质量与成本／延迟对比。根据测得的帕累托前沿，推荐符合用户目标的配置，并说明不确定性和工作负载细分。如果未运行调用，请将交付内容标记为未执行的计划或测试框架，并说明还需完成哪些工作。

结果出来后，针对观察到的故障或瓶颈提出 2–3 个后续配置：检索未命中 → advanced；摘录内容单薄 → 启用或增加 Extract 的使用；延迟过高 → fast；模型令牌成本过高 → 缩小内容预算。每次对比只更改一个因素，记录理由，并使用新的冻结清单。将这些方案作为提议呈现，不要自动启动；只有用户在授权范围和支出额度内提出请求时，才执行这些方案。