ベクトル値

ベクトルは、構造化および非構造化入力データの数学的表現であり、最新の人工知能（AI）アプリケーションやセマンティック検索機能に不可欠である。 Db2 ベクターデータをインポートし、SQLステートメントで照会できる形式に変換できるようになりました。

注： VECTORデータ型のサポートは Db2®12.1.2 以降で利用可能です。

なぜベクターデータが重要なのか？

機械学習モデルやディープラーニング技術を採用した多くのAIアプリケーションは、高次元ベクトル埋め込みという形でベクトルを生成する。高次元のベクトルは、異なるオブジェクトの量を記述する。これらのアプリケーションは、参照ベクトルとして使用するために、データセット内で類似性のあるベクトルを特定するために類似性検索技術を使用します。類似度は通常、ユークリッド距離や余弦類似度など、2つのベクトル間の距離関数として測定される。

多くの企業がAIや GenAI テクノロジーを採用し、費用対効果が高く、安全で、簡素化されたベクターストレージのソリューションを求めている。これらのニーズを満たすためには、アプリケーションは高次元のベクトル埋め込み集合に対する効率的な類似性検索機能を持たなければならない。通常、これらの用途に必要な寸法数は数百から数千に及ぶ。ベクターは各オブジェクトの小さな部分を表現するために使用されるため、これらのアプリケーションのデータベースに保存されるベクターの数は、通常非常に多い。このようなアプリケーションは、1つのユーザープロンプトに対して多数の類似検索クエリを実行して答えを出す必要がある。この種のクエリに期待される応答時間は、コンマ数秒からミリ秒の範囲である。ベクトル埋め込みは通常、類似検索クエリに含めることができるメタデータを保持している。

ベクターデータの保存と操作に Db2 を選ぶ理由は？

市場には、ベクトル保存と効率的な類似性検索に特化したデータベースがある。しかし、これらの解決策には限界がある：

それらは外部のデータ・リポジトリに依存している。ベクトルを元の入力と組み合わせる場合、ユーザーは複数のデータリポジトリを扱う必要があり、コスト、待ち時間、複雑さが増す。
ベクトル埋め込みに関連するメタデータを使って、他のフィルタリング機能でクエリを強化する機能はほとんどない。
他のデータ管理分野での能力は限られている。

多くの Db2 の顧客は、すでに Db2 データベースにベクター作成の元となる入力を持っているため、ベクター保管ソリューションは大幅に簡素化されている。

Db2 のクエリ機能は他の追随を許さず、ベクトル類似性検索を追加することで、これらの機能が強化される。

Db2 は長年にわたり、スケーラビリティ、セキュリティ、監査性、パフォーマンス、モニタリングなどの分野で業界をリードする機能を開発してきました。ベクターに特化したソリューションのほとんどは、それを提供できない。

Db2、ベクターデータを管理するための実用的なアプリケーションの例については、使用例を参照してください。

VECTOR データ型

VECTOR データ型は現在、座標型 INT8 と REAL/FLOAT32 をサポートしています。 VECTOR データ型は固定長型で、座標の数は常に次元と等しくなります。固定型のCHARやBINARYとは異なり、パディングはなく、すべての座標をコンストラクタ関数に提供しなければならない。ベクトルは、同じ次元と座標型を持つ別のベクトルとしか互換性がない。

構文

VECTOR (<dimension> ,<coordinate-type>)

説明

dimension はベクトルの次元を指定する整数リテラルである。行編成テーブルの場合、 FLOAT32 では 1 から 8168 まで、 INT8 では 1 から 32672 までの値でなければなりません（SQLSTATE 42611）。列で構成されたテーブルの場合、 FLOAT32 では 1 から 8148 までの値、 INT8 では 1 から 32592 までの値でなければなりません（SQLSTATE 42611）。
coordinate-type はREALまたは単精度4バイト浮動小数点値、または 1バイト整数。 FLOAT32 INT8

例

次の例は、異なるベクトル・データ型の2つの列を含むテーブルVTABLEを作成するためのコマンド構文です：

