Looker で会話分析を構成するためのベスト プラクティス

会話分析を使用すると、Looker インスタンス内で自然言語で質問することで、LookML でモデル化されたデータをクエリできます。ユーザーは次の方法でデータをクエリできます。

このガイドでは、LookML デベロッパーが会話型分析を適切に構成して最適化するための戦略とベスト プラクティスについて説明します。このガイドの内容は次のとおりです。

LookML モデルと Conversational Analytics を準備することで、ユーザーの導入を促進し、ユーザーが質問に対して正確で有用な回答を得られるようにすることができます。

Gemini for Google Cloud がデータを使用する方法とタイミングに関する説明をご覧ください。

会話分析の LookML のベスト プラクティス

会話分析は、次の 2 つの主な入力を使用して自然言語の質問を解釈します。

  1. LookML モデル: 会話型分析では、Looker Explore の基盤となる LookML モデルで定義されている構造、フィールド（ディメンション、メジャー）、ラベル、説明、同義語が分析されます。

  2. 個別のフィールド値: 会話分析では、フィールド内のデータ値（特に文字列ディメンションとシノニム）を調べて、ユーザーが質問する可能性のあるカテゴリとエンティティを特定します。基数（固有の値の数）は、これらの値の使用方法に影響する可能性があります。

会話分析の有効性は、これら 2 つの入力の品質と明瞭さに直接結びついています。次の表に、不明確または曖昧な LookML が会話型分析に悪影響を及ぼす一般的な方法と、出力とユーザー エクスペリエンスを改善するための解決策を示します。

LookML の品質に関する一般的な問題 会話分析をより明確にするためのソリューション
明確さの欠如: 明確なラベルや説明のないフィールドは、会話分析とユーザーの両方にとって曖昧です。 わかりやすいラベルを適用する: label パラメータを使用して、ユーザーが質問で使用する可能性が高い、直感的でビジネスに適した名前をフィールドに付けます。
フィールドの肥大化: 多くのフィールド（特に内部 ID（主キー）、結合から継承された重複フィールド、中間計算フィールド）を公開すると、会話型分析で使用できるオプションが煩雑になる可能性があります。 無関係なフィールドを非表示にする: すべての主キー、外部キー、結合からの冗長なフィールド、純粋に技術的なフィールドが非表示のままになっていることを確認します。

（省略可）データ探索を拡張する: データ探索に多数のフィールドが含まれている場合は、既存のデータ探索を拡張する新しいデータ探索を作成することを検討してください。これにより、他のコンテンツが依存している可能性があるデータ探索を変更することなく、会話型アナリティクス用に人気のあるコンテンツの専用バージョンをカスタマイズできます。
名前の競合: Explore 内の異なるビューで、名前またはラベルが類似または同一のフィールドが複数あると、フィールドの選択が誤る可能性があります。 詳細な説明を記述する: 説明は、会話分析に重要なコンテキストを提供します。description パラメータは、次のタスクに使用します。
  • 自然言語を使用してフィールドを明確に説明します。
  • 会社や業界固有の用語や類義語を含めます。
  • 計算やコンテキストについて説明します。会話型アナリティクスでは、説明を使用してフィールドの意味をより正確に特定し、ユーザー用語をマッピングします。

たとえば、ラベルが user_count のフィールドには、「ウェブサイトにアクセスしたユニーク ユーザーの合計数」という説明を付けることができます。

命名を標準化する: フィールド名とラベルの整合性とわかりやすさを確認します。
複雑さが隠されている: マイレポート レベルのカスタム フィールドやテーブル計算に大きく依存していると、重要なビジネス ロジックが会話型アナリティクスで利用できなくなる可能性があります。 カスタム ロジックを組み込む: 重要なカスタム フィールドまたは表計算を特定します。これらのフィールドのロジックを LookML のディメンションと指標に変換して、会話分析で使用できるようにします。
不整合なデータ: 次のような不整合なデータや構造が不適切なデータがあると、会話分析でクエリを正確に解釈することが難しくなります。
  • 値のバリエーション: 大文字と小文字の区別や命名規則が統一されていない場合（たとえば、complete、Complete、COMPLETE の値が混在している場合）、会話分析でデータの重複やデータ関係の誤りが生じる可能性があります。
  • データ型の不整合: 数値として使用する列に文字列値が含まれていると、フィールドの型が string に強制的に設定され、数値演算が実行できなくなります。
  • タイムゾーンの曖昧さ: タイムスタンプ フィールドに標準化されたタイムゾーンがないと、フィルタリングや集計が正しく行われない可能性があります。
 データ品質に対処する: 可能な場合は、データ キュレーション中に特定したデータ品質の問題（値、型、タイムゾーンの不整合）にフラグを設定します。データ エンジニアリング チームと協力して、ソースデータをクリーンアップするか、ETL/データ モデリング レイヤで変換を適用します。

クリーンで効率的な LookML を記述するためのベスト プラクティスについては、次のドキュメントをご覧ください。

LookML と会話型分析のどちらにコンテキストを追加するか

会話型分析では、フィールドの類義語や説明などのコンテキスト入力を LookML とエージェントの指示の両方に追加できます。コンテキストを追加する場所を決定する際は、次のガイダンスを適用します。常に true のコンテキストは、LookML モデルに直接追加する必要があります。Looker Explore は、ダッシュボードと会話分析の両方を含む複数の場所で使用される可能性があるため、LookML で適用されるコンテキストは、データとやり取りする可能性のあるすべてのユーザーに当てはまる必要があります。

エージェントのコンテキストは定性的で、ユーザーに焦点を当てる必要があります。1 つの Explore からさまざまなユーザーにサービスを提供するエージェントが多数存在することもあります。エージェントの手順には含めるべきだが、LookML には含めるべきではないコンテキストの例は次のとおりです。

  • エージェントとやり取りしているユーザーは誰ですか？その役割は何ですか？社内ですか、社外ですか？これまでの分析経験について教えてください。
  • ユーザーの目標は何ですか？会話の最後にどのような決定をしようとしていますか？
  • このユーザーはどのような質問をする可能性がありますか？
  • このユーザーに固有の上位のフィールドは何ですか？このユーザーが使用する必要のないフィールドはどれですか？

Conversational Analytics で使用する Explore を設定する際のベスト プラクティス

会話分析で最も役立つ回答を得るには、会話分析のデータソースとして使用する探索を定義する際に、次のベスト プラクティスを参考にしてください。

  • Explore の基盤となる LookML で、エンドユーザーの分析に役立つフィールドのみを定義します。
  • 各フィールドに明確で簡潔な名前を付けます。
  • 各フィールドに、わかりやすい説明を入力します。該当する場合は、値の例も入力します。これらのフィールドの説明は、会話分析に送信されるプロンプトに含まれており、コンテキストの提供に役立ちます。サンプル値は、特に文字列フィールドで役立ちます。