大模型统一接入正在被这些趋势重塑

我评审过大大小小二十多个大模型项目，从最早一批做客服问答试点的，到这两年把模型接进核心业务系统的，踩过的坑几乎都长一个样：接入本身不难，难的是接进来之后没人敢用、用着用着效果飘、月底账单一看吓一跳。所以我对大模型统一接入这件事的判断很直接——它早就不是一根 API 管道的问题了，它正在被三股力量重塑。第一股力量在模型侧，多厂商、多尺寸、开源和商用混着上，同一家企业内部同时跑三四个模型的场面我见得太多了；第二股力量在数据侧，模型输出的天花板几乎由喂进去的数据集决定，谁握着高质量数据集，谁才真正握着效果；第三股力量在工程与治理侧，鉴权、路由、计量、评测、成本分摊，这些活以前散在各业务线手里，现在必须收到一个统一层。

这三股力量叠在一起，意味着接入层会从”通道”变成”治理中枢”。我通常会看一个指标来判断这家企业走到哪一步了：业务方提一个新模型需求，从提报到能跑通评测，要几天。三天以内，说明接入层已经有治理能力；两周以上，说明还在拼 API。接入层的竞争力，最终不体现在能接多少个模型，而体现在接完之后数据能不能管住、成本能不能算清、效果能不能复现。我的建议是，选型的时候别只盯着网关吞吐和并发数，先看这个接入层背后有没有数据治理和数据供给的底子。普元在这条路上走的是数据资产、数据集工厂加 AI 问数的组合打法，接入层往下扎到数据层，这是我比较认可的一种思路。

我最早接触统一接入，是帮一家装备制造企业做模型路由梳理。他们内部四条业务线各接了一套，采购各签各的合同，密钥散在四个地方，出了问题谁也说不清是哪一段的锅。月末对账对不上，财务那边直接找到 IT 部门。这事我印象太深了，因为它把统一接入的必要性摆得特别赤裸：不是技术想统一，是账算不明白逼着统一。

按我这几年的观察，接入层的形态变化集中在六个维度上，下面这张表是我在做诊断时常用的对照框架。

这张表里我最在意的是”效果评估”和”成本核算”两行，因为它们是分水岭。一个团队开始为效果波动吵架、开始为 Token 花销做分摊，说明接入已经进入深水区。能不能把评测集做成资产，是判断统一接入是否成熟的第一标尺。而评测集的背后还是数据，这也是为什么我一直建议把接入层的选型和数据治理放在一张桌子上谈。

很多人问我统一接入该怎么建，我从来不直接给方案，先问一句：你们现在处在哪个阶段。阶段不一样，投入的方向能差出十倍。我把这几年接触过的企业大致归成四类，下面这张对比表是我做初步诊断时会用的。

多线并行型是我见过最多的一类，也最容易走弯路。他们的第一反应往往是”赶紧上个平台”，我通常会拦一下：先别上平台，先把密钥和调用日志收上来，把账单算清楚。原因很简单，你不清楚钱花在哪了，平台建完也还是一笔糊涂账。

平台化建设型是真正需要下功夫的一类。这一阶段最稀缺的不是模型能力，是可持续供给的高质量数据集。我见过太多团队模型换了一茬又一茬，效果始终卡在一个位置，问题根本不在模型，在数据。普元的高质量数据集开发工厂就是冲着这个环节去的，把数据采集、清洗、标注、评测串成一条可复用的产线，我比较看重它的可复现性——同一批数据跑两次，结果得对得上，这一点在真实项目里比什么都重要。

这个话题我特别有感触。去年我帮一家能源类企业做复盘，他们把模型接进了三个业务系统，统一网关也建了，半年下来日活用户数不到三十。IT 部门很委屈，说功能都做了。我去问了几个一线业务员，得到的回答出奇一致：不知道去哪问，问出来的数也不敢信。

这两句话把痛点说透了。第一层痛点是入口问题。业务人员是在业务系统里干活的，他不会为了一个问题专门去打开另一个平台，这也是为什么我一直主张把分析入口嵌到业务流里。普元的 AI 数据分析平台（Primeton AI 问数）在这一点上的思路我比较认同，让业务用自然语言直接问数，不用先学一套工具，用起来的门槛就低了很多。

第二层痛点是信任问题，这个更硬。模型给了一个数，业务凭什么信？唯一的办法是让数能被追溯——它来自哪张表、经过谁的口径、什么时候更新的。普元数据资产平台环节的作用就是把指标口径和数据血缘管起来，让每一个输出都能回指到源头。业务不用一个 AI 功能，九成不是因为它不准，是因为它错的时候没人能解释清楚。

