「OpenAIの最新Embeddingモデルを使っているのに、なぜか社内の専門用語がヒットしないんです」
実務の現場では、こうした課題が頻繁に聞かれます。最高峰のLLM（大規模言語モデル）を採用し、RAG（検索拡張生成）システムを構築していても、PoC（概念実証）の段階で壁にぶつかるケースは少なくありません。
その課題の要因は、「ベクトル空間の歪み」です。
汎用的なAIモデルは、インターネット上の膨大なテキストで学習していますが、特定の業界特有の「言葉のニュアンス」や「略語の定義」までは深く理解していません。結果として、人間なら直感的にわかる「関連性」を、AIが見落としてしまうことがあります。
今回は、単なるツールの使い方ではなく、ビジネスへの最短距離を描くための根本的なアプローチ、すなわち「AIに業界の常識（ドメイン知識）をインストールするデータ処理」について解説します。ベクトル空間を正しく再構築することで、RAGの検索精度は劇的に向上する可能性があります。まずは動くプロトタイプをイメージしながら、その理論と実践手法を紐解いていきましょう。
なぜ汎用LLMは「専門用語」の検索に失敗するのか
まずは、問題の本質である「ベクトル空間」について、少し視覚的なイメージを持っていただきたいと思います。AIが言葉の意味を理解するとき、すべての単語や文章を多次元の空間（ベクトル空間）上の「点」として配置します。意味が近い言葉は近くに、遠い言葉は遠くに置かれる、いわば「言葉の地図」です。
汎用学習データの限界とバイアス
OpenAIやGoogleが提供する最新の汎用埋め込みモデル（Embedding Model）は、Wikipediaや一般的なWeb記事を教科書として学習しています。彼らの地図はあくまで「一般常識」に基づいて構築されています。
しかし、金融や医療の世界では、この地図が役に立たないことが多々あります。例えば、一般的な文脈では「癌」と「悪性新生物」は関連語として認識されますが、医療保険の約款における厳密な定義の違いまでは、汎用モデルの初期状態では区別しきれないことがあります。あるいは、組織固有のプロジェクトコード名や、業界特有の略語（例：金融における「与信」と単なる「信用」の違い）が、汎用的な意味空間ではまったく別の場所に配置されてしまうのです。
ベクトル空間における「意味の距離」の歪み
これが「ベクトル空間の歪み」です。
本来、特定のビジネスドメインでは「隣り合うべき」文書とクエリが、汎用モデルの空間では「遠く離れた」場所に配置されています。RAGシステムは、ユーザーの質問（クエリ）に近いベクトルを持つ文書を探しに行きますが、地図が歪んでいるため、本当に必要なドキュメントを見つけられず、的外れな回答を生成してしまうことがあります。
昨今のトレンドとして、知識グラフを用いて用語間の関係性を補強する「GraphRAG」や、図表を含めた「マルチモーダルRAG」といった技術も進化していますが、基礎となるベクトル空間自体が歪んでいては、その効果も限定的になります。検索アルゴリズムの工夫（リランキングやハイブリッド検索）だけでなく、地図そのもの、つまりドメインに特化した埋め込みモデルへの適応が不可欠です。
金融・医療特有の「同義語・略語」問題
特に顕著なのが、同義語や略語の扱いです。
- 金融: 「デフォルト」という言葉は、IT用語としては「初期設定」ですが、金融では「債務不履行」を指します。文脈を理解していないモデルは、システム設定のマニュアルを検索結果に出してしまうかもしれません。
- 医療: 「AMI」は「急性心筋梗塞（Acute Myocardial Infarction）」の略ですが、モデルがこの略語知識を持っていなければ、単なるアルファベットの羅列として処理され、重要な症例データを見落とす可能性があります。
このように、汎用モデルの「知っていること」と、実務で「必要な知識」のギャップ（乖離）が、検索精度（Recall）を押し下げる主要因となっています。
ドメイン適応（Domain Adaptation）のメカニズム
では、どうすればこの歪んだ地図を修正できるのでしょうか。その答えが「ドメイン適応（Domain Adaptation）」です。これは、既存の高性能なモデルをベースに、特定の業界知識を追加で教え込むプロセスです。
追加学習（Fine-tuning）による空間補正
ドメイン適応は、更地から建物を建てるのではなく、既存の建物をリノベーションする作業に似ています。ベースとなるモデル（例えばBERTベースのモデルなど）はすでに日本語の文法や基本的な単語の意味を知っています。そこに、特定の業界特有のテキストデータを与え、「この業界では、この言葉とこの言葉は近い意味だよ」と教え込むのです。
これにより、ベクトル空間上の点の配置が徐々に移動し、業界の文脈に沿った「新しい地図」が形成されます。
対照学習（Contrastive Learning）の基本原理
埋め込みモデルの学習で最も一般的に使われるのが対照学習（Contrastive Learning）です。仕組みは非常にシンプルですが、強力です。
- ポジティブペア: 質問と、その正解となる文書のペア。「これらは近い」と教えます。
- ネガティブペア: 質問と、関係のない文書のペア。「これらは遠い」と教えます。
モデルはこのペアを大量に見ることで、関連する文書のベクトル同士を引き寄せ（引力）、無関係な文書のベクトルを突き放す（斥力）ようにパラメータを更新します。磁石のS極とN極を操作するように、ベクトル空間を物理的に再配置していくイメージを持ってください。
特化型モデルがもたらす検索精度の変化
実際にこの処理を行うと、検索精度はどう変わるのでしょうか。
適切に導入した場合、汎用モデルでの検索精度（Top-10 Recall）が65%程度だった環境において、専門的なガイドラインを用いてドメイン適応を行った結果、85%以上まで向上した事例があります。特に、専門用語を含むクエリでの改善が著しく、現場のプロフェッショナルが使う専門用語での検索漏れが激減します。
重要なのは、数万件という大規模なデータセットがなくても、数百〜数千件の「高品質なペアデータ」があれば、劇的な改善が見込めるという点です。まずは小さなデータセットでプロトタイプを作り、仮説を即座に形にして検証することが成功への近道です。
学習用データの準備と前処理プロセス
「理論はわかったが、学習データはどうやって用意すればいいのか？」
これが多くのエンジニアが抱く疑問でしょう。ここからは、データ処理のパイプライン（工程）を解説します。ここがモデルの性能を決定づける最重要ポイントとなります。
社内文書からのコーパス構築手順
まず、社内にあるPDFのマニュアル、Excelの規定集、過去のQAログなどを集めます。これらをテキストデータとして抽出し、クリーニング（前処理）を行います。非構造化データの処理は泥臭い作業ですが、ここを疎かにすると後の工程すべてに悪影響が出ます。
- ノイズ除去: ヘッダー、フッター、ページ番号、社外秘マークなどの不要な情報を正規表現等で削除します。
- チャンキング: 長い文書を適切な長さ（例：512トークン程度）に分割します。単に文字数で切るのではなく、セクションや段落といった「意味のまとまり」を保持して分割することが、検索精度向上の鍵です。
専門用語辞書を活用したノイズ除去
金融や医療の現場では、OCR（光学文字認識）の読み取りエラーが致命的なノイズになります。例えば、数値の「1」と英字の「l」、あるいは専門的な薬剤名の誤認識などです。
ここで有効なのが、業界用語辞書を活用したフィルタリング処理です。明らかに誤っている用語を修正したり、信頼度の低いテキストを除外したりします。データの質（Quality）が、そのまま埋め込みモデルの「賢さ」に直結するため、ドメイン固有の辞書を用いた正規化は丁寧に行う必要があります。
学習用ペアデータ（クエリと正解文書）の生成戦略
ここが最大のポイントです。学習には「質問（Query）」と「正解文書（Positive Document）」のペアが必要です。しかし、人手で数千、数万のペアを作るのは現実的ではありません。
そこで、推論能力に優れた最新のLLM（Thinkingモデル等）を活用した「擬似クエリ生成（Synthetic Query Generation）」を行います。従来のモデルと比較して、最新のモデルは文脈理解が深く、より人間に近い複雑な質問を生成可能です。
- 推論モデルによる生成: チャンク化した社内文書をLLMに入力し、単なるキーワード検索では解けないような「文脈理解が必要な質問」を生成させます。
- プロンプト例：「この文書の内容を前提として、専門家が尋ねそうな具体的かつ複雑な質問を作成してください」
- 多様性の確保: 1つの文書に対して、専門用語を用いた質問、平易な言葉での質問、具体的なシナリオに基づいた質問など、複数のバリエーションを作成します。
- Human-in-the-loopによる検証: 生成されたデータは完璧ではありません。Canvas機能のようなドキュメント編集UIを活用し、生成されたペアの一部を人間がレビュー・修正するプロセスを組み込むことで、データセットの信頼性を担保します。
さらに、Hard Negatives（難易度の高い不正解）の生成も重要です。単にランダムな文書を「不正解」とするのではなく、LLMを活用して「キーワードは共通しているが、論理的に答えになっていない文書」を選定・生成させます。これにより、モデルは「単語の一致」ではなく「意味の適合」を学習し、微細なニュアンスの違いを識別できるようになります。
モデル評価と導入判断の基準
モデルを作成したら、実戦投入する前に厳密な評価が必要です。「なんとなく検索結果が良くなった気がする」という感覚値での判断は避けるべきです。
情報検索タスクにおける評価指標（NDCG, MRR）
検索システムの評価には、主に以下の指標を用います。
- NDCG@k (Normalized Discounted Cumulative Gain): 検索結果の上位に正解が含まれているかだけでなく、「順位」も考慮した指標です。1位に正解がある方が、10位にあるより高く評価されます。
- MRR (Mean Reciprocal Rank): 正解が最初に出現した順位の逆数の平均です。最初の正解がいかに早く見つかるかを重視します。
MTEB (Massive Text Embedding Benchmark) などの公開ベンチマークも参考になりますが、最終的には「自社のテストデータ」でのスコアが重要です。開発用データとは別に、評価用のQAセット（人手で作った高品質なもの）を必ず用意してください。
汎用モデルvs特化モデルの比較検証フロー
評価の際は、必ずベースライン（汎用モデル）と比較します。
- 同じクエリセットを、汎用モデルと特化モデルの両方に投げる。
- それぞれの検索結果トップ10を取得する。
- 正解文書が含まれている割合（Recall）と、その順位（NDCG）を比較する。
もし特化モデルのスコアが汎用モデルを下回る、あるいは大差がない場合は、学習データの質を見直すか、過学習を疑う必要があります。
過学習（Overfitting）のリスクと回避策
特定の文書に特化させすぎると、少し言い回しが変わっただけで検索できなくなる「過学習」が起こります。これを防ぐには、学習データに多様性を持たせることや、学習率（Learning Rate）を適切に低く設定することが重要です。また、ドメイン適応によって一般的な日本語能力が低下していないか（Catastrophic Forgetting：破滅的忘却）も、一般的なデータセットで軽くチェックしておくと安心です。
次のステップ：自社専用Embeddingの実装へ
理論と評価方法がわかったところで、次は「実際にどう動くか」です。アジャイルかつスピーディーに検証を進めるための、具体的な実装へのロードマップを示します。
オープンソースモデル（Hugging Face）の活用
ゼロからモデルを作る必要はありません。Hugging Faceには、日本語に強いベースモデル（例えば intfloat/multilingual-e5 シリーズや BGE モデルなど）が多数公開されています。これらをベースに、Sentence Transformers ライブラリなどを使って、用意した社内データで追加学習（Fine-tuning）を行うのが最も効率的です。オープンソース界隈ではモデルの進化が速く、より軽量で高性能なモデルが次々と登場しているため、プロジェクト開始時には最新のリーダーボードを確認することをお勧めします。
クラウドサービス（AWS Bedrock等）での実装
セキュリティ要件が厳しく、ローカル環境での学習が難しい場合は、AWS BedrockやAzure OpenAIなどのマネージドサービスを活用するのが現実的です。これらのプラットフォームでは、基盤モデルを自社データでカスタマイズする機能（Custom ModelsやFine-tuning）が提供されています。インフラ管理の手間を省きつつ、エンタープライズレベルのセキュリティ環境でモデルをドメイン適応させることが可能です。なお、利用可能なモデルや機能は頻繁にアップデートされるため、実装前には必ず公式ドキュメントで最新の対応状況を確認してください。
継続的なデータ改善ループ
モデルは一度作って終わりではありません。RAGシステム運用開始後は、ユーザーの実際の検索ログを収集しましょう。「検索結果がクリックされなかったクエリ」や「ユーザーからの低評価フィードバック」は、モデルの改善点を示す貴重な情報源となります。さらに、高度な推論能力を持つ最新のLLM（GPT-4やClaude 3など）を活用して、不足している学習データ（クエリとドキュメントのペア）を合成生成し、モデルを再学習させるループを回すことも、精度向上のための強力な手法です。
まとめ
汎用モデルの限界を突破し、金融・医療といった専門領域でRAGを成功させる鍵は、「ベクトル空間の歪みを正す」ことにあります。
- 課題認識: 汎用モデルは業界特有の「言葉の距離感」を持っていない。
- 解決策: ドメイン適応によって、AIに業界の地図をインストールする。
- 実践: 社内文書から高品質なペアデータを生成し、対照学習を行う。
- 評価: 定量的な指標で精度の向上を確認し、継続的に改善する。
このプロセスを経ることで、RAGシステムはより専門的な情報を扱えるようになります。
コメント