复杂指标同环比的语义建模：让大模型秒懂"去年同期"与"上月累计"
在对话式取数系统（ChatBI）的实际问答中，“同环比分析”是业务管理层出现频率最高、但也是最容易把大模型和后台语义引擎干翻的复杂计算场景。
业务提问时往往非常随性：
- “看一下我们上周各省份 GMV 的周环比（WoW）和年同比（YoY）”；
- “本月截止到昨天的累计销售额，比上个月同期增长了多少？”；
- “查一下今年 Q3 至今与去年 Q3 全期的达成进度对比”。
如果把这些自然语言直接交给大模型去写物理 SQL，模型通常需要在同一个查询里拼写大量复杂的LAG()、DATE_SUB、多层自连接和条件聚合，生成的 SQL 动辄上百行，而且极容易在闰年、大月小月、自然周与跨年周等时间边界上算错。
今天我们深入拆解如何在语义层（Semantic Layer）中，通过时间维度建模与派生度量模板（Derived Metric Template），让大模型只需要声明基础指标和时间偏移，由语义引擎自动编译出绝对可靠的高性能同环比 SQL。
为什么同环比不能让大模型直接手写 SQL？
在数仓实际查询中，同环比计算看似简单，实则隐藏着三大业务暗坑：
1. 严格日历对齐 vs 星期对齐（52 周问题）
业务在看零售日销量同比时，绝对不能简单地拿2026-09-03（周四）去对比2025-09-03（周三）。因为周三和周四的客流基准不同，零售行业通常要求按 ISO 周对齐（即对比去年同周的周四，即2025-09-04）。大模型很难在没有上下文的情况下准确判断业务到底是要求“日期对齐”还是“星期对齐”。
2. MTD / QTD / YTD 周期累计对齐（Partial Period Alignment）
今天是 9 月 3 日，业务问“本月至今（MTD）的环比”。正确的对比区间是8月1日~8月3日，而不是整个 8 月份（8月1日~8月31日）。直接写 SQL 时，需要动态计算出当天是月份的第几天，并截断对比周期的上界。大模型极其容易遗漏截断逻辑，导致拿 3 天的数据去和上月 31 天的数据比较，得出“环比暴跌 90%”的荒谬结论。
3. 数据稀疏导致的自连接空洞
如果某门店在去年同期没有营业（数据为空），普通的INNER JOIN会导致该门店在今年的同比列表中彻底消失，破坏了总体大盘的聚合基数。
语义层时间模型设计：企业级标准日历维表（Date Dim）
所有优雅的同环比计算，都建立在一张设计精良的标准日历维表之上：
CREATE TABLE dim_date_calendar_df ( date_id DATE PRIMARY KEY, -- 2026-09-03 year_actual INT, -- 2026 month_actual INT, -- 9 day_of_month INT, -- 3 iso_year INT, -- 2026 iso_week INT, -- 36 day_of_week INT, -- 4 (周四) is_weekend BOOLEAN, -- FALSE is_holiday BOOLEAN, -- FALSE -- 核心：预先固化严格对齐的历史对应日期键 prev_day_date DATE, -- 2026-09-02 (日环比对齐) prev_week_date DATE, -- 2026-08-27 (周同比对齐：上周四) prev_month_date DATE, -- 2026-08-03 (月环比对齐：上月3号) prev_year_date DATE, -- 2025-09-03 (自然日年同比对齐) prev_year_iso_date DATE -- 2025-09-04 (同周同天年同比对齐) );有了这张日历表，复杂的日期偏移计算就从动态函数运算退化为简单的高性能主键关联。
语义层 YAML 派生度量配置规范
在语义模型中，我们不需要为每个基础指标（GMV、订单数、DAU）分别手写一套同环比公式，而是定义通用的时间修饰模版（Time Modifiers）：
# 基础原子指标 measures: - name: gmv title: 销售总额 sql: SUM(pay_amount) type: decimal # 声明支持的派生时间变换维度 time_dimensions: - name: order_date sql: dt type: date # 派生度量自动构建规则 derived_measures: - name: gmv_mom_ratio title: GMV月环比增长率 base_measure: gmv calculation: "( {gmv} - {gmv_prev_month} ) / NULLIF({gmv_prev_month}, 0)" requires: - name: gmv_prev_month base_measure: gmv time_shift: -1_month alignment: same_day_of_month - name: gmv_yoy_ratio title: GMV年同比增长率 base_measure: gmv calculation: "( {gmv} - {gmv_prev_year} ) / NULLIF({gmv_prev_year}, 0)" requires: - name: gmv_prev_year base_measure: gmv time_shift: -1_year alignment: iso_weekday大模型意图识别与语义编译器代码生成
当用户输入：“看看 8 月份华东大区 GMV 的年同比和月环比”，大模型输出极其干净的意图 JSON：
{ "cube": "trade_cube", "measures": [ "gmv", "gmv_mom_ratio", "gmv_yoy_ratio" ], "dimensions": ["region"], "filters": [ {"field": "region", "op": "eq", "value": "华东"}, {"field": "order_date", "op": "between", "value": ["2026-08-01", "2026-08-31"]} ] }语义引擎根据 YAML 模板，自动编译出标准而稳健的 CTE（公共表表达式）物理 SQL：
WITH current_period AS ( SELECT t.region, SUM(t.pay_amount) AS gmv FROM dws_trade_daily_di t WHERE t.region = '华东' AND t.dt >= '2026-08-01' AND t.dt <= '2026-08-31' GROUP BY t.region ), prev_month_period AS ( SELECT t.region, SUM(t.pay_amount) AS gmv_prev_month FROM dws_trade_daily_di t WHERE t.region = '华东' AND t.dt >= '2026-07-01' AND t.dt <= '2026-07-31' GROUP BY t.region ), prev_year_period AS ( SELECT t.region, SUM(t.pay_amount) AS gmv_prev_year FROM dws_trade_daily_di t WHERE t.region = '华东' AND t.dt >= '2025-08-01' AND t.dt <= '2025-08-31' GROUP BY t.region ) SELECT c.region, c.gmv, ROUND((c.gmv - m.gmv_prev_month) / NULLIF(m.gmv_prev_month, 0) * 100, 2) AS gmv_mom_pct, ROUND((c.gmv - y.gmv_prev_year) / NULLIF(y.gmv_prev_year, 0) * 100, 2) AS gmv_yoy_pct FROM current_period c LEFT JOIN prev_month_period m ON c.region = m.region LEFT JOIN prev_year_period y ON c.region = y.region;生产落地的三条核心建议
- 分母除零保护是铁律：所有同环比计算公式中，分母必须强制包裹
NULLIF(denominator, 0)，严禁直接相除抛出Division by zero异常导致看板崩溃。 - 显式声明百分比格式与正负号渲染：语义层输出元数据中应当包含
formatter: "+0.00%"，让前端自动为正增长渲染绿色/红色箭头，降低业务认知负荷。 - 把跨年边界作为单元测试核心用例：每年 1 月和每季初是同环比 Bug 的高发期。必须在 CI 流水线中加入针对 1月1日对比12月31日、闰年 2月29日对比 2月28日的自动化断言测试。
