NL2Semantic2SQL 三层架构工程实现：从指标定义到故障降级

传统 NL2SQL 的核心矛盾在于：用户用自然语言描述的"销售额"和数据库中物理表结构之间缺少一层稳定的语义翻译。同一个"销售额"指标，在销售部门可能按含税口径计算，在财务部门按不含税口径计算，直接映射到物理表必然产生歧义。NL2Semantic2SQL 架构的核心思路是在自然语言和 SQL 之间插入一个语义中间层，让指标的业务定义先落地到标准化的语义模型，再由模型生成物理查询。这三层架构——指标定义 DSL 层、语义模型 Schema 层、AI 驱动查询与降级层——分别解决了"指标怎么定义"、"定义怎么映射到数据"、"查询出错怎么办"三个工程问题。

第一层：指标定义 DSL 层

指标定义层的目标是用声明式语言描述指标的业务含义，而非编写计算逻辑。一个指标由四个要素组合而成：基础度量（base measure）、业务限定（business qualification）、时间限定（time qualification）和推导方式（derivation method）。这四个要素的组合覆盖了绝大多数企业指标场景。

原子指标是不可再拆分的最小计算单元。例如"订单金额"的定义只包含基础度量和聚合方式，不涉及任何筛选条件。它的 DSL 定义大致形如：base_measure: order_amount, aggregation: sum。这个定义直接绑定到某个物理字段，但在语义层中它只是一个逻辑符号，不暴露底层表名和字段名。

派生指标在原子指标基础上增加业务限定和时间限定。例如"华东区本月退货订单金额"的 DSL 会组合多个限定条件：base: order_amount, filter: region='华东' AND status='refund', time: current_month。关键设计决策是限定条件用组合表达式而非硬编码，这样当"华东区"的行政区划编码变化时，只需要修改区域维度表，指标定义本身无需改动。

复合指标涉及多个原子或派生指标之间的算术运算。例如"退货率 = 退货订单金额 / 订单总额"。DSL 层需要支持指标引用机制，让复合指标通过名称引用子指标，而非重复定义计算公式。这带来一个工程上的依赖管理问题：当子指标的定义发生变化时，复合指标的语义是否仍然成立。声明式 DSL 的优势在于依赖关系可以通过静态分析自动检测，不需要运行时才能发现语义冲突。

智能指标 AIMetrics 在指标建模层面提供了原子、派生、复合指标的统一建模能力，其指标市场支持检索、血缘追踪和相似性检测，可以作为这类 DSL 层设计的参考实现。

第二层：语义模型 Schema 层

如果说 DSL 层定义了"指标是什么"，Schema 层则解决"指标对应哪些数据"。这一层的核心是逻辑数据模型（LDM）到物理数据模型（PDM）的映射关系管理。

LDM 描述业务视角下的实体和关系。一个典型的 LDM 包含维度表（时间、地域、产品、客户）和事实表（订单、支付、退货）的逻辑结构，以及它们之间的关联关系。LDM 不关心数据存储在 Hive、ClickHouse 还是 Elasticsearch 中，它只描述业务语义层面的数据组织方式。

PDM 则是具体的物理实现。同一个 LDM 的"订单事实"在不同的数仓分层中可能对应不同的物理表：ODS 层的原始订单表、DWD 层的明细宽表、DWS 层的聚合表。Schema 层需要维护 LDM 到 PDM 的多对多映射关系，并根据查询场景自动选择最优的物理路径。

元数据管理是 Schema 层的另一个关键职责。每个指标的定义需要关联到 LDM 中的实体，LDM 实体需要关联到 PDM 的表和字段。当某张物理表的字段名发生变化或表结构迁移时，Schema 层的血缘追踪机制可以自动识别受影响的指标范围，避免"改了一个字段，下游报表全挂"的情况。

