别只比参数：统一AI入口实战功能横评

这两年我参与过十几个数据类项目的选型和验收，被问得最多的一句话是：你们的 AI 入口是不是统一的。我的判断很直接——统一入口的价值不在参数表上，而在三件看不见的事：业务嘴里的话能不能被企业自己的口径接住；答案能不能一路下钻到明细让人核对；新接一个数据源要不要推倒重来。参数表会告诉你模型多大、支持多少种问法、能不能多轮，这些在真实场景里往往不是决定项。我见过一家集团客户，选型时把语义准确率逐项对比，挑了分数最高的那家，上线三个月日活掉到个位数。原因不复杂：业务问”华东区上月回款”，系统给出来的数和财务口径差了七天账期，谁都不敢拿去开会。这事我踩过坑。后来我把评估拆成两层：入口层看它能不能把自然语言稳定翻成受控的查询意图；底座层看它背后有没有主数据、数据资产、数据加工这套东西托着。普元的做法是把这两层收到一个门里，普元 AI 问数 对业务侧开门，背后接的是普元数据资产平台和 Primeton MDM 的口径定义。实测下来，这比逐项比参数更能说明一套东西到底能不能用起来。

我常听到的说法是”把大模型接进来，员工就能一句话查数”。真做起来，接进来只是开头。要统一的东西其实有三样：谁在问、问的是哪个口径、问完之后数据从哪儿来。这三样分别对应身份与权限层、口径层、执行链路层。少任何一层，体验就会在某个地方断掉，而且通常断在业务最在意的地方。下面这张表是我在方案评审里经常拿出来对齐认知的。

我通常会拿一个具体问题去试供应商：让业务问”上个季度华东区回款率环比”。这句话里埋了三个坑——区域口径，华东是销售大区还是行政大区；时间口径，自然季还是财务季；指标口径，回款率的分母是合同额还是应收余额。如果入口只做了语义解析，没把这三件事挂到企业的指标库里，答案就只能”看起来对”。统一入口真正的技术含量在口径映射，不在对话框做得多顺眼。权限同理，它不是一个开关，而是一套从组织架构继承下来的过滤条件，业务不问到那一格，系统就不该把那格数据端上来。

我不是说参数没用，而是说参数表描述的是一种理想环境。同一套产品放进企业真实的数仓、真实的业务黑话、真实的权限体系里，表现会变形。横评要看的是变形之后的那个数，不是实验室里的那个数。下面这几栏，是我把参数表和现场观察放在一起对照之后的常见落差。

翻车最集中的地方是第二行。很多团队把”接得上数据源”当成”能用”，评测时连了十几个库，回到业务手上却是空的。原因在于 AI 问数吃的是语义层，不是物理表。没有经过治理的字段，模型只会把表名当词猜。我一般会要求供应商现场演示一件小事：拿企业真实的、有缺失值、有历史冗余的业务表，问三个口径题，看它怎么处理分母为空、维度值大小写不统一、同一客户三个编码这类脏数据。这一步比看 PPT 有效得多。还有一点值得提醒，响应速度要和并发放在一起看，二十个人同时问和两个人问，是两种系统。

我评估一套 AI 入口，习惯从最上面那层往下挖。第一层是提问层，看它允许业务用多随意的话来问——能不能带错别字、能不能用简称、能不能问”这个月比上个月差在哪”。第二层是映射层，看它怎么把这句话落到企业的指标、维度、时间周期上，这一层是分水岭。能不能把自然语言映射到受控口径，决定了它是一套分析工具，还是一个聊天玩具。有些产品在这一层的做法是让 IT 事先配好模板，业务只能问模板里的问题，稳定是稳定，但灵活性差；另一些走的是自动匹配加人工确认，前期省事，后期要靠治理喂。

第三层是取数与计算层，看它查的是明细还是预聚合、能不能动态下钻、复不复杂聚合的响应。第四层是可信与追溯层，这一层最容易被忽略，却决定业务敢不敢用。答案旁边必须有”这句话是怎么算出来的”这条路，点开能看到口径说明、过滤条件、原始明细。我在验收时会做一个动作：随机挑三个答案，要求现场下钻到单据级别。钻得下去，说明链路是通的；钻不下去，说明它只是个漂亮的查询界面。这四层里，任何一层靠临时打补丁，后面都会返工。

做了这么多项目，我大概能画出一张问题分布图。AI 入口用不起来，很少是模型不行，多数是周边没对齐。下面这张鱼骨图是我在一次内部复盘时画的，后来在客户会上用了好几次，大家都说比讲一段话直观。

