task_type は、embedding を生成するときに 「その埋め込みを何の用途に使うか」 をモデルへ伝えるパラメータ。同じテキストでも用途に合わせて最適化されたベクトルが得られる。embedding を使った retrieval（情報検索）では、この使い分けが検索精度を大きく左右する。
非対称検索：document と query を分ける
retrieval には性質の異なる 2 種類のテキストがある。
| 役割 | task_type | 公式の説明 |
|---|---|---|
| 検索される文書（document） | RETRIEVAL_DOCUMENT | ”Embeddings optimized for document search” |
| 検索クエリ（query） | RETRIEVAL_QUERY | ”Embeddings optimized for general search queries” |
document（長め・構造的）と query（短め・断片的）は文章の性質が違う。この差を埋めるよう 別々に最適化したベクトルを突き合わせる のが 非対称検索（asymmetric retrieval） で、retrieval の正攻法。
主なタスクタイプ（gemini-embedding-001）
| task_type | 用途 |
|---|---|
RETRIEVAL_DOCUMENT | 検索される文書 |
RETRIEVAL_QUERY | 検索クエリ |
SEMANTIC_SIMILARITY | 文同士の類似度比較（retrieval には使わない） |
CLASSIFICATION / CLUSTERING | 分類 / クラスタリング |
QUESTION_ANSWERING / FACT_VERIFICATION | QA / 事実検証 |
CODE_RETRIEVAL_QUERY | コード検索クエリ |
⚠️
SEMANTIC_SIMILARITYは名前に反して 検索・retrieval に使ってはいけない（公式明言：“Do not use this for search or retrieval”）。
よくある落とし穴
- 未指定は
RETRIEVAL_QUERYにデフォルト される。task_typeをどこにも指定しないと保存側・検索側が両方 QUERY になり、document が最適化されない。例外は出ないのに精度だけ落ちる。 - 片方だけ直しても無意味。
RETRIEVAL_DOCUMENTとRETRIEVAL_QUERYは必ずペアで揃える。 - コードを直しても既存ベクトルは直らない。保存済み document は正しい task_type で 再生成（再ベクター化） が必要。
- 新世代モデルでは扱いが変わる。
task_typeパラメータはgemini-embedding-001専用で、より新しい世代は プロンプト内に task を指示 として書く方式。
関連記事・用語
- ベクター検索の落とし穴：保存（document）と検索（query）で task_type を分けないとヒット率が落ちる — task_type 誤用の実例・直し方・運用順序
- embedding — task_type が最適化する対象
- ベクター検索 / セマンティック検索 — task_type が効く検索方式
- Gemini / Vertex AI