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

标题：构建生成式AI应用时的常见陷阱

原文链接：https://huyenchip.com/2025/01/16/ai-engineering-pitfalls.html

发布日期：2025-01-16T00:00:00+00:00

Markdown 内容： 在我们仍处于使用基础模型构建应用的早期阶段时，犯错误是正常的。这是一篇简短的笔记，列举了一些我见过的最常见的陷阱，这些陷阱既来自公开的案例研究，也来自我的个人经验。

由于这些陷阱很常见，如果你曾参与过任何AI产品，你可能以前就见过它们。

1. 在不需要生成式AI的时候使用生成式AI

每次有新技术出现时，我都能听到所有资深工程师的集体叹息：“不是所有问题都是钉子。”生成式AI也不例外——其看似无限的能力只会加剧将生成式AI用于一切事物的趋势。

有一支团队向我提出了一个想法，即使用生成式AI来优化能源消耗。他们将家庭的高能耗活动列表和每小时电价输入到一个大语言模型中，然后让它创建一个以最小化能源成本为目标的计划。他们的实验表明，这可以将家庭的电费减少30%。这是免费的钱，为什么没有人想用他们的应用呢？

我问：“它与仅仅在电价最便宜的时候安排最耗能的活动相比如何？比如晚上10点后洗衣服和给汽车充电？”

他们说他们会稍后尝试并告诉我。他们从未跟进，但不久之后他们就放弃了这个应用。我怀疑这种贪婪的调度方法可能非常有效。即使不是这样，也有其他比生成式AI更便宜且更可靠的优化解决方案，例如线性规划。

我一再看到这种情况。一家大公司想要用生成式AI检测网络流量中的异常。另一家公司想要预测即将到来的客户电话数量。一家医院想要检测患者是否营养不良（真的不推荐）。

只要意识到你的目标不是解决问题而是测试解决方案，探索一种新方法通常是有益的。“我们解决了问题”和“我们使用了生成式AI”是两个截然不同的标题，不幸的是，很多人更喜欢后者。

2. 将“糟糕的产品”误认为是“糟糕的AI”

在另一个极端，许多团队因为尝试过生成式AI后用户不喜欢而将其视为无效的解决方案。然而，其他团队成功地将生成式AI用于类似的应用场景。我只能查看其中两家团队。在这两种情况下，问题都不是出在AI上，而是出在产品上。

许多人告诉我，他们AI应用的技术方面很简单。困难的部分是用户体验（UX）。产品界面应该是什么样子？如何无缝地将产品集成到用户的流程中？如何引入人工参与？

UX一直是一个挑战，但与生成式AI结合时更是如此。虽然我们知道生成式AI正在改变我们阅读、写作、学习、教学、工作、娱乐等方式，但我们还不清楚具体会怎样。未来的阅读/学习/工作方式会是什么样？

这里有一些简单的例子，说明用户的需求可能出乎意料，并需要严格的用户研究。

1. 我的朋友开发了一个会议记录摘要的应用程序。最初，她的团队专注于获得正确的摘要长度。用户是更喜欢3句话的摘要还是5句话的摘要？

然而，结果发现，他们的用户并不关心实际的摘要。他们只希望从每次会议中得到特定于自己的行动项。

1. 当LinkedIn开发一个用于技能匹配评估的聊天机器人时，他们发现用户并不想要正确答案。用户想要的是有帮助的答案。

例如，如果用户问机器人是否适合一份工作，而机器人回答：“你完全不适合这份工作”，这个回答可能是正确的，但对用户来说并没有多大的帮助。用户希望了解差距在哪里以及他们可以采取什么措施来弥补这些差距。

1. Intuit开发了一个聊天机器人来帮助用户回答税务问题。起初，他们得到了冷淡的反馈——用户觉得这个机器人没有用。经过调查，他们发现用户实际上讨厌打字。面对一个空白的聊天机器人，用户不知道机器人能做什么，也不知道该输入什么。

因此，Intuit为每次互动添加了几条建议的问题供用户点击。这减少了用户使用机器人的障碍，并逐渐建立了用户的信任。随后，用户的反馈变得积极得多。

_(由Intuit的AI副总裁Nhung Ho在Grace Hopper的小组讨论中分享。)_

因为现在每个人都使用相同的模型，AI产品的AI组件相似，差异化在于产品。

3. 太复杂地开始

这种陷阱的例子包括：

1. 在直接API调用可行的情况下使用代理框架。
2. 在一个简单的基于术语的检索解决方案（不需要向量数据库）可行的情况下，纠结于选择哪个向量数据库。
3. 坚持微调，而提示就能解决问题。
4. 使用语义缓存。

鉴于众多新颖的新技术，很容易直接跳入使用它们。然而，过早地引入外部工具会导致两个问题：

1. 抽象掉关键细节，使理解和调试系统变得困难。
2. 引入不必要的错误。

工具开发者也可能犯错。例如，当我审查一个框架的代码库时，经常发现默认提示中有拼写错误。如果所使用的框架更新了提示而没有通知你，那么你应用程序的行为可能会发生变化，而你却不知道原因。

