RAG検索エンジニアリング

翻訳注記：簡体字中国語版は英語レポート RAG Retrieval Engineering を翻訳したものです。技術的な正確性と実行可能性を保つため、製品名、論文名、モデル名、略語、API名、コードブロックは可能な限り原文のまま維持し、中国語版のMermaid図内ラベルのみ中国語に翻訳しています。

エグゼクティブサマリー

職務要件の 「知識リコール戦略(ハイブリッド検索、リランクなど)」 は RAG 検索 検索技術(RAG 検索技術) に直接対応しています。 この方向は時に検索 エンジニアリング(検索エンジニアリング)、検索関連性工学、または Retri 検索評価層 AIアプリケーションエンジニアリング とも呼ばれます。

実際のシステムでは、この作業は企業の生データと大規模言語モデル(LLM)の間に位置しています。コンテンツのチャンキング、インデックス化、フィルタリング、検索、融合、リランキング、コンテキストへの組み立て、そして本番環境での評価、観察、ガバナンスを決定します。 したがって、検索工学は単なる「ベクトル検索」ではなく、しっかりと基盤のあるAIアプリケーションを中心に体系的に リコールレート、精度、レイテンシー、セキュリティ、コスト効率 を最適化する工学分野なのです。

ほとんどのチームにとって、最も堅牢なデフォルトアーキテクチャは以下のもの 2段または3段の組立ライン です:

1. 転置インデックスベースレキシカル検索(BM25)を組み込みおよびANNベースの密ベクトル検索を第1段階リコールレイヤーとして用い、
2. **RRF(相互ランク融合、直近の1 融合)**または正規化加重スコア融合を使ってマルチパス検索結果を統合します。
3. モデルアセンブリコンテキストを生成する前に、候補結果を細かく調整 クロスエンコーダリランキングモデル(クロスエンコーダーリランカー) します。

このパターンは主流のプラットフォーム文書や検索研究で繰り返し現れます。なぜなら、両者は明らかに補完的だからです。レキシカル検索依然として正確な用語、ID、コード、バージョン番号、低頻度ワードの扱いに優れています。 密ベクトル検索は意味的マッチングや同義語の言い換えに優れています。 リランキングは最終候補セットのソート精度を回復するために使われます。

AIアプリケーションエンジニアリングのポジションに備えているなら、しっかりとした学習シーケンスは以下の通りです:

まず、ルセン、BM25、分詞を覚えます。 次に埋め込みと人工ネットワークを学び、 そしてハイブリッド検索とリランキングを学びます。 最後に、評価、オブザーバビリティ、ACLフィルタリング、ガバナンスを学びます。

最初と最後の部分を省略したチームは、まずまずのデモシステムを作れますが、実際のエンタープライズトラフィックや権限の制限、コスト制約の下で失敗することが多いです。

背景

検索 検索拡張生成(RAG)はLLMと外部知識を結びつけ、事前学習データを超えたコーパスに基づく回答を生成するモデルを可能にします。 AWSやGoogleのような組織は、RAGを「まず検索、その後生成する」と公に表現しています。 しかし本番システムでは、この単純な「検索」ボックスがインデックス構築、検索オーケストレーション、フィルタリング、ソート、コンテキストロードを含む大きなサブシステムへと拡大します。

求人票に ハイブリッド検索（Hybrid Retrieval） や リランキング（Rerank） が明示的に言及されている場合、企業が「知識リコール戦略」と呼ぶものは通常、このサブシステムを指しています。

建築的には、検索工学は データインジェスション と 生成/オーケストレーション の間に位置しています。

• 上流依存関係は、解析、メタデータ抽出、ACL継承、テキストチャンキング、埋め込み生成、インデックス構築を文書化します。
• 下流はどの証拠がモデルコンテキストにどの順序で、冗長性が存在するか、適用されるセキュリティ制約を決定します。

品質検索回答の品質に強く影響するため、実際の生産環境で「LLM品質」に該当するように見える多くの問題は、実質的に検索問題です。

flowchart LR
    A[原始数据源] --> B[解析与规范化]
    B --> C[分块与元数据]
    C --> D1[词法索引]
    C --> D2[向量索引]
    U[用户查询] --> Q[查询理解]
    Q --> R1[BM25 检索]
    Q --> R2[稠密检索]
    R1 --> F[混合融合]
    R2 --> F
    F --> RR[重排器]
    RR --> CA[上下文组装]
    CA --> G[LLM 生成]
    G --> O[日志、评测与反馈]
    O --> Q
    O --> C

検索は4種類の責任を担うと理解できます。

1. 表現工学:ワードセグメンテーション、アナライザー、埋め込み、メタデータ;
2. 候補世代(候補者世代):BM25、スパースベクトル、濃密なベクトル、ANN、ハイブリッド検索;
3. 候補 リファインメント(候補者リファインメント):リランキング、フィルタリング、重複除去、多様化、コンテキスト構築;
4. 生産管理:レイテンシーバジェット、キャッシュ、オブザーバビリティ、評価、A/Bテスト、ガバナンス。

