はじめに

Azure HorizonDB は、PostgreSQL 基盤に AI アプリケーション向け機能を統合した Azure のデータベースサービスです。Microsoft Build 2026 では、RAG、AI エージェント、インテリジェント検索に必要な埋め込み生成、ベクトル検索、全文検索、ハイブリッド検索、セマンティックリランキング、AI functions、データ準備、永続的な AI パイプラインを、SQL と PostgreSQL 拡張の文脈で扱えることが紹介されました。

Cosmos DB が JSON ドキュメントとグローバル分散 NoSQL を軸に AI 検索を組み込むのに対し、HorizonDB は PostgreSQL の SQL、トランザクション、拡張機能、リレーショナルデータを軸に、AI 検索とモデル呼び出しをデータベース内に寄せる設計となっています。

AI 機能の全体像

主な機能

機能	内容	使いどころ
AI functions in SQL	`azure_ai.generate()`、`azure_ai.extract()`、`azure_ai.is_true()`、`azure_ai.rank()`、`azure_openai.create_embeddings()` を SQL から呼び出します。	アプリケーションコードを増やさず、データベース内で生成、抽出、評価、埋め込み、リランキングを行いたい場合。
AI Model Management	既定のチャット、埋め込み、リランキングモデルを自動プロビジョニングし、モデル登録と接続を管理します。	エンドポイントやキーの管理を最小化して AI functions を試したい場合。
pgvector	PostgreSQL にベクトル型、距離演算子、類似検索を追加します。	意味検索や RAG の一次検索。
DiskANN	`pg_diskann` 拡張による Microsoft のスケーラブルな近似最近傍検索です。	大規模なベクトル検索、本番 RAG、メタデータフィルター付き検索。
全文検索 / ハイブリッド検索	BM25 系のキーワード検索とベクトル検索を組み合わせます。	固有名詞、型番、専門用語と意味検索の両方が必要な検索。
セマンティックリランキング	`azure_ai.rank()` で検索候補をクエリとの関連度に基づき並べ替えます。	上位候補の品質をさらに上げたい RAG。
LangChain 連携	`langchain-azure-postgresql` の `AzurePGVectorStore` から HorizonDB をベクトルストアとして利用します。	Python の RAG アプリやエージェントフレームワークから使いたい場合。
durable AI pipelines	チャンク化、埋め込み、抽出、生成、リランキングなどの AI ワークフローを SQL で宣言し、データベース内の耐障害パイプラインとして実行します。	大量データの継続的なベクトル化、再埋め込み、更新差分処理をアプリケーション外部サービスに切り出したくない場合。

うーん、”ナニカ”を意識しているような気がする…🤔

ベクトル検索と DiskANN

HorizonDB では、vector 拡張でベクトル型を使い、<->、<#>、<=> などの演算子で距離を計算します。たとえば <=> は cosine distance に使われます。

大規模検索では pg_diskann 拡張の DiskANN が推奨されます。DiskANN は高リコール、高 QPS、低遅延を狙える Microsoft の近似最近傍検索アルゴリズムであり、HorizonDB の本番 AI ワークロード向けの推奨既定インデックスです。インプレースの挿入と更新、数百万からさらに大規模なベクトル、最大 16,000 次元、ベクトル検索とメタデータフィルターを組み合わせる高度なフィルターに対応します。

CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS pg_diskann CASCADE;

CREATE INDEX notes_embedding_diskann_idx
    ON notes USING diskann (embedding vector_cosine_ops);

要点

pgvector の HNSW と IVFFlat は vector 型で 2,000 次元までしかインデックスできません。これは pgvector 側の制約です。
HorizonDB の DiskANN は spherical_quantized = true を有効化した場合に限り、最大 16,000 次元までインデックスできます。上限は sq_bits に依存し、sq_bits = 1 で 16,000 次元、sq_bits = 4 で 4,000 次元です。
sq_bits と最大次元数の対応からは、「量子化コードが 1 ベクトルあたり 2,000 バイト（＝16,000 ビット）以内」という関係を導けます（16,000 ÷ sq_bits = 最大次元数）。
Microsoft が公開している DiskANN コアライブラリでは、球面量子化は RaBitQ ベースの量子化 と説明されています。「中心化 → 単位球面へ正規化 → 距離保存変換 → 次元ごとに sq_bits ビットへ量子化」という手順で、補正項を距離推定に利用します。ただし、HorizonDB の pg_diskann が同じ内部実装をそのまま使用しているかは未確認。

