blog シナモンブログ

【第5回】ハイブリッド検索とリランク — 「意味」と「語」の両立で、抽出した中身を使い切る
  • 技術

【第5回】ハイブリッド検索とリランク — 「意味」と「語」の両立で、抽出した中身を使い切る

はじめに

前回の第4回では、Super RAGがドキュメント抽出の入口でいかに丁寧に構造を残しているか——表のセル結合や図のキャプションを、後段の検索のために崩さず取り込む設計——をご紹介しました。記事の最後で、「抽出 ＋ 構造を保ったチャンク化が、後段の検索の天井を決める」とまとめました。

今回の主役は、その天井を実際にどこまで使い切るかを担う検索の中身です。どれほど丁寧に取り込んだ素材でも、検索が「これは関係ありそう」と取り出してくれない限り、回答には届きません。逆に言えば、検索段の設計次第で、第4回で苦労して保った構造の値打ちが何倍にもなります。

本記事では、Super RAGがこの検索段をどう組み立てているか——意味と語の両軸を並列に走らせるハイブリッド検索と、上位候補を質問との関連度で並べ直すリランク——を、非エンジニアの方にもイメージしやすい形でほぐしていきます。記事末尾には、今回の持ち帰り検討材料として「自社の質問を意味寄り／語寄り／混合に仕分ける演習シート」をご用意しました。読み終わったあとに、自社の検索クエリの傾向を把握する叩き台としてお使いください。

本連載について

本記事は第5回です。連載は、(I)なぜSuper RAG、(II)どう組み込むか、(III)中身を可視化、(IV)現場で何が起きているか、(V)導入判断、という5章構成で進めています。第III章「中身を可視化」では、抽出（第4回）→ 検索（第5回） → 回答戦略（第6回）の順で、Super RAGの精度を支える3本柱を取り上げます。

第4回が「入口で取りこぼさない設計」だとすれば、本記事は「取り込んだ素材を取りこぼさず引き出す設計」、第6回は「引き出した素材を回答に変換する設計」です。3回をセットでお読みいただくと、Super RAGが精度をどう積み上げているかの輪郭が立ち上がります。

なぜハイブリッドか — 1本の検索では業務質問に届かない

業務で投げられる質問は、見た目が似ていても、コンピュータから見るとまったく別物であることが多々あります。たとえばこんな2つです。

A：「現場で安全帯を使うときに気をつけることは？」
B：「型番 XYZ-123 のメンテ周期は？」

Aは、文書のどこかに「安全帯使用時の注意点」とそのまま書いてあるとは限りません。「墜落制止用器具」「ハーネス」「フルハーネス型」など、別の言葉で書かれている可能性のほうが高い。人間が頭の中で「同じ意味だ」とわかる言い換えを、検索もできなければ届きません。

一方Bは、型番が1文字でもズレたら別物です。「XYZ-123」と「XYZ-132」は別の機種ですし、「XYZ123」と書かれていても拾えなければなりません。意味の近さで探されると、似た型番がノイズとして混じってしまう。書かれている文字の一致を厳密に追いかけてくれる検索が必要です。 この2つの質問に1種類の検索だけで対応するのは、原理的に難しいことです。Super RAGはこれを諦めずに、意味で探すベクトル検索と、語で探す全文検索を、並列に走らせて結果を統合する——という設計を採っています。これが「ハイブリッド検索」と呼ばれる仕組みです。

ハイブリッド検索の2レーン

意味で探すベクトル検索（Milvus）

ベクトル検索は、文章の「意味」をベクトルと呼ばれる数値の並びに変換して、その近さで類似度を測る方式です。Super RAGではMilvusというベクトルデータベースを採用しています。

質問文も、ドキュメント側のチャンクも、同じ手順でベクトルに変換されているので、「意味の近い文章は、ベクトル空間で近いところに集まる」という性質を使って、近所の文章を引き出せます。冒頭のAの質問なら、本文に「ハーネス」「墜落制止用器具」と書かれていても、「安全帯」と意味が近いので候補に上がります。言い換えに強い検索です。

ただ、ベクトル検索にも弱点があります。意味の近さで判断するため、型番・固有名詞・条番号のような「文字の厳密な一致が問われる語」は、似て非なるものが混じりやすいのです。Bの質問で「XYZ-123」と「XYZ-132」が同じ意味グループに入ってしまう、というのが典型例です。

語で探す全文検索（Elasticsearch）

