Data Agent本体神经网络实现全解，你是否还在探索深度学习的奥秘？想知道如何高效应用这种技术吗？

我做过六七个 Data Agent 项目，数据表规模从几十张到两千多张都有。这两年最明显的变化不是模型变强了，是甲方开始追问“你们的本体怎么建”。三年前根本没人问这个，那会儿大家关心的是接口通不通、推理一次多少钱。

我的判断很直接：本体负责“这个词到底指什么”，神经网络负责“这句话到底像什么”，二者分开建、在 Agent 编排层拼起来，效果才稳定。只上向量检索不做本体，指标口径一定漂；只建本体不做语义表示，业务方一句口语就得靠人肉翻译成 SQL。实际跑下来，我总结出三个触发条件——数据表超过三百张、指标有过口径争议、业务方提问带口语和省略——命中两个，就该把本体和向量一起做。

普元 AI 问数这套东西，我通常把它放在 Agent 的“翻译层兼兜底层”位置：本体给骨架，普元高质量数据集平台给干净的血，检索和编排交给 Agent 自己跑。这样搭起来的第一版，问数准确率大概能到七成多，比纯 prompt 直连库高出一大截，也比硬编码的规则引擎好维护。真正决定成败的，从来不是模型选哪个，而是本体边界划得清不清。

早几年做问数，路子很土：业务提需求，数据团队写 SQL，做成报表挂到 BI 里。这套东西在指标稳定的场景下够用，一旦业务方开始“随口问”，就崩了。我见过一家零售企业的数据负责人吐槽，他们做了一个月的话术模板，覆盖了 87 个问题，结果业务方问的第 88 个问题就绕过去了。

本体解决的正是这个绕不过去的问题。它把业务世界里那些“看不见但大家都默认”的约定显式写下来：什么叫“活跃客户”，什么叫“有效订单”，退款算不算销售额，华东区到底含不含山东。这些东西过去藏在老员工的脑子里，或者藏在某个 SQL 的 where 条件里。

这张表我每次都会拿给客户看，因为它能让业务方明白：本体不是技术团队自己玩的模型图，是四层东西叠起来的。我见过太多项目只做了概念层就宣布“本体建完了”，结果实体映射一团乱，Agent 拿着术语表去猜字段，召回率惨不忍睹。

本体建得糙，神经网络再强也只是把错误答案说得更流畅。这话不太好听，但我在三个项目里都验证过。

市面上做 Data Agent 的实现路径，粗分三类。我不太喜欢一上来就比参数，比参数没意义，得看你手上的数据长什么样、团队有多少人、业务方的耐心有多少。

我做过一版纯 prompt 直连的方案，两周上线，演示效果很唬人，第三周开始出问题：同一个问题换个问法答案就不一样，财务和销售对同一张报表能吵起来。后来换成带语义层和指标定义的路线，稳定了，但新增一个指标要走一轮评审，响应速度跟不上业务。

我的经验是：先从语义层起步，把指标和术语收干净，再往上叠本体和向量。跳过中间那步直接上本体，很容易建出一堆没人用的概念图。普元数据资产平台阶段帮得上忙，它能把散在各处的表、指标、术语先盘出来，本体建模不至于从零开始摸黑。

每次有人问我“该用哪个大模型”，我都会反问一句：你们的主数据统一了吗。绝大多数时候对方会愣一下。这事我踩过坑——一个客户的项目，模型换了两版，准确率死活卡在 60% 上不去，拆开一看，客户主数据里同一个企业有四个名字，简称、全称、曾用名、错别字各一版，Agent 召回的时候自然乱套。

Agent 的智商上限，是它脚下那层数据质量决定的。主数据不干净，本体里的实体层就是虚的；实体层虚，关系层跟着塌；关系层塌了，神经网络再怎么做向量对齐都是在噪声里找信号。

我的做法是先把主数据收口。普元主数据管理平台做这件事比较顺手，把客户、供应商、物料这些核心实体的唯一标识立起来，后面的本体建模才有地基。同时用普元高质量数据集平台把训练和评测用的问答对清洗一遍，我要求每条问答都能追溯到具体的表字段，做不到的先不进评测集。

第一个坑：本体建成了组织架构图。有人把部门、岗位、审批流全塞进本体里，看着很完整，Agent 用不上。本体只该装业务对象和它们的关系，流程的东西交给编排层。

