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

✍️ zhirenhun 📅 2026/5/26 👁 70 阅读 ⏱ 14 分钟

警惕！构建生成式AI应用时最容易踩的10大“坑”

2025年1月16日 • Chip Huyen

由于我们仍在基础模型（foundation models）应用构建的早期阶段，犯错是完全正常的。这是一篇简短的笔记，分享了一些我从公开案例研究和个人经验中观察到的最常见的陷阱。

因为这些“坑”如此普遍，如果你参与过任何AI产品开发，你很可能已经见过它们了。

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

每当出现一项新技术时，我都能听到资深工程师们发出的集体叹息：“并非所有事情都需要钉子（即：并非所有问题都适合用生成式AI解决）。”生成式AI也不例外——它看似无限的能力，只会加剧我们倾向于将它用于所有场景的趋势。

有一次，一个团队向我推销了一个使用生成式AI来优化能源消耗的方案。他们将一个家庭的能源密集型活动列表和每小时的电价输入到一个 LLM 中，然后要求它创建一个能最小化能源成本的调度计划。他们的实验显示，这可以帮助一个家庭将电费账单降低 30%。这简直是白送的钱。为什么没人想用他们的应用呢？

我问道：“这和简单地在电价最低时安排最耗能的活动（比如晚上10点后洗衣服和给汽车充电）相比，效果如何？”

他们说稍后会尝试并告诉我结果。他们从未跟进，但在应用上线后不久就放弃了。我怀疑这种“贪婪调度”（greedy scheduling）的效率其实很高。即使它不是最优解，与生成式AI相比，还有其他更便宜、更可靠的优化方案，比如线性规划（linear programming）。

我一次又一次地看到了这种情况。一家大公司想用生成式AI来检测网络流量中的异常（anomalies）；另一家公司想预测即将到来的客户呼叫量；一家医院想检测患者是否营养不良（这其实并不推荐）。

虽然探索新方法来了解可能性往往是有益的，但前提是你必须清楚地认识到：你的目标不是“解决问题”，而是“测试解决方案”。“我们解决了问题”和“我们使用了生成式AI”是两个截然不同的标题，而不幸的是，太多人宁愿选择后者。

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

在光谱的另一端，许多团队因为尝试了生成式AI并收到了用户的负面反馈，就直接将 GenAI 视为一个无效的解决方案而将其抛弃了。然而，其他团队却成功地将 GenAI 应用于相似的用例中。我深入研究了其中两个团队。在这两个案例中，问题根本不在于 AI 本身，而在于产品（Product）。

很多人告诉我，他们 AI 应用的技术层面是直截了当的。真正困难的部分在于用户体验（UX）。产品界面应该是什么样子？如何将产品无缝地融入用户工作流程？如何融入“人在回路”（human-in-the-loop）的机制？

UX 一直是一个挑战，但对于 AI 应用来说，由于其固有的非确定性（nondeterminism），挑战更大。当你无法保证输出质量时，如何创造出愉悦的用户体验？如何设定用户预期，让他们信任系统，但又知道何时需要进行验证？

一个流行的方法是把 AI 放在一个按钮后面。用户点击按钮，AI 随后生成一个响应。用户可以决定是否采纳这个输出。这是一个很好的起点。

一个优秀的产品可以弥补 AI 的不足。要让生成式AI产品取得成功，往往不在于拥有最好的模型，而在于拥有最周到的产品设计。

一个系统不一定需要达到 100% 的准确率才能有用。如果它 20% 的时间会失败，但在每次成功运行时都能为用户节省一小时，那么它仍然是净正向的，前提是用户可以在不花费太多时间的情况下验证输出。你能为多少种常见的失败模式进行规划，用户体验就会越好。

3. 解决基准测试（Benchmark）而非解决实际问题

许多团队主要使用 MMLU、HumanEval 或 HELM 等公开基准测试来评估他们的 AI 应用。如果他们的模型在基准测试中表现良好，他们就假设它在生产环境中也会表现出色。但这种情况很少发生。

公开基准测试无法捕捉到你特定用例的精确需求。一个在通用知识问答（QA）中表现出色的模型，在特定领域的任务上可能会失败。一个在代码生成基准测试中表现出色的模型，可能会生成无法与你的特定技术栈（stack）编译的代码。