なぜ「2,000 次元の壁」が存在するのか

壁があるのは「インデックス」側

pgvector の vector 型自体は 16,000 次元まで保存できます。1 ベクトルあたりの保存サイズは 4 × 次元数 + 8 バイトです。

型	保存の上限	HNSW のインデックス上限	IVFFlat のインデックス上限	1 要素あたり
`vector`	16,000 次元	2,000 次元	2,000 次元	4 バイト（単精度）
`halfvec`	16,000 次元	4,000 次元	4,000 次元	2 バイト（半精度）
`bit`	—	64,000 次元	64,000 次元	1 ビット
`sparsevec`	非ゼロ 16,000 個	非ゼロ 1,000 個	インデックス非対応	非ゼロ要素あたり 8 バイト

（出典: pgvector 公式 README。HorizonDB に搭載されるバージョンでは差異がないか要確認）

インデックス上限に見える「約 8,000 バイト」という共通点

上の表を「1 ベクトルあたりのバイト数」に直すと、いずれも約 8,000 バイトになります。

$$
\text{vector}: 2{,}000 \times 4 = 8{,}000 \ \text{B} \quad
\text{halfvec}: 4{,}000 \times 2 = 8{,}000 \ \text{B} \quad
ext{bit}: 64{,}000 \div 8 = 8{,}000 \ \text{B} \quad
ext{sparsevec (HNSW)}: 1{,}000 \times 8 = 8{,}000 \ \text{B}
$$

この数値は、PostgreSQL の既定ページサイズである 8,192 バイトと整合します。ただし、pgvector の README は次元上限そのものは明記しているものの、「すべての上限が 1 ページの物理制約だけで決まる」とは説明していない点には注意。

HNSW が高次元で不利になる理由

HNSW はインデックスがメモリに収まると高い再現率と低遅延を得やすい一方、収まらなくてもインデックス自体が利用不能になるわけではありません。高次元になるほど 1 ベクトルのバイト数が線形に増え、必要なメモリと I/O が増えます。HorizonDB のインデックス選択ガイドでは、1 億件以上かつ 3,072 次元以上の例に DiskANN を推奨しています。なお、vector 型の HNSW はデータ件数にかかわらず 2,000 次元がインデックス上限です。

DiskANN が壁を越えられる理由

DiskANN の基本設計

DiskANN は Microsoft のスケーラブルな近似最近傍探索アルゴリズムです。

グラフ構造のインデックスで、SSD 上にデータの大半を置いたまま高速に動作するよう設計されている
数十億点規模でも高い再現率、高い QPS、低遅延を実現する
挿入と更新をその場で適用でき、周期的な全再構築を必要としない
最大 16,000 次元に対応する
HorizonDB では、メタデータ述語をインデックス探索そのものに押し込む「高度なフィルタリング」に対応する唯一のインデックスである

インデックスの種類ごとの比較

項目	Flat（インデックスなし）	IVFFlat	HNSW	DiskANN
アルゴリズム	全件走査	転置ファイル（分割）	階層グラフ	SSD 最適化グラフ
再現率	100%	低〜中	高	高
1,000 万件超での遅延	大	中	小（メモリに載る場合）	小
構築時間	不要	速い	遅い	中程度
メモリ使用量	なし（逐次 I/O）	小	大（高性能を得るにはインデックスをメモリに収める）	小（大半は SSD）
更新・挿入	なし	再現率が劣化、定期再構築が必要	その場で反映	その場で反映
最大次元数	16,000（型の上限）	2,000	2,000	16,000
フィルター付きクエリ	常に正確	後段フィルター、再現率が低下	後段フィルター、再現率が低下	高度なフィルタリング（インデックス内で述語を評価）

Spherical Quantization（球面量子化）

HorizonDB の球面量子化は何をしているのか

球面量子化は、文書ベクトルを少数ビットへ圧縮し、DiskANN が候補を軽く比較できるようにする技術です。

文書は、埋め込みモデルで Embedding へ変換された後、インデックス構築時に次の順で圧縮されます。

