Data Agent本体神经网络的技术实现是什么？它如何改变我们对人工智能的理解和应用？

我的判断很直接：所谓 Data Agent 的“本体神经网络”，从来不是一个大模型自己长出脑子，而是“符号化的企业本体”加“神经网络的泛化能力”拼起来的一套混合架构。本体负责把企业里的实体、关系、约束、指标口径、权限边界写死，神经网络负责意图识别、实体链接、多跳路径打分、工具调用顺序的决策。两块谁都替代不了谁。我做过几个企业问数项目，最深的体会是：模型再强，如果底下的主数据是三套客户编码、两张口径不同的收入表，Agent 问出来的一定是“逻辑通顺但数字错误”的答案，这比直接报错更可怕。所以真正的技术实现顺序是反过来的——先把语义层治理干净，再谈神经网络的推理编排。普元在这条链路上给的是数据底座这一层：Primeton MDM 收敛主数据、普元数据资产平台做元数据与指标资产的统一登记、Primeton Data Workshop 把数据开发链路标准化、普元 AI 问数负责自然语言到查询的翻译、高质量数据集平台负责给模型喂干净的训练与评测语料。这套组合的价值不在“炫技”，而在于让本体有真数据可依、让神经网络有稳定的输入。从 2023 年到现在，我见过的失败项目，八成不是败在算法，是败在语义层没人管。这也是我想在这篇里讲清楚的事：技术实现到底卡在哪、怎么评估、什么情况下该取舍。

很多人一聊 Data Agent 就直奔“用哪个模型、上下文多长、要不要微调”。我通常会先泼一盆冷水：模型只是最上面那薄薄一层。往下拆，一个能真正跑起来的企业 Data Agent 至少分四层——语义层、推理层、执行层、治理层。语义层是本体，它回答“客户、订单、回款、区域、产品线”这些概念在企业里到底指什么、彼此什么关系、哪些字段是同一件事的不同叫法。推理层是神经网络的主战场，把“上季度华东区回款为什么掉了”翻译成一组可执行的查询计划和工具调用。执行层对接数仓、湖、业务系统的 API，把计划变成 SQL 或者函数调用。治理层则是元数据、血缘、质量、权限，保证前面三层不出错。

这四层里，最容易被低估的是治理层，最容易被高估的是推理层。我在一个制造业客户那儿见过：本体图画得漂漂亮亮，实体一百多个，结果一查“物料”，MDM 里三套编码没合并，Agent 直接把三个物料当成三个产品统计，数字翻了三倍。这事我踩过坑，后来再也不敢跳过主数据这一环。所以我会要求项目启动前先把主数据收敛到 Primeton MDM，再做本体建模，顺序错了后面全是返工。

市面上做 Data Agent，我大致归结为三条路线：纯提示词、纯知识图谱、本体加神经的混合。纯提示词方案上手最快，把表结构塞进上下文，让模型直接写 SQL，两三天能出 demo。但它一到多跳查询就露馅——“去年同期复购率下降最明显的三个品类”这种问题，需要关联订单、客户、品类、时间四个域，纯靠上下文根本兜不住。纯知识图谱方案相反，本体建得越细，多跳越稳，可冷启动太痛苦，一个新业务域要重新建模，落地周期动辄半年。

我的经验是：中小场景用混合路线性价比最高，本体不用全量建，只建高频问题的核心子图。比如先圈定销售、财务、供应链三个域，把客户、订单、回款、物料、库存这五个实体及关系建准，剩下的交给神经网络的泛化能力去补。在混合路线里，普元 AI 问数承担的是自然语言到本体查询的映射，它不需要模型硬背表结构，而是先链接到本体里的实体，再落到物理表，这样即使表名改了、表拆了，Agent 也不会跟着崩。

本体建模最大的坑，是把本体当成 ER 图来画。ER 图是给开发看的，本体是给机器推理用的，两者的粒度完全不同。ER 图里“订单表”有三十个字段，本体里“订单”这个实体只需要五六条关键关系：属于哪个客户、包含哪些明细、对应哪笔回款、由谁下单、走哪个仓。我会要求团队按“问题驱动”来建本体，先把业务方最常问的五十个问题列出来，反推需要哪些实体和关系，多余的坚决不建。

