验证问答效果

分析域配置完成后，必须通过实际问答验证效果。只看表是否添加、指标是否创建、健康度是否正常，并不能保证用户提问时一定回答正确。

本指南说明如何设计验证问题、如何查看 SQL 和记录、如何判断知识、指标、答案构建器、字段语义和表关系是否真正生效。

问答验证是管理维护侧对业务使用效果的交付检查。业务用户不需要证明自己“会问”，维护者需要证明系统能理解真实业务问法，并能在正确权限、正确口径和正确数据范围内稳定回答。

验证目标

问答验证要确认四件事：

1. 用户能用业务语言提问。
2. 系统能选择正确字段、过滤、分组和指标。
3. 答案能用正确业务口径解释结果。
4. 系统使用的事实来源、知识和数据范围是可信且当前有效的。

这四件事分别对应管理维护侧的责任：

验证时不要只看最终答案。至少要看：

• 最终文字答案。
• 表格或图表。
• SQL语句。
• 记录。

验证前准备

建议先准备一组固定测试问题，覆盖当前分析域的核心业务场景。

同时建议为每个测试问题补充：

测试问题应包括：

如果分析域不包含某类能力，可以跳过对应问题。

建议建立两类问题集

上线准入问题集不宜过大，但必须覆盖业务最常问、最不能错的问题。回归验证问题集可以从线上反馈和历史错误中持续补充。

第一步：验证简单问题

先验证一个最简单、结果可预期的问题。

示例：

检查点：

• 答案数字是否正确。
• SQL 是否使用正确表。
• WHERE 是否包含正确口径，例如

  active_subscription = TRUE

  active_subscription = TRUE
  。
• 记录中是否命中知识、指标或表结构。

在测试环境的一次实际验证中，该问题返回 464，并使用

active_subscription = TRUE

简单问题验证通过后，再测试过滤、分组和复杂口径。

第二步：验证知识是否生效

知识用于解释业务词和口径。验证时应使用用户真实会说的业务词，而不是字段名。

示例：

检查记录中是否出现：

• search_knowledge

  search_knowledge
• 命中的知识名称、知识详情或 Knowledge ID

• get_knowledge_detail

  get_knowledge_detail
• 知识中的业务口径

如果知识生效，记录会显示系统先搜索知识，再根据知识中的口径继续执行。

如果没有命中知识：

• 检查知识是否加入当前分析域。
• 检查知识是否启用。
• 检查知识中是否包含用户使用的词。
• 检查是否需要补充同义词。

第三步：验证过滤条件

过滤条件用于确认系统能否把用户自然语言转成 WHERE 条件。

示例：

检查 SQL：

• 是否有

  plan = 'Basic'

  plan = 'Basic'
  。
• 是否仍保留活跃账户口径。
• 是否使用正确大小写。

实际验证中，系统会先确认

plan

Basic

建议再测试不同类型过滤：

如果过滤失败，优先检查字段别名、字段描述、字段用途、索引和真实取值。

第四步：验证维度分组

维度分组用于确认系统能否把“按某字段”转成 GROUP BY。

示例：

检查 SQL：

• SELECT 中是否包含

  plan

  plan
  。
• GROUP BY 是否包含

  plan

  plan
  。
• 聚合函数是否正确。

建议测试：

如果分组错误，检查字段用途是否设置为维度，字段是否被隐藏，字段描述是否清晰。

第五步：验证指标

指标用于固定简单聚合口径。

示例：

检查记录：

• 是否找到指标。
• 是否执行指标计算。
• 如果指标计算失败，是否回退 SQL。

实际验证中，系统曾找到“活跃账户总数”指标，但指标计算失败后回退到 SQL 查询。这说明指标能帮助系统理解口径，但仍需检查执行是否成功。

验证指标时应确认：

• 指标是否加入当前分析域。
• 指标是否启用。
• 指标名称和别名是否能匹配用户说法。
• 指标定义是否符合业务口径。
• 指标计算是否成功。

第六步：验证答案构建器

答案构建器用于验证复杂口径、多指标、动态维度和动态过滤。

示例：

检查记录中是否出现：

• 找到答案构建器或其输出指标。

• metricType = SQL

  metricType = SQL
  。

• dims = plan

  dims = plan
  。
• 返回多个输出指标。
• 自动生成表格或图表。

再测试过滤和输出列：

检查记录中是否出现：

• filters: source = Google

  filters: source = Google

• dims = plan

  dims = plan

• outputColumns = active_account_rate, active_seats

  outputColumns = active_account_rate, active_seats

如果答案构建器没有命中：

• 检查构建器名称、别名和描述。
• 检查输出指标名称、别名和描述。
• 检查

  ${filters}

  ${filters}
  和

  ${dims}

  ${dims}
  是否配置。
• 检查过滤字段和维度字段是否绑定。

第七步：验证虚拟列

虚拟列用于确认派生字段能否被自然语言问答使用。

示例：

如果创建了姓名虚拟列，例如：

concat(first_name, ' ', last_name)

检查：

• SQL 是否使用虚拟列或对应表达式。
• 答案是否展示正确拼接结果。
• 虚拟列是否有别名和描述。
• 字段类型和用途是否合理。

如果问答没有使用虚拟列，通常需要补充字段别名、字段描述和字段用途。

第八步：验证多表问题

多表问题用于确认表关系是否正确。

示例：

检查 SQL：

• 是否 JOIN 了正确表。
• ON 条件是否正确。
• 是否存在重复或数据膨胀。
• 是否使用正确维度字段。

建议让系统在测试问题中说明用到了哪些表之间的关联。例如：

在

gaming_profiles_playstation

