生成式 AI 应用架构设计——构建原型我在软件工程和数据分析领域工作了 20 多年，其中有 12 年用于开发机器学习（M

我在软件工程和数据分析领域工作了 20 多年，其中有 12 年用于开发机器学习（ML）产品。我曾在小型初创公司和大型企业工作，开发新产品、扩展已有产品、进入新市场，并应对新出现的竞争对手。我多次遇到过一些我认为被高估的技术。我们常常希望工程团队开发出来的某种很酷的技术，能够帮助解决销售下滑、用户不满意和客户群减少的问题，但这往往只是 wishful thinking，也就是一厢情愿。

我们始终需要先理解自己想要解决的问题。我经常看到工程团队还没有清楚识别挑战和用户面对的问题，就直接投入实现。这样做只会延缓失败的必然到来。

生成式 AI（GenAI）是 ML 的一个子领域，正在快速兴起，越来越多应用和产品工程团队开始开发 GenAI 应用。GenAI 使用特殊类型的 ML 模型，也就是大型语言模型（LLMs）及其扩展，例如大型视觉模型（LVMs）。这些基础模型基于大量数据训练，并覆盖不同输入和输出模态，例如文本、视频、音频等；它们展现出优秀的推理能力和其他能力，能够解决并未专门训练过的任务。这使得我们可以借助 GenAI，在几乎任何领域创建广泛应用。因此，这也意味着几乎所有产品工程师都应该掌握 GenAI。你并不需要能够训练一个 LLM，但你应该能够将它集成到自己的应用中。本书将帮助你理解应该熟悉的基本设计原则，这些原则将帮助你开发生产就绪的 GenAI 应用。

本章中，我们将从如何构建成功的 GenAI 原型开始讨论。令人意外的是，这与启动一个成功的 ML 原型并没有太大不同。我们会看看 AI 在什么情况下有效，什么情况下无效，以及大企业中实施 AI 与小型初创公司中实施 AI 有什么不同。

我们还会讨论业务领导者需要理解的 AI，尤其是 GenAI。显然，本章对业务领导者会有帮助，但它也可能帮助产品经理或技术负责人理解同事的视角。归根到底，作为工程师，我们的任务是教育组织中的业务部门，帮助他们使用新技术来发展业务并改善客户体验。

当然，我会稍微简化一些内容，并避免讨论细微差别。请不要因此对我太苛刻。

你将在本章末尾看到图书推荐。如果你对本章讨论的话题感兴趣，我强烈建议你去看看这些书。

本章将覆盖以下主题：

成功 AI 原型的秘密
GenAI 改变了什么
开发 AI 产品的现实
开发 AI 产品时的误解

成功 AI 原型的秘密

首先，我们简单讨论一下 AI 和 ML 的区别，因为这两个术语经常被混用。AI 是计算机科学中的一个宽泛领域，目标是创建能够解决复杂任务的计算机程序，而这些任务通常需要人类智能。ML 是 AI 的一个子领域；换句话说，所有 ML 问题都是 AI 问题，但并非所有 AI 问题都是 ML 问题。ML 专注于通过在大量标注数据集上训练模型来解决任务，因此我们可以说，相比编写算法，它是一种不同的编程方式。过去十年里，我们见证了 ML 的兴起，各种 ML 算法被应用到不同现实问题中，并产生了巨大的商业影响。从实践角度看，2013 到 2023 这十年里，企业开发的大多数 AI 系统都是 ML 系统，例如推荐引擎、欺诈检测系统、需求预测和计划引擎等，我们也在这十年中学到了大量关于 ML 实际应用的经验。

复杂的基于规则的系统、Monte Carlo simulations 和 greedy search algorithms，都是 AI 系统但不是 ML 系统的例子。随着 GenAI 兴起，我们获得了一种设计 AI 解决方案的新方式，而这些方案基于预训练 LLM。从技术上讲，训练 LLM 属于 ML 领域，但许多工程团队只是使用预训练 LLM 来解决业务问题。正如我们将在本书中看到的，一些开发 ML 系统的核心原则同样适用于 GenAI 应用，而且这些原则的重要性经常被工程团队低估，例如写干净、可读的代码，为可靠性、可维护性和 AI 安全设计系统等。

现在我们已经明确 AI 和 ML 的区别，回到当前主题。开发原型非常类似于创业，即使你是在资源充足、用户基础稳定的大公司中工作。

