在 Looker 中配置对话分析的最佳实践

对话式分析使用 Gemini for Google Cloud 来解读自然语言问题,并使用 Looker 语义模型 (LookML)、数据值和数据智能体配置作为其可信来源。其回答的质量取决于您准备这些输入内容的有效性。

本指南为 LookML 开发者和管理员提供了配置和优化对话式分析的策略和最佳实践。通过遵循针对 LookML 模型、探索和数据智能体的这些建议,您可以提高用户采用率,并确保用户获得准确、相关且有用的问题答案。本指南介绍了与对话式分析相关的最佳实践,遵循从在模型的 LookML 中打下坚实基础、配置基于此模型的探索,到构建使用这些探索作为数据源的数据智能体的逻辑流程。

对话式分析的 LookML 最佳实践

对话式分析通过利用以下主要输入内容来解读自然语言问题:

  • LookML 模型:智能体会提取与其关联的探索的架构。该架构包括字段(维度测量)、仅限过滤条件的字段(过滤条件参数)以及 Looker 探索所基于的 LookML 模型中定义的相应标签说明同义词。如需查看对话式分析分析的 LookML 参数的完整列表,请参阅对话式分析概览
  • 不同的字段值:智能体可以对数据值进行抽样,并执行模糊搜索以检查底层数据库中的特定字段值。借助这些方法,智能体可以选择正确的字段、应用正确的过滤条件值,并识别用户可能会询问的可用类别和实体。

对话式分析的有效性直接取决于这些输入的质量和清晰度。下表列出了不清晰或模棱两可的 LookML 可能会对对话式分析产生负面影响的常见方式,以及用于减少延迟时间、改进输出和用户体验的解决方案。

LookML 质量问题 更清晰的对话式分析的解决方案
缺乏清晰度和命名冲突: 如果字段缺少清晰的标签、定义不明确,或者在不同视图中共享相似的名称,可能会导致字段选择不正确。 应用清晰的标签和详尽的说明
  • 使用 label 参数为字段指定直观、适合业务的名称。
  • 使用 description 参数提供关键背景信息、自然语言定义和行业专用术语。对话式分析使用说明来更好地识别字段含义和映射用户术语。
字段过多: 如果公开的字段过多(例如内部 ID、联接中的重复字段或中间计算),会使对话式分析可用的选项变得杂乱无章。 隐藏不相关的字段: 确保所有主键、外键和技术字段保持隐藏状态。

(可选)扩展探索: 对于包含许多字段的探索,请考虑通过扩展现有探索来为对话式分析创建专用版本。
抽样和搜索的数据库负载: 从数据库检索抽样值和建议可能很慢或产生不必要的负载,尤其是在用户在查询中引用特定数据值时。 在 LookML 中定义建议: 通过对值进行硬编码或指向更高效的维度,避免针对字段建议进行实时数据库查询:
数据查询的数据库负载: 大型或低效的查询可能会增加延迟时间和数据库负载。 优化数据查询: 遵循优化查询性能的一般最佳实践,例如使用汇总感知和高效的联接逻辑。
LookML 定义不完整: 依赖于信息中心级自定义字段或表计算会使对话式分析无法访问关键业务逻辑。 纳入自定义逻辑: 将重要且常用的自定义字段表计算转换为 LookML 维度和测量。
杂乱的数据: 以下类型的不一致或结构不良的数据会使对话式分析难以准确解读查询。
  • 值变体: 大小写或命名惯例不一致(例如,completeCompleteCOMPLETE 值的混合)可能会导致对话式分析中的数据重复或数据关系不正确。
  • 数据类型不一致: 旨在为数值且包含偶尔出现的字符串值的列会强制将字段类型设置为 string,从而阻止数值运算。
  • 时区不明确: 时间戳字段中缺少标准化时区可能会导致过滤或汇总不正确。
