Azure での AI ワークロードの基礎データ設計

AI アプリケーションの場合、データ設計に対する適切に設計されたフレームワークのアプローチでは、操作性、コスト、セキュリティなどの機能以外の要件に対処し、 Azure Well-Architected Framework の柱の主要な原則に従う必要があります。 また、データ インジェスト、準備、検証などの機能要件も考慮する必要があります。

選択した AI モデルは、後続のデータ設計の決定に影響します。 この記事では、結果の関連性を高めるために拡張が必要な基礎モデルのアーキテクチャに関する重要な考慮事項について説明します。 通常、これらのモデルは生成型です。

生成 AI モデルは事前構築済みまたは事前トレーニング済みであり、変更を加えずにすぐに使用できます。 ただし、すぐに使用するモデルは、多くの場合、特定のワークロード要件を満たしていません。 この問題に対処するために、モデルはコンテキスト固有のデータで拡張され、パフォーマンスが向上します。 たとえば、さまざまなユース ケースで GPT モデルを使用できます。 これらのアプリケーションには、ドキュメントからの情報の取得、IT ヘルプデスク サポートの提供、複雑な情報の要約が含まれます。 基礎モデルを使用して特定のニーズを満たすには、これらの考慮事項を理解することが重要です。

ソリューションでは、生成型 AI モデルと判別型 AI モデルの組み合わせを使用して、ワークロードの要件を満たすことができます。 トレーニング データの詳細については、「 データ設計のトレーニング」を参照してください。

推奨事項

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

データの型

推論中にコンテキスト データを使用して生成 AI モデルを拡張したり、微調整プロセスを通じてさらに最適化したりできます。 どちらの方法でも、モデルにより多くのコンテキストを提供する補助データが必要です。 モデルでは、そのコンテキストを使用してユーザー クエリに応答し、期待に応じて回答を形成します。 通常、次のデータ型を使用します。

• ソース データ は運用環境の既存のデータです。 このデータは、データベース内のデータなど、構造化することも、JSON ファイルのように半構造化することもできます。 また、ドキュメント、画像、オーディオ ファイルなど、非構造化化することもできます。

• グラウンド データ は、モデルの初期トレーニング データで説明されていないトピックに関する情報を含むソース データから取得されます。 グラウンド データはユーザー クエリと組み合わされ、特定の推論呼び出しのコンテキストで大規模な言語モデルに送信されるプロンプトが形成されます。 推論呼び出しに含めることができるその他のデータは、システム プロンプト、一発または少数の例、以前の操作などのコンテキスト データです。

  このデータは、簡単に検索でき、迅速に取得できる必要があります。 この要件のため、検索用に最適化されたインデックスにデータを格納する必要があります。 このインデックスは、ユーザーが回答を待っている間にリアルタイムでアクセスされます。 このデータがないと、モデルによって正しくない結果が生成されたり、ユーザーが具体的に求めているものに適用できない可能性があります。

• データの微調整 は、特定のタスク、ドメイン、または応答スタイルに適応して将来の推論要求に対応できるように、モデルに影響を与えるために使用される情報です。 たとえば、モデルが特定の文法スタイルで回答を提供することが予想される場合、そのスタイル ガイドは微調整データとして機能します。

• ユーザー データ には、アプリケーションとの対話中にユーザーが提供する情報が含まれます。 生成モデルを操作すると、ステートフルな相互作用が発生します。 これらのモデルには固有のメモリがなく、各相互作用をアトミックとして扱います。

  チャット アプリケーションでステートフルな操作 ( TURN データ とも呼ばれます) を管理する場合は、必要な最短時間でデータを格納することが重要です。 理想的には、このデータはセッション終了後に破棄する必要があります。 ただし、セッションの期間を超えて、元の質問やモデルの応答など、特定のデータを保持する必要がある運用上またはコンプライアンス上の理由がある場合があります。 可能な場合は、セッションの後にこのデータを格納しないでください。

インデックス作成

