作者 | Thomas Betts、 Daniel Bryant
译者 | 刘雅梦
策划 | 丁晓昀
本文要点
架构师需要将 AI 炒作与真正的软件区分开来。设计系统需基于有形的组件（如 LLM），而不是基于模糊的 AI 愿景。
决定如何、在何处以及何时使用 AI 元素归结为传统的权衡分析。
首先，确定 AI 软件是否适合你的应用程序。与其他任何技术一样，人工智能可以被创造性地滥用。
其次，确定如何有效地使用 AI。考虑使用 AI 即服务（AI-as-a-service）API 与自托管之间的权衡。
架构师可以通过 AI 增强他们的决策和沟通能力，从而实现更好的设计并增进团队成员之间的理解。
Arthur C. Clarke 有句名言：“任何足够先进的技术都与魔法无异”。现在，这种“神奇”的技术被称为人工智能。人工智能（Artificial Intelligence，AI）是一个很好的总括性术语，非常适合营销，但这并不意味着我们可以简单地将其添加到我们的软件中。然而，产品负责人、首席执行官和营销团队希望我们将其添加到所有的东西上。虽然客户并没有要求使用人工智能，但他们开始期望将其作为每个应用程序的筹码。
我们必须摆脱关于如何以及为什么应该使用 AI 的模糊、不着边际的指导。这就像是被要求拿出喷雾罐，在所有东西上都涂上一层漂亮的人工智能涂层。这种随意的做法不会产生人们所希望的结果。我们需要一种深思熟虑的方法，了解 AI 是什么，以及我们应该在何时何地使用它。这就是我所说的架构智能（Architectural Intelligence）。
软件架构师现在需要了解什么是 AI，什么不是。这就要求我们抛开营销和炒作，谈论真正的软件。
我们知道了真正的软件是什么之后，我们就必须弄清楚它在我们的设计中的意义所在。由于架构师需要考虑其系统的架构以及如何改进其架构实践，我们将花一些时间来研究架构师如何在设计系统的过程中使用 AI。
什么是 AI？
AI 只是一个营销术语，几乎毫无意义。严肃地说，当我们描述某件事找不到更好的术语时，我们就会乱用 AI 这一术语。一旦某个小部件成为已知的实体，无论是流程、代码还是产品，我们都会给它起一个名字。有人说，在我们理解它之前，我们将之通称为人工智能，再者称之为计算机科学。
“AI”意味着我们没有更具体的名称。这是我想传达的关键点之一。我们不需要讨论将 AI 添加到软件的哪些地方，而是需要用文字来描述我们哪些真实事物可以融入到设计中。
到目前为止，你或你认识的人至少听说过到一个商业领袖说：“我们需要将 AI 添加到我们的产品中”。将“AI”替换为“DB”，想想你会如何回应这一请求。你会转过身来问业务人员他们想要什么类型的数据库吗？我认为结果不会太好。
但作为软件架构师，我们知道这个问题的答案。这要视情况而定。我们需要问一下需求是什么。我们需要存储什么类型的数据？如何访问它？在哪里访问它？我们利用这些需求来帮助我们进行权衡分析。至于所有要做的权衡，都有很多指导方法。关系存储还是文档存储？基于文件存储还是基于内存存储？ACID 的要求是什么？等等。
回到你被要求将 AI 添加到软件中的场景。你仍然不能问业务人员他们想要什么类型的人工智能。然而，答案还是一样的。要视情况而定。但你知道这取决于什么吗？你知道要问哪些正确的问题来帮助定义需求吗？你知道你有哪些选择吗？
AI 通常指 GenAI
五年前，大多数人谈论人工智能的唯一时机是在科幻小说中。书籍、电影、电视节目和其他媒体都有 AI 角色。这些角色就是被称为通用人工智能（AGI）的例子。而我们并没有实现这一点。
今天，在 2024 年，当有人把“AI”作为一个笼统的术语时，他们可能指的是生成式人工智能或 GenAI。我们在专用产品中看到了这一点，比如 ChatGPT 或 GitHub Copilot。这也是最常见的“在产品上喷涂一些人工智能”的方法。如果一些高管想确保他们的产品看起来既现代又创新，他们会添加一些 GenAI。这导致了太多的聊天机器人。而生成式人工智能不仅仅与语言有关。我们可以使用 Dall-E、Midjourney 和其他工具生成图像、视频和音频。
GenAI 从机器学习开始
GenAI 是机器学习（ML）广义概念的具体应用。更具体地说，它是一个深度学习过程。就我们的目的而言，机器学习过程相对简单。我们将复杂的细节留给数据科学家。
创建机器学习模型是从训练数据开始的——大量的训练数据。它可以是任何的东西——历史销售数据、动物照片、用户评论。你将输入和预期的输出数据输入到机器学习训练过程中。这就像一个单元测试。给定输入 A 和预期输出 B，得到的结果接近程度如何？训练过程创建一个机器学习模型，然后根据预期输出对其进行评估。这是一个简单的过程，你可以重复数千、数百万甚至数十亿次，不断地完善模型。
对于非数据科学家来说，将机器学习模型视为简单的函数框会很有帮助，就像编译库一样。就像你导入数学库来计算平方根和对数一样，你可以将机器学习模型导入到你的应用程序中。或者，你也可以通过 API 调用它。
无论哪种情况，它都是一个简单的函数框。你提供一些输入，它将返回一些输出。就是这样。与平方根函数相比，输入和输出可能非常复杂，但函数框的类比适用于所有类型的机器学习模型。图像识别模型、情绪分析模型、销售预测模型。回到 GenAI，大语言模型。
大语言模型（LLM）是一种机器学习模型，其中训练数据、输入和输出都是词汇——很多很多的词汇。LLM 的输入是一个词汇序列。嗯，实际上是一个 token 令牌序列。什么是 token 令牌？它可能是一个单词或单词的一部分。具体细节并不是很重要。请记住，这一切最终都会转化为模型可以处理的浮点数数组。
我们的输出是一个 token 令牌，不是一个序列，而是一个单一的 token 令牌。LLM 只是预测性文本引擎。然而，预测单个 token 令牌或单词似乎并没有太大用处。接下来，将单个 token 令牌和之前的所有内容反馈到模型中，预测下一个 token 令牌。此过程重复进行，直到模型返回一个表示已完成的 token 令牌。这个过程被称为自回归。
我们应该在哪里使用 AI？
既然我们现在已经知道 AI 意味着 GenAI，而 GenAI 实际上意味着 LLM，而 LLM 只是一种机器学习模型，我们可以开始思考该功能用在我们系统中的意义了。
到 2024 年，机器学习和 GenAI 已经不再是事后才能想到的马后炮了。这些技术正迅速成为现代软件系统的核心要素。我们是如何走到这一步的？
不久前，当公司开始招聘数据科学家并创建机器学习模型时，这一切都是附加解决方案。数据已经存在了。它们被用来训练自定义的机器学习模型。然后，这些模型被用作分析过程中的一个组件。公司会进行实验，但实验并不总是有效的，所以你需要将它们与关键业务型应用程序分开。
现在，我们看到机器学习左移了，因为我们希望生成的模型成为我们软件的内部组件，而不再是辅助系统中的额外附加组件。在过去的几年里，我们已经看到只是作为附加组件的 AI 组件，比如所有的聊天机器人，也左移了，成为了向用户提供功能的核心系统组件。这就是我们想要实现的目标。我们不希望人工智能只是配角。但这具体是什么样的呢？在哪里使用 AI 组件而不是由开发人员编写的“传统”软件有意义呢？
考虑在哪里以及如何在系统中使用 AI，就像在系统设计中引入任何新技术一样。我们需要进行权衡分析。使用 AI 的设计与不使用 AI 的设计相比，优缺点各是什么？或者使用不同的 AI 模型。考虑一下你被要求在软件中添加人工智能的场景。我们如何开始权衡分析？“视情况而定”因素有哪些？
AI 是否适合这一场景？
在为新功能进行设计时，我们通常会从合适的选项开始，并放弃那些不合适的选项。由于 AI 正处于炒作周期中，我们看到了有人建议在不相关的地方使用 AI。除了人工智能，想想其他技术，我们可能会如何滥用它们——一个作为缓存引擎的关系数据库，或者一个完全使用 Lambda 函数构建的电子邮件服务。AI 不是我们一直在等待的金锤子。
我们可以使用 AI 的方式涵盖了从好到可能再到坏的想法。AI 有意义的许多功能都是涉及单词的场景。这些都是大语言模型，所以它们非常擅长处理语言。
AI 的良好应用
LLM 可以提供自然语言界面。这适用于输入和输出。让人们描述他们想要做什么，LLM 可以将其转化为系统指令。或者 LLM 可以将系统响应转换为更人性化的格式。
如果你有一个可定制但复杂的 UI，在其上人们可以描述他们想要什么，但配置所有这些需要一段时间，这种场景使用 AI 是有意义的。考虑一个由 AI 驱动的临时报告生成器，你可以通过聊天式界面请求每周一运行一份新报告，并提供每周的比较。这可以节省学习如何通过 UI 配置所有设置的时间和挫折感。
AI 的可能应用
在某些情况下，AI 是有意义的，但除非它是经过深思熟虑实施的，否则结果可能不会理想。因为许多复杂的软件系统是由关键但难以使用的子系统组成的。
在电子商务场景中，你可能有一个规则引擎来定义客户可用的所有折扣。在配置所有规则时，可能会遇到糟糕的用户体验，这时，用 AI 替换规则引擎可能很有吸引力。但是，如果由 LLM 决定客户是否有资格获得折扣，你可能会对所发生的事情感到惊讶。
要始终记得，LLM 是用来预测下一个单词的。在某些时候，当被问及客户是否有资格享受折扣时，下一个词可能是“是”，而你期望它是“否”。这是一个特性，而不是缺陷。
与其用 LLM 替换整个规则引擎，不如用它来改善用户体验，使输入和验证规则变得更加容易。
AI 的可疑应用
在第三类场景中，使用 AI 就是一个糟糕的想法。这些场景大多涉及审计和数据的可追溯性，例如精确的数学场景，或者在为监管和合规性需求创建报告时。
LLM 可能非常适用于分析数据、总结数据含义并给出你应该做什么的建议。但如果你需要将数据正确地相加，就不要使用 LLM。它们的数学很差。如果你要求 LLM 帮你使用报告 API 来构建报告？它能做的很好。如果你要求 LLM 汇总上一季度的所有销售总额？它做不好。
会计的基本原理自数百年前诞生以来一直都没有变过，这是有原因的。你不应该让人工智能来平衡你的账目，并将这些数字报告给你的股东。
AI 是非确定性软件
绝大多数软件都有确定性的结果。如果输入是这样，那么结果就是那样。这使我们能够编写单元测试并制定功能要求。如果软件做了一些意想不到的事情，我们就会提交一个缺陷并重写软件，直到它能按照我们的预期运行。
然而，我们应该认识到，AI 是非确定性的。这并不意味着随机，但其中内置了大量的不可预测性，这是设计使然。这是一个特性，而不是一个缺陷，是 LLM 预测的最有可能出现的下一个单词。“最有可能”并不意味着“总是能保证”。
对于我们这些习惯于处理可预测软件的人来说，这似乎是一个重大的缺点。然而，有两件事需要考虑。首先，GenAI 虽然不是 100% 准确，但通常已经足够好了。其次，架构师一直在处理“足够好”的问题。我们知道“完美是足够好的敌人”。架构师会进行权衡分析，并试图确定哪些妥协是可以接受的。
当在系统设计中考虑 AI 组件时，你需要考虑一下自己在哪些方面能够获得“足够好”的答案。我意识到，我们是花了几十年的时间来构建能够完成预期任务的软件的，所以这可能是一个需要思考的复杂想法。
作为一项思考练习，用人类替换拟议的 AI 组件。你会如何设计你的系统来处理不正确的人工输入？从 UI 验证到需要第二个人审查的任何事情。如果用户界面中的用户是 AI 呢？对于 AI 正在生产的内容，可能也应该进行类似的验证。
这体现在很多产品被称为“助手”或“副驾驶”的事实中。这些术语旨在让我们放心，人类仍在做决策。但是，如果你把决策权交给 AI，那就是你从副驾驶变成代理的时候。转向 AI 代理需要额外考虑验证过程。
如何有效地使用 AI
如果我们确定 GenAI 对我们的场景有意义，那么下一个设计决策就是如何有效地使用它。再强调一次，答案还是“视情况而定”。有效地使用 AI 将始终取决于具体情况。然而，一些高层次的考量通常也是适用的。
首先，我们必须确保“足够好”的软件是可以接受的。值得注意的是，人工智能输出通常具有非常高的“好”水平。看看 LLM 是如何演变的，现在它可以通过大多数的标准化测试。
如果可能，请创建测试，以便可以定量评估和比较 LLM。如果你有一个特定的任务，请制作一组测试提示，将它们输入到 LLM 中，并评估它们的输出质量，使其达到你期望的经验丰富的人所能够达到的水平。
因为拟议的 AI 用途通常会取代或补充人类，所以做一个真人做这项工作的思考练习是有帮助的。这个人是只需高中文凭即可，还是需要专业的培训，比如会计师或律师助理？如果是后者，请寻找使用该语言的专业模型。
更大并不总是更好
当发布一个新的大语言模型时，大的数字会成为头条新闻，参数的数量会成为焦点，无论是 80 亿还是 800 亿。然而，架构师知道这里面总是存在权衡的，而这些额外的功能也是存在缺点的。我们必须考虑预期目的，而不是自动使用最新的 LLM。
最重要的，大语言模型非常适合通用任务，但可能会过于强大。以美元、时间或碳足迹衡量，更大的模型的训练和运行成本更高。可能一个较小的模型就可以满足你的需求，它可能会更快、更便宜、更准确。
较小的模型也可以更专业化，并针对特定领域进行训练。你可能无法回答 Taylor Swift 是谁，但你的软件很可能不需要了解流行艺术家。
AI 评估与优化
除非你的产品是一个语言模型，否则训练自己的语言模型是没有意义的。现在这些都是你可以购买的商业产品，应该是“购买”而不是“构建”解决方案。在某些情况下，对模型进行微调可能是有意义的，这类似于将模型发送到研究生院。然而，只有当微调后的模型是你软件产品的主要差异化因素时，这才有意义。
优化大语言模型性能的首选技术是检索增强生成（Retrieval-Augmented Generation，RAG）。RAG 通过搜索知识库来补充 LLM。这是一个很好的软件架构，将两项技术结合成更好的东西。
LLM 可以提供一个自然语言界面，将用户输入转换为更好的搜索查询。然后将结果传递给 LLM，以生成用户友好的响应，包括引用来源。RAG 模式适用于产品负责人希望将 AI 添加到现有系统中的许多场景。
租用与自有
由于大语言模型（LLM）是商业产品，因此一种选择是通过 API 来访问它们，即通过 LLM 即服务（LLM-as-a-Service）方法，或者将它们安装在自己管理的硬件上。刚开始时，按需付费的方式是最合理的选择。这使你可以进行实验，找出最有效的方法，并比较不同的模型。收集必要的权衡数据，如响应质量、返回响应的时间和成本。这也可能导致一个结果，即在您的场景下使用 LLM 没有意义，并可能帮助你根据需要调整用例。
一旦你确定 LLM 可以成为可以成为你软件中的一个有用组件，自托管方法可能就有意义了。这并不是一个简单的成本计算，因为会涉及到许多因素，并且你可能无法在内部使用可以通过 API 获得的相同模型。同样，为了进行充分的权衡分析，可能需要进行一些实验。
另一个需要考虑的因素是安全性。当你可以控制硬件和网络时，对数据泄漏的担忧就会减少。如果你必须对发送到 LLM 的数据进行清洗，这将会影响输出的质量。此外，如果你想要微调模型，你可能会选择自托管。
架构师什么时候应该使用 AI？
在之前的一次演讲中，我介绍了架构师每天要用到的四项基本技能。首先，沟通是一切的基础。第二是决策。第三是能够适应变化。第四是领导力。这些都很重要，在任何一天，你可能需要更专注于其中的某一项。但这是基准排名，以及它们是如何相互支撑的。
好消息是，如果你正在寻找 AI 可以帮助你成为更好的架构师的地方，那么 AI 在金字塔的底部是有益的。我并不是说 AI 应该取代你的决策过程或处理你所有的沟通，但它可以增强你已经拥有的技能，并将其提升到一个新的水平。
AI 促进沟通
大语言模型（LLM）擅长总结大量的信息。对于软件架构师来说，这在与各种受众沟通时尤为重要。从一份冗长的设计文档开始，LLM 可以为 CTO、产品负责人和开发团队生成不同的摘要。
你还可以要求 LLM 就你所写的内容提供反馈。在你发送电子邮件或进行演示之前，提示 LLM 回答 CTO 或产品负责人可能会提出的任何问题。
AI 助力决策
好的架构通常来自协作过程，人们围着白板，绘制和擦除新想法。对于一个独自工作或刚开始工作的架构师来说，LLM 可以作为另一个架构师，来与他们交流想法。LLM 擅长头脑风暴，提出其他设计选项，并能解释权衡利弊。
你甚至可以要求 LLM 编写完整的架构决策记录（ADR）。这对于第一次通过可能是有用的，特别是它迫使你能够清晰地思考和描述需求，以便将它们输入到 LLM 中。然而，与所有交互一样，永远不要假设它是正确的。对于设计新的软件组件来说尤其如此，因为 LLM 可能会吐出听起来正确但无法实现的单词。
总 结
架构师需要将 AI 炒作与我们实际可以实现的真实软件区分开来。GenAI 和 LLM 并没有什么神奇之处。决定如何、在何处以及何时使用 AI 元素归结为传统的权衡分析。熟悉任何新软件功能的一种方法是定期使用它。架构师可以通过 AI 工具来增强他们的决策和沟通能力，从而实现更好的设计并增进团队成员之间的理解。
本文从 Clarke 第三定律开始。他的第二定律指出，“发现可能的极限的唯一方法就是冒险越过它们，进入不可能的领域”。
关于 AI 现在有很多炒作。我希望我已经提供了关于如何在软件系统中务实地使用有形的“AI”工具的实用建议。但我也知道我不可能知道所有的答案，我当然不知道什么是可能的。
有时，相信炒作并尝试做不可能的事情是有帮助的。你可能会对自己能取得的成就感到惊讶。
本文根据 2024 年 iSAQB 软件架构大会上的一次演讲整理完成。
作者介绍
Thomas Betts是 InfoQ 架构与设计的首席编辑，InfoQ 播客的联合主持人，Blackbaud 的桂冠软件架构师。二十多年来，他一直专注于提供让客户满意的软件解决方案。他曾在多个行业工作，包括社会公益、零售、金融、医疗保健、国防和旅游行业。Thomas 和他的妻子、儿子住在丹佛，他们喜欢徒步旅行和探索美丽的科罗拉多州。
https://www.infoq.com/articles/architectural-intelligence/
声明：本文为 InfoQ 翻译，未经许可禁止转载。
会议推荐
12 月 13 日至 14 日（下周五至周六），AICon 全球人工智能开发与应用大会将在北京盛大开幕！本次大会汇聚 70+ 位 AI 及技术领域的顶尖专家，深入探讨大模型与推理、AI Agent、多模态、具身智能等前沿话题。此外还有丰富的圆桌论坛、以及展区活动，带你深入探索大模型的最新实践与未来趋势。年度最后一次 AI 盛宴，让我们一起见证 AI 未来。
热门跟贴