源系统字段改名后，AI 问数为什么突然失效？

昨天 AI 还能回答“各渠道净销售额”，今天源系统把 channel 改成 sales_channel，查询就失败了。

更隐蔽的情况是查询没有报错，但字段类型、枚举值或业务含义已经变化，AI 仍然返回一个看似正常、实际错误的数字。

Schema 漂移不只是新增一列

常见变更包括：

• •字段新增、删除或改名；
• •整数变成字符串，日期格式改变；
• •是否为空、默认值和精度变化；
• •JSON 嵌套层级调整；
• •枚举值新增或重新编码；
• •一张表被拆分，或多个字段被合并。

这些变化会影响 SQL、指标公式、维度映射、权限策略和自然语言同义词。

自动接受所有变更也有风险

某些数据平台支持 Schema Evolution，可以在写入时自动合并新字段。但“技术上可以写入”不等于“业务上可以直接使用”。

Delta Lake 将 Schema Validation 与 Schema Evolution 分开：前者校验写入数据与目标表结构是否兼容，后者在明确启用时演进结构。这种边界适合 AI 数据层：先识别变化，再决定是否放行。

数据契约明确上下游承诺

数据契约可以为关键模型声明：

• •字段名称、类型和是否允许为空；
• •主键、粒度和更新时间；
• •枚举值与单位；
• •负责人和变更通知方式；
• •哪些修改属于破坏性变更。

dbt model contracts 会在构建模型时检查输出结构是否符合约定。对 AI 问数而言，契约还能保护指标、语义描述和权限规则依赖的字段。

建议建立变更影响清单

发现 Schema 变化后，应自动定位：

• •受影响的指标和计算字段；
• •依赖该字段的语义词、示例问题和业务文档；
• •行级、列级权限规则；
• •缓存、导出和下游接口；
• •需要重新运行的标准问题集。

在验证完成前，敏感指标可以继续使用上一稳定版本，或者明确提示数据正在升级，而不是静默输出不可信答案。

结论

字段变化是正常的软件演进，但未经治理的变化会让 AI 问数突然报错，甚至更危险地“正常返回错误答案”。

用数据契约声明稳定边界，用 Schema 漂移监控发现变化，再通过影响分析和回归问题集验证，才能让数据模型持续演进而不破坏业务信任。

参考来源

• •dbt Docs：Model contracts
• •Delta Lake：Schema validation and schema evolution