在人工智能领域，软件工程师的工作融合了软件工程、AI工程、产品直觉以及用户同理心。这使得AI开发工作与传统软件开发既有相似之处，又叠加了新的复杂性。
面对AI领域日新月异的发展，工程师需要审视全局，思考如何培养前瞻性技能和思维模式以保持领先。近期阅读《O’Reilly AI工程》一书，启发人们深入探讨AI系统中的核心组成部分——评估（evals）。
一个核心观点是：AI工程化工作，其软件工程的属性往往多于AI模型本身的属性。
在OpenAI或Anthropic等研究实验室之外，大多数AI开发者并非从零开始训练模型。实际工作更多在于利用现有工具解决业务问题——例如为模型提供足够的相关上下文、调用API、构建RAG（检索增强生成）管道、实现工具调用等。所有这些都需要在传统的软件工程考量之上进行，如部署、监控和系统扩展。
换言之，AI工程并非取代软件工程，而是在其之上叠加了新的复杂性层级。
本文旨在探讨这些核心主题，希望能为读者带来启发。
AI应用栈的三大核心层
AI应用通常构建于三个核心层之上：1) 应用开发层；2) 模型开发层；3) 基础设施层。
大多数团队倾向于从顶层开始着手。鉴于强大的预训练模型已可随时取用，通常的做法是首先专注于产品构建，待后续需要时再深入模型开发或基础设施层。
正如O’Reilly所指出，“AI工程本质上是在软件工程栈中融入AI模型。”
为何评估至关重要，又为何充满挑战
在软件开发领域，对于快速迭代的团队而言，回归问题是一个主要痛点。发布新功能时，可能会在不知不觉中破坏其他部分。数周之后，一个隐藏在代码库深处的错误浮出水面，追溯其根源往往异常艰难。
一套全面的测试套件有助于及早发现并捕获这些回归问题。
AI开发面临着类似的问题。每一次改动——无论是提示词调整、RAG管道更新、模型微调还是上下文工程——都可能在一个方面提升性能，却在另一个方面悄然引入性能下降。
在诸多方面，评估对于AI系统而言，其作用正如测试之于软件：它们能及早发现回归问题，让工程师有信心快速迭代而不至于破坏现有功能。
然而，评估AI系统并非易事。首先，模型越是智能化，评估的难度就越大。如果一本图书摘要语无伦次，很容易判断其质量不佳；但如果摘要条理清晰，判断其优劣就变得困难得多。要判断摘要是否真正抓住了核心要点，而不仅仅是听起来流畅或事实正确，可能需要亲自阅读原书。
其次，AI任务往往是开放式的，很少存在唯一的“正确”答案，也几乎不可能整理出一份详尽无遗的正确输出列表。
第三，基础模型常被视为黑盒。尽管模型架构、训练数据和训练过程的详细信息有时会被审查或公开，但缺乏这些内部细节时，人们只能通过观察模型的输出来进行评估，这限制了对模型深层优势和劣势的理解。
AI评估的思维框架
评估通常可分为两大领域：定量评估和定性评估。
定量评估具有明确无误的答案。例如，数学问题是否正确解决？代码是否无错误执行？这类评估通常可以自动化，从而实现规模化检测。
而定性评估则存在于灰色地带。它们涉及解释和判断——例如批改论文、评估聊天机器人的语气，或者判断摘要是否“听起来合理”。
多数评估是两者兼而有之的混合体。例如，评估一个生成的网站，不仅要测试其是否执行了预期功能（定量：用户能否注册、登录等），还要判断用户体验是否直观（定性）。
功能正确性
定量评估的核心在于功能正确性：模型的输出是否真正实现了其预设的功能？
如果要求模型生成一个网站，核心问题是该网站是否满足其需求。用户能否完成关键操作？网站是否运行可靠？这与传统的软件测试非常相似，即针对一系列测试用例来验证产品行为。通常情况下，这类测试可以实现自动化。
与参考数据对比的相似度评估
并非所有任务都具有如此清晰、可测试的输出。翻译就是一个很好的例子：一句法语句子并没有唯一的“正确”英文译文，但可以通过与参考数据进行比较来评估输出。
其缺点在于：这种方法高度依赖参考数据集的可用性，而创建这些数据集既昂贵又耗时。尽管人工生成的数据被视为“黄金标准”，但越来越多的参考数据正通过其他AI系统进行引导生成。
衡量相似度有以下几种方式：
- 人工判断：由人类专家进行主观评估。
- 精确匹配：判断生成响应是否与某个参考响应完全一致，结果通常为布尔值。
- 词汇相似度：衡量输出在表面上的相似程度（例如，词语或短语的重叠）。
- 语义相似度：衡量输出是否表达了相同的含义，即使措辞不同。这通常涉及将数据转化为嵌入（数值向量）并进行比较。嵌入不仅用于文本——例如Pinterest等平台也将其应用于图像、查询乃至用户画像。
词汇相似度仅检查表面上的相似性，而语义相似度则深入挖掘更深层的含义。
以AI作为评估判官
有些任务几乎无法通过规则或参考数据进行清晰评估。例如，评估聊天机器人的语气、判断摘要的连贯性，或评论广告文案的说服力，都属于此类。人类可以完成这些评估，但人工评估难以规模化。
以下是构建此过程的方法：
- 定义结构化且可衡量的评估标准。明确关注点——例如清晰度、实用性、事实准确性、语气等。标准可以使用评分量表（1-5分）或二元检查（通过/不通过）。
- 将原始输入、生成输出以及任何支持性上下文提供给AI判官。AI判官随后会返回一个分数、标签，甚至包含评估解释的结果。
- 对大量输出进行聚合分析。通过在大型数据集上运行此过程，可以发现潜在模式——例如，注意到模型更新后实用性下降了10%。
由于此过程可自动化，因此实现了持续评估，借鉴了软件工程中的CI/CD（持续集成/持续部署）实践。评估可以在管道变更（从提示词调整到模型升级）前后运行，也可用于持续监控，以及时捕获漂移和回归问题。
当然，AI判官并非完美无缺。正如不能完全信任单个人的意见，也不应完全信任单一模型的判断。但通过精心设计、结合多个判官模型，或对大量输出进行评估，它们可以提供可扩展的人类判断近似值。
评估驱动开发
O’Reilly提出的评估驱动开发概念，灵感来源于软件工程中的测试驱动开发，这一概念值得分享。
核心理念很简单：在构建之前定义评估。
在AI工程中，这意味着要明确“成功”的定义以及如何衡量它。
最重要的仍然是实际影响，而非一时的炒作。正确的评估能够确保AI应用以对用户和业务有意义的方式展现其价值。
在定义评估时，以下是一些关键考量：
领域知识
尽管在代码调试、法律知识、工具使用等诸多领域存在公共基准，但它们往往较为通用。最有意义的评估通常源于与利益相关者深入探讨，明确对业务真正重要的内容，然后将其转化为可衡量的结果。
如果解决方案不切实际，仅仅正确是不够的。例如，一个文本转SQL模型可能生成正确的查询，但如果它需要10分钟才能运行完成或消耗大量资源，那么在规模化应用中就缺乏实用价值。运行时长和内存使用量同样是重要的评估指标。
生成能力
对于生成式任务——无论是文本、图像还是音频——评估可能包括流畅性、连贯性以及相关性等特定于任务的指标。
一份摘要可能事实准确，但却遗漏了最重要的要点——评估应能捕捉到这一点。如今，这些质量本身也越来越多地可以通过另一个AI系统进行评分。
事实一致性
输出需要对照事实来源进行核查。这可以通过以下几种方式实现：
- 局部一致性
这意味着根据提供的上下文验证输出。这对于自身独特且范围有限的特定领域尤其有用。例如，提取的洞察力应与所提供的数据保持一致。
- 全局一致性
这意味着根据开放知识源验证输出，例如通过网络搜索或市场调研进行事实核查。
- 自我验证
当模型生成多个输出时，通过衡量这些响应之间的一致性来实现。
安全性
除了不包含不雅词汇和露骨内容等传统意义上的安全概念外，安全性实际上可以通过多种方式定义。例如，聊天机器人不应泄露敏感客户数据，并且应具备防范提示词注入攻击的能力。
总结
随着AI能力的不断增长，强大而全面的评估将变得愈发重要。它们是保障工程师快速迭代而不牺牲系统可靠性的重要防线。
实践证明，系统的可靠性极具挑战性，而回归问题则代价高昂。它们不仅损害公司声誉、使用户感到沮丧，还会给开发人员带来痛苦的开发体验，使工程师陷入反复追逐相同错误的困境。