この分割方法は、現代の検索エンジンやベクトルシステムのAPI設計とも一致しています。例えば、Elasticsearch Retriever、OpenSearch ハイブリッド検索 pipeline、Pinecone混合検索とリランキング、Qdrant混合クエリ融合、そしてMilvusのフィルタリングおよびマルチインデックス検索です。 大まかに、「広範なリコール」と「精製の選別」を異なる段階に分けています。

コア技術

レキシカル検索

レキシカル検索はエンタープライズグレードのRAGの基盤となっています。 Luceneスタイルの全文検索 転置インデックス（Inverted Index） に基づく依存関係のシステム:用語をそれらを含む文書にマッピングします。 OpenSearchのコンセプトドキュメントは転置インデックスをこのように明確に定義しています。 ElasticsearchやOpenSearchのアナライザーは、文字フィルター、トークナイザー、トークンフィルターのパイプラインを通じてテキストをワード要素に分割します。

これは、検索品質がアナライザー設計に大きく影響されるため重要です。 識別子、キャメルケース、ソースコード、法律用語、製品SKU、多言語テキストはしばしば異なるセグメンテーション戦略を必要とします。

Elasticsearchでは、BM25がテキストフィールドのデフォルト類似モデルです。 ElasticのドキュメントおよびBM25の技術分析では、BM25が以下の要素を包括的に考慮していることが指摘されています。

• 用語頻度;
• 逆文書頻度;
• ドキュメント長正規化。

ここでパラメータk1は単語頻度の飽和度を制御し、パラメータbは文書の長さ正規化の強さを制御します。

実際には、クエリに正確なビジネス用語、低頻度用語、バージョン番号、章番号、エラーメッセージ、製品名が含まれている場合、BM25は通常非常に強力です。 このため、ゼロショットの神経検索シナリオにおいても、BEIRはBM25を堅牢な基準とみなしています。

重要な工学的結論として、優れたレキシカル検索は組み込みモデルを選ぶ前に始まるということです。まずは、その条件 フィールド設計 と アナライザー設計 に依存します。

• 長文の物語テキストは標準的なアナライザーを使うことができます。
• IDやキーワードは正確なマッチングフィールドを必要とする場合があります。
• コードやログは通常、カスタムセグメンテーションを必要とします。
• 多言語コーパスは、言語固有の分析ツールや、同じコンテンツに対して複数のインデックスフィールドを作成する必要があることが多いです。

検索システムが正確なマッチングインテントで性能を発揮しない場合、問題は必ずしも埋め込みモデルではなく、解析器やフィールドマッピングにあることが多いです。

密ベクトル検索とANN

密ベクトル検索テキストを埋め込みとして表現し、完全に同一の単語の重複に頼らず、ベクトル類似性に基づいて検索します。 Pineconeの意味探索序論では、高次元空間の点として高次元空間の高ベクトルを説明し、意味的に類似したテキストが互いに近づくと説明しています。 Elasticsearchの密集ベクトル文書も同様のパターンで、フィールドに対してkNN検索dense_vector行います。

密ベクトル検索の核心的価値は、BM25が得意でない同義語の言い換えや表現の違いを橋渡しすることです。

大規模データの場合、密ベクトル検索は通常、網羅的かつ正確な探索ではなく、近似的な探索です。 コーパスサイズが大きくなると、正確な最近近傍探索のコストが急激に上昇するため、生産システムでは通常、**ANN(近似近傍)**インデックスが使用されます。

HNSWの基礎論文は、制御可能な階層構造を持つ概略的ANNインデックスを提案しました。 現在でも、HNSWは現代のベクトルデータベースで最も広く使われているANNアルゴリズムの一つとして残っています。 MilvusはHNSWを、粗いものから薄いものへの迅速なトラバーサルを支援する多層グラフ構造と説明しています。 Qdrantの検索ドキュメントもHNSWをコアベクトル検索構造として使用しています。

FAISSは、密類似性検索研究およびシステム工学における最も代表的な基礎ツールキットです。 MetaとFaissはこれを効率的かつ密集したベクトル類似性検索とクラスタリングのためのライブラリとして定義し、以下の機能を備えています。

• CPUおよびGPUの実装;
• 多重インデックス構造;
• ベクトル圧縮;
• パラメータ調整;
• メモリに完全に読み込まれていない大規模なコレクションをサポートします。

最近のFaissの論文では、Faiss自体が分散型企業データベースではないことが強調されています。 これは検索ツールキットであり、しばしば上位システムの基盤となるエンジンとして機能します。

異なるANNファミリーは異なる工学的トレードオフに対応しています:

• HNSW:通常は優れたリコール遅延バランスを持ち、比較的直接的なパラメータ調整が可能ですが、メモリ消費が増加することがあります。
• IVF / PQクラス指数:粗い量子化と圧縮によってメモリとコストが削減されますが、通常はより詳細なパラメータ調整が必要です。パラメータが誤ると品質損失検索原因となることがあります。

OpenSearchのFaiss製品定量化ドキュメントによると、PQはFaissベースのHNSWまたはIVF ANNと組み合わせて使用可能であるとされています。 Elasticsearchの濃密なベクトルドキュメントは、浮動小数点ベクトル向けの組み込み量子化機能も備えており、量子化によるベクトル検索メモリコスト削減という業界全体の傾向を反映しています。

ハイブリッド検索と結果融合

