検索精度が頭打ちなら「不正解」を疑え。LLMによるHard Negative生成とフィルタリングの実装戦略

導入

「とりあえずRAG（検索拡張生成）を導入してみたけれど、思ったほど精度が出ない」
「キーワードは合っているのに、文脈が逆のドキュメントを拾ってきてしまう」

実務の現場では、RAG導入後にこのような課題に直面するケースが頻繁に見受けられます。初期のPoC（概念実証）段階でBi-Encoderのモデルを導入し、ベクトル検索を実装すれば期待通りの効果が得られると考えられがちです。しかし、実際に運用を開始すると、ユーザーが求める検索結果が得られず、次第にシステムが使われなくなってしまうことがあります。

実際の開発現場でも、似たような現象はよく課題として挙がります。

このような状況において、埋め込みモデル（Embedding Model）を最新のものに変更したり、チャンク（分割）サイズを調整したりといった「パラメータチューニング」に注力するケースが多く見られます。もちろんそれらの調整も重要ですが、より費用対効果が高く現実的なアプローチとして、「モデルに対して『何が間違いか』を正しく教えること」が挙げられます。

特に、一見すると正解に見えるものの実は不正解である「Hard Negative（難しい不正解）」を学習や評価のデータに組み込むことで、検索エンジンの識別能力は大きく向上します。人間がひっかけ問題を解くことで理解を深めるのと同じ理屈です。

ただし、このHard Negativeを準備するのは容易ではありません。人手で作成する場合は多大なコストがかかり、自動生成する場合はノイズが混入しやすくなります。

本記事では、LLM（大規模言語モデル）を活用してこのHard Negativeを効率的に生成し、実用レベルの品質まで高めるための、現場目線の実践的な実装ワークフローについて解説します。

なぜ「難しい不正解（Hard Negative）」が検索品質を左右するのか

ベクトル検索の精度向上が頭打ちになる主な要因は、モデルの「識別能力不足」にあると考えられます。これを理解するために、まずは裏側の仕組みを整理します。

ベクトル検索の弱点：意味的類似性の罠

ベクトル検索は、検索クエリとドキュメントをベクトル空間上の点として表現し、その距離（近さ）で関連度を測定します。ここで課題となるのが、「意味的に似ている」ことと「質問の答えとして適切である」ことは、必ずしも一致しないという点です。

例えば、「2023年の売上報告書」を探していると仮定します。ベクトル空間上では、「2022年の売上報告書」も「2023年の経費報告書」も、近い位置に配置されやすくなります。使用されている単語の重なりが多く、文脈も似ているためです。

もしモデルが「2023年の売上」という具体的な情報を求めていることを正確に理解できず、単に「売上報告書に近い雰囲気のもの」を探してしまうと、2022年のデータを上位に表示してしまうことがあります。これが、ユーザーが直面する「期待外れの検索結果」の正体です。

Random NegativeとHard Negativeの決定的違い

通常、検索モデルの学習や評価には「正解（Positive）」と「不正解（Negative）」のペアを使用します。多くの公開データセットや簡易的な実装では、このNegativeとして「ランダムに選んだ無関係な文書（Random Negative）」が使われます。

• Query: 2023年の売上は？
• Random Negative: 社員食堂の今週のメニューはカレーです。

これでは問題が簡単すぎます。モデルは「メニューの話ではないから不正解」と容易に判断できますが、これでは「2022年の売上」と「2023年の売上」の細かな違いを見分ける能力は育ちません。

一方、Hard Negativeは次のような構成になります。

• Query: 2023年の売上は？
• Hard Negative: 2022年の売上は前年比増の10億円でした。

これであれば、「売上の話をしているが、対象となる年が違う」という微細な差異を識別する必要があります。この「ギリギリの不正解」こそが、モデルの解像度を高めるための非常に有効な教師データとなります。

ビジネスインパクト：誤ヒットによるUX低下のコスト

技術的な観点だけでなく、費用対効果やビジネスへの影響という観点からも、Hard Negative対策は極めて重要です。

