Embeddingsは、文章を比較可能な数値表現へ変換する技術です。意味検索、分類、類似案件提示へ使う際の入力単位、類似度、固有コード対策、モデル評価、再計算、削除までを業務条件に沿って整理します。
Embeddingsは「意味を保存するデータ」ではなく比較用の数値表現
Embeddings(埋め込み)は、文章や画像などを固定長の数値配列へ変換し、近さを計算できるようにした表現です。OpenAIの公式ガイドは、検索、クラスタリング、推薦、異常検知、分類などの用途を挙げています[1]。ベクトルの各次元を人が読んで「この値は契約条件」と解釈するものではなく、同じモデルと前処理で作った表現同士を比較して使います。
「返品できない」と「返品は可能ではない」は語が違っても意味が近いため、意味検索では近くなることが期待されます。一方、製品番号`AB-1200`と`AB-120O`、法令の条番号、日付、金額は一文字の差が重要です。Embeddingsだけで完全一致の重要性を表せるとは限らないため、企業検索ではキーワード条件やメタデータフィルターを併用します。
| 用語 | 実務での意味 | 確認事項 |
|---|---|---|
| 埋め込みモデル | 入力をベクトルへ変換するモデル | 言語、入力上限、出力次元、利用条件 |
| 次元数 | ベクトルが持つ数値の個数 | 索引容量と検索実装が対応するか |
| 類似度 | 二つのベクトルの近さを測る方法 | コサイン、内積、ユークリッド距離のどれを使うか |
| メタデータ | 部署、版、日付、権限などの構造化属性 | 意味の近さより先に絞る条件があるか |
意味検索・分類・重複検知のどこへ使うか
同じEmbeddingsでも、用途ごとに正解と失敗の意味が違います。問い合わせ検索では正しいFAQが上位に入ること、分類では担当部署を当てること、重複検知では同じ案件を誤って二重登録しないことが目的です。一つの「精度」でまとめず、利用先ごとに評価セットを分けます。
| 用途 | 入力例 | 出力 | 向かない条件 |
|---|---|---|---|
| 意味検索 | 「請求書を再発行したい」 | 関連手順の候補順位 | 製品コード完全一致だけで答えが決まる |
| 問い合わせ分類 | 自由記述の相談文 | 経理、人事、ITなどの候補 | 一件で複数部署の承認が必要 |
| 類似案件提示 | 障害の症状と環境 | 過去インシデントの候補 | 古い対処が現行環境で危険 |
| 重複検知 | 商談名と説明 | 既存レコードとの近さ | 法人番号など一意キーが利用できる |
一意キーで決まる処理は通常の照合を優先します。Embeddingsは曖昧な言い換えを扱う補助であり、会計金額、権限、契約状態を確定する台帳の代わりにはなりません。
ベクトル化から検索までの一件の流れ
- 正本のFAQから質問、回答、製品、公開範囲、更新日を取得します。
- 検索に使う本文を正規化し、HTML装飾や不要な定型署名を除きます。
- 選定した埋め込みモデルで本文をベクトル化し、モデル識別子を保存します。
- ベクトルと文書ID、版、権限、更新日を同じレコードへ登録します。
- 利用者の質問を同じモデル・同じ前処理でベクトル化します。
- 権限と版で候補集合を絞った後、類似度で上位候補を求めます。
- 候補を画面またはRAGへ渡し、採用結果を評価ログへ残します。
問い合わせ側だけモデルを変更したり、登録時と検索時で全角・半角の処理を変えたりすると、比較条件が崩れます。Qdrantの公式ドキュメントはベクトル検索とフィルタリングを別の機能として説明しています[2]。製品を問わず、意味の近さと業務属性の絞り込みを同じものとして扱わないことが重要です。
stored_vector = embed(normalize(document_text), model_version)query_vector = embed(normalize(user_query), model_version)candidates = search( vector=query_vector, filter={status: "current", acl_group: user.groups}, top_k=20)
モデル変更では全件再計算と並行索引を計画する
異なる埋め込みモデルが作ったベクトルは、次元数が同じでも同じ空間とは限りません。既存文書を旧モデル、質問だけを新モデルで変換して比較する運用は避けます。移行時は新旧の索引を並行して作り、同じ固定質問で順位、検索時間、容量を比較します。
| 段階 | 実施内容 | 戻せる状態 |
|---|---|---|
| 準備 | モデル、次元、前処理、類似度を版として登録 | 旧索引の設定を固定 |
| 再計算 | 正本全件を新条件でベクトル化 | 旧索引を更新せず保持 |
| 比較 | 検索指標、権限フィルター、p95遅延を測定 | 利用者トラフィックは旧系のまま |
| 切替 | 限定利用者から新索引へ移す | ルーティングで旧系へ戻す |
| 廃止 | 保持期間後に旧ベクトルを削除 | 評価結果と設定は監査用に保存 |
切替理由は「新モデルだから」ではなく、業務データでの改善値と追加費用で示します。日本語、英数字混在、短文、長文を分けて評価し、一部の平均改善で重要な製品コード検索の悪化を隠さないようにします。
検索漏れと情報漏洩を別の失敗として扱う
類似度が低いため正解文書を取得できない問題は品質障害です。閲覧不可文書を候補へ含める問題はセキュリティ事故です。両方を「検索精度が悪い」とまとめると、公開可否の判断を誤ります。権限条件はベクトル検索後の画面処理ではなく、候補取得の時点で適用します。
- 表記揺れ:社内略称と正式名称の辞書を用意し、キーワード検索も比較します。
- 短すぎる入力:「できない」だけの質問は製品・操作を聞き返してから検索します。
- 否定の混同:可能・不可能を含む対の質問を評価セットへ入れます。
- 古い資料:類似度より版・有効日を優先するフィルターを使います。
- 越権候補:利用者グループを変えた陰性テストで返却0件を確認します。
また、ベクトルから元文章を完全に復元できないとしても、機密性が消えるわけではありません。ベクトル、メタデータ、元文書ID、ログを同じ情報資産としてアクセス制御と削除対象へ含めます。
モデル選定と業務正解の所有者を分ける
| 担当 | 決定事項 | 確認する数値 |
|---|---|---|
| 業務担当 | 検索目的、重要語、誤検索の影響、正解候補 | 上位候補の有用率、見逃した重要案件 |
| データ担当 | 前処理、入力単位、再計算、文書ID | 欠損、重複、再計算件数 |
| 検索担当 | モデル、次元、類似度、上位件数、索引 | Recall@k、p95遅延、索引容量 |
| セキュリティ担当 | 保存先、認可、ログ、削除 | 越権返却、削除漏れ、未許可送信 |
業務担当はモデル名ではなく、何を正解とするかを所有します。検索担当はその正解を再現する技術条件を所有します。モデルの更新情報だけを理由に切り替えるのではなく、業務側が承認した固定データで差分を確認します。
検索結果をRAGへ渡す場合、回答担当は取得候補をどう使うかを決めます。埋め込み担当が回答の正しさまで単独で保証することはできません。越権検索は品質チームではなくセキュリティ担当へ直ちに報告し、検索漏れと異なる停止基準で扱います。
500件のFAQで行う想定比較
以下は実績値ではなく、意味検索の評価設計を示す想定例です。FAQ 500件に対し、過去問い合わせから80問を作ります。各問には正しいFAQを1〜3件付け、製品コードを含む20問、言い換え30問、否定・例外15問、答えなし15問に分けます。
Recall@5 = 正しいFAQが上位5件に入った質問数 ÷ 正解あり65問無回答精度 = 上位候補なしと判断できた件数 ÷ 答えなし15問概算保存数値 = FAQ 500件 × ベクトル次元数再計算回数 = 文書件数 × 比較するモデル・次元の組み合わせ数
想定結果としてベクトル検索のRecall@5が58/65、キーワード検索が52/65でも、製品コード20問だけを見るとベクトル12/20、キーワード19/20かもしれません。この場合はベクトル検索へ一本化せず、製品コードを含む質問ではキーワードを強くするか、両者の順位を統合します。平均値より業務上失えない層を優先します。
採用判断に使う検索指標と停止条件
| 指標 | 用途 | 限界 | 停止条件の例 |
|---|---|---|---|
| Recall@k | 正解候補を取りこぼしていないか | 候補内の順位差を細かく表さない | 重要カテゴリの正解を1件でも落とす |
| MRR | 最初の正解が上位にあるか | 二つ目以降の正解を評価しにくい | 利用者が確認できる順位を超える |
| p95検索時間 | 遅い検索の体感を把握 | 回答生成時間は含まない | 画面の待機上限を連続超過 |
| 越権返却件数 | 認可の合否 | 検索品質とは別軸 | 1件でも本番公開を止める |
| 再索引所要時間 | 更新・障害復旧の計画 | 通常検索の品質を示さない | 定めた復旧時間内に終わらない |
Sentence-BERTの原著論文は、文を比較可能な埋め込みへ変換し、コサイン類似度で効率よく比較する方法を報告しています[3]。ただし、論文ベンチマークの値を自社FAQへそのまま適用できません。日本語の社内略語、誤字、固有コード、権限条件を含む自社評価で採否を決めます。
類似度の値は同じモデル・同じ前処理の中で読む
埋め込み検索では、質問ベクトルと文書ベクトルの近さをコサイン類似度、内積、ユークリッド距離などで測ります。値が大きいほど近いのか、小さいほど近いのかは計量方法で異なります。さらに、同じ「0.8」でもモデル、次元、正規化、文書の長さが変われば意味は同じではありません。別環境の閾値をコピーせず、自社の正解付きデータで決めます。
コサイン類似度 = (A・B) ÷ (||A|| × ||B||)例:A = 質問「領収書を失くした」B = FAQ「領収書紛失時の精算」C = FAQ「領収書の保存期間」期待:similarity(A, B) > similarity(A, C)ただし、採用閾値は評価データで決定する。
類似度が高くても、業務上の正解とは限りません。「海外出張の日当」と「国内出張の日当」は意味が近い一方、金額は別です。「解約できる」と「解約できない」も多くの語を共有します。検索候補へ入った後、地域、契約状態、否定、日付などの条件をメタデータや再順位付けで確認します。
| 条件 | 意味検索の役割 | 追加する判定 |
|---|---|---|
| 製品コード | 周辺説明の候補取得 | コードの完全一致・正規化 |
| 否定・例外 | 関連規程の探索 | 否定表現と例外条項の項目抽出 |
| 施行日 | 同じ制度の文書候補 | 対象日が有効期間に入るか |
| アクセス権 | 許可済み集合内の順位付け | 検索前の認可フィルター |
| 一意キー | 原則不要 | 台帳照合を優先 |
入力単位は検索後に利用者が読める範囲で決める
一つの文書全体を一つのベクトルにすると、章ごとの話題が平均化され、具体的な質問と近づきにくくなります。反対に一文ずつ分けると、条件と例外、見出しと本文、表題と数値が離れます。入力単位はトークン数だけでなく、検索結果として提示したときに根拠が理解できるまとまりで決めます。
| 文書 | 候補単位 | 保持する隣接情報 | 避ける分割 |
|---|---|---|---|
| FAQ | 質問と回答の一組 | 製品、対象者、更新日 | 質問と回答を別ベクトルにする |
| 規程 | 条・項または意味のまとまり | 章見出し、適用範囲、例外 | 「ただし」以降を別断片にする |
| 製品マニュアル | 一操作の目的から確認まで | 製品版、前提、警告、画面名 | 手順番号だけを単独保存 |
| 障害記録 | 症状・環境・原因・対処の一件 | 製品版、発生日、再発有無 | 原因と対処の対応を切る |
| 表 | 見出し付きの行群または構造化表 | 列名、単位、脚注 | 値だけを平文で連結 |
前処理では、全角・半角、Unicode、不要な空白をそろえますが、型番のハイフン、単位、否定語、大小文字が意味を持つ場合は消しません。会社固有の略称は正式名称へ置換するだけでなく、元の語も保持すると検索ログを説明しやすくなります。個人名や顧客IDを削除・置換する場合は、元文書との対応を権限付きで管理します。
質問側にも同じ前処理を適用します。ただし、短い質問へ文書本文と同じ分割は不要です。「つながらない」のように情報不足なら、製品、操作、エラー、発生時刻を聞き返します。曖昧な入力を大きな索引へ投げ、最上位を正解とみなす設計は避けます。
日本語・固有コード・長さ別の評価でモデルを選ぶ
埋め込みモデルの比較では、公開ベンチマーク、次元、価格、速度だけで決めません。自社の検索には、社内略語、英数字の型番、日本語と英語の混在、誤字、短い質問、長い規程が含まれます。これらを層別した正解データを作り、各層のRecall@kと順位を比較します。
| 評価層 | 例 | 件数例 | 重視する結果 |
|---|---|---|---|
| 自然な言い換え | 「立替を返して」→経費精算 | 40問 | 正解FAQが上位5件内 |
| 固有コード | `AX-210`と`AX-201` | 20問 | 近似コードの取り違え0件 |
| 否定・例外 | 利用可/利用不可 | 20問 | 反対条件を正解にしない |
| 日英混在 | 日本語質問と英語マニュアル | 20問 | 言語差を越えて根拠取得 |
| 根拠なし | 索引に答えがない新制度 | 20問 | 低品質候補を無理に採用しない |
候補モデルごとに同じ120問、同じ文書、同じ上位件数を使います。想定例としてモデルAの全体Recall@5が92%、モデルBが89%でも、固有コード層でAが75%、Bが95%なら、用途によってBまたはハイブリッド検索を選びます。全体平均だけで重要層の弱点を隠しません。
OpenAIのEmbeddings公式資料は検索などの用途とAPI利用方法を示しています[1]。Sentence-BERTの原著論文は文埋め込みを使った意味類似検索の効率化を報告しています[3]。製品資料や論文の結果は候補選定に使い、最終判断は自社データで行います。
容量・再計算・削除を含む運用費を見積もる
ベクトル索引の費用は、文書数だけでは決まりません。断片数、次元、数値型、メタデータ、索引方式、レプリカ、バックアップ、検索回数、再計算が影響します。以下は実績ではなく容量感をつかむ想定例です。100万断片、1,536次元、1要素4バイトなら、生ベクトルだけで約6.14GBです。索引構造、ID、メタデータ、複製を含めると増えるため、製品の実測値を使います。
生ベクトル容量= 1,000,000断片 × 1,536次元 × 4バイト= 6,144,000,000バイト(約6.14GB)月間再計算件数= 全件再計算1,000,000+ 日次更新2,000 × 30日= 1,060,000件
次元を減らせば容量と転送量を下げられる場合がありますが、検索品質との交換条件です。評価データでRecall@k、p95検索時間、索引容量を同時に比較します。Qdrantの公式ドキュメントは検索、フィルタリング、量子化、マルチテナンシーなどの機能を案内しています[2]。採用機能の対応版と制約を契約・実装時に確認します。
| 保存物 | 削除キー | 確認方法 | 担当 |
|---|---|---|---|
| 元文書 | 文書ID・版 | 保管庫から取得不能 | 文書所有者 |
| 断片本文 | 文書IDに属する断片ID | 検索結果0件 | データ担当 |
| ベクトル | 断片ID | 索引件数と削除ログ | 検索担当 |
| キャッシュ | 文書版・権限を含むキー | 期限前の無効化 | アプリ担当 |
| バックアップ・ログ | 保持規程 | 期限とアクセス制限 | セキュリティ担当 |
ベクトル化したから匿名になるとは限りません。機密文書から作ったベクトルとメタデータは、元文書と同等のアクセス区分で管理します。削除、権限変更、保存地域を追跡できないサービスは、機密性の高いRAGや類似案件検索には向きません。
分類では近傍候補と確信不足の扱いを設計する
Embeddingsを問い合わせ分類へ使う場合、既存チケットのベクトルと新規問い合わせを比較し、近い事例の部署やラベルを候補にできます。ただし、最も近い一件のラベルを必ず採用すると、新しい問い合わせ種別まで既存部署へ押し込みます。第一候補と第二候補の差、絶対的な近さ、対象ラベルの事例数を使って、人へ戻す条件を作ります。
| 状態 | 候補の例 | 処理 | 理由 |
|---|---|---|---|
| 明確 | 経理0.91、人事0.52 | 経理候補として担当者へ提示 | 上位が高く、次点との差も大きい |
| 競合 | 経理0.78、購買0.76 | 申請種別を聞き返す | 二部署をまたぐ可能性がある |
| 未知 | 最高でも0.43 | 総合窓口へ送る | 既存分類へ無理に当てはめない |
| 少数ラベル | 法務0.84、学習例3件 | 法務担当が確認 | 数件の偶然に依存する恐れがある |
上表の数値は架空の説明例であり、共通閾値ではありません。ラベルごとに文章の多様性と誤分類の影響が違います。経理と購買の誤分類は再振り分けで済んでも、情報セキュリティ事故を一般IT問い合わせへ送ると初動が遅れます。重大カテゴリは、類似度に加えて明示的な語、送信元、フォーム選択を使います。
評価では正解率だけでなく、ラベル別再現率、人へ戻した割合、誤転送による遅延を記録します。新しい制度や製品が始まった後は未知問い合わせが増えるため、定期的にクラスタを確認し、正式な新ラベルを追加します。利用者の自由記述を無断で学習データへ転用せず、保存目的と個人情報の扱いを決めます。
Embeddingsの導入可否を確かめる次作業
次の行動:業務責任者は、意味検索または分類から一用途だけを選びます。評価担当は、言い換え、固有コード、否定・例外、日英混在、正解なしを含む評価問題を作ります。候補モデルを同じ前処理、同じ文書、同じ上位件数で比較し、全体平均だけでなく重要カテゴリのRecall@k、越権0件、p95検索時間、索引容量を確認します。完全一致で決まる項目は通常照合へ戻し、埋め込みは曖昧な言い換えの候補取得に限定します。採用時はモデル版、次元、前処理、再計算、削除範囲を台帳へ登録します。
比較表には、モデル名と版、次元数、最大入力長、正規化方法、距離関数、1万件当たりの索引容量、再計算時間、重要カテゴリ別Recall@5、完全一致検索との併用有無を記録します。候補Aと候補Bは同じ文書スナップショットで各3回測り、平均だけでなく最も悪い結果も残します。料金表から求めた埋め込み生成費用と月間追加文書数からの試算は「見積もり」、検索時間と容量は検証環境の「実測」として列を分けます。固有の商品番号、法令条文番号、日付、否定表現で取り違えが起きる場合は、キーワード検索や属性フィルターを前段へ置きます。
採用後の責任境界も試験時に決めます。業務部門は正解ペアと重大カテゴリ、基盤担当はモデル版・索引・削除、セキュリティ担当はテナントと権限フィルター、運用責任者は再計算日と切り戻しを所有します。モデル変更で重要カテゴリのRecall@5が基準を下回る、削除文書が検索結果へ残る、前処理を再現できない場合は更新を止め、直前の索引へ戻します。
参考文献・出典
- OpenAI公式ドキュメント「Vector embeddings」現行Web版、版表記なし(2026-07-30参照)
- Qdrant公式ドキュメント「Qdrant Documentation」現行Web版、版表記なし(2026-07-30参照)
- Reimers and Gurevychの原著論文「Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks」EMNLP-IJCNLP 2019, pp.3982-3992(2026-07-30参照)