データ設計の中核となるのは、基礎データの効率的な格納と管理です。 このアプローチにより、データを拡張して最高レベルの関連性を実現できます。

単純な AI 戦略では、ユーザーの操作ごとにソース データのクエリを実行する必要があります。 ただし、この方法は、直接的なデータ ソース操作のコストと複雑さが高いため、実用的ではありません。 代わりに、検索と取得用に最適化されたインデックス内のコピーとしてソース データを再利用する必要があります。 このアプローチの目的は、モデルの理解度と、関連する応答を生成する能力を向上することです。

ユーザーの銀行口座と設定、金融取引に関連する詳細をデータ ストアに格納する銀行業務ワークロードについて考えてみましょう。 RAG パターンを使用する生成 AI シナリオでは、モデルが関連する応答を提供できるように、グラウンド データが作成され、コンテキストでインデックスが作成されます。 たとえば、推論中にコンテキストのユーザー トランザクションに関する関連データを提供することで、モデルは前四半期のユーザーの支出パターンに関連する質問に回答できます。

特殊なインデックス テクノロジ

グラウンド データを検索インデックスに外部化することを検討してください。 ソース システムから直接クエリを実行する代わりに、この方法を使用します。

検索インデックスを使用する利点があります。 予想されるクエリに従って、データのコピーをモデル化および変換できます。 ソース データにアクセスできない可能性があるため、プライマリ ソースに直接クエリを実行すると問題が発生します。 インデックスを使用すると、データがアプリケーションに関連していると見なされる限り、データを引き続き使用できます。 また、ソース データ システムに負荷をかけないようにします。 この戦略により、AI 関連のクエリがその主要なユース ケースに影響を与えないようにします。

一部のテクノロジ オプションには、セルフインデックス機能があります。 インデックスはデータ ソースにアクセスし、そのデータを組み込むことができます。 このオプションでは、ネットワークに関する考慮事項が重要です。 インデックスをデータベースに接続する必要がある場合は、ネットワーク待機時間や信頼性など、潜在的な問題があります。

データをインポートするには初期コストがかかります。 データがインデックスに含まれると、変更や更新がない限り、データを再度移動する必要はありません。 時間の経過に伴うデータ管理は、インデックス設計の重要な側面です。 詳細については、「 Index のメンテナンス」を参照してください。

既定のインデックスまたはカスタム インデックス

特定のテクノロジでは、データの既定のインデックスの自動作成がサポートされています。 このインデックスは、最小限の入力でデータ インジェストで生成されます。 インデックスには、すぐに使用する機能があります。 既定のインデックスは、概念実証や一部の運用シナリオで許容される場合があります。

シナリオによっては、特定のワークロード要件に基づいて関連性を向上させるために、カスタム インデックス スキーマが必要になる場合があります。 これらの要件によって、スキーマの設計方法、インデックス機能の有効化、関連するメタデータの含め方が決まります。

スキーマの設計

インデックスは、データを整理して取得用に最適化する構造と考えることができます。 具体的には、テーブルのドキュメントとフィールドのデータを整理します。 次の点を考慮してください。

• インデックス トポロジ。 1 つのインデックス内のすべてのデータを併置するか、複数のインデックスに分散するかを評価します。 この決定は、クエリのパフォーマンス、インデックスのメンテナンス、クエリの簡略化、ドキュメント間のフィールド構成 (またはスキーマ) の違いに大きく影響します。

  たとえば、特定の言語でコンテンツを要求するユーザー クエリについて考えてみましょう。 最も簡単なデータ設計の選択肢は、すべての言語を 1 つの言語に翻訳し、1 つのインデックスに格納することです。 または、すべての言語のデータを 1 つのインデックスに格納できます。 この選択により、言語ごとに複数のドキュメントが作成されます。 インデックスのフィルター機能を使用して、結果を目的の言語に制限できます。 また、各インデックスには、クエリで想定どおりに特定の言語の翻訳されたバージョンが含まれる場合があります。

  状況によっては、複数の検索インデックスが必要になる場合があります。 この方法では、検索クエリからの関連性を最大限に高めるために、各インデックスを個別に最適化できます。 たとえば、人事部の従業員ハンドブックと製品メンテナンス マニュアルは、さまざまな目的と対象ユーザーに役立ちます。 個別にインデックスを作成することで、スキーマと検索クエリをそれぞれ調整できるため、ユーザー エクスペリエンスが向上します。 この方法は実装が複雑な場合があり、各インデックスの呼び出しを容易にするためにオーケストレーターが必要です。 オーケストレーション コンポーネントについては、「 Azure での AI ワークロードのアプリケーション設計で説明されています。