正确的做法是构建你自己的评估集——收集来自你实际用例的输入示例和预期输出。将你的 AI 系统运行在这些示例上，分析它在哪里失败，然后进行迭代。这是最有效的改进努力。

4. 从模型入手，而非从数据入手

在构建生成式AI应用时，团队通常会先尝试最新的模型。他们调整 prompt，尝试不同的架构，测试各种提供商（providers）。所有这些都是必要的，但数据——而不是模型——往往是最大的差异化因素。

你的数据管道（data pipeline）比你的模型选择更重要。你应该问自己这些问题：你拥有什么数据？你需要什么数据？你将如何收集、清洗和标注它？你将如何整合用户反馈来改进你的数据集？

在我见过的最成功的 AI 应用中，那些构建了强大“数据飞轮”（data flywheels）的应用脱颖而出。它们收集用户交互，提取关于哪些有效、哪些无效的信号，并利用这些信号持续改进模型。

5. 忽视评估（Evaluation）

如果你无法衡量它，你就无法改进它。然而，许多团队在没有系统性评估的情况下构建 AI 应用。他们查看几个示例，看到输出看起来“合理”，然后就宣布成功了。

对于生产级的 AI 应用，你需要关注：

质量指标（Quality metrics）： 准确率（accuracy）、相关性（relevance）、幻觉率（hallucination rate）
延迟（Latency）： 系统响应速度有多快？
成本（Cost）： 每请求的 Token 数量、API 费用
安全性（Safety）： 毒性（toxicity）、偏差（bias）、prompt injection 漏洞

从第一天起就构建一个评估管道。收集一个保留测试集（held-out test set）。定期运行评估。跟踪指标随时间的变化，以捕获性能衰退（regressions）。

6. 从一开始就忽视安全性

许多 AI 团队将安全性视为“事后考虑”（afterthought）。他们先构建核心功能，然后再考虑安全措施。但这通常为时已晚。

安全性应该从一开始就融入设计：

你将如何防止 prompt injection？
你将如何处理有害或有偏差的输出？
你将如何保护用户隐私？
你将如何确保系统的输出适合你的目标受众？

事后构建安全性比从一开始就设计好安全性要困难得多。一次安全事件就可能不可挽回地侵蚀用户信任。

7. 过度依赖单一模型

将整个应用建立在一个单一的基础模型上是存在风险的。模型会变化、被弃用（deprecated）或以可能破坏你应用的方式进行更新。价格会变化。提供商可能会倒闭。

你需要构建抽象层（abstractions）来让你能够：

轻松更换模型（如 OpenAI、Anthropic、开源模型等）
为不同任务使用多个模型（简单任务用“小而快”的，复杂任务用“大而慢”的）
当一个模型失败时，回退（fall back）到另一个模型
在模型之间进行 A/B 对比测试

8. 假设更多的上下文（Context）总是更好

最常见的错误之一是给模型提供过多的上下文，以为这会有帮助。但更多的上下文往往会适得其反，因为：

模型具有有限的注意力（limited attention）——它们可能会在海量的 Token 中错过相关信息。
更多的上下文意味着更高的成本（更多的 Token，更高的延迟）。
不相关的上下文可能会混淆模型并降低准确性。

你需要有策略地决定包含哪些上下文。使用检索（retrieval）来查找相关信息。明确指出上下文中的哪些部分是重要的。

AI 作为裁判（AI as a Judge）——评估 LLM 输出质量

9. 忽略延迟和成本

生成式AI是昂贵且缓慢的。单次生成可能需要几秒钟，并花费几美分。在规模化（scale）时，这会迅速累积起来。

团队经常构建出在演示中表现良好但在生产环境中失败的应用，因为他们没有考虑到：

每用户（per-user）的延迟要求
并发用户负载（Concurrent user load）
API 速率限制（rate limits）
月度预算限制

要积极地进行缓存（Cache aggressively）。对于简单任务使用更小的模型。尽可能对请求进行批处理（Batch requests）。为提升用户体验而流式传输（Stream responses）响应。考虑混合架构（hybrid architectures）——将 AI 与传统查找（traditional lookup）相结合来处理常见案例。