过去几年，我参与了不少企业级AI项目，尤其是自然语言查询和智能分析这类方向。一个现象反复出现——当AI系统给出错误答案时，几乎所有人的第一反应都是质疑模型本身。
“也许换个更大的语言模型就能解决。”
“提示词再多补充点上下文试试。”
“SQL生成能力还不够成熟。”
但在把这些项目从头到尾梳理一遍之后，我得出一个完全不同的判断：多数情况下，模型并不是真正的症结所在。真正出问题的是企业那套沿用了二十年的数据模型。
几十年来，企业数据库的设计始终围绕着一个核心目标：服务应用程序。范式化减少数据冗余，索引提升查询性能，外键维护引用完整性，数据仓库则把信息按照报表需求重新组织。一切运转良好，因为应用层已经预先内置了对业务逻辑的理解。
关键问题在于，业务逻辑并不存在于数据库中。它散落在源代码里、服务层里、存储过程中、ETL管道里，还有开发人员多年积累的经验判断里。数据库本身不需要对外解释什么是“客户”，因为开发人员早就知道了。这种架构在应用为唯一消费者的时代运行得天衣无缝。
绝大多数AI系统接入企业数据时，第一步都是读取元数据。它们能发现有哪些表，运气好的话还能识别出一些外键关系。但元数据只描述数据的存储方式，并不解释数据实际代表什么含义。
举个例子。企业通常有至少三套系统：CRM里存着客户信息，财务系统里记着付款主体，订单系统里则是下单方。对员工来说，这三者往往指向同一个商业实体，只是经由不同业务流程产生的不同视角而已。但在AI眼里，这就是三张彼此毫无关联的表。没有额外的业务知识注入，AI生成的每一条SQL查询本质上都是在碰运气。
现代语言模型生成SQL的能力其实已经相当不错，语法错误大幅减少。更大的挑战出现在更早的环节——生成SQL之前，AI必须先回答这样一些问题：哪些表才是可信的？这笔交易的真正主体是谁？这个指标到底怎么算？这些从不是SQL层面的问题，而是知识层面的断层。
有意思的是，企业里的业务知识很少被存储在AI能够触碰到的位置。开发人员脑子里装着所有正确的关联路径，业务分析师掌握着指标的定义口径，数据库管理员对物理schema了如指掌，领域专家理解完整业务流程的运转逻辑。每个群体各持一块拼图，几乎没有哪一块被显式地呈现在数据模型本身之中。人类可以天然地弥合这些鸿沟，AI却不行。
这背后折射的是企业正在经历的最大架构变革：AI已经成为一个全新的企业数据消费者。多年以来，应用程序是数据库唯一的使用方。现在AI加入了进来，但它和应用程序有着根本性差异——AI读不到源代码，没参加过任何一次设计评审会，更不可能拍拍资深开发者的肩膀问一句“哪张表才是准的”。它能看到的只有企业已经沉淀下来的文档，而现实是，多数企业把大量关键业务知识留在了开发团队的脑袋里。
热门跟贴