你会如何定义人工智能工程师或人工智能工程？

我觉得现在很多术语都含义模糊了。当初为这本书的书名我可是煞费苦心。我知道我们需要一个不同于“机器学习工程”的术语。原因是，虽然基础模型的出现带来了很多新东西，但很多基本原理和系统方法与机器学习工程仍然是相同的，但也出现了很多新情况。

例如，以前当你想构建机器学习应用时，你需要自己构建模型。这意味着你需要自己的数据，也需要训练和“照看”模型的专业知识。然而，现在如果你想利用机器学习或人工智能来构建应用，你只需发送一个直接的 API 调用，就能接触到这些强大的功能。这大大降低了人们的入门门槛。你不再需要数据，也不再需要一个高大上的人工智能学位。

第二点是，以前，你需要分发渠道，因为你部署的机器学习应用是实际应用的一部分。比如你构建一个推荐系统，你需要一个电商网站才能有推荐功能。但现在，你可以把它作为独立应用发布，不再需要现有的分发渠道，当然拥有分发渠道仍然非常有用。

我认为另一个非常大的变化是，关注点从机器学习转向了工程和产品。以前，优秀的机器学习工程师会从数据开始，收集数据，可能进行人工标注，然后训练模型。现在，一旦模型效果好，就把它部署到你的产品中。但如今，你实际上是从一个真实可用的demo开始的。我们有个很酷的想法，那就先试试看它是否可行。所以我们从产品开始。在你觉得它效果不错，想让它变得更好之后，你才开始收集更多数据，也许是更多的提示示例，或者在极少数情况下——我不建议大多数人在早期这样做——进行微调。

你会引入更多数据，也许是为了评估，这非常重要，拥有好的评估体系在人工智能工程中变得更加重要。之后你可能会想，也许你一直在向 OpenAI、Anthropic 或 Google 发送大量的 API 调用，然后你会觉得：“现在这太贵了，我需要用我自己的模型了。”于是你开始托管自己的模型，使用一些开源替代品，或者微调一个模型。

所以，以前的机器学习工程，是从数据到模型再到产品。而现在的人工智能工程，是从产品到数据再到模型。因此，它更加侧重于产品和数据，当每个人都共享相似的基础人工智能能力时，这将成为竞争优势。所以我认为确实需要一个不同的术语来将其与机器学习工程区分开来。我调查了一群在基础模型之上构建应用的人，他们几乎都称之为“人工智能工程”。我想，既然如此，那就用“人工智能工程”吧。

所以我的理解是，最大的区别在于机器学习工程师做了更多基础工作，比如获取数据和构建模型；而人工智能工程，至少在初期，很多这方面的工作可以通过API或其他方式开始，所以更多的是工程层面，你把各种东西组合起来。然后随着时间的推移，当事情变得更重要或你的产品规模更大时，你才会做更多类似构建自有模型或托管模型的工作，甚至有一天如果必要，你可能会从头构建自己的模型，但这通常是很久以后的事了。

首先，我觉得每个公司对这个角色的定义可能都不同。其次，我不认为问题在于“机器学习还是工程”。在我见过的绝大多数生成式AI系统中，都有非常强大的传统机器学习或分类器组件。比如，你正在构建一个客户支持聊天机器人。你收到了一个客户的请求，也许你有几种潜在的解决方案。如果是一个简单查询，你可能会把它发送给一个便宜的模型；如果是一个更难的查询，你可能会把它发送给一个更昂贵的模型。但如果是一些非常敏感的事情，你可能就想把它转给人工操作员了。所以你可能会有一个路由机制或意图分类器来决定把请求发送给谁，这可以是一个你自行构建的传统经典机器学习模型。

或者，在你从AI模型那里得到回复后，你可能会想检测回复是否包含个人身份信息（PII）或毒性内容，这些检测本身就可以是分类器。在当今的RAG系统中，我们谈到很多系统使用了检索，而检索系统，我认为也属于你可以自己构建的经典机器学习范畴。

那么，在构建AI应用时，最常用的技术有哪些？就是那些软件工程师进入AI应用构建领域后应该了解，并且稍后可以深入研究的东西。

假设你已经尝试了很多解决方案，也尝试了生成式AI，并且认为生成式AI是适合你的解决方案。那么问题就是，接下来我该怎么做。