最重要的一步，是确定业务想要解决的问题。如果要用一句话总结本章核心观点，那就是：“不要害怕问自己困难问题，并明确你到底要解决什么问题，以及为什么要解决它。” 换句话说，要关注问题，而不是关注你想用来解决某个潜在问题的酷技术，尤其是那个问题本身你其实还没搞清楚。定义你正在构建的产品，是产品经理的核心任务之一，而你作为业务负责人或技术负责人，也可能承担这个角色。如果你是产品经理新手，一本很值得读的书是 Marty Cagan 的《Inspired: How to Create Tech Products Customers Love》。

在跳进实现、开始思考酷炫技术问题之前，先问一些非常具体的问题：你要解决的核心问题是什么？能否用 heuristic，也就是启发式规则解决它？这个问题值得解决吗？你的解决方案在实际场景中会如何被使用？

与此同时，有时企业担心被新技术颠覆，我们后面会进一步讨论这个话题，于是它们会问一个合理问题：“现在是我们开始使用 GenAI、ML、chatbots 等技术的正确时机吗？” 有时，重新审视并尝试采用新技术是个好主意。在实践中，我只见过 AI 在三类场景中真正交付价值。

当企业想用 ML 模型替换产品中一组随着时间变得过于复杂的 heuristic 时

复杂度增长会让产品在当前状态下非常难维护、难改进。通常，当我们试图修复一个问题时，另一个功能就会退化。这使得衡量产品质量变得非常困难。在这种场景中，问题是清楚的：我们需要用一个 ML 模型替换一堆 heuristic，并引入一套通用评估方法，用来衡量新版本是否比旧版本更好。

另一个公司可能希望用 ML 替换现有 heuristic 以及其背后人工操作的场景，是业务正在扩张，而增加人力不可行。它们的产品底层可能有大量人工工作，阻止了规模化。想象你有一家初创公司，帮助中小企业做会计。你开发了一款漂亮的移动应用，让客户可以轻松上传银行交易和相关文档，并雇了几个会计师帮助企业完成报表。业务表现非常好，但现在你面对一个问题：一开始你是用一个小型人工团队执行手工操作，但要把这样的团队扩大 100 倍极其困难，甚至经常几乎不可能——你无法以业务增长所需的速度招聘足够多优秀的人。

当企业想优化一个已经扩展到数百万用户的产品性能时

在这种规模下，转化率的小幅提升，也可能证明数周工程投入是合理的，因为改进会在庞大用户群中被放大，并产生强投资回报。

例如，将转化率从 1.0% 提升到 1.05%，对于小型初创公司通常无关紧要。第一，公司很可能没有足够数据来可靠衡量如此微小的提升，我们将在第 2 章和第 10 章更详细讨论评估。第二，潜在收入增长很少能证明工程投入合理。早期公司应该专注于寻找 product–market fit，而不是优化小指标。然而，大公司的情况会完全不同。在规模化条件下，一个看似微小的提升，可能随着时间转化为数百万美元收益。

在这些场景中，问题被清晰定义：你有大量使用数据、有一个想提升的具体指标，并且有一个定义明确的产品组件需要优化。这是 ML 表现极好的经典场景。

当企业想借助新技术解锁此前不可能的机会时

这是创办初创公司最常见的原因。但在大多数情况下，你应该 lean，也就是轻量启动，使用现有且基本可用、但尚未大规模普及的技术，并从多个 heuristic 开始。随着产品成长，你的逻辑会变得越来越复杂，你会接入越来越多用户，这意味着你将收集到大量带标注的领域专用数据；随后你会到达一个节点，开始用更先进的 AI 解决方案替换 heuristic，前文已经讨论过。这时才是定制 AI 开发的时机。

一个好例子是近期 Y Combinator 批次中的 GenAI 初创公司。Y Combinator 是一个享有盛誉且非常成功的初创公司加速器。它以投资 Stripe、Coinbase 和 Airbnb 等初创公司闻名。它们每年运行四个 cohort，你可以在它们网站上浏览不同 cohort。多数公司并不从零开发 LLM，而是一开始构建在 ChatGPT、Gemini 或其他基础模型之上的 thin wrappers，并把时间投入到寻找一个值得解决的问题上。这意味着问题一开始应该足够窄，同时代表一个足够大的市场，值得 VC 投资。Peter Thiel 的《Zero to One: Notes on Startups, or How to Build the Future》是一本关于这个话题的精彩书籍。

当然，也有 Mistral 和 Anthropic 这样的初创公司会自己构建 LLM，但更多业务导向型初创公司是从寻找客户群体、开发商业模型、逐步改进产品开始的。通常，它们从 heuristic 和 rule-based systems 起步；但随着成熟，它们会收集自己的数据集和评估机制，技术也会变得越来越先进、越来越复杂。简而言之，不要害怕从小处开始，找到一个好问题去解决。