ハイブリッド検索語彙信号と意味信号を組み合わせます。なぜなら、両者の失敗パターンは補完的だからです。 Pineconeのハイブリッド検索ガイドでは、ハイブリッド検索を濃密なベクトルとスパースベクトルの両方を単一のリクエストに組み合わせることと定義しています。 QdrantとOpenSearchは、結果融合前に密ベクトル検索とレキシカル検索を組み合わせることをサポートしています。

企業コーパスにおいて、ハイブリッド検索は通常、真剣に投資する価値のある最初の基準です。 例えば:

• ユーザーは「SOX scope control 2.3 revision」と検索することがあります。
• 別のユーザーは「財務承認権限をどのように制限するのですか?」と検索するかもしれません。 ”

前者は正確な単語項目に大きく依存し、後者は意味一致により依存し、両者とも異なる検索信号を必要とします。

最も単純で堅牢な融合方法は RRF(相互ランク融合、直近の1 融合) です。 ElasticsearchのRRFドキュメントでは、異なる相関スコアスケールを調整せずに複数の結果セットを統合する方法として説明されています。 標準的な形式は以下の通りです:各結果は結果セット内の順位に基づいて最終スコアに寄与します。

1 / (k + rank)

OpenSearchのScore Ranker ProcessorもRRFを使って異なるクエリ節の結果を組み合わせています。

RRFは、BM25スコアとベクトル類似度スコア間の脆弱なスケールキャリブレーションを避けるために人気があります。 すべてのリトリーバーが基本的に合理的なソートを出せる限り、RRFは驚くほど堅実な結果を出すことが多いです。

分画校正が可能であれば、**加重融合(加重フュージョン)**安定領域において単純なRRFを上回る性能を持つことがあります。 OpenSearchの正規化プロセッサおよびハイブリッド検索ガイドは、以下のプロセスを説明しています。

1. 各経路のスコアを正規化し、
2. 組み合わせには加重算術平均、調和平均、幾何平均が用いられます。

OpenSearchのハイブリッド検索技術に関する記事では、語彙信号と意味信号間の明示的な重み付け算術融合も示されています。 Qdrantは RRF や DBSF に基づく融合ランキングもサポートし、検索スコアに加えてタイムリーや人気度などのビジネスロジックをカスタムスコア計算式で重ね合わせることができます。

したがって、明確なデフォルトアプローチは次の通りです:

1. まずは BM25 + 密ベクトル検索 + RRF から始めましょう。
2. すでにドメイン注釈データがあり、スコア分布が比較的安定している場合は、正規化加重融合にアップグレードしてください。
3. BM25、密ベクトル検索、スパース検索、タイムアッテュイション、オーソリティなど、2つ以上の信号を組み合わせる必要がある場合は、フェーズ設計を優先すべきです。まずチャネル融合検索、次にリランキングを実行し、最後にビジネスルールを適用します。

上記の表は、BEIRで報告された典型的な挙動、各種ベンダーによる混合検索文書、そして後のインタラクティブ検索文献をまとめたものです。

リランキング

リランキングは、幅広い候補のプールを正確な最終候補セットへと変貌させる洗練されたステージです。 Pinceoneのリランキングドキュメントはリランキングを2段階のプロセスとして説明しています。まず収集検索 候補、その後リランキングモデルを用いてクエリと候補文書の相関に基づいてクエリや文書を並べ替えています。

これはRAGにおける最も標準的なパターンの一つであり、検索の第一段階の最適化目標は通常、最終的なソート精度ではなく速度と高いリコール率であることが目的です。

最も一般的なリランキング装置は クロスエンコーダ です。 Sentence Transformersのドキュメントは、デュアルエンコーダとクロスエンコーダの違いを明確に説明しています。

• バイエンコーダー:クエリとドキュメントを別々にエンコードすること;
• クロスエンコーダ:クエリドキュメントは、フェデレーテッド入力モデルをペアリングして直接相関スコアを出力します。

クロスエンコーダは通常より正確ですが、候補セットが大きいとかなり遅くなります。 Elasticsearchのセマンティックリランキングドキュメントも同様の区別をしており、そのセマンティクスリランキングクロスエンコーダのサポートを指摘しています。 したがって、クロスエンコーダは通常、コーパス全体ではなく最初の20~100 候補結果にのみ適用されます。

いわゆる 「リランキングに似たデュアルエンコーダーの改良」 は本質的に依然として強力な第一段階密ベクトル検索です。文書ベクトルを事前に計算できるため、大規模なコーパスにスケールできます。 しかし、スコアリング時には、特定のクエリと特定の段落間のトークンレベルの相互作用を完全にモデル化することはできません。

実用的な理解のルールは次の通りです:

• デュアルエンコーダは大規模なコーパスへの拡張に使用されます。
• クロスエンコーダは候補ショートリストの精査に使われます。
• ColBERTのような後期段階のインタラクションモデルはこの二つの中間に位置し、より高いストレージオーバーヘッドをトークンレベルのマッチングに置き換えています。

「意味探索は単一の技術ではない」と説明する必要があるなら、ColBERTv2やLoTTE 評価システムが代表的な参考文献です。