• ドキュメントデザイン。 データ設計を予想されるユーザー クエリに合わせて調整し、関連性を最適化します。 各ドキュメントでクエリを処理する方法を検討します。 検索インデックスの場合は、関連するドキュメントに優先順位を付け、関連情報が密集した簡潔なセットに結果を絞り込みます。

• フィールドデザイン。 検索のパフォーマンスと関連性をサポートするようにインデックス フィールドを構成します。 インデックス フィールドは、検索可能、取得可能、フィルター可能、並べ替え可能にするドキュメント属性にマップする必要があります。 これには、埋め込み、ID、または検索を促進できるその他のデータが含まれます。

インデックス機能

最も関連性の高いドキュメントセットを返すように検索インデックス フィールドを構成します。 決定は、検索インデックス テクノロジとワークロード要件でサポートされる機能によって異なります。

• フィルター、検索、並べ替えのオプション。 これらのオプションは、拡張のユース ケースに直接関連しているため、検討してください。 たとえば、 filterable は、クエリで指定された値に対して true または false を判断し、関連するドキュメントを返します。 検索可能性属性は、検索クエリがフィールドを参照できるかどうかを示します。 たとえば、テキスト フィールドに特定のテキストが含まれているかどうか、または別のベクターに数学的に関連しているかどうかを確認できます。 必要に応じて、検索クエリの一部として、そのフィールドに相対的な重みを割り当てることができます。 結果セットを 並べ替え可能にして、関連性別に結果を一覧表示することもできます。

  Tradeoff. フィールドにインデックスを付ける機能を有効にすると、領域の要件が増え、コストに影響します。 使用する機能のみを追加します。

• メタデータ。 インデックスには、通常、インデックス フィールドに関連付けられたメタデータがあります。 メタデータは、データに関する関連する詳細を提供することで、データの理解と管理に役立ちます。 インデックスを設計する場合は、メタデータが取得可能か、関連性の判断にのみ使用されるかを検討します。 基になるインデックス作成プロセスが異なるため、この決定はコンピューティング コストに影響します。 過剰なメタデータを使用すると、インデックスのサイズが不必要に大きくなる可能性があります。

インデックス作成には多くのテクノロジの選択肢があります。 多くは、前に示した特性など、同様の特性を共有します。 一部のインデックスには、インデックス作成中のテキストの処理や言語分析などの追加機能が含まれます。 テキストのインデックス作成と検索に適したテキストにするには、テキストをトークンに分割するか、小文字に変換するか、ストップ ワードを削除します。

効率的なクエリ

グラウンド データは、ユーザー クエリに対する応答の精度と関連性を高めるために、生成 AI アプリケーションで使用されます。 ユーザー クエリを事前に検討してください。 どのような質問が可能か、誰が質問し、どのくらいの頻度で質問されるかを理解します。 この情報は、アプリケーション フォームのコンテキストと、関連する可能性のある結果を理解するのに役立ちます。

一般的な検索の種類は次のとおりです。

• ベクター クエリ 高次元空間内のベクター表現またはデータ ポイントに基づいて同様の項目を検索します。

• キーワード検索 テキスト ドキュメントのコンテンツ全体を検索します。 大量のテキスト データのインデックス作成とクエリが行われ、検索エンジン、データベース、ドキュメント管理システムでよく使用されます。

