AIが自然な文章で回答を生成するRAG（検索拡張生成）システムは、多くの企業で導入が進んでいます。しかし、導入したものの「期待したような正しい回答が返ってこない」という課題に直面する現場は少なくありません。本記事では、RAGの回答品質を決定づける根幹となる検索の技術について深く掘り下げます。従来の全文検索の仕組みから、最新のベクトル検索、そしてそれらを組み合わせたハイブリッド検索や、検索結果の精度をさらに高めるrerank（再ランキング）の仕組みまでを包括的に解説します。実用的なシステムを構築するための設計ポイントを紹介します。

【関連記事】AIを進化させる「思考の連鎖」と「意識の流れ」の関係とは？

RAGの品質を決める「検索精度」

RAGシステムの性能を向上させようとする際、多くの開発者が大規模言語モデル（LLM）の選定やプロンプトの調整に目を向けがちです。しかし、実際の運用において回答の正確性を左右する最大の要因は、言語モデルに渡す前段階の検索の精度にあります。本章では、なぜRAGにおいて検索技術が重要になるのか、その根本的な理由と、検索の土台となる全文検索の仕組みや業務における役割について詳しく解説します。

「Garbage In, Garbage Out」の原則

システム開発の世界には古くから「Garbage In, Garbage Out（ゴミを入力すれば、ゴミが排出される）」という重要な原則があります。この原則は、最先端の人工知能技術を用いたRAGシステムであっても当てはまります。RAGは、ユーザーからの質問に対して外部のデータベースから関連する情報を含んだ文書を探し出し、その内容を大規模言語モデルに参考資料として提示することで、正確な回答を生成させる仕組みです。どれほど頭脳が優秀で高性能な言語モデルを採用したとしても、検索の段階で間違った情報や無関係な文書を渡してしまえば、そこから生み出される回答も誤ったものになります。

多くの企業が社内情報の活用を目指してRAGを構築しますが、実際の運用では、ユーザーの意図とは異なる的外れな社内規程や、古いバージョンのマニュアルが言語モデルに渡されてしまうトラブルが多発しています。言語モデルは与えられた資料を要約する能力に長けているため、一見すると綺麗で説得力のある文章を作成します。しかし、その根拠となるデータ自体が間違っている場合、業務で利用できない危険な回答が生成されます。RAGの信頼性を高め、実用的なシステムとして成立させるための出発点は、何よりもまず質問に対して真に正しい情報を確実に検索できているかという一点に尽きます。

データを「持っている」だけでは足りない

RAGの基本的な処理の流れは、まず社内文書、FAQ、業務マニュアル、議事録、過去の問い合わせ履歴といった膨大なテキストデータを検索対象のデータベースに登録することから始まります。ユーザーがシステムに対して質問を入力すると、システムは登録されたデータ群の中から、その質問の内容に近いと考えられる一部の文書片（チャンク）を自動的に特定して取り出します。その後、抽出された文書片と元の質問をセットにして言語モデルへと転送し、その情報を読み解いて最終的な回答を組み立てます。

この一連のプロセスにおいて最も見落とされがちなのが、「社内データをデータベースに格納していること」と「必要なときに適切な情報を取り出せること」は別問題であるという事実です。どれほど貴重なナレッジや膨大な業務ノウハウをサーバー内に蓄積していても、検索機能が貧弱で、ユーザーの具体的な質問に対して該当する箇所をピンポイントで拾い上げることができなければ、言語モデルはその知識にアクセスすらできません。逆に、質問との関連性が薄いノイズのような文書を大量に拾って言語モデルに渡してしまうと、言語モデルはどの情報を信じるべきか判断に迷い、回答の軸がぶれたり、もっともらしい嘘であるハルシネーション（幻覚）を出力したりする要因になります。RAGの品質向上の本質は、適切な情報だけを過不足なく集める検索の設計にあります。

全文検索を支える基礎技術