最终，抽象是有益的。但抽象需要融入最佳实践，并经过时间的考验。由于我们仍处于AI工程的早期阶段，最佳实践仍在不断演变，因此在采用任何抽象时，我们应该更加谨慎。

4. 过度关注早期成功

1. LinkedIn 花了1个月时间实现了他们想要的80%体验，又用了额外4个月才超过95%。最初的成果让他们严重低估了改进产品有多困难，尤其是在幻觉方面。他们发现每次提升1%都极其困难。

1. 一家为电商开发AI销售助手的初创公司告诉我，从0到80%所花的时间和从80%到90%一样长。他们遇到的挑战包括：

• 准确性/延迟权衡：更多的规划/自我纠正 = 更多节点 = 更高的延迟
• 工具调用：代理很难区分相似的工具
• 系统提示中对语气请求（例如：“像奢侈品牌礼宾一样说话”）难以完全遵守
• 代理很难完全理解客户意图
• 难以创建一组特定的单元测试，因为查询的组合几乎是无限的

_感谢 Jason Tjahjono 分享。_

1. 在论文 UltraChat 中，Ding 等人 (2023) 提到：“从0到60很容易，而从60到100则变得极其困难。”

这可能是任何构建AI产品的人都会迅速学到的最痛苦的教训之一。构建一个演示很简单，但构建一个产品却很困难。除了幻觉、延迟、延迟/准确性权衡、工具使用、提示、测试等问题外，团队还会遇到其他问题，例如：

1. API提供方的可靠性。有团队告诉我，他们10%的API调用超时了。或者因为底层模型发生变化，产品行为也发生了变化。
2. 合规性，例如AI输出版权、数据访问/共享、用户隐私、检索/缓存系统的安全风险，以及训练数据来源的模糊性。
3. 安全性，例如坏人滥用你的产品，你的产品生成不敏感或冒犯性的回应。

在规划产品的里程碑和资源时，务必考虑到这些潜在的障碍。一位朋友称之为“谨慎乐观”。然而，请记住，许多酷炫的演示并不一定带来出色的产品。

5. 忽略人工评估

为了自动评估AI应用，许多团队选择使用“AI作为评判者”（也称为“LLM作为评判者”）的方法——使用AI模型来评估AI输出。一个常见的误区是忽略人工评估，完全依赖AI评判者。

虽然AI评判者非常有用，但它们并不是确定性的。评判者的质量取决于底层评判者的模型、评判者的提示以及使用场景。如果AI评判者没有正确开发，它可能会对你的应用表现给出误导性的评估。AI评判者必须随着时间的推移进行评估和迭代，就像所有其他AI应用一样。

我见过的拥有最佳产品的团队都有人工评估来补充他们的自动化评估。每天，他们都会让人类专家评估其应用输出的一小部分，数量可能在30到1000个例子之间。

每日手动评估有三个目的：

1. 将人工判断与AI判断相关联。如果人工评估者的评分下降，而AI评判者的评分上升，你可能需要调查你的AI评判者。
2. 更好地了解用户如何使用你的应用，这可以给你改进应用的想法。
3. 检测用户行为中的模式和变化，利用你对当前事件的了解，这可能是自动化数据探索所无法察觉的。

人工评估的可靠性还取决于精心设计的标注指南。这些标注指南可以帮助改进模型的指令（如果人类难以遵循指令，模型也会如此）。如果你决定进行微调，这些指南也可以用于以后创建微调数据。

在我参与的每个项目中，_仅仅盯着数据15分钟通常就能给我一些见解，这能节省我数小时的头痛。_ Greg Brockman 推文说：“_手动检查数据可能是机器学习中价值与声望比率最高的活动。_”

6. 外包使用案例

这是我早期看到企业在狂热地采用生成式AI时的一个错误。由于无法想出一个明确的战略来聚焦哪些使用案例，许多科技高管将想法从整个公司中外包。“我们雇佣了聪明的人，让他们告诉我们该做什么。”然后他们尝试逐一实现这些想法。

就这样，我们最终拥有了百万个文本到SQL模型、百万个Slack机器人和十亿个代码插件。

虽然听取你雇佣的聪明人的意见确实是个好主意，但个人可能更倾向于那些直接影响他们日常工作的的问题，而不是那些可能带来最高投资回报率的问题。如果没有一个考虑大局的整体战略，就很容易被带入一系列小而低影响的应用程序，并得出生成式AI没有投资回报的错误结论。

总结

简而言之，这里是一些常见的AI工程陷阱：

1. 在不需要生成式AI的时候使用生成式AI

生成式AI并不是解决所有问题的万能方案。许多问题甚至根本不需要AI。

1. 将“糟糕的产品”与“糟糕的AI”混淆

对于许多AI产品来说，AI本身是容易的部分，产品设计才是困难的部分。

1. 起步过于复杂

虽然花哨的新框架和微调对于许多项目可能有用，但它们不应该成为你的首选方案。

1. 过度关注早期成功

初期的成功可能会产生误导。从演示可用到生产可用可能需要比达到第一个演示更长的时间。

1. 忽略人工评估

AI的评判标准应该经过验证，并与系统化的人工评估相关联。

1. 众包使用场景

制定一个全局策略，以最大化投资回报。