Embeddings は「検索の前に何を同じ意味として近づけるか」を決める層だ
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- 検索で困るのは、必要な資料がないことだけではない。資料はあるのに、言い方が違うせいで見つからないことが多い。
- embeddings は、この『言葉は違うが意味は近い』を拾うための下地である。ここが弱いと、後ろの生成 AI がいくら賢くても、最初に渡す資料を間違える。
- まず決めるべきなのは model 名ではなく、自分のサービスで何を『近い』と見なしたいかだ。質問文と社内文書だけを比べるのか、PDF や画像も一緒に探したいのかで設計が変わる。
- Gemini の新しい embeddings は、文字だけでなく画像、音声、動画、PDF も近さで比べる方向へ広がっている。つまり検索の対象が『文字に直した文書』だけではなくなっている。
- ただし裏方部品だから軽く差し替えられるわけではない。古い embedding model で作った検索用データは、新しい model へ移ると作り直しが必要になる場合がある。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
この guide が強いのは、embedding を text vector の説明で終わらせず、`gemini-embedding-2` を Gemini API 初の multimodal embedding model として、text、image、video、audio、documents を unified embedding space、つまり同じ意味の近さで比べられる共通の配置空間に置くと明記している点です。つまり検索対象を文字列に直せるものだけと考える必要がなくなります。同時に、text-only の task では用途ごとの prompt 形式が示され、PDF には OCR、ページ数、token 上限もあるため、入力設計責任も増えています。
なぜ重要か
日本の RAG 記事は text chunk 検索に偏りやすいですが、現場では PDF、図、画面キャプチャ、音声メモ、短い動画説明まで検索対象にしたいことが増えています。ここで embeddings を text-only 前提で理解していると、設計が最初から狭くなります。また Google は `gemini-embedding-001` と `gemini-embedding-2` の space が互換でないと明言しており、既存 index の再作成が要る。embeddings は気軽な裏方部品ではなく、移行計画を伴う基盤です。
技術的ポイント
- `gemini-embedding-2` は text、image、video、audio、PDF を同じ embedding space に写す multimodal model で、cross-modal search や分類に使える。文字だけの検索前提を崩す。
- text use case では task ごとに query と document の書式が推奨されている。search や question answering では `title` と `text` を分けた構造を入れるほうがよい。
- 出力次元は既定で 3072 だが、`output_dimensionality` で 768 や 1536 などへ縮められる。保存コストや下流計算を下げられる一方、index 設計として統一が要る。
- `gemini-embedding-001` と `gemini-embedding-2` は embedding space が非互換で、`task_type` の扱いも変わる。移行時は既存 corpus の再埋め込みが必要で、単純な model 名置換では済まない。
- PDF は OCR が常時有効で、1 ファイル最大 6 ページ、全 modality 合計 8192 token 上限、超過分は silent truncation と書かれている。multimodal でも投入量は無制限ではない。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| embeddings | ||
| multimodal embeddings | マルチモーダル埋め込み | テキストだけでなく画像、音声、動画、PDF なども意味の近さで比較できるようにする埋め込み。 |
| embedding space | 埋め込み空間 | 意味が近いデータ同士を近くに置く数値上の空間。モデルを替えると互換でない場合がある。 |
| output dimensionality | 出力次元数 | embedding ベクトルの長さ。保存量、検索性能、下流 index 設計に影響する。 |
| OCR |
試すなら
- まず自分の検索対象が text だけか、PDF や画像も含むかを書き出し、最初から modality を限定し過ぎない。
- query と document を同じ雑な文字列にせず、title や task を含む構造で小さく比較実験する。
- embedding model を切り替える前に、再埋め込み対象の件数、所要時間、vector DB 再構築の影響を見積もる。
- PDF や動画を入れる場合は token 上限と truncation を測り、全部入った前提で精度評価しない。
注意点
- multimodal だからといって、何でも 1 つの index に入れれば良いわけではない。アクセス権、更新頻度、引用 UX は別に設計が要る。
- embedding は答え生成そのものではない。検索面の設計が悪ければ、後段の生成品質も上がらない。
- `gemini-embedding-2` への移行では互換性がないため、古い embedding と混在比較すると判断を誤る。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。