全文検索は、文章を単語に分けて「この語が、ここに入っている」というインデックスを引き、語の一致でヒットさせる方式です。Super RAGではElasticsearchを採用しており、業界で長年使われてきたBM25というスコア計算手法で、ヒットの強さを測ります。

語ベースなので、Bのような型番・固有名詞は得意です。「XYZ-123」と書かれた箇所だけを正確に引き出せますし、文書中の出現頻度や希少性も加味して、最も該当しそうな箇所を上位に持ってきます。厳密語に強い検索です。

逆に、Aのような「言い換えがたくさんある質問」には弱い。書かれている語と、質問に出てくる語が違うと、いくら意味が近くてもヒットしない——これが全文検索だけに頼ったときの典型的な詰まり方です。

並列に走らせて統合する — そして、本当に効かせるための前提

Super RAGはこの2方式を逐次で動かしているのではなく、並列に動かして両方の結果をマージしています。並列で動くため、片方を選んでから他方に切り替える、という遅延も発生しません。両方の結果は1本のスコア付き候補リストに統合され、後段に渡されます。同じ箇所が両方からヒットした場合は、まとめてひとつの候補として整理されます。

ここで一点、本記事を通じてお伝えしたい設計上のポイントがあります。ハイブリッド検索という考え方そのものは、業界では広く知られています。しかし「両方を並列で走らせれば、自動的に良い結果が出る」というほど単純ではない——というのが実装現場の実感です。両方式が実力を出すには、①素材側の品質と、②マージの仕方の最適化、この2つが揃っている必要があり、Super RAGはここに業務利用で積み上げてきたノウハウを投入しています。

①素材側の品質については、第4回でご紹介した内容そのものです。DocReader を中核とした高精度な抽出と、素材の性質に応じたチャンク化があるからこそ、ベクトル検索も全文検索も同じ高品質な素材を読みに行ける。表のセル結合が崩れていたり、図のキャプションが本文から切り離されていたり、意味的に分離すべきチャンクが一緒になっていると、どちらの方式もノイズを掴んでしまいます。逆に言えば、抽出の段で素材を整えてあるから、ハイブリッド検索の両レーンがそれぞれの強みを発揮できる——という関係です。一般的なRAG基盤でハイブリッド検索を導入しても期待した精度が出ないケースの多くは、検索方式そのものではなく、前段の素材品質に原因があります。

②マージの仕方の最適化は、Super RAGが業務利用で積み上げてきたチューニングのかたまりです。ベクトル検索と全文検索はスコアの計算方式がそもそも違い、両者の数字をそのまま並べて上位を取ると、片方の方式に偏った結果になります。同じ箇所を指している候補をどう統合するか、両者のスコアをどう揃えるか、最終的にどんな配合で並べるか——こうしたマージの実装ノウハウが、結果の質に直結します。

設計の含意はシンプルです。「業務の質問は、意味寄りも語寄りも混在する」という現実に合わせて、検索層側で両方を抱える、ということです。利用者は質問を意味寄り／語寄りに自分で振り分けて投げる必要がなく、ただ普通に質問を書けば、両方のレーンが受け止めてくれる——というのが運用上の最大の利点です。

リランクが上位を選び直す — 二段ふるいの設計

ハイブリッド検索で候補が集まったら、それで終わりではありません。Super RAGにはリランクという追加の選別工程が組み込まれています。 リランクの考え方は、人間の書類選考に似ています。一次は応募書類を多めに通して、二次面接でじっくり比較して順位を付け直す——この「広く集めて、後で並べ直す」の発想です。

ハイブリッド検索＋リランクの漏斗

一次は多めに集める

ハイブリッド検索の段で、Super RAGは最終的に必要な件数より多めに候補を集める設定を持っています。たとえば最終的に5件をLLMに渡したい場合でも、一次では20件、30件と幅広く拾っておきます。

なぜわざと多めに拾うのかというと、ベクトル検索のスコアと全文検索のスコアは「ものさしが違う」からです。ベクトル検索の0.85と全文検索の0.85は同じ意味の数字ではありません。スコアだけで上位N件を選ぶと、片方の方式に偏ったり、本当に関連が深い候補が惜しいところで落ちたりします。まずは余裕を持って広めに残しておき、本選別は二段目に任せる——という割り切りです。

二段目で関連度を再採点

二段目の主役がリランカーです。リランカーは、一次で集まった候補それぞれと、ユーザーの質問をペアで読み込み、「この候補は、この質問にどれくらい答えるのに適しているか」を質問との関係性として直接スコアリングします。