検索技術の基本であり、現代のシステムでも不可欠な役割を担っているのが全文検索です。全文検索は、データベースに登録された大量の文書の中から、指定された特定の文字列が含まれているものを高速に探し出す仕組みです。単に文書の最初から最後までを力任せに読み込む文字列検索とは異なり、事前に検索用の索引を作成しておくことで、大規模なデータに対しても一瞬で検索結果を返すことができます。

全文検索の基盤となる代表的な技術要素は以下の通りです。

• 転置インデックス：書籍の巻末にある索引のように、どの単語が、どの文書の、何番目の位置に含まれているかをあらかじめ記録しておく構造のファイルです。
• 形態素解析：日本語のように単語の区切りが明確でない言語において、文章を意味を持つ最小の単位である単語に分割する処理を指します。
• トークン化：文章を検索の最小単位であるトークンへと分解し、インデックスに登録しやすい形に整形するプロセスです。
• ストップワード処理：文章中に頻出するものの、検索の絞り込みには寄与しない「てにをは」や助詞などの不要な語句をインデックスから除外する手続きです。
• フィールドごとの重み付け：文書のタイトル、見出し、本文といった要素ごとに重要度を設定し、タイトルにキーワードが含まれる文書をより上位に表示させる制御手法です。

これらの要素が組み合わさることで、膨大なファイル群から瞬時に候補を絞り込むことができます。RAGにおいては新しいベクトル検索に注目が集まりがちですが、長年にわたり検索システムを支えてきた全文検索こそが、あらゆる検索技術の強固な基礎となっています。

「完全一致」の強み

RAGを実際の業務に投入する際、全文検索が威力を発揮する場面が数多く存在します。それは、製品名、型番、エラーコード、社内固有の専門用語、法律や規程の名称、顧客名、固有の機能名など、文字情報として完全に一致していることそのものに強い意味がある検索シナリオです。

現場での具体的なシチュエーションを考えましょう。例えば、システムの保守担当者が運用の現場で「HTTP 502」というエラーに直面し、その対処法をRAGに尋ねたとします。あるいは、製造業のサポートデスクで「DEC-CRM-001」という特定の製品型番に関する仕様マニュアルを探す場合もあります。このようなケースでは、言葉の背景にある抽象的な意味の近さを推測することよりも、その特定の英数字の文字列が正確に含まれている文書を1件も漏らさずに拾い上げることの方が遥かに重要になります。

文字が一致している文書をピンポイントで引き当てる能力において、全文検索は非常に優れています。業務の文書を対象とするRAGにおいて、こうした固有名詞やコード、業界の専門略語を確実にキャッチアップし、回答の根拠となる資料として言語モデルに届けるためには、全文検索の特性を正しく活かすことが成功の絶対条件になります。

全文検索の限界と課題

文字の厳密な一致に強みを持つ全文検索ですが、一方で自然な言語表現を扱う上では回避できない明確な限界も存在します。最大の弱点は、検索を試みるユーザーが入力した言葉と、データベース内の文書で使用されている言葉の表現が少しでも異なっていると、適切な文書を検索できない点にあります。

現場における失敗の例として、カスタマーサポートの担当者が「顧客の解約を防止したい」と考えてRAGに質問を入力するケースが挙げられます。しかし、社内の共有ドキュメントやマニュアルの中では、同じ事象が「チャーン防止」や「ユーザーの離反抑止」という専門的なビジネス用語で記載されている場合があります。このとき、全文検索のシステムは「解約」という文字がドキュメント内に直接含まれていなければ、その文書がどれほど有益な対策を扱っていても検索結果の候補から排除してしまいます。

さらに、ユーザーが「最近発生しているシステムの動作が重くなる問題について、過去の同様のトラブルの事例と具体的な解決手順を教えてほしい」というように、日常会話のような長文の自然文で質問を入力した場合、全文検索は文章に含まれる大量の単語の中から、どの言葉を重視して検索を組み立てるべきかの判断が難しくなります。結果として、関係のない単語が多く含まれる無駄な文書を大量に引き寄せることになり、検索の精度は著しく低下します。全文検索はRAGの強固な基盤である一方、言葉の背後にある意味や文脈を解釈して柔軟に対応する能力は持ち合わせていません。

