这两年我接过不少企业AI项目的选型评审有个现象越来越明显很多团队拿着大把预算最后选了技术指标最漂亮的那家厂商结果落地三个月就卡在业务流程对接上模型效果在演示环境跑得飞起一接真实数据就原地翻车。然后回头问我当初到底怎么筛供应商才对。我的答案一直很统一先别急着比算法精度先判断这家供应商有没有你要的那个行业经验。这不是一句正确的废话而是决定项目生死的前置条件。这篇内容适合正在做企业AI选型的技术负责人、采购决策者也适合想搞清楚为什么自家AI项目推进这么难的业务方。我会把我这些年实际踩过的坑、验证过有效的筛选方法、以及那些商务合同里容易忽略的细节一次性梳理清楚。1. 为什么有行业经验越来越成为选型的第一道门槛很多团队把AI选型当成纯技术选型这是最大的误区。同样的OCR识别、同样的智能客服、同样的预测模型放在制造业和放在金融业技术栈可以完全一样但数据结构、业务流程、合规要求、异常处理逻辑完全不是一个世界。1.1 行业经验决定了模型能不能真正落进业务流程里举个最常见的例子。一个做工业质检的AI项目通用视觉检测模型在实验室数据集上能到99%的准确率但工厂现场有光照变化、产品型号切换、产线震动、灰尘遮挡这些干扰因素不会出现在通用数据集里。有行业经验的供应商会提前知道需要采集哪些现场样本、怎么设计数据标注规范、模型上线后怎么处理频繁的型号变更。没有行业经验的供应商呢大概率还在跟你讨论这个模型的mAP还能再提升0.5个点。不是说精度不重要而是在企业场景里能不能跑通闭环流程远比那一两个百分点的精度重要。1.2 行业积累直接体现在数据理解和标注质量上AI项目里有一句老话数据决定上限模型只是逼近这个上限。但很多企业忽略的是行业经验恰恰决定了你会拿到什么样的数据。我见过一个真实的选型案例。两家供应商同时竞标一个物流园区的调度优化项目A供应商是通用型AI公司算法团队很强B供应商做了七八年物流行业项目手里积累了一批脱敏后的历史调度数据连异常件处理规则都内置在数据预处理模块里。最后B供应商赢了不是因为模型更强而是因为他们的数据清洗逻辑一开始就是按物流行业的业务口径设计的上线时间比A快了一个半月。1.3 行业知识库和业务规则是短期补不出来的大模型时代有个新现象很多供应商拿一套通用大模型底座套一层行业话术就来投标了。你要问他们行业里特定的业务规则比如医疗领域的医保结算规范、制造领域的工单排程约束、零售领域的促销毛利计算逻辑他们全都说不细。真正的懂行是能把行业里的隐性知识结构化成规则、参数、提示词模板和校验逻辑这些东西是项目过程中一点点磨出来的靠临时招聘行业顾问根本来不及。注意判断供应商是否有行业经验不要听他说的要看他已有的知识资产。问他们要行业语料库的构建文档、历史项目的标注规范、内置的业务规则引擎配置这些才是真实的积累。2. 怎么识别真假行业经验一套可以照着用的供应商初筛方法论大多数企业选型踩坑不是因为没有标准而是标准定错了。一上来就比价格、比算法榜单、比PPT里的客户logo数量这些恰恰是最容易被包装的。2.1 先问三个问题快速过滤掉八成不合格的供应商我在帮助企业做初筛的时候习惯先让候选供应商回答三个问题。回答得好不好几分钟就能看出来段位。第一个问题你们团队里有多少人完整参与过这个行业的AI项目交付注意问的是完整参与不是接触过。很多供应商会把算法工程师拉来凑数但算法工程师只是项目里的一环真正懂行业的是做需求分析的、做数据治理的、做交付实施的这批人。第二个问题你们有没有这个行业特定问题的预训练模型、模板或组件库以AI客服为例有行业积累的供应商手里往往有行业话术模板、意图识别预置模型、知识库冷启动方案。没有行业积累的就只能从零开始训周期和成本完全不一样。第三个问题如果我们的业务流程跟你们之前做过的项目差异很大你们怎么应对这个问题的潜台词是逼供应商说清楚哪些环节是配置化的、哪些环节需要定制开发。有行业经验的人能明确告诉你哪些可以复用哪些需要重新做没经验的人只会说我们都能做。2.2 看案例要看细节不要只看客户名单很多供应商PPT上写着一堆客户logo但你要仔细追问做的是哪个部门的需求用了哪些技术模块上线后真实使用率怎么样项目团队多少人周期多长我见过一个很典型的翻车现场。某供应商号称服务过某大型制造企业实际只是做了一个部门内部的报表问答Demo根本没有进入生产流程。这种案例对选型没有任何参考价值。真正有效的案例验证方式是让供应商把项目拆成业务背景、数据情况、实施路径、上线效果、踩过的坑五个部分每个部分追问细节。一问到细节就含糊的基本可以判断是挂名案例或者深度不够。2.3 用表格给供应商打个行业经验分我建议选型团队做一个简单的评分表不要凭感觉打分。以下是我常用的维度可以根据企业自身情况调权重评估维度权重建议考察要点行业落地案例数量与深度25%案例是否涉及核心业务环节能否提供可验证的交付细节行业数据与知识资产积累25%是否有行业预训练模型、标注规范、规则库、语料库交付团队成员行业背景20%项目经理和核心实施人员是否有多年行业经验行业生态与上下游合作10%是否熟悉行业的软硬件生态、系统集成伙伴、数据接口规范解决方案的行业针对性20%方案里有没有行业特有术语、业务约束和合规设计把每家候选供应商按这个表打分低于60分的基本可以直接pass即使他们算法指标再好落地风险也极高。实操心得这个评估表一定要让业务部门参与打分不要只让技术部门打分。业务部门对行业理解更深能在细节上问出很多技术团队想不到的问题。3. 从初筛到选定一套完整的选型落地流程评估维度定了之后下一步是设计选型流程。流程的核心思路是先把自己搞明白再让供应商证明能力最后用最小成本验证真伪。3.1 第一步先把企业自己的需求和边界定义清楚很多企业急匆匆开始选型连自己的需求都没想清楚。我见过一家企业想上AI客服结果聊到第三轮才发现他们真正想解决的不是客服接待效率而是知识库长期没人维护、培训成本太高。需求定义错了后面全部白忙。需求定义阶段至少要想清楚四件事一是业务目标想清楚上线后主要看哪个指标。是降低人工成本还是提升响应速度还是减少客诉率指标必须量化不然没法验收。二是数据基础盘一下手头有多少历史数据数据质量怎么样涉及到哪些部门的数据需要打通。没有数据基础的AI项目就像没有食材的餐厅供应商再厉害也做不出菜。三是组织边界明确这个项目归哪个部门管使用方是谁决策方是谁谁出预算谁负责跟供应商对接。组织边界不清项目后期一定扯皮。四是合规底线企业所处行业的监管要求是什么数据能不能出域模型是否需要可解释性都需要提前列清楚。3.2 第二步发需求说明时故意留出行业细节测试需求文档不要写得过于标准化。我建议在需求说明里故意加入几个行业特有的业务场景描述然后看供应商在应答时能不能主动理解这些场景背后的含义。举例来说如果你们是零售企业可以在需求文档里提一句需要考虑促销活动期间的高并发尖峰和价格策略频繁变动。有零售行业经验的供应商会主动追问促销规则的结构、价格变动的最短时间粒度、与现有促销管理系统的对接方式没经验的供应商可能就直接跳过了因为他们的方案模板里根本没有这个模块。这一招在筛选邮件和初步电话沟通里特别好用几乎可以过滤掉那些拿着通用方案海投的供应商。3.3 第三步POC验证时一定要用真实业务数据很多企业选型时的POC环节形同虚设因为用的是供应商提供的数据集。这样测出来的结果没有任何参考价值只能说明这个供应商的算法在某个公开数据集上表现不错。正确的做法是企业准备好一小批真实业务数据注意脱敏要求供应商用这些数据完成一个最小场景的验证比如用你们的真实客服对话历史跑一个意图识别或者用你们的真实销售数据跑一个需求预测。POC的评判标准也要设计好不要只看模型精度要看三点一要看交付速度供应商拿到数据后多久能跑出第一版结果这个过程暴露的是他们的工程化能力和对数据的理解速度。二要看沟通质量他们在数据清洗过程中提出的问题是不是行业里才会想到的问题比如某些字段的取值规律、某些业务异常的记录方式问得越细说明越懂行。三要看团队构成POC期间实际干活的人是谁如果全是售前而不是后面负责交付的团队就要警惕了。你可以直接要求POC阶段请让未来真正负责交付的项目经理和算法工程师参与。3.4 第四步综合评判时把未来的长期支持能力算进去企业AI项目不是一个上线就结束的一次性工程。模型会漂移业务会变化数据分布会调整供应商能不能提供持续的支持和维护直接影响项目的长期价值。评估长期支持能力时重点看三件事看供应商有没有持续投入这个行业。有些供应商只是临时组建了一个行业小组来做这单生意项目结束小组就解散了。你可以问他们行业解决方案的研发路线图看看接下来几个季度有没有持续迭代计划。看运维体系是否完善。有没有模型监控、告警机制、定期重训的服务方案这些在合同里有没有写清楚。看团队稳定性。销售和售前换人可以但如果项目刚上线负责交付的算法工程师就离职了后面出了问题谁来解决这些细节可能在商务谈判阶段了解清楚。实际经验我见过一个项目上线时一切正常六个月后业务部门调整了流程导致输入数据格式变化模型效果直线下降。因为没有跟供应商约定后续的数据适配支持最后企业内部团队硬着头皮改了一个多月才救回来。长期支持这种事宁可谈的时候多花半天也不要上线后多花几个月。4. 商务合同与持续交付里最容易踩的坑选型流程走到最后很多企业觉得万事大吉结果在合同环节翻了车。商务条款看着是法务的事但里面的技术细节动不动就会变成项目后续的地雷。4.1 数据归属和模型归属必须写清楚这是最容易被忽略、后期最容易扯皮的部分。企业提供的业务数据、标注数据、以及最终训练出的模型到底归谁很多供应商的合同模板里默认这些权益归供应商理由是模型由我方开发。企业在谈判时一定要坚持使用企业真实业务数据产生的模型成果知识产权和所有权应归企业或者至少企业要获得永久的内部使用权。否则后续供应商换个销售策略项目直接受影响。4.2 效果验收标准不能只写准确率AI项目不像传统软件开发需求明确、功能可以穷举。模型的效果标准如果只写准确率达到90%企业根本没法验收——因为不同业务场景的准确率计算方式可以天差地别。验收标准里建议写清楚测试数据集从哪里来必须由企业提供或共同确认评估指标的计算口径是什么达到什么水平算验收通过未达到的处理方式是什么。我曾经帮一家企业改过一份合同原稿里只写了模型准确率不低于95%谈判的时候我要求加上测试数据以企业提供的最新三个月业务数据为准评估指标按加权F1计算若连续两周未达标供应商需免费提供至少一轮调优服务。有了这三句话验收环节就有了抓手。4.3 服务响应时间要有分级约定AI系统出问题跟普通软件系统出问题不太一样。普通系统可能是逻辑BugAI系统更多是效果衰减和异常预测。合同里最好约定不同级别问题的响应时间和处理方式紧急问题系统完全不可用建议约定响应时间不超过2小时修复时间不超过24小时。一般问题效果下降但不中断业务建议约定响应时间不超过1个工作日并在约定周期内完成调优或重训。需求类问题业务流程变化导致模型需适配建议约定按变更评估流程走但要有明确排期机制。这些内容不算技术难题但就是有很多企业忽略最后出了问题连找谁来处理都要翻合同找半天。注意事项合同里还有一个容易被忽略的细节——人员变更条款。供应商的项目经理或者核心算法工程师在项目期间能不能随意更换建议约定核心人员变更需要企业书面同意。前面说过AI项目干活的往往不是售前如果项目进行到一半原来说好的交付团队换了人交接成本极高。5. 避坑清单与实践总结最后把这几年的经验浓缩成一份清单给正在做选型的朋友们参考。5.1 选型全阶段避坑速查表阶段高频踩坑点应对建议需求定义只谈功能不谈指标和验收标准每个需求必须配一个量化指标和测量方式供应商初筛被算法榜单和Demo效果迷惑重点看行业案例、数据资产、团队背景行业经验验证轻信案例不做细节追问让供应商分模块讲交付细节追问真实参与度POC阶段用供应商数据集测试坚持用企业真实数据越接近生产环境越好商务谈判忽略数据归属与模型权益明确数据和模型的归属和永久使用权合同签订验收标准写死也写虚明确测试集来源、指标口径、未达标的补救措施项目管理只看进度不看过程质量关注供应商实际投入的团队人员是否符合承诺上线运维交付即结束无长期支持约定明确响应分级、重训机制和持续支持范围5.2 判断行业经验的五个实操信号根据我个人的接触经验真正有行业经验的供应商通常会有这些表现可以作为快速判断的信号第一他们对你们行业的系统生态了如指掌。说ERP就能直接聊到具体的数据接口说MES就能提到哪些字段在哪些工位容易出问题这种细节是装不出来的。第二敢主动说这个需求在这类项目中很少见或者这块我们用的方案不是最优解。愿意告诉你局限性的供应商比满嘴都能做的更靠谱。第三他们对你们的数据现状做预判而且预判得比较准。还没进场就能说出哪些数据可能缺、哪些数据质量可能差的人在行业里磨过很久。第四项目方案里有业务规则校验和异常兜底设计。这个特别重要——AI模型必然有预测不准的时候行业经验体现在提前设计好这些不准的情况怎么兜底而不是假装模型永远正确。第五他们能说出竞品方案的真实差别。能做到这一步说明对整个行业的解决方案格局有完整认知而不是只了解自己那一套。5.3 选型结束后企业自己还要做三件事选了靠谱的供应商只是起点企业内部的准备工作同样决定项目成败。第一件事指定内部的项目对接人并且这个对接人要有决策权。我见过太多项目供应商每次开会对着一张张迷茫的脸需求说了半天没人能拍板交付节奏一拖再拖。对接人不一定是AI专家但一定要能协调内部资源。第二件事建立业务方和技术方的周例会机制。AI项目最大的风险是业务方觉得这AI怎么这么蠢技术方觉得业务需求变来变去。固定沟通机制可以早期发现这些预期差。第三件事准备好一块试验田。不要把AI解决方案第一天就铺到全公司先在一个小范围、低风险的业务场景里跑起来验证效果、培养信任积累经验之后再逐步扩大。很多企业的AI项目死掉不是技术不行而是步子迈得太大第一个月就出了问题然后口碑崩了后面再做任何优化都很难拉回信任。我在实际项目里见过太多团队花在选型上的时间和花在落地保障上的时间严重不成比例。其实选型只是万里长征第一步真正决定成败的是后续几个月的磨合深度。但反过来讲如果第一步选错了供应商后面再努力都很难补救因为行业经验这种东西不是给你多加点钱就能临时补齐的。最后分享一个我自己一直坚持的小习惯每轮选型评审结束后我会把入围供应商在清单和会议上说过的关键承诺逐条记录下来等他们正式提交方案时逐条对照看有没有缩水或者悄悄更换口径。这个方法很朴素但实测对防止供应商前后不一致非常有效。项目周期越长越值得有这个习惯。