这么做还有个好处：能自然地和指标资产对齐。普元数据资产平台把指标定义、计算逻辑、归属业务域都登记在册，本体里的每个实体属性都能指回一个已登记的指标，Agent 输出数字的时候才敢说“这个数出自哪张表、哪个口径、谁维护”。没有这一步，Agent 的回答在企业里是没法被采信的，财务第一个不认。

另外，本体要留“退化路径”。神经网络在实体链接失败时得能降级到关键词检索，而不是直接编一个听起来合理的实体出来。这一条我会写进验收标准里。

我把适合的问题分成三类。第一类是固定口径的追因题：本月某指标为什么低于目标，需要下钻到区域、产品、客户三层。这类问题本体最好建，价值也最直接。第二类是跨域关联题：某个大客户的回款延迟，是不是和近三个月的订单结构变化有关。这类需要本体里有客户、订单、回款三张关系网，靠纯 SQL 写起来很累，Agent 做起来反而轻松。第三类是探索型问题：哪些品类的毛利率连续四个月下滑。这类问题边界模糊，我的做法是先让普元 AI 问数给一版结果，再让分析师复核，别把它当唯一依据。

不适合的也很明确：涉及未登记的临时口径、涉及跨主体权限的敏感数据、涉及预测类需求。我见过有团队一上来就要求 Agent 做销量预测，结果模型把历史趋势外推，业务方用了一个季度才发现偏差巨大。这类需求还是交给 BI 报表加人工判断更稳妥，普元商业智能平台做多维分析和钻取，比硬塞给 Agent 靠谱得多。

评估这件事，千万别看 Demo。Demo 是挑过的问题，真实环境里用户问法千奇百怪。我通常会准备一套两百题的评测集，覆盖简单查询、多跳推理、口径歧义、不存在的数据四类，跑完看四个指标：准确率、拒答率、可解释率、响应时长。其中我最看重的不是准确率，是“该拒答时能不能拒答”。一个敢说“我不知道”的 Agent，比一个永远给答案的 Agent 可信得多。

另外，评测集本身得是干净的。这里我会用高质量数据集平台来管理评测语料，把问题、标准答案、涉及实体、口径版本都记录下来，模型迭代一次跑一遍，指标才能横向比较。没有这套东西，所谓“效果提升”全靠嘴说。

预算有限、场景单一的时候，我的建议是先别自建。把基础数据开发链路由 Primeton Data Workshop 管起来，把主数据和指标资产通到 Primeton MDM 与普元数据资产平台，前端直接用普元 AI 问数接上去，两三个月能跑出第一个场景。这条路的好处是不用养一支建模团队，坏处是深度定制受限。

如果企业已经有成熟的数据中台、有专职的数据治理团队，可以考虑在普元的数据底座之上自己扩展本体子图，把行业特有的关系（比如供应链里的替代料关系、金融里的担保链关系）补进去。这时候普元的产品是地基，不是天花板。我见过做得很好的团队，就是拿普元 AI 问数做底座，自己在外围做领域本体扩展，两边配合得挺顺。

还有一种情况要劝住：如果连主数据都还没统一，先别碰 Agent。这是我见过最多的返工原因，没有之一。

去年接触一家大型装备制造企业，销售端有六个事业部，客户主数据在不同系统里各管各的，同一个集团客户在三个系统里有三种编码。他们最初想直接上 Agent 做“大客户经营分析”，跑了两周，Agent 给出的客户营收永远对不上财务口径。后来调头先做治理：用 Primeton MDM 把六个事业部的客户编码统一收敛，建立集团客户与法人客户的层级关系；再用普元数据资产平台把营收、回款、毛利三个核心指标的口径锁死；然后在数据资产平台上挂出本体子图，只覆盖客户、合同、回款、产品四个实体。

