Home
Blog
RAGコンテキストの刈り込みとトークン保存のためのセマンティックハイライトモデルの構築方法

RAGコンテキストの刈り込みとトークン保存のためのセマンティックハイライトモデルの構築方法

Engineering

January 19, 2026

Cheney Zhang, Jiang Chen

問題：RAGのノイズとトークンの無駄

ベクトル検索は、エンタープライズアシスタント、AIエージェント、カスタマーサポートボットなどのRAGシステムの強固な基盤です。重要な文書を確実に見つけることができる。しかし、検索だけではコンテキストの問題を解決することはできない。よくチューニングされたインデックスでさえ、広範囲に関連するチャンクを返すが、そのチャンクの中にある文章のうち、実際にクエリに答えるものはごく一部である。

本番システムでは、このギャップはすぐに現れる。一つのクエリで何十ものドキュメントが取り込まれるかもしれない。実際のシグナルを含む文章はほんの一握りで、残りはトークンの使用量を増大させ、推論を遅らせ、LLMの気を散らせるコンテキストである。エージェントワークフローでは、クエリ自体が多段階推論の出力であり、検索されたテキストのごく一部にしかマッチしないため、問題はさらに明白になる。

このため、有用な文章を 識別してハイライト し、残りを無視することができるモデルの明確な必要性が生じる。基本的には、文章レベルの関連性フィルタリング、または多くのチームがコンテキストの刈り込みと呼ぶものである。目的は単純で、重要な部分を残し、LLMに到達する前にノイズを取り除くことです。

従来のキーワードベースのハイライトでは、この問題は解決できない。例えば、ユーザーが "Pythonコードの実行効率を上げるには？"と質問した場合、キーワードハイライターは "Python "と "efficiency "を選び出しますが、質問の答えである "Use NumPy vectorized operations instead of loops "は見逃してしまいます。代わりに必要なのは、文字列のマッチングではなく、意味の理解なのです。

RAGノイズフィルタとコンテキスト刈り込みのためのセマンティックハイライトモデル

RAGビルダーがこれを簡単に行えるように、私たちは、検索されたドキュメントの中でクエリと意味的に一致する文章を特定し、ハイライトするセマンティックハイライティングモデルをトレーニングし、オープンソース化しました。このモデルは現在、英語と中国語の両方で最先端の性能を発揮し、既存のRAGパイプラインに直接組み込むことができるように設計されています。

モデルの詳細

HuggingFace: zilliz/semantic-highlight-bilingual-v1
ライセンスMIT (商用フレンドリー)
アーキテクチャBGE-M3 Reranker v2に基づく0.6Bエンコーダのみのモデル
コンテキストウィンドウ8192トークン
対応言語英語と中国語

セマンティックハイライトは、長い検索文書の有用な部分のみを選択するために必要な関連性シグナルを提供する。実際には、このモデルによって以下のことが可能になります：

文書のどの部分が実際に重要であるかを示す、解釈可能性の向上
ハイライトされた文章のみをLLMに送ることで、トークンのコストを70～80%削減
無関係な文脈を見ずに済むため、回答の質が向上する。
エンジニアが文レベルのマッチを直接検査できるため、デバッグが容易

評価結果SOTAパフォーマンスの達成

英語と中国語にまたがる複数のデータセットで、セマンティックハイライティングモデルをドメイン内とドメイン外の両方の条件で評価しました。

ベンチマークスイートは以下の通りです：

英語マルチスパンQA:multispanqa
英語圏外ウィキペディア：wikitext2
中国語マルチスパンQA:multispanqa_zh
中国語のアウトオブドメイン・ウィキペディア：wikitext2_zh

評価モデルは以下の通り：

オープンプロヴァンスシリーズ
ネイバーのProvence/XProvenceシリーズ
OpenSearchのセマンティックハイライト
学習済みバイリンガルモデル：zilliz/semantic-highlight-bilingual-v1