SELECT g.genres, COUNT(DISTINCT h.playerid) AS player_count, COUNT(*) AS achievement_count, ROUND(COUNT(*) * 1.0 / COUNT(DISTINCT h.playerid), 2) AS avg_achievements_per_player FROM quick_start.gaming_profiles_playstation.v_gpt_history h JOIN quick_start.gaming_profiles_playstation.v_gpt_achievements a ON h.achievementid = a.achievementid JOIN quick_start.gaming_profiles_playstation.v_gpt_games g ON a.gameid = g.gameid GROUP BY g.genres ORDER BY player_count DESC LIMIT 10

这条 SQL 的路径是：

1. 从玩家成就获得记录表

   v_gpt_history

   v_gpt_history
   出发。
2. 通过

   achievementid

   achievementid
   关联成就定义表

   v_gpt_achievements

   v_gpt_achievements
   。
3. 再通过

   gameid

   gameid
   关联游戏信息表

   v_gpt_games

   v_gpt_games
   。
4. 最后按游戏类型

   genres

   genres
   分组统计。

验证时不要只看系统是否“答出了表格”，还要确认 JOIN 路径是否符合业务模型。如果系统选择了错误中间表、错误关联键，或者把一对多关系处理成明细重复统计，最终数字可能看起来合理但实际已经被放大。

如果自动关联没有结果，不建议直接上线多表问答。应手工确认关系，或先限制分析域只回答单表问题。

第九步：验证归因分析

归因分析用于验证系统是否能围绕一个业务现象，自动选择多个可能影响因素，并生成分层对比、贡献占比和解释。

示例：

检查点：

• 是否围绕一个清晰目标指标分析，例如活跃用户数、活跃率、取消率或收入变化。
• 是否选用了当前分析域中真实存在的维度。
• 如果用户提到不存在的维度，是否明确提示无法分析，而不是编造字段。
• SQL 是否按维度正确分组。
• 是否同时输出差异指标和贡献指标，例如活跃率和活跃人数贡献占比。
• 是否生成图表帮助比较。
• 结论是否区分“相关性解释”和“因果结论”。

实操中，在

gaming_profiles_playstation

plan

source

归因类问题通常会触发多段 SQL 和多张图表，运行时间可能显著长于普通查数。验证时应关注 SQL 是否过重、是否需要通过答案构建器、预聚合表或限定时间范围来优化。

第十步：验证时序预测

时序预测用于验证系统是否能基于历史时间序列，预测未来一段时间的指标变化。

示例：

检查点：

• 是否选择了正确的时间字段。
• 是否按合适粒度聚合，例如按天、周、月。
• 是否明确历史数据范围和预测周期。
• 是否识别并处理未完结周期或异常数据。
• 是否触发预测能力，而不只是画历史趋势图。
• 是否给出预测值、置信区间、预测依据和风险说明。
• 是否生成趋势图或预测图。

实操中，在

gaming_profiles_playstation

时序预测结果需要谨慎解释。预测可以用于趋势预判和监控，但不应被当作确定结果。对生产场景，应由 BI 分析师检查 SQL、记录、训练数据范围、异常数据处理和置信区间。

如何阅读记录

记录可以帮助判断系统是否按预期执行。

常见记录信号：

验证时应把记录作为主要证据，而不是只看最终回答。

如何判断验证通过

一个问题可以认为验证通过，需要同时满足：

• 答案结果符合预期。
• SQL 使用了正确表和字段。
• 过滤条件正确。
• 分组维度正确。
• 聚合逻辑正确。
• 记录中命中了预期配置，或合理回退。
• 自然语言解释符合业务口径。

如果只满足“数字看起来对”，但 SQL 或记录不对，不应视为通过。

推荐验证矩阵

plan

dims = plan

source = Google

outputColumns

验证问题设计原则

好的验证问题应覆盖不同能力：

• 一个简单总数问题。
• 一个同义词问题。
• 一个过滤问题。
• 一个分组问题。
• 一个多指标问题。
• 一个复杂口径问题。
• 一个图表问题。
• 一个边界问题。

不要只问系统最容易答对的问题。应故意覆盖容易出错的表达，例如：

• 用户说业务词而不是字段名。
• 用户使用小写枚举值，例如

  google

  google
  。
• 用户只要求部分输出指标。
• 用户同时要求过滤和分组。
• 用户使用相似字段容易混淆的概念。

常见验证失败处理

${filters}

${dims}

配置变更后的回归验证

分析域配置不是一次性工作。只要修改了字段、知识、指标、答案构建器或表关系，都建议重新验证相关问题。

${filters}

${dims}

如果只是补充描述，也可能改变系统选择字段或理解业务词的方式。因此对核心问题应保留一组固定测试集，每次重要配置调整后都跑一遍。

验证报告建议

上线前可以记录一份简单验证报告：

这样可以避免上线后无法追溯“为什么认为这个分析域已经可用”。

上线前最小验证集

如果时间有限，至少验证以下 5 个问题：

1. 一个核心总数问题。
2. 一个核心业务词问题。
3. 一个带过滤条件的问题。
4. 一个按常用维度分组的问题。
5. 一个命中答案构建器的复杂问题。

每个问题都要查看最终答案、SQL语句和记录。

分析域验证的目标，不是证明系统”能回答”，而是证明管理维护工作已经足够支撑业务人员用自然语言稳定得到正确答案。只有当典型业务问题能按正确业务口径、正确字段、正确配置和正确权限边界回答时，才建议开放给业务用户。

相关文档

• 上线检查分析域 — 健康度扫描与上线前检查清单
• 排查问答准确性问题 — 常见问题的诊断与修复
• 配置分析域 — 分析域的创建与数据配置
• 配置字段语义 — 字段别名、描述、用途的配置
• 配置知识 — 业务口径与术语解释
• 指标与答案构建器 — 指标和答案构建器的创建与配置