LLMベースのリランキングまた、特にホスティングされたリランキング APIの導入により、ますます実用的になっています。 Cohereの公式ドキュメントでは、リランキングモデルを次のように説明しています:クエリに基づいて意味的関連性でテキストをソートすること; Pineconeはまた、クエリを受け取り、文書リストを候補し、新しいソートを返すマネージド・リランキングエンドポイントも提供しています。

ツールリランキング自分でトレーニングするよりも、これらのソリューションは運用面では簡単ですが、APIコスト、ネットワーク遅延、データガバナンスの問題が生じるため、小規模な候補セット、プロトタイプ検証、高価値ワークフローにより適しています。

蒸留は、大規模な交通状況下でリランキング品質を維持する必要がある場合に重要です。 PairDistillのような最近の研究では、より強力なペアワイズソートモデルやLLM リランキングがより高速なリトリバーを監督し、オンラインサービスのコストを低くしながらリランキング品質の大部分を維持できることが示されています。

産業的な観点から見ると、蒸留は「良い結果だが遅すぎる」を「十分で許容できるコスト」へと変える橋渡しです。

クエリ理解、フィルタリング、チャンキング、コンテキスト構築

クエリの理解は、プロジェクト検索エージェントプロジェクトと交差し始めるポイントです。

クエリの書き換え、情報不足、依存関係コンテキスト、会話型ユーザー入力を検索に適した形に変換できます。 Rewrite-Retrieve-Readの論文は、クエリの書き換え自体がLLMのパフォーマンスを向上させ検索向上させる可能性があることを示しています。 RaFeやDMQR-RAGなどの新しい研究では、ソートフィードバックや多様化された複数クエリの書き換えも用いられています。

本番環境では、クエリの書き換えは特に以下の状況に適しています。

• ユーザー質問は重要な情報を省略しています。
• 現在の問題は過去の対話に依存しています。
• ユーザー入力には多くのタスク命令が含まれていますが、検索に本当に適したキーワードは非常に少なく、
• 元の表現はナレッジベースの文書の言語と大きく異なります。

クエリ拡張（Query Expansion） 関連用語や疑似文書を追加することでカバレッジを拡大する。 Query2docは、LLMによって生成される擬似文書がスパース検索や密ベクトル検索を向上させることを示しています。 HyDEは少し異なります。「仮想的な関連文書」となり、文書を埋め込み、そのベクトルを検索クエリとして使います。

どちらのアプローチも、「関連性」がユーザーの元の短いクエリではなく文書形式で表現されやすい場合に効果的かもしれません。 HyDEは特にゼロサンプルやラベル希少環境に適しています。

エンタープライズレベルのRAGでは、メタデータフィルタリングとACLフィルタリングは交渉の余地がありません。 Pinecone、Qdrant、Milvus、Elasticsearch、OpenSearchはいずれもメタデータやペイロードフィルタリングを提供していますが、真のアクセス制御のサポートは異なります。

• PineconeとQdrantはメタデータフィルタリングによる範囲の狭検索化をサポートしています。
• Milvusは検索およびスカラー述語のフィルタリングをサポートしています。
• ElasticsearchとOpenSearchは、ロールベースの読み取り分離のためのドキュメントレベルおよびフィールドレベルのセキュリティ制御も提供しています。

もし単に「2025年分の製品ドキュメントを表示する」という要件であれば、メタデータフィルタリングで十分かもしれません。 もし要件が「金融ユーザーは絶対に人事専用の段落を通検索してはならない」なら、ネイティブ検索エンジンのアクセス制御ははるかに重要になります。

**チャンキング（Chunking）**はしばしば過小評価されています。 最近の研究では、チャンキング戦略、ブロックサイズ、重なりの長さ、コンテキスト施工方法がRAGの信頼性に測定可能に影響を与えることが示されています。 2025年の研究では、遅期チャンク化とコンテキスト検索を比較しました。 2026年の調査では、工業構造下でブロックの種類、ブロックサイズ、重複区間、コンテキストの長さが検証されました。

堅牢な結論は「すべてのシナリオに有効なブロックサイズがある」ではなく、「チャンキングは 答え:細かいこと と リトリーバーは能力の境界を表します に一致すべきだ」ということです。

ナラティブビジネス文書の一般的な出発点は以下の通りです。

• 各作品は約300～800 Token;
• 適度な重なりを活用すること;
• 評価クラスターに基づくさらなる最適化。

コード、テーブル、構造化された機関文書の場合、構造認識チャンキングは通常、単純な固定ウィンドウよりも優れています。 この推奨は、関連する研究から部分的には、また研究結果に基づく工学的推論に基づいています。

たとえ結果検索「正しかった」としても、組み立てコンテキスト依然として重要です。 Lost in the Middle研究によれば、言語モデルは長い時間の中間に置かれた証拠を完全には活用していない可能性があるコンテキスト。 したがって、検索エンジニアは最初の10個のチャンクを元のスコア順に無理やりプロンプトに詰め込むべきではありません。

より良い組み立て戦略には通常以下が含まれます:

• 重複の除去;
• 文書別グループ化;
• 最も価値の高い証拠を最優先にすること;
• 多様性を維持するために異なる情報源からの証拠を絡み合って配置すること;
• 新しいコンテキストの限界効用が減少したら、積極的に切り詰めます。

これは検索工学とプロンプト工学の重なりの典型的な例です。