検索結果に「明らかな間違い」が含まれている場合、ユーザーは「まだ検索機能が未熟なのだな」と判断する程度で済むかもしれません。しかし、「もっともらしい間違い（ハルシネーションに近い検索結果）」が表示されてしまうと、ユーザーがそれを正解だと信じ込み、誤った情報のまま業務を進めてしまうリスクが生じます。あるいは、詳細を確認するためにドキュメントを開き、読み進めて初めて誤りに気づくというケースも考えられます。このような確認作業の積み重ねは、業務効率を著しく低下させます。「信頼できない検索システム」という評価が定着する前に、モデルの識別能力をしっかりと鍛え上げる必要があります。

現状の評価プロセス可視化とボトルネック特定

Hard Negativeを用意するプロセスにおいて、実際の開発現場ではいくつかの課題に直面します。

人手によるアノテーションの限界とコスト

理想を言えば、業務知識（ドメイン知識）を持った専門家が、検索クエリに対して「これは正解」「これは惜しいけれど不正解」と一つずつタグ付けしていくのが最も確実です。しかし、これには膨大なコストと時間がかかります。

評価データの作成には多大な工数が必要となり、エンジニアや現場の専門家の稼働コストを考慮すると、費用対効果が見合わなくなる可能性があります。さらに、社内ドキュメントが更新されるたびに評価データも作り直す必要が生じる場合もあります。

既存データセットのバイアス確認

「MS MARCOなどの公開データセットを活用すればよいのではないか」という意見もあります。確かに、モデルの基礎的な能力を向上させるためには役立ちますが、自社特有の専門用語や独自のドキュメント構造（社内規定、仕様書、日報など）には十分に対応できないケースが多々あります。

一般的なWeb上の文書で学習したモデルは、「Pythonのコード」を探すのは得意でも、「自社のレガシーシステムにおける特定のエラーコード」を探すのは苦手な傾向があります。実用的な精度を出すためには、やはり自社の実際のデータに基づいた評価セットが必要不可欠です。

理想的な評価パイプラインの定義

現場の運用負荷を下げつつ品質を保つために目指すべきは、以下のようなパイプラインです。

1. 社内ドキュメントから自動でクエリと正解ペアを生成する
2. そのクエリに対して、意図的に「難しい不正解」を生成する
3. 生成されたデータの品質を自動＋半自動でチェックする
4. 評価セットとしてデプロイし、モデルをテストする

この「2」と「3」の工程にLLMをうまく活用することで、人件費などのコストを抑えつつ、データの品質を担保することが可能になります。次章からは、具体的な実装ワークフローについて解説します。

実践：LLMを用いたHard Negative生成ワークフロー

ここからは、実際のシステム開発やデータ分析基盤構築の現場で採用されている、実践的なワークフローを解説します。単に「Hard Negativeを作って」とプロンプトで指示するだけでは、LLMはなかなか理想的な結果を出力してくれません。検索エンジンを騙せるレベルの高品質なデータを生成するためには、論理的で明確な戦略が必要です。

生成戦略のパターン化

人間が文章を読み間違えるパターンや、検索エンジンが誤検知しやすいパターンを分析すると、いくつかの類型に分けることができます。これらをプロンプトへ明示的に組み込みます。

1. 時系列の改変（Temporal Misalignment）
   • 日付、年度、四半期などを意図的に微妙にずらします。「2024年度下期」を「2024年度上期」に変更するなど、文脈は正しいものの時点だけが異なるケースを作成します。
2. 主体の入れ替え（Entity Swap）
   • 「プロジェクトAの事例」を「プロジェクトBの事例」に書き換える、あるいは「部長の承認」を「課長の承認」に変えるなど、固有名詞や役割を入れ替えます。
3. 条件の否定・改変（Condition Alteration）
   • 「〜の場合は必須」という文脈を「〜の場合は任意」や「〜の場合は不要」に書き換えます。
   • これは特にマニュアルや規定集の検索（RAG）において、誤った回答（ハルシネーション）を防ぐための極めて重要な訓練データとなります。
4. 数値の摂動（Numerical Perturbation）
   • 価格やスペックの数値を少しだけ変更し、論理的な矛盾を作り出します。

プロンプトエンジニアリングの具体例

LangChainなどのフレームワークを使って実装する場合、以下のようなプロンプトテンプレートを用意します。