ベクトル検索や全文検索は、質問とチャンクをそれぞれ独立に符号化して比較します。それに対してリランカーは、質問と候補を1組ずつ並べて読み比べるため、計算量は増えますが判定の精度は格段に上がります。一次のものさしの違いも、二段目で同じ評価基準に揃えられます。

Super RAGの内部では、このリランカーが入れ替え可能なモジュールとして設計されています。具体的には、Cohere社が提供するリランクAPIを直接呼び出す方式、同じCohereのリランクモデルをAzure上のホスティング経由で呼び出す方式、LlamaIndexというフレームワーク経由でCohereリランカーやLLM自身をリランカーとして使う方式——といった選択肢を内部に持っています。

ただし、これらをお客様ごとに切り替えてお使いいただく形ではありません。運用時はSuper RAGの開発側が、その時点でのベストな選択肢を1つ選定し、固定して提供しています。お客様から見ると、常に最高品質のリランクが効いている状態を、開発側で担保している格好です。

モジュール化されている意図は別のところにあります。リランカ―を含め、RAGを取り巻くツールやライブラリは進化が速く、より高精度なモデルや、よりレイテンシ・コスト効率のよい選択肢が今後も登場し得ます。Super RAGはそうした動向を継続的に調査し、より良いリランカーが現れたタイミングで内部を入れ替えられる柔軟性を、設計として持ち続けています。お客様にとっての利点は、Super RAGをお使いいただくだけで、その時点での最良のリランカーが組み込まれた状態を享受できる——という点にあります。

外部リランカーが遅延しても、回答を止めないフェイルセーフ

リランカーは Super RAGの内部から外部のAPIサービスとして呼び出す部品です。CohereやAzure上のホスティングは普段は安定して稼働していますが、世界的な利用集中時間帯や、サービス側の一時的な負荷状況によっては、レスポンスが普段より大幅に遅くなる瞬間がどうしても発生します。これは外部APIに依存する以上、避けられない性質です。

ここで「いつまでも返ってこないリランカーを律儀に待ち続ける」設計にしてしまうと、リランカー側の遅延がそのまま Super RAG全体の回答遅延 に直結し、最悪の場合は回答そのものが返らない事態にもつながりかねません。Super RAGはこれを避けるために、リランクの待ち時間に上限を設け、上限を超えた場合はリランクをスキップして本流の処理を進める——というフェイルセーフを組み込んでいます。

結果として、リランカー側で遅延や障害が起きても、お客様への回答が止まることはありません。順位の精度は多少荒くなりますが、それでも回答自体は確実に返す——というのが設計の意図です。これは外部APIに依存する部品を抱えるシステムでは欠かせない冗長性の確保であり、Super RAGが業務利用に耐えるための重要な工夫の一つです。

全体の流れ — KnowledgeNetworkRetriever という本流

ここまで、ハイブリッド検索とリランクをそれぞれ単独で見てきました。実際のSuper RAGでは、この2つに加えていくつかの整え工程を一本のパイプラインに束ねた、KnowledgeNetworkRetrieverと呼ばれる本流の検索器が動いています。本節では、この本流が頭から最後までどう流れるかを、利用者目線でなぞります。

本流の検索 ― KnowledgeNetworkRetriever の5工程

KnowledgeNetworkRetriever 本流フロー

1. フィルターの適用：質問が届いたら、まず検索する範囲を絞ります。「このフォルダの中だけ」「このファイル群だけ」「このメタデータを満たすチャンクだけ」といった指定が、上流のクエリ管理（第3回でご紹介した認証・ユーザー権限の延長線）から渡されます。範囲が絞られることで、後段の検索が無駄な領域を見ずに済みます。

2. ハイブリッド検索とマージ：絞られた範囲に対して、本記事で見てきた意味検索と全文検索を並列に走らせ、結果を統合します。同じ箇所を指している候補は1つにまとめられ、内部で持っていたチャンクの窓（広めに切ったブロック）が、利用者に見せる表示用テキストにきれいに対応付けられます。

3. リランク：本記事で見たとおり、上位を関連度で並べ直します。外部リランカーが遅延した場合は、フェイルセーフが働いてリランクをスキップし、本流の順位のまま次工程に進みます。

4. 読める長さに収める（fit context length）：LLMが一度に読める文字数（コンテキスト長）には上限があります。集まった候補を全部渡すと溢れてしまうので、OpenAIが公開しているトークン計量ライブラリで長さを測りながら、上位から順に詰め込み、収まる手前で打ち切ります。

