破除大模型统一接入迷思：回归业务本质

我做过一个粗略统计：过去两年我以顾问身份参与的二十多个企业级大模型项目里，超过一半的团队，前三个月都在做同一件事——统一接入。统一网关、统一鉴权、统一计费、统一提示词模板、统一向量库选型。做完演示很流畅，业务方也点头。半年后我再回访，真正跑上线并且还在用的场景，不到三成。大模型统一接入这件事，工程上不难，难的是接入之后模型要回答的那个问题——企业自己都没定义清楚。

我见过最典型的一幕：某制造集团的IT团队花两个月搭好了统一接入层，接了三家模型服务，第一个业务场景是”帮销售查客户历史订单”。跑起来才发现，客户主数据在两个系统里各有一份，订单金额在三套报表里三个口径，销售看到的数字和财务看到的对不上。接入没问题，答案错了。业务方一句话把项目按下暂停：你们先把这个客户到底是谁搞清楚。

所以我的判断很直接：统一接入是必要的基础设施，但它是插座，不是电器。它管模型怎么调、成本怎么控、日志怎么留，管不了数据是不是可信、指标是不是唯一、权限是不是合规。企业真正该回答的是三个问题：我的数据能不能被模型安全地读到？我的指标口径是不是唯一的？我的业务方愿不愿意为场景结果负责？这三个答不上来，接十个模型也一样，只是把错误答案的生成速度提高了十倍。

回归业务本质，落到工程上就是三件事：把数据资产盘清楚、把高质量数据集做出来、把AI能力嵌进业务人员每天要用的界面里。下面我按这个顺序拆开讲，中间会放几张我给客户讲课时常用的对照表和一张鱼骨图，都是实际项目里磨出来的东西，不是画给PPT看的。

先把边界划清楚，免得团队在该做数据治理的时候去做网关。统一接入真正能干的活有四类：模型调用的统一封装、密钥与额度的统一管理、调用量与成本的统一计量、不同模型输出格式的统一归一。这四件事做完，IT团队的运维负担确实会下降，后面换模型、加模型、限流、灰度都有抓手。但接入层的能力止步于”把请求发出去、把回答收回来”，它本身不产生业务价值。

我通常会让客户在立项表上做一道填空题：把”接入层能解决的诉求”和”业务方真正关心的诉求”分两列写。写完大多数人会发现，右边那一列一个都落不到网关头上。下面这张表是我整理过的常见对照，你可以直接拿去对自己的项目。

这张表我用了两年，每次评审都会出现。接入层解决的是”能不能用”，业务关心的是”准不准、敢不敢用”，中间隔着一整套数据工程。绕过数据去做接入，项目极大概率停在POC阶段，而且停的时候大家都觉得是模型不行。

市面上的做法基本能归到三类。一类是纯网关型，把模型当成外部API来管，追求”一次接入、多处复用”；一类是平台一体型，把模型服务、数据服务、应用编排放在同一个平台里，走”数据和AI不拆家”的路子；还有一类是场景驱动型，不建大平台，先挑一个高频场景，把闭环做穿，跑通再复制。

我不认为哪条路绝对正确，但适用条件差别很大。下面这张对比表是按我的落地经验填的，”见效速度”和”长期成本”两列争议最多，你可以按自己的情况改权重。

我的取舍逻辑是：企业已经有比较成熟的数据治理体系，走平台一体型的收益最大，因为模型能直接吃到可信的数据资产；数据基础还很散，就先做场景驱动型，用一个能算清收益的闭环去倒逼治理，比先建平台现实得多。纯网关型适合作为既有体系的一个补充件，不适合当起点。

这里提醒一句：路线选错不会立刻暴露，通常要到第二、第三个场景复制的时候才疼。到那个时候改造成本已经是原来的好几倍，而且业务方的耐心也消耗得差不多了。

某股份制银行，接入层做得非常规整，切换模型只要改一行配置。他们的AI问数场景上线后，业务人员问”上个月华东区对公存款日均余额”，模型给的数字和报表差了七个亿。查了两周，问题出在”日均余额”这个指标，三个部门三套算法。接入层一点毛病没有，是指标从来没被治理过。

某能源集团做设备故障问答，把十年的检修报告全量灌进知识库，效果一直上不去。我们翻了三百份文档，格式五花八门，同一台设备的编号在五份报告里出现过四种写法。喂给模型的不是知识，是噪声。后来他们把设备台账先在主数据层面做了唯一化，同样的问题，答案的可用性肉眼可见地往上走。

