答案构建器最佳实践

答案构建器用于把复杂 SQL 口径封装成可被自然语言问答复用的分析模板。它不是简单的 SQL 保存工具，而是让系统在回答问题时能够动态选择维度、过滤条件和输出指标的可执行语义资产。

当一个分析问题涉及多指标组合、复杂过滤、跨字段计算、明细查询或多表关联时，答案构建器通常比普通指标更合适。

预览

适用场景

答案构建器的核心价值，是把“模型容易临时推错的复杂分析逻辑”变成“可配置、可验证、可复用的 SQL 模板”。下面这些场景都适合优先考虑答案构建器。

active_subscription = TRUE

${dims}

${filters}

实际验证中，“账户健康概览”就是一个典型答案构建器场景。它把账户数、活跃账户数、活跃率、总席位和活跃席位放在同一个 SQL 模板中，用户可以继续通过自然语言指定：

• 按

  plan

  plan
  分组。
• 只看

  source = Google

  source = Google
  。
• 只返回活跃率和活跃席位。

系统会把这些自然语言要求转成

dims

filters

outputColumns

核心概念

答案构建器的 SQL 模板中最重要的是两个占位符：

${filters}

${dims}

实际测试中，未选择过滤条件时，

${filters}

1=1

${dims}

1

页面流程总览

新建答案构建器不是一个“填完 SQL 就保存”的单步表单。页面实际会按以下流程推进：

${filters}

${dims}

因此，答案构建器保存后在问答记录中经常表现为“执行指标计算”。这是因为系统会把答案构建器的输出字段注册成可执行的 SQL 指标实例。你不需要因此困惑：这里的”指标”并不等同于手工创建的普通聚合指标，而是答案构建器生成的可执行输出。

推荐设计方法

1. 一个构建器封装一组强相关指标

答案构建器最有价值的用法，是围绕一个业务主题封装一组相关指标，而不是只保存一个简单计数。

例如“账户健康概览”可以同时输出：

total_accounts

active_accounts

active_account_rate

total_seats

active_seats

这样用户可以直接问：

系统会选择该答案构建器，传入

dims = plan

2. 把稳定口径写死，把变化条件留给占位符

SQL 中应固化不会随问题变化的业务规则，把会变化的部分留给

${filters}

${dims}

示例：

SELECT ${dims}, COUNT(*) AS total_accounts, SUM(CASE WHEN active_subscription = TRUE THEN 1 ELSE 0 END) AS active_accounts, ROUND( SUM(CASE WHEN active_subscription = TRUE THEN 1 ELSE 0 END) * 1.0 / COUNT(*), 4 ) AS active_account_rate, SUM(seats) AS total_seats, SUM(CASE WHEN active_subscription = TRUE THEN seats ELSE 0 END) AS active_seats FROM ns227206.public.v_gpt_accounts WHERE ${filters} GROUP BY ${dims}

这里，活跃账户的业务口径固定为

active_subscription = TRUE

dims = plan

filters: source = Google

dims = country

3. 对过滤字段和维度字段做显式绑定

运行校验成功后，页面会进入“配置过滤和维度”步骤。

如果 SQL 中包含

${filters}

如果 SQL 中包含

${dims}

实际测试中，过滤字段列表会包含更多字段，例如

account_name

id

email

plan

source

seats

created_at

seats

latitude

longitude

这一步会直接影响问答能否正确理解“按 plan”“只看 Google 来源”“按国家”等表达。

4. 理解页面上可选的

${filters}

${filters}

和

${dims}

${dims}

字段

在”配置过滤和维度”步骤中，页面不会让你手写

${filters}

${dims}

字段来源于 SQL 模板中使用到的表。实际操作时，点击 添加过滤 或 添加维度 后，系统会让你先选择表；选择表后，再展示该表中可用于过滤或分组的字段。

实操中，

v_gpt_accounts

• account_name

  account_name

• id

  id

• email

  email

• first_name

  first_name

• last_name

  last_name

• plan

  plan

• source

  source

• seats

  seats

• created_at

  created_at

• trial_ends_at

  trial_ends_at

• canceled_at

  canceled_at

• trial_converted

  trial_converted

• active_subscription

  active_subscription

• legacy_plan

  legacy_plan

• latitude

  latitude

• longitude

  longitude

• country

  country

而在维度字段里，页面主要展示了：

• id

  id

• email

  email

• first_name

  first_name

• last_name

  last_name

• plan

  plan

• source

  source

• created_at

  created_at

• trial_ends_at

  trial_ends_at

• canceled_at

  canceled_at

• trial_converted

  trial_converted

• active_subscription

  active_subscription

• legacy_plan

  legacy_plan

• country

  country

可以看到，过滤字段范围通常更宽；维度字段会更偏向“可分组”的字段。像

seats

latitude

longitude

如果希望某个字段更容易出现在维度或过滤配置中，应先在表字段配置里补充字段信息：

plan

建议在配置答案构建器前，先检查参与 SQL 的表字段：

• 用于

  ${filters}

  ${filters}
  的字段，应适合表达用户常见筛选条件。
• 用于

  ${dims}

  ${dims}
  的字段，应适合分组展示，且基数不要过高。
• 数值型度量字段不要随意配置为维度，否则可能产生大量无意义分组。
• ID、邮箱、姓名等高基数字段虽然可能出现在维度列表中，但通常不适合默认推荐给业务用户做分组分析。
• 日期字段如果用于维度，最好明确用户希望按日、周、月还是年分析，避免分组粒度过细。

