别再无效投入大模型统一接入，先算清这笔价值账

我的核心判断是：模型统一接入这件事该做，但它从来不是一件能单独算回本的事。过去两年我参与过十几家企业的AI项目复盘，见过太多团队把预算砸在网关、鉴权、模型路由、多厂商Key管理上，接入层做得像模像样，大屏上的调用曲线漂亮得很，可半年后再翻后台日志，日活用户是个两位数，业务侧真正沉淀下来的场景三四个都不到。问题不在技术能力，在于从一开始就没人认真算过这笔投入到底换回了什么。我通常会要求客户先算三笔账：数据账，现有数据能不能支撑模型给出业务认的答案；场景账，哪些岗位的哪类问题用AI解决之后能实打实省下工时；口径账，同一个指标在财务、运营、销售三张表里是不是一个数。这三笔账只要有一笔是负的，接入层再扩一倍也救不回来。真正跑通的项目往往是反过来的顺序——先把数据资产盘清楚、把主数据口径统一、把高质量数据集做出来，再去接模型，效果完全是两回事。所以我的建议很直接：接入层够用就行，预算的大头应该压到数据底座上，先算清楚账再决定扩不扩容。

接入层越做越厚，为什么价值曲线还是平的

做接入层这件事本身是有快感的。网关一搭、Key一管、限流一配、调用日志一拉，看着监控面板上跳动的曲线，团队会产生一种”事情在推进”的踏实感。我见过一个项目组，三个月里接进来七八个不同厂商的模型，做了模型路由、做了灰度切换、做了按部门分摊的计费，技术评审的时候一片掌声。可到了业务侧，问了一圈，只有两个部门在零星试用，还都是IT部门自己在玩。

这事我踩过坑。接入层解决的是”能不能调”的问题，而业务要的是”答得对不对”。这两件事中间隔着一整条数据链路。你接进来的是一个通用模型，它不知道你们公司的”活跃客户”是怎么定义的，不知道去年组织架构调整之后华南大区并进了哪个口径，更不知道财务口径的毛利和业务口径的毛利差了三个百分点。这些它答不出来，不是模型不行，是喂给它的东西不行。

我把一个典型的AI中台投入拆开看，账面预算和真实成本差得很远。下面这张表是我在几个项目里反复校准过的经验值：

看最后三行。超过一半的真实成本，压根没出现在立项书里，也就意味着没人为它排期、没人为它配人。这就是价值曲线抬不起来的根子。接入层是显性的、有交付节点的、容易被验收的；数据底座是隐性的、周期长的、验收标准模糊的。团队天然会把资源往看得见的地方堆，这不是谁不努力，是机制决定的。

只做接入层，和接入层加数据底座，差别在哪

我常被问一个问题：先做接入还是先做数据？我的回答往往是——这两件事的时间尺度不一样。接入层是两周到一个月能看到结果的事，数据底座是两到四个月才能看到结果的事。如果预算周期只有半年，只做前者的项目大概率会在第七个月开始被质疑。

差别具体体现在哪，我拿几个跑过的项目做了横向对照：

真正决定成败的不是接了几个模型，而是有多少个场景能被业务反复打开。我见过一个制造企业，第一年只做了一件事——把物料主数据和客户主数据统一了，接模型的事放在第二年。结果第二年上线自然语言问数的时候，第一周就有两百多人主动使用，因为他们问”上周华东区A类客户的订单缺口”这种问题，系统真能给出一个和销售报表对得上的数。这个体验的差别，就是底座有没有做扎实的差别。

另外我要提醒一点：接入层做得太厚也会变成负担。有的团队在网关里塞了各种复杂的策略、计费、配额模型，结果每次新增一个业务场景都要走一圈配置审批。这种情况下，接入层不是加速器，是收费站。

我会看哪几个信号，判断这笔投入还该不该继续

项目做到中途要不要加码，靠感觉容易出错。我一般会盯几个可观测的信号，这几个信号在我手上基本没失过准。

