大模型统一接入项目失败复盘：5个致命原因

我经手过七八个把大模型接进企业系统的项目，跑起来的有，上线三个月被业务悄悄弃用的也有。把这类项目做死的原因里，模型能力排不进前三，排在最前面的是数据口径、场景选择和责任归属。每次复盘翻需求单和调用日志，看到的问题高度重复：接口全通了、模型也换了，问答还是不准；演示环节掌声一片，真上线没人打开；IT 说模型不行，业务说数据不对，两边谁也说服不了谁。

我理解的”统一接入”，是把各家模型能力收敛到一个入口，业务系统、报表、知识库、客服都走同一条通道，权限、成本、日志、评测也收在一处。这一层的技术门槛真不算高，一个网关加几组适配器，两三周就能跑通。难的是网关后面那一段：模型拿到的是不是同一份口径的数据，回答能不能被业务认账，出了问题能不能追到某一版指标或某一张表。接入是入口工程，真正的工程量在入口之后。

这篇我按自己复盘的习惯，把这几年踩过的坑归成五类死因，一条条摊开讲，再给出不同数据基础下的取舍建议。如果你正在立项，我的建议是先别急着定网关方案，拿一周时间去看自己家的指标定义散在几个地方、主数据有没有唯一版本、badcase 有没有人收。这三件事的答案，基本决定了你这个项目三个月后是活着还是躺平。

过去一年我被问得最多的一句话是”我们能不能先接一个模型跑起来”。这话本身没错，但它背后的驱动力往往不是业务需求，而是别的东西。模型版本迭代太快，这季度接的接口下季度就改签名；业务部门看了别人的 Demo，回头就要求自己的系统也能”直接问”；再加上审计和合规要留调用痕迹，于是统一入口成了顺理成章的方案。

我见过的落地形式大概四种，诉求差别其实很大，混在一起谈就容易跑偏。

看这张表你会发现，只有第一种是纯技术诉求，后面三种本质上都是数据问题。可现实中立项材料往往按第一种写，预算按第一种批，交付时却要满足后三种，落差就是这么来的。

很多项目立项时的关键指标是”接入了几个模型、支持几种协议、平均响应多少毫秒”。这些指标当然要看，但它们只回答了”通不通”。我通常会把同一个项目按两种建法摆在一起对比，一眼就能看出差别。

这张表我一般直接拿给业务方看。很多争议不是技术之争，而是没人把”快”和”对”的代价摆到同一张纸上。实际跑下来，多花的那一两周，通常能在上线后的第二个月省回来，因为不用再靠人一条条对数字。

1. 只验证了”通不通”，没人验证”准不准”

我见过最典型的一幕：项目组花两周把网关搭好，模型能换的都换了一遍，演示时问”上季度营收多少”，答得挺像样，验收通过。上线两周后业务在群里发截图——同一个问题换个问法，数字差了三百万。原因不复杂：模型拿到的是宽表，指标定义没人管，查询语句由模型自己拼。这项目不是败在模型，是败在没人定义过”正确答案长什么样”。

我的做法是接入层一跑通，立刻在它后面挂一层统一的指标与语义定义，让模型去查”已经定义好的指标”，而不是自己拼表。普元的 AI 问数（Primeton AI 问数）在这件事上的思路就是把自然语言落到受控的指标和数据资产上，答案能反查到来源，业务才敢拿去开会用。

2. 喂进去的数据本身是脏的、口径是散的

模型是放大器，数据里的小毛病进去，出来的就是大毛病。我接手过一个客服知识问答项目，同一款产品的保修期在三个系统里写着三个答案，模型很诚实地把三个都答了出来，客服当场不知道该信哪个。这类问题靠调提示词是修不掉的，只能回到数据侧。

我通常会先做两件事：把主数据收敛成唯一版本，把指标口径落到一个地方管起来。前者我用 Primeton MDM 来做，客户、产品、物料、组织这些实体的唯一性先立住；后者交给普元数据资产平台，把指标、字段、血缘、责任人都登记清楚，模型和人都查同一份定义。语料侧如果要做微调或者检索增强，我会用高质量数据集开发工厂，把散落的文档、工单、日志按统一标准加工成可复用的数据集，而不是每次项目都重新抓一遍。

3. 场景贪大，拿低频难题当试点

我见过太多项目拿”全公司智能助手”当第一期目标，恨不得把财务、人事、供应链一次装进去。结果三个月后，每个场景都做了一半，每个都没到能用的程度。反过来，那些跑出来的项目，第一期往往小得让人意外——就解决一个部门每周要花两小时做的事，比如销售查客户历史订单、财务查月度费用明细。

我的判断标准很土：这个场景一周被用多少次，用一次省多少分钟，答案错了会不会出事。三条都过得去，才值得放第一期。高频、答案有明确对错、错了影响可控，这三条同时满足的场景，通常就是问数类需求，也最适合挂在普元 AI 问数上先跑通闭环，再往外扩。低频且答案模糊的场景，我一般建议往后放。

