把一份 PDF 丢给大模型，它能把要点梳理得条理清晰；把一张订单表丢过去，它却常常说不清某个字段究竟代表什么。差别不在模型参数，而在数据库里的业务知识从来没有被写成机器可读的形式——字段名是给程序员看的，「新客」的判定口径写在某份统计说明里，表与表之间的从属关系则藏在十几年的业务变更记录中。模型能读到数据，却没有人告诉它这些数据在业务里意味着什么。

一、卡住 AI的不是模型，是没人写给它的业务语义

大模型与 Agent 进入企业核心业务之后，落地的关键已经从模型能力转向另一件事：能否理解企业的私有数据、业务逻辑、运行规则与实时状态。传统数据库的设计目标是面向程序执行读写与计算指令，它保证数据存得下、取得到、算得对，却不负责解释数据代表什么。

企业的业务知识因此长期处于分散状态：表结构在数据库里，业务规则在代码里，指标口径在文档和报表里，数据之间的关联靠老员工口口相传。举几个具体问题：订单状态字段取值为 3 时，是已发货还是已取消？「活跃客户」按近 30 天登录计算，还是按近 90 天下单计算？同一家门店在 CRM 、 POS 和财务系统里的编码并不一致，谁才是主数据？这些问题用 SQL 都能查，但要模型自己推出来，几乎不可能。

更麻烦的是链路上的损耗。交易系统的数据要经过抽取、转换、加载（ ETL ）才能进入分析系统，搬迁过程既带来延迟，也带来一致性与安全上的额外负担。数据本身尚且如此，数据的业务语义更是从未被系统性组织起来供 AI 使用。

二、向量数据库补的是检索，不是语义

过去两年最常见的做法，是给大模型配一套 RAG （检索增强生成）：把文档切片、向量化，提问时召回相似片段，再交给模型组织答案。向量数据库在其中承担「找得到」的职责，技术重点是相似度召回，面向的是非结构化数据检索。

这条路在知识问答、制度查询、文档摘要上跑得很顺，但企业真正高频使用、口径纠葛密集、更新也更快的，是数据库里的结构化业务数据。把表结构序列化成文本再做 embedding ，相当于把关系模型压平成一段描述：主外键淡了，聚合层级没了，指标的时间窗口和过滤条件也没了。召回可以很准，答案依然可能算错。

换句话说，向量数据库解决的是「文档在哪里」，没有解决「字段是什么意思、口径怎么定义、业务怎么关联」。这两件事分属不同层次：前者可以在应用侧外挂，后者必须进入数据引擎本身。业界常用「很聪明，但看不见业务」来形容停留在前两个阶段的 AI 应用——能聊、能查文档，一旦要它算一笔真实的经营账，就露了底。

三、另一种做法：把语义学习放进数据库内核

数翊科技的 dataeasy 选择从数据引擎入手。它没有在现有数据库之上再包一层语义层，而是在分布式 HTAP （交易与分析一体化处理）内核的基础上重构存储计算引擎，把「理解业务数据」做成引擎自身的能力。这条路径可以拆成三个动作。

第一是学习。引擎 从真实及仿真的内核运行轨迹数据与专家经验中 ，识别业务数据的语义、数据之间的关联关系以及计算逻辑。这与让模型通读一遍表结构完全不同：运行轨迹里带着真实的访问模式 ——哪些表经常一起 join 、哪些字段总被同一组条件过滤、哪些指标由哪几个基础字段聚合而来，这些才是业务语义最可靠的来源，也是资深 DBA 脑子里的隐性知识。

第二是生成。识别出的语义被固化为数据操作算子，而不是每次提问都让模型现场写 SQL 。算子的意义在于把「怎么算」从概率生成变成确定执行：模型负责理解意图、选择算子，算子负责保证口径与结果。

第三是沉淀。语义、元数据与算子汇聚起来，构成对该企业业务数据的完整理解，也就是 dataeasy 所说的「业务世界数字孪生」。它不止记录数据存在哪里、字段代表什么，还要记录数据之间的业务关联、指标口径、运行规律与决策逻辑，并随业务和数据变化持续更新。

