火山引擎、エージェント駆動の検索自迭代技術をオープンソース化

火山引擎 AI 搜索 | 2026-07-29 18:00 北京

能够调用搜索功能，只是 Agent 实现智能搜索的第一步。真正的挑战在于：当搜索结果不理想时，系统能否自动找到改进方向，并通过多轮实验持续优化搜索效果？

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

此时若提高语义召回权重，长句的理解能力确实会提升，但精确匹配型号词的能力却可能下降；若提高关键词匹配的门槛，前几条结果的精准度会上去，零结果的数量反而会增加；若扩大候选集范围，召回率提高了，噪声和延迟也可能随之上升。

许多搜索项目都会陷入类似的调优困境。问题不在于没有参数可调，而在于这些参数彼此牵制：一次看似简单的修改，往往同时影响召回率、排序质量、零结果率和响应延迟。要判断一组策略是否真的有效，还需要准备 Query 集合、批量搜索任务、相关性标注数据、离线评测体系以及 Bad Case 分析。

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

于是我们开始思考：既然 Agent 已经能够理解目标并调用搜索功能，它能否再向前一步——根据当前数据和 Query 分布，自动提出候选策略，通过实验验证收益，并向开发者解释“为什么这组配置更好”？

围绕这一目标，火山引擎在开源项目 SearchCLI 中推出了 vs search tune。开发者只需提供应用、数据集和 Query Set，Agent 即可调用该工具完成 Query 校验、实验规划、候选策略生成、批量搜索执行、相关性标注、指标计算、结果对比以及候选场景创建等一系列工作。

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

这一结果首先说明了一个重要事实：在底层模型和数据保持不变的前提下，仅针对具体业务的 Query 分布重新组织召回模式、调整关键词与语义权重、设定匹配门槛及候选规模，依然能释放出可观的效果空间。当然，上述为阶段性离线测试结果，实际收益仍取决于 Query 的代表性、标签质量以及业务数据的分布情况。

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

所谓“自迭代”，并非让 Agent 绕过管控直接修改线上策略，而是将“发现问题—提出假设—分配评测预算—筛选候选—验证收益—输出候选配置”这一系列动作，转化为可重复运行且结果可审阅的闭环流程。

接下来，我们将拆解这套闭环如何运转，以及背后的 SPA 策略优化框架如何在有限的搜索和标注预算下，把更多实验机会留给真正有潜力的策略。

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

一个 AI 搜索系统通常包含召回模式、关键词与语义权重、关键词匹配门槛、候选集规模等配置。参数越多，适配不同场景的能力越强，但人工调优的门槛也随之提高。

真正困难的并非修改某一个参数，而是持续回答：当前策略在哪些 Query 上表现不佳？应该加强关键词还是语义召回？平均指标的提升是否掩盖了某类 Query 的退化？新策略是否会增加零结果和延迟？

搜索自迭代将这套专家工作流转化为一个反馈闭环：

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

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

二、为什么是 Agent + Skills + CLI？

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

例えば、Agent はまずユーザーのクエリが実在するかを判断します。もしクエリが存在しない場合は、合成されたクエリを生成し、ユーザーに確認を求めます。コストのかかる評価を行う前には必ず Plan（計画）を実行し、戦略の数やクエリの数、最大ラベル数を確定させる必要があります。最終的に戦略を適用する際も、まずは dry-run（事前実行）を行い、その結果をユーザーが確認した上で候補となる Scene の作成を許可します。

一度の完全なチューニングには、数千回の検索リクエストと大量の Query-item 関連性判断が含まれる可能性があります。もし Agent が都度スクリプトを組み立てるような方式だと、ネットワークの揺らぎやレート制限、プロセスの中断などが原因で結果が失われてしまうリスクがあります。CLI の価値は、こうした長期間にわたるタスクを安定したコマンドと機械可読な実行成果物に変換することにあります。これにより、Agent は「何をすべきか」を決定し、実行層は「再現性を持って完了させること」を保証します。