我通常会推荐一些开发模式，它们遵循一定的产品发展路径。首先，要努力理解什么是好的响应，什么是坏的响应。你需要的是一个匹配率。例如，LinkedIn为求职者构建了一个职位匹配度评估工具，他们大部分时间都花在理解求职者需要从模型中得到什么。最初他们关注的是正确性，但后来他们意识到求职者觉得这没有帮助。他们更想了解差距在哪里，以及如何弥补这些差距，或者获得其他更适合他们当前情况的职位建议。

所以，要对这些有清晰的理解，然后制定一个指南，在提示中给模型非常清晰的指导。你尝试这些提示，然后查看输出，也许你可以尝试添加更多的例子。然后就是不断获取好的响应，并进行评估，或许可以策划一组查询和期望的响应，使用自动化指标和人工评估来衡量进展。

完成了提示工程，或者在提示中添加了更多示例后，你可能会给模型更多的上下文，以便它能更好地回答问题。例如，当用户提出问题时，你可以让模型调出与此问题相关的文档或招聘信息。这样，你就构建了一个通过文档来增强上下文的系统，这就是RAG模式。我确实认为RAG是一个非常非常强大的模式。

关于RAG，有趣的一点是，很多人将RAG与向量搜索联系起来，直接就想到向量数据库。但第一个解决方案可能不是基于向量搜索和嵌入的检索。因为你需要使用一个嵌入模型，其质量高度依赖于嵌入的质量。如果你的嵌入效果不好，你就检索不到好的东西。而且，向量数据库的运行成本可能相当高，还会增加延迟。另外，向量数据库或嵌入也可能模糊掉某些关键词，例如特定的错误代码。

所以，通常的做法，或许可以从一些简单的方法开始，比如关键词检索。如果文档太长无法放入上下文，才开始考虑分块（chunking）。分块又带来了其他问题，比如信息可能分散在不同块中。这时你可能需要从文档中提取关键词，并为每个文本块添加元数据，或者获取文档的标题，甚至为其添加摘要。Anthropic 有一篇非常好的文章叫做《上下文检索》，他们让模型为每个文档生成关键信息和元数据，并将其附加到每个文本块的前面，以帮助检索到正确的文本块。我确实认为，做好数据准备实际上能带来巨大的性能提升，远比纠结于“我应该使用哪个向量数据库”要大得多。

所以，一开始你可能想尝试一些简单的方法，这些方法能带来最大的性能提升，然后再逐步增加复杂度。另外，一个有趣的观点是：“如果一个检索系统没有和BM25进行基准比较，我是不会认真对待它的。”BM25是一个有二十多年历史的老牌检索算法，它是一种更简单的、基于词项的检索，非常难以超越。很多时候，混合搜索（结合基于词项的检索和向量数据库）是非常常见的，这样既能获得语义理解，也能获得精确的关键词匹配。

那么，我们谈到了提示工程、提供示例、RAG。我想在此之后，也许你已经把这些方法用到极致了，然后你才可能考虑微调（fine-tuning）。但我认为，对于微调，通常我会有很多保留意见，因为它会带来一大堆你需要处理的新问题。首先你需要考虑如何托管微调过的模型，很多模型都很大。其次是如何维护它？你的微调模型能在多长时间内胜过那些不断推出的新模型呢？因此，我认为微调应该是最后的手段，而不是首选的第一道防线。

我听到的基本上是：采取结构化的方法，从提示开始，从简单入手，从获得有意义的回复开始，然后添加更多数据。你可以通过RAG来实现，可以通过分块、关键词提取来做。数据准备真的非常重要。然后你可以转向更高级的东西。你可能仅凭基础知识、一点工程实践，最重要的是，理解你试图解决的问题，就能构建一个相当不错的系统，而不是盲目追求那些光鲜亮丽的技术或方法。

是的。而且，我认为，对于个人开发者或整个企业组织来说，方法可能也会有所不同。我观察到的一点是，特别是在技术的早期发展阶段，通常启用新的用例比对现有用例进行增量改进能带来更大的回报。所以，与其花费精力去投入大量资源，通过更复杂的技术来榨取一点点性能提升，不如利用现有的技术栈去开拓新的应用场景。

假设我们公司决定构建一个人工智能解决方案，就拿客户服务自动化这个例子来说。我应该了解哪些典型的方法？

