构建生成式 AI 应用的常见陷阱

现在用基础模型开发应用还处于早期阶段，犯错是正常的。本文简单列举了一些最常见的陷阱，例子有的来自公开案例，有的来自我个人的亲身经历。

这些陷阱非常普遍，只要做过 AI 产品的人，应该都见过。

1. 不该用生成式 AI 的场景偏要用

每逢新技术出现，我仿佛都能听到资深工程师们集体叹气："不是所有问题都是钉子。"生成式 AI 自然也不例外——它看似无所不能，反而让人更想拿它去解决一切问题。

曾经有个团队向我推荐一个点子：用生成式 AI 优化家庭能耗。他们把家里的高耗电活动清单和每小时电价一起喂给大模型，让它排出一个最省钱的用电时间表。实验结果显示，这样做能让家庭电费降低 30%。白捡的钱，谁不想要呢？

我问他们："和简单地在电价最低的时段运行高耗电活动比起来，效果怎么样？比如晚上 10 点之后再去洗衣服、给车充电。"

他们说之后会试试再告诉我结果，后来也没了下文，这个项目很快就被砍掉了。我估计这个朴素的贪心调度策略效果就不错了。即便效果不好，也有比生成式 AI 更便宜、更可靠的优化方案，比如线性规划。

这类情形我见过太多次了。一家大公司想用生成式 AI 来检测网络流量异常，另一家想预测客服来电量，还有一家医院想用它判断病人是否营养不良（强烈不建议这么做）。

在动手之前先探索一下新方法、摸清能力边界，往往是有益的，但前提是你得清楚自己的目标不是解决问题，而是验证方案。"我们解决了问题"和"我们用上了生成式 AI"，是两个完全不同的标题。可惜很多人更想要后者。

2. 把产品差归咎于 AI 差

另一个极端是，很多团队尝试过生成式 AI 后，因为用户反响很差，就否定了它作为问题解决方案的可行性。然而，另一些团队在类似的用例上却成功运用了生成式 AI。我深入了解过其中两个团队，它们的问题都不出在 AI 本身，而是出在产品上。

不少人跟我说，他们 AI 应用的技术部分反而简单，真正的难点在于用户体验（UX）。产品界面应该怎么设计？如何无缝嵌入用户的工作流？怎样引入人机协同（human-in-the-loop）？

UX 一直是个难题，到了生成式 AI 时代更是如此。我们知道生成式 AI 正在改变阅读、写作、学习、教学、工作、娱乐等诸多方式，但具体怎么变，我们还看不清楚。未来的阅读、学习、工作会是什么样子？

下面举几个简单的例子，说明用户的真实需求往往违反直觉，必须做严谨的用户研究才行。

1. 我有个朋友在做会议转录摘要的应用。起初，她的团队纠结的重点是摘要长度——用户到底更喜欢 3 句的摘要还是 5 句的？
   
   结果发现，用户根本不在乎摘要本身，他们只想要从每场会议中提取出与自己相关的待办事项。

2. 领英在开发一个用于评估技能匹配度的聊天机器人时发现，用户要的不是"正确"的回答，而是"有用"的回答。
   
   比如用户问机器人自己是否适合某个岗位，机器人如果回答"你完全不匹配"，虽然准确，但对用户没什么帮助。用户更想知道差距在哪里，以及怎样去弥补。

3. Intuit 做过一个帮用户解答税务问题的聊天机器人。上线后反馈平平，用户觉得不好用。调研之后才发现，用户其实是讨厌打字——面对一个空白的对话框，他们不知道机器人能做什么，也不知道该输入什么。
   
   于是他们在每次对话时给用户几个推荐问题，让他们直接点击。这一下大大降低了使用门槛，也逐渐建立起用户对机器人的信任，之后的用户反馈就积极多了。
   

（由 Intuit AI 副总裁 Nhung Ho 在 Grace Hopper 我们的圆桌讨论上分享。）

由于大家现在用的都是同一批模型，AI 产品中的 AI 组件大同小异，真正的差异化来自产品本身。

3. 一开始就搞得太复杂

这类陷阱的例子：

1. 直接调 API 就能搞定的事，偏要用智能体框架。
2. 简单基于关键词的检索（不需要向量库）就能解决，却纠结该选哪个向量数据库。
3. 提示词就能解决的事，非要去微调。
4. 使用语义缓存。

面对这么多炫目的新技术，很容易忍不住直接上手。但过早引入外部工具会带来两个问题：

1. 把关键细节封装起来，导致系统难以理解和调试。
2. 引入不必要的 bug。

工具的开发者也会犯错。比如我在审阅某个框架的代码时，经常发现默认提示词里有拼写错误。如果你在用的框架悄悄更新了提示词，应用的输出行为就可能跟着变化，而你却摸不着头脑。

抽象终归是好事，但抽象必须经过实践检验、吸纳最佳实践。AI 工程领域还处于早期，最佳实践本身仍在演进，对任何抽象层都要多留个心眼。

4. 过分看重早期成果