如果你想使用 AI，特别是 GenAI，但感觉自己不属于这三类中的任何一类，那么你可能是在一个更大的组织中工作。在这种环境中，遇到一些 broader context 或 certain initiatives 背后理由不完全可见的情况并不少见，这会带来额外挑战。

一旦领导层决定公司应该探索 AI 或 GenAI，自然下一步就是启动 proof of concept。但在跳进实现之前，值得先退一步，认真准备。

在大公司启动 proof of concept

在大型企业中，高级领导层成员，例如 CEO、董事会成员、CPO 等，决定公司应该开始采用 ML、GenAI 或其他某种技术，是很常见的，因为周围所有人都在告诉他们这是一个公司不能错过的重要机会。这一点并不新鲜——过去几十年中，同样故事已经随着其他新技术多次上演。

你可能非常渴望开始开发 AI 解决方案。你会马上想召集团队开会，开始规划发布。但不要太快跳进去。在组织内部开始实施 AI 之前，请先做以下几件事。

理解你的利益相关者，以及他们真正想要什么

记住，与利益相关者交谈，就像采访用户。他们可能会告诉你你想听到的内容，而不是他们真正关心的内容。你可以在 Rob Fitzpatrick 的精彩书籍《The Mom Test: How to Talk to Customers & Learn if Your Business is a Good Idea When Everyone is Lying to You》中读到更多内容。

这里有一个非常简单的例子：你可能会被告知：“我们想用 GenAI 服务用户，让世界变得更好。” 但他们真正的意思可能是：“现在，我们迫切需要证明自己没有落后于 GenAI 浪潮，并且需要在下一次投资人电话会议前展示至少一个可运行用例。” 这两个说法不一定矛盾，但它们仍然非常不同。你的任务就是发现这一点，并将短期需求与长期路线图和产品战略对齐。

花时间和用户待在一起，理解他们的需求

例如，如果你正在开发一个企业助手，而这也是大多数 GenAI 用例开始的地方，我强烈建议你花一些时间到现场，看实际工作到底包含什么，尝试理解业务逻辑细节，并识别核心问题。比如，如果你正在开发一个自动化支持运营的 agent，就应该花时间待在 call center，了解支持工程师日常在做什么、日常工作中的挑战是什么、他们使用什么工具等等。

质疑所有假设

俄罗斯有一句著名谚语：“Trust but verify.” 也就是“信任，但要验证”。人们可能误解你的需求，并非故意地误导你。例如，在我十多年参与几十个团队和公司的 ML 项目中，我只听过少数几次有人说数据状态不好。大多数情况下，我听到的是数据干净且高质量，我们可以马上开始开发模型。你可以猜到，我从未见过一个可以直接开始 ML 开发的干净、就绪数据集。

写一份简短文档，总结所有准备工作

在这份文档上投入时间。不要写太长；尽量保持简洁，并删除不必要细节。把文档分享给关键利益相关者和团队。安排几次会议，一起打磨这份文档，并挑战关键假设。写文档能帮助你理清思路，同时也给其他人时间去思考。面对面会议和对话通常会在大家已经读过文档、并有空间和时间思考关键假设与建议后，更加高效。Amazon 著名的写作文化就是这种方法的好例子，你可以在这里看到一个描述它的例子：

https://justingarrison.com/blog/2021-03-15-the-document-culture-of-amazon/

缩小范围，并对过度需求提出异议

专注于评估新技术，理解它的限制和机会。

例如，有时候人们开始 proof of concept 时，会试图一口气实现所有东西：高质量解决方案、低延迟、可扩展且高性能的架构，以及低拥有成本。很遗憾，这通常只会让事情复杂化，并增加失败概率。当你开始使用 GenAI 这样的新技术构建时，第一个目标应该是验证业务可行性。当你证明它解决了某个重要问题后，可以再开始降低成本、提升吞吐量和可扩展性。当然，你应该考虑一些生产要求，不要设计永远无法进入生产的原型，但也不要被这类非功能性要求束缚过度。过去几年，LLM 推理成本几乎每年下降 10 倍。同时，当你知道需要改进什么时，工程师通常能够解决这类问题。只要把原始问题拆解成几个部分，把开发分成不同阶段，然后逐步解决原始问题。

识别最重要的问题，并优先解决它

这与前一点相关，但值得强调。你的用户可能面对不同问题，而且它们都可能很适合解决。作为产品或技术负责人，你的挑战是找到核心问题，即所谓的 user pain point，也就是非常关键、用户愿意为解决它付费的问题。如果你想进一步了解如何捕捉客户需求并让创新成功，我建议从 Anthony Ulwick 的《Jobs to Be Done: Theory to Practice》开始。

