技术负责人的 AI 决策——不能只看 Demo
技术负责人的 AI 决策——不能只看 Demo
适读人群：技术 Leader、CTO、有技术决策权的工程师 | 阅读时长：约13分钟 | 核心价值：建立 AI 产品和 AI 方案的技术评估框架，避免被 Demo 打动后的决策失误
两年前，我们公司买了一套 AI 客服系统。
Demo 看起来非常厉害——自然语言理解准确，回答专业，响应快，界面也好看。产品经理看完 Demo 当场拍板，技术 Leader 觉得没问题，我当时也没提出异议。合同签了，三个月后开始集成。
集成的第一周就出了问题。
那套系统在 Demo 环境里跑的是供应商精心准备的知识库，知识库里只有几百条高质量 FAQ。而我们的真实业务有几千条产品 SKU，知识结构复杂，用户问题的长尾分布很宽。真实环境下，这套系统的准确率跌到了 Demo 的一半都不到。
更麻烦的是，当我们提出"我们需要自定义知识库"的时候，供应商说可以，但需要额外付费，而且操作界面复杂到我们自己的运营没法维护。
最终那套系统只用了五个月，就被废弃了，换成了我们自己基于 RAG 搭的方案。
那次失误的学费，大概是 30 万。
事后我复盘，问题不在于供应商骗了我们，他们的系统本身是真实的。问题在于我们在 Demo 阶段问错了问题——我们在问"它能做什么"，但应该问的是"它在我们的条件下能做什么"。
Demo 天然有欺骗性
这不是在说供应商坏，这是 Demo 这种形式本身的局限。
任何 Demo 都是在最优条件下运行的：
- 精心挑选的测试数据
- 预先调好的参数
- 适合展示的问题类型
- 不会触发边界情况的流程
Demo 展示的是系统的上限，而你的生产环境面对的是系统的均值。
AI 系统的这个 gap 尤其大，因为 AI 的性能对数据分布极其敏感。训练数据或者 few-shot 示例如果和你的真实数据分布不一样，效果可能差一大截。
技术决策的三个常见失误
在我见过的 AI 技术决策里，有三类失误反复出现。
失误一：高估 Demo 效果的迁移性
就是上面说的那种情况。Demo 效果好，但没有验证在你的数据上的效果。
更隐蔽的版本是：在你的测试数据上效果也好，但测试数据是你精心准备的，而真实用户的问题千奇百怪。一个典型的例子是意图识别：你测了 100 个标准问法，准确率 92%。但真实用户问"我的那个东西怎么还没发"，这种问法可能就出了识别范围。
失误二：忽视生产成本
AI 的 Demo 成本和生产成本往往差距巨大。
GPT-4o 的 API 调用，在 Demo 里看不出问题，一天就用了几十次。但生产里每天几万次调用，成本计算完，商业模型就算不过来了。
更典型的是延迟问题。Demo 里等三秒是可以的，用户接受，觉得这是 AI 在"思考"。但生产里，如果一个功能每次都要等三秒，用户的使用习惯很快就会改变，甚至放弃使用。
失误三：没有问集成代价
AI 产品通常有一个"看起来能用，实际上很难集成"的问题。
API 文档是否完整？认证方式是否和你们的系统兼容？数据格式转换的代价多大？如果系统有问题，排查路径是什么？这些问题，在 Demo 阶段完全看不出来，但会在集成阶段全部爆发。
技术决策前要问的清单
我整理了一个清单，不是 checklist 那种走形式的东西，是每个问题都有具体含义的。
关于数据适配性
- 你们的数据分布和供应商的训练/测试数据有多大差异？
- 能不能用你们自己的数据（哪怕是小规模）做一个快速验证？
- 系统对输入数据的质量要求是什么？（长度、格式、语言）
- 当输入超出系统预期范围时，它怎么处理？
关于效果的可量化性
- 核心指标是什么？如何测量？
- 有没有和你们业务相关的基准（benchmark）？如果没有，怎么建立？
- 效果下降时，如何发现和诊断？
- 人工兜底的机制是什么？
关于生产成本
- 在你预期的 QPS/日调用量下，月成本大概是多少？
- 延迟的 P95/P99 是多少？在负载增加时，延迟如何变化？
- 系统的降级策略是什么？（模型服务不可用时怎么办）
- 数据需要上传到供应商服务器吗？合规风险如何评估？
关于集成和维护
- 需要多少工程投入才能跑起来？（man-day 估计）
- 知识库/模型的更新流程是什么？运营团队能自己操作吗？
- 出了问题，排查路径是什么？供应商的 SLA 是什么？
- 如果以后要换掉这个方案，迁移代价多大？
关于团队能力
- 团队有没有人能维护和迭代这套系统？
- 如果供应商不再更新或者倒闭，我们能接管吗？
- 团队理解这套系统的工作原理吗？（黑盒还是能 debug）
这 19 个问题，不是要你全部找到完美答案，而是让这些问题的答案显化，帮你判断决策的代价。
一个反直觉的建议：先跑最难的情况
大部分技术评估都是先跑 happy path——最简单的情况，标准的输入，预期的输出。
我建议倒过来：先跑你最担心的情况。
最担心什么？
- 你知道用户会问的那类"奇怪问题"
- 你的数据里质量最差的那部分
- 你的业务里最复杂的那个场景
- 系统压力最大时（高并发）
如果这些情况都能过，happy path 基本不用担心。如果这些情况跑不好，早知道早放弃，比集成三个月后发现要好太多。
这个原则叫"最坏情况优先测试"，听起来很反直觉，但在 AI 系统评估里格外有效，因为 AI 系统在边界情况上的表现，往往和它在标准情况下的表现完全不是同一个水平。
关于 Agent 和"自动化程度"的特别提醒
最近两年，很多 AI 产品的卖点是"自动化"——AI 自动完成某某任务，不需要人工干预。
这类产品在 Demo 里非常好看，因为 Demo 里的任务都是设计过的。
技术决策时，对这类产品要多一个额外的问题：当 AI 出错时，人工干预的入口在哪里？
自动化程度越高，出错的代价往往越大，因为没有人在中间拦截。如果一套 AI 系统能自动发邮件、自动修改配置、自动执行某些操作，那么它的错误恢复机制必须是你技术评估的核心。
我见过一个案例：某公司用 AI Agent 自动处理退款申请，Demo 阶段准确率 95%。生产上线后，有 5% 的误判，这些误判的退款已经打出去了，无法追回。5% 的错误率听起来很低，但乘以每天的处理量，这是真实的资金损失。
高自动化 = 高风险的入口，不是高自动化 = 可以放心。
一个具体的评估流程
把上面的思路整合成一个实际可操作的流程：
阶段一：数据验证（1-2 周）
用你自己的真实数据（或者接近真实的数据）跑一遍核心场景。不需要完整的测试集，50-100 个有代表性的案例足够发现大问题。
阶段二：成本估算（2-3 天）
按照你的预期使用量，算出月成本。包括：API 费用、延迟带来的用户体验成本、运维人力成本。
阶段三：集成 POC（1-2 周）
让工程师做一个最小化的集成，不需要完整功能，只需要跑通核心路径，验证集成代价是否在预期范围内。
阶段四：决策
基于以上三个阶段的结论，做带数据支撑的决策。不是"感觉可以"，是"测试结果 X，成本 Y，集成工期 Z，风险点 W"。
最后说一句：我没有说 AI 产品都不好，也没有说自研一定比买好。我说的是：决策要基于你自己业务场景下的验证，不能基于供应商给你看的 Demo。
Demo 是用来激发想象力的，验证是用来做决策的。这两者不能混。