指标口径体系与验证运维指南

本文面向 Analytics Agent 的语义建设和治理人员,讲清楚指标、答案构建器、知识库三种机制如何协同,以及交付前必做的验证与运维。

Analytics Agent 提供三种口径定义机制——指标(Metric)答案构建器(Answer Builder)知识库(Knowledge Base),它们共同构成 LLM 理解业务语义的上下文。本文讲清楚三者各自的适用边界、协同方式,以及交付前必做的验证与运维。

概述

三者都是给 LLM 的 DSL(领域特定语言),LLM 读取它们来理解业务语义,然后自己生成 SQL。它们不是给数据库的可执行指令——这是理解后续所有规则的前提。

机制形态角色
指标(Metric)单表聚合表达式口径定义——用聚合表达式固化单表指标的计算逻辑,并告诉 LLM「这个域里有这个指标」
答案构建器(Answer Builder)多表 SQL 模板 + 维度声明分析模板——用 SQL 模板固化跨表 JOIN 路径与聚合口径,并告诉 LLM「这个概念支持这些维度下钻」
知识库(Knowledge Base)Markdown 文档自由文本——补充业务规则、公式说明、分析场景

指标(Metric)

适用场景

满足全部以下条件时用指标(而非答案构建器):

  • 所有字段来自同一张表
  • 表达式是纯聚合(SUM/COUNT/AVG/MAX/MIN),无子查询、无窗口函数
  • 表达式中的字符串比较值在 GPT 视图上直接可用(不依赖虚拟列)
  • 不需要通过 API 做程序化时间序列调用(
    metric_calculate
    metric_calculate

创建

cz-cli analytics-agent metric create \ --domain-id <domain-id> --datasource-id <datasource-id> \ --table-name "sales_demo.v_gpt_fact_order" \ --name "GMV" \ --expression "ROUND(SUM(CASE WHEN order_status = 'completed' THEN gross_amount ELSE 0 END), 2)" \ --alias "总销售额" --alias "营收" \ --description "已完成订单的挂牌金额总额(gross_amount,含折扣前)"

注意事项

不要引用虚拟列。虚拟列(

column virtual set
column virtual set
)不会持久化到 GPT 视图,以下写法会报错:

-- ❌ 错误:虚拟列 is_completed_flag 在 GPT 视图中不可解析 SUM(is_completed_flag) -- ✅ 正确:内联 CASE WHEN SUM(CASE WHEN order_status = 'completed' THEN 1 ELSE 0 END)

不要使用相关子查询。GPT 视图不支持相关子查询的外层引用,会导致静默错误:

-- ❌ 错误:GPT 视图中外层引用丢失,返回错误值但不报错 CASE WHEN (SELECT COUNT(*) FROM v_gpt_fact_order fo2 WHERE fo2.member_key = v.member_key) = 1 THEN ... -- ✅ 正确:改用答案构建器,用 GROUP BY 实现

完整示例

以下指标代表典型的最佳用法:

GMV 表达式: ROUND(SUM(CASE WHEN order_status='completed' THEN gross_amount ELSE 0 END), 2) 别名: "总销售额", "营收", "挂牌GMV" 说明: 已完成订单的挂牌金额总额。单表(fact_order),纯聚合,无子查询。 客单价 表达式: ROUND(SUM(CASE WHEN order_status='completed' THEN net_amount ELSE 0 END) / NULLIF(SUM(CASE WHEN order_status='completed' THEN 1 ELSE 0 END), 0), 2) 说明: 分子分母都加了过滤,NULLIF 防除零。 单均配送成本 表达式: ROUND(SUM(CASE WHEN fulfillment_type='delivery' AND order_status='completed' THEN delivery_fee_cost ELSE 0 END) / NULLIF(SUM(CASE WHEN fulfillment_type='delivery' AND order_status='completed' THEN 1 ELSE 0 END), 0), 2) 说明: 同时过滤 fulfillment_type 和 order_status。

答案构建器(Answer Builder)

适用场景

满足任一以下条件时用答案构建器:

  1. 跨表:指标的计算或维度涉及多张表
  2. 需要维度下钻:用户需要「按 XXX 看 YYY」的分析
  3. 需要子查询/窗口函数:表达式超出纯聚合能力
  4. 需要锁定 JOIN 路径:消除多表场景下的二义性

创建

答案构建器包含 DSL(

--content
--content
)和 SQL 模板(
--sql
--sql
)两部分:

cz-cli analytics-agent answer-builder create \ --domain-id <domain-id> --datasource-id <datasource-id> \ --analysis-name "门店层面利润代理" \ --analysis-desc "净收入−(配送+佣金)按门店汇总" \ --content '{...}' \ --sql "SELECT \${dims}, ... GROUP BY \${dims}"

DSL 字段说明

字段必填说明
chartParams[].name
chartParams[].name
占位符名,在 SQL 中用
${name}
${name}
引用。约定
dims
dims
filters
filters
chartParams[].type
chartParams[].type
dimension
dimension
filter
filter
chartParams[].fromTableRefs[].tableName
chartParams[].fromTableRefs[].tableName
GPT 视图全路径
chartParams[].fromTableRefs[].columns
chartParams[].fromTableRefs[].columns
可用维度/过滤列。必须与 GPT 视图实际列名一致,且在 SQL 模板 FROM/JOIN 中可解析
outputColumns[].name
outputColumns[].name
必须与 SQL 中
AS
AS
别名完全一致
outputColumns[].metricName
outputColumns[].metricName
域内唯一。建议
ab_
ab_
前缀避免与 metric 名冲突
outputColumns[].type
outputColumns[].type
ClickZetta 数据类型
outputColumns[].stdTypeName
outputColumns[].stdTypeName
标准类型(int / double / string)
relatedTables
relatedTables
SQL 中所有 GPT 视图的全路径

SQL 模板编写规范

字符串常量:chr() 拼接

因 shell 引号冲突,字符串常量须用

chr()
chr()
拼接:

-- ❌ 错误:单引号与 shell 引号冲突 WHERE order_status = 'completed' -- ✅ 正确 WHERE order_status = chr(99)||chr(111)||chr(109)||chr(112)||chr(108)||chr(101)||chr(116)||chr(101)||chr(100)

常用 ASCII:c=99, o=111, m=109, p=112, l=108, e=101, t=116, d=100, '=39, -=45

${dims}
${dims}
位置规则

✅ SELECT ${dims}, agg1, agg2 FROM ... GROUP BY ${dims} ✅ SELECT * FROM (SELECT ${dims}, agg1 FROM ... GROUP BY ${dims}) t ❌ SELECT ${dims}, total FROM (SELECT ch AS channel, COUNT(*) AS total FROM ...) t → 跨子查询边界列重命名后解析失败

窗口函数:放子查询内,外层

SELECT *
SELECT *
包裹:

SELECT * FROM ( SELECT ${dims}, COUNT(*) AS cnt, ROW_NUMBER() OVER (ORDER BY COUNT(*) DESC) AS rnk FROM ... GROUP BY ${dims} ) t

CTE

WITH t AS ( SELECT ${dims}, COUNT(*) AS cnt FROM ... GROUP BY ${dims} ) SELECT * FROM t

SQL 典型样例

以下样例覆盖从单表到多表 JOIN 的常见复杂度梯度。

样例一:单表 + filter(最简模式)

场景:按渠道和履约类型统计订单数和 GMV,可过滤订单状态。

SELECT ${dims}, COUNT(DISTINCT fo.order_id) AS orders, ROUND(SUM(CASE WHEN fo.order_status = chr(99)||chr(111)||chr(109)||chr(112)||chr(108)||chr(101)||chr(116)||chr(101)||chr(100) THEN fo.net_amount ELSE 0 END), 2) AS gmv FROM sales_demo.v_gpt_fact_order fo WHERE ${filters} GROUP BY ${dims}

对应 chartParams:dims 可选

channel
channel
fulfillment_type
fulfillment_type
pay_method
pay_method
;filters 可选
order_status
order_status
channel
channel

样例二:两表 JOIN + 维度下钻

场景:按门店维度(名称/城市/商圈/形态)统计 GMV 和订单数。

SELECT ${dims}, COUNT(DISTINCT fo.order_id) AS orders, ROUND(SUM(CASE WHEN fo.order_status = chr(99)||chr(111)||chr(109)||chr(112)||chr(108)||chr(101)||chr(116)||chr(101)||chr(100) THEN fo.net_amount ELSE 0 END), 2) AS gmv FROM sales_demo.v_gpt_dim_store ds JOIN sales_demo.v_gpt_fact_order fo ON ds.store_key = fo.store_key GROUP BY ${dims}

对应 chartParams:dims 可选

store_name
store_name
city
city
city_tier
city_tier
trade_zone_type
trade_zone_type
store_format
store_format

关键点:维度列来自 dim_store,度量来自 fact_order——跨表维度下钻的典型模式。

样例三:三表 JOIN(订单→明细→商品)

场景:按商品品类和日期统计销量和 GMV。

SELECT ${dims}, SUM(foi.quantity) AS cups, ROUND(SUM(foi.item_gross_amount - foi.item_discount_amount), 2) AS revenue FROM sales_demo.v_gpt_fact_order fo JOIN sales_demo.v_gpt_fact_order_item foi ON fo.order_id = foi.order_id JOIN sales_demo.v_gpt_dim_sku ds ON foi.sku_key = ds.sku_key WHERE fo.order_status = chr(99)||chr(111)||chr(109)||chr(112)||chr(108)||chr(101)||chr(116)||chr(101)||chr(100) GROUP BY ${dims}

对应 chartParams:dims 可选

category_l1
category_l1
category_l2
category_l2
sku_name
sku_name
year
year
month
month

关键点:三表链式 JOIN(fact_order → fact_order_item → dim_sku),聚合在明细表上。

样例四:子查询 + ROW_NUMBER 排名

场景:按渠道统计订单数并排名。由于

${dims}
${dims}
不能和 ROW_NUMBER 的 PARTITION BY 共享同一列,将窗口函数放在内层子查询,外层用
SELECT *
SELECT *
包裹。

SELECT * FROM ( SELECT ${dims}, COUNT(DISTINCT order_id) AS orders, ROW_NUMBER() OVER (ORDER BY COUNT(DISTINCT order_id) DESC) AS rank FROM sales_demo.v_gpt_fact_order fo GROUP BY ${dims} ) t

对应 chartParams:dims 可选

channel
channel
fulfillment_type
fulfillment_type
order_status
order_status

关键点:①窗口函数放在内层子查询,外层

SELECT *
SELECT *
包裹——这是 AB 中使用窗口函数的唯一可靠模式;②
${dims}
${dims}
在内层直接用于 GROUP BY 和 SELECT,与 ROW_NUMBER 在同一作用域。

样例五:INNER JOIN 子查询——会员预聚合

场景:按会员等级分析复购率——先用子查询统计每会员订单数,再 JOIN 会员维度。

SELECT ${dims}, COUNT(DISTINCT m.member_key) AS total_members, COUNT(DISTINCT CASE WHEN o.order_cnt >= 2 THEN m.member_key END) AS repurchase_members, ROUND(COUNT(DISTINCT CASE WHEN o.order_cnt >= 2 THEN m.member_key END) * 100.0 / NULLIF(COUNT(DISTINCT m.member_key), 0), 2) AS repurchase_rate FROM sales_demo.v_gpt_dim_member m JOIN (SELECT member_key, COUNT(*) AS order_cnt FROM sales_demo.v_gpt_fact_order WHERE order_status = chr(99)||chr(111)||chr(109)||chr(112)||chr(108)||chr(101)||chr(116)||chr(101)||chr(100) GROUP BY member_key) o ON m.member_key = o.member_key GROUP BY ${dims}

对应 chartParams:dims 可选

member_tier
member_tier
register_channel
register_channel
city
city

关键点:①用 INNER JOIN(而非 LEFT JOIN)确保分母为「有购买记录的会员」;②子查询只做预聚合,不引用

${dims}
${dims}
——dims 在外层直接来自 dim_member;③这是替代 GPT 视图相关子查询的标准模式。

样例六:事实表 + 多维度表联查——断货分析

场景:按商品和月份分析断货天数、断货率和缺货时长。

SELECT ${dims}, SUM(CASE WHEN fss.stockout_flag = 1 THEN 1 ELSE 0 END) AS stockout_days, ROUND(SUM(CASE WHEN fss.stockout_flag = 1 THEN 1.0 ELSE 0 END) / COUNT(*) * 100, 2) AS stockout_rate, SUM(CASE WHEN fss.stockout_flag = 1 THEN fss.stockout_hours ELSE 0 END) AS stockout_hours FROM sales_demo.v_gpt_fact_store_stockout fss JOIN sales_demo.v_gpt_dim_sku ds ON fss.sku_key = ds.sku_key JOIN sales_demo.v_gpt_dim_date dd ON fss.date_key = dd.date_key GROUP BY ${dims}

对应 chartParams:dims 可选

sku_name
sku_name
category_l1
category_l1
category_l2
category_l2
year
year
month
month
stockout_reason
stockout_reason

关键点:①事实表(stockout)同时 JOIN 两张维度表(dim_sku + dim_date);②

stockout_flag
stockout_flag
在聚合函数中既作条件过滤又作计数对象。

创建前验证

cz-cli analytics-agent answer-builder validate \ --domain-id <domain-id> --datasource-id <datasource-id> \ --analysis-name "..." --content '...' --sql '...'

指标与答案构建器共存

何时两者都要

场景指标提供答案构建器提供
券核销率全局单值(Dashboard)按活动/渠道/时间下钻
门店利润全局单均利润(摘要)按门店/城市/形态对比
复购率全局复购率(单值)按会员等级/渠道/城市拆解

口径一致性

两者共存时须保持口径一致。建议在 AB 的 outputColumns 中注明来源:

description: "口径与指标『复购率』一致,≥2 次已完成购买的会员占比"

知识库(Knowledge Base)

推荐内容

文档内容
指标口径.md所有指标的计算公式、过滤条件、单位
业务规则.md枚举值含义、会员等级、订单状态
分析场景.md3-5 个典型分析场景的 SQL 模板
数据模型.md表结构、JOIN 关系图、核心字段

三源一致性规则

推荐工作流:

  1. 先在 KB 中定义口径(文档化)
  2. 再创建指标(注册为计算对象)
  3. 如需维度下钻,创建答案构建器(声明维度)
  4. 在 AB 的 description 中反向引用 KB 章节
  5. 三源口径矛盾时,以 KB 为准,同步更新 metric 和 AB

测试与验证

旁路验证法

Agent 可能改写表达式或忽略 AB 模板,唯一可靠的验证是 SQL 旁路测试:

  1. 通过 Agent 提问,得到回答
  2. 提取 Agent 回答中的关键数值
  3. 写等价 SQL,用相同数据源、JOIN 路径、过滤条件
  4. 比对数值——精确到小数点后两位

-- 验证 Agent 的「单均毛利 ¥29.84」 SELECT ROUND(SUM(CASE WHEN order_status='completed' THEN net_amount - delivery_fee_cost - platform_commission + platform_subsidy ELSE 0 END) / NULLIF(SUM(CASE WHEN order_status='completed' THEN 1 ELSE 0 END), 0), 2) FROM fact_order;

不可靠的验证方式

  • Agent 没有报错 → 可能返回外表合理的错误值
  • 数值在合理范围 → 偏差 2% 肉眼不可见
  • Agent 引用 KB 文本 → 可能引用了但按不同公式计算
  • AB 验证通过 → 验证仅检查语法,Agent 可能不执行

测试清单

验证项方法
表达式正确性SQL 旁路逐值比对
JOIN 路径正确性同名列双路径分别查 SQL,确认 Agent 选对表
过滤条件完整性边界测试:「含取消」vs「仅已完成」
维度下钻可用性Agent 提问「按 XXX 看 YYY」
同环比基线跨期对比验证时间窗口

运维最佳实践

本章描述基于 cz-cli 对分析域做二义性消歧、隐性问题消除和旁路测试的标准化操作流程。所有命令示例中的

<domain-id>
<domain-id>
<datasource-id>
<datasource-id>
、表 ID 请替换为你自己域的实际值。

二义性消歧

二义性是同一符号在系统中对应多个不同含义的现象。典型表现:同名列在不同表中代表不同概念(如

city
city
既是门店城市也是会员常驻城市),Agent 可能选错 JOIN 路径且不报错。

全量列语义扫描

# 遍历域中所有表的列语义 for dsid in $(cz-cli analytics-agent domain detail <domain-id> --with-tables --format json | \ python3 -c "import sys,json; [print(t['datasetId']) for t in json.load(sys.stdin)['data']['tables']]"); do cz-cli analytics-agent table columns $dsid --format json done

提取每个列的关键字段:

attrCode
attrCode
(列名)、
semanticType
semanticType
(类型)、
description
description
(描述)、
intendedTypes
intendedTypes
(用途)。

跨表同名列检测

将全部列名去重后,找出在多张表中重复出现的列名:

columns_by_table = {table: {col['attrCode'] for col in cols} for table, cols in scan_result} all_cols = set.union(*columns_by_table.values()) duplicates = {c for c in all_cols if sum(1 for cols in columns_by_table.values() if c in cols) > 1}

逐组对比语义

对每组同名列,对比其

description
description
,判断是同义(用于 JOIN)还是异义(需要消歧):

判断示例处理
同义(JOIN 键)
member_key
member_key
在 dim_member 和 fact_order 中
无需处理
异义(业务含义不同)
city
city
在 dim_store(门店城市)和 dim_member(会员常驻城市)
需消歧
粒度混淆
discount_amount
discount_amount
在 fact_order(订单级)和 order_item(SKU 级)
需标注

数据验证

对异义列,查询不同 JOIN 路径是否产生不同结果:

-- 路径A:门店城市(正确) SELECT ROUND(SUM(CASE WHEN fo.order_status='completed' THEN fo.net_amount ELSE 0 END),0) AS gmv FROM fact_order fo JOIN dim_store ds ON fo.store_key = ds.store_key WHERE ds.city = '上海'; -- 路径B:会员城市(错误) SELECT ROUND(SUM(CASE WHEN fo.order_status='completed' THEN fo.net_amount ELSE 0 END),0) AS gmv FROM fact_order fo JOIN dim_member dm ON fo.member_key = dm.member_key WHERE dm.city = '上海'; -- 如果两值不同且差值 > 1%,确认风险

执行消歧:更新列描述,标注 JOIN 路径和使用场景差异:

cz-cli analytics-agent table semantics set <table-id> <col-id> \ --description "门店所在城市(JOIN路径:fact_order→dim_store。分析消费地/门店业绩请用此列,分析会员户籍地用 dim_member.city)" cz-cli analytics-agent table semantics set <table-id> <col-id> \ --description "会员常驻城市(JOIN路径:fact_order→dim_member。此列代表会员户籍/常住地,非消费发生地。统计门店/地区业绩请用 dim_store.city)"

隐性问题消除

隐性问题是指系统当前不报错、但特定条件下会产生系统性错误结果的缺陷。与二义性不同——二义性是「Agent 不知道该选哪条路」,隐性问题是「Agent 自以为选对了但结果是错的」。

指标表达式审查

逐个检查每个指标的表达式是否包含以下缺陷:

缺陷检测方式修复
缺少 order_status 过滤查表达式有无 WHERE completed 或等效 CASE WHEN分子分母均加状态过滤
虚拟列引用查询该列,如果报「cannot resolve」则虚拟列不持久化改为内联 CASE WHEN
除零无保护除法表达式分母无 NULLIF加 NULLIF(..., 0)
相关子查询表达式含 (SELECT ... WHERE outer.col = inner.col)关联子查询在 GPT 视图上不可靠,改用答案构建器 GROUP BY 实现

# 逐条检查指标 cz-cli analytics-agent metric list --domain-id <domain-id> --format json | \ python3 -c "import sys,json; [print(m['id'], m['names'][0], m['aggExpr']) for m in json.load(sys.stdin)['data']]"

语义类型一致性检查:检测同类型列(Boolean/flag)的标记是否一致。检查项包括

semanticType
semanticType
(CATEGORICAL/CONTINUOUS)、
dimension
dimension
(true/false)、
intendedTypes
intendedTypes
(DIM/FILTER/MEASURE)。常见问题是 flag 类列被误标为 MEASURE 而非 DIM,需交叉比对后统一。

死维度检测:对标记为 CATEGORICAL DIM 的列,检查实际值域,NULL 率 > 90% 或 distinct 值 ≤ 1 的维度列应隐藏:

-- 检测死维度 SELECT 'product_family' AS col, COUNT(DISTINCT product_family) AS distinct_vals, ROUND(SUM(CASE WHEN product_family IS NULL THEN 1.0 ELSE 0 END)/COUNT(*)*100, 0) AS null_pct FROM dim_sku; -- 若 distinct=1 且 null_pct=95 → 死维度,应 hidden=true

# 隐藏死维度 cz-cli analytics-agent table semantics set <table-id> <col-id> --hidden true

跨表数据一致性检查:同一业务概念在不同表中枚举值是否统一(如渠道名),不一致会导致跨表聚合对不齐:

SELECT channel, COUNT(*) FROM fact_order GROUP BY channel; SELECT issue_channel, COUNT(*) FROM fact_coupon GROUP BY issue_channel; -- 若发现 fact_order 有「抖音团购核销」、fact_coupon 有「抖音直播间团购」→ 需统一枚举值

GPT 视图相关子查询验证:对含子查询的指标,同时在物理表和 GPT 视图上执行,比对结果是否一致:

-- 物理表验证(预期正确) SELECT ROUND(100.0 - COUNT(DISTINCT CASE WHEN (SELECT COUNT(*) FROM fact_order fo2 WHERE fo2.member_key = fo.member_key AND fo2.order_status = 'completed') = 1 THEN fo.member_key END) * 100.0 / NULLIF(COUNT(DISTINCT fo.member_key), 0), 2) AS rate FROM fact_order fo; -- → 92.25% -- GPT 视图验证(外层引用可能丢失,返回错误值但不报错) SELECT ROUND(100.0 - COUNT(DISTINCT CASE WHEN (SELECT COUNT(*) FROM sales_demo.v_gpt_fact_order fo2 WHERE fo2.member_key = v.member_key AND fo2.order_status = 'completed') = 1 THEN v.member_key END) * 100.0 / NULLIF(COUNT(DISTINCT v.member_key), 0), 2) AS rate FROM sales_demo.v_gpt_fact_order v; -- → 100.00%(错误!GPT 视图相关子查询外层引用丢失)

旁路测试

旁路测试(Bypass Testing)是在 Agent 的输出路径之外搭建一条独立的 SQL 验证通道,用相同的数据源和计算逻辑重新计算结果,逐项比对。这是唯一可靠的验证方式——Agent 不报错不代表结果正确。

通过 Agent 提问并记录关键数值

cz-cli analytics-agent session create --domain-id <domain-id> --title "test" --format json cz-cli analytics-agent session run --session-id <sid> --domain-id <domain-id> \ --msg "各会员等级的复购率是多少" --summary --format json

从 Agent 回答中提取可验证的数值断言,例如:普通会员复购率 90.32%、金卡会员复购率 97.33%、总体复购率 92.19%。

编写等价 SQL

使用与 Agent 声称相同的口径(如果 Agent 说明了)或与域定义一致的口径:

-- 对应 Agent 回答「总体复购率 92.19%」 WITH member_orders AS ( SELECT m.member_key, m.member_tier, COUNT(fo.order_id) AS order_cnt FROM dim_member m JOIN fact_order fo ON m.member_key = fo.member_key AND fo.order_status = 'completed' GROUP BY m.member_key, m.member_tier ) SELECT member_tier, COUNT(DISTINCT member_key) AS total, COUNT(DISTINCT CASE WHEN order_cnt >= 2 THEN member_key END) AS repurchase, ROUND(100.0 * COUNT(DISTINCT CASE WHEN order_cnt >= 2 THEN member_key END) / NULLIF(COUNT(DISTINCT member_key), 0), 2) AS rate FROM member_orders GROUP BY member_tier ORDER BY rate;

逐值比对

等级AgentSQL偏差判断
普通90.32%90.32%0
金卡97.33%97.33%0
总体92.19%92.19%0

偏差分类

偏差幅度分类处理
= 0完全一致通过
0 < ≤ 1%四舍五入或口径细微差异记录原因
1% < ≤ 5%口径差异需标注并评估是否可接受
> 5%疑似错误排查 Agent SQL 生成路径

常见陷阱

陷阱说明避免方式
GPT 视图相关子查询静默错误含相关子查询的指标在 GPT 视图上外层引用丢失,返回错误值但不报错指标不用子查询
虚拟列不持久化
column virtual set
column virtual set
创建的列在 GPT 视图中不可用
指标用内联 CASE WHEN
二义性列同名不同义的列(如 city)会导致 Agent 走错 JOIN 路径列描述标注路径;跨表指标用 AB 锁定 JOIN
三源矛盾指标、AB、KB 三处可能定义不同口径,LLM 自由裁决用哪个口径只写在一处(KB),其他两处引用 KB

创建前检查清单

指标

  • 单表,纯聚合,无子查询,无窗口函数
  • 未引用虚拟列
  • 已添加中文别名
  • description 说明计算口径和过滤条件
  • SQL 旁路验证数值正确

答案构建器

  • analysis-name 清晰描述业务概念
  • chartParams.fromTableRefs 列名与 GPT 视图一致
  • outputColumns.name 与 SQL AS 别名完全一致
  • outputColumns.metricName 以
    ab_
    ab_
    前缀,域内唯一
  • relatedTables 含所有表
  • SQL 字符串常量用 chr() 拼接
  • ${dims} 和 ${filters} 位置正确
  • 有 NULLIF 除零保护
  • validate 通过
  • Agent 提问 + SQL 旁路验证

知识库

  • 覆盖域中所有指标的口径文档
  • 业务规则文档覆盖所有枚举值
  • 分析场景文档含 3-5 个 SQL 模板
  • KB 公式与 metric/AB 一致
  • 标注二义性列的正确用法

已知限制与绕过方案

限制绕过方案
GPT 视图不支持相关子查询用答案构建器 GROUP BY 替代
虚拟列不持久化指标表达式用内联 CASE WHEN
Agent 可能不执行 AB SQL 模板将 AB SQL 写标准,旁路测试验证
字符串常量需 chr() 拼接记常用 ASCII 码
${dims} 跨子查询边界列名失败
SELECT * FROM (subquery)
SELECT * FROM (subquery)
包裹
metric rule 不可通过 CLI 配置维度下钻用答案构建器
三源无优先级规则KB 为单源真理,metric/AB 引用 KB

相关文档

联系我们
预约咨询
微信咨询
电话咨询
邮件咨询