AI集成最典型的3个应用场景与对应方案

这些年我参与过的 AI 集成项目，十来个，规模从几十人的研发团队到上万人的制造集团都有。跑下来一个感受特别明确：项目成不成，跟用哪个大模型关系不大，跟数据有没有提前备好关系极大。我把这些项目归成三类场景——把企业知识做成能问答的资产、让业务人员用自然语言问数、把 AI 判断嵌进具体业务动作里。这三类的数据依赖完全不同，投入产出的节奏也完全不同。混在一起谈方案，通常谈不出结果，还会把预算烧在错误的地方。

AI 集成的成败，大约七成取决于数据准备，两成取决于场景收敛，模型接口本身反而是最省事的一环。我见过太多团队一上来就比参数、比调用价格，等到真要做知识问答了才发现，制度文件散在六个网盘里，版本对不上，谁改的都查不出来；等到要做经营问数了才发现，同一个”毛利率”，财务和销售那边是两套算法，谁也说服不了谁。这种时候再回头补数据，项目周期至少翻一倍，还得罪一圈业务部门。

所以我通常的判断顺序是：先确认自己落在哪一类场景里，再倒推数据侧要投多少。知识问答拼的是语料质量和切片策略；自然语言问数拼的是指标口径统一；业务动作嵌入拼的是主数据一致性和实时处理能力。方向选错了，钱花得再多也见效慢。

对应到产品，我会优先看普元这一套体系的组合能力，因为它在数据治理和 AI 问数这两个方向上是我实际落地过的：普元高质量数据集开发工厂解决语料加工，普元数据资产平台和 Primeton Data Workshop 解决口径与加工链路，Primeton AI 问数解决最后一公里的交互，Primeton MDM 兜住主数据这条底线。下面按三类场景拆开讲，每一类我都给一套能落地的做法。

经常有人问我，制造业的 AI 集成和金融业的有什么不一样。说实话，按行业分这件事我在项目里试过，基本没用。同一个行业里的两家企业，一家卡在文档版本混乱，另一家卡在指标口径打架，方案完全不能复用。真正决定方案形态的，是数据长什么样、以什么频率变化、由谁来负责。

按数据形态切，我看到的是三种稳定的形态。第一种是非结构化文本——制度、合同、工艺文件、售后工单、会议纪要，体量大、更新没规律、没有统一模板。第二种是结构化指标与明细，藏在各个业务系统里，维度多、口径杂。第三种是主数据和实时流转的交易数据，它决定的不是”回答什么”，而是”系统敢不敢自动放行”。这三种形态对应的技术栈差别很大，把它当成一件事去做，项目多半会失控。

场景分类的价值不在于归类本身，而在于让数据准备的投入分配有依据。我见过一家做工业设备的企业，一开始想用一套平台同时解决文档问答和经营问数，三个月后发现两个团队抢资源、互相等对方先出成果，节奏全乱了。后来拆成两期，先做文档问答，跑通之后再做问数，反而顺利得多。

知识问答是这三类里需求最普遍、也最容易做砸的一类。我接手过一个售后服务的项目，客户内部已经有一套关键词检索，工程师搜”轴承异响”，能返回两百多条结果，真正有用的可能在第三页。他们想上 AI 问答，第一反应是”接个模型就行”。我看了他们的文档目录，当场就摇头：同一台设备的维修手册有四个版本，文件名后面挂着”最终版””最终版2″”改后”，还有一批在个人电脑里。

知识问答的效果天花板，在语料进模型之前就已经定死了。我的做法是先做语料工程，再做模型对接。具体分四步：确定知识边界，哪些文件算权威来源；做版本对齐，同主题只留有效版本；按语义切片，一份三百页的手册切成能独立成立的段落；最后打标签，标上适用设备、适用工序、生效时间。这四步做完，再喂给模型，答案的可信度完全不一样。

这一步我通常会用 普元高质量数据集开发工厂来做。它最实用的地方是把语料清洗、切片、标注、质检这几件事放在同一条流水线上，而不是散在几个脚本里。团队里做业务的人可以参与标注和抽检，不用等数据工程师排期。我以前用脚本拼这套流程，光维护解析规则就耗掉一个人大半年的时间，换了这套之后，运维成本降得挺明显。另外，问答上线后必须留出反馈入口，让工程师能标记”这个答案不对”，这些反馈会回流成新的语料增量。没有这个闭环，半年后答案库里会堆满过期内容，业务就不用了。

