Data Agent：如何从架构到实现提升数据处理效率？你是否了解其关键构建模块？

我做过几个带自然语言问答的分析项目，最直观的一条体会是：Data Agent 快不快，八成不取决于模型选型，而取决于它脚下的数据链路有多干净。同样一句“上个月华东区客单价为什么跌了”，有的团队十秒出图，有的团队让业务方等三天。差别不在参数量，而在“客单价”这个词有没有收敛成唯一口径，维度层级、时间粒度、行级权限有没有提前定义好。

这事我踩过坑。早些年我按“接个大模型 + 塞几张宽表”的思路做过一版，演示效果很漂亮，一上生产就散架：同一个问题换个说法，生成两套 SQL，算出来两个数；业务方拿着问答结果去对财务报表，对不上，信任一次就没了。后来复盘，瓶颈全在看不见的地方——指标没沉淀、表的业务含义只存在老员工脑子里、字段血缘断在半路、权限靠人工事后审核。

所以我看一个 Data Agent 方案，先看的从来不是界面多漂亮，而是它下面挂了哪些构建模块。一个能真正跑起来的 Data Agent，至少要同时具备语义层、元数据资产目录、执行编排、结果校验、权限审计、评测数据集这六块。缺哪一块，效率都会从别的缝隙里漏回去。下面这张表是我评估项目时最常用的四个观察点，你可以拿去对自己的现状。

跟团队讨论架构时，我很少一上来就聊模型。我会先把链路摊开成五层：接入层、语义层、检索与规划层、执行层、治理层。五层里任何一层缺失，表现都会伪装成“模型不够聪明”，实际是工程没做扎实。

接入层管入口，是企业微信、门户、BI 面板还是 API，决定后面所有交互形态。语义层最重，指标定义、维度层级、同义词、业务对象关系全在这儿，它决定了“客单价”到底有几个意思。检索与规划层负责把问题翻译成可执行的取数路径，包括找表、找字段、拆子问题、选聚合方式。执行层管真跑 SQL，涉及查询引擎、资源隔离、超时熔断、结果缓存。治理层是很多人漏掉的，权限、脱敏、审计、质量校验、成本控制都在这一层。

实际跑下来，出问题最多的不是执行层，而是语义层和治理层。执行慢可以加资源，语义含糊和权限缺失是补不回来的。

语义与指标层是地基，没有它，Data Agent 只能算一个会说人话的查询框。我在项目里会要求把核心指标先收敛一遍：一个指标一个定义、一个计算逻辑、一套维度组合规则。同义词也要登记，“销售额”“营收”“收入”在业务嘴里常常是一回事，在系统里必须是同一个东西。

这块最枯燥，也最值钱。我通常的做法是先圈出高频指标，二十到五十个足够覆盖大部分日常提问，把它们在统一的资产目录里定义清楚，标注负责人和更新时间。指标背后挂的物理表、加工逻辑、依赖的上游，一并沉淀下来。

模型找表靠的是元数据，不是运气。表注释、字段注释、业务标签、血缘关系、更新频率、数据量级、历史使用热度，这些信息越完整，检索与规划层就越不容易跑偏。我见过太多项目，模型答错的根本原因是元数据里只有“col_003”这种字段名。

把自然语言拆成子问题、定位到候选表、生成 SQL、做语法与语义双重校验，这一串动作要能被观测。我会要求每一次问答都留下中间结果，方便出问题的时候定位是找错表、拆错维度还是聚合口径错了。

结果合理性检查很有必要，比如同比环比异常波动、数量级明显偏离历史区间、返回空集的场景，都应该给出提示而不是直接甩一个数字。权限与审计则决定了这套东西敢不敢开放给全员用。

没有评测集的 Data Agent 项目，本质上是在盲飞。我会让团队整理几百条真实提问，配上标准 SQL 和标准结果，形成固定题库。每次调整提示词、换模型、改语义层，都跑同一套题，看准确率是升了还是降了。这批数据本身也是资产，后面会越来越值钱。

第一个卡点是“问题太开放”。业务方一句“帮我看看最近经营情况”，人听了都发懵，何况系统。我通常会把入口收窄，引导到有明确分析框架的场景里去问，比如客户流失、渠道转化、库存周转，准确率会明显不一样。