セキュリティに関する重要事項: LangChainなどのツールを使用する際は、必ず最新のセキュリティパッチが適用されたバージョン（langchain-coreの最新版など）を利用してください。過去のバージョン（特にv0.3系以前の一部など）にはシリアライズ処理に関する脆弱性が報告されており、APIキーの漏洩や意図しないコード実行のリスクがあるため、本番環境での利用には十分な注意が必要です。

あなたは検索システムの評価データ作成支援AIです。
以下の「正解ドキュメント（Positive Passage）」と「検索クエリ」を読み、
検索エンジンが誤って上位に表示してしまいそうな「Hard Negative Passage」を生成してください。

制約条件:
- 文体やフォーマットは正解ドキュメントに酷似させること。
- 以下のいずれかの手法を用いて、意味内容を決定的に矛盾させること。
  1. 日付や数値を微妙に変更する
  2. 主語や目的語を類似の別のものに入れ替える
  3. 肯定/否定の結論を逆転させる
- 明らかに無関係な内容は避けること。

クエリ: {query}
正解ドキュメント: {positive_passage}

Hard Negative Passage:

このプロンプトの最大のポイントは、「文体やフォーマットは似せる」という指示です。ベクトル検索は単語の出現頻度や並びにも強く影響されるため、見た目が似ていることはHard Negativeとしての質（難易度）を劇的に高める効果があります。

生成パイプラインのアーキテクチャ設計

これをバッチ処理で実行します。推奨する構成は以下の通りです。

1. Source Data: 社内Wikiやドキュメントストアから取得したテキストチャンク。
2. Generator (LLM): 最高レベルの推論能力を持つフラッグシップモデルを使用します。
   • Hard Negativeの生成には微細な文脈理解が必要です。2026年現在、AIモデルの世代交代が急速に進んでおり、モデル選定と移行計画がパイプライン設計の要となります。
   • OpenAI APIを利用する場合: GPT-4oやGPT-4.1などの旧モデルは2026年2月13日をもって廃止されました。現在利用可能な主力モデルはGPT-5.2（InstantおよびThinking）です。長い文脈理解や文章の構造化能力が大幅に改善されているため、旧モデルを使用していたシステムは、API呼び出し時のモデル指定（model="gpt-5.2-thinking"など）を速やかに最新版へ更新する移行作業を実施してください。
   • Anthropic APIを利用する場合: 2026年2月にリリースされたClaude Sonnet 4.6が現在の標準モデルです。100万トークンという長文コンテキスト推論に対応し、前世代のOpusクラスの性能を低コストで実現しています。特に、タスクの複雑度に応じて思考の深さを自動調整する「Adaptive Thinking」機能が搭載されており、API呼び出し時にthinking={"type": "adaptive"}と指定することで、より精緻で矛盾のないHard Negative生成が可能になります。
   • コストよりも生成されるデータの質を優先し、常に公式ドキュメントで最新のAPI仕様と推奨モデルを確認する運用フローを構築することが重要です。
3. Vector DB: 生成したHard Negativeを一時保存し、検証用インデックスを構築します。

しかし、ここで生成されたデータをそのまま信用してはいけません。ここからが検索精度を左右する重要な「フィルタリング」の工程となります。

品質保証：False Negativeを防ぐフィルタリングプロセス

自動生成にはリスクが伴います。それは、「生成されたネガティブサンプルが、実は正解（あるいは正解とみなしてよい内容）を含んでしまう」ことです。これを「False Negative（偽の不正解）」と呼びます。

例えば、「A製品の価格は？」というクエリに対し、LLMがHard Negativeとして「A製品の価格は以前は1000円でした」と生成したとします。しかし、もし現在のドキュメントにもその記述があり、ユーザーが過去の価格を知りたい文脈であれば、これは不正解とは言い切れません。

もし、実は正解であるデータを「これは不正解だ」とモデルに学習させてしまうと、モデルは混乱し、正しい検索結果まで除外するようになってしまいます。

「正解になってしまっていないか」の検知

このリスクを排除し、実用的な品質を担保するために、以下の3段階のフィルタリングを実装します。

1. Cross-Encoderによる類似度スコアリング

生成されたHard Negativeとクエリの関連度を、高精度なCross-Encoderモデル（rerankerなど）でスコアリングします。
Bi-Encoder（ベクトル検索用）よりもCross-Encoderの方が文脈理解力が高いため、ここで「スコアが高すぎる（＝正解に近すぎる）」データは閾値を設けて機械的に除外します。

