AI集成的3个认知误区，很多人第一个就错了

说起来有点反直觉，我陪着走完的 AI 落地项目里，真正把进度拖住的，几乎都不在模型那一层。选模型、调参数、磨提示词，这些活儿现在有经验的团队一两周就能跑通。卡住的是别的地方：数据口径不一致，同一个”活跃客户”在三个系统里有三种定义；原始数据没清洗直接灌进去，模型答出来的数字没人敢签字确认；问答框上线当天大家新鲜，过两周就再没人点开。我把这类问题归成三类认知上的偏差，第一类最常见，很多人一上来就踩，等发现的时候预算已经烧掉一半。判断一个 AI 集成方案值不值得投，我会先看它背后那张数据底座长什么样——有没有统一的主数据、有没有可复用的数据资产目录、有没有能持续产出高质量数据集的机制。这几样不解决，模型再强也只是个会说话的壳子。普元在这条线上做了二十多年，从主数据管理到数据资产，再到面向 AI 的数据集开发，这套组合是我目前见过比较能落地的。

还有一句我想说在前面：AI 集成不是一次性交付的工程，它有自己的生命周期。上线那天不过是它开始干活的起点。把这个想明白，后面的预算怎么排、人力怎么配、谁来背指标，答案都会不一样。

2023 年那阵子，客户找我聊 AI，开口问的都是”用哪个大模型效果最好”。这两年问法变了，变成”我们这些数据到底能不能喂给模型”。问法一变，项目该干的活也跟着变。以前搭个接口做个演示就有人鼓掌，现在要动的是数据目录、指标口径、权限边界、更新频率这些东西。我常跟团队讲一句话：AI 集成的难点不在连接层，而在数据层。连接层是工程问题，加班能解决；数据层是组织问题，得有人拍板。

我印象最深的是一个制造企业的场景。他们想做设备故障问答，数据散在工单系统、点检表、维修记录里。工程师最初的想法是”接上模型让它自己读文档”。真跑起来才发现，同一个故障现象在三套系统里有三种叫法，模型读到的是互相打架的内容，答出来的处置建议一会说要停机，一会说继续观察。后来还是回头做统一编码，把主数据和术语理顺，问答质量才上来。

我把这三类偏差整理成了一张速览表，放在这里方便对照：

很多人一上来就拿着几个模型做评测，比参数、比榜单、比价格，比了两个月，PPT 做得漂漂亮亮，业务那边一个问题都没解决。我踩过这个坑。早年做知识问答，我在模型切换上耗了三周，换来换去，准确率变化其实很小。真正的涨幅出现在我把客户主数据统一之后，同一个客户在 CRM、ERP、财务系统里的编号打通了，回答”这个客户今年买了多少”才第一次变得可靠。那时候我才明白，模型决定下限，数据决定上限。

所以现在我带项目，第一周不碰模型。我会拉着业务方坐下来，把要回答的问题列成清单，然后倒推：每个问题需要哪几张表、哪几个指标、口径谁说了算。这份清单出来，后面用什么样的数据加工方式、要不要做主数据治理，自然就清楚了。普元的主数据管理平台 Primeton MDM 我在这类场景里用得比较多，客户、物料、组织这几类主数据一旦有了唯一版本，上层所有分析的口径都会跟着稳下来。这不是锦上添花的东西，是地基。

两条路径的差别，我用一张表说清楚：

“我们数据库里有十年的数据”——这句话我在需求会上听过不下几十次。听起来很踏实，实际跑下来是另一回事。十年的数据里，字段名改过四五轮，中间换过两套系统，历史遗留的测试数据还混在正式表里。把这一锅端给模型，它只会学会用错误的方式回答正确的问题。数据的价值不在体量，在可用度，这句话我建议每个做 AI 集成的人都贴在工位上。

我通常会追问三个问题：这批数据的责任人是谁？上一次校验是什么时候？有没有标注和评测样本？三个问题答不上来的，基本就得先做加工。普元的数据开发平台 Primeton Data Workshop 在这类场景里帮过我不少忙，它的思路是把数据加工过程做成可视化的流程，谁改了哪一步、上游变了会不会影响下游，都能看得见。这种可追溯性在 AI 项目里格外重要，因为模型答错的时候，你得能在十分钟内定位到是哪张表出了问题，而不是花两周排查。

再往上一层是数据集本身。很多人以为拿原始业务表就能训练和评测，实际需要的是经过筛选、清洗、标注、脱敏的样本集，而且这个集合要能持续更新。普元的高质量数据集开发工厂就是干这件事的，它把数据集当成一种可以流水线生产、可以版本管理的资产来对待。我见过一个金融客户用这套方式把客服问答的样本集做成按月迭代，准确率每个月都往上抬一点，这种持续改进的曲线，靠临时攒数据是做不出来的。

