次の方法で共有

Azure 上の AI ワークロード用のデータ プラットフォーム

  • [アーティクル]

データ プラットフォームは、ソース データを取り込み、それをフィルター処理、集計、使用するための準備を行うことで、ワークロードの要件を管理するように設計された統合された一連のテクノロジです。

データには、意図した用途に基づく個別の特性があります。 この記事で説明する技術的な機能を調べる前に、優れたデータ パイプライン設計の原則を理解することを強くお勧めします。 詳細については、「 データデザインのトレーニング と データ設計のを参照してください。

プラットフォームは、データがパイプライン内の特定のポイントに置かれたときのストレージ ニーズも満たします。 ワークロードが複雑で、大規模なデータを処理する場合は、パイプライン タスクをさまざまなコンポーネントに分散できます。 より簡単なユース ケースでは、それらの結合された機能を提供するストアでソース データを使用できるかどうかを評価します。

データ プラットフォームの過度に複雑なアーキテクチャを設計しないように、次の質問をしてください。 可能な限りシンプルにしておくことが常に最善です。

  • 1 つのソースからデータを取り込むことで、予想される予測能力をアプリケーションに提供できますか?
  • データ ストアの最初の選択では、データ ウェアハウス機能がサポートされていますか?
  • ソース データは AI 検索用に既に最適化されていますか?

これらの質問に対して "はい" と答える場合は、アプリケーションがデータ ソースに直接アクセスできるようにすることで、アーキテクチャを簡略化できます。 このアプローチにより、データ インジェスト、分析ストア統合、外部データ処理などのビッグ データ アーキテクチャ コンポーネントが不要になります。 ソース データベースが必要な検索を処理できる場合は、検索インデックス機能をソース データベースに直接統合することが実用的なアプローチです。 ソースが新しい需要に合わせてコスト効率よくスケーリングできることを確認します。

たとえば、Azure Cosmos DB ではベクター検索がサポートされているため、別のインデックスは必要ない場合があります。 もう 1 つのユース ケースは、検索操作のエンドポイントとして読み取りレプリカを使用することです。 読み取りレプリカを持つ SQL データベースの場合、これらのレプリカに直接検索を行うと、パフォーマンスが最適化されます。 データベースの組み込み機能を利用して、アーキテクチャを可能な限り簡略化します。

大規模なワークロードのデータ プラットフォーム アーキテクチャは、より複雑です。

複数のデータ ソースからデータを取り込み、さまざまなプラットフォームで検索を調整すると、複雑で非効率的になる可能性があります。 また、抽出、変換、読み込み (ETL) も必要です。抽出、読み込み、変換 (ELT);または、データ ストア内のデータを整形するための抽出と読み込み (EL) プロセス。 データの処理が増えるにつれて、シナリオがより複雑になります。 インジェストからクエリの提供まで、エンドツーエンドのパイプラインを処理するには、アーキテクチャに多くのコンポーネントを追加する必要があります。 多くのビッグ データ テクノロジは、これらの処理タスクを効果的に処理するために高度に特殊化され、構築されています。

そのようなテクノロジの 1 つが検索インデックスです。 別のインデックスを追加する主な利点は、クエリを効率的に管理し、高スループットの大量のデータを処理できることです。 この関数は、元のデータ ソースから AI 機能をオフロードし、インデックスがメイン関数に集中してクエリを提供できるようにします。

特定の機能と目的に基づいてプラットフォームを選択し、機能要件と技術要件を検討します。 複雑なユース ケースを処理するようにアーキテクチャが進化している場合は、集計されたデータ ストア、パイプラインの処理、および検索インデックスに関する次のセクションに注目してください。

推奨事項

この記事で提供される推奨事項の概要を次に示します。

推奨 説明
セキュリティで保護され、パフォーマンスが高く、コスト効率の高いデータ ストアを構築します。 データ プラットフォームの重要な部分は、複数のソースからデータを集計し、さまざまな統合タスクとの統合を可能にするデータ ストアです。 これは、ワークロードの大規模な実行に役立ちます。 コスト効率の高いデプロイを確実に行うために、データ ストアのさまざまな機能要件と機能以外の要件を必ず確認してください。

▪ 集計データを格納するための管理
データインジェストと処理のベスト プラクティスに従います。 高品質のデータは、ワークロードの信頼性とエンド ユーザー エクスペリエンスの向上に役立ちます。 ワークロードの要件と、高品質のバーを維持するのに役立つ効率的なインジェストとデータ移行プロセスを構築するための主要なベスト プラクティスを検討します。