Martin Zinkevich 在著名的《Rules of Machine Learning》论文中提出的第 1 条规则是：“不要害怕在没有机器学习的情况下发布产品。” 今天，我们可以把它改写为：“不要害怕在没有 GenAI 的情况下发布产品。”

明确成功是什么样子

我最喜欢问业务方的问题是：“假设你有一个魔法黑盒，可以完成你想要的预测，它到底会如何改变你的生活？” 我们将在后续章节讨论衡量成功的各个方面，例如 A/B testing，但关键是要坦诚讨论如何定义成功、它是否可测量，以及潜在业务影响大概是多少。

不要忘记数据

我会多次提到这一点：数据对任何 AI 开发都至关重要，GenAI 也不例外。你至少需要一个数据集来评估原型。在第 2 章，我们会讨论评估和数据收集策略。你要准备好从数据收集和数据清洗开始，并把资源投入到数据清洗和准备中。

持续让利益相关者了解进展和阻塞

这听起来可能很普通、很显而易见。但我经常看到人们非常努力地解决问题，被工作量压垮，并且尽管出发点很好，却没有足够关注让关键利益相关者保持对齐。有时候他们只是没时间，有时候忘了，有时候认为不应该打扰高级领导。

你不会在用户和利益相关者身上花太多时间。持续缩小你正在解决的关键问题，并围绕需求提出困难问题。

我建议从每周通过邮件发送简短状态更新开始，你也可以附一句，如果收件人不想收到这些状态更新，可以告诉你。AI 采用对许多人来说是一个有趣话题，你会有很多重要发现和学习，这些内容可能对同事有帮助。因此，可以考虑组织知识分享会，在那里分享你的发现，并非常坦诚地讨论困难。根据我的经验，这种透明性有助于教育领导层，到最后，也会帮助他们理解为什么你的项目可能比预期耗时更长。

作为初创公司启动 proof of concept

你意识到存在一个机会窗口，于是决定创办一家初创公司。先说明，我这里说的不是那种重技术型初创公司，它们会深度投入研究。一个非常著名的例子是 Snowflake，这是一家美国公司，开发了一个用于大规模分析、可扩展且快速的数据库。该公司于 2012 年 7 月成立，并在 2015 年 6 月发布数据库第一版。换句话说，他们花了三年时间研究、开发和实验，才构建出优秀产品，但创始人来自 Oracle，另一家成熟数据库公司，并且非常了解市场和技术。我的观点是，当你因为看见机会窗口和市场格局变化而创办初创公司时，优先事项应该是寻找用户并实现 product-market fit。专注于保持敏捷，快速试验技术。不要害怕在早期使用 heuristic，甚至使用大量 what-if cycles、简单业务规则、regular expressions，以及幕后人工工作。

这意味着你的早期产品很可能边缘粗糙、有点 hacky，架构不完美，并且最终会崩掉。随着成长，你可能会经历重写软件的痛苦过程。这无疑很艰难，但它也意味着你活得足够久，已经到达那个阶段，并且最重要的是，你找到了 product-market fit。

事实是，大多数面向消费者或 B2B 的科技初创公司既没有好数据集，也没有足够资本进行突破性研究。你的目标是利用一个现有的新技术，并成为第一个找到方法将其应用到足够大市场的人。我经常看到创始工程师在只有零个或十几个用户时，就花太多时间讨论如何处理百万用户的最佳架构。软件设计本质上都是 trade-offs，本书会多次重复这一点。在很多情况下，尤其是初创公司早期，你无法作出好选择，因为你还不知道确切需求。原因是你还没找到用户。因此，快速构建，不要害怕快速 hack，去寻找那些非常渴望某个具体问题被解决、以至于愿意为不够精致的解决方案付费的用户。

本节提到的大多数内容，适用于 ML 技术，也适用于任何新技术。但 GenAI 到底给产品开发带来了什么变化？

GenAI 改变了什么

现在，我们来讨论目前为止 GenAI 在工程工作和产品开发方面改变了什么：

开发原型的上市时间显著缩短

许多过去需要单独 ML 模型的任务，例如分类、实体抽取、图像理解等，现在可以通过一次 LLM 调用解决。换句话说，许多过去需要开发定制 ML 模型的用例，现在可以用 foundation model 以 state-of-the-art（SOTA）水平解决。

在许多情况下，开发 GenAI agent 类似于开发一个应用。你所做的主要是集成多个 API，当然有一个关键差异：需要大量评估，我们将在第 2 章讨论。因此，你可以在几周内为某个用例开发出原型，而不是像以前那样花几个月。