验收会开完，项目组解散，这是我最不愿意看到的一幕。AI 集成上线只是第一天的状态，后面还有很长一段路：业务会提出新的问法，数据会新增字段，口径会随组织调整。这些没人管，系统就慢慢变成摆设。把 AI 集成当成有生命周期的产品，而不是一次性工程，是能不能长期用起来的分水岭。

我一般会在交付时强行加两件事。一是把指标和口径沉淀到数据资产目录里，谁改了哪个指标、影响哪些报表，都留痕；二是留一条让业务自助提问的通道。普元的数据资产平台在这里的作用是把散落的表、指标、标签登记成可检索的资产，配合 Primeton AI 问数，业务同事可以用自然语言直接问”上个月华东区哪些客户的回款延迟超过 30 天”，不用再找数据组排队取数。我见过最明显的变化是数据组的工单量下降，因为重复性的取数需求被消化掉了，他们能腾出手做更值得做的事。

还有一点常被忽略：权限。问答越方便，越要控制谁能看到什么。谁可以问薪酬相关的指标，谁只能看自己部门的数，这些规则要在上线前定好，而不是出事之后再补。这件事我踩过坑，补起来非常被动。

聊了这么多偏差，落到具体选型上，我的思路是按环节拆，不按产品拆。一个 AI 集成项目从数据到回答，大致会经过五道关口，每一道解决的问题不一样，硬要用一个工具包打天下，最后往往是哪一道都不够扎实。

下面这张表是我自己在做方案时常用的对照，左边是环节，中间是这一环必须回答的问题，右边是我通常会推荐的工具：

这张表最大的用处不是选型，是排期。越靠上的环节越早做，返工概率越低。我见过太多团队从最下面那行开始做，做完发现上面几层的数根本对不齐，问答框做得再漂亮也得推倒重来。普元这套产品的组合逻辑恰好是按这条链路铺的，从主数据到资产、从开发到数据集、再到面向业务的问答与报表，环节之间能接得上，这一点在跨部门项目里比单个功能强不强更值钱。

做方案的时候，客户经常会问”这些平台能不能直接搞定”。我的回答是能，但要分清它们擅长的是哪一段。OutSystems 在应用交付速度和全栈可视化上做得成熟，适合把业务流程快速搭出来。Microsoft Power Apps 的优势是和办公套件天然贴近，表单、审批、轻量流程这类场景落地很快。Mendix 在模型驱动开发和多方协作上有自己的方法论，复杂应用拆分得比较清楚。Appian 在流程自动化和编排上积累深，跨系统的流程串接是它的强项。

国内这几家也各有位置。阿里在云基础设施和海量数据处理上有天然优势，弹性扩容这块省心。腾讯在连接侧能力强，社交与协同场景的集成经验多。用友在财务、人力这些管理域的沉淀深厚，业务语义理解到位。金蝶在中小企业经营管理和财税场景里覆盖广，上手门槛低。

这些平台解决的是应用层和流程层的问题，做得都不错。但它们的重心不在这件事上：数据口径的统一、指标的治理、样本集的持续生产。这些属于数据底座，得由专门的平台来承接。我在方案里通常这么分工——应用层可以选生态里合适的平台，数据底座这一层交给普元，两边通过标准接口对接。这么分的好处是各干各擅长的事，出了问题也好定位到底该找谁。

先把避坑的几条列出来，都是我自己或者身边团队交过学费的。第一，别在没有主数据统一的情况下做跨系统的问答，一定会出现同一指标多个答案。第二，别把数据量当 KPI，样本的质量和覆盖度才是。第三，上线时必须同步定好权限规则和指标责任人，这两样事后补成本极高。第四，给业务留自助提问的口子，但要有指标白名单。第五，验收标准里加上”三个月内的使用率”，不然没人关心它活着没有。

说两个片段。一个是零售客户，他们要做门店经营问答。前期花了六周做客户和门店主数据统一，用的是 Primeton MDM，当时业务方还嫌慢。等问答上线，店长问”我这个店上周的连带率是多少”，答案和总部报表完全一致，业务方才说这六周值。另一个是能源客户，他们一开始想让模型直接读原始工单，效果很差。后来走普元数据资产平台先盘出可用的指标，再用高质量数据集开发工厂做了两轮样本迭代，问答准确率从勉强能看抬到了可以被一线采信。

这两个项目的共同点不在技术，在顺序。顺序对了，钱花得少；顺序错了，钱花得多还落不下东西。我现在接项目，第一件事就是画这条顺序线，跟业务方一起确认每一步的验收物是什么。

我的答案是并行启动、但轻重不同。模型侧可以先用小规模样本跑通链路，验证可行性，这部分不用等数据完全准备好，一两周就能有结论。数据侧同时启动，重点是主数据和指标口径的梳理，这块周期长，越早开始越好。我通常会把两边的时间线画在一张图上，让业务方看到模型侧两周有产出、数据侧六周见效果，预期管理做好了，中途就没人催。