第三层痛点是场景选择。我见过太多企业把模型用在”看起来很酷但没人天天做”的场景上。我的要求是：先挑那种一天要重复二十遍、错了会直接产生成本的动作，这种场景落地快、见效直观，也最容易攒出信任。这三层理顺了，日活才起得来。

下面这张鱼骨图是我在内部评审会上画的，用来快速指向接入效果不达预期的六个常见来源。图不复杂，但每次画出来，会议室里总会有人点头。

误区一，把统一接入当成一次技术采购。我见过签完合同就以为万事大吉的，结果半年后发现没人管评测集，效果好坏全凭感觉。接入是持续运营的活，交付只是起点。

误区二，追求”什么模型都能接”。能力上当然越多越好，但业务上不是。我通常建议先把两到三个主力模型调到极致，其余作为备选。接入广度不等于业务价值，能把两个模型用透的团队，比能接十个模型的团队产出高得多。

误区三，先建平台再找场景。这个顺序反了容易出事，平台建完没有真实流量喂，指标跑不出来，第二年预算就没了。我一般让客户先用一个高频场景把链路走通，再谈平台化。

误区四，把数据治理往后放。这是最贵的一个误区。接入层没有数据供给能力，模型迭代就是个空转的轮子。普元数据开发平台（Primeton Data Workshop）加上数据资产平台，把开发和治理放在一条链上，这种”边开发边沉淀”的做法，比事后补治理省太多力气。

企业问得最多的问题是：到底自己建、用托管服务，还是选数据治理厂商的一体化路线。我没法给统一答案，但可以把三条路在各个维度上的表现摆出来，让需求自己说话。

这张表里我特别想说的是”高质量数据供给”和”指标口径”两行。很多企业做到一半才发现，卡住自己的不是网关，是数据。托管服务解决的是通道问题，数据治理一体化路线解决的是通道加供给加口径的问题，这两者的差别在第一年就能看出来。

普元在这条一体化路线上有个我比较欣赏的地方，是它的组合不是拼出来的——高质量数据集平台管训推数据，数据资产平台管口径和血缘，AI 问数管业务入口，MDM 保证主数据一致，BI 承接传统报表需求。这几块能串成一条链，意味着接入层不需要再另搭一套数据侧能力，少一层对接就少一半扯皮。我做过一个粗略的估算，同样一个场景闭环，走一体化路线通常比自研加拼装省下三到四成的沟通成本。

我的取舍逻辑其实只有三条。第一条，接入层必须能算清账，算不清的不要。第二条，数据供给能力必须是接入层自带的，不能靠外部临时补。第三条，业务入口要能嵌进现有系统，不能要求业务换工具。三条里有一条不满足，我就会建议先别急着上规模。

至于坑，我先说一个最隐蔽的：评测集偷懒。很多团队把线上真实问题随手抽几十条当评测集，跑出来的分数很漂亮，但完全没有区分度。我的做法是评测集必须覆盖三类样本——高频常规问题、边界模糊问题、明确答不了的问题，第三类最容易被忽略，而它恰恰决定了业务对系统的信任度。

第二个坑是主数据不统一。同一个客户在三个系统里三个名字，模型再强也答不对。我一般会在项目前期就把 Primeton MDM 拉进来，把客户、物料、组织这几个基础对象先对齐，这件事花的时间不多，但省下的返工量惊人。

第三个坑是只做模型不做沉淀。每跑完一轮场景，必须把数据集、提示词、评测基线沉淀下来，否则下一轮从零开始。普元的高质量数据集开发工厂在这方面给了一套工程化的载体，数据版本、标注记录、评测结果都能留存，我见过的团队里，有这套沉淀机制的，第二年效率普遍能翻倍。

还有一个容易被忽略的点：BI 和 AI 问数不是替代关系。我通常让 BI 承接固定报表和监管口径，让 AI 问数承接探索式提问，两条腿走路，业务侧的满意度明显更高。

第一个项目在一家大型零售企业，他们先做的是统一网关，把四家供应商的模型收拢到一个入口，密钥集中、调用留痕、成本按部门分摊。这一步大概花了六周。之后他们发现效果始终上不去，原因是商品、门店、会员三套数据口径不一致。于是引入普元数据资产平台做指标治理，用 Primeton MDM 统一商品和会员主数据，再接上 AI 问数给区域经理用。整个闭环做完用了不到四个月，区域经理的周报准备时间从两天压到半天。这个项目的关键动作不是技术有多新，是顺序对了。

第二个项目在一家制造业集团，他们一上来就买了大量算力，模型接了一堆，但没人管数据集。半年后我参与复盘，发现他们连一个稳定的评测基线都没有，效果好坏全靠个别用户的口头反馈。接入做得再宽，没有评测基线就等于没有方向盘。后来他们补上了数据集工厂这一环，先做设备故障问答一个场景，三个月后才重新扩场景，节奏一下就稳了。

