人工智能工程和评估作为软件工作的新层次
人工智能工程和评估作为软件工作的新层次
在如此多的活动中，我想退一步，从更大的角度反思，以及工程师需要哪些技能和心智模型才能保持领先。最近阅读了《O’Reilly 的人工智能工程》，这促使我也想深入研究如何思考评估——这是任何人工智能系统中的核心组件。
一个突出的观点是：人工智能工程往往更像是软件而不是人工智能。
在像 OpenAI 或 Anthropic 这样的研究实验室之外，我们中的大多数人都不是从头开始训练模型。真正的工作是使用我们已有的工具解决商业问题——给模型提供足够的相关上下文，使用 API，构建 RAG 管道，调用工具——所有这些都是在通常的 SWE 关注点之上，如部署、监控和扩展。
换句话说，人工智能工程并不是在取代软件工程——它是在软件工程之上叠加新的复杂性。
这篇文章是我试图探讨这些主题中的一些。如果其中任何一个引起了你的共鸣，我很乐意听到你的想法——请随时在这里联系我！
人工智能应用堆栈的三个层次
将人工智能应用视为建立在三个层次之上：1）应用开发 2）模型开发 3）基础设施。
大多数团队都是从顶层开始的。由于现成的强大模型随时可用，因此通常先专注于构建产品，然后在需要时才涉足模型开发或基础设施，这样做是有意义的。
正如 O’Reilly 所说，“人工智能工程只是将人工智能模型加入堆栈的软件工程。”
为什么评估很重要以及为什么它们很困难
在软件领域，对于快速发展的团队来说，最大的头疼问题是回归。你发布了一个新功能，在这个过程中无意中破坏了其他东西。几周后，代码库的一个角落里出现了一个虫子，追踪它变成了噩梦。
拥有一个全面的测试套件有助于捕捉这些回归。
人工智能开发面临着类似的问题。每一次变化——无论是提示调整、RAG 管道更新、微调还是上下文工程——都可能在一个领域提高性能，同时悄悄地降低另一个领域的性能。
在许多方面，评估对于人工智能就像测试对于软件一样：它们可以早期捕捉回归，并给工程师带来信心，让他们可以快速行动而不会破坏事物。
但评估人工智能并不简单。首先，模型越智能，评估就越困难。如果一本书的摘要是一堆乱码，那么判断它是否糟糕很容易，但如果摘要实际上是连贯的，那就难多了。要知道它是否真正捕捉到了关键点，而不仅仅是听起来流畅或事实正确，你可能不得不亲自阅读这本书。
其次，任务通常是开放式的。很少有单一的“正确”答案，也不可能编纂一个包含所有正确输出的全面列表。
第三，基础模型被视为黑盒，其中模型架构的细节、训练数据和训练过程通常受到审查，甚至公开。这些细节揭示了模型的优势和劣势，没有它们，人们只能通过观察其输出来评估模型。
如何思考评估
我喜欢将评估分为两个广泛的领域：定量和定性。
定量评估有明确、无歧义的答案。数学问题是否正确解决？代码是否无错误执行？这些通常可以自动测试，这使得它们可扩展。
定性评估，另一方面，存在于灰色区域。它们关于解释和判断——就像评分一篇论文，评估聊天机器人的语气，或者判断一个摘要“听起来是否正确”。
大多数评估都是两者的混合。例如，评估一个生成的网站不仅意味着测试它是否执行了预期的功能（定量：用户能否注册、登录等），还意味着判断用户体验是否直观（定性）。
功能性正确性
定量评估的核心是功能性正确性：模型的输出实际上是否做了它应该做的事情？
如果你要求一个模型生成一个网站，核心问题是该网站是否符合其要求。用户能否完成关键操作？它是否可靠地工作？这很像传统的软件测试，其中你运行一个产品针对一系列测试用例来验证行为。通常，这可以自动化。
与参考数据相似度
并非所有任务都有如此清晰、可测试的输出。翻译是一个很好的例子：对于一句法语句子，没有单一的“正确”英语翻译，但你可以将输出与参考数据进行比较。
缺点是：这严重依赖于参考数据集的可获得性，创建这些数据集既昂贵又耗时。人工生成数据被认为是黄金标准，但越来越来，参考数据正由其他人工智能进行自举。
有几种方法来衡量相似度：
-
人类判断
-
完全匹配：生成的响应是否与参考响应之一完全匹配。这会产生布尔结果。
-
词汇相似度：衡量输出看起来有多相似（例如，单词或短语的重叠）。
-
语义相似性：衡量输出是否意味着相同的东西，即使措辞不同。这通常涉及将数据转换为嵌入（数值向量）并比较它们。嵌入不仅仅是文本——像 Pinterest 这样的平台使用它们来处理图像、查询甚至用户资料。
词汇相似性仅检查表面上的相似性，而语义相似性则深入到意义。
AI 作为评判者
有些任务几乎不可能用规则或参考数据干净地评估。评估聊天机器人的语气、判断摘要的连贯性或批评广告文案的说服力都属于这一类。人类可以做到，但人类评估无法扩展。
下面是如何构建这个过程：
-
定义一个结构化和可衡量的评估标准。明确你关心的是什么——清晰度、有用性、事实准确性、语气等。标准可以使用量表（1-5 评级）或二进制检查（通过/失败）。
-
将原始输入、生成的输出和任何支持性上下文提供给 AI 评判者。然后评判者会返回一个分数、标签甚至评估的解释。
-
对许多输出进行汇总。通过在大数据集上运行此过程，你可以发现模式——例如，注意到在模型更新后，有用性下降了 10%。
因为这可以自动化，它使得持续评估成为可能，借鉴了软件工程中的 CI/CD 实践。评估可以在管道更改前后（从提示调整到模型升级）运行，或用于持续监控以捕捉漂移和退化。
当然，AI 评判者并不完美。就像你不会完全信任一个人的意见一样，你也不应该完全信任模型。但通过精心设计、多个评判模型或对多个输出运行它们，它们可以提供可扩展的人类判断近似。
评估驱动开发
O’Reilly 讨论了评估驱动开发的概念，这是受到软件工程中测试驱动开发的启发，我觉得这个概念值得分享。
**想法很简单：在构建之前定义你的评估。
在 AI 工程中，这意味着决定“成功”看起来是什么样子以及如何衡量。**
影响仍然是最重要的——不是炒作。正确的评估确保 AI 应用以与用户和业务相关的方式展示价值。
在定义评估时，以下是一些关键考虑因素：
领域知识
公共基准在许多领域都存在——代码调试、法律知识、工具使用——但它们通常是通用的。最有意义的评估通常来自于与利益相关者坐下来定义对业务真正重要的事情，然后将这些转化为可衡量的结果。
如果解决方案不切实际，那么正确性就不够。例如，一个文本到 SQL 模型可能会生成一个正确的查询，但如果它需要 10 分钟才能运行或消耗大量资源，那么在规模上就没有用了。运行时间和内存使用也是重要的指标。
生成能力
对于生成任务——无论是文本、图像还是音频——评估可能包括流畅性、连贯性和特定任务的指标，如相关性。
摘要可能从事实上是准确的，但可能遗漏了最重要的要点——评估应该捕捉到这些。日益增多的是，这些质量本身也可以由另一个 AI 进行评分。
事实一致性
输出需要与一个真实来源进行核对。这可以通过两种方式发生：
-
局部一致性
这意味着验证输出与提供的上下文的一致性。这对于具有独特性和有限范围的特定领域特别有用。例如，提取的见解应与数据一致。
-
全局一致性
这意味着通过开放知识源进行输出验证，例如通过网络搜索或市场研究等进行事实核查等。
-
自我验证
这发生在模型生成多个输出时，并衡量这些响应之间的一致性。
安全性
除了通常的安全概念，如不包含粗俗和露骨的内容之外，实际上有很多方式可以定义安全。例如，聊天机器人不应泄露敏感的客户数据，并且应该能够防御提示注入攻击。
总结起来
随着人工智能能力的增长，稳健的评估将变得更加重要。它们是工程师快速移动而不牺牲可靠性的护栏。
我看到可靠性是多么具有挑战性，回归是多么昂贵。它们损害了公司的声誉，让用户感到沮丧，并创造了痛苦的开发体验，工程师们陷入反复追逐相同错误的困境。
随着工程角色之间的界限变得模糊，特别是在较小的团队中，我们在思考软件质量方面面临根本性的转变。现在，维护和衡量可靠性的需求已经超越了基于规则的系统，扩展到本质上概率性和随机性的系统。
浙公网安备 33010602011771号