Apidog

オールインワン協働API開発プラットフォーム

API設計

APIドキュメント

APIデバッグ

APIモック

API自動テスト

アリババZeroSearchとは?Google AI検索への挑戦

Stefania Boiko

Stefania Boiko

Updated on 5月 12, 2025

本技術分析では、Alibaba Tongyi LabのZeroSearchフレームワークを検証します。これは、大規模言語モデル(LLM)が外部API呼び出しなしで検索ライクな操作を実行できるようにする、新しい強化学習アプローチです。洗練されたカリキュラムベースのトレーニング手法を採用することで、ZeroSearchは標準的なLLMを、推論能力を維持しながらドキュメント検索をシミュレートできるシステムへと変革します。本稿では、ZeroSearchのアーキテクチャ、トレーニング手法、および性能特性を技術的に詳細に解説し、従来の検索パラダイムを覆す可能性に焦点を当てます。

💡
美しいAPIドキュメントを生成する優れたAPIテストツールをお探しですか?

開発チームが最大限の生産性で共同作業できる、統合されたオールインワンプラットフォームをお探しですか?

Apidogは、お客様のすべての要求に応え、Postmanをはるかに手頃な価格で置き換えます
ボタン

システムアーキテクチャと実装

ZeroSearchの技術的基盤は、LLMが検索能力を内在化するように設計された、マルチコンポーネントアーキテクチャに基づいています。

外部検索APIをLLMと統合する従来の方式とは異なり、ZeroSearchはいくつかの主要な技術コンポーネントを備えた自己完結型のシミュレーションフレームワークを実装しています。

シミュレーションLLMの選択とデプロイ

このフレームワークは、合成検索結果を生成するために、パラメータ数の異なる(3B、7B、14B)事前学習済みシミュレーションモデルを利用しています。これらのモデルは、LLM推論に最適化された専用のサービングフレームワークであるsglangを使用してデプロイされます。デプロイ構成には、推論パフォーマンスを最適化するためのテンソル並列処理とデータ並列処理の設定が含まれます。

python -m sglang.launch_server --model-path SearchSimulation_14B --host 0.0.0.0 --tp 2 --dp 2 --port 6001

テンソル並列処理(--tp 2)とデータ並列処理(--dp 2)の設定は、モデルの重みとバッチ化されたリクエストを複数のGPUに分割する分散コンピューティングアプローチを示しており、シミュレーションフェーズ中のスループットを向上させ、レイテンシを削減します。

デュアルモードシミュレーション手法

ZeroSearchは、それぞれ特定の技術的特性を持つ2つの異なるシミュレーション手法を実装しています。

プロンプトベースシミュレーション:Qwen2.5-14B-Instructのような命令チューニングされたモデルを利用し、専門的なプロンプト技術に基づいてシミュレートされた検索結果を生成します。このアプローチは、追加のファインチューニングを必要とせずに、命令チューニングされたモデルのゼロショット能力を活用します。

ファインチューニングベースシミュレーション:検索結果生成のために特別に教師ありファインチューニングを受けた専門モデル(SearchSimulation_3B/7B/14B)を採用します。これらのモデルは、関連するドキュメントとノイズの両方の生成を含む、検索エンジンの出力の分布を模倣することを学習します。

これらのアプローチ間の技術的な区別は、トレーニングスクリプトに見られる実装パラメータに現れます。

SEARCH_MODE simulate_prompt SIMULATION_LLM Qwen2.5-14B-Instruct

対して:

SEARCH_MODE simulate_sft SIMULATION_LLM SearchSimulation_14B

強化学習トレーニングループ

ZeroSearchの核となる技術革新は、その強化学習(RL)トレーニング手法にあります。このシステムは、Generalized Reward Policy Optimization(GRPO)とProximal Policy Optimization(PPO)アルゴリズムの両方を実装しており、経験的結果によるとGRPOがより優れた安定特性を示しています。

トレーニングプロセスは、いくつかの技術パラメータによって制御されます。

  1. 難易度しきい値:カリキュラム学習アプローチでは、検索タスクの段階的な複雑さを制御するためにSTART_THRESHOLDEND_THRESHOLDパラメータを使用します。
