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

RAG（Retrieval-Augmented Generation）システムを構築する際、Embeddingの次元数は見落とされがちでありながら、検索精度・ストレージコスト・検索速度・サーバースペックのすべてに影響する重要な設計パラメータです。「とりあえずデフォルトの1536次元で」と決めてしまい、データ量が増えてから検索遅延やコスト増に直面するケースは少なくありません。

本稿では、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
)

バッチ処理での実装

# 複数チャンクを効率的に処理
chunks = ["チャンク1", "チャンク2", ..., "チャンク100"]

response = client.embeddings.create(
    model="text-embedding-3-small",
    input=chunks,
    dimensions=768  # コスト削減のため768次元を指定
)

embeddings = [data.embedding for data in response.data]

次元削減のメカニズム

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

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

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

コスト・パフォーマンス分析

OpenAI APIのコスト比較

text-embedding-3-smallは次元数に関わらず同一料金（$0.02 / 1Mトークン）ですが、ストレージコストと検索速度は次元数に応じて変動します。

10万チャンクのRAGシステム（月間100万クエリ想定）

※ストレージ: AWS RDS PostgreSQL、検索: Lambda実行コストの概算

Ollamaのリソースコスト

ローカルLLMで自前Embeddingを生成する場合、次元数による処理時間の違いがサーバーコストに影響します。

100万チャンク処理時間（Apple M1 Max、GPU使用）

• 768d（nomic-embed-text）: 約14時間
• 1024d（mxbai-embed-large）: 約18時間
• 1536d（カスタムモデル）: 約25時間

GPU時間の単価を考慮すると、初期Embedding生成のフェーズでは次元数が総コストに大きく影響します。

ベクトルDB別の実装例

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))

ChromaDBでの実装

import chromadb

client = chromadb.Client()

# コレクション作成（次元数は自動検出）
collection = client.create_collection(
    name="docs_768d",
    metadata={"dimension": 768}  # 管理用
)

# データ追加
collection.add(
    embeddings=embeddings_768d,  # [[...], [...], ...]
    documents=documents,
    metadatas=metadatas,
    ids=ids
)

# 検索
results = collection.query(
    query_embeddings=[query_embedding_768d],
    n_results=10
)

Pineconeでの実装

from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="YOUR_API_KEY")

# インデックス作成（次元数を指定）
pc.create_index(
    name="rag-768d",
    dimension=768,  # 必須パラメータ
    metric="cosine",
    spec=ServerlessSpec(cloud="aws", region="us-east-1")
)

index = pc.Index("rag-768d")

# Upsert
index.upsert(
    vectors=[
        ("id1", embedding_768d, {"text": "内容"}),
        ("id2", embedding_768d, {"text": "内容"})
    ]
)

# 検索
results = index.query(
    vector=query_embedding_768d,
    top_k=10,
    include_metadata=True
)

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

768次元を選ぶべきケース

推奨シナリオ

• 大規模データ（100万チャンク以上）を扱う
• 検索速度を最優先する（リアルタイム応答）
• ストレージコストを抑えたい
• モバイル・エッジデバイスでの動作を前提とする

具体例

• ECサイトの商品検索（数百万商品）
• リアルタイムチャットボット
• 組み込みデバイスでのローカルRAG

実装例

# OpenAI API使用時
response = client.embeddings.create(
    model="text-embedding-3-small",
    input=texts,
    dimensions=768  # 明示的に指定
)

# Ollama使用時
import ollama

ollama.embeddings(
    model="nomic-embed-text",  # 768次元モデル
    prompt=text
)

1536次元を選ぶべきケース

推奨シナリオ

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

具体例

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

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

3072次元を選ぶべきケース

推奨シナリオ

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

具体例

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

実装例

# text-embedding-3-largeを使用
response = client.embeddings.create(
    model="text-embedding-3-large",  # largeモデル
    input=texts,
    dimensions=3072  # フル次元
)

実践的なアーキテクチャ設計

ハイブリッドアプローチ

用途に応じて次元数を使い分ける、段階的な検索戦略も有効です。

class HybridRAGSystem:
    def __init__(self):
        # 第1段階: 768次元で高速フィルタリング
        self.fast_index = ChromaDB(dimension=768)
        # 第2段階: 1536次元で精密ランキング
        self.precise_index = ChromaDB(dimension=1536)

    def search(self, query, top_k=10):
        # Step 1: 768次元で候補を1000件に絞る
        fast_results = self.fast_index.query(
            query_768d,
            n_results=1000
        )

        # Step 2: 上位候補を1536次元で再ランキング
        precise_results = self.precise_index.query(
            query_1536d,
            filter={"id": {"$in": fast_results.ids}},
            n_results=top_k
        )

        return precise_results

このアプローチにより、精度を維持しながら検索速度とコストを最適化できます。

段階的な移行戦略

プロジェクトの成長に応じて次元数を調整する戦略も現実的です。

1. プロトタイプ段階: 768次元で迅速に実装・検証する
2. β版リリース: 1536次元で精度を向上させる
3. スケール段階: データ増加に応じて768次元へ戻す、またはハイブリッド化する

# 移行スクリプト例
def migrate_dimensions(old_dim=1536, new_dim=768):
    # 既存データを再Embedding
    for batch in get_all_documents(batch_size=1000):
        new_embeddings = client.embeddings.create(
            model="text-embedding-3-small",
            input=batch.texts,
            dimensions=new_dim
        )
        # 新しいコレクションに保存
        new_collection.add(
            embeddings=new_embeddings,
            documents=batch.texts,
            metadatas=batch.metadatas
        )

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

まとめ

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

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

重要なのは、プロジェクト初期から過度に最適化せず、実際のデータとクエリで検証しながら調整することです。A/Bテストにより、自社のユースケースで次元数の違いが実際にどの程度の影響を与えるかを測定し、データに基づいて意思決定することを推奨します。

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