▪ データ処理の管理
信頼性が高く、関連性の高い検索インデックスを設計する。 クエリが正確でない場合でも、即興クエリとあいまいクエリを効率的に処理し、関連する結果をユーザー ベースに提供する、高パフォーマンスの書き込み 1 回の読み取り多くのデータ ストアを目指します。

▪ 検索インデックスの管理
機能データ ストアが大規模に実行されるようにします。 ワークロードの機能要件によっては、オフライン推論などの機能データ ストアを作成する必要がある場合があります。 指定された関数を念頭に置いてデータ ストアを作成し、その関数のベスト プラクティスを適用することが重要です。

▪ 機能ストアの管理
▪ オフライン推論データ ストアの管理

集計データの格納に関する考慮事項

AI ワークロードでは、データは、これらのステージ間でワークフローを調整するパイプラインを使用して、ストレージと処理のさまざまな段階を移動します。 1 つの重要なステージは、複数のソースから取り込んで集計されたデータを含むデータ ストアです。 データがトレーニングまたはインデックス作成に適した状態になるまで処理を実行するには、このストアが必要です。 主な焦点は、データがそのソースを正確に反映できるようにすることです。

Note

別の方法は、データ ソースに直接アクセスすることです。 ただし、このアプローチでは、ソース システムが AI 機能で過負荷になる可能性があるため、パフォーマンスの問題につながる可能性があります。 データ アクセスの問題が発生する可能性もあります。 これらの問題を回避するには、このストアにデータをコピーすることをお勧めします。

このストアのデータ プラットフォームは、データ ソースに適用されるセキュリティ標準を満たし、コスト効率が高く、ETL、ELT、EL 処理タスクとの統合をサポートする必要があります。 オプションは、基本的なストレージからビッグ データ テクノロジまで、データ量によって異なります。 十分な信頼性とパフォーマンスを実現するのに役立つ経済的なストレージを選択します。

次のセクションでは、データ ストア テクノロジを選択するときに考慮する機能に関するガイダンスを示します。 詳細については、「 Data 処理パイプライン」を参照してください。

機能要件

  • プラットフォームはさまざまなデータ形式を処理できますか?

    データ ストアは、さまざまなデータ形式を格納し、必要に応じて他の形式に変換できる必要があります。

    インジェスト パイプラインがリレーショナル データベースと Parquet ファイルからデータをソースし、構造化データと半構造化データの両方をサポートしているとします。 リレーショナル データをスキーマ定義に従って Parquet 形式に変換する必要があります。 データ プラットフォームには、カスタム コードを記述せずにその変換を行う機能が組み込まれている必要があります。

  • 複数のバージョンのデータを格納する予定ですか?

    データ値とスキーマは時間の経過とともに変化する可能性があり、データの複数のバージョンを管理することが重要になります。

    ソース システムは通常、履歴データではなく、現在のデータのみを格納します。 履歴データを保持することが重要な場合は、ソース システムから大規模なデータ セットを複製することが必要になる場合があります。 この場合、バージョン管理によって、履歴データから現在のデータがあいまいさを解消する可能性があります。

    場合によっては、さまざまなユース ケースでデータのコピーを保持することが必要になる場合があります。 このシナリオをサポートするには、データのフォークが必要になる場合があります。 各フォークは、品質と使いやすさを高めるために個別に変異することができます。 データ プラットフォームは、これらのフォークの適切なバージョン管理を維持できる必要があります。

    データ プラットフォームは、履歴コンテキストを提供するために、時間の経過と同時にデータのバージョンを格納できる必要があります。 この contetxt は、単一の時点ではなく複数の観察を提供するため、AI モデルの処理とトレーニングに役立ちます。

  • プラットフォームにはデータ ライフサイクル管理機能が組み込まれていますか?

    データ ライフサイクル管理 (DLM) は、データの収集、ストレージ、使用状況、アーカイブ、破棄などのステージを使用して、作成から削除までのデータを管理するためのプロセスです。

    DLM がないと、データが制御不能に拡大する可能性があります。多くの場合、品質レベルを通過するにつれて複数のコピーが作成されます。 データ プラットフォームには、無制限のデータの増加を防ぐための DLM 機能が必要です。

    このシナリオを考えてみましょう。 前処理手順は、トレーニング目的で許容できる品質に達するまで、データを調整するために繰り返す必要があります。 データ プラットフォームは、データの中間コピーを削除できる必要があります。

    場合によっては、規制監査のためにデータの保持が必要になる場合があります。 データ プラットフォームには、アクセス頻度の低いデータを低コストでアーカイブできるように、コールド ストレージ機能が必要です。

  • プラットフォームはデータ ガバナンス機能をサポートしていますか?

    監査可能性は、AI ワークロードにとって重要な側面です。 データ ストアは、データ アクセスを追跡し、プライバシーを確保し、データの起源を理解できる監査証跡を維持する必要があります。

    データ ディクショナリ機能を使用して、メタデータ、データ型、目的、系列を管理します。 この機能は、データが複数のソースから取り込まれる場合に特に重要です。

  • 運用環境のデータを使用してトレーニングを行う予定ですか?

    デプロイには、モデルデプロイとコードデプロイの 2 つの方法があります。 モデルデプロイでは、運用環境のデータが開発で使用され、厳しいセキュリティ対策が必要です。 コードデプロイでは、モデルは運用環境になるまで運用データを表示しません。 コードのデプロイにより開発環境でのセキュリティ上の懸念は簡単になりますが、コンピューティング コストが増加する可能性があります。 どちらの方法を選択する場合でも、データ プラットフォームでは、開発と運用のための個別の環境をサポートする必要があります。

  • 主要な機能よりも便利な機能を優先していますか?

    AI または機械学習用のデータ プラットフォームを選択する場合は、ノートブックの機能だけに依存しないでください。 ノートブックは探索的データ分析に役立ちますが、決め手にすることはできません。 通常、ノートブックのコンピューティング リソースは集計データ ストアの範囲外です。 通常は、Azure Machine Learning などの他のリソースと統合されます。

