对话式分析使用 Gemini for Google Cloud 来解读自然语言问题，并使用 Looker 语义模型 (LookML)、数据值和数据智能体配置作为其事实来源。回答的质量取决于您准备这些输入内容的有效性。
本指南为 LookML 开发者和管理员提供了相关策略和最佳实践，以帮助他们配置和优化对话式分析。遵循这些针对 LookML 模型、Explore 和数据代理的建议，您可以提高用户采用率，并确保用户获得准确、相关且有用的问题解答。本指南将按照逻辑流程介绍与对话式分析相关的最佳实践，首先从在模型的 LookML 中打下坚实的基础开始，然后配置基于此模型的探索，最后构建使用这些探索作为数据源的数据代理。
对话式分析的 LookML 最佳实践
Conversational Analytics 会利用以下主要输入内容来解读自然语言问题：
- LookML 模型：代理会提取与其关联的探索的架构。该架构包含字段（维度、度量）、仅限过滤条件的字段（过滤条件、参数）以及 Looker 探索所基于的 LookML 模型中定义的相应标签、说明和同义词。如需查看对话式分析会分析的 LookML 参数的完整列表，请参阅对话式分析概览。
- 不同的字段值：代理可以对数据值进行抽样，并执行模糊搜索，以检查底层数据库中是否存在特定字段值。这些方法使代理能够选择正确的字段、应用正确的过滤值，并识别用户可能会询问的可用类别和实体。
对话式分析的有效性直接取决于这些输入的质量和清晰度。下表列出了不清晰或模棱两可的 LookML 可能会对对话分析产生哪些负面影响，以及可用于缩短延迟时间、改进输出和提升用户体验的解决方案。
| LookML 质量问题 | 更清晰的对话式分析解决方案 |
|---|---|
| 缺乏清晰度和命名冲突：如果字段缺少清晰的标签、定义不明确或在不同视图中共享相似的名称，可能会导致字段选择不正确。 | 应用清晰的标签和详尽的说明： |
| 字段过多：公开过多的字段（例如内部 ID、联接中的重复字段或中间计算结果）会使对话式分析可用的选项变得杂乱无章。 | 隐藏无关字段：确保所有主键、外键和技术字段都保持隐藏状态。 （可选）扩展探索：对于包含许多字段的探索，您可以考虑通过扩展现有探索来为对话式分析创建专用版本。 |
| 用于抽样和搜索的数据库负载：从数据库检索样本值和建议可能会很慢，或者会产生不必要的负载，尤其是在用户在查询中引用特定数据值时。 | 在 LookML 中定义建议：通过对值进行硬编码或指向更高效的维度，避免针对字段建议进行实时数据库查询：
|
| 数据查询的数据库负载：大型查询或低效查询可能会增加延迟时间和数据库负载。 | 优化数据查询：遵循优化查询性能的一般最佳实践，例如使用汇总感知和高效的联接逻辑。 |
| 不完整的 LookML 定义：依赖信息中心级自定义字段或表计算会导致对话式分析无法访问关键业务逻辑。 | 纳入自定义逻辑：将重要且常用的自定义字段或表计算转换为 LookML 维度和度量。 |
杂乱的数据：以下类型的不一致或结构不良的数据会让对话式分析难以准确解读查询。
|
解决地址数据质量问题：尽可能标记在数据整理过程中发现的数据质量问题（不一致的值、类型、时区）。与数据工程团队合作，清理源数据或在 ETL/数据建模层中应用转换。 |
LookML 关键要点
在为将用作 Conversational Analytics 数据源的探索定义 LookML 时，请牢记以下要点：
- 使用清晰准确的标签：为数据选择的标签应能反映业务用户的实际用语。避免使用
"amt_usd_curr"等技术缩写，而应使用"Amount (USD)"。 - 实现顺畅的映射：使用同义词和说明来帮助代理将用户问题映射到正确的字段。
- 集中计算：直接将常用计算定义为 LookML 维度或度量，以确保单一的事实来源并减少延迟时间。
- 简化上下文：在 LookML 中隐藏技术字段或仅供内部使用的字段（例如外键或原始 ID），以确保只有回答业务问题所需的字段才会显示在对话式分析中。只关注相关字段可减少噪声并提高字段选择的准确性。
- 优化示例数据和模糊搜索查询：在
suggestions参数中定义硬编码值，或使用suggest_dimension和suggest_explore来提高数据库查询效率。 - 优化数据查询：遵循优化查询性能的 Looker 最佳实践，例如使用汇总感知和高效的联接逻辑。
如需了解有关编写简洁高效的 LookML 的更多最佳实践，请参阅以下文档：
设置探索以搭配 Conversational Analytics 使用的最佳实践
为了帮助对话式分析提供最有用的回答，请考虑在定义探索以用作对话式分析的数据源时，遵循以下最佳实践：
- 在探索的底层 LookML 中，仅定义对最终用户进行分析有用的字段。
- 为每个字段指定清晰简洁的名称和说明。
- 在相关情况下包含示例值。对于字符串类型的字段，示例值尤其有用。
- 考虑策划可重复使用内容的数据智能体专用探索。
构建数据代理的最佳实践
在 LookML 最佳实践和配置完善的探索的基础上，您可以构建数据代理，为特定使用情形或用户群组提供自定义对话体验。数据代理最多可连接到五个探索，并使用自然语言指令来提供背景信息、定义术语和设置行为准则。
在构建智能体和撰写指令时遵循最佳实践，对于调整智能体的回答以满足特定用户需求并提高总体准确性至关重要。这些最佳实践包括为特定领域设计专业智能体和撰写清晰有效的指令。
构建专业智能体
虽然构建一个全局数据代理来处理所有业务问题可能很诱人，但代理在专门针对特定领域（例如销售、营销或产品分析）时表现最佳。如果智能体专注于一个或几个密切相关的探索，则可以为其提供更精确的指令，从而减少歧义并提高回答准确率。
设计代理时，请避免构建单个代理来处理所有不相关的数据模型。您可以为不同的业务领域创建专注型代理，并仅连接到密切相关的探索。例如，您可以创建一个专门关注Orders和Transactions探索的“收入智能体”，而不是使用一个智能体来处理所有公司数据。
撰写有效的智能体指令
智能体指令是自定义数据智能体行为并融入组织特有的业务逻辑和术语的主要工具。您可以将指令视为一种指导智能体如何解读用户问题、处理模糊不清之处并以对用户最有帮助的方式做出回答的方法。撰写清晰的指令是生成准确、相关且可靠的回答的关键。
创建数据智能体时，在指令字段中输入智能体指令。如需详细了解如何创建代理，请参阅创建和管理探索数据代理文档页面。
如需编写有效的指令，请遵循以下最佳实践：
- 定义业务背景和默认行为：指导代理了解组织的独特逻辑和术语。使用说明来定义缩写（例如，“LY 表示去年”）、说明常见的过滤逻辑，或针对模糊不清的情况设置默认行为（例如，“如果未提供
date_created，则过滤到过去 6 个月”）。 - 使用 LookML 和过滤条件语法：在指令中引用字段或应用过滤条件时，请使用 LookML 语法（例如
events.date_created）和过滤条件语法（例如"last 6 months"）。这样可确保代理了解要应用哪些字段或过滤条件。例如：“当用户询问‘区域’时，使用account_holder.geo_region字段。” - 简洁明了：写作时要清晰明了，避免在说明中出现不必要的字词或重复内容。
- 避免冗余：请勿重复显示应在 LookML 中显示的信息，例如字段说明或同义词。如需详细了解何时在 LookML 中定义上下文，何时在代理指令中定义上下文，请参阅何时向 LookML 添加上下文，何时向对话式分析添加上下文。此外，还应避免解释代理已了解的基本概念，例如维度和指标之间的区别或如何执行基本日期过滤。
智能体指令的限制
在编写智能体指令时，请注意 Conversational Analytics 的以下限制：
- 对话式分析不支持生成包含
pivots参数的查询。虽然 Conversational Analytics 可以一次返回多个维度的数据，但它无法像 Looker 探索界面那样将这些数据透视为单独的列。而是以“长”格式或“扁平”格式返回数据，因此数据是横向分组而不是纵向分组。 - 与受管控的 LookML 不同，指令通常是自由格式的文本，并且随着底层数据模型的不断发展，可能会变得“过时”。为避免“探索数据”代理中的指令过时，请使用经过验证的查询来定义自然语言问题及其对应的“探索”查询。
智能体指令示例
以下是一些示例指令，适用于已连接到名为 Order Items 和 Products 的 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`.
# 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 中的上下文示例：
- 与代理互动的用户是谁？导师的职责是什么？是公司内部人员还是外部人员？他们之前是否有过分析经验？
- 用户的目标是什么？在对话结束时，他们希望做出哪种类型的决策？
- 该用户会提出哪些类型的问题？
- 哪些字段与此用户最相关？例如，哪些字段应可供此用户访问，是否应始终应用某些过滤条件，或者是否应优先考虑此用户的某些字段？