• セマンティックランク付け クエリに対するセマンティック関連性に基づいて検索結果を並べ替えることで、検索結果の関連性を向上させ、最も意味的に関連性の高い一致をリストの一番上に昇格させます。

• ハイブリッド検索 は、ベクター検索、フルテキスト検索、セマンティック ランク付けなど、さまざまな検索の種類を組み合わせて、検索結果の関連性をさらに向上させます。

モデルのパフォーマンスをさらに向上させるには、検索の種類を組み合わせます。

データを格納して処理する方法は、クエリの効率に影響します。 インデックスにデータが追加されるたびに、インデックス作成にはコンピューティング サイクルが必要です。 同じコンピューティング リソースに対してインデックス作成とクエリへの応答が行われると、競合が発生する可能性があります。 インデックスは、過剰なインデックス作成ではなく、クエリに効率的に応答し、関連するドキュメントを検索するという主な目標に焦点を当てるのが理想的です。

コストとパフォーマンスは、インデックス設計の重要な要因です。 シャドウ コピーの作成などの手法を使用すると、クエリを高速化できます。 ただし、データの重複はインデックスによって発生し、コストが発生します。

Tradeoff. インデックスの設計では、コストとパフォーマンスの両方を考慮する必要があります。 ストレージを最適化し、過剰なインデックス作成よりも効率的なクエリ応答と関連するドキュメントの取得に優先順位を付けることで、バランスを取ります。

データ ストアのテクノロジの選択肢として、Elasticsearch や AI Search などの検索インデックスは、ベクター化された関連性ベースの検索を含む強力な検索機能を提供します。 または、持っているデータの種類と必要なクエリの種類をサポートするデータベース オプションは、クエリ用に最適化されているため検討してください。 最終的には、チームに新しいスキル セットを構築するオプションと投資によって提供される機能についてです。

データ準備

グラウンド データは、セマンティック クエリに適した既存のデータに基づいています。 インデックス内の関連するドキュメントを検索するクエリの中には、リテラル 一致を指定できるものもあります。 その他のクエリでは、あいまい一致が必要です。

コンテキスト データがモデルへの推論要求をサポートする準備が整う前に、データのクリーニング、変換、構造化を目的とした事前の前処理手順があります。 目標は、ノイズとバイアスを減らし、効率的に検索し、インデックス検索の関連性を最大化することです。 前処理の選択ツールまたはロジックはワークロード チームによって異なりますが、いくつかの大きな考慮事項があります。

データ ボリュームのスコープ設定

データ ボリュームのスコープを設定するには、データの範囲を拡大または縮小して、関連性を高めるために厳密なインデックスを作成する必要があります。 クエリの効率は、もう 1 つの重要な懸念事項です。 不要なデータを格納すると、両方の目標に悪影響を及ぼします。 たとえば、ユーザーの位置情報データを考えてみましょう。 市区町村の部分のみが関連する場合は、住所を表すフルテキストではなく、市区町村のテキストのみを格納して最適化します。

以下に、いくつかの大きな考慮事項を示します。