非機能要件

  • 格納するデータの量はどのくらいですか?

    AI ワークロードは大量のデータを生成します。 複数のバージョンと追加のメタデータにより、ボリュームが大幅に増加する可能性があります。

    ストレージとスループットのスケーラビリティが重要です。 データ プラットフォームでは、データ ボリュームの処理、同時書き込みの管理、および個々の書き込みのパフォーマンスを低下させることなく確実に行いながら、インジェスト パイプラインからのデータを効率的に使用する必要があります。 これらの条件は、ストアへの読み取り、処理、書き戻しを行う処理パイプラインにも適用されます。

    インジェストと処理が同時に行われることが多いため、決定を下すときは、プロセス全体を考慮してください。 設計では、頻繁なデータ移動と処理を管理できる必要があります。 データ プラットフォームは、データを効果的に処理するための高度な並列処理を提供する必要があります。

    プラットフォーム テクノロジは、読み取りと書き込み操作のスループットとパフォーマンスに関する意味のある分析情報を提供するテレメトリを出力する必要があります。

  • このデータ ストアは、ワークロードの信頼性ターゲットに貢献する重要なコンポーネントですか?

    複数のインスタンスを使用して信頼性とスケーラビリティの両方を強化するデータ ストアを選択します。 ビッグ データ ストアには、多くの場合、インスタンス間でデータ処理を調整する組み込みのコントローラーがあります。 1 つのコピーが失敗した場合は、別のコピーを使用できます。

    データが正しくない場合やアクセス可能でない場合、データは目的を果たさないことに注意してください。 データ プラットフォームは持続性を保証し、データがそのままであることを確認する必要があります。 データを照会する API にアクセスできることを確認します。 さらに、バックアップ機能を持つデータ ストアを検討してください。

    一般に、このデータをバックアップする必要はありません。 ただし、最初から毎回データを集計するコストが大幅に高い場合は、バックアップからデータをリハイドレートすることを検討できます。

  • コストの制約はありますか?

    データの信頼性とパフォーマンスが十分な場合は、コストへの影響を考慮してください。

    データ ストレージの過剰な保留を回避するには、システムを一度 書き込み、多くの読み取り 用に最適化する必要があります。 トレーニングデータまたは接地データは重要ですが、実稼働データベースのように重要ではありません。これには即時の応答性が必要です。 投資収益率を最大化するのに十分な効率でコストを分散することに焦点を当てています。

前述の要件により、DLM、品質レベル、可観測性、および多様なファイル形式のサポートが提供されるため、データ レイクの使用を検討する必要が生じることがあります。 ワークロードで既にデータ レイクが使用されている場合は、そのリソースを利用して AI のニーズを満たします。 または、あるレベルの DLM、監視機能、高いトランザクションレートを提供する Azure Blob Storage などの他のストレージ オプションを選択することもできます。

データ処理に関する考慮事項

