Amazon Quick Chat のマルチデータセットトピックのベストプラクティス

Amazon Quick Sightのマルチデータセットトピック機能により、分析チームは複数のデータセットを1つのトピックに取り込み、自然言語駆動のデータ探索の新たな道を開くことができます。従来、テーブル間のクエリには、データエンジニアが事前にテーブルを結合し、単一のデータセットを提供する必要がありました。現在、Quick Sightは2つの方法を提供しています。明示的な関係キーの定義（別のブログで説明）または、生成AIエンジンに十分なセマンティックコンテキストを装備して、自身でSQLを記述させる方法です。この記事は後者の方法、チャット駆動のAI生成SQLに焦点を当てています。

チャット用のトピックを設定する場合、事前に関係を定義する必要はありません。代わりに、データセットレベルのカスタム指示、トピックレベルの指示、フィールド同義語、フィールド記述を含むセマンティックレイヤーを作成します。AIはそのコンテキストを使用して、クエリ時にコンテキストを認識したSQLを生成します。これにより、外部結合、ユニオン、サブクエリ、自己結合、クロスグレイン比較、条件付き結合ロジックがすべて可能になり、関係グラフに構造的な制約はありません。

この記事は、自然言語のチャットベース探索のためにQuick Sightトピックを構築または最適化するデータアーキテクト、BIエンジニア、分析エンジニアを対象としています。以下の内容が得られます。チャット駆動のSQL生成と定義済み関係トピックの違い、AIを導くすべてのメタデータを構造化するための階層的フレームワーク「セマンティックガイダンススタック」、例とアンチパターンを含む8つの具体的なベストプラクティス、外部結合、多対多、再帰的階層、ロールプレイングディメンション、クロスグレイン比較などの複雑なパターンを処理する手法、定義済み関係、セマンティックのみのガイダンス、ハイブリッドアプローチを選択するための判断フレームワーク、および5つのデータセットを使用した小売分析トピックの完全なエンドツーエンドのウォークスルー。

チャットと定義済み関係の違い

ベストプラクティスに進む前に、Quick Sightの2つのマルチデータセットモードの基本的なアーキテクチャの違いを理解することが役立ちます。トピックで明示的な関係を定義すると、Quick Sightは論理的な結合グラフを構築し、クエリ時に内部結合を実行します。グラフは有向非巡回グラフ（DAG）である必要があり、最大12データセットをサポートし、結合パスが事前に指定されているため決定論的な結果を生成します。これは、テーブルをどのように組み合わせるかを正確に強制する必要がある、管理されたレポートシナリオに適しています。

ユーザーがチャットで質問すると、Quick Sightの生成AIは定義された関係またはトピックのセマンティックレイヤー（指示、説明、同義語）を読み取り、その質問に答えるSQLを生成します。AIは、どのデータセットをクエリするか、どの列を使用するか、適切な結合タイプ、結果をどのように集計するかを決定します。事前に配線された結合グラフはありません。AIは構造ではなく意図に基づいて動作します。

定義済み関係はガードレールです。誤った結合が試行されるのを防ぎます。セマンティックメタデータはガイダンスです。AIを正しいコンテキストに適したSQLに導きます。どちらにも価値があり、適切な選択はシナリオによって異なります。後述の判断フレームワークのセクションを参照してください。

定義済み関係とセマンティックガイダンスは相互に排他的ではありません。ハイブリッドトピックでは、コアなファクトからディメンションへの結合には関係を定義し、事前定義グラフの範囲外の探索パターンにはカスタム指示を使用できます。

セマンティックガイダンススタック

Quick Chatを駆動するAIエンジンは、SQLを生成する際に7層のメタデータを利用し、これらがまとまってセマンティックガイダンススタックを形成します。各層を理解することは、効果的なメタデータを作成するための基礎です。

• 第1層：データセット出力；データセット——データセットレベルの指示：各データセットの粒度、目的、キー、ビジネスルールを定義します。
• 第2層：トピック——トピックレベルの指示：データセット間のロジック、曖昧さ回避ルール、デフォルトの結合動作を定義します。
• 第3層：データセット出力；フィールド——同義語：ビジネス用語を技術フィールド名にマッピングします。
• 第4層：データセット出力；フィールド——フィールド記述：列のセマンティクス、単位、NULL可能性、有効範囲を説明します。
• 第6層：データセット変換——列の除外：内部キー、ETLタイムスタンプ、廃止されたフィールドなどのノイズを除外します。
• 第7層：データセット変換——計算フィールドと名前付きフィルター：AIが直接参照できる一般的なビジネスメトリクスとセグメント定義を事前構築します。

各層は、データに関するAIの不確実性を低減します。各層をより正確に設定するほど、妥当なSQL解釈の範囲が狭まり、生成される結果の精度が向上します。多くのデータセットを持つトピックがまばらに記述されていると、信頼性の低い結果が生じます。これはAIの能力不足ではなく、正しい選択を行うために必要な情報が欠けているためです。

ベストプラクティス1：データセットレベルの指示をデータ辞書として記述する

データセットレベルのカスタム指示は、AIが各テーブルに最初に接触するポイントであり、そのデータセットに関連するすべての質問のコンテキストを設定します。含めるべき内容：テーブルの目的と粒度、主キー、外部キーヒント、ビジネスルール、既知のエッジケース、集計ルール。

例えば、SALES_FACTデータセットの場合、良い指示は次のように明確にします。「SALES_FACTは注文明細行ごとに1行を含む。主キー：order_line_id。粒度：1明細行＝1注文の1製品。主要列：order_idはORDER_HEADER_DIM.order_idにリンク、等。収益＝数量*単価－割引額。常にSUM収益。order_status='VOID'の行は収益計算から除外。テーブルは毎日UTC 02:00に更新。」

避けるべきアンチパターン：あまりに一般的な指示、生のSQLスニペットの埋め込み、矛盾するルール。

ベストプラクティス2：トピックレベルの指示でデータセット間ロジックを記述する

トピックレベルの指示は、テーブル間の関連性、用語が曖昧な場合の優先データセット、データセット間の計算の処理方法をAIに伝えます。含める内容：概念的な関係、曖昧さ回避ルール、デフォルトの結合方向、複数ファクトの解決、広範囲のビジネス定義、階層ナビゲーション。

例えば、小売分析トピックの指示ブロックでは以下を指定できます。「SALES_FACTとRETURNS_FACTはどちらもcustomer_idでCUSTOMER_DIMに、product_idでPRODUCT_DIMにリンクする。ユーザーが「売上」を尋ねたらSALES_FACTを、「返品」または「払い戻し」を尋ねたらRETURNS_FACTを、「純売上」には両方を結合する。ファクトテーブルからディメンションテーブルへのLEFT JOINを優先し、一致するディメンションレコードがないファクトがサイレントに削除されないようにする。」

この記事では、同義語の使用、フィールド記述、列の除外、計算フィールド、複雑なパターンの処理、判断フレームワークなど、さらに多くのベストプラクティスと、5つのデータセットを使用した完全な小売分析トピックのエンドツーエンドのウォークスルーを提供しています。