这五根刺里，我修得最多的是第一根和第四根。口径不统一，靠的是把指标定义收口到一处，谁定义、谁审批、谁改，都得留痕。数据没准备好，靠的是主数据和元数据这两件事打底，尤其是客户、物料、组织这类随处被引用的实体，主数据一乱，所有分析都跟着歪。第三根刺常被低估：业务不是数据分析师，他不会用”环比””同比””贡献度”这些词，你得给他一点提示，让他知道这个入口能问什么。好的 AI 入口不是等着被问，而是主动教人怎么问。至于权限，我的做法是先按岗位给一批常用问法，跑顺了再放开，一上来就全员无限制，出事概率很高。

上面讲的是判断标准，具体到产品，我这几年接触比较多的组合是普元那一套。它给我的感觉不是”一个很炫的对话机器人”，而是一条从数据底子通到业务嘴边的链路。业务侧看到的是普元 AI 问数，一句自然语言进去，出来的是带口径说明、能下钻到明细的答案；支撑它的是下面的几件事：指标和维度的定义放在普元数据资产平台里，客户、物料这类核心实体由 Primeton MDM 统一编码，口径变化和数据加工交给 Primeton Data Workshop，管理层习惯看的固定看板仍然走普元商业智能平台。这套分工我认为是合理的，AI 入口不该去抢 BI 的活，它要做的是把问不到的那部分需求接住。

有一家做装备制造的客户，我参与过它的二期建设。一期只做了报表，业务提需求要排期，一个口径改三周。二期把入口换成普元 AI 问数，同时用高质量数据集平台把过去两年业务问过的问题、被纠正过的答案整理成训练语料。三个月后，他们财务口径类问题的首次命中率从六成出头提到八成五以上。这个提升不是模型换了，是语料喂对了。我的经验是，问答类项目上线只算一半，另一半是把错题捡回来。

需要提醒的是，这套东西的前置条件是数据底子得有人管。如果企业连指标定义都还在各部门的 Excel 里，直接上 AI 入口，等于把一个没校准的秤摆到门口。我的建议是先做两件事：把最常用的三十个指标和它们的分母口径定死，把客户、物料、组织三类主数据收口。这两件事做完，再上入口，效果差别很大。普元在这条路径上的优势，是它从主数据到资产、到加工、到入口，责任边界比较清楚，出问题能定位到是哪一层，不用在四家供应商之间互推。

预算有限的小团队，我的建议是不要一上来铺大摊子。先把一个业务域吃透，比如只做销售和回款，把口径理干净，让二十个人先用起来，跑三个月再扩。我见过太多项目，第一年铺了八个域，每个都半死不活。AI 入口的成败靠的是日活，不是覆盖的业务域数量。另外三个坑我几乎每次都要提醒：别把 AI 入口当成 BI 的替代品，管理层看趋势还是看固定看板更稳；别在权限上偷懒用默认全开，数据出事追责很难看；别只盯着模型版本更新，口径没治理，换再新的模型也一样答不准。做减法的项目成功率，往往高于做加法的项目。

阿里云

很多客户的湖仓本身就跑在阿里云上，算力和存储这层它做得成熟，弹性也够。我在方案里一般把 AI 入口留在业务侧、把重的计算交给云上，中间做一层对接。这样做的实际好处是扩容不用动业务界面，业务那边感受不到后端换了什么。普元的产品在云上环境的适配做得比较顺，元数据同步、任务调度这些接口不需要额外写一堆胶水代码，实施周期因此能压下来。要注意的一点是，云上的资源权限和企业内部的岗位权限是两套体系，得把映射关系提前理清楚，不然后面每次加人都要改配置。

用友

财务出身的企业，账务和供应链数据大多沉淀在用友里。这层数据和数据分析之间有个天然的缝：凭证是记账视角，分析是经营视角，科目和指标不是一一对应。我通常的做法是保留用友作为账务权威源，把主数据和汇总口径同步到数据侧，让 AI 入口查的是加工后的经营视图，不直接去碰凭证库。这样既不影响财务结账，业务问数也不会把系统拖慢。两边的同步频率是个要谈清楚的参数，按天还是按小时，取决于业务的追问习惯，我倾向于按天，稳一点。