CREATE TABLE VTABLE (RV VECTOR(100, REAL), -- Coordinates are single-precision (4-byte) floating point
                     IV VECTOR(300, INT8)) -- Coordinates are 1-byte integers

このコマンドは以下の表を生成する：

$ db2 describe table VTABLE

                                Data type                     Column
Column name                     schema    Data type name      Length     Scale Nulls
------------------------------- --------- ------------------- ---------- ----- ------
RV                              SYSIBM    VECTOR(FLOAT32)            100     0 Yes
IV                              SYSIBM    VECTOR(INT8)               300     0 Yes

  1 record(s) selected.

ベクトル関数とその使い方

ベクトル固有のスカラー関数がいくつか用意されており、それを使ってベクトルを作成し、管理することができます。 Db2:

VECTOR : 入力文字列からベクトルを構築する。
VECTOR_SERIALIZE : ベクトルを文字列に変換する。
VECTOR_DISTANCE : 指定されたメトリックを使って2つのベクトル間の距離を計算します。
VECTOR_NORM ：あるベクトルとゼロベクトルの間の距離を指定されたメトリックを用いて計算します。
vector_dimension_count ：ベクトル型定義の次元を返す。

ベクトルを使ったUPDATEとINSERT操作

VECTOR列には、バイナリ形式のベクトルが格納される。 Db2 は、アプリケーションとやりとりするときにベクターの文字列形式を使用する。

例えば、新しいVECTOR関数はベクトルの文字列表現をバイナリ形式に変換する。次の例は、ホスト変数とベクターの文字列形式を使用して既存のベクター値を更新するコマンド構文を示しています：

C++
EXEC SQL BEGIN DECLARE SECTION;
  // Generated by db2dclgn
  sqlint32 id;

  struct
  {
    short length;
    char  data[50];
  } f32_3;
EXEC SQL END DECLARE SECTION;

id = 1;
sprintf(f32_3, "[0.123, -0.456, 0.789]");

EXEC SQL UPDATE VECTOR_TB SET F32_3 = VECTOR(:f32_3, 3, FLOAT32) WHERE ID = :id;

ベクトルを使った EXPORT、IMPORT、LOAD 操作

EXPORT Db2 EXPORT、 IMPORT、 LOAD コマンドは VECTOR データ型をサポートしています：

EXPORT および IMPORT コマンドは、以下の VECTOR データ型をサポートしています。 Db212.1.2 以降でサポートされています。 LOAD コマンドは、 Db2 12.1.3 以降の VECTOR データ型をサポートしています。
EXPORTコマンドは、ベクトル値を文字列として書き出します。 IMPORT コマンドと LOAD コマンドでは、入力ベクトルデータ値が文字列形式であることが想定されています。
EXPORTコマンドは、不要な空白を除いたベクトル値の文字列形式を出力する。
小サイズの INT8 VECTORタイプは6534次元までのもので、小サイズの FLOAT32/REAL VECTORタイプは2041次元までのものである。これらの VECTOR 型では、EXPORT 操作によって生成されるベクタ値の文字列形式は 32672 バイトを超えない。
EXPORT、IMPORT、LOAD コマンドは、これらの小さなVECTOR型をVARCHAR型の扱い方と同様に扱う。
大きなVECTOR型が、 INT8 ベクトルの場合は6534次元を超え、 FLOAT32/REAL ベクトルの場合は2041次元を超える場合、これらのベクターの文字列形式は、EXPORT操作によって生成されると、長さが32672バイトを超える可能性がある。
EXPORT、IMPORT、および LOAD コマンドは、ラージ VECTOR 型を CLOB 型データの扱い方と同様の方法で扱い、 EXPORT、IMPORT、および LOAD コマンドが実際の CLOB 型を扱う方法と同様の使用シナリオと制限を持つ。

ベクトル・データに対する EXPORT コマンドの実行ルール

ラージ・オブジェクト（LOB）データを扱う場合、EXPORT文に含めることができるオプションがあります：