5. 为输出字段补充业务化名称、别名和描述

答案构建器会根据 SQL 输出字段分别创建指标。如果只保留技术字段名，问答仍能使用，但结果和记录中可能出现

active_account_rate_metric

active_seats_metric

建议在保存前补充：

字段名可以保持 SQL 可读，但展示给用户的名称应尽量业务化。

6. 必须使用预览验证

答案构建器保存前应先点击 运行校验 和 预览。

实际测试中发现：

${filters}

SQL缺少过滤条件参数

${filters}

${dims}

预览默认不带过滤和维度时，会返回整体结果。用户问题触发时，系统会根据自然语言传入具体维度、过滤条件和输出列。

需要特别注意：预览结果和问答结果可能不同，这通常不是错误。

${dims}

1

dims = plan

outputColumns

source = Google

7. 用 SQL 和记录确认是否真正生效

答案构建器是否被问答使用，不建议只看最终文字答案，应同时查看 SQL语句 和 记录。

在实际验证中，一个命中答案构建器的问题会在记录中出现类似信息：

• 找到匹配的答案构建器或指标。
• 执行指标计算，

  metricType

  metricType
  为

  SQL

  SQL
  。
• 参数中包含

  dims

  dims
  、

  filters

  filters
  或

  outputColumns

  outputColumns
  。
• SQL 中会看到

  ${filters}

  ${filters}
  、

  ${dims}

  ${dims}
  已被替换成实际字段和条件。

例如用户问“只看 source 为 google 的账户健康概览，按 plan 展示活跃率和活跃席位”时，记录中可以看到：

dims = plan

filters: source = Google

outputColumns = active_account_rate, active_seats

如果记录中没有命中答案构建器，而是临时查看表结构并生成 SQL，说明构建器名称、别名、描述或输出指标信息可能不够清晰，需要补充语义信息。

实操验证案例

案例一：按 Plan 展示账户健康概览

用户提问：

系统行为：

1. 找到答案构建器“账户健康概览”。
2. 识别用户需要按

   plan

   plan
   分组。
3. 传入

   dims = plan

   dims = plan
   。
4. 一次性返回多个指标。
5. 自动生成表格和组合图，并给出业务洞察。

实际结果中，系统返回了 Basic、Business、Premium 三类 Plan 的账户数、活跃账户数、活跃率、总席位和活跃席位，并指出 Business Plan 账户数量少但活跃率和席位利用表现最好。

案例二：按过滤条件查看同一组指标

用户提问：

系统行为：

1. 先查询

   source

   source
   字段中的真实取值，确认存储格式是

   Google

   Google
   。
2. 继续使用同一个答案构建器。
3. 传入

   dims = plan

   dims = plan
   。
4. 传入

   filters: source = Google

   filters: source = Google
   。
5. 只选择用户要求的输出列：

   active_account_rate

   active_account_rate
   和

   active_seats

   active_seats
   。

这说明答案构建器不仅能固定 SQL 口径，还能让系统在问答时动态选择维度、过滤条件和输出字段。

与指标、知识的配合

答案构建器通常不应孤立使用。

实际问答中，系统会先搜索知识，理解“活跃账户”等业务概念；再查找可用指标和答案构建器；如果找到匹配的答案构建器，会优先使用其 SQL 模板执行计算。

名称、别名和描述怎么写

答案构建器里有几类名称，含义不同，建议不要混用。

active_account_rate

一个常见误区是只给答案构建器写了清晰名称，但输出字段仍保留英文技术名。这样系统可以执行，但最终答案、图表字段或记录里仍可能出现

active_account_rate_metric

常见问题与处理建议

${filters}

WHERE

${filters}

${dims}

${dims}

GROUP BY ${dims}

${dims}

1

metricType = SQL

dims

filters

建议检查清单

上线一个答案构建器前，建议逐项检查：

• SQL 中是否包含必要的

  ${filters}

  ${filters}
  。
• 需要动态分组时，是否包含

  ${dims}

  ${dims}
  和

  GROUP BY ${dims}

  GROUP BY ${dims}
  。
• 过滤字段是否覆盖用户常用筛选条件。
• 维度字段是否覆盖用户常用拆分方式。
• 输出字段是否都配置了业务化指标名。
• 输出字段是否补充了别名和描述。
• 比例类指标是否使用合适的 POP 表达式。
• 预览运行结果是否符合预期。
• 是否用自然语言验证过典型问题。
• 构建器名称和描述是否能让系统准确匹配。

设计建议

答案构建器的颗粒度应围绕“一个业务分析主题”设计。

推荐：

• 账户健康概览

  账户健康概览

• 订单转化分析

  订单转化分析

• 渠道投放效果

  渠道投放效果

• 客户留存分析

  客户留存分析

• 交易明细查询

  交易明细查询

不推荐：

• 把完全无关的指标放进一个构建器。
• 为每个简单 COUNT 单独创建答案构建器。
• 只写 SQL，不配置过滤字段、维度字段和业务描述。
• 输出字段全部保留英文技术名。

一个好的答案构建器应该让用户可以自然地问：

而不是要求用户知道底层表名、字段名和 SQL 逻辑。

相关文档

• 指标与答案构建器 — 答案构建器的创建流程与配置参考
• 配置分析域 — 分析域的创建与数据配置
• 分析域配置原则与常见问题 — 配置过程中的踩坑经验与 FAQ
• 问答准确率提升 — 语义层配置的整体方案