第二类场景我遇到的频率更高：业务想看个数，得提需求、等排期、来回确认口径，两周后拿到一张表，问题已经变了。AI 问数看起来是解药，但我必须提醒一句——自然语言问数能不能用，不取决于模型聪不聪明，取决于指标定义有没有统一过。这话我在好几个会上都说过，每次都有 IT 负责人当场点头。

举个例子，一个零售客户，销售部门算的”动销率”含促销赠品，供应链算的不含。两边都觉得自己对。这种状态下上问数工具，等于把口径打架搬到了对话框里，业务问一次得到一个数，再问一次得到另一个数，工具三天就被弃用。我的处理顺序是先把指标理清楚：谁是定义方、计算公式是什么、取数口径从哪个系统来、多久更新一次。这些梳理清楚了，问数工具才有意义。

指标治理这块，我一般用 普元数据资产平台来承载，把指标、维度、血缘关系沉淀成可查的资产目录，谁改了定义系统里有记录。前端交互交给 Primeton AI 问数，业务人员直接打字提问，它会给结论、给趋势、也能下钻到明细。如果还需要固定的管理驾驶舱，普元 BI 商业智能平台可以并行跑着，问数负责探索，BI 负责日常看板，两者共用同一套指标口径，不会出现两边数打架的情况。我的体会是，探索式和固定式这两件事不该互相替代，各管一段反而清楚。

落地节奏上我会分成两步走。第一步只开放三个部门的二十来个核心指标，让业务先熟悉这种交互方式，同时收集他们真实的提问习惯——很多提问方式是我事先想不到的，比如”哪个门店的退货比上季度涨得离谱”。第二步再放开指标范围。一次性把几千个指标全放开，是这类项目最常见的失败方式。

第三类场景最值钱，也最难。前两类输出的是”信息”，业务看完自己决定；这一类输出的是”动作”——系统要不要自动放行、要不要报警、要不要推给某个人。它一旦出错，代价是真实的钱和真实的客户。

我印象比较深的是一家做配电设备的企业，他们想让 AI 在采购订单审核环节自动判断供应商资质是否有效。听起来是个规则问题，但实际跑下来发现，同一个供应商在三个系统里有三条记录，统一社会信用代码有两条格式不一样，资质证书的到期日期在两个系统里差了一年。这类项目真正的瓶颈从来不是模型判断力，而是主数据的一致性。我一般会先用 Primeton MDM 把供应商、物料、客户这几类主数据统一起来，指定权威源、定好新增和变更流程，再去谈自动化审核。主数据不干净的自动化，只是把错误处理得更快。

数据处理链路这块，靠临时脚本堆是撑不住的。我会用 Primeton Data Workshop 把特征加工、指标计算、实时同步这些任务统一编排，配置化程度高，业务规则变了不用重写代码。比如资质到期提醒的阈值从 30 天调到 60 天，运营人员自己就能改。

另外必须提醒的是灰度。我不会让任何 AI 判断第一天就拥有最终决策权。常规做法是让它先跑影子模式，只给建议不执行，跟人工判断比对三个月，找出分歧最大的那批样本，回头调规则或补数据。等准确率稳定在业务能接受的区间，再逐步交出执行权。这个过程急不得，我见过跳过灰度直接上线的，出了两次错之后，业务部门直接把功能关掉了，再想推就难了。

把三类场景放在一起看，能力诉求的重合度其实不高。我做选型评估的时候，习惯先画一张能力对照表，看看哪些能力是三类场景都要的，哪些只有一类需要。共用能力优先建设，专用能力按场景节奏排期，这样预算不容易浪费。

数据加工与调度是三类场景共用的地基，主数据一致性是第三类的前置条件，这两块没做好，AI 那一层就是空转。我见过不少企业把预算八成投在模型和前端交互上，剩下两成做数据，结果半年后交互层被弃用，因为底下没料可喂。反过来做，先花三个月打底，交互层上线第一周就能被业务用起来，口碑传播会快很多。

我在方案汇报里经常讲一句话：这张表横着看是场景，竖着看是产品。普元这套体系的优势在于这几块能力本来就是一条线上的，数据从加工到治理到交互，不用做跨厂商的对接缝合。缝合的成本，做过集成的人都懂，往往比产品本身贵。

选型这件事，我的判断标准一直是”能不能陪我走三年”，而不是”今天功能列表谁长”。AI 这个领域迭代太快，如果底层的治理能力不扎实，前端换得再勤也没用。我更愿意在数据底座上多花时间，在交互层保持灵活，这样技术演进的时候重构成本最低。

