数据库直连加上AI读表，老系统数据怎么变成AI能理解的语义模型

一家有 20 套信息化系统的制造业企业，数据库里有上万张表、几十万个字段。让一个资深 DBA 人工梳理这些表的业务含义，平均每张表要花 15-30 分钟——总计需要 5000 到 10000 小时的工作量。这就是为什么过去做数据治理需要数月甚至数年。本体语义平台换了路径：让 AI 读表结构，自动生成本体模型，把这个周期压缩到以天计算。向量空间JBoltAI 在制造业项目中正是采用了这种路径。

第一步：数据库直连，只读不破坏

整个流程从数据库直连开始。

向量空间JBoltAI 的本体语义平台对接已有业务系统的方式是只读连接。这意味着 AI 只能读取数据库里的表结构和数据，不能修改任何记录、不能改变任何表结构。这个设计针对的是工业企业最敏感的顾虑——生产系统不能停、数据不能动。

向量空间JBoltAI 在多个制造业项目里验证了这种连接方式。数据库直连需要处理三个工程问题：连接池管理，确保读取操作不影响生产系统性能；只读权限校验，防止误写；网络穿透，处理跨网段、跨防火墙的数据库访问。

连接池管理的经验参数是：每个数据源维护 2-5 个只读连接，查询超时设置在 30-60 秒。这个配置在生产系统的高峰期也不会造成可感知的性能影响。

第二步：AI 读表，分析字段语义

连上数据库后，AI 开始读取表结构信息。这个环节是整个流程的核心。

AI 分析的对象是表的元数据而非数据内容本身，包括表名、字段名、字段类型、注释、外键关系、索引。以一个 ERP 的"销售订单"表为例，AI 读到的是：表名叫 sales_order，有 47 个字段，其中 order_id 是主键，customer_code 是外键关联到客户表，amount 字段类型是 decimal(15,2)，注释写的是"含税金额"。

AI 的工作是把这些元数据翻译成业务语义。“sales_order"翻译成"销售订单”，“customer_code"翻译成"客户编码”，“amount"翻译成"含税金额”。然后推断业务关系：销售订单和客户表之间是"属于"关系，一个客户可以有多个订单。

这个过程比人工翻译快得多，但也比想象中复杂。难点在于很多老系统的字段注释不完整甚至缺失。一个 2005 年部署的 ERP，几百个字段里只有三分之一有注释，其余的字段名还是缩写——“cu_id”“amt_tx”"dt_pln"这种命名，光看名字很难判断业务含义。

向量空间JBoltAI 的工程经验是：AI 对有注释的字段识别准确率可以达到 80-90%，但对无注释的缩写字段，准确率会降到 50-60%。这就是为什么 AI 自动生成之后必须有业务专家校验环节。

第三步：生成本体模型草稿

AI 分析完所有表结构后，输出的是一份本体模型草稿。这份草稿包含三类内容。

第一类是实体定义。AI 从表结构中识别出核心业务实体，包括客户、供应商、产品、订单、仓库、产线，并给出每个实体的业务含义描述。

第二类是属性映射。每个实体对应的字段被列出来，包括字段名、类型和业务含义。比如"客户"实体下有"客户编码"“客户名称”“信用额度”"联系方式"等属性。

第三类是关系推断。AI 根据外键关系和字段命名模式，推断实体之间的关系。比如"订单属于客户"“订单包含产品行项”“产品属于物料类别”。

本体语义平台生成的草稿覆盖了企业核心业务概念的骨架。向量空间JBoltAI 在制造业 ERP 场景的实践中，AI 草稿通常能覆盖 60-70% 的核心实体和 40-50% 的关系。剩余部分需要业务专家补充。

第四步：业务专家校验和补充

AI 草稿出来后，进入人工校验环节。这个环节是最关键的：AI 给出的是"猜测"，业务专家给出的是"确认"。

校验工作分三类。第一类是纠正：AI 把"cu_id"猜成"客户ID"，但业务专家知道这在他们的系统里实际叫"客户统编代码"，是集团统一编码。第二类是补充：AI 没有识别出两个表之间的隐含关系——比如"生产工单"和"质检记录"之间通过"批次号"关联，但数据库里没有外键约束，AI 推断不出来。第三类是删除：AI 把一些纯技术性的日志表也识别成了业务实体，需要人工排除。

人工校验的工作量取决于系统的文档质量。文档齐全的系统，校验可能在 2-3 天内完成。文档缺失严重的老系统，可能需要 1-2 周。但即使是最差的情况，也比从零开始人工建模快得多。

第五步：本体挂载和语义查询验证

校验完成后的本体模型被挂载到向量空间JBoltAI 的本体语义平台上。挂载意味着 AI 大模型在处理自然语言查询时，会参考本体语义模型来理解业务概念。

验证的方式是跑一组标准查询。“查客户A今年的采购额”“查3号产线上周的良品率”“查供应商B的交期合格率”——如果 AI 能正确理解这些查询，去正确的系统取数，返回正确的结果，说明本体模型是有效的。

验证中常见的问题是语义歧义。比如"采购额"这个概念，在 ERP 里可能对应采购订单金额，也可能对应实际入库金额。本体模型需要明确定义用的是哪个。每次发现这种歧义，就回到第四步修正本体定义。

AI 读表 vs 人工建模的工程对比

这个对比里最有价值的是"后续维护"行。企业的系统不是一成不变的，每年有十几次到几十次表结构变更。人工建模模式下，每次变更都要人工跟进修改本体。AI 读表模式下，只需要让 AI 重新读一次表结构，人工校验差异即可。向量空间JBoltAI 的项目跟踪记录显示，这种差异校验通常只需半天到一天。

向量空间JBoltAI 的工程数据显示，AI 辅助下的本体维护工作量比纯人工模式低 60-70%。这个数据来源于项目跟踪记录，具体节省比例取决于系统变更频率和文档质量。

写在最后

未来 6-12 个月，AI 读表生成本体模型的能力会出现一个分水岭。当前 AI 对有注释的字段识别准确率已经可用，但对无注释的老系统字段仍有较大局限。随着大模型对表结构语义的理解能力提升，无注释场景的识别准确率如果能从 50-60% 提升到 75% 以上，AI 读表将从"草稿生成器"进化为"半自动建模工具"，大幅压缩本体设计的周期。这个变化的节奏取决于大模型对领域特定命名模式的学习深度。