1. LinkedIn 只花了一个月就达到了 80% 的预期效果，却花了额外四个月才突破 95%。早期的成功让他们严重低估了后续打磨产品的难度，尤其是在幻觉问题上。每提升 1 个百分点所需的努力，都让人倍感挫败。

2. 一家为电商开发 AI 销售助手的初创公司告诉我，从 0 到 80% 和从 80% 到 90% 花费的时间一样长。他们遇到的挑战：
   • 准确率与延迟的权衡：越多规划/自我纠错 → 越多节点 → 延迟越高
   • 工具调用：智能体很难区分相似的工具
   • 系统提示词中的语气要求（例如 "用奢侈品品牌礼宾的语气说话"）很难被完美遵守
   • 智能体很难完全理解客户意图
   • 由于查询的组合几乎是无穷的，很难构建一套完整的单元测试

   感谢 Jason Tjahjono 的分享。

3. 在 UltraChat 论文中，Ding 等人（2023） 提到：「从 0 到 60 很容易，但从 60 到 100 却异常艰难。」

这或许是每个快速搭建过 AI 产品的人最先学到的痛苦教训之一。做 demo 容易，做产品很难。除了前文提到的幻觉、延迟、延迟与准确率的权衡、工具调用、提示工程、测试等问题之外，团队还会遇到诸如：

1. 可靠性：来自 API 提供方的问题。有团队告诉我，他们的 API 调用有 10% 会超时；或者底层模型更新后，产品行为发生变化。
2. 合规性：例如 AI 输出版权、数据访问与共享、用户隐私、检索/缓存系统带来的安全风险，以及训练数据来源的不明确。
3. 安全性：例如恶意用户滥用你的产品，或产品生成了不当、冒犯性的回复。

在规划产品里程碑和资源时，务必把这些潜在的障碍纳入考量。一位朋友称之为「谨慎乐观」。但请记住，许多惊艳的 demo 最终并没有变成优秀的产品。

5. 放弃人工评估

为了自动评估 AI 应用，许多团队选择 AI-as-a-judge（也叫 LLM-as-a-judge）方案——用 AI 模型来评估 AI 输出。一个常见的陷阱是彻底放弃人工评估，完全依赖 AI 评判。

AI 评判虽然很有用，但它并非确定性的。评判的质量取决于底层评判模型、评判提示词以及具体场景。如果 AI 评判开发不当，它会给出误导性的评估结果。和所有其他 AI 应用一样，AI 评判也需要被持续评估和迭代优化。

我见过产品做得最好的团队，都在使用人工评估来补充自动化评估。每天，他们都会让人类专家评估其应用输出的一部分，数量从 30 到 1000 条不等。

日常人工评估有三个作用：

1. 将人工评判与 AI 评判进行关联。如果人类评估者的评分在下降，而 AI 评判的评分却在上升，你就应该去检查一下你的 AI 评判器了。
2. 更好地理解用户如何使用你的应用，这能为你改进应用带来灵感。
3. 借助你对时事的了解，发现用户行为中的模式和变化，这是自动化数据分析可能会遗漏的。

人工评估的可靠性同样依赖于精心编写的标注指南。这些标注指南不仅能帮助改进模型的提示词（如果人类都难以遵循这些指令，模型同样做不到），日后如果你选择微调模型，它们还可以直接复用来构造微调数据。

在我参与过的每个项目中，哪怕只是花 15 分钟盯着数据看一看，往往就能获得一些洞察，省下后续数小时的麻烦。Greg Brockman 在推特上说：“在机器学习领域，手动检查数据大概是最具性价比的活动了。”

6. 从众征集用例

这是企业在生成式 AI 热潮初期经常犯的一个错误。许多技术高管无法确定应该聚焦哪些用例，于是就向全公司征集点子。"我们雇的都是聪明人，让他们告诉我们该做什么就好了。"然后就试图把这些想法一个个落地。

于是，我们有了上百万个 text-to-SQL 模型、上百万个 Slack 机器人，以及无数个代码插件。

倾听你雇用的聪明人的意见固然没错，但个人往往会偏向于解决那些直接影响自身日常工作的痛点，而非投资回报最高的问题。如果没有考虑全局的总体战略，很容易被一个个影响有限的小项目牵着走，最终得出"生成式 AI 没有 ROI"的错误结论。

总结

简而言之，常见的 AI 工程陷阱包括：

1. 不需要生成式 AI 时却硬要用
   生成式 AI 并不是万能的万能解药，很多问题根本不需要 AI。

2. 把"产品烂"误判成"AI 烂"
   对许多 AI 产品来说，AI 是容易的部分，产品才是难的部分。

3. 起步就搞得太复杂
   花哨的新框架和微调对很多项目确实有用，但不该是你的首选方案。

4. 过早押注早期成功
   初期的成功可能具有误导性。从 demo 可用走到生产可用，往往比做出第一个 demo 耗时更久。

5. 省掉人工评估
   AI 评审机制必须经过校验，并与系统化的人工评估相互印证。

6. 用例靠众包凑数
   要有全局策略，才能最大化投资回报。