由于我们仍处于使用基础模型构建应用程序的早期阶段，因此犯错是正常的。这是一篇简短的说明，其中列举了一些我见过的最常见的陷阱，这些陷阱既来自公开案例研究，也来自我的个人经历。
由于这些陷阱很常见，所以如果您曾经开发过任何 AI 产品，那么您可能以前就见过它们。
每当有新技术出现时，我都能听到各地高级工程师的集体感叹：“不是所有的东西都是钉子。”生成式人工智能也不例外——它看似无限的能力只会加剧将生成式人工智能用于一切的趋势。
一个团队向我提出了使用生成式人工智能来优化能源消耗的想法。他们将一个家庭的能源密集型活动清单和每小时电价输入到 LLM 中，然后要求它创建一个时间表以最大限度地降低能源成本。他们的实验表明，这可以帮助家庭减少 30% 的电费。免费的钱。为什么没有人想使用他们的应用程序？
我问道：“这与简单地将最耗能的活动安排在电价最便宜的时候相比如何？比如，晚上 10 点后洗衣服和给汽车充电？”
他们说他们稍后会尝试一下并告诉我。他们没有跟进，但不久后就放弃了这个应用程序。我怀疑这种贪婪调度可能非常有效。即使不是，也有比生成式人工智能更便宜、更可靠的其他优化解决方案，比如线性规划。
我已经多次见过这种场景。一家大公司希望使用生成式人工智能来检测网络流量中的异常。另一家公司希望预测即将到来的客户呼叫量。一家医院希望检测患者是否营养不良（真的不推荐）。
只要你意识到你的目标不是解决问题而是测试解决方案，探索新方法以了解可能性通常是有益的。“我们解决问题”和“我们使用生成式人工智能”是两个截然不同的标题，不幸的是，很多人宁愿选择后者。
2. 将“劣质产品”与“劣质人工智能”混为一谈
另一方面，许多团队认为 gen AI 不是解决他们问题的有效方法，因为他们尝试过，但用户不喜欢。然而，其他团队成功地将 gen AI 用于类似的用例。我只能调查其中两个团队。在这两个案例中，问题都不出在 AI 上，而是出在产品上。
许多人告诉我，他们的 AI 应用的技术方面很简单。难点在于用户体验 (UX)。产品界面应该是什么样的？如何将产品无缝集成到用户工作流程中？如何将人机交互纳入其中？
用户体验一直都具有挑战性，而生成式人工智能则更具挑战性。虽然我们知道生成式人工智能正在改变我们阅读、写作、学习、教学、工作、娱乐等方式，但我们还不太清楚具体如何改变。阅读/学习/工作的未来会是什么样的？
这里有一些简单的例子来说明用户想要的东西可能是违反直觉的，并且需要严格的用户研究。
-
我的朋友开发了一款总结会议记录的应用程序。最初，她的团队专注于获得合适的摘要长度。用户更喜欢 3 句摘要还是 5 句摘要？
然而，事实证明，他们的用户并不关心实际的摘要。他们只想要每次会议中针对他们的具体行动项目。
-
当LinkedIn开发用于技能匹配度评估的聊天机器人时，他们发现用户并不想要正确的答案。用户想要有帮助的答案。
例如，如果用户询问机器人他们是否适合某份工作，而机器人回答说：“你不适合”，这个回答可能是正确的，但对用户来说没有多大帮助。用户想要知道差距在哪里，以及他们可以做些什么来弥补差距。
-
Intuit 开发了一个聊天机器人来帮助用户回答税务问题。最初，他们得到的反馈并不热烈——用户认为这个机器人没什么用。经过调查，他们发现用户实际上讨厌打字。面对一个空白的聊天机器人，用户不知道机器人能做什么，也不知道该输入什么。
因此，对于每次互动，Intuit 都会添加一些建议问题供用户点击。这减少了用户使用机器人的摩擦，并逐渐建立了用户的信任。用户的反馈也变得更加积极。 （Intuit 人工智能副总裁_Nhung Ho_在 Grace Hopper 的座谈会上
分享。）
因为现在大家都用同样的模型，所以AI产品的AI组件都是相似的，差异化的就是产品。
3. 一开始就太复杂
这种陷阱的例子：
- 当直接 API 调用有效时使用代理框架。
- 当一个简单的基于术语的检索解决方案（不需要 vectordb）工作时，苦恼于使用什么向量数据库。
- 提示作品时坚持微调。
- 使用语义缓存。
鉴于有这么多闪亮的新技术，人们很容易直接使用它们。然而，过早引入外部工具可能会导致两个问题：
- 抽象出关键细节，使得系统更难理解和调试。
- 引入不必要的错误。
工具开发人员可能会犯错。例如，我在检查框架的代码库时经常发现默认提示中有拼写错误。如果您使用的框架在未通知您的情况下更新了其提示，则您的应用程序的行为可能会发生变化，而您可能不知道原因。
最终，抽象是好的。但抽象需要融入最佳实践并经过长时间的测试。由于我们仍处于人工智能工程的早期阶段，最佳实践仍在不断发展，我们在采用任何抽象时都应该更加警惕。
4. 过度关注早期的成功
-
LinkedIn 用了_1 个月的时间实现了他们想要的 80% 的体验，又用了 4 个月的时间才超过 95%_。最初的成功让他们严重低估了改进产品的难度，尤其是在幻觉方面。他们发现，每次实现 1% 的收益都非常困难，这让他们感到沮丧。
-
一家为电子商务开发 AI 销售助理的初创公司告诉我，从 0 到 80% 所花的时间与从 80% 到 90% 所花的时间一样长。他们面临的挑战是：
-
准确度/延迟权衡：更多规划/自我校正 = 更多节点 = 更高延迟
-
工具调用：代理难以区分类似的工具
-
很难
"talk like a luxury brand concierge"完全遵守系统提示中的音调请求（例如 -
客服人员很难完全理解客户的意图
-
很难创建一组特定的单元测试，因为查询的组合基本上是无限的
-
-
在论文 UltraChat 中，Ding 等人 (2023)分享道：“从 0 到 60 的旅程很容易，而从 60 到 100 的进步却极具挑战性。”
这也许是任何开发过 AI 产品的人很快学到的第一个痛苦教训。开发一个演示很容易，但开发一个产品却很难。除了幻觉、延迟、延迟/准确性权衡、工具使用、提示、测试等问题之外，团队还会遇到以下问题：
- API 提供商的可靠性。一个团队告诉我，他们的 10% 的 API 调用超时了。或者产品的行为会因为底层模型的改变而改变。
- 合规性，例如围绕人工智能输出版权、数据访问/共享、用户隐私、检索/缓存系统的安全风险以及围绕训练数据谱系的模糊性。
- 安全性，例如不良行为者滥用您的产品，您的产品会产生不敏感或冒犯性的反应。
在规划产品的里程碑和资源时，一定要考虑到这些潜在的障碍。一位朋友称此为“谨慎乐观”。但是，请记住，许多酷炫的演示并不能带来出色的产品。
5. 放弃人工评估
为了自动评估 AI 应用程序，许多团队选择 AI 作为评判者（也称为 LLM 作为评判者）的方法——使用 AI 模型来评估 AI 输出。一个常见的陷阱是放弃人工评估，完全依赖 AI 评判者。
虽然 AI 评判器非常有用，但它们并不是确定性的。评判器的质量取决于底层评判器的模型、评判器的提示和用例。如果 AI 评判器开发不当，它可能会对您的应用程序的性能做出误导性评估。AI 评判器必须随着时间的推移进行评估和迭代，就像所有其他 AI 应用程序一样。
我见过的拥有最佳产品的团队都使用人工评估来补充他们的自动评估。他们每天都会让人类专家评估其应用程序输出的一部分，这些输出可以是 30 到 1000 个示例。
每日人工评估有三个目的：
- 将人类判断与人工智能判断联系起来。如果人类评估员的评分在下降，但人工智能评委的评分在上升，你可能需要调查你的人工智能评委。
- 更好地了解用户如何使用您的应用程序，这可以为您提供改进应用程序的想法。
- 利用您对当前事件的了解，检测自动数据探索可能会遗漏的用户行为模式和变化。
人工评估的可靠性还取决于精心设计的注释指南。这些注释指南可以帮助改进模型的指令（如果人类很难遵循指令，模型也会如此）。如果您选择微调，它还可以重复使用以创建微调数据。
在我从事过的每个项目中，只需花 15 分钟盯着数据，通常就能获得一些见解，从而省去数小时的头痛。Greg Brockman在推特上写道：“在机器学习的所有活动中，手动检查数据可能是价值与声望比最高的。 ”
6. 众包用例
这是我在早期企业疯狂采用生成式人工智能时看到的一个错误。由于无法制定出关注用例的策略，许多技术高管只能从整个公司众包想法。“我们雇佣聪明人。让他们告诉我们该做什么。”然后他们尝试逐一实施这些想法。
这就是我们最终拥有一百万个文本到 SQL 模型、一百万个 Slack 机器人和十亿个代码插件的方式。
虽然听取你雇佣的聪明人的意见确实是个好主意，但个人可能会偏向于那些直接影响他们日常工作的问题，而不是那些可能带来最高投资回报的问题。如果没有一个考虑大局的总体战略，就很容易被一系列小的、影响不大的应用所吸引，并得出错误的结论，认为新一代人工智能没有投资回报。
概括
简而言之，以下是常见的人工智能工程陷阱：
-
在不需要生成式 AI 时使用生成式 AI
生成式 AI 并不是解决所有问题的万能方案。许多问题甚至不需要 AI。 -
将“糟糕的产品”与“糟糕的人工智能”混淆
对于许多人工智能产品而言，人工智能是简单的部分，产品才是困难的部分。 -
开始太复杂
虽然新奇的框架和微调对许多项目都有用，但它们不应该是你的第一步行动。 -
过度关注早期的成功
最初的成功可能会产生误导。从演示到生产准备可能比第一次演示花费的时间更长。 -
放弃人类评估
人工智能评判应该经过验证并与系统的人类评估相关联。 -
众包用例
拥有一个宏观战略来最大化投资回报。