1. 自迭代（自己改善）の仕組み

最初のステップは Query Set の準備です。実際の検索ログやカスタマーサポートからの問い合わせ、そして人手で整理された典型的なクエリが最も価値があります。もしこれらがすぐに用意できない場合は、データセットのサンプルから合成クエリを生成することも可能です。ただしその際は、まずサンプルとタイプ分布を示し、ユーザーにそれらが真の意図を代表しているかどうかを確認してもらう必要があります。

2 つ目のステップは検証と計画です。validate（検証）機能は、フォーマット、重複するクエリ、タイプの偏り、そして sourceItemIds のカバレッジをチェックします。一方、plan（計画）機能は、検索や LLM を呼び出すことなく事前に戦略の数、検索リクエスト数、最大ラベル数を計算します。ユーザーは実際に予算を投じる前に、Query Set を絞り込んだり、候補を減らしたり、低コストのラベルを選択したりできます。

3 つ目のステップは実行とレビューです。CLI は各候補に対してバッチ検索を実行し、まず Source-item の銀標（正解データ）を使って素早くフィルタリングするか、あるいは LLM Judge を用いて意味的な関連性を判断します。その後、NDCG、MRR、Precision、ゼロ結果率、レイテンシなどを計算します。レポートには推奨戦略だけでなく、各クエリの詳細も含まれており、Agent が収益がどこから生まれたのかを説明したり、性能の低下がないかを確認したりするのに役立ちます。

最後に、Agent は異なる Run（実行）を比較し、承認された推奨設定を候補となる Scene として転記します。この一連のプロセスは「query-generate → validate → plan → run → report → compare → apply」に対応しており、各ステップには構造化された入力・出力とチェックポイントが用意されています。

三、SPA：予算をより価値のある戦略評価に集中させる

検索チューニングは一見するとパラメータ最適化のように見えますが、実際には評価コストが高く、フィードバックにノイズが含まれ、パラメータに制約があり、結果の説明可能性と実装性が求められる実験設計の問題です。

候補となる戦略の数、クエリの数、TopK が増加した場合、最悪ケースでのラベル数はおよそ以下の式で表されます：

strategy_count × query_count × topK

したがって、アルゴリズムの核心任務は、可能な限り多くの組み合わせを生成することではなく、「どの戦略を先に評価すべきか」「いつ早期に淘汰すべきか」「次の探索方向はどこか」、そして「十分な証拠が揃ったと判断していつ停止すべきか」を決定することにあります。

SPA（Strategy Population Annealing）では、検索戦略をドメインの意味を持つゲノムとしてエンコードします。専門家の事前知識を用いて初期個体群を構築し、マルチファジリティ評価、多角的な Elite 選抜、意味的な進化、そして退火メカニズムによる予算配分を行います。最後に堅牢な統計手法を用いて、安定性が高く説明可能な候補戦略を選出します。

1. 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（重排序）、个性化推荐、热度加权或运营规则。这样做的目的是确保效果的变化能明确归因于文本相关性策略本身的改进。

2. 初始种群：覆盖搜索行为特征，而非平均撒点

传统的 Matrix Optimizer 会在若干固定档位上组合参数。这种方法虽然简单稳定，但存在明显缺陷：不同参数的组合未必能产生差异化的搜索行为，有限的预算极易被大量相似或低价值的组合所占用。

SPA 的初始种群设计则更具策略性，由当前在线策略、默认基线（Baseline）、边界策略（如仅关键词 KeywordOnly / 仅语义 SemanticOnly）、粗粒度矩阵搜索结果以及行业先验知识共同构成。具体而言：

• 商品搜索场景可保留更多以关键词为主导的混合策略；
• 知识库问答场景则应保留更多语义增强的分支。

算法从具有实际意义的行为区域出发，而非从零散的随机点开始探索。