数据一致性问题在多版本管理中尤为突出。当指标定义发生变更时，历史版本的查询结果不应该受到影响。Schema 层需要支持指标的多版本发布和审批流程：指标创建后进入"草稿"状态，经过影响分析和业务确认后才正式发布；发布后所有下游查询自动适配新定义，同时保留旧版本供历史查询使用。这种集中式的变更管理——修改一次，下游自动同步——是语义层相比传统手工协调方式的核心优势。

物化加速也是 Schema 层的重要能力。对于高频查询的指标，系统需要预定义物化策略，自动创建和更新物化视图，并管理其生命周期。例如"每日销售额"这种固定粒度的指标可以预先物化，而"按客户分组的实时销售额"则需要按需计算。物化策略的选择需要在查询延迟和存储成本之间做权衡。

第三层：AI 驱动查询与故障降级

这一层接收用户的自然语言问题，通过 NL2Semantic 模块将其转换为语义查询，再由 Semantic2SQL 模块将语义查询翻译为物理 SQL。整个流程分为三个阶段：意图解析、语义绑定、SQL 生成。

意图解析阶段处理自然语言的歧义问题。"上个月卖了多少"这句话至少包含三个需要明确的要素：时间范围（上个月的起止日期）、度量对象（"卖了"对应哪个指标）、聚合方式（是总量还是均值）。意图解析模块需要结合上下文（当前日期、用户角色、历史查询）来消歧，输出结构化的查询意图。

语义绑定阶段将解析出的意图映射到 DSL 层定义的指标。这一步的核心挑战是同义词匹配和指代消解。"销售额"、"营收"、"GMV"可能指向同一个指标，也可能在不同业务场景下指向不同指标。系统需要维护一个语义词典，支持模糊匹配和上下文感知的选择。

SQL 生成阶段从语义模型出发，根据 Schema 层的 LDM-to-PDM 映射生成可执行的物理查询。这一步相对确定性较强，因为一旦语义模型确定，生成的 SQL 结构也就确定了。

置信度评估与故障降级是这一层工程实现中最关键的机制。系统需要对每次查询的可靠性进行分级评估，根据置信度采取不同的处理策略：

高置信度查询（置信度 > 0.85）直接执行。这类查询通常涉及明确的指标名称、清晰的时间范围和简单的聚合逻辑。系统直接生成 SQL 并返回结果，无需人工干预。

中置信度查询（置信度 0.5 - 0.85）触发确认流程。系统会向用户展示它理解的查询意图，例如"我理解您想查询的是华东区上月退货订单金额，是否正确？"用户确认后才执行。这种交互式确认虽然增加了操作步骤，但避免了因语义歧义导致的错误结果。

低置信度查询（置信度 < 0.5）回退到模板查询。当系统无法可靠理解用户意图时，不冒险生成可能错误的 SQL，而是提供预定义的查询模板供用户选择，或者提示用户使用更精确的表述重新提问。这种设计背后的核心原则是：AI 能力如果没有平台支撑，容易产生幻觉；而有指标平台约束的 AI 才能成为可靠的企业分析助手。智能指标 AIMetrics 的 AI 智能问数能力正是在这一原则下构建的——对话即分析的前提是指标口径统一且可追溯，而非让大模型自行猜测业务含义。

在工程实现上，置信度的评估需要综合考虑多个信号：指标名称的匹配精确度、时间表达式的明确程度、过滤条件的完整性、以及该查询模式的历史成功率。评估模型本身也需要持续迭代——每次用户确认或纠正都会成为训练信号，逐步提升系统的判断准确度。

---

三层架构的工程价值在于职责分离：DSL 层让业务人员可以独立定义和维护指标，无需依赖 IT 工程师重建宽表；Schema 层让数据架构师可以管理物理实现的变化而不影响业务语义；AI 查询层让终端用户可以用自然语言获取可靠的数据结果。当业务需求变化时，修改的是配置而非代码；当物理表迁移时，调整的是映射而非定义；当查询出错时，系统有明确的降级路径而非静默返回错误结果。这种分层解耦的设计，才是 NL2Semantic2SQL 架构能够工程化落地的根本原因。