火山引擎开源 SearchCLI：Agent 驱动搜索自迭代，多指标提升显著！

搜索调优困境与 Agent 驱动的探索

在搜索应用领域，许多项目面临调优困境。例如刚上线的商品搜索应用，搜品牌、品类和型号基本正常，但用户输入“适合通勤的轻便双肩包”，结果就会跑偏。而且，搜索参数彼此影响，一次简单修改往往同时改变召回、排序、零结果率和延迟。过去，搜索调优依赖搜索专家反复试验，但难以低成本、可复现地持续进行。于是，人们开始思考，既然 Agent 能理解目标和调用搜索，能否根据当前数据和 Query 分布，自动提出候选策略，验证收益并解释配置优势？

火山引擎的开源解决方案——SearchCLI

围绕上述问题，火山引擎在开源项目 SearchCLI 中开放了 `vs search tune`。开发者提供应用、数据集和 Query Set 后，Agent 可调用其完成 Query 校验、实验规划等一系列工作。在服饰商品、综合商品和图片内容等三个业务数据集的阶段性离线评测中，自动调优策略相较默认策略，NDCG@20 提升 11.66% - 13.50%，Precision@10 最高提升 21.17%。这表明，底层模型和数据不变时，围绕具体业务的 Query 分布重新组织相关参数，能释放可观效果空间。不过，实际收益仍取决于 Query 代表性、标签质量和业务数据分布。这种能力被称为“Agent 驱动的搜索自迭代”。

搜索自迭代的闭环与优势

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

从“会搜索”到“会把搜索变好”

一个 AI 搜索系统有多种配置参数，参数越多适配场景能力越强，但人工调优门槛也越高。真正困难的是持续回答一系列问题，如当前策略在哪些 Query 上不好等。搜索自迭代将专家工作流转化为反馈闭环：Query 与业务数据→评测当前效果→生成候选策略→执行搜索与标注→比较指标和 Bad Case→输出候选配置→人工确认后进入验证。这里的“自”由 Agent 持续驱动，“迭代”有 Query、标签和指标作为证据，生产变更保留人为边界。

为什么是 Agent + Skills + CLI？

搜索调优包含多种工作，将其拆给不同层次：Agent 负责理解目标等；Skills 提供参数语义等；SearchCLI 执行批量搜索等。例如，Agent 会先判断用户是否有真实 Query 等。CLI 的价值在于将长任务变成稳定命令和机器可读产物，保证“可复现地做完”。一次自迭代包括准备 Query Set、校验和规划、运行和复核、Agent 比较并转换配置等步骤，每一步都有结构化输入、输出和检查点。

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

搜索调优本质是实验设计问题，算法核心是决定哪些策略值得先测等。SPA 把搜索策略编码为带领域语义的 Genome，通过多保真评测、多视角 Elite、语义化进化和退火机制分配预算，选出稳定、可解释的候选策略。具体包括：Genome 需理解搜索参数语义并转化为可执行配置；初始种群从有意义的行为区域出发；多保真评测分三层，逐步提高置信度；多视角 Elite 保留多个策略前沿；语义化进化与种群退火通过特定动作生成下一代候选，退火温度控制探索幅度；鲁棒目标是寻找在 Query 分布和 Judge 噪声下稳定的策略。

实验结果与工程层保障

实验比较自动调优策略与默认策略，在三个不同业务数据集上，NDCG@20 提升 11.66% - 13.50%，NDCG@10 提升 9.56% - 15.08%，MRR@10 提升 7.74% - 14.95%，Precision@10 提升 7.36% - 21.17%。SearchCLI 重点沉淀了四类能力：Plan 提前编译实验成本；受控并发将长任务拆成小任务；标签缓存让 LLM 判断可复用；Checkpoint / Resume 中断后可接着跑。最终的 `apply` 保留安全边界，自动化不取消人的业务判断。

快速开始与开源初衷

SearchCLI 要求 Node.js 20 或更高版本，采用 Apache - 2.0 License 开源。安装 CLI 与 Viking Skills 有相应指令，Agent 可通过特定指令进行调优。项目地址为相关链接。在 Agent 时代，搜索系统问题转变，SearchCLI 用 Skills 沉淀知识，CLI 承担实验，SPA 提高预算有效性，Agent 组织成可审阅闭环。这正是开源 Agent 驱动搜索自迭代技术的初衷，未来，Viking AI 搜将推出更多能力。