• データの削除。 製品の機能に不可欠なものだけを保持し、不要な詳細を破棄します。 一般的な例を次にいくつか挙げます。

  • 定性的排除。 広い範囲からより狭い相対的な範囲に移行する 1 つの方法は、関連するソース データのインデックスを選択するだけで、低品質のデータを排除することです。 課題は、AI シナリオに関連しないコンテンツをプログラムで識別することです。 コンテンツは、監査や完全性などの他の意図に役立ちますが、AI ワークロードに含めると、関連性が低下するリスクがあります。 このようなコンテンツにフラグを設定する 1 つの方法は、コンテンツをインデックスに追加する必要がある場合にインデックス作成時に使用できるメタデータを使用することです。

  • 機密データ。 ソース データからインデックスにデータをコピーすると、機密情報が引き継がれる場合もあります。 ソースで適用されるデータ分類ラベルを尊重し、このデータ セットに対して同じレベルの感度を維持します。 個人情報を含むデータを処理する場合は、クエリに応答する必要がない限り、個人データを格納しないでください。 たとえば、電子メールのインデックスを作成するときにデータ分類を適用します。 電子メールに機密性の高いフラグが設定されている場合は、一般的な秘密度データ ストアに保存しないでください。

  • テキストの正規化と標準化。 入力ミスに対処し、テキストを標準化することは、キーワードベースのインデックスにとって非常に重要です。 潜在的なユース ケースは、特に多言語コンテンツを扱う場合の翻訳です。

    この種の前処理は埋め込みにも必要です。これにより、コンテキストと意味に基づいて単語を比較できます。 ただし、単語の大文字と小文字の区別から 1 つの課題が発生します。 文脈上の問題であり、形容詞の「市民」と固有名詞「(ホンダ)シビック」の間には意味的な違いなど、微妙な違いがある可能性があります。

• データの追加。 多くの場合、拡張コンテキストはメタデータに依存しますが、通常はソース データには存在しません。 たとえば、テキスト スニペットを考えてみましょう。 ループまたは AI の人間は、スニペットのコンテキストを使用して回答できる関連する質問を作成します。 これらの質問をグラウンド データと共に格納すると、生成されたクエリとユーザー クエリを比較してドキュメントの関連性を評価できます。 この新しいデータとグラウンド データの併置は、チャンクされたデータをエンリッチする強力な方法です。

  もう 1 つのユース ケースは、非構造化データの分析中に見つかった追加エンティティです。 これらのエンティティをインデックスに追加し、外部システムの検索とフィルター処理に使用したり、複雑な計算を実行するために使用したりできます。 たとえば、会社名を特定した場合、外部データベースから業界やその他の関連情報を検索し、インデックスに追加することがあります。

  データ系列を維持することを検討してください。 AI ワークロードでは、さまざまなコンポーネントを 1 つのインデックスに集計すると情報が失われる可能性があるため、データのソースを追跡することが重要です。 この情報はユーザーに公開されることはありませんが、データの起源に関する情報は、内部データ ガバナンス チームにとって非常に重要です。 このメタデータは、必ずしもモデル用であるとは限りません。 透明性と説明責任を維持するのに役立ちます。

  Tradeoff. 一方、新しいデータを追加すると、データセット内の関連性を見つける可能性が高くなります。 ただし、この特典にはコストがかかります。 具体的には、そのフィールドの処理と管理に必要な計算リソースです。 データの収集と格納に費やされる時間は長い場合があります。 不要なフィールドでオーバーロードすると、リソースが負担される可能性があることに注意してください。

• テキスト データの処理。 関連性を高めるために、シノニム、ステミング、セマンティック近接性などの手法を検討します。 可能であれば、これらの手法をツールに委任します。 Elasticsearch や AI 検索などの一部のテクノロジでは、インデックスの作成時にデータを前処理するためのこのような機能が提供されます。

データ型のモーフィング

データストア内のインデックス フィールドは、特定の目的を果たすデータ型です。 数値フィールドは、効率的なクエリを容易にし、テキスト フィールドはテキストベースの検索を可能にし、ブール型フィールドはバイナリ情報を処理します。

ソース データは通常、テキスト、画像、テーブルなどのさまざまな種類のデータに存在し、そのデータの処理は複雑になる可能性があります。 キーと値のペアの抽出、セマンティック チャンクのセクション見出しの識別、特定の識別子の認識などが必要になる場合があります。

たとえば、ソース データに画像が含まれている場合、本質的に検索できません。 効率的なセマンティック検索と比較を可能にするには、ベクター表現に変換する必要があります。 これらの形式の背後にあるデータに関連性が関連付けられている場合は、データの抽出に投資します。 ソース データ型を、クエリと分析に役立つ機能データ型に変換します。

チャンクと埋め込み