検索精度を最大化する文書設計

RAGにおける検索品質の課題を解決するためには、全文検索を古い過去の技術として安易に切り捨てるのではなく、その限界を理解した上で適切な運用設計を行う姿勢が求められます。実務で高い成果を出すためには、検索対象となる元文書をただ機械的に分割してデータベースに放り込むだけではなく、検索エンジンがキーワードを見つけやすいようにデータを加工・整理する文書設計が極めて重要になります。

具体的には、分割した文書の断片であるチャンクに対して、以下のような付加情報をあらかじめ整備しておくアプローチが有効です。

• タイトルの付与：分割された個々の文書片に対し、それが何のテーマについて書かれたものであるかを明示する独自のタイトルを埋め込みます。
• 見出しとタグの構造化：文書の論理的な構造を明確にし、重要なキーワードをシステムが認識しやすいようにメタデータとしてタグ付けを行います。
• エイリアスと想定質問の登録：社内の略語、製品の別称、顧客が使いそうな同義語をあらかじめ登録しておくほか、どのような質問が来たらこの文書を返すべきかという想定質問のリストを文書に紐付けておきます。

こうしたデータ構造の最適化は、検索を支える技術そのものの選定と同じくらい、あるいはそれ以上に、検索される側のデータ構造を最適化し、メタデータを緻密に設計することがRAGの回答品質にダイレクトに直結します。キーワードが確実にヒットする土壌を整えることが、安定したシステム運用の第一歩となります。

【参考】A Hybrid Retrieval and Reranking Framework for Evidence-Grounded Retrieval-Augmented Generation

「キーワード一致」と「意味検索」の違い

RAGシステムにおける検索の精度をさらに高めるためには、単にキーワードが含まれている文書を探し出すだけでなく、どの文書がユーザーの質問にとって最も重要であるかを適切に評価し、順番に並べ替える仕組みが必要です。現代 of RAGにおいて、その中核を担うのが「BM25」と「ベクトル検索」という2つの異なるアプローチです。本章では、それぞれの技術の特性や得意分野、実務で直面する課題について対比しながら解説します。

単語の重要度を測る「BM25」

全文検索システムにおいて、検索結果の関連度を計算するための世界的な標準手法として広く使われているのがBM25です。これは、単に「検索キーワードが文書に含まれているかどうか」を判定するだけでなく、そのキーワードが文書内でどれほど重要な意味を持っているかを計算によって導き出し、スコア化する仕組みです。

BM25の評価基準は、主に以下の3つの要素から構成されています。

• 単語の出現頻度（TF）：1つの文書の中に、検索されたキーワードが何度も登場する場合、その文書は質問に関連している可能性が高いと判断します。ただし、単語が多ければ多いほど無限にスコアが上がるわけではなく、一定の回数を超えるとスコアの伸びが緩やかになる工夫が施されています。
• 逆文書頻度（IDF）：データベース全体の中で、そのキーワードがどれほど珍しいかを表す指標です。例えば、「システム」や「業務」といった多くの文書に頻出する一般的な言葉は重要度が低く設定されます。一方で、「チャーン」や「例外処理」といった特定の文書にしか登場しない専門的な言葉は、意味が強い重要な単語として高く評価されます。
• 文書の長さの正規化：短い文章の中にキーワードが含まれている場合と、数万文字におよぶ長い報告書の中にキーワードが含まれている場合を比較し、情報が凝縮されている短い文書の方をより関連度が高いとみなして優遇する処理です。

数式を用いて複雑に説明されることが多いBM25ですが、その本質は「よく出るけれど一般的すぎる言葉」と「登場回数は少なくても意味が尖っている言葉」を明確に区別し、文書の長さに応じて公平に評価する仕組みにあります。