$$
X' \xrightarrow{\text{中心化}} X=X'-C
\xrightarrow{\text{正規化}} x=\frac{X}{|X|}
\xrightarrow{\text{回転}} y=T(x)
\xrightarrow{\text{量子化}} q
$$

中心化・正規化: ベクトルを中心から見た方向へ分け、単位球面上へそろえる
距離保存変換: 幾何関係を保ったまま成分を分散し、符号の偏りを抑える
1ビット量子化: sq_bits = 1 なら各成分の正負だけを $q_i=\pm1/\sqrt{D}$ として保存する

公開 DiskANN 実装と同じ形式だと仮定した場合、5,376 次元では、文書ベクトル 1 本の量子化コードと補正情報が次の大きさになります。

$$
21{,}504\ \text{B（float32）}
\longrightarrow
672\ \text{B（1ビットコード）}+6\ \text{B（補正情報）}
=678\ \text{B}
$$

一般には、量子化コードと補正情報の大きさは概ね $\left\lceil D\times\texttt{sq_bits}/8\right\rceil+6$ バイトです。これは DiskANN インデックス全体のサイズではなく、グラフ構造、ページ管理情報、アラインメント、テーブル側に保存される元のベクトルなどは含みません。

保存する補正情報	サイズ	距離計算での役割
`inner_product_correction`	2 B	ノルムと量子化による内積の縮みを補正する
`metric_specific`	2 B	L2 のノルム二乗、または内積・コサインの重心項を戻す
`bit_sum`	2 B	0/1コードの整数内積を符号付き内積へ補正する

量子化前後の一致度を $\rho_x=\langle q,y\rangle$ とすると、比較相手の単位ベクトル $u$ との内積は $\langle x,u\rangle\approx\langle q,T(u)\rangle/\rho_x$ と推定できます。6バイトの補正情報は、この縮み、ノルム、重心項、0/1コードのオフセットを距離式へ戻すために使われます。

全計算ステップの一覧

検索時に⑤の近似方向を復元するわけではなく、⑤はあくまで量子化誤差を目で理解するための表示です。公開 DiskANN 実装では、検索クエリを別に Embedding 化して同じ重心・変換で前処理し、クエリ表現と文書側の量子化コードおよび補正情報から距離を直接推定します。クエリ側には 4 ビットまたはフル精度を使う経路があり、文書側を 1 ビットに保ったまま検索精度を補います。

球面量子化は「候補1本を小さくする」技術、DiskANNは「比較する候補数を減らす」技術です。両方を組み合わせることで、高次元ベクトルを現実的なメモリ量とI/Oで検索できます。

microsoft/harrier-oss-v1-27b モデルの利用

harrier-oss-v1 シリーズは、Microsoft が開発した多言語テキスト埋め込みモデル群です。このモデルは、デコーダーのみのアーキテクチャを採用し、ラストトークンプーリングと L2 正規化によって高密度なテキスト埋め込みを生成します。検索、クラスタリング、意味的類似性、分類、バイテキストマイニング、再ランキングなど、幅広いタスクに適用可能です。リリース時点で、このモデルは多言語MTEB v2ベンチマークにおいて最先端の性能を達成しています。

Model	Parameters	Embedding Dimension	Max Tokens	MTEB v2 Score
harrier-oss-v1-270m	270M	640	32,768	66.5
harrier-oss-v1-0.6b	0.6B	1,024	32,768	69.0
harrier-oss-v1-27b	27B	5,376	32,768	74.3

27B の埋め込み次元はなんと、5,376 次元！最大トークン数は 32,768 もあります！さらに、MTEB(Multilingual, v2) ベンチマークでは公開から現在までずっと堂々の 1 位に輝いています。

なお、harrier はクエリ側にタスクを表す指示文を付ける前提で学習されています。モデルカードでも、指示文を付けないと性能が低下すると明記されています。本検証ではクエリを Instruct: Given a web search query, retrieve relevant passages that answer the query\nQuery: <検索文> の形式にし、ON/OFF でどう変化するのかを比較します。文書側には指示文を付けていません。

HorizonDB DiskANN + SQ の最小手順