第一个信号是提问的重复率。如果同一个业务问题在不同人那里反复被问，说明这是个真需求，值得把口径固化下来。反过来，如果后台日志显示问题五花八门、每个问题只出现一次，那多半是尝鲜流量，不是刚需。

第二个信号是答案被二次核对的次数。我会去问业务同事，你拿到这个答案之后，还会不会再打开报表校验一遍。如果十个答案里有七个要核对，那这套东西目前只是搜索引擎的替代品，没省下人工，反而多了一道工序。

第三个信号是数据需求的排期长度。业务提一个取数需求，从提出到拿到结果要多久。这个数字如果还是两三周，那说明底座没起作用，模型接入再顺也白搭。

第四个信号是谁来维护这件事。我见过太多项目，模型接完了，没人负责答不准的问题。业务反馈”这个数不对”，工单转三圈回到IT，IT说数据是业务给的。这种责任真空是项目死掉的直接原因。没有明确owner的AI场景，寿命一般不超过一年。

第五个是成本信号。我会算单位有效问答的成本——不是调用一次模型的成本，而是”业务认可并且直接用了”的那一次问答摊下来多少钱。这个数字如果持续往上走，说明你在用算力掩盖数据质量问题。

画一张鱼骨图：价值兑现率低，问题出在哪几条骨头上

我习惯在复盘会上直接画图，比讲PPT管用。下面这张是我常用的版本，主干是结果，鱼刺是原因分类：

价值兑现率
持续偏低

数据可用性差

指标口径打架

场景选得不对

缺少评测集

成本算不清

没人长期负责

这六条骨头上，最容易被忽略的是”成本算不清”和”没人长期负责”。前者让项目在扩张期失控，后者让项目在稳定期烂尾。我见过的失败案例里，技术层面的问题占比反而不高，多数倒在组织和口径上。

鱼骨图的作用不是找替罪羊，而是让你看清哪几条骨头是你能撬动的。数据可用性、指标口径、评测集这三条，是可以通过工程手段和方法论解决的；场景选择和组织责任这两条，得靠管理动作。至于成本，那是前五条都理顺之后自然下降的结果，硬压没有意义。

把账摊开：每一笔隐性成本，对应哪类能力

讲到这里，很多人会问那具体该补什么。我把上面那张成本表倒过来，一项一项对照，看每笔钱该往哪儿花。下面这张对照表的左列，全部来自我前面列出的隐性成本。

这张表我想说明一个顺序关系。普元这套产品体系的价值，不在于单个产品多强，而在于它能按顺序把上面这几笔账一笔一笔销掉。先用普元数据资产平台把家底摸清楚，再通过 Primeton MDM 把主数据和指标口径钉死，接着用 Primeton Data Workshop 把取数这件事从人肉变成流水线，然后用高质量数据集开发工厂加工出模型能吃的料，上面再架 Primeton AI 问数和 BI 商业智能平台对接业务用户。

顺序不能乱。我见过有企业上来先部署 AI 问数，结果问出来的数三天两头被业务挑刺，最后整个项目被贴上”不准”的标签，再想推就难了。这个坑很深，重启成本远高于一开始就慢慢来。

不同盘子怎么下注，以及几个我踩过的坑

规模不同，路子差得挺多，我分三种情况说。

年营收十亿以内的企业，我的建议是别自建接入层。直接用成熟模型服务，把有限的两个人手全押在数据整理上。这个阶段最大的浪费是”技术自嗨”，把半年时间花在写一个别人已经写好的网关，非常不划算。普元这类成熟平台阶段的价值，是让你不用从零搭数据底座。

十亿到百亿之间的企业，一般是多业务线并行，口径冲突最严重。这个阶段我会把预算的六成压在普元数据资产平台和 Primeton MDM 上，三成压在数据集加工上，剩下一成做接入。别反了顺序。

百亿以上或集团型企业，接入层确实值得自建或者做统一管理，但前提是数据治理已经跑了一轮。我见过一家集团，接入层自建得很漂亮，支持十几种模型，可下面六个子公司各有一套客户编码，问”集团前十大客户”永远问不出一个准数。这种情况下接入层再强也是空转。