5. 採点済みノードを返す：ここまで通ってきた候補が、スコア・出典・メタデータ付きの一覧として、回答生成（第6回の主題）に引き渡されます。

利用者からの見え方は単純です。「質問を投げると、関連の高い順に整理された候補が、長さも整った状態で返ってくる」——この内部に、上記の5工程が畳み込まれている、というのがKnowledgeNetworkRetrieverの設計です。

検索は1本道ではない — 補助リトリーバーの存在

ここまでが本流の検索の話ですが、Super RAGには素材の性質ごとに専用の入口を持った補助的な検索器も用意されています。設計思想は第4回（チャンカーが素材ごとに違う）と一貫しており、「同じ検索という工程でも、対象の性質によって最適な引き方は違う」という考え方です。

代表的なものを、深入りせずに紹介します。

  • DictionaryRetriever：用語集・辞書のチャンクだけを別経路で引く検索器です。本文側の検索とは別の通り道を使うことで、用語の定義を文書の本文ヒットに紛れずに取り出せます。第6回で扱う「Dictionary戦略」の入口にあたります。
  • AttachmentRetriever：チャットごとに添付されたファイル（フォルダに永続登録するのではなく、その会話の中だけで使う添付）を対象にする検索器です。第3回で触れた添付ファイル操作カテゴリと連携し、「添付の申請書について」のような限定的な参照を支えます。
  • DynamicFewshotRetriever：質問に近い例示Q&Aペアを引いてくる検索器です。LLMに「こういう質問にはこう答える」というお手本をいくつか渡すことで、回答スタイルを安定させます。

これら補助リトリーバーが揃っていることで、「すべての質問を本流のハイブリッド検索だけで処理する」という単純な発想を超えて、質問の性質や参照対象の性質に応じた経路の使い分けができる、というのがSuper RAGの検索層の特徴です。各補助リトリーバーがいつ呼ばれて、どう回答に効いてくるかは、第6回の質問タイプ別の回答戦略で踏み込みます。

抽出と検索の接続 — 第4回の話がここで効く

ここで、第4回（抽出）と本記事（検索）の話がどうつながっているかを、1度だけ束ねます。

第4回の最後で、Super RAGは素材の性質に応じてチャンカーを選ぶ——FAQ専用の FAQChunker、辞書専用の DictionaryChunkerなど——という設計をご紹介しました。

これらが本記事の本流ハイブリッド検索や、Dictionary 等の補助リトリーバーといった検索段の使い分けの前提になっています。用語集が「用語と定義のペア」として識別されているから、DictionaryRetrieverが意味のある単位で引ける。FAQがFAQとして識別されてチャンク化されているから、ハイブリッド検索の段でFAQと本文を取り違えずに評価できる。

つまり、抽出が基礎を作り／検索が使い切り／回答戦略が選び取る、という3段構造で、各層が前段の仕事をきちんと使っている、というのがSuper RAGの精度設計です。第4回の構造を保った抽出は、この検索段で初めて回収される——その回収の仕方が、本記事で見てきたハイブリッド検索とリランクと補助リトリーバー、ということになります。

【持ち帰り検討材料】自社クエリを「意味寄り／語寄り／混合」に仕分けるシート

ここまで、ハイブリッド検索が意味と語の両軸を抱え、リランクが広く集めて関連度で並べ直す仕組みをご紹介してきました。読まれて「うちの業務だと、どっちの軸が効くんだろう」と思われたかもしれません。この見当をつけるための簡易シートをご用意しました。

自社クエリの仕分け演習シート

5つの観点で、それぞれ「やること／成果物／Tips」を押さえていきます。

観点1：直近のクエリを集める

直近1か月で実際にAIや検索窓に投げられた質問を、10〜20件ほど集めます。社内アシスタント、ヘルプデスクのチケット、サポート問い合わせのログなど、「実務で実際に投げられた言葉そのもの」を集めるのがコツです。
Tips：頭の中で考えた仮想クエリではなく、実物のログから取ると傾向の理解が一気に上がります。

観点2：3レーンに仕分ける