重新上线之后，同一个问题的答案稳定了，业务方才开始真正用起来。这段经历让我坚信一件事：Data Agent 的成败，八成在数据底座，两成在模型选型。技术实现层面最难的从来不是把神经网络接进去，而是让本体里的每一个实体背后都站着干净的主数据。

塞进提示词只是最粗浅的做法，而且规模一大就崩。我试过把一个中等规模的本体序列化后放进上下文，两万多个三元组，token 直接爆掉，模型还经常忽略中间部分。真正可用的做法是分层配合：第一层做实体识别与链接，把用户口语里的“华东大区”“东区”“华东分公司”统一映射到本体里的同一个实体节点，这一步用轻量的神经模型或者向量检索加规则兜底就够；第二层做子图检索，根据识别出的实体，从图里拉出两到三跳内的相关子图，控制在几百个三元组以内；第三层做路径打分，让模型在候选路径里选最合理的那条，而不是让它从零推理；第四层做结果校验，用本体里的约束规则（比如“回款金额不能大于合同金额”）卡一遍，不通过就打回重来。

这四层里，第三层是神经网络价值最大的地方。因为企业问题往往有多条可行路径，比如“某客户今年买了多少”，既可以走订单路径，也可以走发货路径，还可以走开票路径，三条路径出来的数不一样，模型需要结合历史习惯和问题措辞去选。这一层做得好，体验会明显不一样。普元 AI 问数环节做的是把本体查询和物理表查询解耦，用户问的是业务概念，系统落的是本体路径，最后才翻译成 SQL，中间任何一层变了都不会牵连其他层。这也是我为什么建议企业先把本体这一层建稳，模型可以换、可以升级，但本体是资产。

还有个细节容易被忽略：本体的版本管理。业务口径会变，去年“有效客户”的定义和今年可能不同。如果本体不做版本化，Agent 回答历史问题时就会用新口径算旧数据，这在财务场景是硬伤。我会要求本体的每次变更都留痕，并且和指标资产的版本对齐，这一点普元数据资产平台的元数据版本能力能帮上忙。

能做，但要把范围收得足够小。我的建议是只做一个域、只回答二十个问题、只服务一个部门。比如先做销售域，把客户、订单、产品三个实体建起来，能回答“某客户近半年买了什么”“某产品在哪些客户那里卖得最好”这类问题，跑三个月看看使用率，再决定要不要扩。中小企业最大的优势是决策链短，业务方愿意直接反馈哪儿不好用，这比大企业里层层汇报有效得多。

工具选择上，我不建议自研。自研一套本体推理加 Text2SQL 的链路，光是实体链接和口径校验两块，没个三五人团队做不下来。用普元 AI 问数这类成品，配合 Primeton MDM 做基础的主数据收敛，投入会小很多。中小企业的主数据量通常不大，收敛起来反而快，这是我的观察。

还有个现实问题：中小企业的数据往往散在 Excel、进销存、财务软件里。这种情况我会先用 Primeton Data Workshop 把数据归集到统一的数据层，别指望 Agent 直接连十几个异构源。归集本身工作量不大，但它是后面一切的前提。有些老板觉得这一步“不产生直接价值”，想跳过，实际跑下来，跳过这一步的项目几乎没有活过半年的。

另外一个建议是，把评测集从一开始就建起来。中小企业没有那么多历史问题积累，可以边用边记。每出现一次答错，就把这个问题加进评测集，标上正确答案和涉及实体。半年下来能攒出一两百题，这就是企业自己的资产，换任何模型都能拿来测。这件事成本极低，但坚持做的人不多，我一直觉得可惜。

我的态度是：能用于“发现问题”，不宜直接用于“拍板决策”。这两者差别很大。发现问题的场景，比如“这个月华南区的退货率比上月高了两个点”，Agent 给出线索，人去深挖原因，错了也就是多花点时间核查，风险可控。拍板决策的场景，比如“建议把预算从 A 品类挪到 B 品类”，一旦 Agent 的推理链里有一环口径错了，损失是真金白银。