客户支持解决方案。我会说，首先要看的是，目前这个解决方案的瓶颈在哪里。例如，有家初创公司面临大量客户支持请求，他们的解决方案是尝试把大量问题引导到公共渠道，如公开的 Discord 服务器，让用户互助解答，并形成可供后续参考的知识库。

另一个流行的解决方案是将请求路由到正确的部门。瓶颈在于分诊，即不知道该把请求发送到哪个部门。因此出现了一批初创公司，构建系统来预测请求应该去财务部门还是技术支持部门，仅仅这种路由就已经大大减少了摩擦。

如果你认为确实需要生成式AI来做这件事，我非常推荐微软提出的那个框架，他们称之为Copilot Stack，它倡导从风险较低到风险较高的渐进式部署。首先是客户支持聊天机器人，最初你可以采用“人在回路”（human in the loop）的方式。例如，对于每一个请求，不是让人工坐席从头开始写回复，而是让人工智能建议几个选项，然后人工选择一个，或者选择一个作为起点进行快速编辑后发送。一旦你看到某一类查询的接受率很高，比如达到了百分之九十，你可能就会更有信心地将其推广，也许先向小部分用户推广，或者甚至先在内部用例中推广。然后，你可以赋予它更多的自动化，但同时缩小部署的范围。当你对效果非常满意时，就可以向更多用户推广了。

我非常喜欢你所说的，听起来并不特定于生成式AI。你讲的是：审视业务问题，审视你面临的问题，考虑各种选项，这些选项不仅包括生成式AI，也包括更传统的机器学习。然后，你会看这些工具是否有助于解决你的问题，接着，确保它在推广时确实能解决你的问题，而不是盲目推广。这其实并不新鲜，不是吗？

是的。我绝对认同，处理新技术是那些永恒不变的事情之一。每次有新技术出现，我都能听到各地资深工程师集体发出感叹：“不是所有问题都适用同一种解决方案（不是拿着锤子看什么都是钉子）。”一个非常普遍的挑战是人们直接就跳进去了，他们就是想用生成式AI来解决那些不需要生成式AI的问题。这其实是两种不同的“头条新闻”。一个头条是：“我用了生成式AI。”另一个头条是：“我解决了问题。”如果你想解决问题，那么你就需要理解问题是什么，挑战在哪里，瓶颈是什么，然后用最简单的解决方案而不是最花哨的方案来消除这些瓶颈。

当你构建一个AI系统时，你会遇到的事情之一就是你需要评估输出结果。为什么评估AI系统很困难？以及有哪些常见的方法可以做到这一点？

评估，我认为这是一个价值数十亿美元的问题，考虑到我们现在在生成式AI上投入的资金，甚至可能是数万亿美元的问题了。评估之所以具有挑战性，是因为人工智能越聪明，我们人类就越难评估它。以前，如果人工智能的表达不连贯，我们很容易判断一个回应的好坏。但现在，它的表达相当连贯了。例如，如果你让它总结一本书，如果总结听起来很有说服力，你实际上并不知道这是否是一个好的总结。

我很多时候会用AI来问一些我不知道答案的问题，正因为我不知道答案，所以我也不知道AI给出的答案是否正确。如果我们已经需要当今最聪明的人来评估AI，那么我们很快就会没有足够聪明的人来评估AI了。以前，我们很多时候把人类作为AI性能的黄金标准，但现在，在很多很多任务上，AI的表现已经远远超过了人类。

我想到了几种应对方法。第一章是关于通用方法论，第二章是关于如何使用不同的技术来评估AI系统。方法论方面，一个是功能正确性。它根据应用在执行任务时的表现来评估其输出。比如，你说用AI来节能，你就可以看它实际节省了多少能源。编码是另一个非常常见的用例，我们知道如何评估代码，比如代码是否能编译通过、运行并产生预期输出。

第二种方法是使用AI来评估其他AI（AI as Judge）。它们做得相当不错，很多应用已经使用了这种方法，而且我认为这种趋势还在增长。当然，使用AI作为评委也面临很多挑战。另一种我觉得非常有趣的方法是比较评估。作为人类，我们可能很难给某事物打一个绝对的分数，但是拿到两个版本的东西，我们就能判断出哪个更好。研究表明，即使AI表现与人类专家水平相当甚至超越，我们仍然可以检测出差异。这不仅指导了评估，也指导了模型开发。