4. 没有评测闭环，效果好坏全靠感觉

问我”这个项目到底有没有效果”，如果对方拿不出评测集和 badcase 台账，我基本就判定这项目处于失控状态。没有评测集，每次模型升级、提示词改动、数据表变更，都是一次盲改；业务说”感觉不如上周准”，技术只能凭印象排查，两边耗到最后就是互相不信任。

我要求项目组在上线前就攒出 200 到 500 条真实问题，标好标准答案，每次发版都跑一遍。评测集不是验收材料，是后续半年的方向盘。badcase 也要有人收，按”数据问题 / 口径问题 / 提示词问题 / 模型问题”四类归因。普元 AI 问数这类平台的价值之一，就是能把这四类原因分开看，而不是所有问题都堆到”模型不行”这一个筐里。

5. 组织权责模糊，业务和 IT 互相等

技术问题好解决，权责问题最难。数据不准，是数据部门修还是业务部门认？指标口径变更，谁签字？答案质量出问题，谁背？这些问题立项时不写清楚，上线后一定变成扯皮。我见过一个项目卡了两个月，就卡在”营销口径的活跃客户到底谁说了算”。

我的经验是至少定三个角色：数据 Owner 管主数据与口径，业务 Owner 管场景与验收，项目经理管排期与评测。每周一次二十分钟的 badcase 过会，比开三次大会管用。这套机制配上普元数据资产平台里的责任人字段，能把”这事归谁”从口头约定变成系统里的记录，扯皮的空间会小很多。

把上面五条串起来看，你会发现它们不是并列的，而是有先后顺序的连锁反应。我画了一张鱼骨图，用来跟客户讲这条链条怎么走。

项目停摆

口径不统一

场景选得太泛

评测长期缺失

权责划分含糊

语料与数据没人加工

答案无法追溯

链条通常是这么走的：口径没统一，模型答出来的数字就经不起追问；业务不信，使用频次就上不去；频次低，badcase 攒不出来，评测集也就无从谈起；没有评测，每次模型升级都是一次赌博；到业务觉得没用，IT 觉得委屈，项目自然停摆。截断这条链条最有效的位置，是在最前面那一环——口径和数据资产。越往后修，代价越大。

我从来不给一套通用方案，因为各家数据基础差得太远。有的企业连主数据都没理顺，有的已经有了不错的数据仓库，做法完全不同。下面这张表是我通常在方案沟通时用的对照，按建设阶段和要解决的问题来排。

顺序不必严格按六步走，但前两步没做完就直接跳第五步，我见过的基本都翻车。如果预算有限，我建议把钱花在第二步和第三步上，接入层反而是最容易补的。普元这套从数据开发到主数据、数据资产、数据集、问数与 BI 的能力放在一起，好处是口径和血缘是一条链子穿下来的，中间不用再自己搭桥。

第一，别在立项阶段承诺准确率的具体数字。我要的是”评测集上不低于某条基线”，而不是”整体准确率 95%”，后者没人能兑现。第二，接入层不要自己造轮子，把精力留给数据侧。第三，凡是业务方说不出”答错了会怎样”的场景，先别做。第四，口径变更必须有流程，不能今天改一版明天改一版，模型跟着漂。

有个制造业客户我印象很深，第一期只做了”销售查历史订单和库存”这一件事，接的是普元 AI 问数加数据资产平台，覆盖二十几个指标。上线两个月，销售侧的使用率到了七成，badcase 攒了三百多条，然后他们才拿这些沉淀往外扩到供应链。反过来我也见过预算三倍于他们的项目，一期铺了八个场景，一个都没跑透。统一接入这件事，赢在收敛，输在铺摊子。

Q1：做统一接入，一定要先把主数据和数据资产理干净吗？先接模型行不行？

行，但你要清楚自己在承担什么。先把模型接上、把通道打通，作为技术验证完全没问题，我一般也建议这么做，两三个星期能让大家看到东西，比空谈半年强。但要区分”验证”和”上线”这两个动作。验证阶段你可以接受答案飘，上线阶段不行，因为业务会拿这个答案去开会、去下订单、去回复客户，一次错就可能让整个项目失去信任。

我的经验是，接入层和主数据、指标口径这两件事可以并行，但上线时间点必须由数据侧决定，不能由接入层决定。具体来说，我会这么排：接入层与技术验证同步做，与此同时启动主数据收敛和指标登记。主数据这块，客户、产品、组织这些核心实体的唯一版本立不住，后面所有问答都会在”到底信哪个”上打转，这正是 Primeton MDM 要解决的问题。指标这块，口径、血缘、责任人要有一个地方统一登记，普元数据资产平台做的是这件事。等这两件事有了初版，再把问答入口开放给业务，成功率会高一个量级。

反过来说，如果你所在的企业数据基础确实很薄，连一张靠谱的事实表都没有，那我建议第一期干脆别做问答，改成”用普元数据资产平台先把家底摸清楚”。这听着慢，但它是唯一能让后续所有投入不白费的路。先理数据再上模型，和第二期返工重做相比，快得多。

