プロダクションRAGとAI検索のためのバイリンガル・セマンティック・ハイライティング・モデルをトレーニングし、オープンソース化した。

製品検索、RAGパイプライン、AIエージェントのいずれを構築する場合でも、ユーザーが最終的に必要とするものは同じです。ハイライトは、マッチをサポートする正確なテキストをマークすることで、ユーザーが文書全体をスキャンする必要がないようにします。

ほとんどのシステムはまだキーワードベースのハイライトに頼っている。ユーザーが "iPhone performance "と検索すると、システムは "iPhone "と "performance "というトークンをハイライトする。しかし、テキストが異なる表現で同じアイデアを表現すると、これはすぐに破綻する。A15 Bionicチップ、ベンチマークで100万以上、ラグがなくスムーズ」というような説明は、明らかにパフォーマンスについて述べているにもかかわらず、キーワードが登場しないため、何もハイライトされないのです。

セマンティックハイライトはこの問題を解決します。正確な文字列をマッチングするのではなく、クエリと意味的に一致するテキストスパンを特定する。RAGシステム、AI検索、エージェントなど、関連性が表面的な形ではなく意味に依存する場合、これは文書がなぜ検索されたのかについて、より正確で信頼性の高い説明をもたらす。

しかし、既存のセマンティックハイライトの方法は、本番のAIワークロード用に設計されていない。利用可能なすべてのソリューションを評価した結果、RAGパイプライン、エージェントシステム、大規模ウェブ検索に必要な精度、レイテンシー、多言語カバレッジ、ロバスト性を提供するものはありませんでした。そこで、私たちは独自のバイリンガル意味強調表示モデルをトレーニングし、オープンソース化しました。

• 私たちのセマンティックハイライティングモデル：zilliz/semantic-highlight-bilingual-v1

• 私たちのDiscordに参加したり、LinkedInで私たちをフォローしたり、Milvusオフィスアワーの20分のセッションを予約したりして、あなたの意見をお聞かせください。

キーワードベースのハイライトはどのように機能するのか - そしてなぜ現代のAIシステムでは失敗するのか

従来の検索システムは、単純なキーワードマッチによってハイライトを実装しています。検索結果が返されると、エンジンはクエリにマッチするトークンの位置を特定し、マークアップ（通常は<em> タグ）で囲みます。これは、クエリ用語がテキストにそのまま表示される場合は問題なく機能します。

問題は、このモデルは関連性がキーワードの完全な重複と結びついていると仮定していることだ。この仮定が崩れると、信頼性は急速に低下する。たとえ検索ステップが正しくても、異なる表現で正しいアイデアを表現した結果は、ハイライトされずに終わってしまう。

この弱点は、最新のAIアプリケーションで明らかになる。RAGパイプラインやAIエージェントのワークフローでは、クエリがより抽象的になり、文書が長くなり、関連する情報が同じ単語を再利用しないことがあります。キーワードベースの強調表示は、開発者やエンドユーザーに答えが実際にどこにあるのかを示すことができなくなり、検索が意図したとおりに動作していても、システム全体の精度が低く感じられるようになる。

ユーザーがこう尋ねたとしよう："Pythonコードの実行効率を上げるにはどうしたらいいですか？"システムはベクターデータベースから技術文書を検索する。従来のハイライトでは、"Python"、 "code"、 "execution"、"efficiency "といったリテラルマッチしかマークできない。

しかし、その文書の最も有用な部分は次のようなものです：

• 明示的なループの代わりにNumPyのベクトル化された演算を使う。

• ループの中で繰り返しオブジェクトを生成することを避ける

これらの文章は質問に直接答えていますが、クエリ用語を含んでいません。その結果、従来のハイライトは完全に失敗します。文書は関連性があっても、ユーザーは実際の答えを見つけるために一行ずつスキャンしなければなりません。

AIエージェントでは、この問題はさらに顕著になる。エージェントの検索クエリは、多くの場合、ユーザーのオリジナルの質問ではなく、推論とタスク分解によって生成された派生命令である。例えば、ユーザーが"最近の市場動向を分析できますか？"と質問した場合、エージェントは "2024年第4四半期の家電製品の販売データ、前年比成長率、主要な競合他社の市場シェアの変化、サプライチェーンのコスト変動を取得 "のようなクエリを生成するかもしれない。

