SQL Database のベクターサポートについて情報をまとめておく at SE の雑記

PASS 2024 で Exciting Announcement: Public Preview of Native Vector Support in Azure SQL Database! として SQL Database のベクターサポートの Public Preview がアナウンスされました。

MI については、今後数か月で Public Preview が公開されるということで、Azure の SQL Server ベースの環境でベクターサポートの一般公開の作業が進められています。

EAP 時点の情報とは多少異なっている内容がありますので、現時点の情報をまとめておきたいと思います。

SQL Server 2025 でもベクターサポートが入りますので、今後の SQL Server でも活用できる知識となるのかと。

Contents

1 SQL Database のベクターサポートについて
2 ベクターデータ型
3 ベクター関数
4 SQL Database から Azure OpenAI の利用
- 4.1 トークンの上限についての考慮
- 4.2 CREDENTIAL を使用した sp_invoke_external_rest_endpoint の実行
5 ベクターサポートについての参考情報
- 5.1 Azure SQL Devs’ Corner
- 5.2 GitHub Samples
6 一般的な内容

SQL Database のベクターサポートについて

SQL Database のベクターサポートについては次のドキュメントで概要を確認することができます。

SQL データベースエンジン内のベクターの概要

SQL Database でサポートされている大きな機能としては次の 2 つの機能となります。

ベクターデータ型

新しいデータ型として vector データ型のサポートが追加されました。

ベクトルデータ型 (プレビュー)

このデータ型はベクトルデータを効率的に格納することを想定したデータ型となり、Embedding (埋め込み) で利用するベクターデータを格納する際に利用を行います。

EAP 開始時点からの変更点

EAP が開始された直後は、vector データ型はサポートされていなかったため、nvarchar(max) や json データ型のような文字列データにベクターデータを格納して、Embedding で利用をしていました。

その際の情報は、Announcing EAP for Vector Support in Azure SQL Database にも名残が残っているのですが、当初はベクターデータ型がサポートされていなかったため、JSON_ARRAY_TO_VECTOR / ISVECTOR / VECTOR_TO_JSON_ARRAY 関数を使用して文字列とベクターフォーマットのデータの相互変換を行っていました。

ベクターデータ型が追加されたことで、現在は、これらの関数は非推奨の関数となっており、ベクターデータについては、VECOTR データ型を使用することが推奨されたものとなっています。

過去の記事で非推奨な関数が使用されているものがあるかもしれませんが、その場合はベクターデータ型がサポートされる前の情報なのかについては意識しておくとよいかと。

サポートされる最大のディメンション数

ベクターデータ型で最大 1998 のディメンションがサポートされています。

SQL Database 単体で Embedding を生成する場合、後述の利用可能な外部サービスの制限の関係で、Azure OpenAI Embedding を使用することになるかと思います。

使用可能なモデルと各モデルの最大のディメンションについては modelName でサポートされるディメンション で確認することができますが、「text-embedding-3-large」については、最大ディメンションが 3,072 となっているため、VECTOR データ型に格納することができません。

Azure OpenAI を使用する場合、現時点では最大ディメンションが 1,536 となっている「text-embedding-ada-002」「text-embedding-3-small」のいずれかを使用することになり、「text-embedding-3-small」を使用することが多くなるのではないでしょうか。(モデルの違いについては、Vector embeddings / New embedding models and API updates が参考になります。)

データ型の制限事項

データ型の現時点での制限については、制限事項に記載されています。

REST API で JSON フォーマットの文字列を nvarchar(max) に格納して VECTOR に格納するのであれば、「CAST(@v AS vector(1536))」で直接 vector に変換すれば問題はありません。

JSON データ型に格納されているデータを VECTOR に変換する場合は、JSON → VECTOR はサポートされていないため、json → nvarchar(max) → vector の順で変換する必要があります。

ベクターインデックス

現時点ではベクターデータ型については、インデックス列として使用することはできず、INCLUDE 列としての利用に制限がされています。

仕様についてはまだ公開されていないのですが、PASS 2024 で近日公開の機能として Vector Index with DiskANN がアナウンスされました。