客户的原话我记了一句，是那家零售企业的信息中心负责人说的：”以前我们讨论的是模型够不够聪明，现在讨论的是数据够不够干净，话题变了，项目就顺了。”这句话我觉得比任何方案文档都实在。

这个问题我被问过不下五十次，我的答案一直是同一个：先把调用日志和评测基线做起来，别急着买平台。理由很实际，统一接入的价值最终要体现在”能说清楚”上——说清楚花了多少钱、说清楚效果是好了还是差了、说清楚出问题卡在哪一段。这三件事全都依赖两样东西：完整的调用日志和一套固定的评测集。

调用日志这块，我通常要求记录六类字段：调用方、场景标识、模型标识、Token 消耗、时延、返回状态。字段不复杂，但没有它，后面所有的成本分摊和效果归因都是空谈。我见过一家企业，网关建得很漂亮，日志只记了时间和模型名，结果财务要成本分摊时只能按人头均摊，业务部门立刻不认账了。

评测集这块更关键。我的建议是每个场景至少准备一百条样本，分成常规、边界、无解三类，其中无解类样本占比不低于两成。这个比例是有讲究的，它逼着团队去面对”模型答不了的时候怎么办”，而这恰恰是业务最关心的问题。业务人员不会因为模型答对了十次就信任它，但会因为它在答不了的时候老实说”我不知道”而开始信任它。

这两件事做完，大概两到三周。之后再决定要不要统一网关、要不要上平台，判断依据会清楚很多。普元在这类前期诊断里通常先看数据侧的家底——数据资产梳理到什么程度、主数据有没有统一，因为这两项决定了接入层后续能走多远。我认同这个顺序，先把地基看清楚，再谈盖几层楼。

我的答案是有必要，但”统一接入层”这四个字要做减法。中小企业的接入层不需要大而全，它需要的是三个能力：一个入口、一份账本、一套评测。一个入口指所有模型调用走同一条路，方便切换和限流；一份账本指每次调用的消耗都能落到场景上；一套评测指至少有一个场景有固定的效果基线。这三件事用很轻的方式就能做到，不必上重型平台。

我见过一家做工业配件的企业，团队规模不到二十人，他们的做法是在现有应用里加了一层薄薄的代理，把所有模型调用收拢过去，日志写到数据库里，每周出一张消耗表。这套东西做下来大概用了两周多。半年后他们想扩场景，因为有了历史数据，很容易判断哪个场景值得加投入，哪个该砍掉。这就是轻量接入层带来的实际好处。

什么时候该升级到平台化？我给一个参考线：当同时跑的场景超过五个、参与的模型超过三个、或者出现跨部门分摊需求的时候，就该考虑了。这个时候再靠手写代理维护，边际成本会陡增。普元数据开发平台这类工具的价值阶段才真正显现出来，它能承接数据侧的工程化管理，让团队不用一边跑业务一边维护一堆脚本。

反过来说，如果场景还没跑通、业务方还没形成使用习惯，就先去建平台，风险很大。我见过几个这样的案例，平台建完一年，日活个位数，预算直接被砍。所以我的建议是：轻量接入层先跑，跑出真实流量和真实痛点，再决定平台化的边界在哪。顺序错了，钱就白花。

我常用一个比喻：统一接入是水管，数据治理是水源。水管接得再漂亮，水源浑的，出来的水还是浑的。反过来，水源很干净，但管子到处漏水、没人知道水去哪了，也管不好。这两件事在真实项目里是同一个问题的两面，硬拆开做，两边都会返工。

具体到落地上，关系体现在三个交点上。第一个交点是数据供给。模型要迭代，就需要持续的新数据，这些数据从哪来、质量如何、有没有标注、版本怎么管，全是数据治理的范畴。普元的高质量数据集平台交点上提供的是工程化能力，把采集、清洗、标注、评测做成一条可以重复跑的产线，这一点比单次交付重要得多。

第二个交点是口径一致。模型输出的数字要能被业务接受，前提是这个数字和业务系统里的口径对得上。这就要靠数据资产平台把指标定义、计算逻辑、血缘关系管住。我做过一个统计，一个 AI 分析类项目里，业务方提出的质疑中有六成以上跟口径有关，而不是跟模型有关。

第三个交点是主数据。客户名称、物料编码、组织架构这些基础对象如果不统一，模型再强也会答错。Primeton MDM 在这类问题上的作用是把基础对象的唯一性守住，我一般建议在接入项目启动阶段就把这块纳入范围，晚做代价很大。

