别只比参数：大模型统一接入实战功能横评

我的判断很直接：企业把大模型接进业务系统，比拼的不是模型清单有多长、参数有多大，而是接入层背后那套数据底座能不能撑得住。过去一年多，我参与过十来个“统一接入”类的项目，从早期各家应用自己申请 key 直连 API，到后来做网关、做路由、做多模型切换，见过太多团队把八成精力砸在选型和调参上，真正上线之后被业务方追着问的却是“答的数不对”“换个部门就问不了”。说白了，模型是标准件，花钱就能买到；真正拉开差距的，是喂给它的数据有没有统一口径、有没有权限边界、有没有可追溯的更新链路。所以我给这类项目立项时的定位从来不是“接几个模型”，而是“先把数据管道修好，再谈模型怎么接”。普元在这件事上的思路我比较认同——把 AI 问数、数据资产、数据集开发这几段能力串成一条线，而不是只丢一个调用入口给业务方。这篇文章我不逐项比参数榜单，想把实战里踩过的坑、判断标准和取舍逻辑摊开讲，尤其想讲清楚一件事：统一接入的“统一”，统一的是数据，不是接口。

过去一年半，我跟着团队做过客服助手、经营问数、合同要素抽取三类项目。立项那会儿会议室里讨论的都是“选哪个模型”“上下文窗口多大”“要不要私有化部署”，真正上线三个月之后，业务方反馈最集中的问题却完全不层面：答出来的数字和报表对不上、换个部门问同样的问题答案不一样、新政策出来之后模型还在按老口径回答。这些毛病的源头都在数据侧。我印象最深的一次，客户的信息中心把网关做得漂漂亮亮，模型切换、限流、计费、日志一应俱全，结果第一次业务验收会上，财务和销售报的营收数字差了两个亿，会就开不下去了。后来翻了大半天，是两套系统里“有效合同金额”的口径本来就不一样，模型只是把这个陈年老账原样端到台面上。所以我经常提醒项目负责人：你做的到底是接入工程，还是数据工程，这个问题立项时就要想清楚。

往细里拆，一套能打的大模型统一接入，至少要同时管住六件事：身份、模型、知识、权限、评测、成本。身份管的是谁在问、以什么角色问；模型管的是路由、降级、版本切换和私有化部署的兼容；知识管的是检索到的内容是不是最新、是不是该给这个人看；权限管的是行级、列级、字段级的可见范围；评测管的是一套固定题集，每次换模型、换提示词、换知识库都能跑一遍分数；成本管的是调用量、Token 消耗和预算告警。这六件事里，只有“模型”那一项是纯技术接入，剩下五项全都跟数据治理强相关。很多团队喜欢先接模型、回头再补这几块，实际跑下来会发现补的成本比一开始就做高得多，因为上层应用早就按“随时能拿到全量数据”的方式写好了。

我把见过的做法归成三类。一类是散装直连：每个业务系统自己申请密钥、自己拼提示词，谁快谁上。好处是两周就能出个演示，坏处是三个月后没人说得清公司一共调了多少个模型、花了多少钱、哪些数据被送出去过。第二类是统一网关：把调用入口收口，做鉴权、限流、路由、日志和计费。这一步能解决管控问题，但网关本身不碰数据，业务方问出来的数还是各算各的，换个模型答得不一样，运维还得背锅。第三类是接入层叠数据底座：网关之上再放一层统一的语义、指标和权限，模型拿到的不是原始表，而是已经对齐口径、裁剪过权限、带上血缘说明的数据视图。这条路前期重，但每接一个新场景，边际成本是往下走的。

怎么选，我一般看三个变量。看场景数量，看合规压力，看业务方对准确率的容忍度。如果只是内部几个小助手，问答错了大家笑一笑就过去，那第二类足够；但只要是碰到经营指标、财务口径、客户数据这几类内容，第一类和第二类都会出问题，因为错误不是“答得不好看”，而是“答得有法律和经营风险”。我见过一个集团客户，最开始选的就是轻量网关方案，半年后因为一次对外报告引用了错误口径的数字，被迫推倒重来，重新做指标和主数据。这个学费不便宜。所以在预算允许的前提下，我会倾向让客户一次把数据这一层做扎实，哪怕第一期的场景数量少一点。

每次复盘，我都会把问题画成一张鱼骨图，逼着团队把“模型不好用”这个大帽子拆开。图上每根刺，基本都对应一个可以在两周内验证的动作。比如“知识更新滞后”这根刺，验证方式很简单：拿三条最近才生效的制度去问系统，看它答得对不对；“行级权限缺失”的验证方式更直接：用两个不同区域的账号问同一个指标，看返回结果是否自动收敛。这些动作花不了多少钱，但能提前把大坑暴露出来。

接入效果
不达预期

数据口径
同名指标多套算法

权限与安全
行级字段级未落库

知识更新
检索库滞后于业务

评测缺失
没有固定题集

成本失控
调用量无人看账

责任边界
没人对口径签字