flowchart TD
    Q[用户查询] --> U1[改写或扩展]
    Q --> U2[实体与元数据提取]
    U1 --> L1[词法检索]
    U1 --> L2[稠密检索]
    U2 --> F1[元数据或 ACL 过滤]
    L1 --> H[混合融合]
    L2 --> H
    F1 --> H
    H --> R[交叉编码器或 LLM 重排]
    R --> D[去重、多样化与分组]
    D --> P[Prompt 上下文打包器]
    P --> M[LLM]

ベクトルシステムと製品選定

FAISSは理解に最も価値のある基礎となるANNライブラリですが、本番検索エンジニアは統合検索エンジンとベクトルデータベースのどちらかを選ぶ必要があります。

• Elasticsearch / OpenSearch:通常、全文検索、ハイブリッド検索、セキュリティ制御を同一プラットフォーム上で統合する必要がある場合に最大の利点があります。
• Qdrant:現代ハイブリッド検索、フィルタリングベクトル検索、柔軟なクエリ融合において卓越した性能;
• Milvus:オープンソースの分散型ベクトルデータベースを必要とするチームや、複数のタイプのANNインデックスをサポートしたいチームに適しています。
• Pinecone:マネージドオペレーション、サーバーレス展開、マネージド推論サービスを重視するチームに適しています。

上記の表は、さまざまなメーカーの公式文書およびFAISSの基礎研究文献を要約したものです。

実装ガイド

これを実用的に実装する方法は、**2つの検索曲面(検索曲面)**を保持することです:

• ElasticsearchまたはOpenSearchで動作するレキシカル検索サーフェス、
• ベクトル検索は同じエンジン上で動作するか、Qdrant、Milvus、Pineconeのような専用ベクトルバックエンドを使うことができます。

組織がすでにLuceneベースの検索システムを広範に利用している場合、まずElasticsearchやOpenSearchからレキシカル検索とベクトル検索の両方を扱うのが、最も抵抗の少ない道筋となります。

もし大規模な意味検索が主な課題で、迅速に実験したいなら、QdrantやPineconeをLuceneベースのエンジンと組み合わせることができます。前者はベクトル意味リコールを担当し、後者は語彙リコールとアクセス制御を担当します。

以下の例は以下の通りです:

• Python；
• LangChainスタイルのアプリケーション結合法;
• Qdrant ベクトル 保管として;
• OpenSearch / Elasticsearch 語彙層として;
• クロスエンコーダ リランキングデバイスとして。

パッケージ名や二次APIは、特にLangChainの異なるバージョン間で進化し続けるでしょう。 稼働前に依存バージョンをロックし、アーカイブされたv0.xページの代わりに現在のLangChainドキュメントを使うべきです。 LangChain v1の移行ガイドには、検索補助コンポーネントの一部が移動またはインポート経路を変更したことが明確に記載されています。

例：チャンキング、Embedding、Qdrantによる取り込みパイプライン

from typing import List
from dataclasses import dataclass

from langchain_openai import OpenAIEmbeddings
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_core.documents import Document

from qdrant_client import QdrantClient, models

@dataclass
class ChunkedDoc:
    id: str
    text: str
    metadata: dict

def chunk_documents(raw_docs: List[Document]) -> List[ChunkedDoc]:
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=600,
        chunk_overlap=80,
        separators=["\n\n", "\n", ". ", " ", ""],
    )
    out: List[ChunkedDoc] = []
    for i, doc in enumerate(raw_docs):
        pieces = splitter.split_text(doc.page_content)
        for j, piece in enumerate(pieces):
            meta = dict(doc.metadata)
            meta["chunk_id"] = j
            out.append(
                ChunkedDoc(
                    id=f"{meta.get('doc_id', i)}:{j}",
                    text=piece,
                    metadata=meta,
                )
            )
    return out

emb = OpenAIEmbeddings(model="text-embedding-3-large")
client = QdrantClient(url="http://localhost:6333")

collection_name = "kb_chunks"
dim = len(emb.embed_query("dimension probe"))

client.recreate_collection(
    collection_name=collection_name,
    vectors_config=models.VectorParams(size=dim, distance=models.Distance.COSINE),
)

def upsert_chunks(chunks: List[ChunkedDoc]) -> None:
    texts = [c.text for c in chunks]
    vecs = emb.embed_documents(texts)

    client.upsert(
        collection_name=collection_name,
        points=[
            models.PointStruct(
                id=chunk.id,
                vector=vec,
                payload={"text": chunk.text, **chunk.metadata},
            )
            for chunk, vec in zip(chunks, vecs)
        ],
    )

これは一般的な密集型データ取り込みプロセスで、チャンキング、埋め込み生成、メタデータの付付、そしてUpsertです。 Qdrantのドキュメントはペイロードインデックス化とフィルタリング機能を強調しているため、メタデータ設計はシステム確立後に追加するのではなく、プロジェクトの初期段階で完了すべきです。

例：ElasticsearchまたはOpenSearchによるレキシカルインデックス

from opensearchpy import OpenSearch

os_client = OpenSearch(
    hosts=[{"host": "localhost", "port": 9200}],
    http_compress=True,
)

index_name = "kb_lexical"