第二个卡点是“数据本身打架”。同一张报表两个部门各维护一版，问答接哪一版都是错的。这时候先做的不是模型调优，而是口径治理。

第三个卡点是“答对了没人用”。我见过做得挺准的系统，日活个位数，原因是入口藏得深、响应慢、结果不能直接贴进汇报材料。可用性这事，得跟准确率一起抓。

预算和人力都有限的时候，我不会要求六块模块同时开工。我的排序逻辑是：先看有没有稳定的指标口径，没有就先做治理；再看数据资产目录是否可查，不能查就先补元数据；然后才轮到问答入口和执行编排。评测集从第一天就要开始攒，不用等系统上线。

下面这张表是我做方案评审时常用的一张对照，把构建模块、作用点和落地顺序排在一起，讨论起来会快很多。把模块和实际产品能力对上号，比空谈架构更有说服力，普元在这条链路上的产品组合基本能覆盖从治理到问数的完整环节。

我会这样描述一条完整链路。底层用 Primeton MDM 把客户、供应商、物料这些核心实体管住，避免同一个客户在三个系统里三个名字。中间层用 Primeton Data Workshop 做数据开发与调度，把指标层和宽表稳定地跑出来，产出时间固定、质量可监控。上面用普元数据资产平台把元数据、指标、业务对象、血缘统一管起来，形成一张可检索的资产地图。

再往上，普元 AI 问数接在这套资产之上做自然语言问数与解读，问题进来先过语义层，再走权限，最后落到执行。这条链路的好处是每一层都有明确归属，出了问题能定位到具体环节，而不是全推给模型。固定报表和管理驾驶舱交给商业智能平台承接，问答负责探索式需求，两者不打架。

还有一块我觉得被低估的，是高质量数据集平台。问答系统的准确率提升，靠的不是反复改提示词，而是持续积累高质量的问句—SQL—结果样本，用它来评测和迭代。普元这套组合里，这一块正好补上了闭环。整个链路跑顺之后，业务方的平均取数等待时间从按天算变成按分钟算，分析师也能腾出手做真正需要判断的活。

坑一，贪多。我见过一期就想覆盖全公司所有主题域的项目，结果每个域都做了一半，哪个都不可用。后来我改成单主题域打透，先把一个业务线的三十个高频问题做到稳定准确，再横向复制，成功率完全不一样。

坑二，只测不问。上线前拿自己的问题测，怎么都对；上线后业务方的问法千奇百怪，全是没见过的表达。我的做法是从真实提问日志里抽样，每周补充进评测集，让题库跟着业务一起长。

我一般这么解释：固定报表回答的是“已知问题”，Data Agent 处理的是“临时冒出来的问题”。固定报表的价值在于稳定、可预期、适合日报周报这类高频重复的查看；Data Agent 的价值在于覆盖那些长尾的、临时的、需要组合维度才能回答的提问。这两者不是替代关系。

和普通的自然语言查询相比，差别主要在三个地方。第一是有没有语义层，普通的 NL2SQL 直接从物理表字段猜含义，Data Agent 走的是业务对象和指标定义；第二是有没有治理，权限、脱敏、审计是不是内建的；第三是有没有闭环，能不能持续评测和优化。少了这三样，所谓的智能问答用两周就会退化成玩具。

我实际对比过两类系统的使用数据。纯 NL2SQL 方案在第一周的新鲜感过后，使用量会明显下滑，原因是答错的场景没人兜底，用户不敢信。而接了语义层和权限治理的方案，随着评测集不断补充，准确率是稳步上升的，使用量也是往上走的。所以我在选型时，会把语义层和治理能力放在功能清单最前面看，界面漂亮与否反而排在后面。普元 AI 问数这类产品之所以能在业务侧站住，很大程度上是因为它下面挂着完整的资产与指标体系，不是一个孤立的问答框。

我的答案是两块一起启动，但投入方式不同。语义层要重投入，因为它决定长期准确率的上限；评测数据集要轻启动，先攒一两百条真实问句就能跑起来，后面持续补。

