こんにちは、@shin0higuchi です😊
この記事は、Elastic Stack (Elasticsearch) Advent Calendar 2025の23日目の記事です。
昨年のアドベントカレンダーでは、Elasticsearchを用いたRAGに関する記事を執筆しました。
acro-engineer.hatenablog.com
この1年でElasticsearchの inference API と retriever はさらに成熟し、実戦投入しやすい状態になりました。今回は、重要要素の1つであるリランクについて、Elasticsearchで現状できることを整理します。
2つの選択肢：外部APIか、内部モデルか？
Elasticsearchでリランク（Reranking）を導入する際、現在は大きく2つの選択肢があります。
現場では単純な機能比較だけではなく、コスト構造とレイテンシで選ぶことも必要になってきます。
| 特徴 | 外部 Rerank API (Vertex AI, Cohere等) | Local Inference (Elastic Rerank / Eland) |
|---|---|---|
| 強み | 圧倒的な知識量。 LLMベースのモデルが「文脈」を深く理解する。 インフラ管理不要。 |
データ局所性。 データが外に出ない（セキュリティ）。 ネットワーク遅延が小さい。 |
| コスト構造 | 従量課金。 クエリ数ベースで課金。 スパイク時にコスト増のリスクあり。 |
固定費。 MLノード（メモリ/CPU/GPU）のインスタンス費用のみ。 利用量に比例しない。 |
| 向いている場面例 | Eコマース、FAQ検索 | 社内文書検索（秘匿性高）、 低レイテンシが必要なAutoComplete |
ここではそれぞれの使い方や特徴を見ていきましょう。
実践1：外部Rerank API とのネイティブ連携
2025年現在、Elasticsearchは Google の VertexAI サービスをネイティブサポートしています。
Googleが提供するランキングモデルを、あたかもElasticsearchの一機能のように呼び出すことが可能です。
同様に、Google以外のAWS / Azure やOpenAIなど、各ベンダーが提供するランキング／リランクモデルも、外部API連携として呼び出し対象にできます。
設定：Inference Endpointの作成
Vertex AIのランキングモデルは、`model_id` に公式のIDを指定します。代表例は次の通りです。
- semantic-ranker-fast-004
- semantic-ranker-default-004
- semantic-ranker-default@latest
（fast系は低レイテンシ、default系は精度寄り。@latest は互換性に注意して運用）
PUT _inference/rerank/vertex-ranker { "service": "googlevertexai", "service_settings": { "service_account_json": "<SERVICE_ACCOUNT_JSON>", "project_id": "<PROJECT_ID>", "location": "<REGION>", "model_id": "semantic-ranker-fast-004" }, "task_settings": { "top_n": 10 } }
検索：Retrieverでの利用
検索クエリは retriever を使います。
ここで重要なのは rank_window_size です。デフォルトは10ですが、50〜100程度で検証する例もよく見かけますね。
ただし、rank_window_size を大きくしすぎるとGoogleへのAPIコストとレイテンシが跳ね上がるので、ログやA/Bで最適値を決めるのが安全かと思います。
POST /my-index/_search { "retriever": { "text_similarity_reranker": { "retriever": { "standard": { "query": { "match": { "content": "RAG architecture trends" } } } }, "field": "content", "inference_id": "vertex-ranker", "inference_text": "RAG architecture trends", "rank_window_size": 50, "min_score": 0.5 } } }
これで、Elasticsearchの1次検索結果がGoogleのサーバーに送られ、Vertex AIのランキングモデルで高精度に並び替えられて返ってきます。RAG（検索拡張生成）の前段として、極めて精度の高いドキュメントをLLMに渡したい場合に最適です（認証は `service_account_json` の設定が必須）。
とても簡単ですね。
実践2：Hugging Face / Elastic Rerank の活用
「社外にデータを出せない」「100ms以内で返したい」という場合は、Elasticsearchクラスタ内での推論（Local Inference）一択です。
2025年の今なら Elastic社純正の Elastic Rerank モデルを使うのが最も手軽かと思いますが、
日本語に特化したモデルや、独自ドメインで学習させたモデルをインポートしたい場合はHugging Faceのモデル（BGE-M3など）をElandで持ち込むのも良いと思います。
ただし、Eland取り込み時の `task_type` は `text_similarity` になる点に注意してください（rerank専用タスクはありません）。
Elandによるモデル取込みは、少し前ですがこちらの記事で書いているので是非ご覧ください。
acro-engineer.hatenablog.com
設定：Local Inference Endpoint
Elasticsearch内蔵の `elasticsearch` サービスとして定義します。スレッド数はCPUコア数に合わせて調整しましょう。
PUT _inference/rerank/my-local-elastic-ranker { "service": "elasticsearch", "service_settings": { "model_id": ".rerank-v1", "num_allocations": 1, "num_threads": 4 } }
※ローカル推論を行う場合、MLノードのリソース確保が必要です。必要メモリはモデルと同時推論数で変動するため、最初は低い並列から始めて段階的に調整するのが安全です。
あとはVertex AIの時と同様、retriever クエリで `my-local-elastic-ranker` を指定するだけです。
アプリ側のコードを一切変えずに、バックエンドの設定だけで「Google Vertex AI」と「ローカルモデル」を切り替えられるのが、この Inference API の真骨頂と言えるでしょう。
まとめ
今回は、Elasticsearchのリランク最新事情として、外部クラウドサービスとの連携と、ローカルモデルの活用について解説しました。
- 外部Rerank API連携: 圧倒的な精度を手軽に導入できる。RAGの切り札。
- 自前リランク: ドメインデータで学習したモデルを運用可能。
- Elastic Rerank / Cross-Encoder: セキュアかつ低レイテンシ。
- Interfaceの統一: アプリ側からは同じクエリで扱える。
ここまで来ると、Elasticsearchは単なる検索エンジンにとどまらず、複数のAIモデルを統合する「AI検索オーケストレーター」のような存在になって来ていますね。
年末年始、こたつで寛ぎながら、ぜひ皆さんの環境でもリランクを試してみてください。
それでは、良いお年を！
Acroquest Technologyでは、キャリア採用を行っています。
- Azure OpenAI／Amazon Bedrock等を使った生成AIソリューションの開発
- ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
- マイクロサービス、DevOps、最新のOSSやクラウドサービスを利用する開発プロジェクト
- 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