面向消费者应用开发者的基础设施成本显著降低

大多数情况下，你不需要训练或微调自己的 LLM。你只是在拼接几个 API，而开发这种原型的初始基础设施成本很低，因为你不需要投资任何硬件或购买许可证。从某种程度上说，模型供应商已经进行大量前期投资，训练出能够解决复杂任务的强大模型。

你最终可能会购买自己的硬件并托管自己的模型。但大多数情况下，应从小处开始，评估技术潜力。如果你在整个组织中找到的唯一用例都需要 fine-tuning、hosting，甚至训练自己的 LLM，那么你可能忽略了一些机会。先从小处开始，积累经验和专业能力，拿到第一批胜利，然后再规模化。

你可以从比以前小得多的数据集开始

注意，我并不是说你不需要任何数据集。我们会在第 2 章更详细讨论这一点，但提前说一下，你可以用一个只包含 40–50 个样例的验证数据集开始做用例开发，而且多数情况下不需要任何训练数据。

你需要更小的团队

除了 GenAI 缩短原型开发上市时间之外，很多证据表明 GenAI 总体上也提升工程生产力，并且有大量工具让原型开发更容易，例如 Cursor 和 Claude Code。所有这些加在一起，使开发 GenAI 原型并将其推向生产，比以前所需工程团队更小。

FOMO 非常强

没有人能可靠预测未来几年会发生什么，但有很多预测认为，一些行业可能被显著颠覆。Gartner 预测，全球 GDP “可能推动全球 GDP 增长 7%，约 7 万亿美元，并在 10 年内将生产率增长提高 1.5 个百分点”；GenAI 已经对许多行业的劳动生产率产生正面影响，例如软件开发、医疗和金融。这些预测是基于当前进展外推得出的。

现代 AI 快速进步背后有几个关键因素。过去几年，我们见证了许多重大突破，例如：

更多数据和更大模型意味着更好的模型
LLM 的 emergent capabilities，也就是能够解决未经过专门训练任务的涌现能力
GPU 和定制芯片等专用硬件的进展
基于强化学习和合成数据的 LLM 推理能力取得重大进展

如果进展继续保持当前速度，未来几年我们可能看到非常强大的推理模型。这正是大量 FOMO 的来源，因为许多公司和领导者担心太晚加入竞争。这些预期是在相对较短时间段内，也就是 3–4 年，对趋势进行外推。也存在相反观点，代表对 GenAI 快速进步的怀疑。是的，过去几年我们观察到了意外突破，但这是否保证进展会继续以同样规模发生？反对者会提到 Transformer 架构的限制，以及额外数据不足，因为几乎所有可用数据都已经被用于训练。

我们已经见过一些被过度炒作的预测。例如，2017 年，comScore 预测到 2020 年，一半搜索都会通过语音完成。2016 年，Gartner 预测，到 2020 年，普通人与机器人对话的次数会超过与配偶对话的次数。

围绕 GenAI 的许多预测，都基于一个假设：近期发现形成的短期趋势会在未来几年持续。技术乐观主义者希望这是真的，但仍有大量挑战尚待解决；外推短期趋势很容易导致错误。

我们不知道哪些预测会成真。形成自己的观点也许有趣，但估计这些预测成真的概率其实没那么重要。熟悉贝叶斯概率解释的读者会知道，它最终要么为真，要么为假，中间没有状态。如果这些预测是真的，对你的公司或市场的后果可能巨大。Clayton Christensen 在《The Innovator's Dilemma》中很好地解释了这一点。

Clayton Christensen 在《The Innovator's Dilemma》中提出了 market disruption，也就是市场颠覆这一术语，后来它变得非常流行。当某件事，例如新技术，彻底改变某个行业的运作方式时，市场颠覆就会发生。在这类情况下，通常一家资源较少的小公司能够成功挑战成熟大企业，因为起初新技术市场很小、被大玩家忽略，例如新技术可能还不足以服务大众市场。但当技术改进时，那些专注 niche cases 的新玩家会突然获得强竞争优势。

因此，许多企业领导者决定投资 GenAI，以防颠覆到来。作为技术负责人，你的角色是尽可能协助他们。科学家非常清楚，负面结果和正面结果一样好，因为它们提供有价值反馈，可用于后续研究。因此，即使你持怀疑态度，也可以把它当成学习和评估新技术的机会。

我们已经讨论了 GenAI 如何改变产品开发，以及如何看待当前炒作。现在，让我们看看 ML 模型开发生命周期的一些方面，以及标注数据对任何 AI 开发的重要性。