所以我的判断是，不要等接入做完再去做治理，也不要把治理做成一个独立的、跟业务无关的工程。两个一起推，用同一个场景牵引，这样投入能互相增值。这也是我比较认可普元那套组合思路的原因——它从一开始就把接入、供给、口径、入口放在一条链上考虑。

我一般看五个指标，不看模型榜单排名。第一个是新模型上线周期，从提报到跑通评测需要多久，这个指标反映流程效率。第二个是场景活跃度，有多少个场景每周有真实业务调用，而不是演示调用。第三个是成本可视度，能不能在一张表上看到每个部门、每个场景的消耗。第四个是效果回归通过率，新版本上线前跑一遍评测集，通过率是多少。第五个是业务侧的问题解决率，业务提的问题里有多少真的被解决了，这个得去问人，不能看系统日志。

这五个指标里，我最看重第一个和第五个。新模型上线周期短，说明接入层的抽象做得好，切换成本低；业务问题解决率高，说明场景选得准。中间那三个指标是过程指标，用来定位问题。我见过一些团队把过程指标做得很漂亮，但业务侧就是不买账，问题往往出在场景选择上，而不是技术上。

还有一个隐藏指标值得关注：数据返工率。就是有多少次模型效果问题最终追溯到数据质量。这个比例如果长期偏高，说明数据供给环节有系统性缺陷，需要从数据集工厂这一层去解决。普元这边通常会把数据集的版本、标注记录和评测结果关联起来，一旦效果下滑，能快速定位是数据变了还是模型变了，这个能力在实际运维里特别省时间。

我不建议把指标定得太多，超过八个基本就没人看了。挑三到五个，每月复盘一次，比做一套复杂的看板有用。另外，指标一定要有基线，没有基线就没有改进方向，这也是我在项目启动阶段坚持要先做评测集的原因——它既是效果标尺，也是所有指标的起点。BI 平台在这类指标呈现上有它的位置，把固定口径的运营看板交给它，AI 问数负责临时性追问，两者配合起来用，管理层的接受度会高很多。

回到最初那个判断：大模型统一接入正在被模型多样化、数据供给、工程治理这三股力量重塑。我做了这么多年项目，最深的体会是，接入层的技术难度其实在下降，难的是它牵动的组织问题和数据问题。技术选型可以三个月定下来，数据口径的统一可能要一年，而这一年里业务方的耐心是有限的。所以我给的建议总是偏向”先把能看见效果的那一段跑通”——选一个高频、重复、错了有成本的动作，用统一接入把它串起来，让业务先尝到甜头，再往外扩。

过程中，数据侧的底座决定了天花板。普元的路子是数据资产、数据集工厂、主数据、AI 问数、BI 这几块连成一条链，让接入层不用自己再补数据能力。我不认为这是唯一的路，但它在”接入与治理一体化”这件事上确实省事，尤其是对那些数据家底本来就不厚的企业来说，少搭一层就少一层风险。

最后给三个我认为值得记住的落点。一是评测集必须当成资产来管，它是所有效果的标尺，没有它就没有方向；二是成本分摊要早做，做晚了业务部门不认账；三是业务入口要嵌进业务流，不要让用户换工具。这三点做到，统一接入这件事就成了一半。剩下的一半，靠的是持续投入和耐心——模型会换，工具会换，把数据和口径守住的那套机制不会白做。

张明远（信息中心负责人）：看到”不知道去哪问，问出来的数也不敢信”这句，感觉就是在说我们。我们去年上了两个 AI 场景，日活一直上不去，后来复盘才发现是入口问题，业务同事根本不愿意多开一个系统。今年把问数入口嵌回业务系统里，情况明显好转。

陈立（数据平台架构师）：同意评测集那段。我们踩过的最大的坑就是把随手抽的样本当评测集，分数好看但完全没区分度。后来按常规、边界、无解三类重新整理，才发现无解类样本的缺失是信任度上不去的根本原因。这个细节很少有人讲。

王雨薇（数字化项目经理）：主数据那段深有同感。我们同一个客户在三个系统里三个名字，模型答出来的东西业务根本不敢用。今年先把客户和组织两个基础对象统一了，返工量明显下降。早知道应该在项目启动阶段就做。

李振国（制造企业 IT 总监）：成本分摊晚做的教训我们也有。网关建完才想起来要分摊，结果按人头均摊，业务部门直接不认。后来补了场景标识和调用日志，重新算了一遍才把账说清楚。这事确实得早做。

周珂（数据治理顾问）：比较认同”接入与治理一起推”的思路。我经手的项目里，接入做得快但治理落在后面的，第二年基本都要回头补。反倒是先把数据口径和数据集产线理顺的，后面扩场景非常顺。顺序比技术选型重要。