使用 Fireworks 构建成本降低 100 倍的轨迹评判器（7 分钟阅读）

# 用 Fireworks 构建一个便宜 100 倍的 Trace Judge 来源：https://www.langchain.com/blog/building-a-100x-cheaper-trace-judge-with-fireworks 如今，Agent 生成了全球大部分数据（https://www.cnet.com/tech/services-and-software/its-official-agentic-bots-surf-the-web-more-than-real-people-do/），并驱动着我们日常使用的许多应用。随着越来越多的 Agent 投入生产环境，traces（https://docs.langchain.com/langsmith/observability-concepts#traces）将成为最丰富的数据源之一，帮助我们理解 Agent 系统在与真实用户交互时的行为。 **研究问题：** 我们如何**经济高效地**从每一条 trace 中挖掘重要信号，同时保持**前沿性能**？ 为了解决这个问题，我们与 Fireworks（https://app.fireworks.ai/account/home）合作，微调了一个基于 Qwen 的评估模型，用于检测用户交互中的“感知错误”。 **什么是感知错误：** > 感知错误是指用户认为助手犯了错误，或产生了需要纠正的内容。感知错误不评判客观正确性或用户满意度。例如，一个 Agent 可能给出了正确答案，但用户对信息本身（而不是 Agent）感到沮丧。 我们通常建议团队构建应用特定的评估器，因为判断一条 trace 的逻辑通常需要了解该应用的上下文。然而，我们相信“感知错误”是一个可以通用的评估器示例。我们认为它所寻找的信号在各种应用中都是通用的。 “感知错误”的通用性是一个关键问题。我们后续运行的一些实验正是为了测试这一指标的通用性。 我们从 trace 信号中推断感知错误，例如用户纠正、拒绝 Agent 动作、重复请求，以及助手承认错误。然后，感知错误评估器会以如下格式将信息丰富到 trace 中： `{"perceived_error": true, "reason": "The user corrects the meeting date the assistant used."}` ## 我们如何创建数据集 应用于任务的 Agent 的质量取决于训练它们所用的数据。我们从两个内部 tracing 数据集中获取数据，这些数据集在生产环境中使用： **chat-langchain**（https://github.com/langchain-ai/chat-langchain） *一个文档问答 Agent，用于回答关于 LangChain 库和产品的问题。用户可能提出概念性问题、调试问题或寻求构建帮助。这些交流通常涉及技术细节，内容详尽。* **Fleet**（https://www.langchain.com/langsmith/fleet） *一个无代码工具，用于创建能够执行实际工作的 Agent，如撰写文档和进行研究。用户可能使用 Fleet 完成各种任务，调用许多不同的工具或技能。* 我们从每个 tracing 数据集中选取了一部分 trace 作为训练集和保留集。在从 trace 池中筛选时，我们选择了多轮交互的 trace，因为判断“感知错误”需要人类对 AI 结果做出响应（例如，纠正助手或重复请求）。 使用多个数据集的动机之一是为了测试“感知错误”的通用性。在一个数据集上训练出的检测感知错误的模型能否迁移到第二个数据集？ | 数据集 | 总示例数 | 训练行数 | 保留行数 | | --- | --- | --- | --- | | chat-langchain | 885 | 707 | 178 | | Fleet | 911 | 727 | 184 | ### 数据准备 在准备训练和预测数据时，我们选择只包含人类和 AI 消息，忽略所有工具调用。我们这样做是因为假设对于我们寻找的信号，人类和 AI 消息是主要信息来源。这是一个我们计划未来实验的杠杆。 我们还保留了所有消息的原始内容，不做内容截断。这也是我们计划未来实验的另一个杠杆。 ### 标签 为了生成标签，我们结合了模型辅助标注和人工审核，为每条 trace 创建了简短的 JSON 标签和理由。具体来说，我们首先让一组模型对一条 trace 进行判断。如果它们意见一致，我们将其作为真实标签。如果意见不一致，我们将所有标签和理由传递给另一组模型，让它们判断谁是正确的。如果这组模型意见一致，我们将其作为真实标签。如果仍然不一致，我们手动进行人工标注。在整个数据集中，chat-langchain 和 Fleet 分别有 24% 和 18% 的 trace 带有感知错误标签。 ## 微调设置 在运行了一些小规模实验测试其他模型后，我们选择了 `Qwen-3.5-35B` 作为基础模型。更小的模型错误率较高，且不足以对我们的多轮 trace 进行推理。而 `Qwen-3.5-35B` 则是一个强大、廉价的开源模型，通过微调有潜力达到前沿性能。 我们只使用 chat-langchain 数据集的数据进行训练。这样做的原因是为了测试模型是否能迁移到完全不同的领域。 在观察到基础模型在小规模实验中的常见失败模式后，我们还对输入提示进行了轻微优化。在训练时，我们使用 Fireworks 上的托管 SFT 训练与 LoRA（https://docs.fireworks.ai/fine-tuning/supervised-fine-tuning）。 ## 实验与结果 我们围绕三个问题组织了实验： 1. 微调是否能将基线评估质量提升到前沿模型水平？ 2. 经过训练的评估器能否跨数据集迁移？ 3. 部署微调模型是否经济高效？ **微调开源模型可以超越或匹敌前沿模型** | 模型 | chat-langchain 准确率 | Fleet 准确率 | | --- | --- | --- | | 基础 Qwen | 90.5% | 83.2% | | chat-langchain SFT | 96.1% | 90.8% | | Fleet SFT | 92.7% | 91.3% | | Claude Opus | 91.6% | 90.2% | | GPT-5.5 | 98.9% | 89.1% | 我们发现，在适当提示下，基础 Qwen 在感知错误分类上已经是一个强大的开箱即用模型，但落后于前沿模型的分类准确率。在两个数据集上，运行 LoRA SFT 工作将基础模型提升到接近或超过前沿性能。 除了与前沿模型对比，我们还与更小、更便宜的模型进行了比较。运行高流量、低成本的推理工作负载的常见策略是使用最小的封闭前沿模型，如 Haiku。但我们始终发现，强大的开源模型在开箱即用时表现优于 Haiku，同时运行成本要低得多。 **微调后的评估器能很好地迁移到未见过的数据** （.png） 我们的初步结果显示，Fleet 对所有模型来说都是一个更具挑战性的数据集。在 chat-langchain 上微调后，我们测试了该模型在没有 Fleet 特定训练的情况下迁移到 Fleet 数据的效果。在 chat-langchain 数据上训练的模型在 Fleet 数据上优于所有前沿模型。 随后，我们尝试在 Fleet 数据上专门训练一个模型。与 chat-langchain SFT 模型相比，这带来了小幅提升。 这是一个重要的结果，因为： 1. 它表明我们的感知错误模型能够迁移到其他领域，并保持前沿水平的性能（在本例中略高于前沿）。 2. 对于希望在感知错误（或其他微调评估器）上进一步提升其数据集性能的构建者，他们可以选择在应用特定的 trace 上进行微调以获得进一步的性能提升。 **微调模型运行成本低得多** 微调模型达到前沿准确率，并且在大规模运行成本低得多——根据 trace 数量和模型选择，成本降低 10-100 倍。随着 trace 数量增长，微调模型带来的成本节约也会持续增加。在性能上，微调后的 Qwen 模型优于所有尺寸的 Haiku、Sonnet 和 Opus（以及 gpt-5.5）。 ## 关于 trace 理解的未来研究 解决持续学习问题需要应对围绕 trace 理解的大规模数据挖掘挑战。总的来说，我们很兴奋地推动关于构建专用、高性价比模型以更好地理解 trace 的配方。 开源模型已经跨越了一个智能阈值（https://www.langchain.com/blog/open-models-have-crossed-a-threshold），现在在许多任务上是强大的、开箱即用且高性价比的分类器。借助 Fireworks 的易用训练和推理基础设施，我们能够将开源模型推向前沿性能，同时运行成本低几个数量级。 未来的研究方向包括帮助团队设计良好的训练目标和评分标准，以构建他们自己的 Agent trace 评估器模型。我们越了解 Agent trace，就越能在改进 Agent 时做出更明智的决策。 ## 试用我们的感知错误模型 我们将在未来几周内向部分客户推出我们的微调感知错误模型，并在未来一两个月内进行更广泛的发布。如果您有兴趣测试这个感知错误评估器并提供反馈，请在此处（https://airtable.com/appWdRBlSecNOgErA/pagAEfUlHu4F35opm/form）注册。