本記事は Zilliz 公式ブログの A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud（2026年2月11日 / Ivan Tang）を日本語向けに翻訳・再構成したものです。日本語環境固有の観点は「🇯🇵」マークのセクションとして加筆しています。
Milvus 2.6 の機能を 4 回に分けて扱うシリーズの第 2 回です。
| 回 | テーマ |
|---|---|
| ① Embedding Function | 埋め込み生成をデータベースに寄せる |
| ② Lexical Highlighting（本記事） | なぜヒットしたのかを見せる |
| ③ N-gram インデックス | 部分一致を速くする |
| ④ Decay Ranker と Boosting | ランキングを業務要件に寄せる |
Lexical Highlighting（語彙ハイライト表示）
Lexical highlighting は、マッチのきっかけになった語やフレーズを視覚的にマークすることで、ユーザーに「なぜこの結果が出たのか」を示す機能です。検索結果の透明性、解釈可能性、そして信頼につながります。
主なシナリオは次の通りです。
UI 上での検索結果表示。 検索インターフェースを作るとき、ハイライトがあれば文書を開かずに関連性を判断できます。認知負荷が下がり、クリック率が上がります。
文書・コンテンツ検索。 ナレッジベース、PDF、規程類といった大きな文書では、マッチしたキーワードを周辺文脈の中で即座に見つけられます。
ログ・イベント分析。 密で非構造なテキストの中から、マッチしたパターン、エラーコード、キーワードを見つけやすくなります。障害対応時に効きます。
RAG のデバッグ。 RAG パイプラインにおいて、取得したチャンクのどの部分が元のクエリにマッチしたのかを検査できます。具体的には、
- 検索が正しく動いているかの検証
- 誤検出や弱いマッチの診断
- なぜそのコンテキストが生成に選ばれたのかの理解
使い方
実装は、まず LexicalHighlighter をインスタンス化し（ハイライト対象のクエリテキストと、囲みタグを指定）、全文検索リクエストのパラメータとして渡します。
Milvus は検索を実行したのち、語彙的なロジックで完全一致を探し、どの部分文字列をハイライトすべきかの位置情報を返します。
ベストプラクティス
- LexicalHighlighter は BM25 全文検索でのみ動作します。 dense ベクトル検索では機能しません
-
pre_tagsとpost_tagsで、マッチした語を HTML タグ（カスタム CSS クラス、太字、斜体など）で囲めます。Web ページにそのままレンダリングできます
🇯🇵 補足：日本語のハイライト範囲は、アナライザ設定で決まる
日本語で使うときに知っておきたいのは、ハイライトの単位が形態素解析の結果に従うことです。
英語なら空白で区切られるので直感通りに動きますが、日本語は「どこで切るか」がアナライザ次第です。たとえば「機械学習」を検索したとき、
- 辞書が
機械学習を 1 語として持っていれば → 「機械学習」全体がハイライトされる - 持っていなければ → 「機械」「学習」が別々にハイライトされる
さらに ipadic のような古い辞書だと、新語や製品名が細かく分割されてハイライトがバラバラに散ることがあります。見た目の問題に見えますが、ユーザーからは「検索がおかしい」と受け取られます。
対策としては、lindera トークナイザの辞書を用途に合わせて選ぶ（新語が多いなら ipadic-neologd）、run_analyzer で実際の分割結果を事前に確認する、といったところです。ハイライトの見た目を確認する作業は、そのまま全文検索の品質確認になりますので、UI を作る前に一度通しておくと良いと思います。
なお、RAG のデバッグ用途では日本語でも十分実用的です。「なぜこのチャンクが選ばれたのか」を目視できるのは、日本語のように分割の仕方で結果が変わる言語ほど価値があります。
次回
第 3 回は N-gram インデックス です。LIKE %〜% の部分一致を高速化する機能ですが、日本語の全文検索では「形態素解析か N-gram か」という古典的な設計判断に直結します。本シリーズで最も日本語固有の話が多くなる回です。
参考リンク
原記事
- A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud（Ivan Tang, 2026年2月11日）
ドキュメント
関連ブログ
日本語アナライザ関連