本記事は Zilliz 公式ブログの A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud（2026年2月11日 / Ivan Tang）を日本語向けに翻訳・再構成したものです。日本語環境固有の観点は「🇯🇵」マークのセクションとして加筆しています。
Milvus 2.6 の機能を 4 回に分けて扱うシリーズの最終回です。
| 回 | テーマ |
|---|---|
| ① Embedding Function | 埋め込み生成をデータベースに寄せる |
| ② Lexical Highlighting | なぜヒットしたのかを見せる |
| ③ N-gram インデックス | 部分一致を速くする |
| ④ Decay Ranker と Boosting（本記事） | ランキングを業務要件に寄せる |
Decay Ranker（減衰ランカー）
論文の意味検索エンジンを作っていて、10 年以内に出版された論文を、それ以前のものより優先したいとしましょう。
Decay ranker がなければ、出版年フィールドに基づいて検索結果で並べ替えることになります。Decay ranker の中心にあるのは Decay Function です。これは数値フィールド（タイムスタンプなど）に基づいて関連度スコアを調整します。最終スコアは次の式で計算されます。
final_score = normalized_similarity_score × decay_score
現在 3 種類の減衰関数があります。
| 関数 | 使いどころ |
|---|---|
| Linear | 一定の地点を超えたものを除外したいとき（年数、距離など） |
| Exponential | 新しいものを支配的にしつつ、古いものも発見可能にしておきたいとき |
| Gaussian | 位置情報検索。現在地に近いものを上位にしたいとき |
減衰関数はパラメータでカーブの形を細かく制御できます。
| パラメータ | 意味 |
|---|---|
origin |
基準点（現在のタイムスタンプなど） |
offset |
減衰しないゾーンを作る（decay = 1.0）。ごく最近・ごく近いものにペナルティを与えたくない場合に有効 |
scale |
大きいほど緩やかに減衰、小さいほど急峻に減衰 |
decay |
カーブの急峻さ。低い値（0.3 など）で急降下、高い値（0.7 など）で緩やか。デフォルトは 0.5 |
パラメータの決め方の例です。
- 現在の年を基準点にする →
origin=2026 - 2021〜2026 年の論文は同等に扱い、減衰させない →
offset=6 - スケール距離におけるスコア倍率 →
decay=0.5 - 2010 年の論文の減衰スコアが 0.5 になるようにする →
scale=16（2026 − 2010 = 16）
ベストプラクティス
-
減衰設定は A/B テストする。
scaleとdecayの小さな変更が、ユーザー体験に大きく影響します - 時間関連のパラメータ（
origin、scale、offset）は、コレクションのデータと同じ単位を使うこと - FunctionScore は 1 クエリにつき DecayFunction を 1 つしか受け付けません。 複数の連鎖・合成は現状サポートされていません
- 各 decay ranker は数値フィールドを 1 つしか扱えません
- 疎な、あるいは偏ったフィールドでの減衰は避ける。 null が多い、外れ値がある、分布が極端に偏っているフィールドでは、直感に反する結果になります
Boosting（ブースティング）
Boosting は、ドメイン固有のシグナルをベクトル検索のランキングに組み込むための実用的な仕組みです。
意味検索はクエリが「何について」かは捉えますが、そのドメインで「何がより重要か」は往々にして無視します。Boosting を使うと、任意のメタデータフィールドで結果を並べ替えられる、つまりビジネス上・ドメイン上の直感を検索レイヤに符号化できます。
たとえば論文検索で、2 本の論文がどちらも「deep learning」に関連しているとします。しかし同等に重要とは限りません。引用数の多い論文は、類似度スコアがわずかに低くても上位に出るべきかもしれない。Boosting を使えば、類似度 0.79 で引用 1,200 の論文を、類似度 0.81 で引用 10 の論文より上位にできます。
これは引用数に基づくブースティングで実装できます。シンプルな実装は次の通りです。
では、引用数 100〜1000 の論文をブーストしつつ、さらに新しい論文を優遇する減衰関数も入れたい場合はどうでしょう。FunctionScore クラスを使えば、1 回の検索リクエストの中で、減衰関数と複数の boost ranker を連鎖させられます。
ベストプラクティス
- FunctionScore は現状 dense ベクトル検索でのみサポートされています。 ハイブリッド検索では使えないので、単一のランカーを使ってください
- 連続値フィールドでブーストする場合は、値を離散的なバケットに分けて、バケットごとに異なるブースト重みを割り当てることを検討してください
🇯🇵 補足：日本企業の文書には「格」がある
Decay と Boosting は、日本企業のナレッジ検索でかなり素直に効きます。理由は、日本の組織文書には明確な階層と鮮度の概念があるからです。
Boosting が効く軸の例
| 軸 | 内容 |
|---|---|
| 文書の格 | 本社通達 > 部門規程 > 課内メモ |
| 承認状態 | 承認済み > レビュー中 > ドラフト |
| 版 | 最新版 > 旧版（そもそも旧版は除外したい場合も） |
| 発行元 | 法務・総務の正式文書 > 各部署の運用メモ |
「同じことが書かれた文書が複数あるとき、どれを根拠に答えるべきか」という問題は、RAG の回答品質に直結します。意味的な近さだけで選ぶと、たまたま表現がクエリに近かったドラフトが採用される、ということが起きます。承認状態でブーストしておけば、これを構造的に防げます。
Decay が効く軸の例
日本企業の文書は年度サイクルで改訂されるものが多く、これは減衰関数と相性が良いです。
- 規程・マニュアルの改訂日
- 法令改正への対応時期
- 年度ごとに更新される申請様式
ここで offset が効きます。「今年度中に発行されたものは同等に扱い、それ以前を減衰させる」という設定は、offset を年度の経過月数に合わせることで表現できます。日本の年度は 4 月開始なので、origin を暦年で置くと期待とずれます。年度を基準にするなら、そのように数値を持たせておく必要があります。
組み合わせが本命
原記事にあるように、FunctionScore で減衰と複数のブーストを連鎖できます。日本語のナレッジ検索なら、
- Decay で改訂日の新しさを効かせる
- Boost で承認済み文書と本社発行文書を持ち上げる
という組み合わせが素直な出発点になると思います。ただし注意点として、FunctionScore はハイブリッド検索では使えません。日本語 RAG は BM25 との併用が多いので、ここは構成上の制約になります。dense 単独で回すか、ハイブリッドを選んで FunctionScore を諦めるか、設計時に判断が要ります。
シリーズのまとめ
Milvus 2.6 は、ベクトルデータベースがそのまま使える範囲を広げた、意味のある一歩だと思います。4 回で扱った機能は「あれば嬉しい」ものではなく、これまでデータベースの外で作って保守する必要があった接着剤コードを消すものです。
外部の埋め込みパイプライン、独自のリランキングロジック、部分文字列検索の回避策 —— これらを継ぎ接ぎする代わりに、Milvus のクエリの中で直接表現できます。結果として、アプリケーションコードは整理され、レイテンシは下がり、何かが壊れたときにデバッグすべき可動部が減ります。
Milvus を「単なるベクトルストア」として扱っていたなら、何ができるのか見直してみる価値はありそうです。
🇯🇵 日本語環境では、どこから試すか
シリーズ全体を通しての、優先順位の私見です。
1. N-gram インデックス（第 3 回） —— 日本語の部分一致は業務検索でほぼ必ず要求されます。従来 LIKE %〜% の全走査で我慢していたなら、ここが一番効きます。ただし min_gram=2 から始めることと、正規化済みフィールドを別に持つことの 2 点は必須です。これを飛ばすと「速いが当たらない」状態になります。
2. Decay + Boosting（本記事） —— 承認状態・文書の格・改訂日という、日本企業の文書が元々持っている属性をそのまま使えます。既存のメタデータで始められるので、追加のデータ整備が要りません。ただしハイブリッド検索と併用できない制約は先に確認してください。
3. Lexical Highlighting（第 2 回） —— RAG のデバッグ用途で、日本語の分割が意図通りかを目視確認できます。アナライザ設定の検証ツールとして使うのが、実は一番価値があるかもしれません。
4. Embedding Function（第 1 回） —— 実装は最も楽になりますが、生テキストが外部に出るという前提と、日本語のトークン消費が英語と大きく異なるという 2 点をクリアしてから。閉域要件がある案件では、そもそも選択肢に入りません。
参考リンク
原記事
- A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud（Ivan Tang, 2026年2月11日）
ドキュメント
シリーズ