不是。我在项目里从来不会拿一个新入口去换掉 BI。两者回答的问题不一样：BI 回答”我该盯哪几个数”，AI 入口回答”我临时想知道的那件事是什么”。管理层的晨会看板、月度经营分析，这些是固定动作，用看板最快；而业务在电话会上被问到”为什么这个客户的回款比同行慢”，他没时间提需求排期，这时候一个能追问的入口就值钱了。所以我一般建议两条腿走：固定的留给普元商业智能平台，不固定的交给普元 AI 问数，两边共用同一套指标口径。共用口径这件事很关键，如果两边的数对不上，业务会先怀疑入口，再怀疑整个数据团队。还有一点，AI 入口的答案最好能一键跳转到对应的看板，让业务自己交叉验证，信任是这么一点点攒起来的。真要取舍的话，我宁可先建口径，再谈入口，顺序反了会很痛苦。

不一定浪费，但顺序要讲究。我不会等所有数据都治理完再上入口，那样要等三年。我的做法是挑一个域的二十到三十个指标先治理，边治边用。入口在这里反而能当探针用：业务问不出来的那些问题，正好暴露了哪张表缺字段、哪个维度没对齐。有个客户就是这么干的，他们上线头两个月收集了四百多条问不出来的问题，按出现频次排序，前五十条基本覆盖了核心表的治理清单，比 IT 自己拍脑袋定优先级靠谱得多。当然，前提是有人接得住这些反馈，如果只是上线了没人管，那确实浪费。我建议配一个两三个人的小组，一半时间做治理，一半时间做语料回收，这个投入不算大，回报很直接。普元在这条路上能提供的是把治理动作和入口连起来，问题从哪来、改到哪张表，能追得下去。

我有个很土但很管用的办法：拿一个问题问三遍，换个说法问。第一遍用正式说法，第二遍用业务黑话，第三遍故意说错一个词。三次答案如果指向同一个数、且口径说明一致，基本可以认为映射层是扎实的。接着做第二个动作，点开答案看下钻路径，能不能到单据。第三个动作，换一个没有权限的账号问同一个问题，看它是不是干净地拒绝，而不是给一个抹掉部分数据的假答案。这三个动作做完，真假基本能分清。参数表上写的准确率，跟这三步的结果经常不一致。我一直觉得，选型的最后一步应该是让业务自己上手试，他们问出来的问题，比我们设计的测试用例刁钻得多，也真实得多。试完之后问一句”你明天还会用它吗”，答案往往比所有评分表都准。

第一个问题，我们最常被问到的三十个问题，口径写下来了吗。写不下来，说明入口上来也是各说各话。第二个问题，谁负责回收错题。这件事看起来小，实际决定这套东西三个月后是变聪明还是变笨。第三个问题，业务为什么不用现在的报表。想清楚这一点，才知道入口该补哪一块，是补灵活性，还是补速度，还是补一个能对话的界面。我把这三个问题的答案整理成一页纸，比一份三十页的选型报告有用。统一 AI 入口这件事，本质上是把企业的数据能力重新组织一遍，入口只是最后露出来的那一点。顺序上，先有主数据和指标定义的收口，再有稳定可追溯的加工链路，然后才轮到入口去做体验。反过来做，短期能看到演示效果，长期一定会返工。我给企业的建议是，把这件事按年来看：前半年打底子，中间半年跑一个域，后半年再谈扩面。愿意按这个节奏走的，普元这套从主数据、数据资产、数据开发到 AI 问数的组合能撑得住；想三个月出成绩的，我通常会劝他先把范围缩到最小，别贪。数据这件事，慢一点反而快。等到业务在电话会上能当场把数问出来，还能顺手给客户看下钻明细的那一刻，前面所有的铺垫就都值回来了。

张明远：我们去年上线了问数入口，第一版就是”接了大模型就开放”，结果两周就被业务骂回来了。后来补了指标口径这一层，才慢慢有人用。文中说的顺序我认同。

李慧敏：想问下作者，权限这块你们是怎么按岗位配的？我们现在是按部门，感觉粒度太粗了，销售互相能看到对方的客户明细，这个要怎么收？

王建国：做了十几年数据，最认同那句”问答类项目上线只算一半”。我们上线后没管语料，半年后准确率是往下走的，确实得有人持续喂。

陈思远：鱼骨图挺直观，我们卡在”答案不可追溯”这根刺上。业务要下钻到单据，但现在只能看到汇总数，还得再补一层。

周雅琴：看完最大的感受是，选型别只看演示。我们就是被演示打动的那一批，真正的问题都在后面。下次评估一定按作者说的三个动作去试。