集めた質問を「意味寄り」「混合」「語寄り」の3レーンに分けます。判定の目安はシンプルです。

  • 意味寄り：質問が概念・状況・手順を聞いている。回答も言い換えで成立する。例：「現場で安全帯を使うときに気をつけることは？」「経費精算の流れを教えて」
  • 語寄り：質問が特定の語そのもの（型番・条番号・固有名詞・略号）を含んでいて、その語が回答にも一致して出てくる必要がある。例：「型番 XYZ-123 のメンテ周期」「Super RAGのインフラ要件」
  • 混合：両方の性質を持つ。例：「XYZ-123 が安全帯規格に適合するか」（型番は語寄り、適合の判断は意味寄り）

Tips：判別に迷ったら混合に入れるで構いません。混合が多い業務ほど、ハイブリッド検索の旨味が大きく出ます。

観点3：分布から効きどころを把握する

仕分けた結果の分布を見ます。お客様側で何かを設定する話というより、お客様の業務クエリの傾向によって、Super RAG のどの工夫がもっとも効いてくるかが変わる——という見方をしてください。

  • 語寄りが多い業務（型番・条番号・固有名詞中心）：全文検索とリランクが効きどころです。型番違いを誤ヒットしない厳密語の検索と、本当に関係する箇所を上位に持ち上げる二段ふるいが、回答の的中度を支えます。
  • 意味寄りが多い業務（手順・概念・状況中心）：ベクトル検索と前段のチャンク設計が効きどころです。第4回でご紹介した素材の性質に応じたチャンク化が、意味検索の精度を底支えします。
  • 混合が多い業務（実務はだいたいここ）：ハイブリッド検索の両レーンが揃っていることそのものが効きどころです。意味と語のどちらが要る質問でも、利用者が振り分けを意識せず投げられる——という運用上の単純さが効いてきます。

Tips：「うちは語寄り中心」「意味寄り中心」と決めつけず、実物クエリの分布で判断するのが大事です。思い込みと実態がずれることはよくあります。

観点4：「想定と違うヒット」を別表に抜き出す

仕分けた質問のうち、既存システムでは「期待した回答が出てこない」「関係ない箇所が上位に来る」ものだけを別表に抜き出します。これは第6回の主題（質問タイプ別の回答戦略）に直結する素材になります。
Tips：何が出るべきだったか・何が出てしまったかをセットで書き留めておくと、PoCやトライアルでそのまま検証クエリとして使えます。

観点5：トライアルでの検証相談

仕分けが終わったら、実データで実際にSuper RAGの検索を走らせて検証するのが最も確実です。スコープ・期間・対象ファイル数といった具体は、業務要件によって最適な形が変わります。記事末尾のお問い合わせフォームからお気軽にご相談ください。営業よりお客様の状況に合わせてご提案します。
Tips：観点1〜4の結果を整理してお伝えいただくと、初回トライアルで何を試すかの設計が一気にスムーズになります。

次回予告

次回（第6回）は、質問タイプ別の回答戦略 をお届けします。本記事では「検索結果をどう揃えるか」を扱いましたが、次回は揃った候補をどう答えに変換するか——という回答生成側の判断が主題です。

具体的には、Super RAGが質問を自動分類し、それぞれに応じた回答戦略を選ぶ思想を掘り下げます。本記事で名前だけ出てきたDictionaryRetrieverやDynamicFewshotRetrieverは、第6回でその活用場面が明らかになります。

第4回（抽出）→ 第5回（検索）→ 第6回（回答戦略）をセットで読むことで、Super RAGの入口から出口までの一貫した品質設計の輪郭が立ち上がります。

まとめ

検索は、第4回で取り込んだ素材を実際に回答生成に届けるための関門です。Super RAGの検索層は、意味と語の両軸を並列に走らせ、広めに集めた候補をリランクで関連度順に並べ直す——という二段ふるいで、業務質問の多様性を受け止めています。さらに本流のKnowledgeNetworkRetrieverは、ハイブリッド検索とリランクに加えて、参照範囲のフィルターやコンテキスト長の調整といった整え工程を一本に束ね、外部リランカーの遅延に対してはフェイルセーフで回答を止めない冗長性を備えることで、利用者には「質問を投げれば整った候補が返ってくる」という単純さを見せています。 「うちの業務クエリだと、どの軸がどれくらい効くか」が気になられた方は、本記事の持ち帰り検討材料の3レーン仕分けをまずご検討ください。そのうえで実データでの検証をご希望でしたら、記事末尾のお問い合わせフォームからお気軽にご相談ください。無償・有償のトライアルで、お客様の実データを流して結果を比較いただけます。

＜このシリーズの記事＞

お問い合わせ
Super RAG資料ダウンロード
ブログ一覧に戻る

おすすめ記事