会話分析は、Gemini for Google Cloud を使用して自然言語の質問を解釈します。その際、Looker のセマンティック モデル（LookML）、データ値、データ エージェントの構成を信頼できる唯一の情報源として使用します。回答の品質は、これらの入力をどれだけ効果的に準備できるかに左右されます。
このガイドでは、LookML デベロッパーと管理者が会話型分析を構成して最適化するための戦略とベスト プラクティスについて説明します。LookML モデル、Explore、データ エージェントに関するこれらの推奨事項に沿って対応することで、ユーザーの導入を促進し、ユーザーが質問に対して正確で関連性の高い有用な回答を得られるようにすることができます。このガイドでは、Conversational Analytics に関連するベスト プラクティスについて説明します。モデルの LookML で強力な基盤を開発し、このモデルに基づいて Explore を構成し、これらの Explore をデータソースとして使用するデータ エージェントを構築するという論理的な流れに沿って説明します。
- 会話型分析の LookML のベスト プラクティス
- 会話型分析で使用する Explore を設定するためのベスト プラクティス
- データ エージェントを構築するためのベスト プラクティス
- LookML とエージェントの指示にコンテキストを追加するタイミング
会話型分析の LookML のベスト プラクティス
Conversational Analytics は、次の主な入力を使用して自然言語による質問を解釈します。
- 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 の基盤となる LookML で、エンドユーザーによる分析に役立つフィールドのみを定義します。
- 各フィールドにわかりやすく簡潔な名前と説明を付けます。
- 必要に応じてサンプル値を含めます。サンプル値は、特に文字列型のフィールドで役立ちます。
- コンテンツを再利用するデータ エージェント固有の Explore をキュレートすることを検討してください。
extendsを使用して既存の LookML を基に構築し、エージェントに必要なフィールドをキュレートします。システム アクティビティでは、エージェントによって生成されたクエリで使用されているフィールドを確認し、除外するフィールドを決定できます。- フィールドレベルの LookML 絞り込みを使用して、エージェント専用の説明（「ユーザーがセールスについて言及した場合は、Orders フィールドを使用してください」など）を作成します。
データ エージェントの構築に関するベスト プラクティス
LookML のベスト プラクティスと適切に構成された Explore を使用して強固な基盤を確立したら、データ エージェントを構築して、特定のユースケースやユーザー グループ向けにカスタマイズされた会話型エクスペリエンスを提供できます。データ エージェントは最大 5 つのデータ探索に接続し、自然言語による指示を使用してコンテキストの提供、用語の定義、行動ガイドラインの設定を行います。
エージェントの構築と指示の作成でベスト プラクティスに従うことは、エージェントの回答を特定のユーザーのニーズに合わせて調整し、全体的な精度を高めるうえで非常に重要です。これらのベスト プラクティスには、特定のドメイン専用のエージェントを設計することや、明確で効果的な指示を作成することなどがあります。
専門エージェントを構築する
すべてのビジネスに関する質問を処理するグローバル データ エージェントを 1 つ作成したくなるかもしれませんが、エージェントは、販売、マーケティング、プロダクト分析などの特定のドメインに特化している場合に最適なパフォーマンスを発揮します。1 つまたは少数の密接に関連する探索に焦点を当てたエージェントには、より正確な指示を与えることができます。これにより、曖昧さが軽減され、レスポンスの精度が向上します。
エージェントを設計する際は、関連性のないすべてのデータモデルを処理する単一のエージェントを構築しないようにしてください。代わりに、ビジネス分野ごとに焦点を絞ったエージェントを作成し、関連性の高い Explore のみに接続します。たとえば、すべての会社データに対応する 1 つのエージェントではなく、Orders と Transactions のデータ探索に特化した「収益エージェント」を作成します。
効果的なエージェントへの指示を作成する
エージェントの指示は、データ エージェントの動作をカスタマイズし、組織独自のビジネス ロジックと用語を組み込むための主要なツールです。手順は、ユーザーの質問の解釈方法、曖昧さの処理方法、ユーザーにとって最も役立つ方法での回答方法についてエージェントを指導する方法と考えることができます。正確で関連性の高い信頼できる回答を生成するには、適切な指示を記述することが重要です。
データ エージェントを作成するときに、[手順] フィールドにエージェントへの指示を入力します。エージェントの作成の詳細については、Explore データ エージェントの作成と管理のドキュメント ページをご覧ください。
効果的な指示を作成するには、次のベスト プラクティスを実践してください。
- ビジネス コンテキストとデフォルトの動作を定義する: 組織独自のロジックと用語についてエージェントを指導します。手順を使用して、頭字語を定義したり（「LY は Last Year の略」など）、一般的なフィルタリング ロジックを説明したり、曖昧さに対するデフォルトの動作を設定したりします（「
date_createdが指定されていない場合は、過去 6 か月間にフィルタする」など）。 - LookML とフィルタの構文を使用する: 手順でフィールドを参照したり、フィルタを適用したりする場合は、LookML 構文（
events.date_createdなど）とフィルタの構文（"last 6 months"など）を使用します。これにより、エージェントはどのフィールドまたはフィルタを適用すべきかを理解できます。たとえば、「ユーザーが「リージョン」について質問した場合は、account_holder.geo_regionフィールドを使用します。」 - 簡潔にする: わかりやすく記述し、手順の中で不要な単語や繰り返しを避けます。
- 冗長性を避ける: フィールドの説明や同義語など、LookML に属する情報を重複させないでください。LookML とエージェントの指示のどちらでコンテキストを定義すべきかについては、LookML と会話型分析のどちらでコンテキストを追加すべきかをご覧ください。また、ディメンションと指標の違いや、日付の基本的なフィルタリング方法など、エージェントがすでに理解している基本的なコンセプトの説明も避けてください。
エージェントへのカスタム指示の制限事項
エージェントの手順を作成する際は、Conversational Analytics の次の制限事項に注意してください。
- 会話型分析では、
pivotsパラメータを含むクエリの生成はサポートされていません。会話分析では複数のディメンションのデータを一度に返すことができますが、Looker Explore UI のように個別の列にピボットすることはできません。代わりに、データは「長い」形式または「フラット化された」形式で返されるため、データは縦ではなく横にグループ化されます。 - LookML はガバナンスが適用されますが、指示は多くの場合自由形式のテキストであり、基盤となるデータモデルが時間とともに進化すると、指示が古くなる可能性があります。データ エージェントの古い手順を回避するには、検証済みのクエリを使用して、自然言語の質問とそれに対応する Explore クエリのペアを定義します。
エージェントへの指示の例
Looker の Explore（[Order Items] と [Products]）に接続されているデータ エージェントの指示の例を次に示します。
# 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`.
# 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 には含めるべきではないコンテキストの例は次のとおりです。
- エージェントとやり取りしているユーザーは誰ですか？その役割は何ですか？社内ですか、社外ですか？これまでの分析経験について教えてください。
- ユーザーの目標は何ですか？会話の最後にどのような決定を下そうとしているか。
- このユーザーはどのような質問をする可能性がありますか？
- このユーザーに最も関連性の高いフィールドはどれですか？たとえば、このユーザーがアクセスできるフィールド、常に適用されるフィルタ、優先されるフィールドなどを指定します。