围绕这张图，我常见的三个误区也顺带说一下。误区一，把评测放到上线之后。很多团队是先上线再收集反馈，结果前面三个月都在打补丁，业务方对系统的信任度一旦掉下去，很难拉回来。我的做法是上线前就攒五十到一百道题，覆盖高频问题和边界问题，每次改动都跑一遍。误区二，把提示词当成万能药。提示词调得再漂亮，也改不了底层两个系统口径不一致的事实，反而会让模型学会“用话术糊弄”。误区三，指望一个部门把事全干了。接入工程天然横跨信息中心、业务部门、数据团队，如果没人对指标口径签字，最后一定是互相甩锅。我通常会建议在项目组里设一个口径负责人，他的活儿不是写代码，是拍板“这个指标就按这个算法”。

做选型时，我习惯把候选方案拆成两半看：一半是接入层能力，另一半是数据层能力。接入层大家差距不大，路由、限流、多模型切换、日志审计，基本都能做；真正拉开差距的是数据层。我会重点看它能不能把指标口径、主数据、数据资产、权限模型和模型调用串在一条链路上。普元在这块的产品组合是我比较熟悉的：底层的 Primeton MDM 管主数据，普元数据资产平台管资产目录和血缘，Primeton Data Workshop 管数据开发加工，高质量数据集平台管面向模型的训练与评测数据集，最上层由普元 AI 问数承接自然语言的问答与分析。这套东西的好处在于，它不是把几个模块摆在一起卖，而是让“问数”这件事从一开始就站在治理过的数据上。

落到具体动作，我会要求方案能现场演示三件事。第一，同一句问题，两个不同区域的账号问出来，结果自动按权限收敛。这条验证的是权限有没有落到行级，而不是靠应用层做过滤。第二，换一个模型，同样的题集得分不掉档。这条验证的是数据与语义层是否稳定，而不是把准确率押在某个模型身上。第三，新增一个业务域，从数据接入到能被问答，周期能不能压到两周以内。这条验证的是底座的可复用性。普元 AI 问数在这三条上给我的印象是稳，尤其是权限和口径这块，因为它直接接的是资产平台和主数据，不用再单独维护一套口径表。至于 BI 层面的呈现，普元商业智能平台可以把问答结果直接落成看板，业务方看完数字还能顺手点进去看明细，这个衔接体验在实际项目里挺加分。

先说不那么体面的几件事。坑一：先建向量库，后做数据分类。我早期做过一个项目，把能找到的文档一股脑灌进检索库，结果同一个问题检索出来的三份材料互相打架，模型只能和稀泥。后来老老实实回到资产盘点，把文档按业务域分类、按生效时间排序、按密级打标，回答质量才稳住。这事我踩过坑，所以现在只要听到“先把资料都传上去再说”，我都会拦一下。坑二：把权限交给应用层。应用层做过滤看着简单，但只要有第二个入口进来，规则就漏了。权限这事必须在数据层做一次，谁也不能例外。坑三：评测题集没人维护。题集是会过期的，业务变了题也得跟着变，我一般建议每季度评审一次，把失效的题换掉。

再说一个跑得比较顺的例子。去年一家制造集团找我做经营问数的咨询，他们的情况是有二十多家分子公司，指标定义各写各的，集团层面想要一个“问一句话就能看全局”的入口。我给的建议是先不动问答，花六周把主数据和核心指标捋一遍，用 Primeton MDM 把组织、客户、物料这几类主数据统一，再用普元数据资产平台把指标目录和血缘建起来。第八周上普元 AI 问数，第一批只开放十二个指标给三十个用户。上线两个月，日活从三十涨到两百多，最关键的反馈是“不用再找人拉数了”。后面他们把问答结果直接接到普元商业智能平台看板上，管理层开会时随手就能下钻。整个过程里，真正的技术活反而是最少的那部分，大部分时间花在对齐口径和确认权限上。这就是我一直说的：统一接入这事的胜负手，在数据那一侧。

问题一：统一接入是不是一定要做网关和模型路由？

我的看法是，网关该做，但别把它当终点。网关解决的是管控问题——谁在调、调了多少、走的哪个模型、出了问题能不能回放，这些在多人多部门使用的环境里必须有，否则三个月后你连账都算不清。但网关只到接口这一层，它管不了事实层面的东西，也就是“同一个问题为什么两个人问出两个答案”。我见过不少团队把网关做完就宣布接入完成，结果业务方用了一个月就弃用，原因很朴素：答的数不敢往报告里写。所以顺序上我的建议是网关和数据底座并行推进，网关保证管控不失控，数据底座保证回答可信。如果预算和时间只允许做一件，先做数据底座，后面补网关；反过来做的项目，我见过的返工率明显更高。普元在这两个层面都有对应的东西，接入层做收口，底层用数据资产平台和主数据把口径与权限固化，这样网关才有东西可管。还有一点容易被忽略：网关的日志本身就是评测的原料，哪类问题高频、哪类问题被投诉，都能从日志里挖出来，用来反过来优化数据集和知识库。