mapping = {
    "settings": {
        "analysis": {
            "analyzer": {
                "default": {"type": "standard"}
            }
        }
    },
    "mappings": {
        "properties": {
            "title": {"type": "text"},
            "body": {"type": "text"},
            "doc_id": {"type": "keyword"},
            "tenant_id": {"type": "keyword"},
            "created_at": {"type": "date"},
            "acl": {"type": "keyword"},
        }
    },
}

if not os_client.indices.exists(index=index_name):
    os_client.indices.create(index=index_name, body=mapping)

def index_lexical(doc_id: str, title: str, body: str, tenant_id: str, acl: list[str]):
    os_client.index(
        index=index_name,
        id=doc_id,
        body={
            "title": title,
            "body": body,
            "doc_id": doc_id,
            "tenant_id": tenant_id,
            "acl": acl,
        },
        refresh=True,
    )

このコードはBM25をサポートし、テナント隔離やACL対応フィルタリングに必要なメタデータフィールドを明示的に定義するレキシカル検索を作成します。 システムがドキュメントレベルまたはフィールドレベルのセキュリティを必要とする場合、アプリケーション層フィルタリングのみに頼るのではなく、ネイティブな検索エンジン制御を優先すべきです。

例：クライアント側RRFによるハイブリッド検索

from collections import defaultdict
from typing import Any

def lexical_search(query: str, tenant_id: str, k: int = 20) -> list[dict[str, Any]]:
    resp = os_client.search(
        index=index_name,
        body={
            "size": k,
            "query": {
                "bool": {
                    "must": [{"multi_match": {"query": query, "fields": ["title^2", "body"]}}],
                    "filter": [{"term": {"tenant_id": tenant_id}}],
                }
            },
        },
    )
    return [
        {
            "id": hit["_id"],
            "text": hit["_source"]["body"],
            "score": hit["_score"],
            "source": "bm25",
        }
        for hit in resp["hits"]["hits"]
    ]

def dense_search(query: str, tenant_id: str, k: int = 20) -> list[dict[str, Any]]:
    qvec = emb.embed_query(query)
    points = client.query_points(
        collection_name=collection_name,
        query=qvec,
        limit=k,
        query_filter=models.Filter(
            must=[models.FieldCondition(
                key="tenant_id",
                match=models.MatchValue(value=tenant_id)
            )]
        ),
        with_payload=True,
    ).points
    return [
        {
            "id": str(p.id),
            "text": p.payload["text"],
            "score": p.score,
            "source": "dense",
        }
        for p in points
    ]

def rrf_fuse(rankings: list[list[dict[str, Any]]], rank_constant: int = 60) -> list[dict[str, Any]]:
    scores = defaultdict(float)
    doc_store = {}
    for ranking in rankings:
        for rank, item in enumerate(ranking, start=1):
            scores[item["id"]] += 1.0 / (rank_constant + rank)
            doc_store[item["id"]] = item
    fused = sorted(scores.items(), key=lambda x: x[1], reverse=True)
    return [{**doc_store[doc_id], "rrf_score": score} for doc_id, score in fused]

def hybrid_search(query: str, tenant_id: str, k: int = 30) -> list[dict[str, Any]]:
    bm25_hits = lexical_search(query, tenant_id, k)
    dense_hits = dense_search(query, tenant_id, k)
    return rrf_fuse([bm25_hits, dense_hits])[:k]

バックエンドがすでにRRFやハイブリッド検索パイプラインをネイティブサポートしている場合は、ネイティブ機能に優先順位を置くべきです。 ElasticsearchはRRF Retrieverを提供し、OpenSearchはスコア正規化された加重融合とランクベースの融合パイプラインの両方を提供しています。 上記のクライアント実装は、概念的なベースラインおよび局所的な実験的実装として適しています。

例：クロスエンコーダによるリランキング

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")

def rerank(query: str, candidates: list[dict[str, Any]], top_n: int = 8) -> list[dict[str, Any]]:
    pairs = [(query, c["text"]) for c in candidates]
    scores = reranker.predict(pairs)
    rescored = [{**c, "rerank_score": float(s)} for c, s in zip(candidates, scores)]
    rescored.sort(key=lambda x: x["rerank_score"], reverse=True)
    return rescored[:top_n]

Sentence Transformersのドキュメントでは、クロスエンコーダがどのようにリランキングで使われるかが具体的に説明されています。 PineconeやCohereも同等のマネージドリランキング APIを提供しています。 自分でモデルをホストしたくない場合は、リランキング能力をサービス境界の後ろに配置することもできます。

例：HyDE形式のクエリ拡張

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4.1-mini", temperature=0)

HYDE_PROMPT = """
Write a concise hypothetical passage that would answer the question below.
Do not explain what you are doing.

Question: {question}
"""

def hyde_expand(question: str) -> str:
    return llm.invoke(HYDE_PROMPT.format(question=question)).content

def hyde_search(question: str, tenant_id: str, k: int = 20):
    hypothetical_doc = hyde_expand(question)
    qvec = emb.embed_query(hypothetical_doc)
    # then use dense_search-like logic with qvec

これはHyDEのアプローチの簡略化デモンストレーションであり、完全な本格的な実装ではありません。 その核心的なコンセプトはHyDEの論文に由来します。つまり、Mr.は仮想の関連文書となり、それを埋め込み、さらに隣接する実際の文書検索します。

