FDE Times 数据在招 FDE 职位 838▼55 近 7 天在招职位数的变化(同口径比较):不计入本周新开始追踪的公司的职位近 7 天新增 66在招公司 169支持远程 24%美国薪资中位数 $200k招聘最多 Palantir 95
ENVI

前线部署工程师(FDE)的专业媒体

技能指南 · 指南

AI 试点何时叫停,开工前就要说定

企业平均放弃 46% 的 AI 概念验证,症结常在于没人事先写明“好”的标准。

分享微博

要点速览

  • 叫停试点很正常:S&P Global 发现,企业平均有 46% 的 AI 概念验证在进入生产环境前被放弃。
  • 结果阈值和应对规则必须在第一天定下;错误评分细则要等读过真实日志后再写。
  • 换模型之前,先数清有多少错误其实来自数据、产品或工作流。
堆叠条形图把第 60 天的 52 个错误回答分成三部分:31 个因缺少运单号(突出显示),14 个因价目表过时,7 个来自模型。强制填写运单号可让准确率从 74% 升至 89.5%;换用更强的模型最多只能修复 7 个错误。
第 60 天,大部分错误源于一个可修复的瓶颈,而不是模型,因此决策是修复。来源:文中的假设试点案例(回答发票问题的 Agent,在 200 个真实问题上测试)。

试点进行到第六周,你正和客户开会。Agent 大约能答对四分之三的问题。运营负责人问:“那这算好还是不好?”没人接话,因为从来没人写下多少才算“好”。

这种场景比想象中常见。S&P Global Market Intelligence 的一项调查发现,企业平均有 46% 的 AI 概念验证(PoC)在进入生产环境前被放弃。放弃大部分 AI 项目的公司占比,一年之内从 17% 跃升至 42%。

所以,前线部署工程师(FDE)要问的不是如何确保试点永不失败,而是:当结果不达标时,下一步是否已经确定、清晰,并且双方都签了字?能把试点做好的人和只擅长演示的人,差别就在这项能力。

试点失败,不只因为质量不够,更因为缺少定义

SoftwareSeni 的一份实操指南说得很直白:试点之所以常常卡住,是因为开始之前没人商定“能用”是什么意思。没有定义,各方对 75% 这个数字就各有解读。工程团队看到进展,财务看到风险,项目发起人看到的是疲惫。

Gartner 曾预测,到 2025 年底,至少 30% 的生成式 AI 项目会在概念验证后被放弃,并给出四个原因:数据质量差、风险控制不足、成本攀升,以及商业价值不明确。

最后一条完全在你掌控之中。价值之所以“不明确”,只是因为没人写下该如何衡量它。

Anthropic 关于模型评测的官方文档阐明了基本原则:用具体、可衡量的指标取代“表现良好”,并在构建评测之前就把指标定下来。

同一份文档也提醒,目标不应超出模型当前的能力。基准测试只能达到 85% 的任务,却定下 99% 的阈值,等于提前写好了失败报告。

第一天定什么,什么留到后面?

很多人在这里出错。曾在 Airbnb 和 GitHub 工作的评测专家 Hamel Husain 提醒,没看数据就写评分细则是非常常见的错误。他认为,必须先分析日志,弄清实际会出现哪些错误,然后再建评测。

这两条建议并不矛盾。第一天定下的是业务结果指标、阈值和应对规则;针对每类错误的详细评分细则,要等头几周读过真实日志后再写。

应对规则是最常被遗忘的部分。SoftwareSeni 建议,在记分卡发出失败信号之前,就商定如何应对,并把方向调整分为两类。

修复(revive),指保留现有方案,修好一个可解决的瓶颈。重构(restructure),指重新设计方案。第 90 天的最终决策则刻意设计成只有两个可能的答案:扩大规模,或者停止。

第一天的记分卡长什么样?

设想一个假设的试点:为一家物流公司的客服团队开发一个回答发票问题的 Agent。写第一行代码之前,你和客服负责人签下这样一页记分卡。