集約データ ストアのデータを処理して、そのユーティリティをダウンストリームに増やす必要があります。 ETL パイプラインはこのタスクを実行します。これは、次の点で最も重要です。

  • インジェスト レイヤー

    パイプラインは、さまざまなソースからデータを収集し、集計データ ストアに移動する役割を担います。 このプロセス中、パイプラインは通常、基本的な前処理を実行し、クエリ可能な形式でデータを構造化する場合もあります。

    カスタム コードの必要性を最小限に抑えるために、この責任の多くをデータ プラットフォームにオフロードすることをお勧めします。 テクノロジを選択するときは、モデルのトレーニングと拡張をサポートするために必要な ETL 特性を考慮してください。

  • 処理レイヤー

    集計データ ストアのデータは、インデックス作成またはモデル トレーニングのユース ケースに使用する前に、広範な処理を受けます。 処理パイプラインには、インジェスト パイプラインに似たレベルの信頼性とスケーリングが必要です。 主な違いは、データに対して実行される処理の種類です。

    このプロセスには、データの大幅なスコープ設定と再構築が含まれます。 このプロセスには、エンティティ認識、データ セットへの追加データの統合、ルックアップの実行などのタスクが含まれます。 このプロセスには、不要なデータの削除や、データ オーケストレーション プラットフォームを介したデータ ロジックの適用も含まれる場合があります。

データ処理ステージでは、さまざまな出力を生成できます。この出力は、意図ごとに異なる宛先に配置されます。 その主な目標は、集計されたデータ ストアからデータを準備し、最終的な宛先で使用できるように転送することです。 コンシューマーは、必要に応じてデータをプルすることも、処理レイヤーが準備ができたらデータをプッシュすることもできます。

Note

機械学習と生成 AI のコンテキストでは、ETL、ELT、EL の各プロセスを区別することが重要です。 従来の ETL は、データ ウェアハウスとオブジェクト リレーショナル マッピングに不可欠です。スキーマの制限により、ターゲット システムに読み込む前にデータを変換する必要があります。 ELT には、データの抽出、データ レイクへの読み込み、Python や PySpark などのツールを使用した変換が含まれます。 特に取得拡張生成 (RAG) の場合、生成 AI では、多くの場合、ドキュメントの抽出とストレージへの読み込みが最初に行われ、その後にチャンクや画像の抽出などの変換が行われます。

次のセクションでは、ETL 機能を備えるデータ処理テクノロジを選択するときに考慮するガイダンスを示します。

