企业AI系统很少会因为模型本身不够强而失效。 更隐蔽的失败模式是：模型运行正确，SQL执行成功，结果看起来也很合理——但系统正在基于过时的业务表示进行推理。 这就是语义漂移（Semantic Drift）。 随着越来越多的团队在LLM与企业数据之间加入语义层，维护这些语义就不再是一次性的建模任务，而变成了生产工程问题。 数据库在变。业务定义在变。关联关系在变。 如果AI的理解没有跟着变，准确度就会悄悄退化，而且很难被及时发现。 语义层是运行时基础设施 典型的AI分析架构大致如下： 用户提问 → LLM/查询代理 → 语义层 → 企业数据 语义层通常包含： - 业务术语； - 指标定义； - 维度； - 物理表与字段的映射； - 用于生成查询的关联关系。 语义层的作用，是防止LLM直接从原始schema猜测业务含义。 但这里有一个重要的推论： 一旦AI在查询时依赖语义层，过期的语义就会变成运行时故障。 问题在于，很多团队把语义模型当成文档来维护。 定义一次，评审一次，发布一次。 然后就假设它会一直正确。 企业数据可不会这样。 失败模式1：Schema漂移 假设某个指标映射到： customer.customer_id 仓库迁移之后，组织引入了新表： account_customer.customer_key 旧表可能为了兼容性仍然保留。 这就形成了一个危险局面。 表面上什么都没坏。 旧查询依然可以执行。 但语义映射指向的，是一个已经不再具有权威性的数据表示。 传统的schema监控只能告诉你"新增了一列"。 AI分析需要回答一个更难的问题： 这次schema变更，是否让AI所依赖的任何业务含义失效？ 要回答这个问题，必须把schema变更检测与语义影响分析连接起来。当数据管道调整、迁移脚本执行或建模方式改变时，系统需要自动识别：哪些指标定义、哪些维度映射、哪些关联关系受影响，并主动触发语义层更新，而不是等业务人员发现报表数字不对时再去排查。 结语 在LLM驱动的企业AI时代，语义层绝不是可以一次建好、永久使用的静态资产，而是需要持续运维的运行时基础设施。 把语义当文档维护，系统会在沉默中慢慢失效； 把语义当基础设施运营，AI才能真正站在正确的业务事实上回答问题。
热门跟贴