導入背景：製造現場における技術文書検索の課題
「なぜ、AIは『A-100』と『A-101』の違いが分からないのでしょうか？」
これは、製造業の現場でRAG（Retrieval-Augmented Generation）システムを導入する際、頻繁に直面する問いです。数万件に及ぶ技術マニュアルや設計仕様書を保有する組織において、社内問い合わせ対応の効率化と、現場の顧客体験（従業員体験）向上の両立を目指してRAGを構築するケースは増えています。
多くのプロジェクトにおける初期設計は、いわゆる「教科書通り」のアプローチが採用されがちです。最新の埋め込みモデル（Embedding Model）を使用し、すべてのドキュメントをベクトル化してVector DBに格納。ユーザーの自然言語による質問から類似度の高いチャンクを検索し、LLMに回答させるという構成です。
PoC（概念実証）の段階では、「ポンプの異音がするときはどうすればいい？」といった抽象的な質問に対して、関連するトラブルシューティングのマニュアルを的確に提示できるため、高い評価を得ることが多いでしょう。しかし、いざ全社規模で実運用を開始すると、状況が一変するケースが後を絶ちません。
ベクトル検索のみでのスタートと初期の挫折
現場のエンジニアから寄せられるのは、「使えない」「検索結果が的外れだ」という厳しいフィードバックであることは珍しくありません。利用ログを解析すると、共通した事実が浮かび上がります。現場のエンジニアが検索しているのは、「ポンプの異音」といった自然言語ではなく、「P-204X エラーコード E03」といった具体的な型番や記号であることが多いのです。
ここに、ベクトル検索単体運用の限界があります。ベクトル検索は「意味の近さ」を探すのは得意ですが、こうした「記号の完全一致」を保証するのは苦手です。その結果、型番が一文字違うだけの全く別の製品マニュアルが上位に表示されたり、エラーコードの数字が近いだけの無関係なドキュメントがヒットしたりする現象が多発します。
結果として、ユーザーが求めていたドキュメントが上位に含まれないケースが散見され、問い合わせ削減という本来の目的を達成できない事態に陥ります。こうした背景から、流行の技術であるベクトル検索一本槍の戦略を見直し、キーワード検索を組み合わせた「ハイブリッド検索」や、リランキング（再順位付け）といった現実的な解法を探求する必要があるのです。
直面した「検索の壁」：なぜAIは現場の言葉を理解できなかったか
なぜ、最新のAI技術を使っても、現場の単純な検索ニーズに応えられないのでしょうか。この問題を解き明かすには、セマンティック検索（ベクトル検索）が得意なことと、不得意なことを冷静に整理する必要があります。
セマンティック検索の弱点と現場ニーズのギャップ
セマンティック検索は、言葉を多次元のベクトル空間上の点として表現し、その距離で類似性を判断します。例えば、「PC」と「パソコン」と「コンピュータ」は、文字面は異なりますが、意味空間上では非常に近い位置に配置されます。これが、表記ゆれを吸収し、文脈を理解できる理由です。
しかし、製造業などの現場で頻繁に飛び交う「型番」や「品番」の検索では、状況が異なります。
- 製品A-100（旧モデル）
- 製品A-101（新モデル）
この2つは、文字面も似ていますし、製品としての説明文（スペックや用途）も酷似しています。その結果、ベクトル化されたデータ上では、この2つのドキュメントは「ほぼ同じ位置」に重なってしまうことが多いのです。AIにとっては「どちらも似たような製品についての文書」という認識になってしまい、ユーザーが厳密に区別したい「100と101の違い」を、ノイズとして処理してしまうケースは決して珍しくありません。
さらに厄介なのが、組織固有の略語やプロジェクトコードです。一般的な学習データに含まれていない造語は、AIがその意味を正しくベクトル化できず、見当違いな意味として解釈されるリスクがあります。
ファインチューニング vs ハイブリッド検索の比較検討
この課題に対するアプローチとして、開発の初期段階で検討されやすいのが「埋め込みモデルのファインチューニング」です。固有のデータを学習させ、型番の違いをAIに教え込むという発想です。
しかし、多くのプロジェクトにおいて、このアプローチは現実的な選択肢として推奨されません。主な理由は以下の3点です。
- コストと時間: モデルの再学習には膨大な計算リソースと、質の高い学習用データセットの作成が必要です。
- 追従性: 新製品のリリースや用語の追加があるたびに再学習が必要になり、運用負荷が限界を迎えます。
- 確実性: コストをかけて学習させたとしても、意図した通りに完全に制御できる保証はありません。
そこで現在、エンタープライズ検索の標準的な解決策として定着しているのが「ハイブリッド検索」です。これは、ベクトル検索（セマンティック検索）と、従来型のキーワード検索（BM25など）を併用するアプローチです。
古典的な検索アルゴリズムであるBM25は、現在では単独での使用は推奨されていません。しかし、キーワード検索は「意味」は理解しないものの、「特定の文字列が含まれているか否か」については100%正確です。「A-100」と検索すれば、必ず「A-100」という文字列を含むドキュメントを見つけ出してくれます。
この「融通の利かなさ」こそが、厳密な一致が求められるケースでは最大の武器になります。最新のシステム構築においては、PostgreSQLのpg_textsearch拡張機能を用いてTrue BM25ランキングを直接実装し、DiskANNなどのベクトル検索と併用する手法が注目されています。
純粋なBM25の単独使用から脱却し、ハイブリッド構成（BM25＋埋め込み）に自動チューニング（MLOps）を組み合わせることで、FAQや設計書、議事録などの異質なデータを横断的に検索し、現場の言葉を正確に捉える堅牢な検索基盤を実現できます。
実装への挑戦：精度とレスポンス速度のトレードオフ
ハイブリッド検索の方針が決まっても、実装フェーズに入ると多くの開発現場ですぐに新たな壁にぶつかります。それは、「異なる尺度のスコアをどうやって統合するか」という根本的な問題です。顧客体験を損なわないレスポンス速度を維持しながら、いかに高精度な回答を安定して生成するかが問われます。
ElasticsearchとベクトルDBの併用構成
一般的なシステム構成として、既存のベクトルDBに加え、キーワード検索エンジンとして実績のあるElasticsearch（またはOpenSearch）を併用するアプローチがよく取られます。ユーザーのクエリに対して、ベクトル検索とキーワード検索を同時に走らせ、それぞれの結果をマージしてLLMに渡すというフローです。
近年では、ElasticsearchによるテキストフィールドでのBM25スコアリング継続使用（LLM連携のエンティティ解決など）に加え、PostgreSQLのネイティブ統合という新たな選択肢も注目を集めています。例えば、pg_textsearch拡張機能を用いて真のBM25ランキングを直接実装し、DiskANNのようなベクトル検索と組み合わせる手法です。
CREATE EXTENSION pg_textsearch;
このような拡張機能を実行するだけで導入できる手軽さもあり、システム構成をシンプルに保ちつつ、低レイテンシとコスト削減を実現するケースも増えています。
いずれの構成においても、統合の際に問題になるのが検索スコアの性質の違いです。
- ベクトル検索（Cosine Similarity）: 通常0.0〜1.0の範囲に収まる正規化されたスコア。
- キーワード検索（BM25）: 文書の長さや単語の出現頻度によって算出されるスコア。上限がなく、クエリによって数値の桁が変わることもある古典的なアルゴリズム。
「0.85」というベクトルスコアと、「15.4」というBM25スコアを、単純に足し合わせることはできません。純粋なBM25単独での使用は現在では推奨されておらず、ベクトル検索と組み合わせた上で、どちらかの影響力が極端に強くなってしまうのを防ぐ仕組みが不可欠です。
「重み付け」の泥沼とRRF（Reciprocal Rank Fusion）の採用
初期のアプローチとして、「重み付け係数（Alpha）」を導入し、手動でバランスを取ろうとするケースは珍しくありません。
Final Score = (Vector Score * α) + (Keyword Score * (1 - α))
といった計算式を組み、αの値を0.1刻みで調整しながらテストを繰り返すことになります。
しかし、現場の声を総合すると、これがまさに泥沼化しやすいポイントです。「型番検索の精度を上げようとしてキーワードの比重を高めると、今度は抽象的な質問の精度が落ちる」というシーソーゲームが続きます。さらに、クエリの種類や、FAQ・設計書・議事録といった異質なデータの横断検索を行う場合、最適なαが変動するため、一つの設定値で全てをカバーするのは不可能に近い状態に陥ります。
そこで現在、ハイブリッド検索の標準的な解決策として多くのプロジェクトで採用されているのが、RRF（Reciprocal Rank Fusion）というアルゴリズムです。
これは、スコアそのものではなく、「検索結果の順位（ランク）」を使って統合する方法です。計算式はシンプルで、各検索エンジンでの順位（k）の逆数を足し合わせます。
RRF Score = 1 / (k + constant)
例えば、あるドキュメントがベクトル検索で1位、キーワード検索で5位だった場合、それぞれの順位に応じたスコアが付与され、合算されます。この手法の最大のメリットは、「スコアの尺度を気にする必要がない」こと、そして「面倒なパラメータ調整がほぼ不要」であることです。近年はMLOpsの文脈で自動チューニングを組み合わせる手法も一般化しています。
RRFを導入することで、それまで不安定だった検索結果が驚くほど安定するケースが多く報告されています。キーワード検索でしかヒットしないニッチなドキュメントも、ベクトル検索で上位に来る文脈重視のドキュメントも、納得感のある順序で混ざり合うようになります。これは開発チームにとって、品質保証の観点からも大きな安心材料となるはずです。
導入後の成果と現場の反応：回答精度92%への道のり
ハイブリッド検索とRRFの実装を経て、適切に導入されたシステムでは劇的な改善が見られます。実際の導入事例におけるリリースから1ヶ月後の評価データを共有します。
定量的成果：MRR（Mean Reciprocal Rank）の向上推移
検索精度の指標としてMRR（正解ドキュメントが何位に表示されたかの平均逆数順位）を計測した事例では、以下のような結果が得られています。
- 導入前（ベクトルのみ）: MRR 0.42
- 導入後（ハイブリッド）: MRR 0.88
特に顕著だったのは、やはり型番やエラーコードを含むクエリでのヒット率です。以前は圏外に飛ばされていたドキュメントが、ほぼ確実に1位〜3位以内にランクインするようになりました。最終的な回答精度（ユーザーがGood評価を押した割合）は、目標としていた90%を超え、92%に達したケースもあります。
また、懸念していたレイテンシ（応答速度）についても、並列処理を行うことで増加を最小限に抑えることが可能です。平均検索時間は約200msから350msへと増加する傾向にありますが、ユーザー体験を損なうレベルではありません。
定性的成果：「やっと使えるようになった」という現場の声
定量的な数字以上に重要なのは、現場の反応の変化です。
「以前は『A-100』と入れても一般的な説明しか出なくてイライラしたが、今はピンポイントで仕様書が出る。やっと業務で使えるレベルになった。」
「『画面が固まった』みたいな曖昧な検索でもちゃんとヒットするし、『E005』みたいなコードでもヒットする。使い分けなくていいのが楽。」
このように、ユーザー側が検索の仕方を工夫しなくても、システム側が意図を汲み取ってくれる状態を作れることが、最大の成果と言えます。信頼を取り戻したことで、利用率はV字回復し、当初の目的であった問い合わせ削減も順調に進み始めます。
開発者への提言：ハイブリッド検索を成功させるための「割り切り」
ここまで成功側面を強調してきましたが、これからハイブリッド検索を検討する方へ、実運用の現場で直面するリアルな課題についてもお伝えしておきます。
最初から完璧なパラメータを求めない
ハイブリッド検索は強力ですが、銀の弾丸ではありません。特にRRFを採用した場合でも、順位付けのロジックがブラックボックスになりがちで、「なぜこの記事が1位なのか」を直感的に説明しづらいケースが出てきます。
ここで完璧を求めすぎると、またパラメータ調整の沼にハマります。「9割のクエリで正解が出るならOK」という割り切りが必要です。残りの1割は、Re-ranking（再ランク付け）モデルのような、より高コストだが高精度な処理を後段に挟むことで解決するなど、段階的なアプローチを推奨します。
辞書管理と類義語展開の運用体制
そして、最も覚悟すべきは「運用の復活」です。ベクトル検索の魅力の一つは「辞書メンテからの解放」でしたが、キーワード検索を導入する以上、辞書管理は避けて通れません。
社内用語、略語、新製品の型番。これらを類義語辞書（Synonym Dictionary）に登録し続ける作業が発生します。「スマホ」と検索して「スマートフォン」をヒットさせるような基本的な処理は、キーワード検索エンジンの辞書機能に依存するからです。
実際の運用現場では、月1回の「辞書メンテ会議」を設定し、検索ログからヒットしなかったキーワードを拾い上げて登録するフローを確立するケースが多く見られます。これは地味で泥臭い作業ですが、この人間によるメンテナンスこそが、ラストワンマイルの精度を支えています。
AIによる自動化と、人間による運用。このバランスをどう設計するかが、プロジェクトの成否を分ける鍵となります。
まとめ
ベクトル検索の「文脈理解」と、キーワード検索の「確実性」。この両方の利点を活かすハイブリッド検索は、実用的なRAGシステムを構築する上で、もはや避けては通れない標準的なアーキテクチャになりつつあります。
今回ご紹介した事例のように、調整の難しさはRRFなどのアルゴリズムで克服可能です。そして、多少の運用コストを払ってでも得られる「信頼性の高い検索結果」は、ユーザー体験を根本から変える力を持っています。
もし現在、RAGの精度課題に直面しているなら、まずは自社のデータでハイブリッド検索の挙動を試してみてください。理論だけでなく、実際に動くものを見ることで、解決への道筋が見えてくるはずです。
ハイブリッド検索やRRFの実装済み環境を提供するサービスを活用すれば、複雑な構築作業なしで、自社のドキュメントがどのように検索されるかを確認できます。まずは実際の精度を確かめてみることをおすすめします。
コメント