RAGのEmbedding次元設計｜768d/1536d/3072dの比較と選定指針

RAG（Retrieval-Augmented Generation）システムのEmbedding次元数は、検索精度・ストレージコスト・検索速度・サーバースペックに影響する設計パラメータです。社内RAG基盤では、データ量の増加に伴う検索遅延やコストを考慮して選定する必要があります。

768次元・1536次元・3072次元の違いを整理し、DigitalBaseが社内RAG基盤を構築する際に用いている選定指針を解説します。

Embedding次元数の基礎知識

次元数とは

Embeddingの次元数は、テキストを表現するベクトルの要素数です。次元数が高いほど、より細かな意味的ニュアンスを表現できる一方、ストレージや計算コストが増加します。

例えば、768次元のベクトルは次のような形式になります。

[0.023, -0.156, 0.891, ..., 0.234]  # 768個の浮動小数点数

主要なEmbeddingモデルと次元数

OpenAIのtext-embedding-3-small/largeは、dimensionsパラメータで次元数を動的に調整できる点が特徴です。

次元数による違いの詳細比較

1. ストレージコスト

次元数はベクトルDBのストレージサイズに直接影響します。1万チャンクを格納した場合の容量（pgvector、float32）は次のとおりです。

# 計算式: チャンク数 × 次元数 × 4バイト(float32)
768次元:  10,000 × 768   × 4 = 30.72 MB
1536次元: 10,000 × 1,536 × 4 = 61.44 MB
3072次元: 10,000 × 3,072 × 4 = 122.88 MB

100万チャンクの場合は次のとおりです。

• 768次元: 約3 GB
• 1536次元: 約6 GB
• 3072次元: 約12 GB

これに加えて、インデックス（HNSW、IVFFlat等）の容量も必要です。一般的にインデックスはベクトルデータの20〜40%程度を追加で消費します。

2. 検索速度

次元数が増えると、類似度計算（コサイン類似度、内積等）のコストが線形に増加します。

実測パフォーマンス（10万ベクトルから類似トップ10を検索）

※環境: PostgreSQL 15 + pgvector、HNSW index（m=16, ef_construction=64）

検索速度は次元数にほぼ比例して増加しますが、インデックスパラメータの最適化により影響を軽減できます。

3. メモリ使用量

ベクトル検索時には候補ベクトルをメモリに展開するため、次元数が高いほどメモリ消費が増加します。

10万ベクトル検索時のメモリ使用量

• 768次元: 約300 MB
• 1536次元: 約600 MB
• 3072次元: 約1.2 GB

大規模システムでは、この違いがサーバースペック選定に影響します。

4. 検索精度

次元数と精度の関係は線形ではありません。多くの場合、1536次元で十分な精度が得られ、3072次元への増加は限定的な改善にとどまります。

MTEB（Massive Text Embedding Benchmark）スコア例

• text-embedding-3-small（512d）: 61.2
• text-embedding-3-small（1536d）: 62.3
• text-embedding-3-large（1024d）: 62.8
• text-embedding-3-large（3072d）: 64.6

512次元→1536次元で約1.1ポイント、1536次元→3072次元で約2.3ポイントの改善です。精度要件が厳しくない用途では、次元数を増やすコストに見合う改善が得られるかを確認する必要があります。

OpenAI Embeddingsでの次元削減実装

OpenAIのtext-embedding-3-small/largeでは、dimensionsパラメータで次元数を指定できます。

基本的な実装

from openai import OpenAI

client = OpenAI()

# 1536次元（デフォルト）
response = client.embeddings.create(
    model="text-embedding-3-small",
    input="RAGシステムの実装方法"
)

# 768次元に削減
response = client.embeddings.create(
    model="text-embedding-3-small",
    input="RAGシステムの実装方法",
    dimensions=768
)

# 3072次元（text-embedding-3-large）
response = client.embeddings.create(
    model="text-embedding-3-large",
    input="RAGシステムの実装方法",
    dimensions=3072
)

次元削減のメカニズム

OpenAIのモデルは、高次元ベクトルから重要な次元を後から選択するのではなく、Matryoshka Representation Learning という手法を用いて学習されています。これにより、先頭から任意の次元数を切り出しても情報の損失を最小化できます。

設計時に押さえておくべき点は次のとおりです。

• 後から次元を増やすことはできない
• 異なる次元数のベクトルは比較できない
• 一度決めた次元数は、そのコレクション全体で統一する必要がある

pgvectorでの実装

import psycopg2
from pgvector.psycopg2 import register_vector

conn = psycopg2.connect(database="vectordb")
register_vector(conn)

# テーブル作成（次元数を指定）
cur = conn.cursor()
cur.execute("""
    CREATE TABLE embeddings_768 (
        id SERIAL PRIMARY KEY,
        content TEXT,
        embedding vector(768),  -- 次元数を明示
        metadata JSONB
    )
""")

# HNSWインデックス作成
cur.execute("""
    CREATE INDEX ON embeddings_768
    USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64)
""")

# データ挿入
cur.execute(
    "INSERT INTO embeddings_768 (content, embedding) VALUES (%s, %s)",
    ("テキスト", embedding_768d)
)

# 検索
cur.execute("""
    SELECT content, 1 - (embedding <=> %s) as similarity
    FROM embeddings_768
    ORDER BY embedding <=> %s
    LIMIT 10
""", (query_embedding, query_embedding))

ユースケース別の選定指針

768次元を選ぶべきケース

推奨シナリオ

• 大規模データ（100万チャンク以上）を扱う
• 検索速度を最優先する（リアルタイム応答）
• ストレージコストを抑えたい

具体例

• ECサイトの商品検索（数百万商品）
• リアルタイムチャットボット

1536次元を選ぶべきケース

推奨シナリオ

• 中規模データ（10万〜100万チャンク）
• 精度とコストのバランスを重視する
• 一般的なビジネスアプリケーション

具体例

• 社内ナレッジベース検索
• カスタマーサポートFAQ
• 技術ドキュメント検索

OpenAIのtext-embedding-3-smallはデフォルトで1536次元であり、多くのユースケースで最適なバランスを示します。迷った場合の標準的な出発点として推奨できます。

3072次元を選ぶべきケース

推奨シナリオ

• 最高精度が必要（数パーセントの改善が成果に直結する）
• データ量が比較的小規模（10万チャンク未満）
• コストよりも品質を優先する

具体例

• 法律文書の精密検索
• 学術論文のセマンティック検索
• 高度な推薦システム

次元数の変更と移行コスト

次元数は一度決めると変更にコレクション全体の再Embeddingを要するため、移行コストを見越したうえで初期設計を行うことが重要です。

まとめ

RAGシステムにおける次元数の選択は、検索精度・処理速度・ストレージコストのトレードオフです。一般的な指針は次のとおりです。

• 標準的な出発点: 1536次元（OpenAI text-embedding-3-small）
• 大規模・高速重視: 768次元
• 最高精度重視: 3072次元（OpenAI text-embedding-3-large）

選定時は、実際のデータとクエリで検証しながら調整します。A/Bテストで自社のユースケースにおける次元数の影響を測定し、結果に基づいて判断します。

次元数は後から変更しづらいパラメータであるため、将来のスケールを見据えた設計が欠かせません。不確実性が高い場合は、768次元または1536次元から始め、段階的に最適化する柔軟なアプローチが有効です。

下記のお悩みなら、ご相談ください

PoC から商用化に進むには、次の 3 点が必要になります。統合型 AI エージェント基盤「DigitalBase」は、 これらを 1 つの製品で提供しています。お気軽にご相談ください。