某零售企业更有意思。技术团队做得挺好，业务方也认，但用的人一直很少。我跟着他们看了两天，发现业务人员要问一个问题，得先打开一个独立的AI窗口，登录、选知识库、把Excel里的客户号复制进去。AI没有嵌进他们每天用的界面，就等于不存在。后来把问数入口挂进已有的BI看板里，用量一周翻了六倍。

这三个片段指向同一件事：接入是技术活，落地是业务活。技术团队能决定模型跑不跑得起来，决定不了它有没有人用。中间那道坎，几乎全是数据和组织的事。

我习惯在项目复盘时画一张鱼骨图，把”效果差”这个结果头摆在右边，往左追原因。画过十来次之后，骨头的形状基本稳定下来，就那么六根。下面这张是我简化过的版本，拿去就能用在你们的复盘会上。

大模型场景效果差的原因拆解

场景效果差

数据口径不统一

指标没有唯一定义

权限与脱敏滞后

场景选得太泛

没有业务负责人

缺少评测与回流

六根骨头里，真正属于技术侧的只有”权限与脱敏”那一根，剩下五根全是业务和数据治理的事。这就是为什么我总说，大模型项目的问题清单里，八成写着数据治理的答案。团队如果拿着一张纯技术的排期表去做这件事，走到一半一定会发现排期表上没写的东西才是关键路径。

我个人最看重”业务负责人”和”评测回流”这两根。前者决定场景有没有人拍板，出了问题有没有人兜；后者决定它能不能越用越好，而不是上线即巅峰。很多团队把评测做成了技术指标，跑一堆准确率、召回率，业务方看不懂也不关心。我建议把评测指标直接翻译成业务语言——问数答案和财务口径的一致率是多少，故障问答被运维采纳的比例是多少。指标能被业务看懂，场景才有可能活下来。

我判断一个企业该从哪里起步，主要看两件事：核心实体有没有唯一化，指标有没有统一定义。按这两个维度，大致分成三层，对应的动作差别很大。

第一层最该做的不是接模型，而是把主数据立起来。普元的主数据管理平台阶段的用处很实在，它把客户、供应商、物料、组织这些核心实体的唯一标识和分发机制管住，后面所有AI场景的数据来源才是干净的。这一步看起来离AI很远，其实是所有AI场景的地基。

第二层是主数据有了，但指标和分析口径还在打架。这个阶段我会建议先把数据资产盘清楚，普元数据资产平台能把散落的数据表、指标、报表做成一本能查的账，谁在用什么数据、口径从哪来，都能追。同时用Primeton Data Workshop把数据开发流程规范起来，让做数据集的人和用数据集的人说的是同一套语言。口径这件事不上收，AI问数就永远对不齐报表。

第三层就好办了，不要再纠结平台建得多完整，直接把场景跑起来。普元AI问数是我比较推荐的一个入口，业务人员用自然语言提问，系统基于已经治理过的指标和数据资产给答案，结果能追溯到口径，不是模型自己编出来的。这件事的意义在于，它把大模型能力和数据治理成果绑在了一起，避免了”听着挺像、数字全是假的”这种最伤信任的情况。

还有一类需求值得单独说：企业要微调或者要做一个垂直领域模型，核心资产不是算力，是数据集。普元的高质量数据集开发工厂就是为这个准备的，把原始数据经过清洗、标注、脱敏、评测，做成可以反复复用的训练与评测数据集。我见过太多团队把预算全砸在算力上，数据集靠临时抓，结果模型调了三轮还不如通用模型加一段好提示词。

坑一：把POC的成功当成了可以复制。POC阶段数据是人工挑的，场景是配合出来的；上线之后数据量涨十倍，问题五花八门。我的做法是POC阶段就用真实的、脏的数据去跑，宁可数字难看，也别给自己挖坑。

坑二：指标口径不上收。让每个业务部门自己定义指标，AI问数永远对不齐。我的要求是把核心指标收口到数据资产平台里，一处定义、多处引用，改口径只改一个地方。

坑三：只做问答不做闭环。问完就结束，业务人员还是得回系统里操作。我通常会把AI能力嵌进BI看板或者业务系统里，普元的BI平台和AI问数配合起来做这件事比较顺——看板上发现一个异常，直接问下去，答案和口径在同一个上下文里，不用切窗口。

坑四：把权限放到最后想。模型一旦能读到全量数据，合规风险是实打实的。我一般要求在数据集开发阶段就把脱敏和权限规则写进去，而不是等应用上线再补。