「キーワード一致」の威力

BM25がもたらすキーワードの厳密な評価は、企業の業務システムに導入されるRAGにおいて大きな役割を果たします。オフィスで働くユーザーが検索を行う際、抽象的な概念ではなく、具体的な業務上の名称を入力して検索することが多いからです。

現場での具体的なシチュエーションとして、ヘルプデスクや運用現場で以下のようなキーワードが使われるケースがあります。

• 「〇〇エラー」：特定のシステムが出力した英数字の混ざった不具合の識別コード
• 「〇〇申請書」：社内の総務や経理の手続きで定められた各種様式の名称
• 「〇〇契約書」：特定の取引先企業や案件ごとに作成された法務ドキュメント

ユーザーが「経費精算申請書の提出期限」を知りたくて検索した際、システムが言葉の文字列を無視して「出張旅費の精算方法」という類似の概念の文書を上位に表示してしまっては実務になりません。BM25は、こうしたユーザーが指定したピンポイントな「名前の一致」を最優先で守り、確実性の高いデータを言語モデルへ届ける役割を担います。

文脈を解釈する「ベクトル検索」

BM25のように言葉の表面的な一致を重視するアプローチとは異なる、新しい手法がベクトル検索（セマンティック検索）です。ベクトル検索では、文章を機械学習モデル（埋め込みモデル）に通すことで、その文章が持つ意味や文脈を数百から数千次元の数値の並び（ベクトル）に変換してデータベースに登録します。

検索を行う際は、ユーザーの質問文も同じように数値のベクトルに変換し、空間上で意味の近い文書を計算によって探し出します。この技術の最大のメリットは、検索語と文書内の言葉が1文字も一致していなくても、語句の持つ意味の近さを解釈して適切な候補を見つけ出せる点にあります。

具体的な表現ゆれの対応例として、例えば「顧客が離れてしまう理由」という日常的な質問に対し、社内資料に書かれた「チャーン要因」という専門用語のチャンクをヒットさせることができます。また、「問い合わせ対応を早くする」という現場の要望に対し、マニュアル内の「応答時間の短縮に関するガイドライン」という記述を的確に引き当てることも可能です。

ユーザーの知識量や言葉選びの癖に左右されることなく、質問の背後にある意図を汲み取ってナレッジを引き出せる点が、ベクトル検索がRAGにおいて支持されている理由です。

意味検索が抱える弱点

表現ゆれを吸収できるベクトル検索ですが、実務の運用においては万能ではなく、特有の弱点や設計上の落とし穴があります。意味を抽象的な数値へと丸めてしまう特性上、固有名詞の区別や型番の識別、エラーコードなどの1文字の違いが重要になる厳密な情報の検索において、取りこぼしを発生させる性質があります。例えば、「A棟の会議室」と「B棟の会議室」は意味的には類似しているため、ベクトル検索では同じようなものとして混同され、誤った場所の案内資料を引っ張ってくる要因になります。

また、ベクトル検索の精度は、登録するテキストデータをどれくらいの長さに切り分けるかという「チャンク分割の単位」に依存します。チャンクが大きすぎる場合、1つのまとまりの中に複数の異なるトピックや話題が混在することになり、文章全体の意味のベクトルが薄まって曖昧になります。結果として、質問に対して本当に必要な核心部分が埋もれてしまいます。反対に、チャンクが小さすぎる場合は、文章の前後関係や前提条件となる文脈（コンテキスト）が抜け落ちてしまい、単体では何を指しているのか分からない文章の断片になります。これを言語モデルに渡しても、文脈が繋がらずに正しい回答を合成できません。データの作り方が少しでも雑であると、意味検索のポテンシャルは失われてしまいます。

２つの技術を活かすハイブリッド検索

