サポートされているデータ型 (Azure AI Search)
この記事では、Azure AI Search でサポートされるデータ型について説明します。 フィルター式で使用されるフィールドと値は、 エンティティ データ モデル (EDM) に従って入力されます。 EDM データ型を指定することは、フィールド定義の要件です。
注意
インデクサーを使用している場合は、「Azure AI Search でのインデクサーのデータ型マップ」を参照してください。インデクサーがソース固有のデータ型を検索インデックスの EDM データ型にマップする方法の詳細については、「Azure AI Search」を参照してください。
ベクター フィールドの EDM データ型
ベクター フィールド型は、埋め込みモデルの出力に対して有効である必要があります。 たとえば、text-embedding-ada-002 を使用する場合、出力形式は Float32
または Collection(Edm.Single)
です。 このシナリオでは、 からfloat
プリミティブへのキャストが禁止されているため、データ型をint
割り当てInt8
ることはできません。 ただし、 から Float32
または (Collection(Edm.Half))
にFloat16
キャストできます。
ベクター フィールドは、埋め込みの配列です。 EDM では、配列はコレクションです。
データ型 | ベクター型 | 説明 | 推奨される使用法 |
---|---|---|---|
Collection(Edm.Byte) |
Binary | 1 ビット符号なしバイナリ。 Createまたはインデックスの更新 (2024-05-01-preview) 以降で使用できます。 |
Cohere の v3 バイナリ埋め込みモデルなど、バイナリ埋め込みを出力するモデルとの統合をサポートします。または、1 ビット符号なしバイナリ出力を出力するカスタム量子化ロジックをサポートします。 型 Collection(Edm.Byte) のフィールドについては、 バイナリ データ のフィールド定義とベクター検索アルゴリズムの指定に関するヘルプについては、「バイナリ データのインデックス作成」を参照してください。 |
Collection(Edm.Single) |
Float32 |
32 ビット浮動小数点。
Createまたはインデックスの更新 (2023-07-01-Preview) 以降で使用できます。 このデータ型は、新しいプレビュー バージョンと安定バージョン 2023-11-01 でもサポートされています。 |
ユーザーに代わってベクター フィールドを作成する Microsoft ツールの既定のデータ型。 精度と効率のバランスを取ります。 ほとんどの埋め込みモデルでは、ベクトルが として Float32 出力されます。 |
Collection(Edm.Half) |
Float16 |
精度と範囲が低い 16 ビット浮動小数点。 Createまたはインデックスの更新 (2024-03-01-preview) 以降で使用できます。 | メモリと計算効率が重要であり、ある程度の精度を犠牲にすることが許容されるシナリオに役立ちます。 多くの場合、クエリ時間が短縮され、 と比較して Float32 メモリ占有領域が減少しますが、精度は若干低下します。 インデックスFloat32 埋め込みに 型を としてFloat16 割り当てることができますFloat16 。 を使用 Float16 して、モデルまたはネイティブに出力 Float16 するカスタム量子化プロセスを埋め込むこともできます。 |
Collection(Edm.Int16) |
Int16 |
16 ビット符号付き整数。 Createまたはインデックスの更新 (2024-03-01-preview) 以降で使用できます。 | 多くのアプリケーションで十分な精度を Float32 維持しながら、より高精度の量子化方法と比較してメモリ占有領域を削減し、サポートします。 メモリ効率が重要な場合に適しています。 ベクトルを として Int16 出力するカスタム量子化が必要です。 |
Collection(Edm.SByte) |
Int8 |
8 ビット符号付き整数。 Createまたはインデックスの更新 (2024-03-01-preview) 以降で使用できます。 | または Float16 と比較して、メモリと計算効率が大幅にFloat32 向上します。 ただし、精度の低下とリコールを適切に相殺するには、補足的な手法 (量子化やオーバーサンプリングなど) が必要な場合があります。 ベクトルを として Int8 出力するカスタム量子化が必要です。 |
非ベクトル フィールドの EDM データ型
データ型 | 説明 |
---|---|
Edm.String |
テキスト データ。 |
Edm.Boolean |
true または false の値が含まれます。 |
Edm.Int32 |
32 ビット整数値です。 |
Edm.Int64 |
64 ビット整数値です。 |
Edm.Double |
倍精度 IEEE 754 浮動小数点値。 |
Edm.DateTimeOffset |
OData V4 形式で表される日付と時刻の値: yyyy-MM-ddTHH:mm:ss.fffZ または yyyy-MM-ddTHH:mm:ss.fff[+|-]HH:mm 。 フィールドの DateTimeOffset 有効桁数はミリ秒に制限されます。 サブミリ秒の有効桁数の値をアップロード DateTimeOffset した場合、返される値はミリ秒に切り上げられます (たとえば、 2024-04-15T10:30:09.7552052Z は として 2024-04-15T10:30:09.7550000Z 返されます)。 タイム ゾーン情報を含む値をインデックスにアップロード DateTimeOffset すると、Azure AI Search によってこれらの値が UTC に正規化されます。 たとえば、 2024-01-13T14:03:00-08:00 は として 2024-01-13T22:03:00Z 格納されます。 タイム ゾーン情報を格納する必要がある場合は、インデックスにフィールドを追加します。 |
Edm.GeographyPoint |
地球上の地理的な場所を表すポイントです。 要求本文と応答本文の場合、この型の値の表現は GeoJSON の "Point" 型形式に従います。 URL の場合、OData は WKT 標準に基づくリテラル形式を使用します。 点のリテラルは、geography'POINT(lon lat)' という形式で構築します。 |
Edm.ComplexType |
プロパティが、サポートされている他の任意のデータ型のサブフィールドにマップされるオブジェクト。 この型を使用すると、JSON などの構造化階層データのインデックス作成が可能になります。 型 Edm.ComplexType のフィールド内のオブジェクトには入れ子になったオブジェクトを含めることができますが、入れ子のレベルは制限されています。 制限については、「 サービスの制限」を参照してください。 |
Collection(Edm.String) |
文字列の一覧。 |
Collection(Edm.Boolean) |
ブール値の一覧。 |
Collection(Edm.Int32) |
32 ビット整数値のリスト。 |
Collection(Edm.Int64) |
64 ビット整数値のリスト。 |
Collection(Edm.Double) |
倍精度数値のリスト。 |
Collection(Edm.DateTimeOffset) |
日付時刻の値の一覧。 |
Collection(Edm.GeographyPoint) |
地理的な場所を表すポイントの一覧。 |
Collection(Edm.ComplexType) |
型 Edm.ComplexType のオブジェクトの一覧。 ドキュメント内のすべての種類 Edm.ComplexType のコレクションの要素の最大数には制限があります。 詳細については、「 サービスの制限 」を参照してください。 |
プリミティブ型と複合型のコレクション (例: Collection(Edm.String)
) を除き、上記のすべての型は null 許容です。 NULL 値が許容されるフィールドは、明示的に NULL に設定できます。 Azure AI Search インデックスにアップロードされたドキュメントから省略すると、自動的に null に設定されます。 コレクション フィールドは、ドキュメントから省略されると、自動的に空 ([]
JSON) に設定されます。 また、コレクション フィールドに null 値を格納することはできません。
複雑なコレクションとは異なり、プリミティブ型のコレクション内の項目の数に特に上限はありませんが、 ペイロード サイズの 16 MB の上限 は、コレクションを含むドキュメントのすべての部分に適用されます。
フィルター式で使用される地理空間データ型
Azure AI Search では、地理空間検索はフィルターとして表されます。
Edm.GeographyPolygon は、地球上の地域を表す多角形です。 この型はドキュメント フィールドでは使用できませんが、関数の引数 geo.intersects
として使用できます。 OData の URL のリテラル形式は、 WKT (既知のテキスト) と OGC の単純な機能アクセス標準に基づいています。 多角形のリテラルは、geography'POLYGON((lon lat, lon lat, ...))' という形式で構築します。
重要
多角形内のポイントは、反時計回りの順序である 必要があります 。 多角形内のポイントは、ポリゴンの内側を基準に、反時計回りの順序で解釈されます。 たとえば、ロンドン周辺の 4 ポイント閉じたポリゴンは、-0.3°W 51.6°N [左上] 、-0.3°W 51.4°N [左下]、 0.1°E 51.4°N [右下], 0.1°E 51.6°N [右上], -0.3°W 51.6°N [開始点].