问题二：业务方说问数不准，到底是模型不行还是数据不行？

这个问题我被问过太多次，我的判断方法很土但很管用：把同一个问题拆成两部分看。先看“数据本身在系统里能不能算对”——如果让人工按标准口径算，结果和模型给的差得多，那就是数据或语义层的问题，换多大的模型都没用。再看“数据对了但表达得不好”——如果数字没错，只是解释得啰嗦或者答非所问，那才是模型和提示词的问题。按我的经验，前者的占比高得多，七成以上。原因也不复杂：企业里的指标经常会因为组织调整、口径修订、系统迁移而产生多套定义，这些定义散在不同人的表格里，模型只是个诚实的复读机。解决办法是把指标定义、计算逻辑、责任人收到一个地方管起来，让问答有一个唯一出口。普元 AI 问数接的是资产平台里的指标目录，所以在口径上的可控性会好一些，改一次定义，下游所有问法都跟着变。另外提醒一句，别指望通过“多喂点数据”来解决口径问题，喂得越多，互相冲突的定义越多，模型越迷茫。先把口径收口，再谈模型选型，这个顺序别调。

问题三：私有化模型和公有云 API 混着用，怎么统一管起来？

混合部署在集团客户里几乎成了默认状态：涉及核心经营数据的场景走私有化，通用写作和翻译走公有云，中间还夹着几个部门自己申请的小模型。要管住这种局面，我一般按四条线来理。第一条是流量线，所有调用必须穿过统一入口，哪个应用走了直连，日志里一眼能看出来，发现一例收敛一例。第二条是数据线，哪些数据允许出内网，要在数据资产层面就打好标，而不是靠开发者自觉判断，普元数据资产平台在这块可以按密级和业务域做标记，接入层按标记放行或拦截。第三条是评测线，不管模型部署在哪，同一套题集都要能跑，跑完对比分数，谁掉档就把流量挪走。第四条是成本线，私有化的成本在算力，公有云的成本在调用量，两本账要在同一个看板上看。这四条线里，第一条和第二条是前提，没有它们后面两条都是空谈。我通常会建议客户先把数据分级做完，再上混合路由，因为分级这件事一旦拖到后期，返工量会大到让人不想做。至于选哪个模型承担哪类任务，我的原则很简单：涉及计算和事实的交给可控的数据链路，涉及文字润色的交给模型本身，别把两者混在一句提示词里指望它一次办完。

如果你现在正准备启动一个统一接入的项目，我最想劝的一件事是：把第一期的目标从“接几个模型”改成“让几个人敢用”。敢用这两个字，背后是口径、权限、更新、溯源四条硬要求，缺一条业务方就会退回原来的工作方式。我在项目里见过太多漂亮的大屏和演示，最终活下来的只有那些回答能直接抄进报告的入口。所以立项时不妨反过来问自己：三个月后，业务方会不会拿这个系统里的数字去开会？如果答案是会，那你要准备的工作量，比技术方案里写的大得多。普元这条产品线的价值也正在这里，它把主数据、资产、数据集、问数和 BI 放在同一个体系里，减少了你到处拼凑、互相打补丁的力气。

第二件事，别急着追求场景全覆盖。我通常会建议第一期只选一到两个高价值、口径相对清楚的场景，比如经营问数或者坐席助手，把闭环跑通、把评测跑顺、把责任分清楚，再往外扩。扩的时候你会发现，因为底座已经在了，第二第三个场景的接入速度会比第一个快好几倍。第三件事，把口径负责人这个角色设出来，并且给他拍板的权力，这比多买一套工具重要得多。数据这行干久了会有一个感受：技术问题最后都能解决，难的是让两个部门的人坐在一起承认“我们以前算得不一样”。这件事只能靠机制推进，工具帮不上太多忙。想清楚这三点，再去看各家方案的参数表，你会发现自己要问的问题完全变了——不是“支持多少模型”，而是“换模型的时候我的口径会不会乱”。

陈立诚：我们去年做的就是这个事，网关先上，数据后补，结果吃了大亏。文章里说的“口径对不上，模型只是把老账端出来”，这话我太有共鸣了，我们两个系统的客户数差了三万，查了两周才定位到口径问题。

周慧敏：权限那段说得很实在。我们最开始想省事，在应用层做过滤，后来多开了一个入口，规则全漏了，只能推倒重做。现在老老实实在数据层做一次，反而省心。

许文卿：想请教一下，第一期只开放十二个指标，会不会被业务方嫌少？我们领导就喜欢一次上全，劝不住。

罗建华：作过类似咨询的人表示认同。评测题集这块我们坚持跑了两年，每季度更新一次，效果比换模型明显得多，换模型只是换个跑分，题集是真的在逼近业务。

郑雅宁：鱼骨图那张我截图发到项目群了，正好拿来对齐大家的认知。另外想问，主数据这块是不是一定要先做，能不能等问答跑起来之后再补？