解决数据质量问题: 如果可能,请标记在数据整理期间发现的数据质量问题(值、类型、时区不一致)。与数据工程团队合作,清理源数据或在 ETL/数据建模层中应用转换。

LookML 关键要点

在为将用作对话式分析数据源的探索定义 LookML 时,请注意以下要点:

  • 使用清晰准确的标签: 为您的数据选择能够反映业务用户实际说话方式的标签。避免使用 "amt_usd_curr" 等技术缩写,而应使用 "Amount (USD)"
  • 实现无缝映射: 使用同义词和说明帮助智能体将用户问题映射到正确的字段。
  • 集中计算: 将常用计算直接定义为 LookML 维度或测量,以确保单一可信来源并减少延迟时间。
  • 简化上下文:在 LookML 中隐藏技术字段或仅限内部使用的字段(例如外键或原始 ID),以确保对话式分析仅显示回答业务问题所需的字段。仅关注相关字段可以减少干扰并提高字段选择的准确性。
  • 优化抽样数据和模糊搜索查询:在 suggestions 参数中定义硬编码值,或使用 suggest_dimensionsuggest_explore 进行更高效的数据库查询。
  • 优化数据查询: 遵循优化查询性能的一般 Looker 最佳实践,例如使用汇总感知和高效的联接逻辑。

如需了解有关编写简洁高效的 LookML 的更多最佳实践,请参阅以下文档:

设置探索以用于对话式分析的最佳实践

为了帮助对话式分析提供最有用的答案,请考虑在定义探索以用作对话式分析的数据源时遵循以下最佳实践:

  • 在探索的基础 LookML 中,仅定义对最终用户进行分析有用的字段。
    • 为每个字段指定清晰简洁的名称和说明。
    • 在相关位置添加抽样值。抽样值对于字符串类型字段尤其有用。
  • 考虑整理可重复使用内容的数据智能体专用探索。
    • 使用 extends 基于现有 LookML 构建,并整理智能体所需的字段。在系统活动中,用户可以查看智能体生成的查询中使用的字段,并决定要排除的字段。
    • 使用字段级 LookML 优化 来创建专为智能体打造的说明 -“当用户提及销售额时,使用订单字段”。

构建数据智能体的最佳实践

在通过 LookML 最佳实践和配置良好的探索打下坚实基础后,您可以构建 数据智能体,为特定用例或用户群组提供自定义对话体验。数据智能体最多可以连接到五个探索,并使用自然语言指令来提供上下文、定义术语和设置行为准则。

在构建智能体和编写指令时遵循最佳实践对于调整智能体的回答以满足特定用户需求并提高整体准确性至关重要。这些最佳实践包括为特定领域设计专用智能体,以及编写清晰有效的指令

构建专用智能体

虽然构建一个全局数据智能体来处理所有业务问题可能很诱人,但智能体在专门针对特定领域(例如销售、营销或产品分析)时表现最佳。专注于一个或几个密切相关的探索的智能体可以获得更精确的指令,从而减少歧义并提高回答准确性。

在设计智能体时,请避免构建单个智能体来处理所有不相关的数据模型。相反,请为不同的业务领域创建专注的智能体,仅连接到密切相关的探索。例如,不要为所有公司数据创建一个智能体,而是创建一个专门专注于 OrdersTransactions 探索的“收入智能体”。

编写有效的智能体指令

智能体指令是自定义数据智能体行为并为其注入组织独特的业务逻辑和术语的主要工具。您可以将指令视为指导智能体如何解读用户问题、处理歧义以及以对用户最有帮助的方式做出响应的方式。编写良好的指令是生成准确、相关且可靠的答案的关键。

创建数据智能体时,请在指令 字段中输入智能体指令。如需详细了解如何创建智能体,请参阅创建和管理探索数据智能体文档页面。