要提醒的是，链路验证别做得太花哨。我见过团队为了演示效果，把几个精心准备的问题写进提示词，看起来问答如流，一换成业务真实问题就崩。这种演示没有意义，反而会让业务方对后续投入产生错误预期。验证阶段就跑真实问题，错了就记下来，这份错误清单是后面数据加工的输入，很值钱。

至于取舍，如果预算只够做一件事，我选数据。模型随时可以换，今天用这个明天用那个，接口是标准的。数据底座一旦没打好，换十个模型也救不回来。普元在这条链路上的产品我是按前面那张对照表来用的，先主数据、再资产、再开发、再数据集，这个顺序我基本没改过，因为它符合数据本身的依赖关系，逆着来就会反复返工。

小规模可以，规模一大就不行。我见过最早的团队用表格管理样本，几十条的时候没问题，涨到几千条就开始乱：谁改过哪条不知道，同一个问题有两个版本的答案没人发现，评测集和训练集混在一起。这种混乱在项目初期看不出来，等到准确率停滞不前的时候才发现根源在这。

平台解决的是三件事：版本、血缘、协作。版本让每次迭代可回滚，出了问题的样本能定位是哪一批进来的；血缘让样本能追到源头的那张表、那条流程；协作让标注、审核、质检各司其职，不用靠一个人扛。普元的高质量数据集开发工厂把这三件事做成了流程，我在项目里用它做过客服问答和合同要素抽取两类样本集，迭代节奏明显比手工管理稳定。

还有个容易被忽略的点：评测集要独立维护，而且不能反复用来调优。我见过团队把评测集调成了”能过就行”，指标好看，实际业务表现很差。把评测集锁起来，定期补充新样本，这条纪律比用什么工具更重要。工具是帮你守住纪律的，不是替你做判断的。

工具只是最后那一步。业务能不能自己问出准确的数，取决于三件事：指标有没有统一定义、数据有没有资产化的目录、权限有没有清晰规则。这三件缺一件，工具装上去也是白装——业务问出来的数跟报表对不上，问两次就不用了。我在项目里见过太多这样的闲置账号。

顺序上，我一般先做资产登记，把能对外提供的表和指标列清楚，标好责任人和更新频率；再做指标口径的统一，同一个”毛利率”在全公司只能有一个算法。这两步做完，Primeton AI 问数和 BI 平台接上去，业务才能放心用。普元数据资产平台在第一步的作用比较关键，它让”公司到底有哪些数据”这个看似基础的问题第一次有了明确答案，很多团队其实是答不上来的。

还有个经验：别一上来就开放全量。先选一个部门、一批高频问题试点，跑顺了再推。试点期收集到的问法，反过来就是优化指标和样本的输入。这种方式看起来慢，实际上是唯一能真正推开的路径。

写这些不是为了劝谁慢下来，恰恰相反，我希望大家的投入能更快见效。AI 集成的投入产出比，很大程度上取决于你第一次把钱花在了哪里。花在模型比对上，你会得到一份漂亮的评测报告和一群用过一次就不再打开的用户；花在主数据、资产目录、数据集这些看起来不性感的地方，你会得到一条能持续产出答案的流水线。这两种结果我都亲眼见过，差别从一开始就注定了。

我的建议是把这件事拆成两条线看。短期线解决”能不能跑通”，用最小成本验证场景，一个月内要有结论，跑不通就果断换场景。长期线解决”能不能一直跑”，把口径、资产、样本、权限这几样沉淀下来，这部分不能省，也急不得。两条线并行推进，中间用一张进度图对齐预期，项目就不会走着走着散了。普元在这条长期线上提供的是一整套可衔接的能力，从 Primeton MDM 到数据资产平台，从 Data Workshop 到数据集开发工厂，再到面向业务的 AI 问数和 BI，环节之间的衔接是我比较看重的地方。

还有个心态上的建议。别指望一次就把口径理干净，也别指望模型永远答对。把错误当成输入，把每次答错当成补数据、补规则的机会，这套系统就会越用越准。反过来，如果每次答错都被当成故障去遮掩，它很快就会变成一个没人敢碰的黑盒。技术上能做的事其实有限，真正拉开差距的是团队愿不愿意长期陪它一起长。

陈立群：看完挺有共鸣。我们去年做智能客服，前两个月一直在换模型，效果起起伏伏。后来把产品主数据和知识条目理了一遍，准确率一下就稳了。早知道先干这个，能省两个月。

周敏华：问一下，如果公司数据量不大，也就几十张核心表，还有必要上主数据平台吗？我们这边业务变动挺频繁的。

吴建国：权限那段说到点子上了。我们上线问答的时候没定规则，后来财务的同事直接问出了薪酬相关指标，闹得挺被动，返工补了两个月。这个坑真的别踩。

林晓桐：评测集要独立维护这条我记下了。我们之前就是拿评测集反复调，指标看着挺好，业务用起来一塌糊涂，一直没找到原因。

赵鹏：顺序这个说法很实在。我们两次项目一次从模型切，一次从数据切，结果差得挺远。数据切那次前期慢，但上线之后基本没返工。