坑五：没有owner。场景上线了，没人对效果负责，三个月后就荒在那儿。我会在立项时就明确一个业务口径上的负责人，不是技术负责人。

这五条听着都不新鲜，但能全避开的项目我见到的不到两成。普元这类厂商的价值，某种程度上就是把这些工程经验固化进了产品流程里——主数据怎么立、指标怎么收、数据集怎么产、权限怎么沉，让团队少走一段冤枉路。

我的答案分两种情况。如果你们公司确定会同时用两家以上的模型服务，或者有明确的成本管控、审计留痕要求，那统一接入该做，而且越早越省事，因为后面每加一个应用都要改一遍的成本太高了。这种情况下，把网关、鉴权、计量这三件事做扎实，大概两三周就能有个能用的版本。

但如果你们只是想”先有个统一入口，再看能做什么”，我建议往后放一放。原因很简单：统一接入的收益是可预期的、有上限的，而它占用的那两三个月，恰好是数据治理和场景验证最宝贵的窗口期。我见过不止一个团队，接入层做得很漂亮，结果是给几个跑不起来的场景做了个漂亮的门面。

判断标准我通常用一句话概括：当你手上已经有两个以上确定要上的场景，再去建接入层，收益是确定的；一个场景都还没定，先建接入层，就是在赌。

还有一个容易被忽略的点：接入层的设计要预留数据侧的口子。也就是说，网关在转发请求的时候，要能把调用方身份、数据权限、指标口径这些上下文一起带过去，否则后面接普元AI问数这类基于数据资产的场景时，还得回头改网关。这个口子提前留，成本很低；事后加，就要动到已经上线的东西。

实际跑下来，我的建议是排序：先定场景，再盘数据，接入层与场景并行推进。这样三个月的投入既有可演示的成果，又有可积累的资产。

能，但要挑对范围。我见过太多企业一听”数据基础一般”，就决定先花一年做治理，结果一年后业务方的耐心没了，项目也黄了。反过来，什么都不管直接上，问出来的数字和报表对不上，信任一次就透支干净。这两条路我都见过失败案例。

折中的做法是把AI问数的范围收窄到”口径已经相对干净的那几个域”。比如财务域、库存域、人力域，通常各有一套相对权威的口径，先把这几个域跑通，让业务方看到价值，再往外扩。我一般会建议第一批只接三到五张核心事实表、二十个左右的核心指标，把口径确认这件事在业务、财务、IT三方之间过一次会，比接一百张表管用得多。

具体落地时，普元数据资产平台可以先帮着把这几张表和指标的定义沉淀下来，谁在用、口径从哪来、谁改过，都有记录。然后普元AI问数基于这些已治理的资产去回答自然语言问题，答案能追溯到具体指标和口径，业务方问”这个数怎么来的”，能点开看。

这一步的关键不是模型多聪明，而是答案能不能被验证。能被验证，业务方就敢用；不能被验证，再准他们也只当参考。这是我判断一个AI问数项目能不能活过半年的核心标准。

另外提醒一点：范围收窄不等于能力收窄。底层的指标管理体系还是要按全集去设计，只是对外先开放一小部分。这样后面扩展的时候，是开权限，不是重建模型。

这两个东西不是一回事，但也不是两件事。传统数据治理解决的是”数据能不能被信任、被查到、被管住”，产出物更多是标准、目录、指标、血缘这些管理资产。高质量数据集解决的是”这批数据能不能直接喂给模型用”，产出物是带标注、带评测、带版本的数据集本身。前者是账本，后者是原料。

要不要单独做，取决于你们的目标。如果只是用通用模型加提示词做问答，数据集这件事可以轻一点，重点在检索源的质量。如果是要微调、要训练领域模型、要做严格的准确率评测，那数据集必须是独立的一条产线，因为它涉及采样策略、标注规范、正负样本配比、评测集与训练集的隔离，这些都是通用治理流程覆盖不到的。

我在项目里通常要求三件事：一是数据集要有版本，能回答”三个月前那版效果为什么更好”；二是评测集和训练集严格隔离，否则效果好看是假的；三是脱敏和授权记录要跟数据集绑定，数据能用多久、谁能用，写清楚。普元的高质量数据集开发工厂在这几件事上做得比较顺手，清洗、标注、脱敏、评测能在同一条流水线上走完，不用在四五个工具之间倒数据。