听起来确实没有简单的答案，你可能需要审视所有这些选项，然后判断在你的具体情况下，哪种方法在成本、可行性以及是否能有人工介入等方面是合理的。

是的，我不认为有简单的解决方案。这也是我对评估工具持怀疑态度的一个原因，因为很多评估的挑战并非因为我们不知道如何评估，而是因为它需要纪律和努力，很多事情是工具无法真正自动化的。我们需要根据用户的需求来评估一个应用，这意味着我们需要去和用户交谈，需要观察他们的互动。我们必须衡量那些真正重要的东西。

例如，我有个朋友在做一个总结会议的应用。最初他们想衡量正确性，比如总结是否涵盖了会议内容，是否遵循了格式。但最终他们发现，用户其实并不关心会议的全部内容，人们只想知道：“我的行动项是什么？”

再比如，一家大型税务软件公司推出了一个聊天机器人帮助人们报税，但发现回复率很低。最终发现，用户不用它，是因为他们讨厌打字，而且面对不熟悉的税务领域，根本不知道该问什么问题。后来他们开始尝试更多地了解用户会问什么类型的问题，并在开始时就给出建议，引导用户。

很多时候，这都关乎于深入理解你所在的领域和问题领域，去和用户交流，去查看数据。Greg Brockman 认为手动检查数据是那些“价值与感知价值比率”最高的活动之一。通过查看数据，你可以发现模式，理解用户是如何使用你的产品的。我强烈推荐不要忘记人工评估。你可以使用AI作为评判者，但AI评判者有很多挑战。如果你有一些人工评估，有非常一致、非常清晰的指导方针，比如每天查看一定数量的实际交互样本，就能对用户如何使用你的产品有一个大致的了解，也能帮助你将自动化指标与实际情况联系起来。

在你看来，团队在构建AI应用时，有哪些常见的错误？

一个非常常见的错误是，在不需要生成式AI的时候使用它。例如，有家初创公司想用生成式AI帮助人们优化用电，但实际上简单地将大功率活动安排在非高峰时段就能解决大部分问题，可能用线性规划甚至电子表格就能解决，不需要生成式AI。

另一方面，我看到很多公司放弃了生成式AI，因为他们尝试过后发现它不适用于他们的问题。但深入研究后，通常发现问题出在糟糕的产品设计上，比如没有很好地设计提示，不了解用户，甚至不知道该如何正确评估。例如，一家做简历信息提取的公司，效果很差，但他们没有细分问题出在PDF文本提取阶段还是组织机构名称识别阶段。如果你不能精确定位问题出在哪里，又怎么能修复它呢？

很多时候这看起来像是常识，但不知为何，这总让我有点困惑。或者，另一个例子是一开始就做得过于复杂，比如直接就用上了向量数据库或微调。还有一个现在很常见的现象是，当你看到一个花哨的智能体（agent）框架时，就想直接使用。抽象最终是非常酷的，但应该包含最佳实践并且经过严格测试。我们现在仍处于学习最佳实践的阶段，很多抽象可能会引入一些不必要的、非常痛苦的bug。例如，框架中默认提示词的微小变动（如修复拼写错误）可能在你不知情的情况下导致应用性能发生变化。

这些听起来都像是我们可以把“生成式AI”替换成任何一种新技术或新架构，然后我们可能会听到类似的事情。因为它总是在变化，没有固定的最佳实践，没有人真正知道如何使用它。

是的，我完全同意。尽管技术会随着时间而改变，但系统性思维和解决问题的系统性方法通常不会改变。比如，如果你想解决问题，你首先要做的就是分解问题，看看挑战在哪里，然后尝试不同的解决方案。这听起来很平常，但我认为很多时候，我们会受到“错失恐惧症”（FOMO）的影响，这会阻碍我们进行深入思考。

对于一个正在学习生成式AI、希望进入AI工程领域的软件工程师，你会建议他们如何学习？

我认为学习有两种不同的方法：一种是基于项目的学习，另一种是结构化学习。基于项目的学习是选择一个项目并全身心投入，解决其中的问题。结构化学习更像是参加课程或读书。我确实认为基于项目的学习非常有价值，但它不总能覆盖所有知识点。所以有时学生需要通过结构化学习来补充。

在基于项目的学习中，很多人会跟着教程做。教程很酷，但人们很容易只是机械地操作，而没有真正停下来思考“为什么”。能够停下来提问非常重要，有时结构化学习能帮助你提出正确的问题。所以，我会推荐两者结合：选择一些你想做的项目，同时辅以一些结构化学习，比如读一本好书，或者和朋友一起学习一门课程，阅读论文。