機能要件

  • データ ソースに接続するためのサポートは何ですか?

    処理する必要があるデータは、リレーショナル データベース、ビッグ データ ソース、またはさまざまなストレージ ソリューションに格納される場合があります。

    ほとんどのデータ処理テクノロジでは、コードを記述せずにさまざまなデータ ソースに接続できる事前構築済みの統合がサポートされています。 コネクタには、ソースからシンクにデータをコピーし、参照を実行し、何らかの形式のデータ ガバナンスを適用する機能などの機能があります。 不要なコーディングを回避するためのドラッグ アンド ドロップ機能を提供するツールがあります。

    予想されるデータ ソースと簡単に統合できるデータ プラットフォームを選択します。

  • プラットフォームはさまざまなデータ形式を処理できますか?

    データは、データベースや JSON などの構造化データ、画像やドキュメントなどの非構造化データ、モノのインターネット デバイスからのデータなどのストリーミング データなど、さまざまな形式で提供される場合があります。 パイプラインは、想定されるファイルの種類を処理できる必要があります。

  • プラットフォームでは、データの準備とスコープ設定のための機能が提供されますか?

    トレーニング、微調整、またはインデックス作成に適するまで、トレーニングまたは拡張に使用するデータを処理する必要があります。 データ設計戦略では、要件を明示的に概説する必要があります。

    次の記事では、具体的な考慮事項について説明します。

    基本的なクレンジングの一環として、プラットフォームは重複を削除し、欠損値を埋め、インジェスト中の余分なノイズを排除します。 RAG パターンの実装など、特定のユース ケースでは、チャンクを小文字にすることをお勧めします。

    これらの前処理手順は必要ですが、プラットフォームでは、ニーズに固有の豊富なデータ操作もサポートする必要があります。 このプロセスには、データの読み込み、再スコープ、変換が含まれます。 特定のモデルでは、ドキュメント インテリジェンスやその他の AI ツールなど、ドキュメント分析のために外部ソースにクエリを実行できる必要があります。 この作業は、データの準備とデータ エンリッチメントに必要です。

    データ ストアでこのレベルの処理がサポートされている場合は、ストア内のこのステージを他の場所に移動せずにローカライズできます。 それ以外の場合は、Azure Databricks や Azure Data Factory などの外部テクノロジが必要です。 これらのテクノロジは、データの移動や、フィルター処理、欠損値の入力、文字列の大文字と小文字の標準化などの操作の実行に適しています。 より複雑なタスクの場合、通常はジョブ ホスティング プラットフォームが必要です。 ビッグ データ オーケストレーションには Spark プールを使用できます。

    特定のユース ケースでは、この責任をデータのコンシューマーに外部化することが必要になる場合があります。 たとえば、機械学習を使用する AI モデルでは、カスタム Python コードを使用してデータの読み取り、操作、書き込みを行うジョブ処理機能が提供されます。

    もう 1 つの例として、RAG 実装があります。 一般的な処理手順はチャンクです。ここで、ドキュメントは複数のチャンクに分割され、各チャンクはインデックス内の行になります。 また、これらのチャンクに対して OpenAI サービスによって生成されることが多い埋め込みも格納されます。 AI 検索では、このプロセスは、OpenAI または Azure AI Search のどちらを使用してインデックス作成ワークフロー内で調整されます。

  • ワークフローを管理するための組み込みのオーケストレーターはありますか?

    処理タスクはモジュール式であり、ジョブとして実行されます。 プラットフォームには、ワークフローをステップまたはジョブに分割するオーケストレーション機能が必要です。 各ジョブは、個別に定義、実行、および監視する必要があります。

    複雑なワークフローでは、特定の手順は、前の手順が正常に完了したかどうかによって異なります。 オーケストレーターはジョブの依存関係を処理し、タスクが正しい順序で完了していることを確認する必要があります。

    データ設計は反復的なプロセスであるため、オーケストレーター ツールは、ワークフローを簡単に変更するのに十分な柔軟性を備える必要があります。 コードの大部分を書き直すことなく、新しいステップを挿入したり、既存のステップを調整したりすることができます。

    Data Factory は、データ ワークフローを管理するための豊富な機能セットを提供するため、一般的な選択肢です。 Azure Databricks では、複雑なワークフローを管理し、ジョブをスケジュールおよび監視することもできます。 コストへの影響も考慮する必要があります。 たとえば、Azure Databricks の機能は広範囲に及ぶ可能性がありますが、コストも高くなります。 Apache NiFi などのオープンソースの代替オプションの方が、コスト効率が高い場合があります。

    最終的に、どのツールを選択するかは、組織が許可する内容と、ワークロード チームが快適に使用できるスキルによって異なります。

非機能要件