推奨技術スタック

評価とテスト計画

オフライン評価は基本です。 検索システムにとって最も重要な指標は以下の通りです:

• Recall@K；
• Precision@K；
• MRR；
• nDCG。

Pineconeのオフラインの評価ガイドとEvidentlyのランキング指標ガイドは、これらの指標の重要性をまとめています。

• Recall@K 最初のK結果のカバレッジをすべての関連文書で測定すること;
• Precision@K 上位Kの成績に関連文書の割合を測定候補;
• MRR 最初に関連する結果が出たものに報酬を与える;
• nDCG ランキング順位を考える際に階層的相関タグを用いてソートの品質を測定します。

実際には、第1段階検索コアインジケーターは通常Recall@Kです。 システムがリランキングに加わると、nDCG@10やMRR@10は特に価値が高まります。

ベンチマークの選択は、ドメインや言語環境に合致している必要があります:

• BEIR:依然として最も重要な広範なゼロショット検索ベンチマークであり、稀で密度の高い後期段階の相互作用およびリランキング手法を異種なタスクで比較するのに適しています。
• MIRACL:18言語に対応した多言語単一言語検索;
• MTEB:複数のタスクと言語をカバーする広範な組み込み評価フレームワークを提供します。
• LoTTE:多くの古いベンチマークと比べると、ロングテールのテーマ検索より近いです。
• TREC RAG:システム生成のためのエンドツーエンドのパブリックベンチマーク(検索)を提供します。

オンラインテストは「新しいRetrieverにランダムに本番トラフィックを切り替える」から始めるべきではありません。 より信頼性の高い発射シーケンスは以下の通りです:

1. オフライン検索評価；
2. シャドウトラフィック；
3. スモールフロースライシングA/B試験；
4. 打ち上げの範囲を拡大。

LangSmithのようなオブザーバビリティプラットフォームは、エージェントやRAGの動作を追跡・評価するために使われています。 OpenTelemetryは標準化されたトレース、メトリクス、ログのインフラストラクチャを提供します。 これらを合わせることで、実際のトラフィック下で異なる検索バージョンを比較するために必要な最小限の観察能力を提供します。

実用的なテスト行列は、少なくとも以下をカバーすべきです:

• 単一ラウンドおよび複数ターンのクエリ;
• 正確なワードクエリと緊張的な書き換えクエリ;
• テナントフィルタリング付きクエリとフィルタリングなしのクエリ、
• 短い文書と長文文書の両方;
• 通常のクエリと対抗的クエリです。

各スライスは回答の質だけでなく、以下の点も追跡すべきです。