4つのデータセットすべてにおいて、私たちのモデルはトップランキングを達成しています。さらに重要なことは、英語と中国語の両方で一貫して優れた結果を出す唯一のモデルであるということです。競合モデルは、英語だけに焦点を当てるか、中国語テキストで明らかなパフォーマンス低下を示しています。

セマンティックハイライティングモデルの構築方法

このタスクのためのモデルをトレーニングすることは難しいことではありません。初期の問題を処理し、SOTAに近いパフォーマンスを提供する優れたモデルをトレーニングすることが、本当の仕事になります。私たちのアプローチは次の2点に重点を置いています：

モデル・アーキテクチャ：高速推論のためにエンコーダのみの設計を使用する。
トレーニングデータ：推論可能なLLMを使用して高品質の関連性ラベルを生成し、ローカル推論フレームワークでデータ生成をスケールする。

モデルアーキテクチャ

コンテキスト刈り込みをトークンレベルの関連性スコアリングタスクとして扱う、軽量なエンコーダのみのネットワークとしてモデルを構築した。この設計は、ICLR 2025でNaverによって紹介されたコンテキスト・プルーニング・アプローチであるProvenceに触発されたもので、プルーニングを "正しいチャンクを選択する "から "すべてのトークンをスコアリングする "ことに置き換える。この枠組みは、きめ細かなシグナルが不可欠なセマンティック・ハイライトと自然に合致する。

エンコーダのみのモデルは最新のアーキテクチャではないが、ここでは非常に実用的である。本番のRAGシステムでは、このスピードの優位性は、より大きなデコーダーモデルを使うよりもはるかに重要である。

トークン・レベルの関連性スコアを計算したら、それを文レベルのスコアに集約する。このステップにより、ノイズの多いトークン信号が安定した解釈可能な関連性メトリックに変わる。設定可能な閾値以上の文はハイライトされ、それ以外はフィルタリングされる。これにより、クエリにとって実際に重要なセンテンスを選択するためのシンプルで信頼性の高いメカニズムが出来上がる。

推論プロセス

実行時、我々のセマンティックハイライティングモデルはシンプルなパイプラインに従う：

入力-プロセスはユーザーのクエリーから始まる。取得された文書は関連性評価のためのコンテキスト候補として扱われる。
モデル処理-クエリとコンテキストは1つのシーケンスに連結される：[BOS] + クエリ + コンテキスト
トークンのスコアリング -コンテキスト内の各トークンは、クエリとの関連性の強さを反映する0から1の間の関連性スコアが割り当てられる。
文の集約 -トークンのスコアは文レベルで集約され、通常は平均化され、各文の関連性スコアが生成されます。
しきい値フィルタリング -設定可能なしきい値以上のスコアを持つ文はハイライトされ保持され、スコアの低い文は下流のLLMに渡される前にフィルタリングされる。

ベースモデルBGE-M3 Reranker v2

ベースモデルとしてBGE-M3 Reranker v2を選択した理由はいくつかある：

トークンや文のスコアリングに適したエンコーダアーキテクチャを採用している。
英語と中国語の両方に最適化された多言語をサポート
長いRAG文書に適した8192個のトークンコンテキストウィンドウを提供
0.6Bのパラメータを維持し、計算量を増やすことなく十分な強度を確保
ベースモデルに十分な世界知識を確保
関連性判定タスクと密接に連携するリランキング用に学習済み

トレーニングデータ推論を伴うLLMアノテーション

モデル・アーキテクチャが完成したら、次の課題は、実際に信頼できるモデルを訓練するためのデータセットを構築することだった。私たちはまず、Open Provenceがどのようにこれを処理しているかを見ることから始めた。彼らのアプローチは、公開されたQAデータセットと小さなLLMを使って、どの文が関連性があるかをラベル付けする。スケールもよく、自動化も簡単なので、私たちにとって良いベースラインとなった。

LLMに文レベルのラベルを直接出力させると、結果は必ずしも安定しない。LLMに文レベルのラベルを直接出力させると、結果が常に安定しないのだ。あるラベルは正しくても、あるラベルは疑わしい。完全に手作業でアノテーションを行うという選択肢もなかった。手作業でラベル付けできる量をはるかに超えるデータが必要だったのだ。

