埋め込みサイズ: 768、1536、または 3072 次元?

明らかに、text-embedding-3-small と text-embedding-3-large のどちらを選択するかということは、切り捨てについて話す前に、まず 1536 ～ 3072 のネイティブ サイズを選択することになります。以下の表は、pgvector がインデックス作成側でネイティブに認識する 3 つのレベルと、Aurabase ルートに関する検証可能な事実をまとめたものです。

出典: OpenAI、公式ブログ「新しい埋め込みモデルと API アップデート」、2024 年 1 月 25 日 (MTEB スコアと開始価格、使用前に現在の価格ページを確認してください)。 aura-ai/src/embeddings/mod.rs、Aurabase (列とインデックスのサポート、2026 年 8 月 24 日に検証済み)。

埋め込みは浮動小数点数の配列のように格納されます。 pgvector では、古典的な vector 型は各次元を 4 バイト (float32) でエンコードします。したがって、pgvector ヘッダーと Postgres ページのオーバーヘッドをカウントする前でも、768 次元はベクトルあたり約 3 KB の生データ、1536 次元は約 6 KB、3072 次元は約 12 KB になります。

ここで、pgvector の halfvec タイプが登場します。これは、各次元を 4 バイトではなく 2 バイト (float16) でエンコードします。 halfvec に格納される 3072 次元のベクトルの重さは約 6 KB です。これは、従来の vectorに格納される 1536 次元のベクトルの重さとまったく同じです。

直接的かつ直感的ではない結果: embedding_3072 カラムは halfvecキャストを介してクエリされるため、Aurabase では 1536 次元から 3072 次元に移行してもディスク上の実際のストレージは 2 倍になりません。したがって、3072 次元の実際の追加コストは主にディスクではなく、関連する OpenAI モデルの価格と、次のセクションで詳しく説明する vectorタイプのネイティブ インデックス サポートの出力です。

pgvector の vector タイプでは、2000 次元を超える HNSW または IVFFlat インデックスを構築できません。したがって、3072 次元はこの制限を超えます。vector(3072) 列のベクトル検索クエリは近似インデックスに依存できず、完全な順次スキャンに頼るため、本番環境の RAG コーパスの規模では使用できません。

Aurabase コードはこのケースを明示的に処理します。embedding_3072 カラムは、各挿入および検索クエリで halfvec(3072) にキャストされます。pgvector が最大 4000 次元のインデックスを作成できるタイプです。列 768 と 1536 は制限に近づいていないため、キャストされていないネイティブ vectorのままです。

// 3072 (>2000) の場合、HNSW はタイプ `vector` のインデックスを作成せず、halfvec をキャストします
fn vec_query_parts(dims: usize) -> AuraResult<(&'static str, &'static str, &'static str)> {
    match dims {
        768  => Ok(("embedding_768",  "", "::vector")),
        1536 => Ok(("embedding_1536", "", "::vector")),
        3072 => Ok(("embedding_3072", "::halfvec(3072)", "::halfvec(3072)")),
        other => Err(...), // サポートされていない次元
    }
}

この詳細は、[768, 1536, 3072] にリストされていない埋め込みディメンションが、受け入れられて不適切にインデックス付けされるのではなく、Aurabase 側で明示的に失敗する理由も説明しています。列名は常に固定のホワイトリストから取得され、クライアントから送信された自由な値から取得されることはありません。この特定のケースを超えて、Postgres での HNSW インデックスの構築についてさらに詳しく知りたい場合は、記事 HNSW インデックスと Postgres ベクトル検索を参照してください。

2024 年 1 月の時点で、OpenAI の Embedding API は、別のモデルを再度呼び出すことなく、返されるベクトルを短縮する dimensions パラメーターを受け入れます。この手法はマトリョーシカ表現学習と呼ばれます。モデルはベクトルの最初の次元に有用な情報を集中させるようにトレーニングされるため、切り捨ての精度は突然ではなく徐々に失われます。

OpenAI は、発表の中で具体的な例を示してこの手法の有効性を説明しています。text-embedding-3-large は、わずか 256 次元に切り詰められていますが、フル サイズの 1536 次元で使用されている古い text-embedding-ada-002 の MTEB スコアを依然として上回っています (出典: OpenAI、公式ブログ、2024 年 1 月 25 日)。この特定のベンチマークでは、12 倍小さいベクトルで、完全なベクトルよりも優れたパフォーマンスが得られます。

let body = json!({
    "model": self.embed_model,       // 例: "text-embedding-3-large"
    "input": text,
    "dimensions": self.embed_dimensions, // 3072 → 設定値を切り捨てる
});

重要な点であり、よく誤解されますが、切り捨てによって請求される価格は減額されません。 OpenAI は、実際のコストは入力テキストに対して実行される計算であるため、返されたベクトルのサイズではなく、クエリされたモデルに基づいて料金を請求します。したがって、text-embedding-3-large から 1536 ディメンションをリクエストすると、その 3072 ネイティブ ディメンションと同じ料金がかかります (出典: OpenAI、公式ブログ、2024 年 1 月 25 日)。ストレージと検索速度のみが変わります。

これはまさに Aurabase のデフォルトの選択であり、 config/mod.rsで検証されています。デフォルトで設定されているモデルは text-embedding-3-largeですが、デフォルトで設定されている出力ディメンションは 3072 ではなく 1536です。 したがって、このサービスは、3072 に必要な halfvec キャストを行わずに、ネイティブ HNSW のインデックス可能な vector 列に残るように切り詰められたワイド モデルの表現に対して支払いを行います。

1536 次元は、大部分の RAG またはセマンティック検索プロジェクトにとって依然として妥当な開始点です。text-embedding-3-small の MTEB スコア (62.3%) は依然として大規模モデルのスコアに近く、ストレージは依然として軽量であり、HNSW では特定の構成を必要とせずに古典的な vector タイプの pgvector インデックスが使用されます。

コーパスがあいまいまたは技術的である場合、3072 ディメンションは正当化されます。この場合、62.3% と 64.6% の間の品質ギャップが、一般的な OpenAI ベンチマークではなく、独自のクエリで目に見えてより優れた検索結果に変換されます。 OpenAI 開発者コミュニティのディスカッションに記録されたチームのフィードバックのいくつかは、この方向性を示しています。3072 次元のゲインはケースバイケースで測定されるものであり、想定することはできません。

768 次元は、ストレージや計算の予算が実際の制約となる大規模なコーパス、またはすでに 768 ネイティブ次元にあるレガシー埋め込みモデルの使用など、ニュアンスよりもボリュームが優先される場合に特に適しています。

このディメンションの選択は、より大きな RAG スタック、埋め込み、HNSW インデックス、ハイブリッド検索の一部であり、ネイティブ AIページで説明しています。

768、1536、および 3072 次元は単一の軸上で分割されていません。 3072 は、OpenAI によって公開された MTEB スコアで向上しましたが、pgvector のネイティブ HNSW サポートを残し、最終的に要求されたディメンションが何であれ、大規模モデルの価格を支払うことになります。 Aurabase を含め、1536 が依然として最も一般的なデフォルト残高です。 768 は、ニュアンスよりもボリュームが優先される場合に役立ちます。

OpenAI's dimensions parameter changes the question to ask: it is no longer "which model to choose", but "which truncation to accept, for what gain measured on my corpus". Before finalizing a choice in production, test the search quality on a real sample, not just on a general benchmark. Our guide RAG pipeline with pgvector details the complete setup, from ingestion to hybrid search.