检查点 要回答的问题 商定的阈值与行动
第 30 天 真实错误是什么样? 至少读 100 条日志,给错误归类,据此编写评分细则
第 60 天 进展是否正常? 正确率 85% 及以上:准备扩大规模。70–85% 且错误集中于一个可修复的原因:修复。低于 70%,或错误分散且由工作流导致:重构或停止
第 90 天 扩大还是停止? 只有两个选项;签字决策的人在第一天就已指定

这里的 85% 和 70% 只是示意。实际中,应根据一次小规模的初步实验和员工手工处理的当前效率来设定,这也符合 Anthropic 所强调的“可实现”目标。

现在到了第 60 天。在 200 个真实问题上,Agent 答对 148 个,即 74%,落在中间档。谁都不能急着下结论。你打开 52 个错误回答,逐一打标签。

结果是:31 个错误是因为提问者没有提供运单号,Agent 查不到正确的发票;14 个错误来自 Agent 查阅了一份没更新的旧价目表;只有 7 个是模型在数据齐全的情况下推理出错。

这正是 Husain 所描述的那类失败:用户的问题太模糊、缺少足够的上下文,模型根本没有机会答对。

如果增加一个必填的运单号字段能修复这 31 个错误,准确率可升至 200 题中答对 179 题,即 89.5%。

相比之下,换用更强的模型,最多只能修复 7 个错误。

按照签好的规则,决策是修复:保留现有方案,修好一个具体的瓶颈。于是,第 60 天的会议只开了十五分钟,因为没人需要再争论“好”是什么意思。

什么时候该重新设计,而不是打补丁?

假设标签呈现的是另一番景象:错误分布均匀,客服人员不用这个 Agent,因为它不在他们日常使用的工具里。这就是该重构的信号。MIT NANDA 的报告“The GenAI Divide”认为,通用工具在企业中屡屡受挫,是因为它们不会从真实工作流中学习,也不会去适应。

该报告给出的企业 AI 解决方案失败率为 95%,但样本相当小,这个数字只宜作为参考。

值得记住的是它的诊断:根本原因在于与工作流的集成存在缺口,而不在模型质量。在这个案例里,重构意味着把 Agent 直接放进员工本来就用来干活的那个界面。

同一份报告还发现,自建解决方案的成功率只有向专业厂商采购或通过合作构建方案的三分之一。所以重构时,即便写代码的人就是你,也要认真考虑买而不是建。

毁掉好决策的几个错误

第一个错误是过早打分。Gartner 的 Rita Sallam 指出,生成式 AI 的影响往往不会立刻显现,而是随时间逐步体现。如果主指标是整个团队的处理时长,就不要在第二周、员工还在学用工具时去测量。

第二个错误是条件反射式地换模型。如示例所示,大部分错误可能出在一个输入表单或一份价目表上,而任何模型都修不好过时的数据。打开模型对比页面之前,先数一数错误标签。

第三个错误是让试点无限期拖下去。没有第 90 天检查点的试点,很容易变成没完没了的“再延一个月”。它会慢慢耗掉成本,而 S&P Global 把成本与数据隐私、安全并列为最主要的障碍。

把这项能力变成职业优势

简历上不要只写“为客户部署了一个 Agent”。要写清楚你如何设定记分卡、读了多少条日志、依据哪些数字在修复和停止之间做出选择。

招聘方读到这些,会看出你懂得把试点推向明确的结论,而不是止步于演示。

本周练习:挑一个你参与过的试点,哪怕已经结束,重写它从第一天就该有的记分卡。如果你写不出它第 60 天的阈值,就明白那次会议为什么会冷场了。

这篇文章对你有帮助吗?

8 个信源
路线图上的下一篇 · 阶段 7: 项目主导两句话,让 FDE 招聘方相信你真正交付过招聘方要看部署在别人基础设施上的代码,罗列工具说明不了,系统、约束和实测结果才能。