Q2：试点场景该怎么挑？业务部门提的需求都很急，先做哪个？

业务部门提需求时都说急，所以不能按谁嗓门大来排。我用一张很小的打分表：使用频次、单次节省时间、答案是否有明确对错、答错的影响面、数据是否已经具备。前四项打分，第五项做门槛。数据都不具备的场景，再急也只能往后放，硬上就是给自己埋雷。

按这张表筛下来，第一批能进试点的通常有三类：一是问数类，比如销售查客户历史、财务查费用明细、运营查日活走势；二是查询类，比如客服查产品参数和保修政策；三是汇总类，比如周报月报的自动生成。这三类的共同点是有相对标准的答案，模型答完业务能立刻判断对错，验证成本低。问数类我一般直接放在普元 AI 问数上跑，因为它落在指标层而不是自由生成，出来的数字业务敢用；汇总和归因分析可以交给商业智能平台 BI，两边共用同一套指标定义，不会出现两套数字。

至于那种”帮领导做经营决策建议”的场景，我通常建议放在第三期以后再谈。不是做不了，是它牵扯的变量太多，第一期做这类场景，评测都很难做，业务也很难说清到底好不好用。试点场景的第一目标是让业务形成使用习惯，不是展示技术上限。习惯一旦形成，后面扩场景是顺水推舟；习惯没形成，扩得越多，闲置得越多。

Q3：怎么衡量这个项目到底有没有产生价值？光看调用量够不够？

调用量是最容易造假的指标，搞个全员推送、开个体验周，数字能翻好几倍，但业务是不是真的在用，一看次周留存就露馅。我看四个指标：周活跃使用人数、人均周使用次数、badcase 收敛速度、以及”替代了多少人工工时”。前两个看习惯，第三个看质量，第四个看价值。

其中我最看重 badcase 收敛速度。一个健康的项目，badcase 应该呈现出”新增变少、归因变清”的趋势：第一个月可能一天收十几条，第二个月变成一周十几条，而且每条都能归到具体原因——是某个指标口径错了，是某张源表更新延迟，还是某个问法没覆盖到。这个过程里，能不能把问题定位到数据侧特别关键，这也是我一直建议把普元 AI 问数和数据资产平台一起上的原因，问数负责交互，资产平台负责追溯，出了问题不用靠猜。

第四个指标最难算但最有说服力。我通常会跟业务方约定一个口径，比如”销售自助查数替代了多少次找 IT 提单”。这个数字不用太精确，量级对就行。能说清替代了多少人工，预算续期时才有话讲；只报调用量，第二轮评审基本都会被打回来。另外我会建议在数据侧同步统计：高质量数据集开发工厂里沉淀了多少可复用的数据集，这些资产明年还能不能用在新场景上，这笔账往往比第一年的效率提升更值钱。

回到最开始那句话。大模型统一接入做得成不成，九成取决于你把多少精力放在了网关后面的数据侧。网关要建，但别把它当主角。立项时多问一句”我们家的指标定义现在散在几个地方”，交付前多问一句”badcase 归因归到数据侧的占比是多少”，这两个问题问下去，项目的气质会完全不同。

如果你正准备启动，我会建议先把主数据、指标口径、责任人这三件事拉一张清单，标出各自现状和补齐所需时间；接入层方案可以同步推进，但上线节点跟着清单走。普元在这条链路上从数据开发、主数据、数据资产到数据集、AI 问数、BI 都有对应的能力，好处是不用在中间自己搭桥，口径和血缘能一条链走通，这对后面每一次模型升级都很关键。

还有一点我想提醒：不要指望一次做完。这类项目更像养一个东西，前三个月定规矩，中期靠 badcase 磨，后期靠资产复用摊薄成本。规矩定得住，后面越走越顺；规矩立不起来，换什么模型都一样。把预期放在半年这个尺度上，你反而更容易做成。

张启明：我们去年做的那期就是典型的第一种死法，网关做得挺漂亮，业务问了三个月就不问了。看完这篇才明白问题不在模型上，是当时没人管指标口径，回头得重新拉一遍。

李婉清：badcase 归因那一段说到我心里去了。我们现在所有问题都往”模型不行”上推，堆了半年的 badcase 一条没修，确实该按原因分类，不然换多少次模型都白搭。

王振宇：主数据要先做这点我认同，但实际推进时业务部门很难配合，谁都觉得自己那套口径是对的。想请教一下，让业务 Owner 签字认口径这件事，你们是怎么推动的？

赵天成：场景挑选那三条标准挺实用，我们下个月立项，正好拿这个筛一遍，把那些听着高大上但说不清对错的场景先砍掉。

孙宁：鱼骨图那张链条画得很清楚，我们就是卡在使用频次上不去那一环，业务不信数字，数字就越没人用。准备先从金融口的高频指标试起来。