我们将讨论一些经常被业务领导者误解、并在他们与工程领导者之间造成紧张的问题。这应该能帮助前者更好理解开发 AI 解决方案的复杂性。

开发 AI 产品的现实

我的职业生涯始于零售、分析和金融领域的数据分析和预测。在这些行业工作了近 10 年后，我转向科技行业，开始从事本地搜索。我清楚记得自己当时对工程师无法修复搜索行为中的“简单”bug 感到沮丧，也记得需要收集数据和运行线上实验的漫长迭代周期。自那以后，我看到许多负责 AI 产品的业务领导者也有同样沮丧。

第一，ML 模型针对平均表现优化，你无法保证它 100% 准确。这意味着永远会存在边界案例，ML 模型无法给出正确答案。当我们用 ML 解决方案自动化业务流程时，应该评估错误成本，也就是 ML 模型在具体案例中给出错误预测的成本，并保留 humans in the loop 处理申诉。让我们看一个简单例子。假设我们正在开发一个 GenAI 助手，帮助保险公司员工验证理赔。提前说明，这是一个 binary classification 问题，我们会在第 2 章更详细讨论如何衡量这类模型表现。但先看看当 AI agent 批准或拒绝理赔时会发生什么：

GenAI agent 批准理赔：我们期望智能体大多数情况下正确，也就是说，它批准有效理赔，同时也会批准少量本不该批准的理赔。只要平均准确率足够高，这通常可以接受，但有一个小提醒：我们可能希望对超过某一阈值的理赔增加人工审查，因为 1% 的已批准理赔可能占 10% 甚至更多赔付金额。

GenAI agent 拒绝理赔：如果 1,000 个有效理赔中有 1 个被拒绝赔付，这种情况就可能造成问题。

如果被保险人获得了一笔他们本不应获得的赔付，那对保险公司来说是一项成本。只要平均损失相对收入较小，这类成本可以忽略。但当被保险人被拒绝了一笔他们应当获得的赔付时，这就是重大问题。设计自动化时，我们应该给客户一个容易申诉的机会，并由人类复核；或者根据业务要求引入人工审查。AI 关心 expected outcomes，倾向于在平均表现足够高时忽略边界案例，但不要忘了，这些边界失败背后是真实的人。我们将在第 7 章更详细讨论 AI fairness。

第二，你会遇到 AI-based solution 明显失败的场景。在传统软件中，我们称这种情况为 bug。

不存在没有 bug 的软件。失败和错误永远会发生。降低失败率，需要你在测试、开发和组织流程改进上大量投入。本书中我们会更详细讨论这一点。

但你应该为 bug 和失败做好准备。即使在航空这样关键的行业，也会出现 bug。只是由于这类软件开发成本很高，它们出现得很少。你的目标不是无 bug 软件，而是达到一个合理可接受的失败和性能水平，帮助业务繁荣。

通常，工程师可以调试软件，找到问题原因并修复它，之后你就再也看不到这个问题，当然前提是你有良好测试。但当产品背后有一个 ML 模型时，修复一个简单 bug 会变得几乎不可能。我们将在第 4 章讨论一些为 GenAI 用例添加 backdoor 以便快速修复的方法。但总体来说，如果模型对一个具体问题回答很差，即使修复看起来显而易见，也需要大量工作。

开发一个 AI-based solution 的典型流程如下：

收集标注数据集，其中包含输入和期望输出示例。
提出如何改进模型的假设并实现它们。
运行离线实验和评估。离线实验意味着不在真实用户上测试，而是使用标注数据集进行评估。我们会在第 2 章深入讨论评估。
准备生产实现。
部署。
用真实用户测试你的解决方案，第 10 章会进一步讨论。

每当你想改变模型行为时，如果这不是包装模型输出的业务逻辑变化，你都需要走完整个周期，而这可能花费相当长时间。更重要的是，你不能直接告诉模型：“在这个具体案例中这样做。” 你需要收集一个更新后的数据集，代表你正在经历的一般问题，然后才能重新训练模型。

正如你可能从上述讨论中推断出的，标注数据集对 AI-based solution 成功至关重要。没有数据，就没有 AI；没有好的标注数据集，你也无法开发基于 AI 的软件。

AI 和计算机科学中的 garbage in, garbage out（GIGO）概念，指的是用于训练模型的低质量输入或数据，会产生同样低质量的输出，或训练出同样低质量的模型。