RAGの検索構成を設計する上で、「これからはAIの時代だからBM25は不要であり、すべてをベクトル検索に置き換えるべきだ」という極端な二者択一の思考に陥ることは避けるべきです。BM25とベクトル検索はどちらかが優れているという関係ではなく、お互いの弱点を補い合う関係にあります。

BM25は「言葉として一致しているか」という客観的な事実に基づき、ブレのない検索結果を提供します。一方でベクトル検索は「意味として近いか」という文脈に基づき、柔軟な検索結果を網羅します。社内のFAQやマニュアル、過去の応対履歴といった実際の業務データには、厳密な製品型番とユーザーの曖昧な質問文が常に混じり合っています。実用的なRAGを構築するためには、これら2つの検索エンジンを同じシステムの中で共存させ、双方の強みを同時に引き出すアプローチが必要です。

検索エンジンの特性を活かしたフィールド設計

検索技術をどのように組み合わせるかという議論と同じくらい実務で差を生むのが、検索対象となるデータベース側のフィールド設計です。1つの大きなテキスト領域に文書を流し込むのではなく、データの構造を明確に分けて管理し、検索エンジンにどこを重点的に読ませるかをコントロールする必要があります。

具体的なデータ設計のポイントは以下の通りです。

• フィールドごとの独立管理：ドキュメントのタイトル、見出し、本文、メタデータタグをそれぞれ異なるフィールドとして定義し、検索時に個別にスコアを評価できるようにします。
• 重み付けのチューニング：本文の中に一度だけ登場したキーワードよりも、ドキュメントのタイトルやFAQの質問文そのものに含まれているキーワードの方を強く評価するようにシステム側のパラメータを調整します。
• 同義語・エイリアスのマッピング：社内で使われている独自の略称や、新旧 of 製品名、顧客が間違いやすい誤表記などをあらかじめエイリアス（別名）のフィールドとしてデータに紐付けて登録しておきます。

どれほど高性能な検索アルゴリズムを導入しても、検索される対象のデータが整理されていなければ、十分な効果は得られません。技術の選定と並行して、業務データの構造そのものを検索されやすい形へと磨き上げることが、結果としてRAG全体の回答精度を向上させる近道です。

【参考】Hybrid search

RAG検索を実用レベルに引き上げるには

単一の検索手法だけでは、実際の業務で発生する多様な質問に安定して対応することは困難です。実用的なRAGシステムでは、キーワード検索と意味検索を融合させた「ハイブリッド検索」と、その結果をさらに精査する「rerank（再ランキング）」を組み合わせるアプローチが主流になっています。本章では、これら2つの技術がどのように機能し、システムの回答精度を実用レベルへと引き上げるのか、具体的な仕組みと実装のポイントを詳しく解説します。

ハイブリッド検索のアプローチ

ハイブリッド検索とは、言葉の厳密な一致を捉えるBM25などのキーワード検索と、言葉の背後にある文脈を捉えるベクトル検索を、同じシステム内で同時に実行して結果を融合させる手法です。双方の検索技術には一長一短があります。実務の現場では、ユーザーがどのような意図や表現で質問してくるかを事前に予測することは困難です。そのため、最初から網を広く張るために、性質の異なる2つの網を同時に投げ入れるアプローチが有効になります。

例えば、ユーザーが社内ヘルプデスクのRAGシステムに対して「出張に伴う経費精算書の再発行の手続きについて教えてほしい」という文章で質問を入力したシチュエーションを想定します。このとき、キーワード検索は「経費精算書」や「再発行」という具体的な固有名詞を手がかりにして、該当する申請マニュアルのドキュメントを確実に検索結果の候補に含めます。同時に、ベクトル検索は「提出済みの帳票をもう一度出力する」や「支払明細を再度送付してもらう」といった、ユーザーが入力した言葉とは異なるものの、意味として深く関連している言い換え表現が含まれた過去のトラブル対応履歴などを拾い上げます。このように、片方の検索方式だけでは見落としてしまうはずだった有益な文書を、ハイブリッド検索を採用することで漏れなく検索結果の候補として集めることができます。