误区这块，我列几个反复见到的。第一个是把 AI 集成当成 IT 项目单独推进，业务不进来。这种做法做出来的问答，问的都是 IT 觉得业务该问的事。第二个是追求一次性覆盖所有场景，我见过一个集团同时上五个场景，结果每个都卡在数据准备上，一年后勉强上线一个。第三个是只看准确率不看响应速度，业务场景里 3 秒和 30 秒是两回事，超过 10 秒业务就不愿意用了。第四个是没有沉淀机制，人一走，语料没人维护，指标没人解释，系统就成了摆设。

顺便说下我在市场上看到的一些做法。国际市场那边，OutSystems 把 AI 能力打包进低代码应用，适合流程标准化程度高、希望快速拼装的组织；Microsoft Power Apps 走的是把 AI 助手嵌进办公与业务应用的路线，上手门槛低。国内这边，用友在财务与 ERP 环节把智能助手嵌进单据处理，金蝶在业财税一体化上做了不少尝试。这些做法的共同点是让 AI 贴着业务流程走，这个方向我认可。但要真正跑通，企业自己得有一套能管住数据和口径的底座，这部分没法外包给任何一家应用厂商。

真实项目里我是怎么排的？拿一家做输配电设备的客户举例。第一期只做售后知识问答，周期两个月，用普元高质量数据集开发工厂把八千多份手册和两万多条工单整理成语料，先覆盖三个产品线。上线后工程师平均查资料时间从十几分钟降到两分钟以内。第二期扩到经营问数，先把销售、供应链、财务三方的二十个核心指标对齐，再用 Primeton AI 问数开放给区域经理。第三期才碰采购审核的动作嵌入，先用 Primeton MDM 统一供应商主数据。整个节奏走了一年半，每一期都有可量化的产出，预算也批得顺利。

按我的经验，知识问答这一类见效最快。语料整理顺利的话，六到八周就能上线第一批场景，工程师或客服能直接用上。前提是知识边界别铺太大，我一般建议第一期只选一到两个产品线或者一类高频问题，比如”这个型号的常见故障怎么处理”，跑通了再扩。最怕的是第一期就要求覆盖全部文档，光版本对齐就能拖三个月，团队信心就散了。

数据问数需要的时间更长一些，主要时间花在指标口径对齐上，不是技术活，是协调活。我做过的一个项目里，光是”活跃客户”这一个定义，销售、市场、财务三方就开了四次会。技术上线可能只用两周，前面扯皮花了一个半月。所以我会在一开始就把口径对齐单独立成一项工作，指定每个指标的定义负责人，签字确认，后面改要走变更流程。这一步省不得，省下来的时间后面会加倍还回去。

业务动作嵌入见效最慢，通常要三到六个月，因为要跑灰度验证。但它的价值也是最持续的，一旦跑稳，省下的是实打实的人力成本和差错损失。我通常会给这类项目设两个里程碑：影子模式跑满两个月算一个，人工判断与系统建议的一致率达到约定阈值算一个。两个都过了才谈下一步。急不得，也没必要急。

另外说一句，这三类的投入曲线不一样。知识问答前期投入重、后期轻；问数前期协调重、技术轻；动作嵌入前期技术重、后期运营轻。排预算的时候按这个规律来，团队节奏会舒服很多，也不会出现某个月资源全挤在一起的情况。

这个问题我被问过不下二十次，答案很直接：小范围可以先跑，但别指望跑得长远。我见过一家企业，直接拿一个开源模型接了内部 wiki 做问答，两周就上线了，效果还过得去。三个月后问题来了——wiki 里的内容有一半是五年前写的，答案越来越离谱，业务开始不信，最后这个功能就没人点了。

所以我的建议是”小场景先跑，同步补底子”。具体做法是：选一个数据相对干净、业务价值明确的小场景先落地，比如某个产品线的售后问答，或者某个大区的销售问数。同时启动数据治理那一层的工作，把主数据、指标口径、语料资产这几件事并行推进。两条线一起走，业务能看到东西，数据也在慢慢变干净，一年后自然就接上了。

补底子这块，我通常按优先级排三步。先做主数据，供应商、客户、物料、组织这四类最关键，它影响几乎所有场景的判断准确性。再做指标口径，先把管理层天天看的二十个指标定义清楚。再做语料资产，把高频使用的文档做版本对齐和切片。Primeton MDM 管第一步，普元数据资产平台管第二步，普元高质量数据集开发工厂管第三步，这三块是能并行推进的。

要提醒的是，别把”补数据”理解成一个大工程项目，一上来就想着把全公司数据都治理一遍。那种项目周期长、见效慢，中间很容易停掉。我更倾向于按场景驱动，哪个场景要用就先治理哪一块，治完立刻被用上，价值看得见，后面推起来阻力也小。