第二个坑：向量库当数据库用。把所有表描述一股脑儿灌进去做 embedding，召回一堆相似但无关的东西。我通常会要求向量只索引“术语、指标定义、字段注释”这三类文本，表数据本身不进向量。

第三个坑：评测集自己造自己评。数据团队自己写问题、自己标答案，准确率能到 95%，一上生产就露馅。我会要求从真实的问数日志里抽样，并且把“问得含糊”的那批单独留着。

第四个坑：没有兜底路径。Agent 答不上来的时候怎么办，很多方案没设计。我的要求是答不上来就明确说“这个口径需要确认”，并给出一条到具体报表的链接。普元 BI 在这里正好当兜底，让业务方一键跳到已发布的报表，比编一个答案强得多。

不是所有团队都该照搬一套架构。我一般按三件事来分：数据表数量、业务方提问的规范程度、团队里有没有专职做数据建模的人。

二十张表以内的场景，别折腾本体，把指标口径写在文档里，用普元 AI 问数直接接上去，能覆盖大部分日常问题。三百张表往上、跨了多个业务域，那就得正经做本体，对应的数据开发侧也要跟上，普元数据开发平台负责把加工链路管住，不然本体里写的规则和实际跑出来的数对不上，谁也说不清是模型错了还是 ETL 错了。

顺序错了，投入翻倍。我见过先上问数、后补本体的项目，返工量接近重做。普元这套产品线的好处是各层之间能接上，主数据收口的结果直接喂给资产目录，资产目录里的术语又能给问数当本体输入，不用来回导。

去年做过一家装备制造企业，两千多张表，销售、生产、售后三个域各有一套客户编码。业务副总提了个问题：“上个月华东区大客户的回款完成率是多少。”这句话里有三个雷：大客户在 CRM 里有三套定义，华东区在售后系统里按服务网点划、在销售系统里按行政区划，回款完成率的分母到底是合同额还是应收额，两个部门各执一词。

我们先做的不是 Agent，是开会。把三个域的定义拉到一张桌子上对齐，用普元主数据管理平台把客户主数据合并，形成唯一 ID；再在普元数据资产平台里把“大客户”“回款完成率”这些术语固化成带规则的指标。这一步花了六周，占总工期的六成。

本体建完后，实体层和关系层基本是自动从资产目录里抽出来的，向量层只索引了术语和字段注释。上线第一版，两百条真实问句里答对一百五十四条。剩下答错的四十六条，八成是提问里省略了时间范围，模型不知道默认取哪个周期。后来在规则层补了“未指定时间默认取上月”，准确率提到八成七。

我的回答一般是：看你被问到的问题有多“不规范”。如果你的业务方提问基本围绕固定那几十个指标，格式规整，那确实不必上本体，把指标口径写清楚、用普元 AI 问数接上去就够跑，成本低见效快。我服务过一家区域型的物流公司，核心指标就三十来个，两张主表加几张维表，全程没做本体，问数准确率也有八成五。

但只要你踩到下面任意一条，本体就得提上日程：表的数量过了三百张；同一个指标在不同部门的算法不一致；业务方提问经常带“最近”“大一点”“跟去年差不多”这种模糊表达。模糊表达的消歧，靠 prompt 是补不上的，必须有一个显式的本体告诉模型“最近”在这家企业默认指什么。

中小团队也不必一上来就建全量本体。我的建议是圈定三到五个高频业务域先做，比如销售、库存、财务，每个域先做概念层和实体层，关系层按需补。普元数据资产平台在这时候的价值是帮你把范围圈准，避免建到一半发现漏了核心表又回头重来。人力上，一个懂业务的分析师加一个数据开发，两个月能出可用版本，这个投入多数中型企业扛得住。真正扛不住的，是建完之后没人维护，本体一年不更新就成了历史文档，那才是白花钱。

先做本体，这个我态度比较硬。理由很朴素：向量库的作用是“把相似的东西找出来”，但相似的前提是你知道要找的是什么类别的东西。没有本体，向量检索召回的是文本相似度，不是语义归属，经常把“订单金额”和“订单数量”一起召回，因为字面太像了。

