Looker で会話分析をロールアウトするためのベスト プラクティス

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

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

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

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

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

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

  1. LookML モデル: 会話型アナリティクスは、Looker の Explore 内で定義されている構造、フィールド（ディメンション、メジャー）、ラベル、説明を分析します。

  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 には含めるべきではないコンテキストの例は次のとおりです。

  • エージェントとやり取りしているユーザーは誰ですか？その役割は何ですか？社内ですか、社外ですか？アナリティクスの経験はどの程度ですか？
  • ユーザーの目標は何ですか？会話の最後にどのような決定をしようとしていますか？
  • このユーザーはどのような質問をするでしょうか？
  • このユーザーに固有の上位のフィールドは何ですか？このユーザーが使用する必要のないフィールドはどれですか？

このガイドでは、Looker で会話分析を実装するための段階的なアプローチとして、次の方法をおすすめします。

このアプローチでは、小規模で制御された範囲から開始し、設定を検証してから、より多くのユーザーとデータに拡大できます。

フェーズ 1: データをキュレートし、初期スコープを定義する

このフェーズでは、ユーザーが会話分析でクエリを実行できるようにデータを準備し、初期デプロイの範囲を定義します。小規模で制御されたスコープから始めるための推奨事項は次のとおりです。

  • 初期ユーザー アクセスを制限する: 内部テストと検証を有効にするには、Looker の権限システムを使用して、データに精通している少数のユーザーに Gemini ロールを付与します。
  • Gemini の Looker モデルへのアクセスを制限する: Gemini ロールを付与するときに、Gemini がアクセスできるモデルを制限することもできます。まず、会話分析用にキュレートした 1 つまたは 2 つのモデルに Gemini のアクセスを制限することを検討してください。
  • 厳選された探索を選択する: 比較的クリーンなデータに基づいており、明確なビジネス価値を提供する、構造化された 1 つまたは 2 つの探索から始めます。会話分析の LookML のベスト プラクティスに記載されている詳細な手順に沿って、Looker の会話分析用にこれらの Explore を最適化します。

フェーズ 2: エージェントを構成して内部で検証する

このフェーズでは、会話型分析エージェントを構築して改良し、社内ユーザーによる徹底的なテストを実施して、精度と有効性を確認します。このフェーズでは、次の手順を実施します。

  1. キュレートされたエージェントを作成する: キュレーションと初期設定のフェーズで準備したキュレートされたデータ探索のみに基づいて、会話分析エージェントを作成します。

  2. エージェントの指示で絞り込む: エージェントの指示を使用して、追加のコンテキストとガイダンスを提供します。次に例を示します。

    • フィールド名または値の同義語を定義します。
    • 特定のフィールドの使用方法に関する具体的なコンテキストやルールを指定します。

  3. 内部で検証して反復処理を行う: データに精通しているユーザーにエージェントを徹底的にテストしてもらいます。さまざまな質問をしたり、エッジケースをテストしたりして、弱点を特定します。テストからのフィードバックに基づいて、次の変更を行います。

    1. LookML を調整します。たとえば、label、description、hidden の LookML パラメータの値を調整します。
    2. エージェントへの指示を調整します。
    3. データ品質に関する問題の報告を続けます。

フェーズ 3: 会話分析の導入を他のユーザーに拡大する

このフェーズでは、アクセス権を付与し、フィードバックを収集し、エージェントを反復処理することで、会話型分析の導入をより多くのユーザーに拡大します。このフェーズでは、次の手順を実施します。

  1. 対象を絞ったアクセス権を付与する: Gemini ロールを持つ追加のユーザーに会話分析へのアクセス権を付与し、作成した特定の審査済みエージェントを使用するようユーザーに促します。

  2. リリースしてフィードバックを収集する: 以下のトピックについて積極的にフィードバックを求めます。

    • 回答の精度
    • 使いやすさ
    • 情報が不足している、または結果がわかりにくい

  3. 継続的に反復処理する: フィードバックを使用して LookML とエージェントの手順をさらに絞り込み、データのクリーンアップ作業を優先します。

  4. アクセスを拡大する: エージェントが安定していて価値があることが証明されたら、他の関連するユーザー グループにアクセスを拡大し、Gemini ロールを付与して新しいキュレートされたエージェントを導入します。また、前のフェーズで使用したのと同じプロセスに沿って、新しいキュレートされたエージェントを導入したり、Gemini ロールで使用できるモデルへのアクセスを拡大したりすることもできます。