另外一个有用的练习是：花一周时间观察自己做了什么，记录下来，然后思考其中有多大比例可以被AI自动化，哪些事情可以由AI完成。然后尝试用AI去做那些事，这会给你很多关于用例的想法。

现在有很多关于“AI将终结软件工程”的危言耸听。你对此有何看法？

我们可以用写作来打比方。过去，写作指的是把文字写在纸上的物理行为。但后来有了电脑，写作指的是将想法组织成可读格式的过程。我认为编码也是如此。现在人们认为软件工程就是把代码敲到编辑器里的物理行为，但那并不是工程的全部。工程是关于解决问题的，设计出可执行的程序来解决这个问题，编码本身只是其中的物理行为。AI可以帮助自动化编码，但我不认为它能完全自动化问题解决，因为你仍然需要知道问题是什么。

而且，软件工程需要非常精确。编程语言被发明出来就是为了非常精确、没有歧义。从自然语言到编程语言的转换非常模糊。对于商业或专业用例，你将需要那些能够保证你得到你想要的确切结果的人。

我其实非常期待AI能够自动化一部分编码工作，因为它实际上能让软件工程师去做更复杂的软件。就像写作一样，以前手动抄写时书都很短，现在我们有数十万字的书籍。如果不必手动编写代码，而是能快速地将想法转化为代码片段，我认为这能让我们运行更复杂得多的软件。

是的，也许一个软件工程师就能驾驭更多软件，调试或维护一个复杂得多的系统。

除了编码之外，你还对AI可能带来的哪些其他用例感到兴奋？

我对教育领域感到兴奋。AI可以帮助人们更快地学习他们想学的东西。现在如果你知道问题，找到答案相当容易，但真正困难的仍然是如何提出正确的问题。教育需要专注于培养学生提问的习惯和理解能力。

我还对娱乐行业感到兴奋。我们可以有那种能帮助我们学习更多东西的游戏，比如教我们谈判知识的策略游戏，或者更具智力启发性的电影或节目。AI可以帮助我们创作既有趣又有智力启发性的内容，也可以帮助进行不同媒介内容的转换和改编。

我还认为，企业或公司的组织结构将会发生变化。中层管理的职责之一是信息聚合与传递，这实际上是AI可以做得非常好的一件事。所以我确实认为公司可以变得更有效率。

让我们用一些快速问答来结束。你在构建AI应用或从事机器学习工程时，最常使用哪种编程语言？为什么？

Python和JavaScript。JavaScript在我需要快速构建演示产品时非常方便，这是构建产品非常重要的一部分。AI现在也帮我更容易上手JavaScript了。

那么，你目前最喜欢的LLM模型是哪一个？为什么？

我并没有特别喜欢的。我会根据不同的用途使用不同的模型。我习惯性地使用 ChatGPT，因为我已经为它准备好了一堆提示词。我有时会用 Claude 来进行一些创意写作。也用过像 LLaVA 这样的模型进行一些有趣的用例测试。但我对它们都没有什么情感上的依恋。

你用过并且喜欢的一个简洁好用的AI工具是什么？

我构建了一些真正帮助我做研究的东西。比如，当我看到一个论文链接时，我会遵循同样的流程：阅读摘要，查找作者的其他工作，提出问题，检查引用情况。所以我做了一个小工具，它会扫描链接，然后把所有相关信息都给我。现在AI的美妙之处在于，你可以花很少的时间就构建一个只为你自己服务的工具。

那么，你读过并且会推荐的一两本书是什么？

我喜欢那些能给我新视角，或者让我对我不了解的主题有深入见解的书。比如《复杂适应系统》（Complex Adaptive Systems），一本关于系统思维的有趣的书。我喜欢《自私的基因》（The Selfish Gene），它让你更多地了解自由意志。我还喜欢纳西姆·塔勒布的《反脆弱》（Anti Fragile）。

感谢你参与这次播客。人工智能工程是一个如此新的领域，能听到你的见解真是太好了。

非常感谢。我真正享受写作或交谈的一点是得到反馈。我更喜欢的是一些反驳，比如：“你没有考虑到这个”，“你忘了这个”。所以我非常希望得到这些反馈。