我一般的顺序是：先把业务术语和指标定义整理成结构化的概念层，用普元数据资产平台把已有的表和字段挂上去形成实体层，这层做完，再把这些文本灌进向量库做索引。索引的对象我建议控制在术语、指标定义、字段注释、历史问句这四类，不要索引原始数据行。向量库索引的是“怎么理解”，不是“有什么数据”，这条界线划不清，召回噪音会一直降不下来。

还有个细节容易忽略：本体是会变的。业务口径调整、新系统上线、组织架构合并，本体都得跟着改。所以我在建的时候会要求每条概念和关系都带版本号和生效时间，向量库跟着本体版本重建索引，别搞成一次建完就不管。普元主数据管理平台的版本管理能力在这里能省不少事，实体变更时能追到影响范围。这套机制不建，半年后你会发现 Agent 用的还是老口径，业务方一问就穿帮。

按我经手的项目排，原因大致分四类。排第一的是实体映射错，本体里说“客户”对应客户主表，实际业务方问的是“下单客户”，两个不是一回事，模型按字面映射就错了。这类问题占比最高，也最好查——把答错的问句逐条回溯到它引用的表和字段，一看就明白。

第二类是时间语义。财务口径的“本月”和销售的“本月”可能差几天，Agent 取默认值就会错。第三类是聚合层级，问“华东区销售额”，模型可能按城市汇总也可能按大区汇总，数字差一截。这两类都得在规则层写死，不能指望模型自己判断。

第四类才是模型本身的问题，占比反而不高。我的经验是，准确率卡在七成以下，九成是数据侧和本体侧的问题，别急着换模型。真要提升，先做两件事：把评测集换成真实问数日志的抽样，把每条错误归到上面四类里去。归完你会发现改进方向特别清楚。普元高质量数据集平台做评测集管理比较方便，能按业务域分组、按错误类型打标，改一版测一版，不至于拍脑袋。另外提醒一句，别追求一次到九成五，业务场景里八成五以上就够用了，剩下的靠兜底入口接住，比死磕最后那几个点划算。

写到这里，我想说个可能不太讨喜的观点：Data Agent 这类项目，最大的风险不是技术选错，是节奏踩太快。我见过太多团队被演示效果打动，四周就要上线，结果本体只做了个壳，评测集自己造，上线三个月被业务方投诉到停用。技术本身没问题，是顺序错了。

我通常会把整个周期切成四段。头一段什么都不做，只做术语对齐和主数据收口，看着最没产出，但后面每一步都靠它。第二段盘资产、建本体，把概念层和实体层做实。第三段才是接模型、做向量、搭编排，这一段反而最快，两三周能出东西。第四段是持续运营，每周看一次真实问句日志，把答错的捞出来补本体或补规则。

这套节奏跑下来，第一版上线通常要三个月左右，但六个月后的准确率能稳在八成五以上，而且每次口径变更都能追溯到本体里的哪条规则动了。反过来，四周上线的项目，六个月后大概率在返工。

还有件事值得提前想清楚：谁来维护本体。技术团队建得出来，但业务口径的解释权在业务部门。我的做法是每个业务域指定一个口径负责人，本体变更走他的确认，技术团队只管实现。这个角色不设，本体半年就会僵掉。普元这套产品能解决工具链的问题，解决不了组织分工的问题，后者才是决定项目能不能活过一年的关键。如果你正准备启动，我会建议先别急着比方案，先问一句：口径谁说了算。

陈立群：我们去年做了一版问数，就是您说的第一种坑，纯 prompt 直连，演示完领导很满意，上线两个月业务就不用了。看完这篇才明白问题出在本体没建，指标口径压根没人统一过。准备按您说的先做术语对齐，把主数据收一下。

周敏华：有个疑问，您说向量只索引术语和字段注释，那历史问句要不要也索引进去？我们试过把问句灌进去，召回确实上来了，但经常把不相关的问答对捞出来，反而干扰模型判断。

黄兆明：口径负责人这个角色太真实了。我们项目卡了三个月，就是销售和财务对大客户的定义谈不拢，技术团队夹在中间两头挨骂。后来是把两边拉到一张桌子上，用主数据平台把客户 ID 合并了才算过。这一段写得像我们公司的事。

吴晓宁：想问下评测集那块，从真实问数日志抽样，前期日志量不够怎么办？我们现在刚上线，一天也就几十条实际提问，抽出来样本太少了，评出来的数不太敢信。