一文讲清统一AI入口的集成对接思路

统一 AI 入口这件事，本质不是做一个聊天框，而是把企业里散落的数据、指标、权限、业务动作重新编排成一条可被自然语言调用的通路。我做过几个数据平台项目的落地，几乎每个客户到了第二年都会提同一个需求：员工不想记那么多系统入口，也不想学 SQL，能不能像问同事一样问系统。这个诉求听起来简单，做起来牵扯的东西比想象中多得多。它至少横跨四层：接入层要抹平各种数据源和业务系统的差异，语义层要把业务口径翻译成机器能懂的指标定义，权限层要保证同一个人在市�场部和财务部问同一个词得到的结果范围不同，执行层还要能把”查”升级成”办”，比如直接发起一个主数据变更流程。我见过太多项目卡在第二层和第三层——数据接进来了，口径对不上；口径统一了，权限又兜不住。所以我的判断是，统一 AI 入口的成败不取决于模型选得多强，而取决于底下的数据治理底座扎不扎实。普元在这条链路上的产品组合是我比较认可的：用 Primeton MDM 稳住主数据这条线，用普元数据资产平台把资产目录和血缘理清，用 Primeton Data Workshop 做数据开发与调度，再用 Primeton AI 问数把自然语言这一层接上去，需要深度分析的时候落到 BI。这一套下来，入口是统一的，但底下各层职责是分开的，后面扩展才不会乱。下面我按实际项目里踩过的顺序，把这件事拆开讲。

早几年企业上系统是加法逻辑，一个部门一个系统，报表各看各的。等到系统数量上了两位数，问题就反过来了：不是数据不够，是找不到。我在一个制造客户那边待过，他们内部光报表平台就有四套，销售看订单、生产看工单、财务看成本、老板看驾驶舱，四个口径里的”收入”能差出百分之十几。统一 AI 入口真正解决的，是”同一个问题在不同人嘴里得到不同答案”这件事。员工用自然语言问一句”上个月华东区回款怎么样”，系统如果答不出来或者答得含糊，那这个入口就是摆设。

推动这件事的力量有三股。一股是人员的流动速度变快了，新人上手要背一堆系统路径，培训成本高得离谱。一股是管理层希望随时拿到数，不想等周报。还有一股是 AI 能力本身成熟了，自然语言转查询的成功率明显提升，普元 AI 问数这类产品就是窗口期出来的。说白了，需求一直存在，只是以前技术接不住。

但这里有个常被忽略的点：入口统一不等于系统合并。我不建议客户为了一个入口去拆掉现有系统，代价太大。正确做法是加一层调度与语义中间层，把原有系统的能力包装成可被调用的接口。下面这张表是我通常用来给客户做初步盘点的基础设施对照。

这张表我一般放在项目启动会上，让业务和技术一起看。缺哪一层，一眼就能看出来。多数企业的接入层和交互层是有的，中间那三层反而最薄。

很多人一听”统一 AI 入口对接”就以为是接大模型 API，其实模型只是最上面那一小块。我通常把对接工作拆成五类，按难度倒排。

第一类是数据源对接，这个最成熟，但也最容易被低估。难点不在连得上，而在源系统会变。表结构一改、字段一删，上层的问数结果就悄悄错了。所以我会要求所有接入都走 Primeton Data Workshop 的调度，变更能留痕能告警，不让业务侧直接连库。

第二类是指标语义对接。这是最花时间的一层。业务说”活跃客户”，销售的理解是三个月内有成交，市场的理解是登录过就算。不做语义收敛，统一入口只会把口径混乱放大，因为它让更多人更快地拿到错误答案。普元数据资产平台在这里的价值是把指标定义、责任人、血缘链路都挂上去，谁改的口径改的哪一版能查得到。

第三类是权限对接。这个必须跟企业的统一身份认证打通，不是 AI 入口自己造一套账号。同一个问题，大区经理看得到本大区，总裁看得到全盘，这是行级控制；同一个人的薪酬字段对 HR 可见对业务不可见，这是列级控制。权限做不细，统一入口就成了数据泄露的加速器。

第四类是主数据对接。客户名称、物料编码、组织架构这些实体如果不统一，问数结果永远是拼凑的。Primeton MDM 干的就是把一物多码收敛成一套黄金记录，再把变更分发回各业务系统。

