火山引擎开源 Agent 驱动的搜索自迭代技术

搜索调优的现实困境

假设你刚上线一个商品搜索应用：搜品牌、品类和型号基本正常，但用户输入“适合通勤的轻便双肩包”，结果就开始跑偏。

你提高语义召回权重，长句理解变好了，精确型号词却可能变差；提高关键词匹配门槛，前几条结果更准了，零结果又开始增加；放大候选集，召回更多了，噪声和延迟也可能随之上升。

很多搜索项目都会遇到类似的调优困境。问题不是没有参数可调，而是这些参数彼此影响：一次看似简单的修改，往往同时改变召回、排序、零结果率和延迟。要判断一组策略是否真的更好，还需要准备 Query、批量搜索、相关性标注、离线评测和 Bad Case 分析。

过去，这套工作依赖搜索专家反复试验。每一轮都能做，但很难低成本、可复现地持续做。

Agent 驱动的搜索自迭代

火山引擎在开源项目 SearchCLI 中开放了 vs search tune。开发者提供应用、数据集和 Query Set 后，Agent 可以调用它完成 Query 校验、实验规划、候选策略生成、批量搜索、相关性标注、指标计算、结果对比和候选 Scene 创建。

在服饰商品、综合商品和图片内容等三个业务数据集的阶段性离线评测中，自动调优策略相较默认策略，NDCG@20 提升 11.66%～13.50%，Precision@10 最高提升 21.17%。

这组结果首先说明了一件事：底层模型和数据不变时，仅仅围绕具体业务的 Query 分布重新组织召回模式、关键词与语义权重、匹配门槛和候选规模，也能释放出可观的效果空间。以上为阶段性离线结果，实际收益仍取决于 Query 代表性、标签质量和业务数据分布。

我们把这套能力称为：Agent 驱动的搜索自迭代。

自迭代的闭环机制

“自迭代”不是让 Agent 绕过控制、直接修改线上策略，而是把“发现问题—提出假设—分配评测预算—筛选候选—验证收益—输出候选配置”变成一套可以重复运行、结果可以审阅的闭环。

Query 与业务数据 → 评测当前效果 → 生成候选策略 → 执行搜索与标注 → 比较指标和 Bad Case → 输出候选配置 → 人工确认后进入验证

这里的“自”指流程可以由 Agent 持续驱动；“迭代”指每一轮都有 Query、标签和指标作为证据。生产变更仍保留明确的人为边界。

Agent + Skills + CLI 的分层设计

搜索调优既包含上下文判断，也包含领域知识和大量确定性执行。我们将三类工作拆给不同层次：

例如，Agent 会先判断用户是否有真实 Query；没有时，才生成合成 Query 并交由用户审阅。昂贵评测前必须先执行 Plan，确认策略数、Query 数和最大标注量。最终应用策略时，也必须先 dry-run，再由用户确认是否创建候选 Scene。

一次完整调优可能包含数千次搜索请求和大量 Query-item 相关性判断。如果让 Agent 临时拼脚本，网络抖动、限流或进程中断都可能让结果丢失。CLI 的价值，是把这些长任务变成稳定命令和机器可读的运行产物，让 Agent 决定“做什么”，让执行层保证“可复现地做完”。

一次自迭代如何发生

第一步是准备 Query Set。真实搜索日志、客服问题和人工整理的典型 Query 最有价值；如果暂时没有，也可以从数据集样本生成合成 Query，但必须先展示样例和类型分布，由用户判断它们是否代表真实意图。

第二步是校验和规划。validate 会检查格式、重复 Query、类型倾斜和 sourceItemIds 覆盖率；plan 则在不调用搜索和 LLM 的情况下，提前计算策略数量、搜索请求数与最大标签量。用户可以在真正花费预算前缩小 Query Set、减少候选或先选择低成本标签。

第三步是运行和复核。CLI 对每个候选执行批量搜索，先用 Source-item 银标快速筛选，或直接使用 LLM Judge 进行语义相关性判断，再计算 NDCG、MRR、Precision、零结果率和延迟。报告不仅给出推荐策略，也保留每条 Query 的明细，方便 Agent 解释收益来自哪里、是否存在退化。

最后，Agent 可以比较不同 Run，并把确认后的推荐配置转成候选 Scene。整个过程对应 query-generate → validate → plan → run → report → compare → apply，每一步都有结构化输入、输出和检查点。

SPA：把预算花在更值得评测的策略上

搜索调优看起来像参数优化，实质上却是一个评测成本高、反馈有噪声、参数存在约束、结果还必须可解释和可落地的实验设计问题。