処理パイプラインを選択するときは、スループットと可観測性のバランスを取る必要があります。 パイプラインは、十分な期間内にモデルまたはインデックスに必要なデータを確実に処理して配置する必要があります。 現在のニーズをサポートするのに十分な軽量で、将来の成長のためにスケーラブルである必要があります。 チームは、後で技術的負債を回避するために、プラットフォームを将来に備える必要がある量を決定する必要があります。 重要な考慮事項には、データ インジェストの頻度と量、プロセスの信頼性、問題を迅速に監視して対処するための監視の必要性などがあります。

  • 取り込むデータの量はどのくらいですか?

    インジェストと処理の段階では、タスクを処理するためのプラットフォームのスケーラビリティと速度を考慮してください。 たとえば、インデックスまたはモデル トレーニングのために、毎日 10 テラバイトのデータを読み込む必要があります。 データ インジェスト プラットフォームは、予想されるスループットで、その量を処理できる必要があります。 この場合、このような負荷の下で失敗する可能性があるため、Azure Logic Apps を使用できない可能性があります。 代わりに、Data Factory は、この規模のデータ処理に適しています。

    大量を処理する方法の 1 つは、並列処理を使用することです。並列処理により、データの処理と処理がより効率的になります。 Azure Databricks などのプラットフォームでは、同じジョブに対して複数のインスタンスを作成し、負荷を効率的に分散することで、タスクを調整できます。

    また、許容可能な待機時間とジョブの複雑さを考慮してください。 たとえば、データ クレンジングには、無効なフィールドの検証や置換、機密情報のマスクが含まれます。 これらのタスクは基本的ですが、各行が個別に処理されるため、大量のリソースが必要です。これにより、全体的な時間が増加します。

  • どのような監視機能が必要ですか?

    データ処理パイプラインには監視機能が必要であり、パイプラインのパフォーマンスとジョブの状態に関する分析情報を提供する必要があります。

    ジョブの進行状況を追跡できる必要があります。 パイプラインが、完了または部分的に完了しないデータ クレンジング ジョブを実行するとします。 モデルのトレーニングに使用するデータの品質にダウンストリームの影響が生じ、予測能力に影響を与える可能性があります。

    ワークロード内の他のコンポーネントと同様に、データ パイプラインのログ、メトリック、アラートを有効にして、その動作を理解する必要があります。 パフォーマンス メトリックを収集して分析し、効率と信頼性の側面を理解します。

    組み込みのテレメトリのギャップを特定し、実装する必要がある追加の監視を決定します。 この監視には、ジョブ ステップに関する特定の詳細をキャプチャするためのカスタム ログまたはメトリックの追加が含まれる場合があります。

  • データ処理プラットフォームの信頼性はどのくらいですか?

    データ処理パイプラインの信頼性は、プラットフォームの選択によって異なります。 Logic Apps にはオーケストレーション機能がありますが、Data Factory ほど信頼性が高くない場合があります。 Azure Kubernetes Service (AKS) クラスターでホストされている Data Factory の信頼性特性は異なる場合があります。

    単一インスタンスのセットアップは、障害のポイントと見なされます。 要件を満たすために、複数のインスタンスなどの信頼性機能をサポートするプラットフォームを選択します。

    プラットフォームでは、回復性機能もサポートする必要があります。 たとえば、オーケストレーターは失敗したタスクを自動的に再試行する必要があり、手動で再起動する必要が減ります。

    バッチ処理は、データの鮮度と待機時間の要件に応じて、推論よりも信頼性が低くなる可能性があります。 トレーニングが毎週発生し、処理に 1 日かかる場合は、再試行に十分な時間があるため、不定期の失敗が許容されます。

  • コストの制約はありますか?

    データ処理パイプラインのコスト効率を考慮するときは、不要な費用をかけずにニーズを満たすソリューションを選択することが重要です。 要件が Azure Databricks の高度な機能を正当化しない場合は、Data Factory のようなより経済的なオプションで十分な場合があります。 さらに、Apache エアフローや Apache NiFi などのオープン ソース ツールでは、堅牢な機能を低コストで提供できます。 重要なのは、不要な機能に対する過剰な支出を回避し、機能とコスト効率のバランスを取るプラットフォームを選択することです。

  • ワークフローと処理するデータに関するセキュリティ要件は何ですか?

    セキュリティ、プライバシー、データ所在地の要件について明確にしてください。 たとえば、地理的な規制要件について考えてみましょう。 データが特定のリージョン内に格納および処理されるようにすることで、データ所在地の要件に準拠します。 地域のコンプライアンス規制を満たすために、ヨーロッパ用とアメリカ用など、異なるリージョンに対して個別のパイプラインを実行することが必要になる場合があります。

    データ パイプライン プラットフォームでは、承認された ID のみがワークフロー内の特定のジョブまたはステップにアクセスできるように、ID とアクセス管理をサポートする必要があります。 たとえば、ETL プロセスが複数のワークフローで構成され、そのうちの 1 つが非常に機密性の高いデータを処理する場合、プラットフォームでは、他のワークフローへのアクセスを制限しながら、他のワークフローへのアクセスを制限できる必要があります。 この機能は、異なるデータ感度レベルに個別のプラットフォームを必要とせずに、セキュリティ要件を満たすのに役立ちます。 理想的には、プラットフォームは、効率的で安全なデータ管理を可能にするこのような分離に対する組み込みのサポートを提供する必要があります。

データ処理パイプラインは、検索インデックスまたはモデル トレーニング パイプラインにデータを出力できます。 ユース ケースに応じて、 検索インデックス または 機能ストアのセクションを参照してください。

検索インデックスに関する考慮事項

検索インデックスは、プロンプトと共にモデル推論エンドポイントに送信するコンテキストデータまたはグラウンド データを格納するように設計されています。 インデックス クエリと推論エンドポイント呼び出しの両方が、同じクライアント HTTP 要求にサービスを提供するコンテキストで行われます。 オフライン ジョブとバッチ ジョブを処理する ETL プロセスとは異なり、このインデックスではリアルタイム推論がサポートされており、高いパフォーマンスと信頼性が必要です。 これは AI クエリに特化しており、ビッグ データ ストアの一般的ではないキーワード インデックス作成やフィルター処理などの機能を提供します。 目標は、即興クエリとあいまいクエリをサポートする高パフォーマンスの write-once、read-many データ ストアを用意することです。 このデータ ストアは、正確なクエリなしで関連する結果を提供できます。