「スコアの統合」という難題

ハイブリッド検索を実装する上で、開発者が直面する技術的課題が、性質の異なる検索エンジンから出力されたスコアをどのようにして1つのランキングに統合するかという問題です。BM25が算出するスコアは、単語の出現頻度や文書の長さに応じて理論上は上限なく上昇する数値です。一方で、ベクトル検索が算出するスコアは、コサイン類似度などのように、基本的には0から1、あるいはマイナス1から1の間の一定の範囲に収まる数値になります。これらは、メートルで測った長さとキログラムで測った重さをそのまま足し合わせようとするようなものであり、単純に数値を合計するだけでは正しいランキングを作ることはできません。

この課題を解決するためには、それぞれのスコアを適切に扱うための明示的な正規化や重み付けの調整が必要になります。代表的な統合のアプローチとして、それぞれの検索手法における文書の具体的なスコア数値を無視し、純粋に何位にランクインしたかという順位の情報だけを基にして最終的な総合順位を計算する「RRF（相互順位融合）」があります。あるいは、双方のスコアを事前に0から1の範囲に変換した上で、システム管理者が設定した比率を掛け合わせて合算する「スコアの正規化と重み付け（アルファパラメータによる制御）」などの手法が挙げられます。

実際の業務システムでは、検索対象となるデータの性質によってこのバランスを調整します。FAQのように日常会話に近いデータが多い場合は意味検索の比重を高くし、製品仕様書のように型番や専門用語が飛び交うデータが中心の場合はキーワード検索の比重を高くするような、現場に合わせた細やかなチューニングがRAGの成否を分けるポイントになります。

検索結果の「最終選考」を担う「rerank」

ハイブリッド検索によって、取りこぼしのない網羅的な文書の候補を集めることには成功しますが、これだけで言語モデルに情報を渡すのはまだ不十分です。統合された直後の検索結果の最上位に、本当に質問の核心に答えている文書が並んでいるとは限らないからです。ここで登場するのが、検索の精度を最終的な実用レベルへと引き上げる「rerank（再ランキング）」というプロセスです。

rerankは、書類選考を通過した上位の候補者たちに対して、より厳密な面接を行う「最終選考」のような役割を担っています。最初のハイブリッド検索の段階では、数万件から数百万件におよぶデータベースから高速に候補を絞り込むため、計算コストの低い軽量なアルゴリズムが使用されます。その結果として絞り込まれた上位数十件の文書の断片に対してのみ、今度はcross-encoder（クロスエンコーダー）と呼ばれる非常に高精度で強力なAIモデルを適用します。このモデルは、ユーザーの質問文と候補となる文書を一体化させて深いレベルで相互の関係性を読み解き、「この質問に対して、この文書は本当に直接的な回答を含んでいるか」を高い精度で再評価し、ランキングを並べ替えます。

最初からすべての膨大な文書に対してこのような負荷の高い処理をかけるのは、システムの応答速度の面から見ても現実的ではありません。しかし、最初の検索で候補を小さく絞り込んだ後であれば、システムのパフォーマンスを犠牲にすることなく、高度な評価の恩恵を受けることができます。

「rerank」がRAGの品質とコストを変える

実務のRAGシステムにおいて、rerankのプロセスを導入することでもたらされる実利は、単に検索順位が改善されるというレベルに留まりません。大規模言語モデルが一度に処理できる文字数（コンテキストウィンドウ）には限界があり、また処理する文字数が多ければ多いほど、APIの利用料金という形で企業の開発運用コストに影響します。そのため、検索結果が優れているからといって、上位20件も30件も大量の文書をそのまま言語モデルに送りつけるわけにはいません。