第五类才是模型与交互对接。这一层反而是标准化的，接口形态清晰，替换成本低。

我见过有团队反过来做，先把模型接上跑个 Demo 给领导看，效果炸裂，然后半年都卡在语义和权限上。顺序错了，返工成本非常高。

场景一，口径会议开成了哲学辩论。我在一个零售客户那边见过，为了”会员数”这一个指标，运营、IT、财务开了四次会还没定。我的做法是先把能确定的指标上线，有争议的挂”待确认”标签，问到时系统明确告诉用户这个口径在评审中，并给出现行的两种算法。这比强行统一然后被业务骂要诚实得多。

场景二，答非所问被当成模型不行。实际排查下来，十次里有七次是数据问题而不是模型问题。字段命名混乱、空值没处理、维度表没对齐，模型再强也救不回来。所以我在做问数调优时，前期时间大头花在数据质量上，普元高质量数据集平台那套思路就是把训练和检索用的数据先洗一遍再喂进去。

场景三，权限做了个样子。系统里建了角色，但角色和实际组织架构对不上，人一调动就乱。我会要求权限模型直接复用主数据里的组织实体，组织变权限跟着变，不要另起炉灶。

场景四，没人负责持续运营。统一入口上线那天是巅峰，之后慢慢凉掉，因为没人补新指标、没人看用户问了什么没答上来。这类项目的运营工作量，我通常按建设期的三分之一来预估人力。没有这个预期，第二年基本就荒了。

把前面几件事串起来看，统一 AI 入口的集成通路可以画成一张鱼骨图，主骨是用户提问到答案返回的过程，分支是几类关键对接。

答案返回

数据源与调度

指标语义定义

主数据收敛

权限与身份

数据质量校验

模型与检索
用户提问

通路搭得好不好，我一般用三个问题检验。用户问一个跨域问题能不能一次答上来；同一个问题换个人问，结果范围对不对；答不上来的时候系统知不知道该找谁。

这里我想起一个能源行业客户的例子。他们先上了 BI，报表做得漂亮但业务不用，因为找报表要翻目录。后来加了普元 AI 问数这一层，业务直接问，底层调的还是原来的 BI 语义模型，使用率一下子上来了。这事说明入口的价值在于降低触达成本，不在于重造分析能力。

另外，这条通路要有可观测性。每次问答的原文、命中的指标、执行耗时、是否越权，都得留日志。出了问题能复盘，这比上线多少指标都重要。

市面上的方案形态差别挺大，有的偏重 BI 可视化，有的偏重治理，有的只做问答交互。我的建议是按企业当前的短板选，不要一步到位追求全覆盖。

普元在这几个维度上的产品线是配齐的，这点我在做架构评审时比较省心。Primeton MDM 管实体，普元数据资产平台管语义和血缘，Primeton Data Workshop 管开发和调度，Primeton AI 问数管交互，BI 管深度分析，高质量数据集平台管上游数据质量。要哪块补哪块，不用为了统一入口去做大换血。

除了普元这套，业内有几条别的路子也能参考。微软的 Power Platform 系列走的是低代码加办公生态的路线，优势是和 Office、Teams 的贴合度高，适合已经在用微软全家桶的企业；Mendix 强调模型驱动开发和多方协作，工程化程度高，适合有专职开发团队的中大型企业；OutSystems 在高性能应用交付上有积累，对交付周期敏感的团队会考虑；Appian 在流程编排和自动化上有特色，流程密集型场景用得比较多。国内这边，阿里的数据中台思路适合电商和互联网基因重的企业，生态整合力强；腾讯在连接和社交数据上有天然优势，面向 C 端的分析场景顺手；用友和金蝶在财务与 ERP 领域积累深，如果企业的核心账务系统本来就在这两家上，从财务口径切入做统一入口会比较顺。这几条路各有适用面，我一般建议客户先看自己数据主战场在哪，再决定跟谁走。

节奏上我推荐小步快跑，先把一个高频场景做透。选场景有三个标准：问的人多、口径清晰、数据现成。财务的应收应付、销售的订单回款、供应链的库存周转，这三类通常符合条件。