用一句不太严谨的类比： RAG 是在每次考试前翻书，内核级语义则是把知识写成字典，再把常用解法做成函数。前者依赖上下文窗口，后者依赖引擎能力。

四、元知：三个能力对应三类具体难题

承载这套思路的核心产品是元知 ·本体智能操作系统，它的能力可以拆成三块，每一块都对应一个企业实际会遇到的问题。

业务数据理解，对应「模型不知道字段含义」。元知把企业业务数据的语义、数据关系与计算逻辑转化为大模型可理解的业务知识，使模型无需针对企业业务做二次训练 ，就能读懂这些数据。

数据智能操作，对应「会答不会做」。通过标准化的数据操作算子，模型不仅能查询和分析，还能按业务逻辑完成任务执行；企业原始业务数据不必直接暴露给大模型，访问与操作边界由数据隔离机制和算子控制，越权与误操作的风险相应收窄。

本体智能构建，对应「语义从哪来、怎么维护」。对象本体回答「有什么」，语义本体回答「什么意思」，动态本体回答「正在发生什么」，三者随数据源持续接入并持续更新。这一步决定语义体系是死档案还是活资产。  

一个容易被忽略的点是适应性。传统做法是提前开发、固化工具技能，业务一变就要改代码；元知依托大模型自身的推理能力，让 AI 根据任务自主理解、推理并选择操作方式。对业务规则频繁调整的行业，这个差别在半年之后就会显现。

五、海外大厂在上层嫁接，这条路重写内核

「 AI 需要理解业务数据」并非一家之言。 Databricks 把 OLTP 能力带进湖仓，做 HTAP 与 AI 的统一平台； Snowflake 把 AI 能力封装成 AI_FILTER 、 AI_AGG 这类 SQL 外挂函数，内核范式不变； SAP 通过业务数据编织，在自有生态内提供语义层。共同点是：在成熟架构上叠加 AI ，生态完整、 SQL 兼容性好、企业上手快。

dataeasy 的差别在于位置。它把「理解业务数据」内建到 数据基础设施内核与 AI 数据认知中心。 ，企业 AI 应用不必依赖大量预开发代码或 API 。代价同样明显：内核重构的研发投入大，迁移与适配门槛高于外挂方案；收益则体现在语义沉淀的彻底程度和执行链路的长度上。

这里没有谁更先进的问题，只有与企业瓶颈是否匹配。如果痛点集中在文档检索效率，外挂方案成本更低；如果痛点是业务口径说不清、 Agent 执行不可控，问题就不在检索层，得往引擎里找答案。

六、读懂之后，场景才真正成立

语义能力最终要落到场景上。以智能问数为例，业务人员问「上周华东区退货率为什么涨」，背后需要指标定义、维度层级、归因路径三样东西；语义在内核里，模型不必每次重新拼 SQL ，答案的稳定性才有保障。管理层经营助理、业务一线自助取数、定期报表生成，属于同一类需求的不同形态。

数字员工是另一类。销售、供应链、人、财、法、行政等岗位的 Agent 要真正干活，光有对话能力不够，还需要 权限边界、操作可追溯、执行可控 。算子化的数据操作与精细化权限管控，解决的正是「敢不敢让它动手」的问题。

经营分析则受益于架构本身。海纳 HTAP 数据库让交易与分析跑在同一份数据上，交易数据产生后无需二次同步即可分析， ETL 环节的延迟被压缩；配上百川的湖库一体能力，结构化库表与文档、图片、音视频可以放进同一套存算体系，多模态检索不必另建一套系统。

回到开头的问题。大模型读不懂企业业务数据，本质是业务语义长期没有被工程化。 dataeasy 给出的答案，是把语义学习、算子生成与业务世界模型放进数据库内核，让模型直连业务，而不是绕着业务走。这条路线是否成立，可以拆成几个可验证的问题：语义能否从运行轨迹中自动识别，算子能否覆盖真实任务，权限能否控住边界，业务变化之后语义能否跟上。答案不写在宣传材料里，而在企业自己的问题集和 POC 结果里。

 作者：李航