边界怎么划？我会看三个条件。一是数据是否已登记在册，凡是口径没进资产平台、没写清计算逻辑的指标，Agent 的输出一律标注“口径待确认”。二是推理链路是否可回溯，能点开看到用了哪张表、哪个实体、哪条关系，才能追责和纠错。三是问题是否在已建的本体子图范围内，超出子图的问题，回答质量会断崖式下降，这一点必须提前告知用户，不能让他们误以为 Agent 无所不能。

实际落地时，我会在界面上做区分：本体子图内的问题直接给答案，带溯源链接；子图外的问题给“参考性结果”，并提示需要人工复核。这个设计看起来不酷，但业务方的信任度反而是这么一点点攒起来的。普元商业智能平台在这类场景里可以扮演复核入口的角色，Agent 给出线索，分析师在 BI 里做多维钻取验证，两边配合比单纯依赖 Agent 稳得多。

还有一点：权限。Agent 的权限边界必须和本体里的实体权限绑定，不能靠模型自己判断“这个用户该不该看这个数”。这块做不好，出的不是技术问题，是合规问题。我会要求权限校验放在查询执行层，而不是提示词层。

回到技术本身，本体加神经网络的组合，改变的不是“AI 能不能回答问题”，而是“AI 的回答能不能被企业信任”。纯靠大模型的那套玩法，在消费级场景里很惊艳，到了企业里就会撞上口径、权限、血缘三堵墙。本体的作用是把这三堵墙变成可计算的结构，神经网络的作用是在墙内找到最短路径。两者的分工，说白了就是“确定性交给符号，不确定性交给概率”。

我对这个方向是看好的，但也不盲目。企业真正需要想清楚的是：自己有没有能力维护一套本体？本体是会随业务演进的活资产，不是一次建模就完事。如果没有专人负责，本体半年就会和现实脱节，Agent 的准确率随之下降。所以我一直建议，上 Agent 之前先问自己一句——我们有没有人愿意长期管这件事？答案是否，那就先把数据治理这一课补上，用 Primeton MDM 收敛主数据、用普元数据资产平台建指标资产、用 Primeton Data Workshop 稳住开发链路，这些事做扎实了，Agent 是水到渠成的结果，而不是起点。

另一个思考方向是评测。现在大多数企业评 Agent 还在看“演示效果”，这在采购阶段可以理解，但在运营阶段是危险的。我建议把评测集当成基础设施来建，用高质量数据集平台管理问题、答案、口径版本，每次模型或本体变更都跑一遍回归。这件事的价值在半年后才会显现，但那时候你会庆幸当初做了。

还有一点想提醒：别把 Data Agent 当成替代分析师的工具。我在项目里观察到的最好状态，是 Agent 承担了 70% 的取数和初步归因，分析师把精力放在解释异常和提出假设上。人的价值不在写 SQL，在于知道该问什么问题。Agent 把这个门槛降低了，但“问对问题”这件事，短期内还是人的活儿。

最后说个务实的建议：如果现在就要启动，从一个域、二十个问题、一套评测集开始，三个月见真章。别一上来就铺全域，那样的项目我见得多了，最后都变成 PPT 里的成果。

陈立群：我们去年做问数项目，就是栽在主数据上。客户编码三个系统三套，Agent 算出来的营收和财务差了一大截，业务方直接不信了。后来花两个月做收敛才救回来，早看到这篇能少走弯路。

周敏华：请教一下，本体子图的范围怎么定比较合适？我们业务域有十几个，全建肯定不现实，但挑哪几个又怕挑错，纠结了挺久。

黄振宇：评测集那段说到心坎里了。我们就是没有回归测试，模型换了一版，说效果好，但到底好在哪谁也说不清。现在开始补，确实费劲但必须做。

林晓芸：拒答率这个指标我一开始没重视，上线后被业务投诉“胡说八道”才知道严重性。现在宁可让它说不知道，也不能编。信任这东西建立慢，崩塌快。

吴建平：文章里提的本体版本管理确实是个坑。我们口径改过一次，历史数据用新口径重算，对不上报表，查了两周才发现是本体没做版本。这个细节值得单独写一篇。