現実的な運用では、言語モデルに手渡す文書は、本当に価値のある最上位の数件に厳選する必要があります。rerankを適用していない検索結果の場合、最上位の数件の中に、質問に似ているだけで肝心の答えが書かれていない「ノイズ文書」が混入する確率が高くなります。関係の薄い不要な情報を大量に提示された言語モデルは、思考が妨げられて回答の焦点がボケてしまうばかりか、間違った情報を真実だと思い込んでハルシネーションを起こす危険性が高まります。rerankによって本当に質問の解決に直結する高純度の文書だけを最上位に凝縮して言語モデルに届けることが、回答の安定性を高め、同時に無駄なトークン消費を抑えて運用コストを削減するための鍵となります。

実務におけるRAG検索の構成

これまでに解説してきたすべての検索技術を体系的に組み合わせることで、実際の企業の厳しい実務要件に耐えうる、高精度なRAGの検索パイプラインを構築することができます。

現場のシステム実装において推奨される標準的な処理の構成フローは以下の通りです。

• メタデータフィルタリング：ユーザーの所属部署、閲覧権限、ドキュメントの更新日時、顧客の区分といった属性情報に基づき、そもそも検索対象にすべきではない不要な文書を最初の段階で除外します。
• ハイブリッド検索の実行：フィルタリングを通過したデータ群に対して、BM25によるキーワード検索と、k-NN（最近傍探索）などを用いたベクトル検索を並列で走らせます。
• スコアの正規化と融合：得られた2つの異なる検索結果を、RRFなどのアルゴリズムを用いて1つの統合された検索候補リストへと合成します。
• rerankによる最終選考：統合リストの上位から抽出した数十件の文書片に対して、専用のrerankerモデルを適用し、質問に対する真の関連度を基に順位を厳格に再評価します。
• LLMへのコンテキスト注入：最終的に選ばれた最上位ドキュメントのみを厳選し、ユーザーの質問文と合わせて言語モデルへと転送します。

RAGにおける検索の世界は、単に「BM25かベクトルか」という二者択一の単純な議論を超え、密結合なニューラル検索や、検索エンジンの内部で動的に検索クエリを書き換える手法など、現在も早いスピードで進化を続けています。しかし、どれほど新しいトレンドが登場したとしても、基盤となるのはデータの構造を正しく整理し、段階的に候補を絞り込んで精度を高めてしていくという段階的検索の設計思想に他なりません。技術の特性を正しく理解し、自社の業務データの性質に適合させていく継続的な改善活動こそが、実用的なAIシステムを成功に導く道です。

【参考】Reranking

RAGの成否は「検索設計」で決まる

RAGシステムは、最先端の大規模言語モデルを導入して外部の情報を流し込めば、自動的に正しい回答を生成してくれるわけではありません。ユーザーの多様な質問に対して、データベースの中から真に正しい文書を探し出し、適切な優先順位で厳選し、本当に必要な情報だけを言語モデルに届けるための検索設計があって初めて、実務で使い物になる高い信頼性が担保されます。

1文字のブレも許されない製品型番やエラーコード、社内固有の専門用語の完全一致には、長年の実績を持つBM25を筆頭とするキーワード検索が強みを発揮します。その一方で、ユーザーごとの言葉選びの癖や知識の差から生まれる多様な表現ゆれ、日常会話のような曖昧な自然文の文脈を深く解釈するためには、文章の意味を数値化して捉えるベクトル検索が不可欠な役割を担います。実際の業務運用においては、これらどちらか一方の技術に依存するのではなく、双方の強みをハイブリッド検索によって融合させ、さらにその結果をrerankのモデルによって再評価する多段階のパイプラインの構築が重要になります。

RAGの品質改善の本質は、言語モデルのパラメータ調整やプロンプトエンジニアリングの技術だけに終始するものではありません。検索対象となるドキュメントを適切な長さに切り分けるチャンク分割の技術、タイトルやタグを構造化するメタデータの設計、同義語を紐付けるエイリアスの整備、そして日々の運用のログから検索のヒット率を定量的にはじき出す評価指標の運用にいたるまで、システム全体を内包した継続的な改善活動として捉え、向き合い続ける姿勢が求められます。