LOB の宛先
LOBFILE
MODIFIED BY LOBSINFILE
MODIFIED BY lobsinsepfiles

EXPORT ステートメントで LOB オプションが指定されている場合、大きな VECTOR 列からのベクトル文字列値は個別の LOB データファイルに書き込まれ、 LOB ロケーション指定子（LLS ）はベクトル文字列値を指すためにメイン出力データファイルに書き込まれます。 LOBオプションが指定されない場合、ベクトル文字列値はメイン出力データファイルに書き込まれ、長さを超える場合は最大32700バイトに切り捨てられる。値が切り捨てられた場合、特定のデータ行に対する警告は発せられない。

注： IMPORT コマンドは、切り捨てられたベクトル文字列を持つデータ行を VECTOR 列 ( SQL0420N ) に挿入しません。ベクター文字列の切り捨て問題を回避または緩和する他の方法がない限り、EXPORTコマンドにLOBオプションを指定する。

ベクトルデータに対するIMPORT およびLOAD コマンドの実行ルール

小さな VECTOR 列を持つテーブルに対して IMPORT 文または LOAD 文を実行する場合、ベクトル文字列値はメインの入力データ・ファイルに存在し、値は切り捨てられてはならず、サイズは 32672 バイトを超えてはなりません。
VECTORカラムが大きく、LOBオプションが指定されていない場合、ベクトル文字列値はメイン入力データファイルに存在しなければならない。 LOBオプションの例には、LOBS FROMとMODIFIED BY LOBSINFILEがある。この場合も、ベクター文字列の値は切り捨てられてはならず、32700バイトを超えてはならない。
VECTOR列が大きく、LOBオプションが指定されている場合、メインの入力データファイルには、別々のLOBデータファイル内のベクトル文字列値を指すLLSが含まれていなければならない。この場合、LOADコマンドは 1MB （1048576バイト）までのベクター文字列値をサポートする。 EXPORT コマンドは、 1MB を超えるベクトル文字列値を生成しません。 LOAD コマンドでは、リモート・クライアントから LOAD コマンドが送信された場合も、LOAD コマンドが CLIENT パラメータを使用した場合も、個別の LOB データ・ファイルにサーバーからアクセスできる必要があります。 Db2 LOAD コマンドがリモート・クライアントから送信される場合も、LOAD コマンドが CLIENT パラメータを使用する場合も、サーバーからアクセス可能でなければなりません。
リモートクライアントからLOADコマンドを実行する場合 Db2 クライアントと Db2 クライアントと Db2 サーバーのバージョンが 12.1.3 以降でなければならない。
注：ベクトル入力データがEXPORTコマンドで生成されないこともあります：手動または他のツールやアプリケーションで作成できます。このベクトル文字列データをVECTOR列型にインポートする場合は、EXPORTコマンドで生成されたデータをインポートまたはロードする場合と同じルールに従います。

ベクトルデータの EXPORT、IMPORT、LOAD 操作に適用されるルール

ベクトル値が大きな VECTOR 列に正しく挿入されるようにするには、EXPORT コマンドと対応する IMPORT または LOAD コマンドの両方で LOB オプションを使用するか、LOB オプションを使用しない必要があります。 LOBオプションを使用しないと、ベクター文字列の値が切り捨てられるリスクがある。
EXPORT、IMPORT、LOAD コマンドは、ベクトル文字列の値を数値ではなく文字列として扱います。数値に適用されるファイルタイプ修飾子は、ベクトル文字列値には適用されません。影響を受けるファイルタイプ修飾子は以下の通り：
- decplusblank.
- decptx.
- implieddecimal IMPORTとLOADのみ。
- striplzeros輸出専用。
VECTOR 列からベクトル値をエクスポートし、そのベクトル値を異なる型の VECTOR 列にインポートすることはサポートされていません。異なるタイプの例としては、次元の異なるベクトルや座標型の異なるベクトルがある。
注:
EXPORTおよびIMPORTコマンドは、クライアント側の機能である。リモートクライアントからEXPORTおよびIMPORTコマンドを実行する場合 Db2 クライアントから Db2 クライアントと Db2 サーバ・インスタンスの両方が Db212.1.2 またはそれ以降が実行されている必要があります。

