RAG実装における次元の設定方法 | 768d vs 1536d vs 3072d

Embedding次元数の基礎知識

次元数とは

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

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

python

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

主要なEmbeddingモデルと次元数

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

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

1. ストレージコスト

次元数はベクトルDBのストレージサイズに直接影響します。

1万チャンクを格納した場合の容量（pgvectorの場合）：

python

# 計算式: チャンク数 × 次元数 × 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パラメータで次元数を指定できます。

基本的な実装

python

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
)

バッチ処理での実装

python

# 複数チャンクを効率的に処理
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 tokens）ですが、ストレージコストと検索速度が変わります。

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

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

Ollamaのリソースコスト

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

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

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

GPU時間単価を考慮すると、初期Embedding生成で次元数が大きな影響を与えます。

ベクトルDB別の実装例

pgvectorでの実装

python

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での実装

python

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での実装

python

import pinecone

pinecone.init(api_key="YOUR_API_KEY")

# インデックス作成（次元数を指定）
pinecone.create_index(
    name="rag-768d",
    dimension=768,  # 必須パラメータ
    metric="cosine"
)

index = pinecone.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

実装時の注意：

python

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

# Ollama使用時
ollama.embeddings(
    model='nomic-embed-text',  # 768次元モデル
    prompt=text
)

1536次元を選ぶべきケース

推奨シナリオ：

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

具体例：

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

デフォルト推奨： OpenAIのtext-embedding-3-smallはデフォルトで1536次元であり、多くのユースケースで最適なバランスです。

3072次元を選ぶべきケース

推奨シナリオ：

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

具体例：

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

実装時の注意：

python

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

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

ハイブリッドアプローチ

用途に応じて次元数を使い分ける戦略も有効です：

python

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次元に戻す、またはハイブリッド化

python

# 移行スクリプト例
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
        )

まとめ

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

• デフォルト選択: 1536次元（OpenAI text-embedding-3-small）
• 大規模・高速重視: 768次元
• 最高精度重視: 3072次元（OpenAI text-embedding-3-large）

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

次元数は一度決めると変更が困難なため、将来のスケールを見据えた設計が重要です。不確実性が高い場合は、768次元または1536次元から始め、段階的に最適化する柔軟なアプローチを推奨します。