START_THRESHOLD 0.25 END_THRESHOLD 0.5

これらの値は検索タスクの相対的な難易度を表しており、システムは堅牢な検索能力を開発するためにトレーニング中に徐々に複雑さを増していきます。

  1. トレーニングステップ構成:フレームワークは、RLトレーニングの範囲を制御するために合計ステップ数パラメータを使用します。
TOTAL_STEPS 203

これはトレーニング中に実行されるポリシー更新の数に対応しており、各ステップにはシミュレーション環境との複数のバッチインタラクションが含まれます。

技術的な実装詳細

データエンジニアリングパイプライン

ZeroSearchのトレーニングパイプラインは、Hugging Faceのデータセットリポジトリからのデータセット取得から始まります。データセット構造には、シミュレーション学習と評価の両方に使用されるクエリとドキュメントのペアが含まれている可能性が高いです。データエンジニアリングワークフローには以下が含まれます。

  1. データセットのダウンロードと前処理:
huggingface-cli download --repo-type dataset --resume-download sunhaonlp/ZeroSearch_dataset --local-dir ZeroSearch_dataset
  1. モデルチェックポイントの取得:
huggingface-cli download --resume-download sunhaonlp/SearchSimulation_14B --local-dir SearchSimulation_14B

計算要件と最適化

実装では、計算要件を管理するためにいくつかの最適化技術を活用しています。

  • Flash Attention 2flash-attnへの依存は、トレーニング中のメモリ使用量を削減し、スループットを向上させるための最適化されたアテンションメカニズムの使用を示しています。
  • マルチGPU分散:トレーニングフェーズとシミュレーションフェーズの両方がマルチGPU環境向けに設計されており、パフォーマンスを最適化するための特定の並列化戦略が採用されています。
  • vLLM統合:vLLM(v0.6.3)の使用は、シミュレーションモデルの効率的なサービングのための連続バッチ処理とPagedAttentionの実装を示唆しています。

比較分析:技術的性能指標

Zero Searchのメイン結果
Zero Searchのメイン結果
ZeroSearchと実際の検索エンジンの比較
ZeroSearchと実際の検索エンジンの比較

ZeroSearchの技術的性能は、いくつかの次元で評価できます。

1. 情報検索効率

Googleのような従来の検索エンジンは、関連するドキュメントを取得するために、転置インデックス、PageRank、およびその他の情報検索アルゴリズムを採用しています。ZeroSearchは、この外部検索を内部化されたシミュレーションに置き換え、根本的に異なる性能特性をもたらします。

レイテンシ比較:従来の検索エンジンはネットワークおよびAPIのレイテンシに直面しますが、ZeroSearchのレイテンシはモデル推論速度によって決定され、これはネットワークバウンドではなく主にGPUバウンドです。

再現率-精度トレードオフ:ZeroSearchのシミュレートされた検索は、関連するドキュメントの生成とハルシネーションリスクのバランスを取る必要があり、インデックスベースの検索とは異なる一連の最適化課題を提示します。

2. 計算コスト分析

ZeroSearchの計算プロファイルは、APIベースのアプローチとは大きく異なります。

  • トレーニング計算量:高負荷なRLトレーニング計算量への初期投資(203ステップにわたる複数のGPU使用)
  • 推論計算量:推論中のクエリあたりの計算量が多い(モデル全体の実行) vs. 軽量なAPI呼び出し
  • ストレージ要件:広範なドキュメントインデックスが不要なため、ストレージ占有領域が削減されます。

3. モデルアーキテクチャ性能

リポジトリのドキュメントは、シミュレーションモデルアーキテクチャ間での性能変動を示しています。

  • 14Bパラメータのシミュレーションモデルは、より小さいバリアントよりも優れています。
  • GRPOトレーニングは、PPOと比較して優れた安定性を示します。
  • カリキュラム学習パラメータは、最終的なモデル性能に大きく影響します。

技術的な制限と研究課題

いくつかの技術的な制限が、継続的な研究課題を提示しています。

1. 知識カットオフの制約