LOADコマンドには、クライアントサイドとサーバーサイドの両方のコンポーネントがある。リモートクライアントからLOADコマンドを実行する場合 Db2 を実行する場合、 Db2 クライアントと Db2 サーバー・インスタンスの両方が Db212.1.3 またはそれ以降が実行されている必要があります。

ベクターの制限

VECTOR データ型は、以下のオブジェクト・タイプと操作ではサポートされていません：

ユーザー定義タイプ：
- 特殊。
- 配列。
- 行タイプ
- 構造化されたタイプ。
アンカーデータ型。
ニックネームを作成します。
タイプマッピングを作成する。

さらに、以下の制限があります。

レプリケーションは VECTOR 列を持つテーブルをサポートしません。
ベクターを比較することはできない。
LOAD およびの操作はベクトルをサポートしていない。 INGEST
db2dart は/DDELオプションによるVECTOR列のダンプをサポートしていません。
論理バックアップおよびリストア操作は、 VECTOR タイプをサポートしていません。
ALTOBJ プロシージャは、カラムを持つテーブルをサポートしていません。 VECTOR
既存の列をVECTORに変更することはできません。
既存のVECTOR列を異なるデータ型や異なる座標型に変更することはできません。
既存の VECTOR 列ディメンジョンは変更できません。
DEFAULT 値として許されるのは NULL だけなので、NOT NULL ベクトル・カラムを既存のテーブルに追加することはできません。
VECTOR 式は、REFRESH IMMEDIATE 体系化問い合わせテーブルの選択リストではサポートされていません。
ベクトルを扱う場合、大なり小なりという概念がないため、VECTOR列やVECTOR結果データ型を持つ式は以下のような使い方はできません：
- 主キーとして。
- 外部キーとして。
- ユニーク・キーとして。
- CREATE INDEXキーとして。
- ORDER BY ソートキーとして。
- DPFのディストリビューション・キーとして。
- レンジ・パーティション・キーとして。
- MDCのキーとして。
- RCTキーとして。
- GROUP BY式として。
- IS (NOT) NULL 以外のジョイン条件の場合。
- SELECT DISTINCT式として。
- COUNT DISTINCT式として。
- UNION ALL以外のセット演算子。

ユース・ケース