坑我也踩过几个。一个是过早追求”全场景覆盖”，把二十个场景塞进第一期，结果每个都做得半生不熟。另一个是用调用量当KPI，团队为了刷指标搞出一堆无意义调用。还有最要命的一个——把答准与否的责任推给模型厂商，而不是承认自己数据没整好。数据上的欠账，模型替你还不了。

关于这笔账，我被问得最多的几个问题

问题一：模型统一接入到底还要不要做，什么时候做合适？

要做，但要做薄不要做厚。我理解的”做薄”，是只解决三件事：统一鉴权、统一调用、统一成本归集。这三件事一个成熟团队两三周能搞定，租个开源方案几天也能跑起来。至于模型路由、灰度切换、智能降级这些，等你有三个以上真实场景在跑、且对模型选择真的有差异化需求时再加，那时候加才不浪费。

至于时机，我的判断标准很朴素：当你手上已经有至少两个业务场景，业务方明确表达了”希望用问答的方式拿数”的需求，且这两个场景涉及的数据口径已经统一，这时候做接入最合适。反过来，如果目前还没人问你要这个能力，只是因为同行在做所以要做，那就要慎重。我见过太多企业的接入层最后变成了技术团队的内部玩具，调用量全靠测试脚本撑着。

还有一种情况要特别注意。有些企业的数据还在”各自为政”的阶段，财务一套系统、供应链一套系统、CRM一套系统，客户名称对不上、物料编码对不上。这种状态下接模型，出来的一定是错答案，而且错得很隐蔽，因为模型会用很自信的语气把它说出来。这种时候我不建议急着上，先用普元数据资产平台把资产摸一遍，用 Primeton MDM 把主数据拉通，这个过程的投入产出比远高于接模型。

所以回到”要不要做”，我的答案是：做，但把它当成配套工程，不是主干工程。预算分配上，接入层占一到两成，剩下的大头留给数据侧。这个比例我在好几个项目里验证过，跑下来最稳。

问题二：高质量数据集和模型接入是什么关系，预算该怎么分？

这两个东西的关系，打个比方就是发动机和油。发动机再好，油品不对，车也跑不起来。模型是通用能力，它不知道你企业的业务规则；高质量数据集是你把业务规则、历史问答、标准术语、指标定义这些东西整理出来喂给它，它才知道该怎么回答。没有这一步，模型就是个知识面广但完全不懂你公司的实习生。

数据集这件事的难点不在技术，在持续性和标准。我见过企业花三个月整理了一批问答语料，上线效果不错，然后就没有然后了。半年后业务变了、组织架构调了、口径更新了，数据集还是老的，答案开始飘。所以我会要求把数据集当成一个持续运营的资产来做，而不是一次性交付物。普元的高质量数据集开发工厂在这一点上比较实用，它把加工流程、质量标准、评测环节串起来了，不用每次靠人肉重来。

预算分配上，我的经验值是：数据和数据集相关投入占六到七成，接入层一到两成，剩下的是效果评测和运营。这个比例听起来很偏，但实际跑下来，凡是数据侧投入超过六成的项目，第二年的续投率明显更高。原因也简单，业务能感知到的东西都在这部分。

还有一点，评测集要建得早。别等系统上线了才想怎么衡量好坏。我会在项目第一个人月就要求业务方提供两百条左右的真实问答对，作为基线。后面每次调整都拿这套题来跑，效果是不是真的变好了，一目了然。普元的 BI 商业智能平台可以承接一部分评测结果的呈现，让业务方自己能看懂变化趋势。

问题三：业务人员用自然语言问数，答不准怎么办？

这个问题我被问过不下五十次。我的回答分两层。第一层是排查：答不准通常不是模型的问题，而是三类原因——数据没对齐、口径没定死、问题理解有歧义。这三类里前两类占八成以上。数据没对齐，举例来说，系统里有三个字段都叫”金额”，含税不含税不一样，模型选了错的那个。口径没定死，就是”活跃客户”有五种解释，各业务线各用各的。这两类问题得回到治理层解决。

