Chroma Context-1、フロンティアLLMと同等の検索性能を20Bパラメータで実現
RAGの標準的な実装は「1回のクエリで類似ドキュメントを取得し、それをコンテキストに詰めてLLMに渡す」シングルパス構造だ。Difyで社内ヘルプデスクを構築した話でも触れたが、実用上はGraphRAGやリランキングで精度を上げていく流れになる。ただ、シングルパスの根本的な弱点は残る。「あるドキュメントを読んで初めて次のクエリが決まる」マルチホップな質問に対して構造的に対処できない。
フロンティアLLMをエージェントとして使えばマルチホップ検索は解決できる。NeMo RetrieverのアジェンティックRAGがReACTループで示したように、LLMが検索クエリを反復改善しながら必要な情報を段階的に収集するアプローチだ。ただしフロンティアモデルのコストとレイテンシは本番運用では重い。
Chromaが2026年3月26日に公開したContext-1はこのコスト問題を直撃する。gpt-oss-20Bをベースにした20Bパラメータの検索特化エージェントモデルで、自己編集型コンテキスト管理機構をRLで学習させた。重みはApache 2.0でオープン公開されている。
自己編集コンテキストとは何か
エージェントが検索を繰り返すと、取得済みドキュメントがコンテキストウィンドウに蓄積し続ける。Claudeの1Mコンテキストのようにウィンドウ自体が広がっても、雑音に埋もれて精度が下がる問題（context rot）は解消しない。この問題に対するアプローチはいくつか出てきている。
| アプローチ | 代表例 | 仕組み |
|---|---|---|
| 外部プロキシ型 | Compresr Context Gateway | エージェントとLLM APIの間にプロキシを挟み、先読み要約やツール出力圧縮でトークンを削減 |
| ウィンドウ拡張型 | Claude 1M, Gemini 2M | コンテキストウィンドウ自体を大きくして蓄積に耐える |
| モデル内蔵型 | Context-1 | モデル自身が不要なパッセージを積極的に削除する |
Context-1は3番目の「モデル内蔵型」だ。エージェントが使えるツールは4種類で構成されている。
| ツール | 説明 |
|---|---|
search_corpus(query) | BM25と密ベクトルのハイブリッド検索。RRFで融合後、リランカーを通して上位チャンクを返す |
grep_corpus(pattern) | Regex検索。最大5チャンク返却 |
read_document(doc_id) | ドキュメント全文読み込み |
prune_chunks(chunk_ids) | 指定チャンクをコンテキストから除去 |
search_corpus が使っているBM25は転置インデックスに基づく古典的なランキング関数で、TF-IDFの発展形にあたる。密ベクトル検索と組み合わせるハイブリッド構成は現在のRAGで広く採用されており、BM25がキーワードの正確な一致を拾い、密ベクトルが意味的な類似性をカバーする。RRF（Reciprocal Rank Fusion）は複数の検索結果リストを順位の逆数で統合するアルゴリズムで、NeMo Retrieverのパイプラインでもフォールバックとして使われていたものと同じだ。
4番目の prune_chunks が核心になる。検索を重ねながら不要と判断したチャンクを削除し、コンテキストウィンドウを常にクリーンに保つ。学習時には「プルーニング後のチャンクも報酬計算の対象に含める」設計で、削除の精度も最適化対象になっている。
flowchart TD
A[クエリ入力] --> B[search_corpus / grep_corpus<br/>で情報収集]
B --> C{必要な情報が<br/>揃ったか?}
C -- 不十分 --> D[read_documentで<br/>詳細読み込み]
D --> E[prune_chunksで<br/>不要チャンク削除]
E --> F[トークン使用量を<br/>トラジェクトリに追記]
F --> B
C -- 十分 --> G[最終回答生成]
H[ソフト閾値超過] -.-> E
I[ハードカットオフ到達] -.-> J[prune以外の<br/>ツールコール拒否]トークンバジェット管理も組み込まれている。ターンごとに使用量をトラジェクトリに追記し（[Token usage: 14,203/32,768]）、ソフト閾値を超えたらプルーニングか最終回答の生成を促し、ハードカットオフではprune以外のツールコールを拒否する。
合成データ生成パイプライン
人手アノテーションに頼らないスケーラブルなタスク生成が設計の要だ。4ドメインでデータを生成している。
| ドメイン | データソース | チャンク規模 |
|---|---|---|
| Web | Wikipediaタイトルをシードに、SerperとJina AI Readerで収集 | 大規模 |
| Finance | 2025年SEC提出書類1707社（10-K, 20-F） | 大規模 |
| Legal | USPTO特許公報2026年1月〜1500件。§102/§103拒絶引用 | 中規模 |
| Epsteinファイル（2025年11月公開）＋Enronメール、984ユニークスレッド | 拡張後396,510チャンク |
Emailドメインは特殊で、Epsteinコーパス単独では小さすぎるため、Enronメールの名前・日付を置換してデータ拡張した。これによりチャンク数が1,366から396,510に増えた。
タスク生成の品質担保にはExtraction-based Verificationを使っている。LLMに「supporting documentからの原文引用（document_quotes）」と「clueからの対応箇所（clue_quotes）」の両方を抽出させ、正規化してマッチを確認する手法だ。人手ラベルとの一致率はWebで84.40%、Financeで93%、Emailで87.5%を示している。
強化学習の設計
SFT段階
大型モデル（Kimi K2.5など）でエージェントループを実行してSFTトラジェクトリを生成する。失敗トラジェクトリも学習データに含める（分布特性が精度より重要という判断）。フィルタリング基準は以下のとおり。
- trajectory recall > 50% かつ output recall > 40% → 全量使用
- 低リコールは確率的に含める
- ゼロリコールは最大5%（失敗モードの露出）
- trajectory recall >> output recall の乖離は除外（探索と選択の乖離を強化しないため）
RL段階: CISPOアルゴリズム
ベースモデルはgpt-oss-20b（LoRA適用）。アルゴリズムにはGRPOの変形であるCISPOを使用する。
16のオープンソースRLライブラリ比較で整理したように、現在のLLM向けRLはGRPOファミリーが主流になっている。GRPOはグループ内の相対的な報酬差で方策を更新するアルゴリズムで、PPOのようにクリティックモデルが不要なため計算効率が高い。Context-1のCISPOはその変形で、重要度サンプリング重みがクリップ範囲外になったときの処理が異なる。GRPOでは「ゼロ勾配」になるところを、CISPOでは「デタッチした係数でスケーリング」する。これによりプルーニング決定やクエリ改変のようなレアなトークン列も学習に貢献できる。
DRGRPOのunbiased lossやDAPOのclip-higherも試したが、CISPOが最も安定したと報告されている。
各学習ステップで128クエリをサンプルし、クエリごとに8つの独立環境でロールアウトする（1024トラジェクトリ/ステップ）。全8ロールアウトが同一報酬になったステップは廃棄する（グループ内正規化で勾配がゼロになるため）。
報酬は5成分から構成される。
| 報酬コンポーネント | 内容 |
|---|---|
| アウトカム報酬 | Fβスコア（β初期値はrecall 16倍重視。エポックをまたいでrecall 4倍までアニーリング） |
| プロセス報酬 | trajectory recall（探索中に正解に到達したか） |
| ファイナルアンサーボーナス | 正解を含むチャンクを取得で +1.0 |
| 繰り返しプルーニングペナルティ | 3回超の連続prune呼び出しに0.1/回（上限0.5） |
| ターン数ペナルティ | 64〜128ターンで0→0.5に線形増加 |
2段階カリキュラムで学習する。フェーズ1は低難度（少ないホップ数）、フェーズ2は高難度（多ホップ）という難易度カリキュラムと、エポック間でFβのβをrecall重視からprecision重視へとアニーリングする報酬カリキュラムを組み合わせている。
学習規模は約5エポック・300ステップで、230ステップ付近で収束が確認されている。検索インフラはChroma Cloud内でコレクションをレプリケーションし、ピーク3000+クエリ/秒を捌いた。
ベースモデルとの比較
RLによる学習でエージェントの振る舞いがどう変わったかを示す数値がある。
| 指標 | gpt-oss-20b | Context-1 | 変化 |
|---|---|---|---|
| 並列ツールコール/ターン | 1.52 | 2.56 | +68% |
| ターン/トラジェクトリ | 6.7 | 5.2 | -22% |
| プルーニング精度 | 0.824 | 0.941 | +14pt |
ターン数が減り、プルーニング精度が上がり、並列検索が増えた。少ないステップで多くの情報を集め、不要な情報を高精度で捨てる、というエージェントとしての効率がRLで改善されている。
単一タスク（Web domain task 1_0）での直接比較では次のとおり。
| 指標 | gpt-oss-20b | Context-1 |
|---|---|---|
| Trajectory Recall | 0.640 | 0.739 |
| Output Recall | 0.361 | 0.641 |
| F1 | 0.307 | 0.487 |
| Final Answer Found | 0.541 | 0.798 |
フロンティアモデルとのベンチマーク比較
Context-1の4xは4つのロールアウトをRRFで結合する構成で、並列実行可能なため「フロンティアモデルへの単一APIコールより安価」という位置づけだ。
生成ベンチマーク（Final Answer Found）での主要比較（Webドメイン、難易度2以上）。
| モデル | Web | Finance | Legal | |
|---|---|---|---|---|
| Context-1 (4x) | 0.97 | 0.82 | 0.95 | 0.98 |
| Context-1 (1x) | 0.88 | 0.64 | 0.89 | 0.92 |
| gpt-5.4 | 0.97 | 0.67 | 0.95 | 0.97 |
| sonnet-4.6 | 0.96 | 0.72 | 0.91 | 0.97 |
| opus-4.6 | 0.98 | 0.84 | 0.94 | 0.98 |
| gemini-3.1-pro | 0.97 | 0.82 | 0.88 | 0.94 |
Emailドメインは学習データに含まれていないにもかかわらず大幅に改善しており、汎化性能が確認できる。Financeでの精度がやや低いのはトークンバジェット制約による早期終了が影響しているとされており、200k context・no prune構成では0.82まで回復する。
公開ベンチマーク（BrowseComp+、FRAMES、HotpotQA）でも同様の傾向で、Context-1 (4x)はHotpotQAをほぼ飽和させ、FRAMESでは0.96とフロンティアと並ぶ。
推論はvLLMで提供。NVIDIA B200上でMoE層をMXFP4量子化して400〜500 tok/sのスループットを実現している。