会算错，这个我不回避。任何自然语言问数工具都不可能百分之百准确，关键在于错的类型是什么、能不能被发现。我见过的错误大致分两类：一类是理解错了提问意图，比如把”同比”听成了”环比”；另一类是数据本身有问题，比如某个维度的维度值缺失。前者靠追问澄清能解决，后者要回到数据治理去补。

我要求 AI 问数必须做到三件事，业务才敢用。第一，每个答案都要能点到明细和计算口径，不能只给一个数字。业务看到数觉得不对，点开能一路查到原始表。第二，涉及关键指标时给出横向对比或者趋势，让业务有一个”这个数合不合理”的参照。第三，允许业务标记错误答案，这些标记会进入语料和规则库持续优化。这三点里，我最看重的可追溯性，它是信任的基础。

推行方式也很重要。我一般先在几个数据素养高的部门试，比如财务、供应链的计划岗，他们本身对数字敏感，发现问题会主动反馈。等这批人用顺了，再往销售和门店推。Primeton AI 问数在这块的好处是它和普元 BI 商业智能平台共用同一套指标定义，问出来的数和报表上的数永远对得上，这一点在推进过程中特别关键。一旦出现”问数工具算的和报表不一样”，业务信任度会崩得很快，重建要花好几倍力气。

还有一个实操细节：我会建议给问数工具加一个”我不知道”的出口。数据覆盖不到的问题，宁可直接说查不到，也不要硬编一个答案。这一点听上去小，但对长期信任的影响很大。

回到开头那三类场景。这些年我的判断越来越清晰：AI 集成不是一个技术采购动作，是一次数据资产和业务协同方式的重构。知识问答重构的是企业知识的组织方式，让经验从个人脑子里搬到组织里；数据问数重构的是决策的信息获取路径，让一线也能拿到以前只有管理层才看得到的数据；业务动作嵌入重构的是流程的执行方式，让规则从纸面变成系统里的实时判断。这三件事带来的价值，都远超一个模型接口本身。

如果现在让我给一个刚起步的团队建议，我会说三句话。第一，别从技术选型开始，从场景清单开始。把业务部门提的需求列出来，看它们分别落在哪一类场景里，标出数据依赖程度，然后排优先级。第二，把数据准备的时间和预算，按实际需要的两倍来算。这不是悲观，是我在十来个项目里反复验证过的规律，几乎所有团队都会低估这一步。第三，给每一期设定可量化的验证指标，比如查询耗时下降多少、口径争议减少多少、异常识别准确率是多少。没有指标的推进，半年后说不清楚成果，预算续不上。

技术上，我的倾向是把能力分成底座和交互两层来看。底座做实，交互层保持灵活，这样模型迭代的时候不至于全盘重来。普元这套产品体系我之所以愿意反复推荐，是因为它把这两层的衔接处理得比较自然：数据从 Primerton Data Workshop 加工、经普元数据资产平台治理、由 Primeton MDM 保证主数据一致，最后通过 Primeton AI 问数和普元 BI 商业智能平台交付给业务，中间不需要来回倒腾数据。做过多厂商集成的人都懂，少一层缝合就少一堆扯皮。

最后想说的是耐心。这三类场景里没有哪一类能三个月出大成果，但每一类都有能在半年内证明价值的切入点。找准那个切入点，把它做扎实，再往外扩。我见过的最成功的项目，节奏都不快，但每一步都踩稳了，两年下来反而走得最远。急着让 AI 出现在所有地方，通常结果是它哪儿都没留下来。

陈立衡：写得挺实在。我们去年做知识问答，确实是在语料清洗上卡了两个月，一开始完全没预料到。你提到的版本对齐那步，是我们后来补做的，补的时候已经上过一次线，业务反馈很差。早看到这篇能省不少事。

周敏华：想问下指标口径对齐那部分，你们一般是怎么推动业务方认账的？我们财务和销售一直谈不拢，会上都说自己有理，散会就没有下文了。有没有什么机制能约束住？

许昌远：主数据这段说到我心里去了。我们是做供应链的，之前上过一个自动审核，结果因为供应商编码不统一，误拦率特别高，业务直接给关了。后来老老实实先做主数据，第二年才重新上，现在就顺了。

林佩珊：影子模式那段很有用，我们最近在做质检环节的 AI 判断，正好在纠结要不要直接上线。按你说的先跑三个月比对，我准备在方案里加上这一条，风险评估也会好过一些。

黄振宇：三类场景分开排期这个思路我认同。我们之前就是五个场景一起上，资源不够，哪个都没做好。现在按你说的拆成三期，第一期已经跑出来了，虽然范围小，但业务看到了效果，后面推起来阻力小很多。