社内用語・略称・型番が検索に当たらないとき：用語集とハイブリッド検索の使い分け

まず原因を3つに切り分ける

同じ「ヒットしない」でも、次の3種類があります。

• 型番を入れても別の製品の資料が出る、想定される原因：意味検索が固有の文字列を区別できていない
• 通称で聞くと出ず、正式名称で聞くと出る、想定される原因：文書側にその言い方が存在しない
• 略称で聞くと別部署の資料が出る、想定される原因：一つの略称が複数の意味を持っている

切り分けには、同じ質問を「キーワード検索のみ」「意味検索のみ」「両方」で流し、上位10件に正解の文書やチャンクが入るかを見ます。キーワードだけで当たるなら固有表現の問題、どちらでも当たらないなら文書側に用語がない問題（またはチャンクの分割で用語が切れている問題）です。

意味検索が固有表現に弱い理由と、ハイブリッド検索の役割

MicrosoftのAzure AI Searchの解説は、製品コード、専門性の高い用語、日付、人名などはキーワード検索のほうが完全一致を見つけられるため向く、と述べています。ハイブリッド検索は全文検索とベクトル検索を並行して走らせ、結果を統合する方式です。

Google CloudのVector Searchのハイブリッド検索の説明でも、意味を表す密ベクトルは製品SKUや新製品のような学習データにない語が苦手で、キーワード頻度に基づく疎ベクトルは型番や社内コードネームに強いとされています。

統合にはRRF（Reciprocal Rank Fusion）がよく使われます。Azureの説明によれば、各検索結果の順位から点数を付けて足し合わせ、複数のリストで上位にある文書を押し上げる仕組みです。

ただし、ハイブリッド検索は「文書に同じ文字列がある」ことが前提です。通称が文書のどこにも書かれていなければ、キーワード側も当たりません。そこで用語集の出番になります。

固有名詞を含む質問の振り分け表

質問を受けたとき、どの手段を優先するかの目安です（編集上の提案で、自社データでの確認が必要です）。

• 型番・コードの完全一致、説明用の例：「MX-4200N の消耗品コードは？」、優先する手段：キーワード検索を主に。表記ゆれ（ハイフン有無）を登録、確認すること：正解が上位に出るか
• 概念＋型番、説明用の例：「MX-4200N の紙詰まりの直し方」、優先する手段：ハイブリッド検索、確認すること：型番違いの資料が混ざらないか
• 通称・社内呼称、説明用の例：「営業のあのアプリ、権限申請は？」、優先する手段：用語集で正式名称に展開してから検索、確認すること：展開後の語が文書にあるか
• 多義の略称、説明用の例：「SRの提出期限は？」、優先する手段：聞き返す、または部署で絞る、確認すること：候補の意味を人が決めたか
• 新製品・新用語、説明用の例：発売直後の型番、優先する手段：キーワード側を優先、確認すること：文書の取り込みが済んでいるか
• 文書に定義がない用語、説明用の例：口頭でのみ使う呼称、優先する手段：用語集に定義を追加。なければ「資料にない」と答えさせる、確認すること：定義の出典

用語集のひな形

次の列を持つ表（スプレッドシートで十分です）を作ります。1行が1概念です。

• 正式名称、内容：文書で使う表記、説明用の例：複合機 MX-4200N
• 別表記・略称、内容：通称、略称、ハイフン有無、説明用の例：MX4200N, MX 4200N, 4200
• 種別、内容：型番／略称／通称／部署名、説明用の例：型番
• 展開の向き、内容：双方向か、一方向か、説明用の例：双方向
• 曖昧さ、内容：他の意味がないか、説明用の例：なし
• 出典、内容：根拠となる文書、説明用の例：製品仕様書 v3
• 確認者・確認日、内容：人が見た記録、説明用の例：空欄

「SR」のように多義なものは、1語を1行にせず、意味ごとに行を分けて「曖昧さ」に競合先を書きます。展開してよいのは、意味が一つに決まるものだけにします。

検索エンジン側に登録する場合

Azure AI Searchでは同義語マップで同じ考え方を実現できます。形式はSolr形式のみで、カンマ区切りが「どれでも同じ」、=> が「左を右に置き換える」です。置き換えは指定した向きにだけ働きます。説明用の例です。

{
  "name": "internal-terms",
  "format": "solr",
  "synonyms": "MX-4200N, MX4200N, MX 4200N\nキャッシュ君 => 経費精算システム\n"
}

公式ページには、この機能が検索語を書き換えるクエリ拡張であること、同義語を割り当てた文字列フィールドにだけ効くこと、フィルターには使えないことが書かれています。クエリ側の語は小文字化され、ハイフンなどの記号は既定のアナライザーで落ちることがあるため、型番を扱うなら記号を保持するアナライザーの検討が必要とされています。同義語マップの作成や割り当てはAPIやSDKで行い、Azureポータルからは定義できません。

別の検索基盤を使う場合も、同様の機能の有無と仕様を、使う製品の資料で確認してください。

質問の言い換えで補う

同義語機能がない環境では、LLMに質問を書き換えさせる方法があります。用語集をプロンプトに入れ、検索前に展開させます。

あなたは社内検索の前処理担当です。次の用語集だけを根拠に、利用者の質問を検索用に書き換えてください。
- 用語集に一意に対応する語は、元の語を残したまま正式名称と型番の別表記を併記する
- 用語集に複数の意味がある略称は、書き換えず「要確認：候補A / 候補B」と返す
- 用語集にない語は推測で展開しない
出力は「検索クエリ」と「要確認」の2項目のみ。

【用語集】（ここに表を貼る）
【質問】SRの提出期限は？

元の語を残して併記するのがコツです。展開が誤っていても、元の語で当たる可能性が残ります。「要確認」が返ったら、聞き返すか部署で絞る処理に回します。

用語集づくりで人が確認すること

LLMに「文書から略称と正式名称の候補を抜き出して表にして」と頼むことはできますが、掲載の可否は人が決めます。特に、多義語の分離、機密の呼称を外部サービスへ渡してよいか、出典と食い違う展開がないかは、人が見てください。

運用は次の順がおすすめです。

1. 「当たらなかった質問」を20〜30件集める
2. 上の3パターン切り分けで原因を分類する
3. 用語集に行を足すか、キーワード検索の重みを見直す（Google CloudのVector Searchには密と疎の重みを0〜1で調整する rrf_ranking_alpha があります）
4. 同じ質問で再テストし、他の質問が悪化していないか確認する

用語集を足すと、別の質問が当たらなくなることがあります。追加のたびに同じ質問セットで見比べると、原因を追いやすくなります。