很多情况下，业务领导者相信自己拥有好数据，因为他们至少十年来一直投资数据仓库、数据收集等。不幸的是，事实往往并非如此。想象你想使用 GenAI 帮助客户支持工程师做决策，甚至在内部系统中生成一些点击或调用。你可能很快发现，support case 中的数据只代表最终解决方案，而不代表支持工程师当时看到并作出决策时的初始状态顺序。此外，你没有收集哪些实体被点击以及用户 engagement 数据，而这些最初却是你的成功标准；这意味着没有可供模型训练的数据。

在 ML 中，用于训练模型的数据应该类似于预测时可获得的数据。例如，温度是冰淇淋销量的强预测变量，但我们不应该使用某一天的实际温度作为预测变量，而应该使用预测时刻可获得的那一天的天气预报。

最后但同样重要的是，开发和部署 AI-based solutions 需要在工程流程和工具上投入一定资源。有时你看到一个精彩 proof of concept 和 demo，会觉得可以立刻部署，但距离生产就绪应用还有很长一段路。第 4 章会讨论原因。

我们总结一下：

ML 模型针对平均表现优化，设计业务流程时必须考虑这一点。始终假设在某个具体案例中，模型可能给出错误预测。
ML / AI 的开发周期可能比经典 B2C 软件开发更长。修复表现上的“bug”很困难，可能需要重新训练模型的完整周期。
数据是关键，而且很可能还需要额外投入数据标注。记住：garbage in, garbage out。
工程师需要投入工具建设，并处理从闪亮原型迁移到生产时的技术债。

我们已经讨论了 ML 模型开发的一些方面、适当工具的重要性，以及投入收集、标注和清洗数据。现在，让我们看看企业在 AI 开发中常见的一些误解。

开发 AI 产品时的误解

业务领导者从各处听到 AI 很强大。虽然这会提高采用率，但也会导致一些误解和错配预期。本节应该帮助业务领导者稍微更好理解他们应该期待什么，同时也帮助工程师更好理解业务领导者视角。当双方都能围绕问题开放沟通时，任何项目的成功率都会大幅提升。下面来看一些常见错误。

以为基础模型很强大、可以 zero-shot，所以不再需要任何标注数据

正如我们将在第 2 章看到的，你仍然需要评估数据集，而且这是进入生产前的关键组件。

GenAI 允许你用比以前更小的标注数据集构建强大的 AI-enabled applications。但干净、准备充分的数据集，仍然是几乎任何成功 GenAI 实现的前提。

不投资内容创建和数据清洗

这强调了前一点。你可能真诚相信自己有一个干净数据集，但这很不可能，因为使用 GenAI 时，你会遇到以前可能没有考虑过的场景。

规划项目时，要考虑将一些 subject matter experts（SMEs）加入团队，帮助完成数据标注。遗憾的是，我太常见到这样的 GenAI 项目：投入了数百万美元和数百天工程工作，却无法让一个 SME 全职投入几周做数据标注。

盲目信任 LLM，不投资评估

我保证这是本章最后一次谈 evaluation。首先，不要因为所有人都在谈 LLM，就假设 LLM 很强。我见过 LLM 甚至在相对简单的分类问题上挣扎。这里的“挣扎”并不是指它最终完全无法完成任务。基础模型总体能解决这个问题，只是需要多次尝试提示。第二，从 evaluation pipeline 开始你的 proof of concept。Martin Zinkevich 的第 2 条规则是：“先设计和实现指标。” 甚至在你开始 ML 或 GenAI 之前就应该做这件事。我经常看到项目计划如下：

第 1–6 周：开发解决方案
第 7 周：评估
第 8–9 周：部署到生产

我建议尽可能早设置评估阶段；至少从一开始就定义成功指标、开发评估管线，并用你的 baseline 跑一遍。如果一开始没有 evaluation pipeline，你就无法衡量自己做得怎么样。

以为原型就是全部

GenAI 模型在 “give me a summary of the document” 或 “rewrite this email” 这类任务上表现非常好。有时它几乎像魔法一样，这可能造成一种错觉：它在任何任务上都会表现很好。事实是，将一个解决方案适配到你的领域和具体情况，仍然需要复杂工作流和大量实验。一个令人印象深刻的原型，通常只是打开了开始采用 GenAI 的门；要构建能安全部署给用户的稳定解决方案，还需要更多努力。

以为 GenAI 很便宜

LLM 的价格是每百万 token 几美元。这听起来不多，但想象一下，100 美元能生成多少封邮件！但工业用例通常需要复杂 agentic workflows，远远不止向 LLM 发送一次文本提示。我们会向 GenAI 发送越来越多数据，包括多模态输入，并开始使用更复杂、更昂贵的推理模型，例如 Gemini Pro 或 GPT-5。Agentic workflows 可能让单次请求成本膨胀 10 倍甚至更多。除了查询 LLM 的成本，你还需要准备数据，并用正确方式组织和索引数据；这一切都需要运行服务器来存储索引并服务查询。