DiskANN を使用したベクターインデックスについては Cosmos DB for No SQL / Azure Database for PostgreSQL Flexible Server で既に実装されていますので、Azure Cosmos DB for NoSQL におけるベクトル検索 (プレビュー) / Azure Database for PostgreSQL – フレキシブルサーバーで diskann 拡張機能を有効にして使用するも参照しておくとよさそうです。

ベクター関数

ベクターデータ型で格納されているデータ向けの関数としてベクター関数が追加されています。

ベクターデータの使用方法については理解が浅いので、VECTOR_DISTANCE しか使用用途を理解できていないのですが…。

SQL Database では、Embedding をローカルで作成することができないため、SQL Database で完結して、VECTOR_DISTANCE を使用する場合には、距離の測定対象となる文字列の Embedding の取得についても Azure OpenAI に頼る必要があります。

各ベクター関数の具体的な利用ケースについては、本機能を学習しながら、理解できたことがあればこの節に追記していきたいと思います。

SQL Database から Azure OpenAI の利用

SQL Server ベースの環境で AI というと、モデルをデータベースの内部に配置し、データベースに近い場所で AI を使用するというのが今までの構成となっていましたが、Embedding については現在はローカルのモデルを使用するのは一般的な構成にはなっていません。

前述のとおり、SQL Database 単体で Embedding のモデルを使用してベクター化されたデータを生成するためには Azure OpenAI を使用する必要があり、Azure 内の別サービスと連携する必要があります。

この際に利用できるのが sp_invoke_external_rest_endpoint となります。

このストアドプロシージャで利用可能なエンドポイントは許可されるエンドポイントに記載されており、Azure の許可されているサービスに限定されますが、許可されたサービスに対してアクセスをすることができます。(これ以外のサービスにアクセスする場合は、許可されているサービス経由でアクセスできないかを検討する日宇町があります)

そのため、現時点では SQL Database を起点として、Embedding のためのデータを作成するためには、Azure OpenAI の使用を検討する必要があります。

呼び出し方法については Azure OpenAI に記載されており、Azure ApenAI を REST API として呼び出し、指定したテキストについての Embedding のためのベクター化されたデータを取得することができます。

sp_invoke_external_rest_endpoint の基本的な利用方法については、Azure SQL DB sp_invoke_external_rest_endpoint samples が公開されており、Azure OpenAI の利用についてもこのサンプルから確認することができます。

トークンの上限についての考慮

Azure OpenAI で Embedding のためのデータを作成するためには、前述のとおり「text-embedding-ada-002」「text-embedding-3-small」を使用することになるかと思います。

これらのモデルでは、最大で 8,192 のトークンまでがサポートされており、それ以上のトークンで API が呼ばれた場合には次のような 400 のエラーとなります。

This model’s maximum context length is 8192 tokens, however you requested 8455 tokens (8455 in your prompt; 0 for the completion). Please reduce your prompt; or completion length.

簡易的なトークン数の確認としては Tokenizer が使用できますが当ブログの内容であれば 35,000 バイト前後のポストで 8,192 トークンを超えることが多いです。

ある程度の長さの文字列でチャンクして API にテキストを渡す必要が出てくるかと思いますが、SQL Database で Azure OpenAI を使用する場合の T-SQL でのデータのチャンク方法の一般的な方法が確立されていないように思えます。

sp_invoke_external_rest_endpoint では Logc Apps を呼び出すこともできますので、Azure Logic Apps の Standard ワークフローのコンテンツを解析またはチャンク化する (プレビュー) の方法を参考にして、T-SQL でチャンクする方法は確認しておきたいと思います。

CREDENTIAL を使用した sp_invoke_external_rest_endpoint の実行

Azure OpenAI では、CREDENTIAL の構文までは記載されていませんでしたが、sp_invoke_external_rest_endpoint では、API 呼び出し時の認証情報については、CREDENTIAL として指定することができます。

CREATE DATABASE SCOPED CREDENTIAL [<資格情報名>]
WITH IDENTITY = 'HTTPEndpointHeaders', SECRET = '{"api-key":"<API キー>"}';

このようなクエリで CREDENTIAL を作成しておくことができ、事前に作成しておくことで、呼び出しごとにヘッダーに明示的に API キーを指定しなくてもストアドプロシージャの呼び出し時に @credential として作成しておいた CREDENTIAL を指定することで Azure OpenAI でデプロイしたモデルを使用することができます。