pgvectorの次元数不一致を、生成設定・DB列・検索ベクトルから確認する

pgvectorの次元数不一致を登録時と距離計算時に分け、生成モデル・実配列長・列型・検索関数を照合します。

確認日 2026年10月20日AIものさし編集部

pgvectorでexpected ... dimensionsやdifferent vector dimensionsが出たときは、埋め込みを作る処理、DBの列・キャスト、検索用ベクトルを一組で確認します。モデル名を変えた直後でも、原因をモデルの性能やDBの故障と決めず、どの境界で要素数が食い違ったかを特定してください。

この記事はpgvectorの公式READMEとv0.8.7の実装を基にした診断手順です。PostgreSQLや埋め込みAPIで実行した結果ではありません。SQL中の表・列名、モデルA／B、数値は説明用で、実環境の設定値を示すものではありません。

二種類の不一致を分ける

pgvectorの公式ソース（新しいタブで開く）には、型が期待する次元数との不一致と、二つのベクトル間の次元数不一致を調べる処理があります。エラーに出た二つの数を、何と何の比較だったかへ戻すことが出発点です。

表は横にスクロールできます

失敗した段階	比較するもの	最初に残す情報
登録・型変換	入力の要素数と列・キャストの指定	INSERT等の対象、列型、実際の配列長
距離計算	保存済みベクトルと検索用ベクトル	対象行、検索要求の生成設定、両方の長さ
特定の検索経路だけ失敗	関数内のキャストや検索対象	呼び出した関数、絞り込み、型指定

エラーの出たSQLがアプリ側で組み立てられるなら、秘密情報や原文を除き、対象のスキーマ・表・関数名とパラメーターの形を残します。管理画面で見た別環境の列定義と比較しないよう、接続先も固定してください。

要素数と生成条件を一枚にまとめる

まず、保存側と検索側で以下を対応付けます。モデル名だけでなく、出力次元数の指定や前処理の変更を記録するのがポイントです。提供元によって指定できる項目は異なるので、使用中のAPIの公式仕様へ戻します。

表は横にスクロールできます

項目	保存データ側	検索要求側
生成元	提供元、モデル識別子、設定版	同じ項目を記録
実際の長さ	登録前の配列長、保存後の次元数	距離計算へ渡す直前の配列長
データの版	文書ID、本文版、分割方法	問い合わせの前処理版
DB上の境界	列型、検索関数、index式	パラメーターの型・キャスト

同じ次元数でも、別のモデルで作ったベクトルがそのまま比較可能だとは判断しません。これはエラーの有無だけでは検出できないため、生成条件を別の識別情報として保持する設計が必要です。次元数の一致は、検索結果が正しいことの証明にはなりません。

保存値と列型を別々に確認する

公式README（新しいタブで開く）では、vector(n)の代わりにvectorを使うと異なる次元数を同じ列へ保存できる一方、indexには同じ次元数の行を対象にする条件が示されています。列型を緩めるだけで検索全体の不一致が解消する、と考えないでください。

次は、次元数を読むための説明用SQLです。最初の式の値は要素数から3と読めますが、ここではDBで実行していません。

SELECT vector_dims('[1,2,3]'::vector);

SELECT document_id, model_version, vector_dims(embedding) AS dims
FROM app.document_embeddings
ORDER BY document_id
LIMIT 10;

後半の表・列は仮の名前です。実環境では権限のある対象を使い、原文やベクトル全体をログへ出す必要があるかも検討します。10件の確認は標本にすぎず、全行がそろっている証拠にはなりません。全体集計が必要なら、対象件数や負荷を把握して別途実施します。

保存値の次元数が合っていても、検索関数内で古いvector(n)へ変換している場合は、呼び出し経路の確認が残ります。アプリの設定、DB列、関数定義、index式のうち、一か所を変えて他が古いままになっていないかを追ってください。

具体例で不一致の場所を読む

次は架空の構成です。実製品の標準次元数ではありません。

表は横にスクロールできます

場所	仮の設定・観察値	判断
既存文書	モデルA、3要素	Aの検索対象として管理
新しい問い合わせ	モデルB、4要素	3要素の保存値へ直接比較しない
DB列	`vector(3)`	4要素の新規登録にも型との不一致がある

この場合、検索側だけを3要素へ切り詰めたり、4要素へゼロを足したりして、意味が保たれたことにはできません。次元短縮を正式に扱うモデルや手法もありますが、その契約を確認せず独自加工で合わせないようにします。

最初の対応は、どのモデル・設定を使う検索経路なのかを決めることです。既存データへ合わせるのか、新しいモデルへ移すのかを分け、本文からの再生成が必要な範囲を見積もります。エラーが消える最小変更と、検索品質を保つ変更が同じとは限りません。

モデル変更は旧データを残して検証する

モデルを移すなら、旧ベクトルをその場で上書きする前に、文書ID、本文版、生成設定、処理済み件数を対応付けます。別列や別の保存領域など、旧経路を確認できる移行方法を設計し、検索側の切替と戻し方もまとめます。

検証用には、答えと根拠文書が分かっている少数の問いを用意します。同じ問いで、検索対象のモデル版が混ざらないか、正しい文書が見つかるか、参照先が現行本文かを確認します。距離の数値だけを別モデル間で横並びにして、品質向上と断定しないでください。

indexの再作成や列型の変更は、対象件数、稼働中の読み書き、失敗時の復旧に影響します。本番の列変更や全件再生成を診断の第一手にはせず、確認済みの不一致に対応する移行として扱います。

再開の判断を残す

完了記録には「SQLが通った」だけでなく、保存側と検索側の生成設定、次元数、対象件数、旧経路の扱い、評価に使った問いを残します。原文が更新された文書を旧ベクトルのまま使っていないかも確認対象です。

AIに手伝わせるなら、匿名化したエラー、列・関数の定義、配列長、生成設定の対応表を渡し、不一致箇所を説明させます。実ベクトル全体や社内文書を渡す前に、長さと設定だけで切り分けられないかを考えてください。埋め込みAPIへの追加要求を繰り返しても、DB側に残る古い型指定は直りません。

確認した公式情報

確認日：2026-10-20。利用環境の拡張機能版、生成API、検索性能は未実測です。

質問から自分に合うAIを探す