このクエリは複数の次元にまたがり、複雑な意図をコード化しています。しかし、従来のキーワードベースのハイライトでは、「2024年」、 「販売データ」、「成長率」といった文字通りの一致を機械的にマークすることしかできません。

一方、最も価値のあるインサイトは次のようなものだ：

• iPhone 15シリーズが市場全体の回復を牽引

• チップ供給の制約がコストを15%押し上げた

これらの結論は、エージェントがまさに抽出しようとしているものであるにもかかわらず、クエリとキーワードを一つも共有していないかもしれない。エージェントは、検索された大量のコンテンツから本当に有益な情報を素早く特定する必要があります。

セマンティックハイライトとは何か、現在のソリューションの問題点

セマンティックハイライトは、セマンティック検索と同じ考え方に基づいています。セマンティック検索では、埋め込みモデルがテキストをベクトルにマッピングするため、検索システム（通常、milvusのようなベクトルデータベースに支えられている）は、たとえ表現が異なっていても、クエリと同じアイデアを伝える文章を検索することができます。セマンティックハイライトは、この原理をより細かい粒度で応用したものである。文字通りのキーワードヒットをマークする代わりに、ユーザーの意図に意味的に関連する文書内の特定のスパンをハイライトする。

このアプローチは、クエリ用語が逐語的に表示される場合にのみ機能する従来のハイライトの中核的な問題を解決します。ユーザーが「iPhoneのパフォーマンス」と検索した場合、キーワードベースのハイライトでは、「A15 Bionicチップ」、「ベンチマークで100万回以上」、「ラグがなくスムーズ」といったフレーズは無視されます。セマンティックハイライトは、このような意味主導のつながりをとらえ、ユーザーが実際に気になる部分を浮かび上がらせます。

理論的には、これは簡単なセマンティックマッチングの問題である。現代の埋め込みモデルはすでに類似性をうまく符号化しているので、概念的な部分はすでに整っている。課題は実世界の制約から来る。ハイライトはすべてのクエリで発生し、多くの場合検索されたドキュメントにまたがるため、レイテンシー、スループット、クロスドメインのロバスト性が譲れない要件となる。大規模な言語モデルは、このような高頻度のパスで実行するには、単純に遅すぎ、コストがかかりすぎる。

そのため、実用的なセマンティック・ハイライトには、軽量で特化したモデルが必要なのです。このモデルは、検索インフラストラクチャーと並行して使用できるほど小さく、数ミリ秒で結果を返せるほど高速です。既存のソリューションのほとんどがここで破綻している。軽量なモデルは高速ですが、精度が落ちたり、多言語やドメイン固有のデータで失敗したりします。

opensearch-semantic-highlighter（オープンサーチ-セマンティック-ハイライター

昨年、OpenSearchはセマンティックハイライトのための専用モデルopensearch-semantic-highlighter-v1をリリースしました。この問題に対する有意義な試みですが、2つの重大な制限があります。

• コンテキストウィンドウが小さい：このモデルはBERTアーキテクチャに基づいており、最大512個のトークン（おおよそ300～400の漢字または400～500の英単語）をサポートしている。実際のシナリオでは、製品説明や技術文書は数千語に及ぶことが多い。最初のウィンドウを超えるコンテンツは単純に切り捨てられ、モデルは文書のごく一部に基づいてハイライトを識別することを余儀なくされます。

• 領域外の汎化が悪い：このモデルは、学習セットと同様のデータ分布でのみ良好な性能を発揮する。ニュース記事で学習したモデルをeコマースコンテンツや技術文書のハイライトに使用するなど、領域外のデータに適用すると、パフォーマンスが急激に低下する。我々の実験では、このモデルはドメイン内のデータでは約0.72のF1スコアを達成したが、ドメイン外のデータセットでは約0.46まで低下した。このレベルの不安定性は、本番では問題となる。さらに、このモデルは中国語をサポートしていない。