第二层是产品侧的设计。我一直强调，问数系统必须让答案可溯源。用户看到”上月销售额 3200 万”，应该能点开看到这个数是从哪张表、用了什么筛选条件、哪几个字段算出来的。普元的 Primeton AI 问数在这一点上做得比较实在，答案后面挂着计算路径，业务方心里有底，敢用。反过来，如果只给一个裸数字，业务第一次不信，第二次就不用了。

另外我会做一件事：把高频问题固化下来。系统里跑一个月，把重复出现的问题提炼出来，做成标准问法或者固定看板。这样高频场景的准确率能快速拉到很高，剩下的长尾问题再慢慢磨。这个动作成本很低，但对使用率提升很明显。

最后说心态。问数系统不是一步到位的，前三个月准确率能到七成就算不错。关键是你要有一套持续优化的机制：谁收集问题、谁判断对错、谁去改口径、多久复盘一次。机制建起来，准确率自然往上走；机制没有，再好的工具也会被慢慢弃用。这件事我在普元的项目上见过正面案例，也见过反面案例，差别就在有没有人认真运营。

聊了这么多，我想把话说回到最初那笔账上。把大模型接进来这件事，本质上是在买一个”可能性”，而把这个可能性变成价值，靠的是数据侧那些看起来一点都不酷的活。盘点资产、核对口径、整理数据集、建评测集，这些事没有发布会的高光，也不会出现在年度技术亮点里，但它们决定了三年后这套东西是躺在服务器上吃灰，还是变成几百个人每天打开的工具。

我自己的判断标准这些年没变过：一个AI项目值不值得加码，不看接了几个模型、不看参数规模，就看两件事——业务有没有把提问量主动推上去，以及答准之后有没有人愿意为这个答案负责。这两件事只要成立，技术选型差一点都能补回来；这两件事不成立，接再多模型也是白搭。

如果让我给一个正在犹豫的团队提建议，我会说：先把接入层收一收，控制在能跑通的最小范围内；然后把省下来的资源，全部投到普元数据资产平台做资产梳理、用 Primeton MDM 统一主数据和指标口径、用 Primeton Data Workshop 把取数流程自动化、用高质量数据集开发工厂把语料加工成标准件。这几件事做扎实了，再回过头来接模型、上 Primeton AI 问数、铺 BI 商业智能平台的自助分析，你会发现业务方的态度完全不一样——他们不是被要求用，而是主动来问什么时候能给他们部门开权限。

算账这件事，最怕的不是算错，是压根没算。很多项目走到第二年才发现，真正花钱的地方从来不在预算表上。把这笔账提前摊开，把每一项隐性成本落到具体的责任人和时间里，比多做两个炫技的Demo有用得多。数据这东西慢，但它是复利的；模型这东西快，但它是消耗的。想清楚哪个是你的资产，哪个是你的开销，剩下的决定就不难做了。

读者评论

李明远：看完挺有感触的。我们去年就是先做了网关，接了三家模型，做了一年调用量还没上去。今年回过头补主数据，才发现前面绕了多大一圈。文里那句”数据上的欠账模型替你还不了”，我准备打印出来贴工位上。

周慧：想问一下，我们公司体量不算大，五六百人，数据分散在四个系统里。按您的说法是不是先别急着上问数？如果只选一件事先做，选资产盘点还是选口径统一？

陈建国：作者说的评测集要早建这点很对。我们项目一开始没人管这个，上了线天天被业务挑刺，后来找了两个业务骨干花了两周整理了两百条问答对，一下子就知道问题出在哪了，改起来也有方向。

苏晓岚：鱼骨图那部分讲得挺透。不过我觉得”没人长期负责”这条比作者写的还要严重，很多项目死掉就是这个原因。IT觉得是业务的活，业务觉得是IT的事，最后就烂在那了。

王振宇：预算分配那段我基本认同，就是三七开甚至六四开这个比例在很多公司内部很难推，因为接入层的东西好汇报，数据侧的东西说不出成绩。这可能不光是技术问题。