リアルタイムのウェブデータにアクセスするAPIベースの検索システムとは異なり、ZeroSearchは基盤となるLLMの知識カットオフによって制約を受けます。これは、急速に変化する情報やモデルトレーニング後に現れる情報にとって、重大な技術的課題となります。

2. ハルシネーションの軽減

このフレームワークは、ドキュメント生成中のハルシネーションを防ぐための洗練された技術を実装する必要があります。創造的なドキュメント合成と事実の正確さのバランスは、アーキテクチャにおける重要な技術的課題です。

3. パラメータ効率の最適化

現在の実装では、効果的なシミュレーションのために比較的大きなモデル(3B〜14Bパラメータ)が必要です。パラメータ効率の高いアーキテクチャに関する研究は、性能を維持しながら計算要件を削減できる可能性があります。

今後の技術的な方向性

ZeroSearchアーキテクチャから、いくつかの有望な技術的な方向性が生まれています。

1. 検索拡張生成ハイブリッドアプローチ

将来のイテレーションでは、シミュレートされた検索と、信頼度が特定のしきい値を下回った場合の疎な実際のAPI呼び出しを組み合わせたハイブリッドアプローチを実装できます。これにより、両方のアプローチの強みを活用する適応システムが作成されます。

2. ドメイン固有のシミュレーションチューニング

フレームワークのアーキテクチャは、特定のドメイン向けにシミュレーションモデルをファインチューニングすることをサポートしており、技術分野、法律文書検索、医療情報アクセスなどの専門的な検索機能を作成できる可能性があります。

3. 量子化と最適化

GPTQやAWQのような量子化技術の実装により、シミュレーションモデルとターゲットモデルの両方の計算要件を削減し、エッジデバイスやリソースに制約のある環境へのデプロイを可能にできます。

技術的な実装コード分析

トレーニングスクリプトの実装は、いくつかの重要なアーキテクチャ上の決定を明らかにしています。

bash train_grpo.sh NUM_GPUS_PER_NODE 4 MODEL_PATH Llama-3.2-3B DATA_PATH ZeroSearch_dataset TOTAL_STEPS 203 IP localhost SEARCH_MODE simulate_prompt SIMULATION_LLM Qwen2.5-14B-Instruct START_THRESHOLD 0.25 END_THRESHOLD 0.5

この実装は以下を示しています。

  1. マルチGPUトレーニング(ノードあたり4つのGPU)
  2. ターゲットモデルとしてのLlama-3.2-3Bの使用
  3. Qwen2.5-14B-Instructを使用したプロンプトベースシミュレーション
  4. 段階的な難易度(0.25 → 0.5)によるカリキュラム学習

GRPOとPPOの両方の実装スクリプトが存在することは、GRPOの優れた安定特性を決定する前に、アーキテクチャが複数のRLアルゴリズムで評価されたことを示唆しています。

結論

ZeroSearchは、検索ドメインにおける重要な技術革新であり、LLMが外部API呼び出しなしでドキュメント検索をシミュレートできるようにする洗練された強化学習アーキテクチャを実装しています。カリキュラム学習、デュアルモードシミュレーション、および高度なRLアルゴリズムを活用することで、このフレームワークは、API依存性を排除しながら、実際の検索エンジンベースのモデルを上回ると報告されている性能を達成しています。

この技術アーキテクチャは、APIコストゼロ、強化されたプライバシー機能、柔軟なデプロイオプションなど、いくつかの利点を示しています。しかし、知識カットオフ、ハルシネーションリスク、計算効率への対応には課題が残っています。

この分野が進化するにつれて、ZeroSearchの技術的アプローチは、言語モデル内で検索能力をどのように内在化できるかについての貴重な洞察を提供し、検索アーキテクチャに対する私たちの理解を再構築する可能性があります。オープンソースの実装は、さらなる研究と最適化、特に従来の検索エンジンが期待通りの性能を発揮しない場合やプライバシー上の懸念がある専門ドメインにおいて、基盤を提供します。

次世代の情報検索システムに関心のある研究者や実務家にとって、ZeroSearchは慎重な検討と継続的な開発に値する、説得力のある技術的設計図を提供します。