当前开源的首版已实现了这一层逻辑：基于多个代表性中心点，建立粗、细两种搜索半径，生成边界、中心和邻域候选解，随后执行合法化与去重。其中，粗粒度邻域用于判断优化方向，细粒度邻域则用于比较局部差异。

3. 多保真评测：先排除错误方向，再提升置信度

完整的评测体系分为三层设计：

如果一个策略连生成 Query 的源 Item（原始商品）都无法召回，就没有必要继续为其 Top20 结果支付昂贵的 LLM（大语言模型）标注成本。反之，Fast Pass（快速通道）的高分也不能直接判定胜出：它必须证明收益并非仅集中在标题改写等少数特定 Query 类型上。

4. 多视角精英策略：保留一条前沿策略

単に平均 NDCG で上位 N を選定するのは危険です。ある戦略は短語のクエリでは強力でも、自然言語クエリでは著しく性能が低下する可能性があります。一方で、平均スコアがわずかに低い戦略であっても、ゼロ結果率やレイテンシ、クエリタイプごとのパフォーマンスにおいてより安定しているケースがあります。

そのため SPA（Search Population Algorithm）は、Global Best（全体最適）、Query-Type Best（クエリタイプ別最適）、Stable Best（安定性重視）、Low-Latency Best（低遅延重視）、Low-Zero-Result Best（ゼロ結果率低減）、Baseline-Improver（ベースライン改善型）、そして十分な差異を持つ Diverse Candidate（多様な候補）の 7 つを同時に保持します。各 Elite は「なぜこの戦略がさらに予算を消費する価値があるのか」という問いに答える必要があります。これにより、単一のランキングよりもはるかに効果的に、個体群の早期収束を防ぐことができます。

1. セマンティックな進化と種群の冷却（アニーリング）

次世代の候補は 3 つの操作によって生成されます。「交叉」では、2 つの Elite から検証済みの有効な構造を組み合わせます。例えば、戦略 A のキーワードやセマンティック重み付けと、戦略 B のキーワード閾値を融合させるようなケースです。「局所変異」では、優秀な戦略の周辺で重みや候補数、マッチング比率などを微調整します。「方向移動」は、候補をグローバル最適解や特定のクエリタイプにおけるローカル最適解へと近づけるための操作です。

これらの操作が単に JSON をランダムに組み合わせているわけではありません。例えば、キーワード閾値が高すぎてゼロ結果が増加した場合は、次世代で閾値を下げる方向へ調整します。また、候補数を 100 から 200 に増やしても性能向上が見られず、レイテンシだけが増大する場合は、検索規模を小さくする方向へと収束させます。

冷却温度（アニーリング温度）は探索の幅を制御します。初期段階では温度が高く、わずかに劣るが差異の大きい戦略も許容します。中期には Elite の周辺で交叉と変異を行いながら、境界領域のプローブも維持します。後期になると温度を下げて、高価値な領域での微調整に集中します。単点のシミュレーテッド・アニーリングとは異なり、SPA は複数の戦略分岐を同時に保持するため、ローカル最適解から脱出できると同時に、一度のランダム移動によって大きく逸れるリスクも低減されます。

1. 頑健性の確保：一発の高スコアに騙されない

RobustScore（頑健性スコア）は以下の式で計算されます。

NDCG@20

+ α × MRR@10

• β × zero_result_rate
• γ × latency_penalty
• δ × query_type_variance
• ε × confidence_interval_width

NDCG は全体としてのソート品質を、MRR は最初の関連結果の位置を重視して評価します。ゼロ結果率とレイテンシは実運用上の制約であり、クエリタイプごとの分散（Variance）は「一部のタイプでのみ性能が高い」戦略をペナルティとして扱います。信頼区間は Bootstrap 法によって算出されます。クエリセットに対して多次再サンプリングを行い、平均値が高くても信頼区間が広い場合、それは単にその特定のクエリセットで偶然良い結果が出ただけである可能性を示唆します。

つまり、完全な SPA が目指すのは、一度の実験における最高スコアではなく、クエリの分布や評価ノイズが存在する状況下でも安定して機能する戦略です。

