この記事ではAIエージェントに特化して解説します。AIエージェント全般は AIエージェントフレームワーク比較2026年版 をご覧ください。
何が起きたか
ベクトルデータベース企業のChromaが、自己編集機能を持つサーチエージェント「Context-1」の研究論文を公開した。gpt-oss-20Bベースの20Bパラメータモデルで、MXFP4量子化によりNvidia B200上で400〜500 tok/sのスループットを実現する。Chroma自身の発表によれば、フロンティアスケールのLLMと比較して10倍以上安価でありながら、同等以上の検索精度を達成している。
従来のRAGシステムはクエリを1回実行して結果を返す「シングルパス」モデルが主流だった。Context-1はこれを根本から変え、検索と推論を反復させながら最終回答に収束させる設計を採用した。RAGFlowのようなドキュメント解析RAGと組み合わせることで、複雑な多段階クエリへの対応力が大幅に向上する可能性がある。
3フェーズのアーキテクチャ詳解
Context-1の動作は3つのフェーズで構成される。それぞれが独立した技術的革新を持ち、組み合わせることで従来の検索手法を大きく上回るパフォーマンスを実現している。
フェーズ1:クエリ分解(Query Decomposition)
複雑な質問を複数のサブクエリに自動分解し、それぞれに対して独立した検索を実行する。1ターンあたりの平均並列ツールコール数は2.56回(ベースモデルの1.52回から68%増加)。
例えば「2024年のAI規制が欧州スタートアップの資金調達に与えた影響」というクエリは、「EU AI Act 2024年施行内容」「欧州スタートアップ資金調達2024年統計」「AI規制と投資家心理の関係」の3サブクエリに分解されて並列実行される。
フェーズ2:反復的検索(Iterative Search)
各検索ステップで得た情報を基に次の検索戦略を動的に調整する。初回の検索結果が不十分であれば、追加のサブクエリを生成して深掘りする。平均探索ターン数は5.2回(ベースモデルの6.7回から22%短縮)。
ターン数が減少したのは「無駄な探索をしなくなった」ことを意味する。より少ない探索ステップで答えに到達できるよう、強化学習によって探索効率が最適化されている。
フェーズ3:コンテキスト自己編集(Context Self-Editing)
複数ターンの検索で蓄積したドキュメントから、最終回答に不要なものを自動的に剪定(pruning)する。これにより、次のターンの検索に使えるコンテキスト容量を確保しながら、回答の精度を維持する。剪定精度(pruning precision)は0.941(ベースモデルの0.824から14%向上)。
この自己編集フェーズがContext-1の核心だ。コンテキストウィンドウの物理的な制限がある中で、「何を保持し何を捨てるか」をモデル自身が判断する。
検索パイプライン全体の流れ
(平均2.56サブクエリ) loop 平均5.2ターン(反復検索) C1->>S: 並列サブクエリ実行 S-->>C1: 検索結果返却 C1->>K: 結果をコンテキストに追加 C1->>K: フェーズ3: 不要ドキュメントを剪定
(精度0.941) C1->>C1: 回答が十分か判定 end C1-->>U: 最終回答を生成
ベンチマーク結果の詳細
Context-1は4つのドメインで評価されており、いずれも強い結果を示している。
| ドメイン | 評価指標 | Context-1スコア | ベースモデル | 備考 |
|---|---|---|---|---|
| BrowseComp-Plus | 最終回答発見率 | 0.87 | — | 複雑なWeb検索タスク |
| Web検索 | 最終回答発見率 | 0.88 | — | 一般Web情報検索 |
| Web検索 | F1スコア(4xアンサンブル) | 0.82 | — | アンサンブル時の精度 |
| 金融 | 難易度別精度 | 競合的 | — | 訓練データあり |
| 法務・メール | 汎化性能 | 限定訓練で強い汎化 | — | ドメイン外への転移 |
BrowseComp-Plusは複数ステップの推論と検索を組み合わせた難易度の高いベンチマークだ。0.87というスコアは、多くのフロンティアLLMと比較しても遜色ない水準だとChromaは主張している。
訓練手法:SFTウォームアップとCISPO
Context-1の訓練は2段階で行われた。
第1段階:Kimi K2.5によるSFTウォームアップ
まずKimi K2.5を教師として教師あり微調整(SFT)を実施する。これにより検索タスクの基本的なパターンをモデルに学習させる。SFTの訓練データはWeb、金融、法務、メールの4ドメインの合成タスクで生成されており、人間の判断との一致率80%以上を達成している。
第2段階:CISPOによる強化学習
CISPOはGRPO(Group Relative Policy Optimization)の変種で、検索エージェントの探索効率と回答精度を同時に最適化する。報酬信号には「最終回答の正確性」だけでなく「探索ターン数の効率」も組み込まれており、これが平均探索ターン数の短縮につながっている。
Chromaのビジョン:「検索特化エージェント」という新しいカテゴリ
ChromaがContext-1で示そうとしているのは、単なる性能改善ではない。「検索に特化した小型エージェント」という新しいカテゴリの提案だ。
フロンティアLLM(GPT-4o、Claude 3.7 Sonnetなど)は汎用性が高い反面、検索タスクでは過剰なスペックになりやすい。Context-1は検索に特化することで、同等の検索精度をはるかに低いコストで実現する。フロンティアモデルを「オーケストレーター」として、Context-1を「検索サブエージェント」として使い分けるアーキテクチャが想定されている。
# Context-1をサブエージェントとして利用する概念的な統合例
# (Chroma公式APIは研究公開段階のため、実装詳細は今後変わる可能性あり)
import chromadb
from chromadb.agents import Context1Agent # 仮の将来API
# Chromaクライアントの初期化
client = chromadb.Client()
collection = client.get_or_create_collection("knowledge_base")
# コレクションにドキュメントを追加
collection.add(
documents=[
"AI規制に関する欧州議会の2024年決議...",
"スタートアップ資金調達の2024年統計レポート...",
"機関投資家のAI分野投資動向...",
],
ids=["doc1", "doc2", "doc3"]
)
# Context-1エージェントによる反復検索
agent = Context1Agent(collection=collection)
result = agent.search(
query="2024年のAI規制が欧州スタートアップの資金調達に与えた影響",
max_turns=8, # 最大探索ターン数
parallel_queries=3, # 並列サブクエリ数
pruning_threshold=0.9 # コンテキスト剪定の閾値
)
print(result.answer)
print(f"探索ターン数: {result.turns_used}") # 平均5.2
print(f"使用サブクエリ数: {result.total_queries}")
# より低レベルなChroma APIを使った現行の使い方
import chromadb
client = chromadb.Client()
collection = client.get_or_create_collection(
name="documents",
metadata={"hnsw:space": "cosine"}
)
# クエリ実行(現行API)
results = collection.query(
query_texts=["AI規制と資金調達の関係"],
n_results=10,
include=["documents", "distances", "metadatas"]
)
# 手動での反復検索ループ(Context-1が自動化する部分)
for i, doc in enumerate(results["documents"][0]):
print(f"ランク{i+1}: {doc[:100]}...")
競合ベクトルDBとの比較
Context-1の登場により、ベクトルDB各社の検索エージェント機能の差が明確になってきた。
| ベンダー/手法 | 反復検索 | クエリ分解 | コンテキスト自己編集 | スループット | オープン度 |
|---|---|---|---|---|---|
| Chroma Context-1 | 5.2ターン平均 | 2.56並列 | pruning精度0.941 | 400〜500 tok/s (B200) | 研究公開 |
| Pinecone | なし(シングルパス) | なし | なし | スケール重視 | クローズド |
| Weaviate | 限定的 | なし(Hybrid Search止まり) | なし | 中程度 | オープンソース |
| Milvus | なし | なし | なし | 高スループット | オープンソース |
| 標準RAG(LangChain) | ループ実装は可能 | 手動設定 | なし | モデル依存 | オープンソース |
| Rerank API | なし | なし | なし | 高速 | APIのみ |
RAGFlowのようなドキュメントパース特化のRAGシステムは複雑なドキュメント構造の解析に強みがあるが、クエリの反復的最適化という点ではContext-1が新しい次元を開いている。両者は補完関係にあると言えるだろう。
MXFP4量子化と推論コストの関係
Context-1のコスト競争力を支えるのがMXFP4(Microscaling Float Point 4-bit)量子化だ。
MXFP4は従来のINT4よりも精度劣化が少なく、FP16と比べて4倍のメモリ効率を持つ。Nvidia B200アーキテクチャはMXFP4をネイティブサポートしており、400〜500 tok/sというスループットはこの組み合わせによって実現されている。
・複数ドキュメントにまたがるマルチホップ質問応答
・金融レポートや法律文書などの専門ドメイン検索
・フロンティアLLMのAPIコストが問題になっているRAGパイプライン
・エージェント型システムの「検索サブエージェント」として
・BrowseComp系のWeb調査タスクの自動化
エンジニアへの影響
RAGシステムの精度改善
反復検索とコンテキスト自己編集により、複数ドキュメントにまたがる複雑な質問への回答精度が向上する。従来型RAGが苦手とする「答えが複数のドキュメントに分散している」ケースに特に有効だ。
推論コスト削減
Chroma発表の「フロンティアLLM比10倍安価」が実際のプロダクション環境でも成立するなら、検索ヘビーなアプリケーションのコスト構造が変わる。月次の検索API費用が大きい企業には特に重要な選択肢になる。
サブエージェントアーキテクチャへの示唆
大型の汎用モデルを1つ使うのではなく、タスク特化の小型モデルを組み合わせるアーキテクチャが現実的な選択肢として浮上してきた。OpenHandsのようなAIコーディングエージェントがコードに特化しているように、Context-1は検索に特化することで効率を最大化する。
ドメイン汎化の実証
4ドメイン(Web、金融、法務、メール)の合成データで訓練して未訓練ドメインへの汎化を示したことは、カスタムドメインへの適用可能性を示唆している。企業固有のナレッジベース検索への応用が期待される。