スケーラビリティを犠牲にすることなく安定性を向上させるために、LLMは出力するラベルごとに短い推論スニペットを提供しなければならない。各トレーニング例には、クエリ、ドキュメント、センテンススパン、センテンスが関連または無関係である理由の簡単な説明が含まれる。この小さな調整により、アノテーションの一貫性が高まり、データセットの検証やデバッグの際に参照できる具体的な情報が得られた。

理由を含めることは、驚くほど価値があることがわかった：

アノテーションの質の向上：理由を書き出すことでセルフチェックができ、ランダムなラベルや一貫性のないラベルを減らすことができる。
観察可能性の向上：ラベルをブラックボックスとして扱うのではなく、なぜその文章が選択されたかを見ることができる。
より簡単なデバッグ：何かが間違っているように見えるとき、プロンプト、ドメイン、アノテーションロジックのどれが問題かを簡単に見つけることができます。
再利用可能なデータ：将来的に異なるラベリングモデルに切り替えたとしても、推論トレースは再ラベリングや監査に役立ちます。

アノテーションのワークフローは以下のようになる：

Qwen3 8Bによるアノテーション

アノテーションのためにQwen3 8Bを選択した理由は、Qwen3 8Bが出力による「思考モード」をネイティブにサポートしており、一貫性のある推論トレースの抽出が非常に容易だからである。小さなモデルでは安定したラベルが得られず、大きなモデルはこの種のパイプラインには遅く、不必要に高価でした。Qwen3 8Bは、品質、スピード、コストの間で適切なバランスを保っている。

我々は、クラウドAPIではなく、ローカルのvLLMサービスを使って全てのアノテーションを実行した。これにより、高いスループット、予測可能なパフォーマンス、より低いコスト、つまりGPU時間とAPIトークン料金を交換することができ、何百万ものサンプルを生成する場合、より良い取引となった。

データセットのスケール

合計で500万以上のバイリンガルのトレーニングサンプルを構築し、英語と中国語でほぼ均等に分けた。

英語のソースMS MARCO、Natural Questions、GooAQ
中国語ソースDuReader、中国語ウィキペディア、mmarco_chinese

データセットの一部は、Open Provenceのようなプロジェクトで使われている既存のデータを再注釈したものである。残りは、まずクエリとコンテキストのペアを作成し、推論ベースのパイプラインでラベル付けすることで、生のコーパスから生成されました。

すべての注釈付きトレーニングデータは、コミュニティの発展とトレーニングの参考のためにHuggingFaceでも利用可能です：Zillizデータセット

トレーニング方法

モデルのアーキテクチャとデータセットの準備ができたら、8×A100 GPUでモデルを3エポック訓練しました。

注：訓練は、セマンティックハイライトタスクを担当するPruning Headのみを対象とした。Rerankヘッドをトレーニングしなかったのは、プルーニングの目的のみに集中することで、文レベルの関連性スコアリングでより良い結果が得られたからである。

実際のケーススタディ

ベンチマークはストーリーの一部しか語らないので、よくあるエッジケース、つまり検索されたテキストに正解と非常に魅力的なディストラクターの両方が含まれている場合にモデルがどのように振る舞うかを示す実際の例を紹介します。

クエリ The Killing of a Sacred Deer（聖なる鹿殺し）を書いたのは誰ですか？

コンテキスト（5文）：

1\. The Killing of a Sacred Deer is a 2017 psychological horror film directed by Yorgos Lanthimos,
with a screenplay by Lanthimos and Efthymis Filippou.
2. The film stars Colin Farrell, Nicole Kidman, Barry Keoghan, Raffey Cassidy,
Sunny Suljic, Alicia Silverstone, and Bill Camp.
3. The story is based on the ancient Greek playwright Euripides’ play Iphigenia in Aulis.
4. The film tells the story of a cardiac surgeon (Farrell) who secretly
befriends a teenager (Keoghan) connected to his past.
5. He introduces the boy to his family, who then mysteriously fall ill.

