会話型分析では、Gemini for Google Cloud を使用して自然言語の質問を解釈します。その際、Looker セマンティック モデル（LookML）、データ値、データ エージェント構成を信頼できる唯一の情報源として使用します。レスポンスの品質は、これらの入力をどれだけ効果的に準備できるかに左右されます。
このガイドでは、LookML デベロッパーと管理者が会話型分析を構成して最適化するための戦略とベスト プラクティスについて説明します。LookML モデル、Explore、データ エージェントに関するこれらの推奨事項に沿って作業することで、ユーザーの導入を促進し、ユーザーが質問に対して正確で関連性の高い有用な回答を得られるようにすることができます。このガイドでは、会話型分析に関連するベスト プラクティスについて、モデルの LookML で強固な基盤を構築し、このモデルに基づいて Explore を構成し、これらの Explore をデータソースとして使用するデータ エージェントを構築するという論理的な流れに沿って説明します。
- 会話型分析の LookML ベスト プラクティス
- 会話型分析で使用する Explore を設定するためのベスト プラクティス
- データ エージェントを構築するためのベスト プラクティス
- LookML とエージェントの指示のどちらにコンテキストを追加すべきか
会話型分析の LookML ベスト プラクティス
会話型分析では、次の主な入力を使用して自然言語の質問を解釈します。
- LookML モデル: エージェントは、接続されている Explore のスキーマを取得します。スキーマには、フィールド（ディメンション、メジャー）、フィルタ限定フィールド（フィルタ、パラメータ）、および Looker Explore の基盤となる LookML モデルで定義されている対応する ラベル、説明、類義語が含まれます。会話型分析で分析される LookML パラメータの完全なリストについては、会話型分析の概要をご覧ください。
- 個別のフィールド値: エージェントはデータ値をサンプリングし、あいまい検索を実行して、基盤となるデータベースで特定のフィールド値をチェックできます。これらの方法により、エージェントは正しいフィールドを選択し、正しいフィルタ値を適用し、ユーザーが質問する可能性のある利用可能なカテゴリとエンティティを特定できます。
会話型分析の有効性は、これらの入力の品質と明確さに直接関係しています。次の表に、不明確または曖昧な LookML が会話型分析に悪影響を及ぼす一般的な方法と、レイテンシを短縮し、出力とユーザー エクスペリエンスを改善するための解決策を示します。
| LookML の品質に関する問題 | 会話型分析を明確にするためのソリューション |
|---|---|
| 明確さの欠如と命名の競合: 明確なラベルがないフィールド、定義が曖昧なフィールド、異なるビュー間で類似した名前を共有するフィールドは、フィールドの選択が誤る可能性があります。 | 明確なラベルと詳細な説明を適用する:
|
| フィールドの肥大化: 内部 ID、結合からの重複フィールド、中間計算など、過剰なフィールドを公開すると、会話型分析で使用できるオプションが煩雑になります。 | 無関係なフィールドを非表示にする: すべての主キー、外部キー、技術フィールドが非表示になっていることを確認します。 （省略可）Explore を拡張する: フィールドが多い Explore の場合は、既存の Explore を拡張して、会話型分析専用のバージョンを作成することを検討してください。 |
| サンプリングと検索のデータベース負荷: データベースからサンプル値と候補を取得するのに時間がかかる場合や、不要な負荷が発生する場合があります。特に、ユーザーがクエリで特定のデータ値を参照する場合に発生します。 | LookML で候補を定義する: 値をハードコードするか、より効率的なディメンションを指定して、フィールド候補のリアルタイム データベース クエリを回避します。
|
| データクエリのデータベース負荷: 大規模または非効率的なクエリは、レイテンシとデータベース負荷を増大させる可能性があります。 | データクエリを最適化する: 集計認識や効率的な結合ロジックの使用など、クエリ パフォーマンスを最適化するための一般的なベスト プラクティスに準拠します。 |
| LookML の定義が不完全: ダッシュボード レベルのカスタム フィールドまたは表計算に依存すると、会話型分析で重要なビジネス ロジックにアクセスできなくなります。 | カスタム ロジックを組み込む: 重要でよく使用される カスタム フィールド または 表計算 を LookML ディメンションとメジャーに変換します。 |
データの不整合: 次のタイプの不整合なデータや構造化されていないデータでは、会話型分析でクエリを正確に解釈することが困難になります。
|
データ品質に対処する: 可能な場合は、データのキュレーション中に特定したデータ品質の問題（値、型、タイムゾーンの不整合）にフラグを設定します。データ エンジニアリング チームと協力して、ソースデータをクリーンアップするか、ETL/データ モデリング レイヤで変換を適用します。 |
LookML の重要なポイント
会話型分析のデータソースとして使用される Explore の LookML を定義する際は、次の点に注意してください。
- 明確で正確なラベルを使用する: ビジネス ユーザーが実際に使用する言葉を反映したラベルをデータに選択します。
"amt_usd_curr"などの技術的な略語は避け、"Amount (USD)"を使用します。 - シームレスなマッピングを有効にする: 類義語と説明を使用して、エージェントがユーザーの質問を正しいフィールドにマッピングできるようにします。
- 計算を一元化する: よく使用される計算を LookML ディメンションまたはメジャーとして直接定義して、信頼できる唯一の情報源を確保し、レイテンシを短縮します。
- コンテキストを効率化する: LookML で技術フィールドまたは内部専用フィールド（外部キーや未加工 ID など）を非表示にして、ビジネス上の質問に回答するために必要なフィールドのみが会話型分析に表示されるようにします。関連するフィールドのみに焦点を当てることで、ノイズが減り、フィールド選択の精度が向上します。
- サンプルデータとあいまい検索クエリを最適化する:
suggestionsパラメータでハードコードされた値を定義するか、suggest_dimensionとsuggest_exploreを使用して、データベース クエリを効率化します。 - データクエリを最適化する: 集計認識や効率的な結合ロジックの使用など、クエリ パフォーマンスを最適化するための一般的な Looker ベスト プラクティスに準拠します。
クリーンで効率的な LookML を記述するためのその他のベスト プラクティスについては、次のドキュメントをご覧ください。
- ベスト プラクティス: LookML で行うことと行わないこと
- ベスト プラクティス: Looker ユーザーに良質なエクスペリエンスを提供
- ベスト プラクティス: 持続性と管理性に優れた LookML の記述
会話型分析で使用する Explore を設定するためのベスト プラクティス
会話型分析で最も役立つ回答を提供できるように、会話型分析のデータソースとして使用する Explore を 定義する際は、次のベスト プラクティスに従うことを検討してください。
- Explore の基盤となる LookML で、エンドユーザーによる分析に役立つフィールドのみを定義します。
- 各フィールドに明確で簡潔な名前と説明を付けます。
- 必要に応じてサンプル値を含めます。サンプル値は、文字列型のフィールドに特に役立ちます。
- コンテンツを再利用するデータ エージェント固有の Explore をキュレートすることを検討してください。
extendsを使用して既存の LookML を基に構築し、エージェントに必要なフィールドをキュレートします。システム アクティビティでは、エージェントによって生成されたクエリで使用されているフィールドを確認し、除外するフィールドを決定できます。- フィールドレベルの LookML リファインメントを使用して、エージェント専用の説明を作成します（例: 「ユーザーが売上について言及する場合は、[注文] フィールドを使用します」）。
データ エージェントを構築するためのベスト プラクティス
LookML のベスト プラクティスと適切に構成された Explore を使用して強固な基盤を確立したら、データ エージェントを構築して、特定のユースケースやユーザー グループ向けにカスタマイズされた会話エクスペリエンスを提供できます。データ エージェントは最大 5 つの Explore に接続し、自然言語の指示を使用してコンテキストを提供し、用語を定義し、動作ガイドラインを設定します。
エージェントを構築して指示を作成する際にベスト プラクティスに従うことは、特定のお客様のニーズに合わせてエージェントのレスポンスを調整し、全体的な精度を向上させるために不可欠です。これらのベスト プラクティスには、特定のドメイン専用のエージェントの設計と、明確で効果的な指示の作成が含まれます。
専門エージェントを構築する
すべてのビジネス上の質問を処理するグローバル データ エージェントを 1 つ構築したくなるかもしれませんが、エージェントは、販売、マーケティング、プロダクト アナリティクスなど、特定のドメインに特化している場合に最適なパフォーマンスを発揮します。1 つまたは少数の密接に関連する Explore に焦点を当てたエージェントには、より正確な指示を与えることができるため、曖昧さが軽減され、レスポンスの精度が向上します。
エージェントを設計する際は、関連性のないすべてのデータモデルを処理する単一のエージェントを構築しないようにしてください。代わりに、個別のビジネス領域に焦点を当てたエージェントを作成し、密接に関連する Explore のみに接続します。たとえば、すべての企業データに対して 1 つのエージェントを使用するのではなく、Orders Explore と Transactions Explore に特化した「収益エージェント」を作成します。
効果的なエージェントの指示を作成する
エージェントの指示は、データ エージェントの動作をカスタマイズし、組織固有のビジネス ロジックと用語を組み込むための主要なツールです。指示は、ユーザーの質問を解釈し、曖昧さを処理し、ユーザーにとって最も役立つ方法で応答する方法をエージェントに指導する方法と考えることができます。正確で関連性の高い信頼できる回答を生成するには、適切に記述された指示が不可欠です。
データ エージェントを作成するときに、[手順] フィールドにエージェントの指示を入力します。エージェントの作成について詳しくは、Explore データ エージェントの作成と管理のドキュメント ページをご覧ください。
効果的な指示を作成するには、次のベスト プラクティスに従います。
- ビジネス コンテキストとデフォルトの動作を定義する: 組織固有のロジックと用語についてエージェントに指導します。指示を使用して、頭字語を定義したり（例: 「LY は前年を意味します」）、一般的なフィルタリング ロジックを説明したり、曖昧さに対するデフォルトの動作を設定したりします（例: 「
date_createdが指定されていない場合は、過去 6 か月にフィルタします」）。 - LookML とフィルタ構文を使用する: 指示でフィールドを参照したり、フィルタを適用したりする場合は、LookML 構文（例:
events.date_created）とフィルタ構文（例:"last 6 months"）を使用します。これにより、エージェントは適用するフィールドまたはフィルタを理解できます。例: 「ユーザーが「地域」について質問する場合は、account_holder.geo_regionフィールドを使用します。」 - 複雑な例にはゴールデン クエリを使用する: 複雑なビジネス ロジックを含む一般的な質問やクエリの場合は、
golden queries（自然言語の質問とそれに対応する検証済みの Looker クエリのペア）を指定します。ゴールデン クエリは、エージェントが特定のパターンを学習するのに役立ちます。わかりにくい用語や一般的なフィルタの組み合わせを明確にするクエリに焦点を当てます。ゴールデン クエリは、未加工の SQL や標準の Explore URL ではなく、特定の LookML クエリ表現で指定する必要があります。 - 簡潔にする: 明確に記述し、指示内で不要な単語や繰り返しを避けます。
- 冗長性を避ける: フィールドの説明や類義語など、LookML に属する情報を重複させないでください。LookML とエージェントの指示のどちらでコンテキストを定義すべきかについて詳しくは、LookML と会話型分析のどちらにコンテキストを追加すべきかをご覧ください。また、ディメンションとメジャーの違いや基本的な日付フィルタリングの方法など、エージェントがすでに理解している基本的なコンセプトの説明は避けてください。
エージェントの指示の制限事項
エージェントの指示を作成する際は、会話型分析の次の制限事項に注意してください。
- 会話型分析では、
pivotsパラメータを含むクエリの生成はサポートされていません。会話型分析では、複数のディメンションのデータを一度に返すことができますが、Looker Explore UI のように、それらを個別の列にピボットすることはできません。代わりに、データは「長い」形式または「フラット」形式で返されるため、データは縦ではなく横にグループ化されます。 会話型分析では、既存の Looker コンテンツで定義されているカスタム フィールドを再利用したり（たとえば、カスタム フィールドを含む Explore から生成された LookML を使用してゴールデン クエリを作成する場合）、新しいクエリ内で新しいカスタム フィールドを生成したりすることはできません。代わりに、既存の LookML フィールドを使用するか、Python を使用してデータ結果にカスタム計算を作成します。
ガバナンスが適用される LookML とは異なり、指示は多くの場合、自由形式のテキストであり、基盤となるデータモデルが時間とともに進化すると「古く」なる可能性があります。
エージェントの指示の例
Order Items と Products という Looker Explore に接続されているデータ エージェントの指示の例を次に示します。
# Define a persona and provide instructions on how to propose suggestions
You are a helpful data assistant. After answering the user's question, please provide 2-3 relevant follow-up questions they might be interested in exploring based on the data.
Anticipate the user's needs. Suggest potential next questions or related analyses after each response.
Always offer suggestions for deeper dives into the data.
Your tone should be professional and concise.
# Business Terms
# Define how business terms map to LookML fields or data values that can't be captured in LookML synonyms or descriptions.
Terms:
EOP: End of Period. This is the last day of the period.
LY: Last Year.
Month-over-month: This is a measure of `type: period_over_period` with `period: month`.
# Default Behaviors
# Define how to handle ambiguous or underspecified queries.
When users mention Orders, you must apply a filter of `Status` like `COMPLETED`. Consider this a **hard-coded requirement**. Do not attempt to verify this filter by querying sample values; proceed directly to the calculation using this exact string.
Defaults:
Date Filter: If no `created_date` is specified by the user, filter order_items.created_date to "last 12 months".
Product Grouping: If "group by product" is requested without specifying name or category, use `products.category`.
# Golden Queries
# Provide examples of question/query pairs for common or complex questions.
Golden Queries:
- Question: "How much revenue did we generate from successful orders in 2024?"
Looker query:
model: thelook_ecommerce
explore: order_items
fields: [order_items.total_sales]
filters: [{field: order_items.status, value: "Complete"}, {field: order_items.created_year, value: "2024"}]
# Related Fields
# Provide instructions for what other related fields the agent should fetch information from
Include parent dimensions like Category when asking for "item level" data.
LookML と会話型分析のどちらにコンテキストを追加すべきか
会話型分析では、LookML またはエージェントの指示内にコンテキストを追加できます。コンテキストを追加する場所を決定する際は、次のガイダンスを適用してください。
- Explore のすべてのユーザーに適用されるコンテキストは、LookML モデルに直接追加する必要があります。Looker Explore は、ダッシュボードと会話型分析の両方など、複数の場所で使用される可能性があるためです。コンテキストを特定のユーザーにのみ適用する場合は、ユーザー属性などの LookML 機能を使用して、カスタマイズされたエクスペリエンスを作成することを検討してください。
- フィールド固有のメタデータとハード要件には、LookML を優先します。類義語や説明などのフィールド固有のメタデータは、エージェントの指示ではなく、LookML に直接配置します。デフォルトのフィルタ値や非表示フィールドなどの要件は、LookML で処理して、確実に適用されるようにすることをおすすめします。
- Looker クエリの作成方法、ディメンションやメジャーの説明、アクセス可能な Explore、基本的な日付フィルタリングの方法など、エージェントがすでに知っている情報を重複させないでください。同様に、LookML とエージェントの指示の両方で同じ用語を定義しないでください。
エージェントのコンテキストは定性的でユーザーに焦点を当てる必要があり、1 つの Explore からさまざまなユーザーにサービスを提供するエージェントが多数存在する可能性があります。LookML はフィールドが「何であるか」を定義するのに適していますが、通常はビジネス戦略や予測計算を定義することはできません。 エージェントの指示に含めるべきで、LookML に含めるべきではないコンテキストの例を次に示します。
- エージェントとやり取りしているユーザーは誰ですか？その役割は何ですか？社内ですか、社外ですか？以前のアナリティクスの経験はありますか？
- ユーザーの目標は何ですか？会話の最後にどのような意思決定をしようとしていますか？
- このユーザーはどのような質問をしますか？
- このユーザーに最も関連性の高いフィールドは何ですか？たとえば、このユーザーがアクセスできるフィールド、特定のフィルタを常に適用する必要があるかどうか、このユーザーに優先するフィールドなどです。