使用例 1: Db2 テーブルから類似の患者記録を検索する: Db2、提案されているベクトルサポート機能を使って、リレーショナルレコードに対するベクトル類似性検索を実装することができる。; Db2、患者記録を保存するデータベーステーブルを考えてみよう。テーブルの各行は患者を表し、体格、健康マーカー、病状、性別など、患者に関するさまざまな属性や情報が含まれている。; 最近、このテーブルにいた患者の一人が心臓発作を起こしたと報告した。医師は、この患者と似たような特徴を示す他の患者を特定したいと考えている。この情報は、医師が血管造影などのさらなる医学的検査が必要な患者を特定するために重要である。しかし、注意しなければならないのは、医師はすべての患者をこれらの検査に出したいわけではないということである。というのも、これらの検査は高額になる可能性があり、すべての患者に必要とは限らないからだ。; このユースケースをサポートするために、病院の秘書は、クエリ患者と呼ばれる例の患者に最も似ている他の患者を見つける必要がある。; 図1： SQL文でのベクトルの使用; 病院のデータサイエンティストは、SQLクエリーを使用して、 Db2 テーブルから Python プログラムに患者記録を取り出す。これらは SQL 言語と独自のビューを使用し、 IBM DB や Db2 Magic commands extension for Jupyter Notebook のような Python 用の Db2 ツールもサポートしている。これらのツールは、すべての患者記録を自分のノート（ Python ）に取り込むことを可能にする。; 各レコードについて、データサイエンティストは各列の値を列名とともに連結して文章を生成する。これらの文章は患者記録を表し、 RoBerta のような言語モデルに送られ、各文章のベクトル埋め込みが生成される。このプロセスの最後に、1つのベクトルが各患者の特徴を表す。データサイエンティストは、これらのベクトルを格納するためにVECTOR列を追加して、Patientsテーブルを変更する。; UPDATE 文を使用して、患者テーブルの VECTOR 列にベクトルを格納します。ベクトルが Db2 に格納されると、病院の秘書は VECTOR_DISTANCE 関数を使用して SQL クエリを作成し、クエリ患者に最も類似した 5 人の患者を検索します。
使用例2：生成AI/RAGアプリケーションのためのベクトル・ストレージ: 近年、大規模言語モデル（LLM）の人気が高まっているが、これには限界がある。彼らは訓練されたデータに対してのみ優れたパフォーマンスを発揮することができる。新しい問題に直面したとき、彼らはしばしば間違った答えを出したり、作り話をしたりする。これに対処するため、検索補強生成（RAG）と呼ばれる方法を用いてLLMの回答を強化する。 RAGはプライベート・ナレッジ・リポジトリーを利用しており、LLMへのプロンプトにはリポジトリからの関連文書のリストが含まれている。そして、LLMはこれらの文書に基づいて答えを生成しようとする。 RAGを実装するには、ベクトル埋め込みを保存するための安全なデータベースと、機密の知識コンテンツのための安全なリポジトリが必要である。このコンテンツは、PDF、Word文書、またはWikiページから取得することができます。知識はベクトル埋め込みに変換され、安全にリポジトリに保存される。; Db2 構造化されていないコンテンツをblob、clob、JSONのような異なるカラムタイプで保存することができる。ユーザーは、自分のプライベートな知識資産を Db2 に保存することができる。各知識資産は、その異なるセクションのために生成されたベクトル埋め込みを持つことができ、それはVECTOR列を使用して Db2。 llama 3のような事前に訓練された、あるいはカスタムで訓練されたLLMがこれらの埋め込みを生成する。; 検索を開始するには、ユーザーはアプリケーションにプロンプトを送信する。このアプリケーションは、知識資産のベクトル化に使用したのと同じLLMを使用して、プロンプトをベクトル化する。同じLLMを使用してプロンプトをベクトル化した後、アプリケーションはクエリベクトルを生成し、このクエリベクトルは Db2 のベクトル類似性検索に利用される。この検索方法では、上位にマッチする文書のリストを取得し、それを元のプロンプトに追加する。また、LLMが増強された文書リストに基づいてユーザーの問い合わせに回答するための指示も含まれている。
図2：でベクトル類似性検索を実行する。 Db2
ここでは、 Db2 ベクトルサポートを使用したRAGアプリケーションの実装シナリオ例を紹介する：あるソフトウェア開発会社は、開発者向け記事の自然言語検索の実装を目指しています。以前は、開発者はキーワードベースの検索に頼らざるを得なかったが、これには限界があった。特に初心者にとっては、適切なキーワードを見つけるのが難しかった。検索結果は、開発者が目を通さなければならないドキュメントの長いリストであることが多く、多大な時間を費やし、無関係な情報を含んでいた。こうした問題に対処するため、同社のデータ・サイエンス・チームは、ユーザーが自然言語で質問できるようAI技術を活用する計画を考案した。彼らはコンテンツをベクトル表現として Db2 データベースに保存し、オリジナルの記事はテキストファイルとして保存している。; 開発者が質問をすると、アプリケーションは会社の知識資産に採用されているのと同じ方法でそれをベクトルに変換する。アプリケーションは次に、 Db2 データベース内のベクトルを検索し、最も関連性の高い文書を取得する。これらの文書の原文とプロンプトを組み合わせてAIモデルに送り、これらの文書だけを用いて開発者の質問に答えるよう指示する。言語モデルは、 Db2 に保存されている企業の個人的な知識に基づいて答えを提供しようとする。