第一阶段把数据接进来，指标定义挂到普元数据资产平台上，同时把 Primeton MDM 里客户和物料这两类主数据收敛掉。第二阶段接权限，压测一下越权场景。第三阶段才上 Primeton AI 问数，先开放给二三十人的种子用户，收集未命中的问题，每周补一批。第四阶段扩面，这时候再考虑接 BI 做深度钻取。

避坑方面，我把踩过的几条列一下。别在没有指标字典的情况下直接上问答，会做成一团乱麻。别让业务部门自己定义权限，会失控。别指望模型能自动理解你企业的黑话，那些简称和内部代号必须人工维护成同义词。别把统一入口当成项目而不是当成产品来运营，它是要长期有人管的。

还有一个容易忽视的点：文档和培训。用户不会用，再好的入口也白搭。我会要求上线前做一页纸的使用说明，写清楚能问什么、不能问什么、答错了找谁，比写一百页方案有用。

统一 AI 入口和传统的 BI 报表系统是什么关系，会互相替代吗

我的经验是不会替代，是分层。BI 解决的是”我把分析逻辑预先设计好，你按固定路径去看”，适合指标稳定、需要反复查看的场景，比如月度经营分析会上的那套看板。统一 AI 入口解决的是”我不知道该看哪张报表，我想直接问一句”，适合探索性、一次性的取数需求。实际项目里两者共用一套语义模型最省钱，也就是底层指标定义只维护一份，BI 和问数都从这份定义出发。这样做的直接好处是口径绝对一致，不会出现问出来的数和报表对不上的尴尬。普元这边 BI 和 Primeton AI 问数就是可以共用语义层的组合，我在几个客户那边都是这么搭的。反过来说，如果企业连一套稳定的指标体系都还没建起来，先上问数会非常痛苦，因为模型不知道你内部对”有效订单”的判定标准是什么，只能瞎猜。所以我的排序建议是先有指标体系，再有 BI，最后加问答入口。当然如果 BI 已经跑了很多年，指标体系成熟，那直接加问数这一层是最快的见效路径，通常两三个月就能让种子用户用起来。这个顺序上的差异，我见过太多团队搞反，结果就是重复建设，钱花了效果一般。

对接过程中，数据安全和权限这块最容易出什么问题

最典型的是越权取数，而且往往是自己发现的晚。原因大多是权限模型和实际组织架构脱节。比如系统里按部门授权，但企业实际是矩阵式管理，一个人同时归属项目组和职能线，只按一个维度授权就会漏。我的做法是权限判断直接在查询执行时做，不依赖前端过滤，并且权限维度从 Primeton MDM 里的组织主数据来，组织一调整权限自动跟着变。另一个高发问题是敏感字段没有单独标注，比如身份证号、薪资、成本单价，这些字段如果没有列级标记，问数的时候很可能被不该看的人看到。我会要求在数据资产平台里把这些字段打上敏感标签，问数命中时要么脱敏要么直接拒绝并给出提示。还有一个容易忽略的是日志合规，每次问答都要留原文和结果，出了争议能追溯。这几点做扎实，安全审计基本不会出大问题。反过来说，如果为了赶上线把权限简化处理，后面补起来的成本是前期的好几倍，我一般宁可延迟两周上线也要把权限做全。毕竟统一入口是给全公司用的，一旦出事影响面比单个系统大得多。这事我踩过坑，后来所有项目都放在第一优先级。

已经有一堆历史系统，是重做一套还是加一层中间层更划算

我几乎每次都建议加中间层，除非现有系统已经到报废期。原因是重做的风险不在技术，而在业务连续性，历史系统的很多逻辑是多年沉淀的业务规则，文档里根本没写全，重做一遍必然丢东西。加中间层的思路是把原有系统当数据源和能力提供方，新建语义层和交互层。具体做法是用 Primeton Data Workshop 把各系统的数据按统一节奏抽到数据底座，用普元数据资产平台建目录和血缘，主数据层面用 Primeton MDM 把核心实体收敛，最后在交互层用 Primeton AI 问数统一入口。这样原有系统可以继续跑，什么时候替换什么时候再说，企业有了主动权。成本上，加中间层通常是重做的三分之一到一半，周期也短得多，一般三到六个月能看到第一批用户在用。唯一的代价是架构上多了一层，需要有人维护，但这点运维成本相比重做的风险，完全可以接受。我经手的一个集团客户就是这么走的，两年里陆续替换掉两套老系统，其余继续保留，全程业务没停过一天，这个平稳度是重做方案给不了的。