プロヴァンス / XProvence

Provenceは Naverによって開発されたモデルで、当初はセマンティックハイライトと密接に関連するタスクであるコンテキストの刈り込みのために学習された。

どちらのタスクも、意味的マッチングを使用して関連するコンテンツを識別し、無関係な部分をフィルタリングするという、根本的な考え方は同じです。このため、Provenceは比較的少ない適応でセマンティックハイライトに再利用することができる。

Provenceは英語のみのモデルであり、その設定においてそれなりにうまく機能する。XProvenceはその多言語版で、中国語、日本語、韓国語を含む12以上の言語をサポートしている。一見すると、XProvenceはバイリンガルまたは多言語のセマンティック・ハイライト・シナリオに適しているように見える。

しかし実際には、ProvenceにもXProvenceにもいくつかの顕著な限界がある：

• 多言語モデルにおける英語のパフォーマンスが弱い：XProvenceは英語のベンチマークでProvenceの性能に及ばない。これは、多言語モデルにおける一般的なトレードオフである。言語間で能力が共有されるため、英語のような高リソース言語では性能が低下することが多い。この制限は、英語が主要または支配的な作業負荷であり続ける実世界のシステムにおいて重要である。

• 限られた中国語のパフォーマンス： XProvenceは多くの言語をサポートしている。多言語トレーニングでは、データとモデルのキャパシティが各言語に分散されるため、単一の言語に特化したモデルの性能が制限される。その結果、XProvenceの中国語性能はわずかであり、高精度のハイライト処理には不十分である。

• 刈り込みと強調表示の目的の不一致：Provenceはコンテキストの刈り込みに最適化されており、重要な情報を失わないよう、可能な限り有用なコンテンツを保持することが優先されます。これとは対照的に、セマンティックハイライトは精度を重視し、文書の大部分ではなく、最も関連性の高い文章のみをハイライトする。Provenceスタイルのモデルがハイライトに適用されると、このミスマッチがしばしば過度に広い範囲やノイズの多いハイライトにつながる。

• ライセンスの制限：ProvenceもXProvenceもCC BY-NC 4.0ライセンスでリリースされており、商用利用は許可されていない。この制限だけで、多くの本番環境には適さない。

オープン・プロヴァンス

Open Provenceは、Provenceトレーニングパイプラインをオープンで透明性のある方法で再実装するコミュニティ主導のプロジェクトです。トレーニングスクリプトだけでなく、データ処理ワークフロー、評価ツール、複数スケールでの事前学習済みモデルも提供する。

Open Provenceの主な利点は、寛容なMITライセンスである。ProvenceやXProvenceとは異なり、法的な制限なしに商用環境でも安全に使用できるため、生産志向のチームにとって魅力的である。

とはいえ、Open Provenceは現在のところ英語と日本語しかサポートしていないので、私たちのようなバイリンガルのユースケースには不向きです。

バイリンガル・セマンティック・ハイライティング・モデルをトレーニングし、オープンソース化しました。

実際の作業負荷のために設計されたセマンティックハイライティングモデルは、いくつかの重要な機能を提供する必要があります：

• 強力な多言語パフォーマンス

• 長い文書をサポートするのに十分な大きさのコンテキストウィンドウ

• 頑健な領域外汎化

• セマンティックハイライトタスクにおける高い精度

• 生産に適した寛容なライセンス（MITまたはApache 2.0）

既存のソリューションを評価した結果、利用可能なモデルのどれもが実運用に必要な要件を満たしていないことがわかりました。そこで、私たちは独自のセマンティックハイライトモデル：zilliz/semantic-highlight-bilingual-v1をトレーニングすることにしました。

これらすべてを達成するために、私たちは単純なアプローチを採用しました。大規模な言語モデルを使用して高品質のラベル付きデータを生成し、その上でオープンソースのツールを使用して軽量のセマンティックハイライトモデルを学習します。これにより、LLMの推論の強さと、生産システムで必要とされる効率性と低レイテンシーを組み合わせることができる。