以为 GenAI 很贵

这听起来与上一点矛盾，但和往常一样，一切取决于上下文。即使你认为 GenAI 很贵，也不应该因此停止尝试。记住，LLM 服务成本正在快速下降。先关注业务价值，一旦证明业务价值，就可以优化解决方案并降低成本。此外，你可以预期每 token 成本还会进一步下降。

没有规划应用维护

本书讨论的是如何把应用从 sandbox 推向 production。在很多情况下，这很难。不要因为一个精彩 demo 就过度兴奋；请记住，在你能安全地把应用放到用户面前之前，还有很长一段路。同时，像往常一样，硬币还有另一面。不要害怕将 alpha 版本放给少量愿意测试的用户快速试运行，但从一开始就要对相关风险和限制保持透明。

过度依赖 “best practices”

作为一名在工程咨询领域工作多年的专家，我很喜欢别人问我 best practices，因为这正是我被付费做的事。但软件工程本质上都是 trade-offs。我和团队面对的最大挑战，很少真正来自技术困难本身。大多数情况下，挑战在于收集清晰需求。

试图原样自动化流程，并追求完美结果

在自动化任何流程之前，要先确认它在当前形态下是否真的有意义。如果一个流程混乱、不一致或过于复杂，自动化只会放大已有问题，而不是解决它。专注于那些自动化或 GenAI 能真正创造价值的区域，特别是重复性或高影响任务。准备好先简化或优化流程；当事情干净且定义清楚时，自动化效果最好。此外，并不是每个问题都需要复杂技术方案。有时候，UX 或工作流上的小改动，就能比调 AI 模型或后端系统更轻松地达到同样结果。

如果要用一句话总结本节，我会说：“keep it simple。” 我们将在第 4 章进一步讨论这一点，但现在先记住：当你开始构建一个新产品时，不要过度工程化，应该先建立一个简单 baseline，为未来 AI 增强打基础。关注业务需求并推向市场，同时确保组织中的业务和工程部分保持良好对齐，使用同一种语言，并理解彼此的需求和挑战。很多时候，业务人员和工程师都非常优秀，只是彼此并不真正理解，这会导致错误激励、被误读的需求和焦点丢失。

小结

本章从一个讨论开始：在跳进技术实现之前，尤其是在 GenAI 语境中，先理解要解决的问题有多重要。无论在初创公司还是大型企业，成功 AI 原型都与创业有相似之处：重点是提出困难问题，并清晰定义问题。

随后，我们考察了 AI 会表现良好的三类关键场景：在具有复杂 heuristic、难以维护的成熟产品中；在已扩展到数百万用户、微小改进也能产生显著回报的产品中；以及当新技术能够实现此前不可行的解决方案，并由此改变市场格局时。

对于大公司，我们考察了理解利益相关者需求、花时间与用户相处、质疑假设、记录准备工作、缩小范围并专注最重要问题的重要性。我们也强调了清晰成功指标、数据和持续利益相关者沟通的重要性。

对于初创公司，我们讨论了优先寻找用户和 product-market fit、保持敏捷、快速试验技术的重要性，即使这意味着从 “hacky” 解决方案开始。GenAI 已显著缩短原型上市时间、降低基础设施成本、减少对大型数据集的需求，并使小团队更有能力完成工作。

随后，我们考察了常见错误，例如以为不再需要标注数据、忽视内容创建和数据清洗、没有评估就盲目信任 LLM、以为原型已经足够，以及误判 GenAI 成本。

总之，我们强调：ML 模型针对平均表现优化，开发周期可能更长，数据至关重要，并且必须投资工具和流程，才能构建生产就绪应用。

下一章中，我们将讨论 ML 开发生命周期、评估的重要性，以及如何为 GenAI 应用实现恰当的评估流程。

需要记住的三个关键结论如下：

始终从业务需求开始，并界定你要解决的问题范围。搞清楚需求是软件工程中的最大挑战，而不是使用酷技术本身。
不要过度工程化，尤其是在一开始。专注快速迭代，验证用户需求和你正在构建内容的可行性。在开发 MVP 时，不要害怕使用快速 workaround 或 hack。
GenAI 已经显著缩短上市时间，但从令人印象深刻的原型到生产就绪解决方案，还有很长的路，因为原型会忽略边界案例和复杂业务需求。

生成式 AI 应用架构设计——构建原型