候选策略、Query 数量和 TopK 增加后，最坏情况下的标注量近似为：

strategy_count × query_count × topK

因此，算法的核心任务不是生成尽可能多的组合，而是决定：哪些策略值得先测，哪些应尽早淘汰，下一轮沿什么方向探索，以及何时已经有足够证据停止。

SPA（Strategy Population Annealing）把搜索策略编码为带领域语义的 Genome，以专家先验构造初始种群，通过多保真评测、多视角 Elite、语义化进化和退火机制分配预算，再用鲁棒统计选出稳定、可解释的候选策略。

SPA 的核心设计

Genome：搜索参数不是普通数值向量。

{
  "user_defined_recall_mode": "KeywordSemantic",
  "dense_weight": 0.25,
  "text_weight": 0.75,
  "query_keyword_match_percent": 0.3,
  "max_retrieved_num": 100
}

这组参数既有枚举值，也有近似连续值和请求侧参数；同时还存在约束，例如 dense_weight 与 text_weight 需要归一，不同召回模式下参数含义也不同。SPA 的交叉、变异和移动都必须先理解这些语义，生成后还要经过裁剪、归一化、合法性校验和去重，才能转化为可执行配置。

第一阶段聚焦 similarity-only：只优化召回模式、关键词/语义权重、关键词匹配比例和最大候选数，不同时调整 Rerank、个性化、热度或运营规则。这样才能把效果变化归因到文本相关性策略本身。

实验结果

实验比较自动调优策略与默认策略。在三个不同业务数据集上：

• NDCG@20 提升 11.66%～13.50%
• NDCG@10 提升 9.56%～15.08%
• MRR@10 提升 7.74%～14.95%
• Precision@10 提升 7.36%～21.17%

让算法真正可用的 CLI 工程层

算法决定评估什么，工程层决定实验能否稳定完成。SearchCLI 重点沉淀了四类能力。

Plan：先把实验成本编译出来。 vs search tune plan 不实际调用搜索或 LLM，而是提前给出 Query 数、候选策略数、预计搜索请求和最大标注量，让 Agent 在昂贵任务开始前缩小范围或调整标签来源。

受控并发：把长任务拆成小任务。 当前开源实现将评测拆为 strategy × query 任务，并采用有界批次调度；每批通过 Promise.allSettled 汇总结果，单个失败不会丢掉同批已完成的数据，也不会无限放大请求。

标签缓存：让 LLM 判断成为可复用资产。 不同策略经常召回相同 Item。SearchCLI 的缓存 Key 同时包含数据集、Query、Item 内容和 Judge 配置；只有这些信息一致时才复用，内容或评测标准变化后旧标签会自然失效。

Checkpoint / Resume：中断后接着跑。 CLI 会持续保存运行状态、搜索结果、已用标签、失败记录、中间指标和性能摘要。任务中断后，Agent 可以使用原 Run ID 继续未完成部分，不必重新支付已经完成的搜索与标注成本。

最终的 apply 也保留安全边界：先 dry-run 展示配置，获得确认后只创建新的候选 Scene，不会自动切换默认入口。自动化减少的是重复劳动，不是取消人的业务判断。

快速开始

SearchCLI 要求 Node.js 20 或更高版本，并采用 Apache-2.0 License 开源。安装 CLI 与 Viking Skills：

git clone https://github.com/volcengine/SearchCLI.git vs
cd vs
bash ./scripts/install.sh
npx skills add "https://github.com/volcengine/SearchCLI.git" -y -g

vs auth login
vs doctor --json

Agent 可以通过以下指令进行调优：

vs search tune validate --queries ./queries.jsonl --json

vs search tune plan \
  --application-id <application-id> \
  --dataset-id <dataset-id> \
  --queries ./queries.jsonl \
  --profile similarity-only \
  --optimizer spa \
  --json

vs search tune run \
  --application-id <application-id> \
  --dataset-id <dataset-id> \
  --queries ./queries.jsonl \
  --profile similarity-only \
  --optimizer spa \
  --label-source llm \
  --json

vs search tune report --run-id <run-id> --json

项目地址：https://github.com/volcengine/SearchCLI

结语

Agent 时代，搜索系统面对的问题正在从“能不能提供足够多的策略参数”，转向“能不能根据当前数据和 Query，持续找到更适合的策略”。

SearchCLI 给出的答案，是用 Skills 沉淀搜索专家知识，用 CLI 承担确定性实验，用 SPA 提高评测预算的有效性，再由 Agent 把它们组织成一个可审阅的闭环。

从“可调用”到“可评测”，从“可配置”到“可迭代”。

这正是我们开源 Agent 驱动搜索自迭代技术的初衷。