このプロセスで最も難しいのはデータ構築である。アノテーション中、LLM(Qwen3 8B)にハイライトスパンだけでなく、その背後にある推論全体を出力するよう促す。この追加的な推論信号により、より正確で一貫性のある監視が行われ、結果として得られるモデルの品質が大幅に向上する。

アノテーションパイプラインは次のように動作する：LLM推論 → ハイライトラベル → フィルタリング → 最終トレーニングサンプル。

この設計は、実際に3つの具体的な利点をもたらします：

• ラベリングの質の向上：モデルは最初に考え、次に答えるように促される。この中間推論ステップは、組み込みのセルフチェックとして機能し、浅いラベルや一貫性のないラベルの可能性を低減します。

• 観察可能性とデバッグ可能性の向上：各ラベルは推論トレースを伴うため、エラーが可視化されます。これにより、失敗ケースの診断が容易になり、パイプライン内のプロンプト、ルール、またはデータフィルタを迅速に調整できます。

• 再利用可能なデータ：推論トレースは、将来の再ラベリングに貴重なコンテキストを提供します。要件が変更されても、同じデータを再検討し、ゼロから始めることなく改良することができます。

このパイプラインを使用して、英語と中国語をほぼ均等に分けた100万以上のバイリンガルのトレーニングサンプルを生成しました。

モデルの学習には、BGE-M3 Reranker v2（0.6Bパラメータ、8,192トークンコンテキストウィンドウ）から開始し、Open Provence学習フレームワークを採用し、8×A100 GPUで3エポックの学習を行い、約5時間で学習を完了した。

推論トレースに依存する理由、ベースモデルの選択方法、データセットの構築方法など、これらの技術的な選択については、次の投稿で詳しく説明します。

Zillizのバイリンガル意味強調モデルのベンチマーク

実世界でのパフォーマンスを評価するため、多様なデータセットで複数のセマンティックハイライティングモデルを評価しました。ベンチマークは、本番システムで遭遇する様々なコンテンツを反映するため、英語と中国語のドメイン内シナリオとドメイン外シナリオの両方をカバーしています。

データセット

評価には以下のデータセットを使用した：

• MultiSpanQA（英語）- インドメインのマルチスパン質問応答データセット。

• WikiText-2（英語）- 領域外のWikipediaコーパス。

• MultiSpanQA-ZH (中国語)- 中国語のマルチスパン質問応答データセット

• WikiText-2-ZH（中国語）- 領域外の中国語ウィキペディアコーパス

比較モデル

比較の対象としたモデルは以下の通りです：

• Open Provenceモデル

• Provence / XProvence(Naverがリリース)

• OpenSearchセマンティックハイライター

• Zillizの対訳セマンティックハイライティングモデル

結果と分析

英語データセット

中国語データセット

バイリンガルベンチマーク全体において、我々のモデルは最先端の平均F1スコアを達成し、過去に評価された全てのモデルやアプローチを凌駕しました。特に中国語データセットで顕著であり、我々のモデルは、中国語をサポートする他の唯一の評価モデルであるXProvenceを大幅に上回っています。

さらに重要なことに、我々のモデルは英語と中国語の両方でバランスの取れた性能を発揮します：

• Open Provenceは英語のみサポート

• XProvenceはProvenceに比べて英語のパフォーマンスを犠牲にしています。

• OpenSearch Semantic Highlighterは中国語をサポートしておらず、汎化が弱い。

その結果、我々のモデルは、言語カバレッジとパフォーマンスの間の一般的なトレードオフを回避し、実際のバイリンガル展開により適しています。

実際の具体例

ベンチマークのスコアだけでなく、具体的な例を検証することでより明らかになることがよくあります。以下のケースは、実際のセマンティックハイライトのシナリオにおいて我々のモデルがどのように振る舞い、なぜ精度が重要なのかを示しています。

クエリー映画「The Killing of a Sacred Deer（聖なる鹿殺し）」の脚本家は？

コンテキスト（5文）：

1. The Killing of a Sacred Deer』は、ヨルゴス・ランティモス監督による2017年のサイコスリラー映画で、脚本はランティモスとエフティミス・フィリッポウが執筆した。