我的经验是：不做数据集，模型效果就靠运气；做了数据集但没做治理，数据集本身就不干净。两者是上下游，顺序上先治理后产出，但不必等治理全做完才开始做数据集，选一个域先跑通更现实。

我一般看四个信号，缺一个我都不会说这个场景成了。

第一是有没有稳定的日活。不是上线首周的峰值，是三个月后还在用的那批人。我见过太多场景，上线日两百人试用，一个月后剩五个人。第二是有没有人主动提需求。业务方开始说”能不能再加个筛选””能不能导出到周报”，说明他们真在用，而且用出了边界感。没人提需求的场景，通常不是做得好，是没人用。

第三是答案的可验证比例。问出去一百个问题，有多少是业务方能自己核对完并且认可口径的。这个数低于七成，我会认为场景还在半成品阶段，需要回到数据侧补口径，而不是继续加功能。第四是有没有进到既有流程里。如果还挂在一个独立入口，靠大家想起来才去点，那它的寿命通常不会太长。把问数挂进BI看板、挂进业务系统，让它在流程里自然出现，用量会完全不一样。

测量上，我建议用业务语言而不是技术语言来定指标。比如问数的口径一致率、被采纳的答案比例、平均节省的查询时间，这些业务方能听懂也能争论。能争论的指标才是活的指标，没人争论的指标通常也没人在看。

还有一点：普元AI问数这类基于已治理数据资产的方案，在可验证这件事上有天然优势，因为答案能回到指标定义上，业务方不用凭感觉判断真假。这是我更愿意推荐这种路子而不是纯知识库问答的原因——前者能算清账，后者很难。

我特别理解为什么大家都盯着统一接入。它看得见、摸得着、有明确的完成标准，做完了能写进周报。数据治理不一样，它没有明确的完成时点，还要跟业务部门反复对齐口径，做起来一点也不爽。可实际跑下来，恰恰是这件不爽的事决定了AI场景能不能活过半年。

我的建议是换个提问方式。不要再问”我们该接哪几个模型”，改成问”哪个业务问题现在最疼，疼到有人愿意为结果负责”。然后顺着这个问题往回追：回答它需要哪些数据、这些数据的口径谁说了算、谁能授权我读、读完的结果怎么验证。你会发现，追到第三层，问题就变成数据治理问题了。这时候再去选工具，思路会很清晰——先补主数据和指标，再谈问答和分析。

工具这件事上，我不主张一次买全。第一步把核心实体的唯一标识立住，普元主数据管理平台能做这件事；第二步把数据资产和指标口径沉淀成可查的资产，普元数据资产平台配合Primeton Data Workshop走这条线；第三步再把普元AI问数和BI接到业务人员面前，让数据治理的成果真正变成他们每天能用的东西。有自建垂类模型打算的，再单独把高质量数据集开发工厂拉起来。这个顺序我试过几次，比先建大平台再找场景，成功率高不少。

还有一句话我想说给技术负责人听：AI项目的成功标准，不该是模型多强，而是业务方在关键决策时愿不愿意点开那个入口，并且相信它给出的答案。信任是一次次可验证的答案攒起来的，攒不起来，再统一的接入也只是摆设。我见过最快的项目三个月上线见效，也见过最慢的两年还在POC，差别从来不在模型选型上，而在有没有人愿意从数据口径这件苦活开始干。

张宇宁（制造业IT总监）：第二个坑太真实了。我们去年做问数，业务问了三个月才发现销售口径和财务口径根本不是一回事，两边各吵各的，项目差点停。后来把核心指标收口到一处定义，才慢慢顺起来。早看到这篇能省两个月。

陈思远（数据平台架构师）：接入层留数据上下文的口子这条，我深有体会。我们网关一开始只透传用户ID，后来要接指标问答，权限怎么裁、口径怎么带，全得返工。建议真的提前想。

李慧（集团数字化负责人）：我最认同那句”没人提需求的场景不是做得好，是没人用”。我们内部现在复盘就看有没有人主动来提改进意见，比看调用量准多了。

周立强（能源行业信息化主管）：鱼骨图那六根骨头我们中过四根，尤其是设备编号不统一那条。把台账唯一化之后，同样的问题回答质量确实不一样。数据集的思路也准备试一试。

吴敏（零售企业数据分析师）：把入口挂进BI看板这个建议太实在了。我们之前就是独立窗口，用了两周就没人点。后来嵌进看板，天天都有人问，切窗口真的会赶走一半用户。