构建大模型应用，有人认为其中大部分工作更像是传统的软件开发，而非纯粹的机器学习或数据科学，毕竟我们通常是使用现成的基础模型，而非亲自训练。即便如此，构建基于大模型的应用时，一个至关重要的环节仍围绕着数据，尤其是其评估流程。无法衡量的事物就无法改进，无法理解的事物也无从衡量。因此，要建立一个评估流程，仍然需要投入大量精力去审查、理解和分析数据。
本文旨在记录构建基于大模型应用的评估流程的一些心得体会，以及将在线阅读到的理论概念（主要来自 Hamel Husain 的博客）应用于具体案例的一次实践。
文章目录
-
应用场景 – 阐述具体的应用情景和用例。
-
评估流程 – 评估流程概览及其主要组成部分。每个步骤将分为：
- 概述 – 对该步骤进行简要的概念性解释。
- 实践 – 根据用例，提供概念应用的具体示例。
-
未来展望 – 这仅仅是开始。评估流程将如何演进？
-
总结 – 回顾关键步骤和最终思考。
1. 应用场景
为了具体化讨论，采用一个具体案例：一个AI驱动的IT服务台助手。
该AI作为一线支持。员工提交描述技术问题的工单——笔记本电脑运行缓慢、无法连接VPN或应用程序崩溃。AI的任务是分析工单，提供初步故障排除步骤，并解决问题或将其转介给适当的人工专家。
评估该应用的性能是一项主观任务。AI的输出是自由格式文本，这意味着没有单一的“正确”答案。一个有用的响应可以通过多种方式表达，因此不能简单地检查输出是否是“选项A”或“选项B”。这也不是一个回归任务，无法使用均方误差（MSE）等指标来衡量数值误差。
“良好”的响应由多种因素共同定义：AI是否正确诊断了问题？是否提出了相关且安全的故障排除步骤？是否知道何时将关键问题转介给人工专家？一个响应可能事实正确但无用，或者可能因为未能转介严重问题而失败。
- 背景：IT帮助台场景作为一个替代案例，以便公开讨论其方法论。这个类比并非完美，因此某些例子可能会为了阐明特定观点而显得有些牵强。
2. 评估流程
在理解了用例之后，接下来将概述提议的评估流程。在接下来的章节中，将详细介绍每个部分，并通过与用例相关的示例进行情境化。
提议的评估流程概览，展示了从数据收集到可重复、迭代改进的循环。图片由作者提供。
数据准备
一切都始于数据——理想情况下，是来自生产环境的真实数据。如果尚未获取，可以尝试自行使用应用程序或邀请朋友试用，以了解其可能出现的故障模式。在某些情况下，如果数据量较少，可以生成合成数据来启动或补充现有数据。
使用合成数据时，请确保其质量高且与真实世界数据的预期高度匹配。
尽管大模型相对较新，但人类在研究、训练和认证方面已有相当长的时间。如果可能，尝试利用为人类设计的现有材料，帮助为应用程序生成数据。
实践经验
初始数据集规模较小，包含少量来自生产环境的真实用户工单，以及领域专家为涵盖常见场景而创建的一些演示示例。
由于没有很多示例，因此利用了IT支持专业人员的现有认证考试材料，其中包含带答案指南和评分键的多项选择题。这样不仅获得了正确答案，还获得了每个选项为何错误或正确的详细解释。
利用大模型将这些考题转换为更实用的格式。每个问题都变成了一个模拟用户工单，答案键和解释则被重新利用，以生成有效和无效AI响应的示例，并附有明确的理由。
使用外部资源时，务必注意数据污染问题。如果认证材料是公开可用的，它可能已被包含在基础模型的训练数据中。这可能导致评估的是模型的记忆能力，而非其在新颖、未见过的问题上进行推理的能力，从而产生过于乐观或误导性的结果。如果模型在此数据上的表现异常完美，或其输出与源文本高度匹配，则很可能存在污染。
数据标注
收集到一些数据后，下一个关键步骤是分析数据。这个过程应该是积极的，务必在进行时记录心得。数据标注涉及的各种任务有多种分类或划分方式。通常会将此过程分为两个主要部分：
- 错误分析：审查现有（通常不完善的）输出以识别故障。例如，可以添加自由文本笔记解释故障，或用不同的错误类别标记不充分的响应。可以在Hamel Husain 的博客上找到更详细的错误分析解释。
- 成功定义：创建理想的工件来定义成功的标准。例如，对于每个输出，可以编写真实参考答案，或制定包含理想答案应包含内容的指导方针。
主要目标是更清晰地理解数据和应用程序。错误分析有助于识别应用程序面临的主要故障模式，从而解决根本问题。同时，定义成功有助于建立适当的标准和指标，以准确评估模型的性能。
无须担心如何精确记录信息。最好从开放式笔记和非结构化标注开始，而不是纠结于完美的格式。随着时间的推移，需要评估的关键方面和常见的故障模式将自然而然地浮现。
实践经验
采取的方法是首先创建一个定制工具，专门用于数据标注，使其能够扫描生产数据，添加注释，并生成前面讨论的参考答案。发现这是一个相对快速的过程，因为可以构建一个相对独立于主应用程序的工具。考虑到这是一个供个人使用且范围有限的工具，可以“凭感觉”编写代码，无需像在常规设置中那样担心。当然，仍会审查代码，但不太担心偶尔出现问题。
该过程最重要的成果在于，逐渐了解了什么构成一个糟糕的响应，什么又构成一个优秀的响应。有了这些认识，就可以定义评估指标，有效地衡量对用例至关重要的因素。例如，意识到解决方案存在“过度转介”的行为，即倾向于将简单请求转介给人工专家。其他问题，程度较轻，包括不准确的故障排除步骤和不正确的根本原因诊断。
编写评估标准
在定义成功的步骤中，发现编写评估标准（rubrics）非常有帮助。创建评估标准的指导原则是：什么构成一个理想的、优秀的响应？这有助于减少评估过程的主观性——无论响应如何措辞，它都应符合评估标准中的所有要求。
考虑到这是评估过程的初始阶段，不会预先知道所有整体标准，因此会根据具体示例来定义要求，而不是试图为所有示例建立单一的指导方针。也没有过于担心设定严格的模式。评估标准中的任何条件都需要有一个键和一个值。可以选择该值是布尔值、字符串或字符串列表。评估标准可以灵活，因为它们旨在供人工或大模型评判器使用，两者都可以处理这种主观性。此外，如前所述，随着该过程的持续，理想的评估标准指导方针将自然而然地稳定下来。
以下是一个示例：
{
"fields": {
"clarifying_questions": {
"type": "array<string>",
"value": [
"询问具体的错误消息",
"询问用户是否最近更改了密码"
]
},
"root_cause_diagnosis": {
"type": "string",
"value": "用户凭据过期或MFA令牌同步问题"
},
"escalation_required": {
"type": "boolean",
"value": false
},
"recommended_solution_steps": {
"type": "array<string>",
"value": [
"引导用户重置公司密码",
"指导用户重新同步MFA设备"
]
}
}
}
尽管每个示例的评估标准可能不同，但可以将其分组为明确定义的评估准则，以用于下一步。
运行评估
有了标注好的数据，就可以建立一个可重复的评估流程。第一步是策划标注示例的子集，以创建一个版本化的评估数据集。该数据集应包含代表性的示例，涵盖应用程序的常见用例以及所有已识别的故障模式。版本控制至关重要；在比较不同实验时，必须确保它们与相同的数据进行基准测试。
对于像自由格式文本输出这样的主观任务，“大模型作为评判器”（LLM-as-a-judge）可以自动化评分过程。评估流程会向大模型评判器提供数据集中的输入、AI应用程序的相应输出以及创建的标注（例如参考答案和评估标准）。评判器的作用是根据提供的标准对输出进行评分，将主观评估转化为可量化的指标。
这些指标允许系统地衡量任何更改的影响，无论是新的提示词、不同的模型，还是RAG策略的改变。为了确保这些指标有意义，定期验证大模型评判器的评估结果与人类领域专家的评估结果在可接受范围内保持一致至关重要。
实践经验
完成数据标注过程后，应能更清晰地了解什么构成好的或坏的响应，并以此知识为基础，建立一套核心评估维度。在这种情况下，识别出以下几个方面：
- 转介行为：衡量AI是否适当地转介工单。响应被评定为“适当”、“过度转介”（将简单问题上报）或“转介不足”（未能上报关键问题）。
- 根本原因准确性：评估AI是否正确识别用户问题。这是一个二元评估，分为“正确”或“不正确”。
- 解决方案质量：评估建议的故障排除步骤的相关性和安全性。它还考虑AI在提供解决方案之前是否询问了必要的澄清信息。评定为“适当”或“不适当”。
定义了这些维度后，就可以运行评估了。对于版本化评估集中的每个项目，系统都会生成一个响应。此响应，连同原始工单及其标注的评估标准，然后传递给大模型评判器。评判器会收到一个提示词，指示它如何使用评估标准来评估响应在这三个维度上的表现。
以下是用于大模型评判器的提示词：
您是一位专业的IT支持AI评估员。您的任务是判断AI生成的IT帮助台工单响应的质量。为此，您将获得工单详情、高级IT专家提供的参考答案以及包含评估标准的评分细则。
#{ticket_details}
**参考答案（来自IT专家）：**
#{reference_answer}
**新的AI响应（待评估）：**
#{new_ai_response}
**评分细则标准：**
#{rubric_criteria}
**评估说明：**
[此处为评估说明...]
**评估维度**
请根据以下维度评估AI响应：
- 总体判断：良好/糟糕
- 转介行为：如果评分细则中的`escalation_required`为`false`但AI进行了转介，则标记为`过度转介`。如果`escalation_required`为`true`但AI未进行转介，则标记为`转介不足`。否则，标记为`适当`。
- 根本原因准确性：将AI的诊断与评分细则中的`root_cause_diagnosis`字段进行比较。标记为`正确`或`不正确`。
- 解决方案质量：如果AI的响应未能包含评分细则中必要的`recommended_solution_steps`或`clarifying_questions`，或者提出了不安全的建议，则标记为`不适当`。否则，标记为`适当`。
如果评分细则未能提供足够信息以评估某个维度，请使用参考答案和您的专家判断。
**请提供：**
1. 总体判断（良好/糟糕）
2. 详细的推理说明
3. 转介行为（过度转介/适当/转介不足）
4. 根本原因准确性（正确/不正确）
5. 解决方案质量（适当/不适当）
**响应格式**
请以以下JSON格式提供您的响应：
{
"JUDGMENT": "良好/糟糕",
"REASONING": "详细说明",
"ESCALATION_BEHAVIOR": "过度转介/适当/转介不足",
"ROOT_CAUSE_ACCURACY": "正确/不正确",
"SOLUTION_QUALITY": "适当/不适当"
}
3. 未来展望
当前应用设计简洁，评估流程也相对简单。随着系统扩展，需要调整衡量性能的方法。这意味着将来需要考虑以下几个关键方面：
多少示例才足够？
起始时使用了大约50个示例，但尚未分析这与理想数量的接近程度。理想情况下，期望有足够的示例来产生可靠的结果，同时保持运行成本可承受。在 Chip Huyen 的《AI Engineering》一书中，提到了一种有趣的方法，即创建评估集的引导样本。例如，可以从原始的50个样本集中，通过有放回抽样创建多个引导样本，然后评估并比较这些引导样本的性能。如果观察到截然不同的结果，则可能意味着评估集中需要更多示例。
在进行错误分析时，还可以应用Husain 博客中提到的一条实用经验法则：
持续迭代更多跟踪记录，直到达到理论饱和，这意味着新的跟踪记录似乎不再揭示新的故障模式或信息。通常情况下，目标是审查至少100条跟踪记录。
使大模型评判器与人类专家保持一致
期望大模型评判器尽可能保持一致，但这具有挑战性，因为判断提示词会进行修订，底层模型可能由提供商更改或更新，等等。此外，评估标准会随着对输出进行评分而随着时间推移而改进，因此至关重要的是，始终确保大模型评判器与自身判断或领域专家的判断保持一致。可以定期与领域专家安排会议，审查大模型判断的样本，并计算自动化评估与人工评估之间简单的协议百分比，当然，必要时调整评估流程。
过拟合
过拟合在大模型领域仍然是一个问题。即使没有直接训练模型，仍然通过调整指令提示词、优化检索系统、设置参数和增强上下文工程来“训练”系统。如果更改是基于评估结果进行的，则存在过度优化当前数据集的风险，因此仍然需要遵循标准建议来防止过拟合，例如使用保留集。
复杂性增加
目前，该应用保持简单，因此需要评估的组件较少。随着解决方案变得更加复杂，评估流程也会变得更加复杂。如果应用涉及多轮带记忆的对话，或者不同的工具使用或上下文检索系统，应将系统分解为多个任务并分别评估每个组件。到目前为止，一直使用简单的输入/输出对进行评估，因此直接从数据库检索数据就足够了。然而，随着系统演进，可能需要跟踪单个请求的整个事件链。这涉及采用日志记录大模型跟踪的解决方案，例如使用 Arize、HoneyHive 或 LangFuse 等平台。
持续迭代和数据漂移
生产环境不断变化。用户期望演变，使用模式转变，新的故障模式出现。今天创建的评估集可能在六个月后就不再具有代表性。这种转变需要持续的数据标注，以确保评估集始终反映应用程序当前的使用状态和不足之处。
4. 总结
本文涵盖了构建数据评估基础的一些关键概念，以及用例的实践细节。从一个小型、混合来源的数据集开始，逐步开发了一个可重复的测量系统。主要步骤包括积极标注数据、分析错误，并使用评估标准定义成功，这有助于将主观问题转化为可衡量的维度。在标注数据并对其有了更好的理解之后，使用大模型作为评判器自动化评分，并创建了一个持续改进的反馈循环。
尽管这里概述的流程只是一个起点，但接下来的步骤涉及解决数据漂移、评判器一致性和系统复杂性增加等挑战。通过努力理解和组织评估数据，将获得所需的清晰度，从而有效地进行迭代并开发更可靠的应用程序。