2. 主演はコリン・ファレル、ニコール・キッドマン、バリー・キーガン、ラフィー・キャシディ、サニー・スルジッチ、アリシア・シルヴァーストーン、ビル・キャンプ。

3. ストーリーは、エウリピデス作の古代ギリシャの戯曲『アウリスのイフィゲニア』をベースにしている。

4. この映画は、心臓外科医が、自分の過去につながる10代の少年と秘密の友情を結ぶ姿を描く。

5. 彼は少年を家族に紹介するが、その後、不可解な病気が起こり始める。

正しいハイライト文1は、脚本がヨルゴス・ランティモスとエフティミス・フィリッポウであることを明示しているので正解。

この例文には微妙な罠がある。文3は、この物語の大まかな原作であるギリシャ劇の作者、エウリピデスについて触れている。しかし、設問は誰がこの映画を書いたかを問うているのであって、古代の原作を問うているのではない。したがって正解は、数千年前の劇作家ではなく、映画の脚本家である。

結果

下の表は、この例題で異なるモデルがどのように機能したかをまとめたものです。

モデル	特定された正解	結果
我々のモデル（バイリンガルM3）	✓	文1（正解）と文3を選択
XProvence v1	✗	文3のみを選択、正解を逃す
XProvence v2	✗	文3のみを選択、正解を逃す

文レベルのスコア比較

文	私たちの (バイリンガルM3)	XProvence v1	XProvence v2
センテンス1（映画脚本、正解）	0.915	0.133	0.081
センテンス3（オリジナル劇、ディストラクター）	0.719	0.947	0.802

XProvenceが不十分な点

• XProvenceは"Euripides "と"written "というキーワードに強く惹かれ、文3にほぼ満点（0.947と0.802）をつける。

• 同時に、文1の正解をほとんど無視し、極端に低いスコア（0.133と0.081）を与える。

• 判定しきい値を0.5から0.2に下げた後でも、モデルは依然として正解を浮かび上がらせることができない。

言い換えれば、このモデルは質問の実際の意図よりも、表面レベルのキーワードの関連性によって主に駆動されます。

私たちのモデルの異なる動作

• 私たちのモデルは文1の正解に高いスコア(0.915)を割り当て、映画の脚本家を正しく特定します。

• また、文3には中程度のスコア(0.719)を割り当てます。この文は脚本関連の概念に言及しているからです。

• 重要なのは、分離が明確で意味があるということだ：0.915対0.719で、ほぼ0.2の開きがある。

この例は、キーワードによる関連付けを越えてユーザーの意図を正しく解釈するという、私たちのアプローチの核となる強みを強調しています。複数の "author "コンセプトが現れた場合でも、モデルは一貫して質問が実際に言及しているものをハイライトします。

より詳細な評価レポートとその他のケーススタディは、次の投稿でご紹介します。

試して感想をお聞かせください

私たちはHugging Face上でバイリンガルのセマンティックハイライトモデルをオープンソース化し、すべてのモデルの重みを公開しました。使ってみての感想や問題点、改善のアイデアなどをぜひお聞かせください。

並行して、私たちは本番環境に対応した推論サービスに取り組んでおり、ネイティブのセマンティックハイライトAPIとしてMilvusにモデルを直接統合しています。この統合はすでに進行中であり、間もなく利用可能になる予定です。

セマンティックハイライトは、より直感的なRAGとエージェントAI体験への扉を開きます。Milvusが複数の長い文書を検索する際、システムは最も関連性の高い文章を即座に表示し、答えがどこにあるかを明確にすることができる。これはエンドユーザーの体験を向上させるだけでなく、システムがコンテキストのどの部分に依存しているかを正確に示すことで、開発者が検索パイプラインをデバッグするのにも役立ちます。

私たちは、セマンティック・ハイライトが次世代検索およびRAGシステムの標準機能になると信じています。バイリンガル・セマンティック・ハイライトのアイデア、提案、使用例をお持ちの方は、私たちのDiscordチャンネルに参加して、あなたの考えを共有してください。また、Milvusオフィスアワーを通して、20分間の1対1のセッションを予約し、洞察やガイダンス、質問への回答を得ることもできます。