如需编写有效的指令,请遵循以下最佳实践:

  • 定义业务背景和默认行为:指导智能体了解组织独特的逻辑和术语。使用指令定义缩写(例如,“LY 表示上一年”)、解释常见过滤逻辑或设置歧义的默认行为(例如,“如果未提供 date_created,则过滤到过去 6 个月”)。
  • 使用 LookML 和过滤条件语法:在指令中引用字段或应用过滤条件时,请使用 LookML 语法(例如 events.date_created)和过滤条件语法(例如 "last 6 months")。这可确保智能体了解要应用哪些字段或过滤条件。例如:“当用户询问‘区域’时,使用 account_holder.geo_region 字段。”
  • 针对复杂示例使用黄金查询:对于涉及复杂业务逻辑的常见问题或查询,请提供 golden queries,即自然语言问题及其对应的经过验证的 Looker 查询对。黄金查询可以帮助智能体学习特定模式。重点关注阐明棘手术语或常见过滤条件组合的查询。黄金查询必须以特定的 LookML 查询表示形式提供,而不是原始 SQL 或标准探索网址。
  • 简洁明了:编写清晰,避免在指令中使用不必要的字词或重复内容。
  • 避免冗余:不要重复 LookML 中的信息,例如字段说明或同义词。如需详细了解何时在 LookML 中定义上下文,何时在智能体指令中定义上下文,请参阅何时向 LookML 添加上下文,何时向对话式分析添加上下文。此外,还要避免解释智能体已经了解的基本概念,例如维度和测量之间的区别或如何执行基本日期过滤。

智能体指令的限制

在编写智能体指令时,请注意对话式分析的以下限制:

  • 对话式分析不支持生成包含 pivots 参数的查询。虽然对话式分析可以一次返回多个维度的数据,但它无法像 Looker 探索界面那样将这些维度透视到单独的列中。相反,它以“长”或“扁平”格式返回数据,因此数据是水平分组而不是垂直分组。
  • 对话式分析无法重复使用在现有 Looker 内容中定义的自定义字段(例如,当您使用包含自定义字段的探索中生成的 LookML 来创建黄金查询时),也无法在新查询中生成全新的自定义字段。相反,它使用现有 LookML 字段或使用 Python 在数据结果上创建自定义计算。

  • 与受治理的 LookML 不同,指令通常是自由格式文本,并且随着底层数据模型的不断发展,可能会变得“过时”

智能体指令示例

以下是连接到名为订单项产品 的 Looker 探索的数据智能体的一些示例指令:

# 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 或 智能体指令中添加上下文。在决定向何处添加上下文时,请遵循以下指导原则:

  • 应将适用于探索的所有用户的上下文直接添加到 LookML 模型中,因为 Looker 探索可能会在多个位置使用,包括信息中心和对话式分析。如果上下文仅适用于某些用户,请考虑使用 LookML 功能(例如 用户属性)来创建自定义体验。
  • 优先使用 LookML 来处理字段专用元数据和硬性要求。将字段专用元数据(包括同义词和说明)直接放在 LookML 中,而不是智能体指令中。默认过滤条件值或隐藏字段等要求最好在 LookML 中处理,以确保它们得到遵守。
  • 不要重复智能体已经知道的信息,例如如何创建 Looker 查询、维度或测量的说明、其可访问的探索或如何执行基本日期过滤。同样,不要在 LookML 和智能体指令中定义相同的术语。

智能体上下文应是定性的,并且以用户为中心,并且可以有许多智能体从一个探索为不同的用户提供服务。LookML 擅长定义字段的“内容”,但通常无法定义业务策略或预测计算。 应包含在智能体指令中但不包含在 LookML 中的上下文示例如下:

  • 与智能体互动的用户是谁?他们的角色是什么?他们是公司内部人员还是外部人员?他们之前的分析经验是什么?
  • 用户的目标是什么?他们希望在对话结束时做出哪种类型的决策?
  • 此用户会提出哪些类型的问题?
  • 哪些字段与此用户最相关?例如,此用户应可以访问哪些字段,是否应始终应用某些过滤条件,或者是否应为此用户优先处理某些字段?