• 空ヒット率；
• フィルターヒット率；
• リランカーの落下率(リランキング 落下率；
• P95遅延；
• リクエストごとのコスト。

検索設計はしばしばこれらの運用指標にまず問題を露呈します。 この提案は上記のオブザーバビリティとツールに基づく工学的推論評価です。

デプロイチェックリスト

公開前にまず確認データパス:

• パーサーが文書の境界や重要な構造を保持しているかどうか;
• チャンクIDが安定しているかどうか;
• メタデータが正規化されているかどうか、
• ACLに関連する属性が検索層に伝播されるかどうか、
• 各チャンクが元のドキュメントや特定の章に遡ることができるかどうか。

結果検索出典のトレーサビリティを失うと、システムのデバッグが困難になります。

次に確認検索道:

• リランキングを可能にする前に、BM25、密ベクトル検索、ハイブリッド検索の基準線を別々に測定しました。
• クリアなリコールレート(遅延ターゲット、
• メタデータフィルタリングを使用する場合、フィルタリングされたフィールドのインデックスはできるだけ早く作成すべきです。 QdrantもPineconeも、フィルタリングの性能はフィールドのモデリングやインデックス付けの方法に依存することを強調しています。
• OpenSearch加重融合を使用する場合、正規化済みおよび結合構成はバージョン付き構成に保存し、実験の再現性を確保します。

次に、精密経路を確認してください:

• リランキング遅延予算で許された量の1 候補のみを対象としています。
• クロスエンコーダやマネージドリランキング APIは一般的に超大規模候補セットには適さないため、2段階検索が存在します。
• より高いスループットが必要な場合は蒸留や圧縮を検討すべきです。
• 複雑な段落の品質が不十分な場合は、無謀にスケーリングするのではなく、まずポストプロダクションのインタラクションモデルやより合理的なチャンキングをテストすべきですリランキング。

次に確認走行経路:

• クエリキャッシュを増やす;
• 埋め込みキャッシュの増加;
• 適切なシナリオでは応答バッファを増やし、
• OpenTelemetryを用いてエンドツーエンドの経路のトレース、指標、ログを収集すること;
• 空の結果率、リランキングキュー時間、平均検索トークン数、リクエストあたりのコストを追跡検索専用ダッシュボードを作成しましょう。

Redisは高性能なキャッシュおよびデータシステムとして位置づけられ、ベクトル機能をサポートするため、人気のあるクエリキャッシュを実現する実用的な方法となっています。

最終検証安全保障とガバナンスの経路:

• エンタープライズシステムでは、単純なメタデータフィルタリングでは通常不十分です。
• 必要に応じて文書レベルおよびフィールドレベルの権限管理を活用し、
• 多目的の組み合わせを慎重にテストし、
• 攻撃者が検索チェーンを通じてプロンプトを注入しようとしたとします。
• OWASP LLM トップ10は、プロンプトインジェクション、機密情報漏洩、サプライチェーンの問題、データ中毒を中核リスクとして挙げています。
• NISTのプライバシーおよびリスク管理フレームワークは、AIシステムにおけるプライバシーおよびリスクガバナンスに関するより広範な指針を提供します。

リリースの簡潔なリストは以下の通りです。

• 少なくとも主要なクエリタイプにはタグ付き評価セットが確立されています。
• BM25、密ベクトル検索、ハイブリッド検索、リランキングのベースラインがそれぞれ測定されました。
• 対抗的なユースケースはACLやテナントフィルタリングのテストに用いられました。
• P50、P95、残業代の予算は検索とリランキングに設定されています。
• オブザーバビリティシステムはトレース、メトリック、ログ、検索ドキュメントおよびコストを収集します。
• Retriever、融合モード、Rerankerはいずれもロールバックスイッチを備えています。
• 各デプロイメントはバージョンとインデックスバージョンを記録チャンキング;
• 文書化されたデータ保持、プライバシー、インシデント対応のルール。

これらの要素は、関連するプラットフォームのドキュメントから直接得られるか、プラットフォームの能力やリスクに基づく保守的な本来の生産工学的推論です。

推奨学習ロードマップ

ステップ1:RAGを専門にする前に、**古典情報検索検索(古典情報検索)**を学びましょう:

• 転置インデックス；
• 分詞;
• アナライザー;
• BM25；
• ルセンの基本的なメンタルモデル。

OpenSearchのコンセプトガイド、Elasticsearchのアナライザーとセグメンテーションのドキュメント、そしてBM25の説明は、教科書から本検索の検索エンジンへの情報概念をつなぐ優れた実践的な出発点です。

ステップ2:密ベクトル検索とANNを学ぶ:

• HNSWの論文を読んでみてください。
• ファイスの論文および最新のファイスの文書を読み、
• Milvus、Qdrant、Pinecone、ElasticsearchがANN、フィルタリング、量子化、ハイブリッド探索をどのように実装しているかを学びましょう。

このシーケンスは、アルゴリズム的視点とシステム視点の両方を同時に確立することができます。

ステップ3:ハイブリッド検索とリランキングを学ぶ:

1. 純粋なBM25基準値の達成;
2. 純粋な密ベクトル検索基準の達成;
3. BM25 + 密ベクトル検索 + RRFを実装;
4. クロスエンコーダリランキングの追加;
5. 最後に、加重型融合、DBSF、相互作用後解析、蒸留法が研究されました。

この順序は実際のシステムの成熟度の段階と一致し、早期最適化を避けるのに役立ちます。

ステップ4:探求、理解、そしてチャンキングの勉強:

• Query2doc；
• HyDE；
• Rewrite-Retrieve-Read；
• 最近のチャンキング評価研究。

面接では、「クエリの書き換えを優先すべき時とチャンキング調整すべき時」を説明できる候補は、用語だけを挙げる人よりも目立つ傾向があります。なぜなら、前者は失敗パターンを分析しているからです。

最後に、評価・オブザーバビリティと統治を学びましょう:

• BEIR、MIRACL、MTEB、TREC RAGを使用しています。
• LangSmithや類似プラットフォームをOpenTelemetryと組み合わせて検索スタックの観測機能を強化すること;
• OWASPおよびNISTガイドラインを用いてシステムリスクをマッピングすること。

この部分こそが検索デモシステムをエンタープライズレベルのAIアプリケーションへと変貌させるのです。

結論

求人情報で強調されている要件は、明らかにAIアプリケーションエンジニアリングの広範な RAG 検索工学 に属しています。

具体的には、検索層全体をカバーしています:

• レキシカル検索；
• Embedding；
• ANN；
• 混合融合;
• リランキング；
• クエリの書き換えと拡張;
• メタデータとACLフィルタリング;
• チャンキング；
• コンテキスト集会;
• 評価；
• オブザーバビリティ；
• ガバナンス。

求人情報に ハイブリッド検索 と Rerank が記載されている場合、それはベクトルデータベースAPIだけを呼ぶエンジニアではなく、検索層全体をプロとして設計・評価・運用できる人を求めています。

2026年までに、最も信頼性の高いデフォルトアーキテクチャは依然としてフェーズドシステムとなるでしょう。

BM25+ 密ベクトル検索で高い リコール レートを達成し、RRF や加重融合を用いたハイブリッドソートを実施し、クロスエンコーダリランキング精度を向上させ、厳格なメタデータ/ACL フィルタリングを強制し、オフラインおよびオンラインの規律ある評価システムを確立します。

この基盤により、チームはポストプロダクションのインタラクション、蒸留、より豊かなクエリ理解、ドメイン固有の最適化へとさらに進めることができます。 しかし、この基準がなぜ機能するのか、どのように測定し、本番環境で安全に運用するかを説明できれば、すでに職務要件に直接関連するコア知識ができているということです。