多くの場合、グラウンド データには大量の情報が含まれていますが、モデルでは一定量のみをトークン化できます。 チャンク は、ドキュメントを個別に処理してインデックスを作成できる小さな部分に分割する必要があるため、重要なデータ設計戦略です。 この戦略により、トークンの制限にもかかわらず効率的な検索と取得が可能になります。 選択した大規模言語モデルで処理できるトークンの最大数を確認します。 チャンクがその制限を超えないようにする必要があります。

チャンクを実装する方法は多数あります。 詳細については、「 Chunking アプローチ」を参照してください。

埋め込み は、ベクター検索機能を有効にするもう 1 つの設計戦略でもあります。 埋め込みは、接地データに基づいて AI モデルによって生成されるオブジェクトの数学的表現です。 これらはインデックスに格納され、複雑なクエリにより関連性の高い結果が得られるのに役立つコンテキストが追加されます。 詳細については、「埋め込みの生成」を参照してください。

インデックスのメンテナンス

時間の経過に伴うメンテナンスは、インデックス設計の重要な側面です。 ドキュメントが変更されない静的データの場合、インデックスのメンテナンスは簡単です。 ただし、ほとんどのインデックスは動的です。 時間の経過と同時に、新しいデータが追加され、インデックス スキーマに新しいフィールドが必要になる場合があります。 逆に、一部のデータとフィールドは、関連性がなくなった場合は削除する必要があります。 インデクサーでよく使用されるテクノロジ オプションには、更新プログラムを自動的に処理する機能があります。 推奨されるインデックス特性の詳細については、「 検索インデックスの概要」を参照してください。

メンテナンス条件

• 機能の更新。 アプリケーションの機能に変更がある場合は、インデックスの更新が必要になる場合があります。 この状況は、新しい質問が行われるときに発生します。 これらの変更に対応するには、インデックスに新しいフィールドを追加するか、既存のフィールドのフィルター処理、検索、またはテキスト処理のオプションを変更することが必要になる場合があります。

• データの削除。 データの削除は、無関係なものを特定するために、使用可能なデータと不足しているデータを分析する必要があるため、困難です。 インデックスから古いコンテンツを除外するには、検索エンジンが特定のページまたはコンテンツのインデックスを作成できないようにするメタデータの使用を検討してください。 また、ストレージ オプションを選択する場合は、削除を効率的にサポートするテクノロジを選択します。 たとえば、BLOB ストレージでは論理的な削除がサポートされています。 AI 検索を使用してストレージからドキュメントを読み込む場合、BLOB ストレージは削除されたドキュメントを検出し、対応するエントリを削除できます。 この方法は理想的ではありませんが、インデックスのサイズが大きいためインデックスの再作成にコストがかかる場合に必要です。

  忘れられる権利の概念はオンライン プラットフォームまたはデータベースから個人データを削除する個人の権利を指します。 トレーニングに使用された個人データを削除するポリシーが設定されていることを確認します。 この要件に対処するには、データ セットのインデックスを再作成します。 トランザクション データベースからデータが削除された場合、後続のインデックスの更新にはそれらの変更が反映されます。

• 互換性の維持。 多くの場合、アプリケーションには特定のデータ構造が必要であり、どの偏差でも機能が中断される可能性があります。 たとえば、フィールドが削除され、アプリケーションがそのフィールドを要求した場合、エラー状態が発生する可能性があります。 従来のデータベースの場合と同様に、インデックスの前方互換性の考え方を採用し、厳しいレベルを維持します。 フィールドの追加や削除など、インデックスに変更を加えた場合は、コードの更新を使用してスキーマの変更を調整します。

  Tradeoff. インデックスに対するアクションの追加、更新、削除はコストがかかります。 データ ストアのサイズと効率に基づいて、更新の頻度とパフォーマンスのコストを検討します。 古いドキュメントをインデックスに保持すると、ストレージ、メンテナンス、クエリのコストが発生します。

展開戦略

デプロイ戦略。 インデックスを更新するための主な方法は 2 つあります。