2. LLM-as-a-Judge（AIによるダブルチェック）

生成したLLMとは別のLLM（または別のプロンプト）を用意し、「審査員」の役割を与えます。

「以下のクエリに対し、このドキュメントは回答として適切ですか？ 『はい』か『いいえ』で答えてください」

ここで「はい（回答として適切）」と判定されたものは、Hard Negativeとして不適切（＝正解になってしまっている）であるため廃棄します。これは「Critic（批判者）モデル」と呼ばれる論理的なアプローチです。

3. Human-in-the-Loopによる最終確認フロー

全てのデータを人間が目視確認するのは現実的ではありませんが、サンプリング検査は必須です。特に生成の初期段階や、プロンプトを変更した直後は、生成されたデータの10〜20%を人間が確認します。

ここで現場主義の観点から重要なのは、エンジニアだけでなく、実際の業務やドキュメントの内容を深く理解している「ドメイン担当者」を巻き込むことです。エンジニアが見ても判断が難しい細かな差異が、現場の担当者から見れば明確に判断できるケースが多々あるからです。

この厳密なフィルタリングを経て残ったデータこそが、検索モデルを鍛え上げるための価値あるデータとなります。

運用と効果測定：評価指標と継続的改善サイクル

作成したHard Negative評価セットを使用して、実際に検索システムの精度を測定します。

追跡すべきKPI

単に「正解率」を見るだけでは、実務上の評価としては不十分です。ランキング学習の文脈では、以下の指標を重視して効果測定を行います。

• NDCG@k (Normalized Discounted Cumulative Gain):
  • 検索結果の上位（例えばTop 10）に、どれだけ正解が含まれているか、かつ「より上位に」正解があるかを評価します。Hard Negativeが正しく機能していれば、際どい不正解が下位に沈み、NDCGスコアが向上するはずです。
• Hit Rate (Recall@k):
  • 上位k件の中に正解が1つでも含まれている割合です。これはシステムの最低限の要件（ベースライン）として維持する必要があります。

改善前後の比較検証（オフライン評価）

本番環境で実際のユーザーを対象にテストを行う前に、まずは作成したデータセットでオフライン評価を実施します。これはA/Bテストの前段階として非常に重要です。

1. Baseline: Random Negativeのみで学習/評価した場合のスコア
2. Experiment: Hard Negativeを混合させた場合のスコア

良質なHard Negativeを適切な量（正解データの1〜2倍程度）混ぜることで、NDCG@10が改善する傾向にあります。特に「惜しい間違い」が減少することで、ユーザーが体感する検索精度は大きく向上します。

データドリフトへの対応とデータセット更新

システムは一度構築して終わりではありません。社内ドキュメントや製品情報は日々の業務の中で絶えず更新されます。

• 製品の仕様が変更された
• 組織変更に伴い部署名が変わった

こうした現実の変化に合わせて、Hard Negativeも再生成する必要があります。最近のトレンドでは、これをLLMOps（LLM Operations）の重要なプロセスとして位置づけることが一般的です。

具体的には、ドキュメントの更新をトリガーとして、評価用データセット（QAペアやNegativeサンプル）の一部を自動的にリフレッシュするパイプラインを構築します。RAG（検索拡張生成）システムの運用において、データの鮮度と検索精度の両立は継続的な課題となります。手動での更新は運用コストの増大を招くため、データパイプラインに自動評価の仕組みを組み込むことが、長期的な精度維持と費用対効果の最大化の鍵となります。

まとめ

検索システムの精度向上において、アルゴリズムの選定と同じくらい重要なのが「評価データの質」です。

1. Random Negativeだけでは不十分：モデルの識別能力を鍛えるには「Hard Negative」が不可欠です。
2. LLMによる自動生成が鍵：人手によるコストを抑えつつ、多様なパターンの「難しい不正解」を効率的に生成します。
3. フィルタリングこそが重要：生成されたデータに潜む「False Negative（実は正解）」を排除するプロセスが、実用的な品質を担保します。

「なんとなく検索できる」状態から、現場の業務に耐えうる「信頼できる検索システム」へと進化させるためには、このような現実的で論理的なデータエンジニアリングの工程が極めて重要になります。