正解：文1（「脚本：ランティモスとエフティミス・フィリッポウ」と明示されている）

この例文には罠がある：文3は「エウリピデス」が原作を書いたと述べている。しかし、設問は「誰が映画『聖なる鹿殺し』を書いたか」を尋ねており、答えは映画の脚本家であって、数千年前のギリシャの劇作家ではないはずだ。

模範解答結果

模範解答	正しい答えを見つけたか？	予測
我々のモデル	✓	文1（正解）と文3を選択
XProvence v1	✗	文3のみを選択、正解を逃す
XProvence v2	✗	センテンス3のみ選択、正解を逃す

キーセンテンスのスコア比較

文	モデル	XProvence v1	XProvence v2
センテンス1（映画脚本、正解）	0.915	0.133	0.081
センテンス3（オリジナル劇、ディストラクター）	0.719	0.947	0.802

XProvenceモデル：

エウリピデス」と「戯曲」に強く惹かれ、センテンス3に満点に近いスコア（0.947と0.802）を与える。
実際の回答（文1）を完全に無視し、極端に低いスコア（0.133と0.081）を与える。
しきい値を0.5から0.2に下げても、正解を見つけることができない。

我々のモデル

文1に最も高いスコアを与える (0.915)
文3は背景と関連しているため、まだある程度の関連性を付与 (0.719)
0.2程度のマージンで2つを明確に分離

この例は、表面的なキーワードのマッチングではなく、クエリの意図を理解するというモデルの核となる強みを示しています。この文脈では、"Who wroteThe Killing of a Sacred Deer"は古代ギリシャの戯曲ではなく映画を指しています。私たちのモデルは、他のモデルが強い語彙的な手がかりに気を取られている間に、それを拾う。

使ってみて感想をお聞かせください

私たちのzilliz/semantic-highlight-bilingual-v1モデルは、現在MITライセンスの下で完全にオープンソース化されており、実運用に使用する準備ができています。あなたのRAGパイプラインに組み込んだり、あなた自身のドメイン用に微調整したり、この上に新しいツールを構築することができます。コミュニティからの貢献やフィードバックも歓迎します。

HuggingFaceからダウンロード：zilliz/semantic-highlight-bilingual-v1
全ての注釈付き学習データ : https://huggingface.co/zilliz/datasets

MilvusとZilliz Cloudで利用可能なセマンティックハイライト

セマンティックハイライトはMilvusと Zilliz Cloud(フルマネージドMilvus)にも直接組み込まれており、各文書がなぜ検索されたかを明確に表示します。チャンク全体をスキャンする代わりに、クエリに関連する特定の文章を即座に見ることができます。これによって、検索が理解しやすくなり、デバッグが非常に速くなります。また、RAGパイプラインでは、下流のLLMが何を重視するかが明確になり、迅速な設計と品質チェックに役立ちます。

フルマネージドZilliz Cloudのセマンティックハイライトを無料でお試しください。

バグレポート、改善アイデア、ワークフローへの統合中に発見したことなど、ぜひお聞かせください。

より詳しくお聞きになりたい場合は、お気軽にDiscordチャンネルにご参加いただくか、20分間のMilvusオフィスアワーをご予約ください。他のビルダーとおしゃべりしたり、メモを交換したりするのはいつでも大歓迎です。

謝辞

この作品は、多くの素晴らしいアイデアとオープンソースの貢献の上に成り立っており、このモデルを可能にしたプロジェクトに注目したい。

Provenceは、軽量エンコーダーモデルを使ったコンテキスト刈り込みのための、クリーンで実用的なフレームを導入した。
Open Provenceは、寛容なライセンスの下で、トレーニングパイプライン、データ処理、モデルヘッドなど、堅実でよく設計されたコードベースを提供した。これは私たちに実験のための強力な出発点を与えてくれた。

その基盤の上に、私たちはいくつかの貢献を加えた：