• サイド バイ サイドデプロイ。 このアプローチでは、更新を含む新しいインデックスが既存のインデックスと共に存在します。 新しいインデックスがテストされ、完全に動作すると、更新されたインデックスを使用するようにクエリが切り替えられます。 アプリケーションは新しいインデックスとのみ対話するため、この切り替えを認識しないままです。 新しいインデックスが運用環境にデプロイされた後で他の問題が検出された場合は、古いインデックスに戻すことができます。 この方法では、ダウンタイムを最小限に抑え、継続的な可用性を確保します。

  サイド バイ サイドの更新は、インデックスの再構築コストが妥当であり、妥当な時間内に完了できる場合に適切に機能します。 一般に、インデックスが大きいほどリソースが消費されるため、インデックスの効率をできるだけ高く保つように努めます。 不必要な増加を避けるために、インデックスを定期的に監視および維持します。

• インプレース更新プログラムの展開。 この方法では、既存のインデックスが直接変更されます。 重複のコストを節約すると有益ですが、ダウンタイムやリソースを集中的に消費する操作が発生する可能性があるため、リスクも発生します。 インデックスが大きく、最初から再構築する頻度が目的の更新頻度を超えている場合は、インプレース更新の使用を検討できます。 ただし、このアプローチは困難であり、サービス レベル目標 (SLO) に違反するリスクを伴います。

  Tradeoff. 追加、更新、削除をデプロイするインプレース更新を行うことに対して、インデックスの並列デプロイを行うコストを評価します。 ほとんどの場合、インプレース更新ではなく、サイド バイ サイド更新を使用する必要があります。 インデックスが再構築されると、プロセスは完全に新しいデータ セットを作成するため、削除と更新を効果的に処理します。 この戦略は、データをテストする機会を提供します。 サイド バイ サイドデプロイでは一時的にデータが重複し、追加のコストが発生しますが、多くの場合、テストとパフォーマンス評価の利点によって、このストレージ要件が正当化されます。 インデックスをライブにする前に、データを調べて、期待に沿っていることを確認します。

• スケジュールされた更新。 データ ソースとの継続的なリアルタイム通信を維持する代わりに、グラウンド データを定期的に更新できます。 この方法により、スケジュールされた更新によってデータが確実に関連し続け、一定の相互作用が不要になります。

• 緊急更新プログラム。 望ましくないデータが誤って検索インデックスに漏えいするなど、予期しない状況が発生する可能性があります。 この問題が発生した場合は、特定のドキュメントの削除やインデックス内のデータの調整など、直ちに対処する必要がある場合があります。 サイド バイ サイドの更新プログラムやインプレース更新プログラムなど、選択した展開戦略に関係なく、常に緊急操作の可能性を計画します。

• インデックスの自己更新。 インデックス作成テクノロジで、インデックスを外部データ ソースとの同期を維持するためにインデックスの自動更新がサポートされている場合は、データの変更を自動的に処理できる可能性があります。 データの変更には、手動による介入なしに追加または削除が含まれます。 すべての変更によってインデックス内の操作がトリガーされ、リソースが消費されます。 インデックスはクエリに対して引き続き応答する可能性がありますが、更新プロセス中にクエリを処理するための容量が減る可能性があります。

Freshness 操作

ソース データの作成または変更とインデックスへの追加の間の時間枠をインジケーターとして測定し、SLO に対して追跡します。 このインジケーターにより、データ パイプライン設計の更新に関するデータの決定が促進され、必要なときにインデックスでデータを確実に使用できるようになります。 インデックスは、必要なだけ新しいインデックスにする必要があります。

鮮度を維持するには、インデックスを完全に再構築するか、元のデータ ソースとの同期を維持するように増分更新します。 どちらの方法でも、インデックスが最新で正確なままであることを確認します。

モデルの微調整に対する初期投資は、RAG パターン、プロンプト エンジニアリング、およびデータ拡張方法を実装するよりもコストが低くなる可能性があります。

次のステップ