機能要件

  • 検索インデックスはどの種類の検索をサポートしていますか?

    システムが受け取るクエリは基本的に検索であり、インデックスは豊富な検索機能をサポートする必要があります。 RAG の場合、データは計算ベクターとして格納されるか、または検索に使用される埋め込みとして格納されるため、ベクター検索はネゴシエートできません。

    ベクター検索は強力であり、フィルター処理とフルテキスト検索と組み合わせることで、検索インデックスの有効性が向上します。 データ設計では、ベクター、フルテキスト検索、フィルター処理、地理位置情報などの特殊なデータ型など、これらの種類の検索を組み合わせることを考慮する必要があります。

    データ設計では、これらの要件を明示的に示す必要があります。 詳細については、「 データ設計での効率的なクエリの実行」を参照してください。

  • インデックスはマルチモーダル データをサポートしていますか?

    マルチモーダル データをサポートするインデックス テクノロジを選択します。 たとえば、AI 検索では、電子メールを分析し、その中の画像をベクターに変換し、説明をインデックスに格納できます。 この関数を使用して、画像、ビデオ、オーディオ ファイルなど、さまざまなコンテンツ モダリティを検索します。

  • インデックスは、データ ソース内のデータが変更されたときに自動更新機能をサポートしていますか?

    自動更新機能を持つインデックスを選択します。 使用できない場合は、インデックスに対する変更を手動で検出してプッシュする必要があります。 これらの機能を使用すると、インデクサーはデータ ソースの変更を検出し、更新プログラムを自動的にプルできます。 この責任をプラットフォームにオフロードすることで、運用オーバーヘッドを削減し、メンテナンス プロセスを簡略化できます。

非機能要件

  • インデックスは大量のデータで実行できますか?

    インデックスは、大量のデータを処理し、スケーラブルで、大量の検索ワークロードに対して適切に実行できる必要があります。 インデックスには、生データと、それに関連付けられているすべてのメタデータ、エンリッチメント、エンティティが格納されます。 RAG パターンのコンテキストでは、複数のチャンクに分割された 1 つのドキュメントによって、データ 量が大幅に増加する可能性があります。

  • インデックスには信頼性機能が組み込まれていますか?

    推論エンドポイントまたはモデルの信頼性と、相互に依存するデータ ストアの間の整合性を考慮してください。

    検索プロセスには、データ ストアのクエリと推論エンドポイントのクエリの 2 つの手順が含まれます。 どちらの手順も、同様の信頼性特性を持つ必要があります。 両方のコンポーネント間で信頼性目標のバランスを取り、検索の有効性を確保します。

    回復性を確保するために、ワークロードは予想される同時ユーザー数をサポートし、トラフィックの急増を処理するのに十分な帯域幅を備える必要があります。 理想的には、プラットフォームはゾーンの停止を乗り切る必要があります。

    データ プラットフォームは、推論に破損したインデックスを使用しないように設計する必要があります。 このような場合は、インデックスを簡単に再構築できる必要があります。 インデックスでは、インデックスのスワップ中のダウンタイムを最小限に抑えるためにエイリアス化などの機能を使用して、インデックス間の信頼性の高いスワップもサポートする必要があります。 この機能がないと、インデックスのバックアップに依存することが必要になる場合があります。 バックアップの管理には、より複雑さが伴います。

    ワークロードの観点から、潜在的な障害モードやストレス インジケーター (調整など) を理解します。 たとえば、システムは通常、50 人の同時ユーザーをサポートする場合がありますが、バックグラウンド ジョブとして実行されるインデックス再作成プロセス中にサポートするユーザーは 30 人に限られます。 その場合、バックグラウンド ジョブのタイミングが重要になります。 インデックスのスループットを評価する場合は、フロントエンド クエリとバックエンド ジョブの両方を含めます。

  • このテクノロジの主なコスト 要因は何ですか?

    コストをモデル化するときは、データの量、クエリの数、およびインデックスの予想スループットに関連付けられている経費を見積もります。 インデックスは主にサービスとしてのプラットフォーム (PaaS) であり、価格が抽象化されていることに注意してください。 未使用の容量や機能に対する過剰な支払いを避けるために、階層とその機能を調査します。

    たとえば、AI Search はユニットとして課金され、容量、スループット、ストレージを含めることができます。 追加の機能により、料金が増える可能性があります。 たとえば、画像抽出機能を広範に使用すると、課金が高くなる可能性があります。 インデックスの範囲外にあるがデータ処理の一部である依存関係 (スキル セット機能など) では、追加コストが発生する可能性があります。

    完全な容量を使用せずにレベルに対して支払うと、過剰な支払いにつながる可能性があります。 同様に、インデックス内のテーブルの数と同時トラフィックを処理する機能は、コストに影響します。

    AI Search に関連するコストを理解するには、「 AI Search サービスのコストを計画および管理する」を参照してください。

  • インデックスのセキュリティ機能は、セキュリティ データ設計を満たしていますか?

    データ設計では、セキュリティとプライバシーの要件を明確に指定する必要があります。 実際の実稼働データが使用される開発環境とテスト環境では、インデックスは、すべてのアクセス制御と追跡可能性の測定に準拠する機能をサポートする必要があります。 データ マスクやインデックス内の個人情報の削除などのセキュリティ機能を確認します。

    Microsoft Entra ID を使用してクライアントを一意に識別できるインデックスを選択します。 検索インデックスでは、ID による関連性のクエリを実行できるように、ドキュメント レベルのアクセス制御もサポートする必要があります。 インデックスでこれらの機能が提供されない場合は、クエリ フィルターを使用して同様の機能を実現するように設計を調整します。 詳細については、「 AI Search で結果をトリミングするためのセキュリティ フィルターを参照してください。

    理想的には、検索インデックスはネットワーク セキュリティ要件と一致している必要があります。 たとえば、Microsoft 以外のサイトへのエグレス トラフィックをフィルター処理し、監視を維持する必要がある場合、インデックスはエグレス制御を提供する必要があります。 また、ネットワークのセグメント化もサポートする必要があります。 バックエンド コンピューティングが仮想ネットワーク内にある場合、パブリック インターネットへの公開を回避するには、インデックスを含むキー コンポーネントのプライベート接続が不可欠です。 インデックスはプライベート ネットワークと簡単に統合し、Microsoft Entra ID を介した認証のマネージド ID をサポートする必要があります。