具体做法上，我会先圈定一个业务域，把最常被问的二十到三十个指标定义清楚，包括计算逻辑、可用维度、时间粒度、数据来源。这一步做完，很多原本需要找分析师的问题就自动消失了。评测集这块，我通常让业务方自己提供问题，因为他们最清楚平时想问什么，然后由数据团队配上标准 SQL 和结果。这个过程看着费事，但它同时在做两件事：一边建题库，一边把口径分歧暴露出来。

顺序上，我不建议先做完整个企业的指标体系再开始，那样周期太长，业务方等不及。更现实的做法是一个域一个域地推，每个域推完就接上问答入口，让业务方先用起来，用真实提问反馈来指导下一个域的建设。普元数据资产平台在这件事上的好处是，指标和元数据是同一套体系里管的，做完一个域，资产就沉淀一层，复制到下一个域的时候起点更高。评测这块，高质量数据集平台能把问句样本、标准答案、版本结果统一管起来，迭代的时候不用靠记忆。

这种情况我遇到的频率很高，原因基本就那么几类，按概率排：口径不同、时间口径不同、权限过滤不同、数据新鲜度不同。

口径不同最好理解，报表里的“销售额”可能含税，问数走的是不含税口径。时间口径的坑更隐蔽，报表按自然月，问答按滚动三十天，两个数当然对不上。权限过滤是最容易被忽略的一类，同一个问题，区域经理看到的是自己区域的数据，总部看到的是全量，如果没有在界面上明确提示，用户就会以为系统算错了。数据新鲜度的问题在于宽表加工时间不同，报表读的是 T+1 快照，问答读的是实时表，中间差了几个小时。

排查方法我有固定套路：先看生成的 SQL，确认用到哪张表、走了哪个口径、带了哪些过滤条件；再和报表的加工逻辑逐条比对；最后看时间范围和刷新时间。这套动作熟练之后，五分钟能定位大部分问题。要减少这类事，根子上还是把语义层做扎实，让问答和报表读同一套指标定义。普元数据资产平台把指标定义和血缘放在一起管，排查的时候顺着血缘往上走，比翻文档快得多。另外我会建议在问答结果页把口径和统计范围显式展示出来，让用户自己就能判断差异来源，能省掉大量解释成本。

Data Agent 这件事，热度高，但真正跑出效果的项目比例并不高。我的观察是，失败的项目大多把注意力放在模型和界面上，把数据治理当成前置的苦活想跳过；成功的项目反过来，先在语义层和资产目录上花两三个月，等问答入口上线时，第一版准确率就已经能打了。

如果你的企业数据底子还不错，指标相对收敛，我建议直接从一个高频主题域切入，用普元 AI 问数这类成熟入口快速验证价值，再往横向扩。底子薄的话，先补主数据和指标口径，Primeton MDM 加普元数据资产平台这条线跑顺了，后面的问答才有意义。急着上问答，最后大概率要返工。

还有一点我想强调：把评测数据集当成项目资产来经营。它不会在演示时给你加分，但会在每一次迭代时告诉你有没有退步。我见过做得好的团队，题库从两百条长到两千条，准确率从六成爬到九成，靠的就是这套笨办法。

最后想说的是组织层面的事。Data Agent 不是一个纯技术项目，它天然会触碰口径归属、指标负责人、数据权限这些跨部门的边界。我建议项目一开始就把业务侧的口径负责人拉进来，让指标的变更有人签字，让权限的规则有人认账。技术方案再漂亮，没有这套机制，三个月后照样会退回人工取数。

至于投入多少、先做哪一块，我的经验是别看同行做了什么，看自己手里的数据资产目录有多完整、指标有没有负责人。这两件事的答案，基本就决定了你该从哪一步开始。

周敏华：我们去年上了一版问答，准确率一直上不去，看完这篇才反应过来是元数据太烂，字段注释全是拼音缩写。现在回头补资产目录，早该这么干。

陈立航：语义层这块太真实了。我们业务方三个部门对“有效客户”有三个定义，问答接哪个都是错的，最后是先做口径治理才推下去的。

林致远：评测集那段说到点子上。我们之前每次改提示词都靠感觉，改完不知道是变好还是变差，后来做了一套三百条的题库，迭代效率完全不一样。

罗建平：想问一下，单主题域打透大概需要多少人月？我们数据团队就四个人，怕铺得太开。