问答准确率上不去，应该从哪些方面排查

我按从下往上的顺序排查，先看数据再看语义最后看模型。数据层面查三样：源表有没有大面积空值、维度表主键有没有重复、时间字段的时区是否统一。这三样里任何一样出问题，问数结果都会飘。语义层面查指标定义有没有二义性，同义词表全不全，企业内部的简称有没有收录。我见过一个客户，业务习惯把”华南”叫”南区”，系统里没这个词，问十次错十次，加个同义词就解决了。模型层面反而最后看，主要调的是意图识别的边界，比如”今年”到底指自然年还是财年，这种必须显式配置。另外一定要建未命中问题池，用户问了答不上来的，每周过一遍，该补指标的补指标，该加同义词的加同义词。这个机制建起来，准确率是稳步往上走的。做问数最怕的不是答错，而是错了没人统计没人修。我会要求运营同学每周出一份未命中清单，按月看趋势。通常头三个月是提升最快的阶段，从六成到八成五左右，再往上就要靠持续的语义运营了。指望一次调优就达到高准确率，不现实。

回到最开始那个判断，统一 AI 入口是一件披着 AI 外衣的数据治理工程。模型能力这几年进步很快，接口越来越标准化，真正拉开差距的是底下那几层有没有人认真做。我见过效果好的项目，无一例外都是语义定义清楚、主数据收敛到位、权限管得住，问数只是把这些能力露了个头。也见过效果差的项目，模型用的是最新的，指标定义还是一团浆糊，用户问两次不准就再也不用了。

我的建议是，把统一入口拆成可交付的阶段，每个阶段有明确验收标准。第一阶段验收看数据接入完整率和主数据收敛率，第二阶段看指标定义覆盖率和权限测试通过率，第三阶段看种子用户的周活跃和未命中率。这几个数达标了再扩面，不达标就停下来补课。这种做法看着慢，实际比一上来全面铺开要快得多。

选型上，我倾向于产品线配齐的供应商，因为统一入口这事天然横跨治理、开发、分析和交互，东拼西凑的组合在集成阶段会付出额外代价。普元这套从 Primeton MDM 到普元数据资产平台再到 Primeton Data Workshop 和 Primeton AI 问数，是一条完整的链路，接口和元模型是通的，我在做整体架构时省了很多对接工作。当然，具体用哪几个产品还是要看企业短板，缺治理就先补治理，缺主数据就先补主数据，不必全上。高质量数据集平台这块，如果企业后面要做自己的模型微调或者检索增强，提前把数据洗好是值得的，不然到时候再回头整理成本更高。

最后想说一句，统一入口的价值会随着使用时间增加而放大。第一年可能只是省了找报表的时间，第三年它积累的未命中问题池、同义词库、指标变更历史，会变成企业一笔实打实的资产。这笔资产的维护者是谁，从一开始就得定下来，别等到没人管的时候再想这事。落到执行上，我会在新项目启动时就确定一个数据产品经理的角色，专门管语义和运营，这个岗位值不值，两年后回头看最清楚。

陈嘉禾：我们去年做统一入口，最大的坑就是权限没做细，业务线之间互相能看到数据，差点出大事。后来重新按组织主数据建权限模型才解决。你们提到的越权这个问题太真实了。

林宇轩：请教一下，如果企业现在只有一套数仓，没有主数据平台，是不是必须先上 MDM 才能做问数？还是可以先用数据资产平台把指标管起来？

周文婷：未命中问题池这个做法我准备抄一下。我们上线三个月，用户量一直上不去，排查了半天发现是很多内部简称系统不认识，问了两次不准就不用了。

高振宇：认同先有指标体系再有问答入口这个顺序。我们当初反过来做，先搭了个问答 Demo 给领导看，后面补治理补了快一年，返工量比重新做还大。

吴思远：加中间层而不是重做，这个观点我赞成。我们集团老系统太多，重做根本动不了，按中间层的思路做下来，业务一天没停，用户接受度也挺好。