北陌大叔1. 智能问数落地的现实困境与本质矛盾
去年为某零售集团部署智能问数系统时，我亲眼见证了业务总监从兴奋到失望的全过程。演示环节，系统完美回答"各区域销售额对比"这类常规问题，赢得满堂喝彩。但当他追问"上季度高价值客户复购率"时，系统返回的数字却让财务团队集体摇头——这个看似简单的指标，背后涉及7张表的关联和5条业务排除规则，而大模型基于统计概率生成的SQL，根本无法还原企业特有的计算逻辑。
这正是当前ChatBI（智能问数）落地的典型困境：在实验室环境下表现优异的NL2SQL（自然语言转SQL）技术，一旦进入企业真实业务场景，就会遭遇三重致命挑战：
1.1 语义鸿沟：业务语言与数据语言的断层
当管理者提出"查看优质客户"这类需求时，其语义包含三个层次：
- 显性需求：字面表达的查询意图
- 隐性规则：企业特有的业务定义（如优质客户=年消费>10万且复购3次以上）
- 数据映射：对应数据库中的字段组合（可能是customer_type='VIP' AND total_payment>100000）
传统BI工具要求用户自行完成这三个层次的转换，而智能问数本应自动实现这种转换。但问题在于：
- 大模型缺乏企业特有的业务知识，无法准确还原隐性规则
- 数据库字段命名往往与业务概念脱节（如把"优质客户"标记为cust_level=5）
- 相同业务术语在不同部门可能有不同定义
关键发现：在测试的17家企业中，83%的查询错误源于业务语义与数据语义的映射偏差，而非模型本身的SQL生成能力问题。
1.2 数据债：历史遗留的技术债务
某制造业客户的ERP系统中，我发现同一个"销售额"指标竟有6种计算逻辑：
- 销售模块：含税金额，包含取消订单
- 财务模块：净金额，已扣除退款
- 仓储模块：按发货时点确认
- 报表系统：按会计准则调整后数据
这些矛盾不是技术问题，而是企业数字化转型过程中积累的"数据债"。更棘手的是：
- 关键业务规则常以存储过程、触发器等形式存在，没有完整文档
- 数据血缘关系断裂，历史数据迁移导致统计口径变化
- 临时字段（如is_special_order）承载重要业务逻辑
1.3 可靠性悖论：概率模型与确定需求的冲突
金融客户的一个真实案例：当CFO询问"本月逾期贷款金额