事前に HorizonDB のパラメーターグループ設定で、azure.extensions に、 pg_diskann, vector を登録したグループを作成し、リソースに割り当てています。他にも AI 機能を使う場合、azure_ai, pg_durable を登録。

MEMO
pg_diskann: v0.7.3 以降じゃないと 16,000次元対応インデックスを作成できない

-- 1. 拡張を有効化
CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS pg_diskann CASCADE;

-- 2. ベクトル列を持つテーブルを作成
CREATE TABLE harrier_docs (
    docid text PRIMARY KEY,
    body text NOT NULL,
    embedding vector(5376) NOT NULL
);

-- 3. 生成済みの5,376次元ベクトルを登録
INSERT INTO harrier_docs (docid, body, embedding)
VALUES ($1, $2, $3::vector);

-- 4. Spherical Quantizationを有効にしたDiskANNインデックスを作成
CREATE INDEX harrier_docs_embedding_diskann_idx
ON harrier_docs USING diskann (embedding vector_cosine_ops)
WITH (
    spherical_quantized = true,
    sq_bits = 1,
    sq_training_samples = 25000
);

-- 5. 探索量と結果順を設定し、コサイン距離で近傍検索
SET diskann.l_value_is = 100;
-- SET diskann.iterative_search = 'strict_order';

SELECT
    docid,
    body,
    1 - (embedding <=> $1::vector) AS cosine_similarity
FROM harrier_docs
ORDER BY embedding <=> $1::vector
LIMIT 5;

日本語精度評価とモデル比較

私がいつも使っている MIRACL 日本語データセットから文書を用意し、前処理後に HorizonDB へ登録した 8,066 行を対象として、それぞれのモデルごとに精度評価を行いました。OpenAI Embeddings モデルおよび harrier モデルは HorizonDB DiskANN で実施しています。

ちなみに、Azure AI Search のサービス上限ではベクトルフィールドの最大次元数は 4,096 のため、5,376 次元をそのまま格納することはできません…😥

条件

HorizonDB: 2 個の仮想コア、16 GiB RAM
pg_diskann: v0.7.3
vector: v0.8.0
model: microsoft/harrier-oss-v1-0.6b, microsoft/harrier-oss-v1-27b
gpu: NVIDIA GeForce RTX 5090 VRAM 32GB
top_k: 上位 3 件または 5 件を取得
DiskANN: diskann.l_value_is = 100。評価コードでは diskann.iterative_search を明示していないため、既定の relaxed_order を使用

harrier-oss-v1-27b については、元の BF16 モデルは重みだけで約 54 GB になるため、本検証では bitsandbytes の 4-bit NF4 量子化を適用しました。二重量子化と BF16 演算を組み合わせ、今回の入力長とバッチサイズでは 32 GB の GPU メモリで動作可能なサイズまで削減しています。実際の GPU メモリ使用量は、入力長、バッチサイズ、実装、推論時の一時領域によって変わります。

ここでの 4-bit NF4 は埋め込みモデルの重み量子化です。前述の spherical_quantized はDiskANN インデックス内のベクトル表現の量子化であり、対象も目的も異なります。

検証結果

harrier-oss-v1-27b、すごい… 4-bit 量子化しているとはいえ、純粋なベクトル検索だけでこれほど高い Recall が得られるとは驚きです。フルサイズではどんな精度になってしまうんだ… harrier-oss-v1-0.6b についても text-embedding-3-large に匹敵する精度が出ている点にも注目です。ちなみに、クエリの Instruct を省略すると Recall は低下しました。

現実的に 27B モデルのホスティング費用を考えると、検索品質の向上が追加コストに見合うかは慎重に判断する必要があります。実運用では軽量な 0.6B モデルを基準とし、品質要件が特に高いユースケースで 27B モデルを採用するのが現実的かもしれません…　が現状自力で推論環境の構築が必要です。ちなみに、2026 年 8 月 11 日時点で Microsoft Foundry のモデルカタログを harrier で検索すると、対応しているのは microsoft-harrier-oss-v1-0.6b のみです。

※今回はベクトル検索のみを使うシナリオでの話です。実際はハイブリッド検索やセマンティックリランキングで結果を補ってさらに精度を向上させることができます。

また、HorizonDB における DiskANN のレイテンシーについてはちょっと変数が多いので、また別途検証してみることにします。

参考