1. 大模型生成的结果是给谁看的

随着大型模型的迅速发展，各个领域纷纷尝试利用这些模型来解决重复的人工操作，或通过引入随机性和概率性来产生多样性的输出。在SQL生成领域，各种方案层出不穷，这里不一一列举，但综合来看，大模型生成的结果更多地是供人类阅读或理解，而不是供机器（程序）理解。

人类的理解能力远远超过机器，即使大型模型生成的结果存在少量错误，人类仍能够理解。然而，如果大型模型生成的结果需要让机器来理解，则对精度的要求就变得非常高。大型模型输出结果的程序处理逻辑也会变得极度复杂，细微的错误可能导致最终结果完全偏离预期。

在数据分析领域，经过几十年的发展和各种概念的碰撞，关系型建模方法和SQL仍然是相对成熟的解决方案。SQL完全基于数学体系衍生而来，其结构严谨、规则体系复杂。通过大型模型生成SQL，让数据库能够精确理解并输出正确的结果，这是一个极具挑战性的任务。

2. 领域规则

领域规则是指：实际业务领域中指标或维度的计算规则，例如：零售领域中的 "销售额"，字面上理解销售额的计算方法为：销售量 × 商品单价，但实际场景中销售额的计算方法为：

『 销售额 = 销售量 × 商品单价 - 优惠券金额 - 促销抵扣 』

面向不同领域中和不同客户，上述的计算方法可能都不一样，如果通过大模型来生成SQL，前期大模型的规则学习，领域知识学习等会产生大量的项目实施成本，而且想要严格限制输出精度难度很大。

除了领域规则导致大模型生成SQL 的精度难以把控，数据库中表名和列名，同样会导致前期的实施成本极高。

3. Agile Query 是如何生成SQL

以上述销售额为例，Agile Query 中销售额指标的定义方法如下：


SUM(order_details.quantity * order_details.unit_price)
   - SUM(coupons_logs.amount)
   - SUM(promotions.discount)

上述的指标与传统SQL 的差异比较大，这也是Agile Query 公式的特点，一个公式中可以存在张表，表与表之间的关系由Agile Query 内部计算，多张表之间如果存在多对多关联，Agile query 会自动拆分多个子查询，并合并多个查询，最终形成正确的结果。

Agile Query 公式还有其它形式的定义方式：

1）月增长率

GROWTH_OF(
  SUM(order_details.quantity * order_details.unit_price), 
  orders.order_date, 
  'MONTHLY', 
  1
)

上述公式定义了销售额的月增长率，其中的 'MONTHLY'，可以为daily, quarterly, yearly 时间区间，分别计算日增长率，季增长率和年增长率。

7c2addf736c8ed0ace36a074d6afae62_640_wx_fmt=png&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

（上图为两个环比指标的子查询图）

2）客户分类


SEGMENT(
  CASE
    WHEN COUNT(orders.order_id) > 10 
      AND SUM(order_details.quantity * order_details.unit_price) > 1000 THEN '高价值客户'
    WHEN COUNT(orders.order_id) LBETWEEN 5 AND 10
      AND SUM(order_details.quantity * order_details.unit_price) > 500 THEN '中等值客户'
    WHEN COUNT(orders.order_id) LBETWEEN 2 AND 5 
      AND SUM(order_details.quantity * order_details.unit_price) > 100 THEN '一般客户'
    ELSE '其它'
  END,
  customers.customer_id,
  orders.order_date = LAST_YEARS(1)
)

上述公式，基于订单数据和销售额对客户进行分类，数据以过去 1 年的数据为基础。

e3c0efe38c8798e2194b4911e385ae3c_640_wx_fmt=png&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

（上图为客户分类的子查询图）

4. 维度与指标自由组合

维度和指标是数据分析中基础的概念，维度用于定义观察指标变化的不同视角，指标则是对特定维度的度量方法，通常为聚合值的形式存在。一个特定领域中，维度和指标的数量相对稳定，但维度与指标的组合关系非常灵活，很难预先设计。

目前很多领域中存在一些固化的分析模式、建模方法，也是经历数十年的沉淀才形成的，很多公司建设了指标平台（或指标中台），但每个领域在不断发展，同时也有新的数据不断加入。当有新的数据或新的业务加入时，总是需要不断的重构原始的模型，增加新的跑批任务，成本是极高的。随着时间的推移，不断被重构的数据模型变得千疮百孔，遗留了大量无法被识别的数据。

试想一下，通过公式定义的维度和指标可以自由组合，同时又不存在任何的开发成本，是不是可以极大地提高数据的生产效率，当统计规则或统计方法发生变化时，直接调整公式，实时生效。当新的数据接入，只需要配置新数据与旧数据的关联方法即可，下面来看一下Agile Query 是如何实现指标与维度的自由组合。

1）基于品类统计销售额，客户数量，订单数量，客单价

b850d48a2cb77c5a3c48030884e0b145_640_wx_fmt=png&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

4aabd03ade8e1ebd11cd5f2bcb5d6fe9_640_wx_fmt=png&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

2) 基于供应商统计销售额月增长率，客户数量月增长率

5b4f0504435e1e97f2548843284e7bcd_640_wx_fmt=png&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

1f765efe6be786711d4a39ada2827d97_640_wx_fmt=png&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.webp

上述示例中的单个聚合指标相对简单，但当很多聚合指标组合查询时，SQL 的复杂度就上升了几个层次，在传统数据分析系统或指标平台，会基于固定的分析模式，预先基于维度对聚合值进行计算，并存储在宽表中。这样的建模方法，会产生大量预计算表，维度越多，预计算表越多，随着时间的推移或数据工程师的替换，维护成本极高。

在Agile Query 中，只需要在搜索框中选择相应的关键词即可，无需关心关键词背后涉及了多少张表，会产生多少个子查询等具体的技术细节。所有预定义的维度或指标可以自由的组合。Agile Query 生成的SQL 复杂度相对较高，所以对底层计算引擎的计算效率比较敏感，传统的MySQL或PostgreSQL 可能无法输出，通过会使用MPP 型数据库，例如：StarRocks，Doris，Databend 等。

5. 最后

当你读这里的时候，相信你的脑中会产生大量疑问，例如：

1）这么复杂的SQL 能快速出结果吗？

2）不做大宽表能满足业务团队的高并发的查询需求吗？

3）生成的SQL 能保证计算的正确性吗？

等等，这些问题在设计Agile Query 时都有充分的考虑，也有妥善的处理方法，在后续的文章中会一一解答。