在企业数仓从星型模型一路野蛮生长到百张大宽表之后，Text2SQL 最大的敌人早已不是“SQL 语法生成错误”，而是漫山遍野的同名字段灾难。
当业务在对话框输入“统计各省份上月的成交金额和创建时间”时，底层的元数据检索模块（Schema Linker）可能会瞬间捞出七八张包含province、pay_amount和created_at的宽表。其中，用户中心宽表里的created_at是“用户注册时间”，订单宽表里的是“下单时间”，履约宽表里的是“出库派单时间”，甚至在同一张包含多次合并的大宽表里，还会同时存在order_created_at、pay_created_at和被缩写为created_at的历史字段。
大模型在这种泥潭里几乎百分之百发生别名引用的语义幻觉（Semantic Hallucination）：它要么在SELECT里随意指派一个别名，导致数据口径驴唇不对马嘴；要么在生成多表JOIN时，把不同业务含义的同名字段直接拼进ON条件，引发笛卡尔积爆炸。
要解决百张宽表下的重名危机，靠在 Prompt 里堆砌“不要搞错时间”这种玄学提醒毫无意义。我们必须在 AST 解析、Schema 拓扑裁剪以及确定性重写层面建立物理级别的隔离栅栏。
重名危机的三大典型车祸现场
在没有别名歧义消解策略前，线上 Text2SQL 引擎频繁踩进以下三个坑：
- 同名异义导致的静默口径错误：
业务要算“商品客单价”，模型同时关联了dim_sku（商品维度表）和dws_trade_store_sku_1d（门店商品聚合日表）。两张表都有status字段，维度表里代表“商品档案上下架状态（0-下架，1-在售）”，事实表里代表“当天是否有动销状态（0-未动销，1-有动销）”。模型生成了WHERE status = 1，引擎成功返回了数据，但财务核对后发现少算了 40% 的停售商品历史销量，这种静默错误比直接抛 SQLSyntaxErrorException 恶毒十倍。 - 多表关联下的未限定列引用（Ambiguous Column Name）：
在联合分析订单表与退款表时，SQL 引擎直接报出致命错误：-- 典型报错：Column 'order_id' in field list is ambiguous SELECT order_id, sum(pay_amt), sum(refund_amt) FROM dwd_trade_order_di t1 LEFT JOIN dwd_trade_refund_di t2 ON t1.order_id = t2.order_id GROUP BY order_id; - 自关联时的别名漂移（Alias Drift）：
当涉及层级树结构（如多级类目、组织架构）的自查询时，模型为同一张表派生了t1和t2，但在WHERE或HAVING过滤阶段，往往把过滤条件错绑在被关联表的列上，造成层级错位。
全生命周期消解架构：从粗筛到精修
为了彻底消除歧义，我们设计了四层过滤与重写流水线：
用户提问 (Natural Language Query) │ ▼ [1. 业务实体与意图锚定] ── 锁定主事实域与实体生命周期阶段 │ ▼ [2. Schema 图剪枝与别名强制命名空间绑定] ── 限定候选表集合，统一生成 FQN 规范 │ ▼ [3. AST 语法树遍历与隐式列显式补全] ── 解析 AST，检查 Ambiguous Column，补全别名 │ ▼ [4. 语义等价校验与执行计划审查] ── 运行 Dry Run，确认执行计划安全第一步：基于 Schema 图的主事实域剪枝
面对数百张宽表，绝不能把所有 Schema 毫无保留地塞进上下文。我们根据业务实体（Entity）构建了数仓元数据拓扑图。
当识别到用户提问中的核心动词为“退款”、“退货”时，剪枝器会强制将主事实域锁定为Trade_Refund域，切断与User_Growth域下宽表的关联路径。此时即使两处都有user_id和create_time，模型也只能在退款事实的上下文空间内检索，从物理源头上扼杀 70% 的字段冲突。
第二步：强制全限定名（FQN）生成约束
在 Prompt 构建阶段，严禁将字段以扁平字符串提供给大模型，必须强制要求模型在输出任何列时，必须遵循table_alias.column_name的全限定语法，并且在 Prompt 模板中植入强类型签名（Strongly Typed Signatures）：
[Available Schema Context] Table Alias: orders (dwd_trade_order_di) Columns: - orders.order_id [STRING]: 交易主订单号 (唯一主键) - orders.created_at [TIMESTAMP]: 订单创建时间 (严禁用于用户注册时间统计) - orders.pay_amount [DECIMAL(18,2)]: 订单实付金额 Table Alias: users (dim_user_profile_df) Columns: - users.user_id [STRING]: 用户 ID - users.created_at [TIMESTAMP]: 用户账号注册时间通过元数据描述中的显式负向约束（Negative Constraints），引导大模型在生成字段时具备上下文辨别能力。
基于 SQLGlot 的别名歧义自动修复引擎
即便大模型生成了带有歧义的 SQL，后置的规则引擎也必须具备兜底修复能力。我们利用sqlglot库解析 AST，在物理执行前强制重写。
import sqlglot from sqlglot import exp from typing import Dict, Set class AmbiguityResolver: def __init__(self, table_schemas: Dict[str, Set[str]]): """ table_schemas: 格式如 {'dwd_order': {'order_id', 'created_at', 'amt'}, ...} """ self.schemas = table_schemas def resolve(self, sql: str) -> str: parsed = sqlglot.parse_one(sql) # 1. 提取所有参与查询的表及其别名映射 alias_to_table = {} for table in parsed.find_all(exp.Table): alias = table.alias_or_name alias_to_table[alias] = table.name # 2. 遍历所有列引用，检查未指定别名的字段 for column in parsed.find_all(exp.Column): col_name = column.name col_table = column.table if not col_table: # 寻找拥有该字段的候选表 candidates = [ alias for alias, tbl_name in alias_to_table.items() if tbl_name in self.schemas and col_name in self.schemas[tbl_name] ] if len(candidates) == 1: # 唯一匹配，自动补充表别名 column.set("table", exp.to_identifier(candidates[0])) elif len(candidates) > 1: # 存在多表同名字段冲突，优先回退绑定到主表（FROM 子句中的第一张表） from_table = parsed.find(exp.From) primary_alias = from_table.this.alias_or_name if from_table else candidates[0] if primary_alias in candidates: column.set("table", exp.to_identifier(primary_alias)) else: raise ValueError(f"字段 `{col_name}` 在多表中均存在，存在严重口径歧义: {candidates}") # 3. 消除 SELECT 子句中的无区别重名输出 select_expressions = parsed.expressions seen_aliases = set() for expr in select_expressions: output_name = expr.output_name if output_name in seen_aliases: # 发现重名输出列，强制重命名 new_alias = f"{expr.this.table}_{output_name}" if isinstance(expr.this, exp.Column) else f"{output_name}_dup" expr.replace(exp.alias_(expr.unalias(), new_alias)) seen_aliases.add(new_alias) else: seen_aliases.add(output_name) return parsed.sql(pretty=True)这段代码执行的核心逻辑在于：它不仅仅是个校验器，更是一个确定性的自动语法补全器。当检测到GROUP BY order_id没有带别名，而orders和refunds都有该列时，它会自动根据 SQL 主表结构，将其精准补全为GROUP BY orders.order_id，杜绝数据库抛出Column is ambiguous的崩溃。
实战改造对比与优化后效果
以典型的双表聚合查询为例，改写前后的变化清晰呈现了治理效果：
-- 改写前：大模型粗糙生成的带有歧义的原始 SQL SELECT dept_id, user_name, sum(amount) FROM dwd_sales_performance_di s JOIN dim_department d ON s.dept_id = d.dept_id WHERE created_at >= '2026-08-01' GROUP BY dept_id, user_name; -- 改写后：经由拓扑判定与 AST 补全后的确定性 SQL SELECT s.dept_id AS s_dept_id, s.user_name AS employee_name, sum(s.amount) AS total_sales_amount FROM dwd_sales_performance_di AS s INNER JOIN dim_department AS d ON s.dept_id = d.dept_id WHERE s.created_at >= '2026-08-01' -- 明确绑定销售业绩的产生时间，而非部门创建时间 GROUP BY s.dept_id, s.user_name;架构师的技术避坑总结
数仓宽表建模是历史债务与性能折中的产物，而 Text2SQL 是数仓质量的照妖镜。在重名字段治理中，我们沉淀了两条铁则：
第一，宁可报未定义错误，绝不允许猜测执行。当两个同名字段在业务权重上平分秋色（例如订单发货时间和签收时间，业务只输入了“时间”），系统必须阻断执行并向前端返回澄清交互卡片：“请确认您指的是发货时间还是签收时间？”。在数据领域，确定的失败远好于伪装的正确。
第二，推动数仓建模向“语义视图层”演进。不要让大模型直面未经修剪的底层百列大宽表。在数仓之上封装一层语义明晰的逻辑模型（Semantic Layer / Metrics Store），将字段名称严格标准化为事实_实体_属性（例如trade_order_created_at与user_registered_at），这是根治 Text2SQL 歧义的最强护城河。