機能ストアに関する考慮事項

判別モデルの場合、データ設計には、追加の絞り込みのためにデータをキャッシュする中間データ ストアが含まれる場合があります。 このストアは機能ストアと呼ばれ、データ サイエンティストは集計データ ストアの外部で、最後の手順として特徴を格納できます。

この機能ストアは、生成時刻や配信元などのメタデータを追加することで、複数の用途のデータをカタログ化するのに役立ちます。 この中間ランディング スポットは、 golden トレーニング データに最適です。

Machine Learning のマネージド Feature Storeは、MLflow やその他のツールと統合されるデータ ストレージ オプションです。 集計データ ストアからデータをフェッチしてトレーニングし、Machine Learning 内でより適切なデータ系列と正式な識別を行う再利用可能なレイヤーを追加します。

機能ストアを使用する場合は、セキュリティとアクセスに関する考慮事項があるデータ ストアのように扱います。

オフライン推論データ ストアに関する考慮事項

一部のシナリオでは、事前に収集および事前に計算されたデータに対して推論が行われるため、将来の参照を高速化するために別のストアを使用することが適切です。 このプロセスでは、ユーザー要求が AI モデルに到達することはありません。 いくつかの利点があります。

  • 待機時間を短縮することで、効率とユーザー エクスペリエンスが向上しました。 結果として FAQ を生成するなど、頻繁にクエリを実行する場合は、結果が高速に提供されます。
  • 推論呼び出しは、リアルタイム処理の制約なしに、バッチ プロセスとしてより簡単にスケールアウトできます。
  • 事前検証により、運用環境の前に精度を確保できます。
  • 要求は干渉エンドポイントに送信されないため、負荷が軽減され、ワークロードの信頼性に寄与します。
  • リアルタイム処理に必要な高パフォーマンスハードウェアの必要性が軽減されるため、コスト効率が向上する可能性があります。

ただし、この方法は、可能性のある要求 予測できる場合にのみ有効です 予測のかなりの部分がユーザーによって要求されることが予想されます。 繰り返し要求が少ないシナリオでは、オフライン推論ストアの効果が低下する可能性があります。

このシナリオのデータ ストアは、読み取り操作用に最適化する必要があります。大量のデータを処理し、効率的な取得を提供できる必要があります。 また、集計されたデータ ストアに統合することもできます。 Azure Cosmos DB やテーブル ストレージなど、これらの機能を備えた任意のストアを考慮できます。

リソース

これらの記事では、この記事で説明する考慮事項のテクノロジ オプションとして推奨される Azure 製品の詳細について説明します。

次のステップ

設計領域: MLOps と GenAIOps