四、実験結果

自動チューニング戦略とデフォルト戦略を比較したところ、3 つの異なるビジネスデータセットにおいて以下の改善が確認されました。

• 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 は主に 4 つの能力を蓄積・提供しています。

Plan（計画）：まず実験コストを見積もります。「vs search tune plan」コマンドを実行すると、実際の検索や LLM の呼び出しを行わずに、クエリ数、候補戦略数、予想される検索リクエスト数、最大ラベル付け量を事前に提示します。これにより、Agent は高コストなタスクを開始する前に範囲を絞り込んだり、ラベルソースを調整したりすることが可能になります。

制御された並行処理：長時間かかるタスクを小分けにします。現在のオープンソース実装では、評価プロセスを「戦略 × クエリ」の単位で分割し、バッチサイズを制限したスケジューリングを採用しています。各バッチは Promise.allSettled を用いて結果を集約するため、1 つのタスクが失敗しても、そのバッチ内で完了したデータは失われず、リクエスト数が無限に増大することもありません。タスクキューとワーカープールについては、今後の拡張・進化の余地を残しています。

ラベルのキャッシュ：LLM の判断を再利用可能な資産に

異なる戦略で同じアイテムが頻繁に検索されるケースがあります。SearchCLI では、キャッシュキーにデータセット、クエリ、Item 内容、そして評価設定（Judge 設定）のすべてを含めています。これらすべての要素が一致した場合のみキャッシュが利用され、コンテンツや評価基準が変われば自動的に旧ラベルが無効化されます。この仕組みにより、コスト削減を実現しつつ、過去の結果を誤って再利用するリスクを防ぎます。

チェックポイントと再開機能：中断から続きから実行可能

CLI は、実行状態、検索結果、使用済みのラベル、失敗記録、中間指標、性能サマリーなどを継続的に保存します。タスクが中断しても、元の Run ID を指定することで未完了部分をそのまま引き継ぎ、既に完了した検索やラベリングのコストを再支払いする必要はありません。

最終的な適用（apply）にも安全策を設けています：まず dry-run で設定内容を確認し、ユーザーの承認を得てから新しい候補シーンを追加するだけで、デフォルトのエントリーポイントへの自動切り替えは行われません。自動化によって削減されるのは反復作業であり、人間の業務判断が不要になるわけではありません。

六、クイックスタート

SearchCLI は Node.js 20 以降を必要とし、Apache-2.0 ライセンスでオープンソース化されています。CLI と Viking Skills のインストール手順は以下の通りです。

git clone git@github.com:volcengine/SearchCLI.git vs

cd vs

bash ./scripts/install.sh

npx skills add "git@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 \

--dataset-id \

--queries ./queries.jsonl \

--profile similarity-only \

--optimizer spa \

--json

vs search tune run \

--application-id \

--dataset-id \

--queries ./queries.jsonl \

--profile similarity-only \

--optimizer spa \

--label-source llm \

--json

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

プロジェクトの GitHub リポジトリ：https://github.com/volcengine/SearchCLI

結び

Agent が主流となる時代、検索システムが直面する課題は、「十分な数の戦略パラメータを提供できるか」から、「現在のデータとクエリに基づいて、より適切な戦略を継続的に見つけ出せるか」へと変化しています。

SearchCLI が示す答えは、Skills で検索の専門知識を蓄積し、CLI で確定的な実験を担い、SPA（Search Performance Analyzer）で評価予算の有効性を高め、Agent によってこれらを検証可能なクローズドループに組織化することです。

「呼び出し可能」から「評価可能」へ、「設定可能」から「反復可能」へ。

これが、私たちが Agent ドライブ型の検索自迭代技術をオープンソース化した初衷です。

今後、Viking AI 検索はさらに多くの機能を追加し、皆様と共に検索をよりシンプルにし、自迭代の取り組みを継続して前進させていきます！

WeChat で開くにはこちらへ