Laurie Voss：为 AI 智能体建立评估循环

我是 Arize AI 开发者关系负责人 Laurie Voss。工作坊用一个刻意设计得不完善的金融分析智能体构建评估循环；股票输出只是示例，不是投资建议。

TypeScript 项目包含检查点，即使设置或现场运行失败，参与者也能继续。示例用 Phoenix 保存轨迹、用 Claude 运行智能体，但评估原则适用范围更广。

AI 应用在几次试用中可能看起来不错，遇到意外输入却失败。修改提示词可能修复一种行为，同时悄悄破坏另一种行为。评估可以让这些变化可见。

目标是记录智能体轨迹、编写代码和模型检查、测试评判器、比较修改，并把选定的回归测试放进 CI。任何一步都不能让系统永不出错。

轨迹记录发生了什么，包括智能体步骤、模型调用、工具输入输出、耗时，有时还有成本。span 是其中一个步骤，可以嵌套构成完整运行。

评估询问记录中的某个行为或输出是否符合要求。与精确字符串断言不同，它可以考虑同一问题存在多个有效回答。

看三个答案后说它们不错，并不能构成测试集。模型每次可能产生不同措辞，所以仅靠精确匹配往往会漏掉真正重要的东西。

修正语气时，可能意外引入没有依据的产品说法。可重复的评估集有助于发现回归，而不是等客户发现。

代码评估器可以快速检查结构化属性，例如 JSON 是否有效、长度或必填字段。属性能被确定性表达时很有用，但检查也可能过于僵硬。

LLM 评判器依据评分标准判断语义问题，例如答案是否遵循来源。它耗费时间和费用，也可能自信地出错，因此评判器本身必须接受测试。

领域专家可以检查细微或陌生的失败，并标注案例来检验评判器。代码、模型和人工检查彼此补充，而不是互相替代。

智能体增加了复杂度：早期错误可能通过工具调用和后续推理不断传播。一份看似精致的报告仍可能写错对象，或建立在错误数据上。

Voss 介绍一个智能体找到基准测试未预料到路径的例子。教训是清楚规定预期成果，并检查测试是否错误拒绝了有效解法。

评估通常返回分数和标签；LLM 评判器还可能给出解释。解释有助于发现反复出现的失败模式，但应加以核实，不能当作证明。

循环包括记录轨迹、阅读、评估、检查评估器、修改智能体、比较结果并保留有用检查。Voss 把它看作迭代过程，而不是单一基准分数。

Phoenix 收集轨迹，并把评估结果与之保存在一起。示例可以在本地运行，团队也可以根据自己的数据和访问要求选择部署方式。

工作坊项目把埋点、智能体逻辑、提示词、评估函数和测试查询分开。示例智能体先研究股票代码，再根据研究撰写报告。

Voss 展示基于 OpenTelemetry 的追踪设置。根据框架和配置，埋点可能自动捕获嵌套模型及工具调用，而不必为每一步手写日志。

她的 TypeScript 示例有一个细节：要使用辅助函数返回的已埋点副本。如果直接导入原模块，应用可能仍能运行，却没有预期轨迹。

示例智能体可以搜索网页，并在没有交互式权限提示的模式下运行。设置将它与讲者本地智能体配置隔离，以提高演示的可重复性。

会话 ID 将研究轮次与报告撰写轮次连接起来。父 span 把两轮组合起来，让读者能在一条轨迹中跟踪完整过程。

初始提示词刻意写得简短。参与者可以各自修改，再比较歧义如何影响智能体的选择。

现场示例中，智能体自行选择搜索词和搜索次数，然后撰写报告。即使输入相同，不同运行也可能采用不同路径。

一次运行试图保存文件并请求权限，尽管它处于无人值守模式。提示词只说写报告，没有说明放在哪里；轨迹揭示了失败的工具调用。

轨迹展示研究和撰写 span、网页搜索及失败的写入。这样可以区分指令含糊与模型或工具失败。

Voss 让参与者批量运行不同查询，而不是从一个例子得出结论。现场批量运行无法完成时，可以使用预置数据。

测试集包括公司比较、口语问题和虚构股票代码。虚构代码用于检查智能体能否承认无法识别公司，而不是编造一家。

评分之前，应与产品和领域相关人员一起定义好报告的标准。本练习的期望属性包括公司正确、证据及时和结论清晰。

合成查询可以作为测试集起点，但需要人检查，因为生成案例可能漏掉真实用户的行为。有真实流量后，在妥善处理数据的前提下可以补充有价值的案例。

在自动评估前，先从头到尾阅读一批轨迹。如果还不理解失败就自动化，可能测量的是容易测量的东西，而不是真正重要的东西。

编码智能体可以帮助整理更多轨迹，但人工抽样仍有价值，因为辅助工具可能漏掉失败或分类错误。

在一次运行中，虚构股票代码被正确识别为无效。其他运行产生含糊建议，或未经授权尝试写文件，展示了不同类型的失败。

一个 Tesla 示例把不同搜索结果的百分比混在一起，总计约 116%。这个错误说明流畅的报告也可能合并不相容的数据；这些数字是错误的示例输出。

Voss 区分检索不佳、推理错误、编造事实和回答错问题。看到的错误答案只是症状；原因决定应该修复什么。

她建议先用普通语言写下观察，再把观察归类。过早决定类别可能掩盖团队没有预料到的失败模式。

没有任何一种评估能抓住所有失败。应组合代码检查、模型评判器和人工审查，让不同盲区不易重合，同时仍需测试每一层。

应同时根据频率和严重程度确定优先级。罕见但严重的失败可能比常见的表面问题更需要先处理。

第一个代码评估器检查报告是否提到请求的股票代码。结构化输入便于提取代码，并返回标签、分数和缺失项目。

检查无需再次调用模型，因此运行很快，并找到了部分漏掉请求对象的报告。在本练习中，提到股票代码是必要条件，但不能证明报告准确。

代码评估器也可以检查数据库状态、工具结果或外部参考。应选择符合预期成果的检查；除非过程本身重要，否则固定工具顺序可能过于限制。

LLM 评判器由模型、评分标准和待评分数据组成。内置评估器可以覆盖正确性、忠实度或工具使用等类别，但仍须测试其是否适合场景。

Voss 用另一个模型评分，并讨论同一模型家族偏好可能带来的偏差。更强或不同的评判器不会自动正确；应与人工标注比较。

在她的样本中，内置正确性评估器把 16 份报告全部判错。解释显示，评判器缺少核实部分说法所需的较新市场数据。

有些解释也指出真实的算术或日期问题。因此统一的零分混合了真实错误与无法回答问题的评估器；单看分数并不够。

忠实度提出更窄的问题：给定来源材料，报告是否以这些材料为依据？Voss 同时提供搜索结果和研究笔记，给评判器相关上下文。

评判器在样本中标记了缺少依据或混淆的数据。忠于给定材料很有用，但不能证明来源材料本身真实。

工具评估可以检查工具选择、参数和结果使用方式。判断工具选择时，评估器需要知道有哪些工具可用，而不只是调用了哪个工具。

工具评判器有时认为保存文件合理，因为原指令只说写报告，没有指定位置。必须一起考虑智能体指令和评估标准。

Voss 总结说，提出正确问题比调优一个测错内容的评估器更重要。随后她为这项练习构建自定义可执行性评判器。

她的评分标准给评判器提供背景和明确条件，例如具体建议、有依据的风险及前瞻性分析。这些是工作坊标准，不是可靠投资建议的公式。

她明确标记输入、输出和示例，让评判器区分数据与指令。这种边界可以减少混淆，但不能完全防御提示注入。

示例可能澄清评分标准，也可能导致过拟合。Voss 比较有示例和无示例的版本，而不是假设示例越多越好。

在一个边界案例中，她的人工标注接受了没有风险部分的建议，而评判器更严格地解释评分标准。分歧暴露了标准和人工标注中的歧义。

示例把评判器的可选标签限制为“可执行”或“不可执行”。结构化输出更容易处理，但本身不会让判断可靠。

16 份样本报告中有 5 份通过她的可执行性检查。这个分布提供了可检查的通过与失败案例，而不是证明生产性能。

评估提示词对措辞和格式很敏感。应进行版本管理、测试变更，并为不同维度保留独立评估器，而不是把所有标准塞进一个难以解释的评判器。

保护性底线可以作为阻止发布的条件；目标则可以跟踪改进，不一定阻止发布。团队应根据自己的产品和风险决定如何区分。

测试评判器时，应把它视为分类器，并将其标签与专家标注的案例比较。人工标签是本练习可用的参考，但也可能不一致。

Voss 标注了 16 份报告，称之为黄金数据集。她强调使用与评判器相同的标准并避免疲劳；少量认真标注的案例可能比大量草率案例更有用。

遇到困难案例时应持续补充，并同时检查需要某种行动和不需要该行动的情况。否则评估器可能奖励智能体每次都执行同样的动作。

将开发案例和保留的测试案例分开。她的 16 个示例只留下 4 个测试案例，远不足以支撑有力的生产结论。

元评估让评判器处理已标注案例，再用代码检查其标签是否与人工一致。在 12 个开发案例上达成一致只是初步信号，不能证明普遍可靠。

在她的小样本中，一次意在消除歧义的评分标准修改反而降低了一致性。这说明评估器本身也需要版本管理、测试和保留集。

精确率问的是被标记为失败的案例中有多少真正失败；召回率问的是所有真实失败中有多少被标记。两者的重要性取决于漏报和误报的代价。

评判器可能存在位置、长度、自信程度和自我偏好等偏差。应交换候选顺序、检查错误并与人工判断比较，而不是假设评判器中立。

人工审查者也可能意见不一致。出现分歧时应检查标准和案例，而不能自动认定人或模型中的某一方正确。

实验使用相同输入和评估器比较修改。Voss 为集中开发建立失败案例数据集，同时保留通过案例检查回归。

她根据观察到的失败修改提示词：要求明确建议、让风险有证据、使用有来源的数字，并直接返回报告而不是尝试未经授权的文件写入。

实验由数据集、任务和评估器组成。Phoenix 在案例上运行任务并保存结果，以便比较不同版本。

小型数据集可以提供粗略的开发信号，但更有力的结论需要更大且有代表性的样本。模型行为会变化，因此重复运行很重要。

Voss 区分 pass@k，即 k 次尝试中至少成功一次，与 pass^k，即每次尝试都成功。哪种指标有用取决于能否重试以及失败的代价。

她建议先检查数据质量，再考虑提示词和模型选择。最佳顺序可能因应用而异，但不可靠的输入会限制后续调优能达到的效果。

在她的样本中，修改提示词改善了股票代码与可执行性检查，但忠实度仍然很差：修改后 48 次运行只有 3 次通过。演示并没有展示一个可靠的金融分析师。

能力评估衡量系统正在努力改善的行为。当检查足够稳定地通过后，可以把它变成回归检查，发现未来退化。

她在同一任务上比较更新的模型。在有限运行中，忠实度有所改善但仍然很差，成本也增加；这些数字只描述该配置。

一致性提高的部分原因是新模型反复选择同一种建议。指标可能因为不希望出现的原因改善，因此要检查单独输出和失败解释。

价值在于循环：运行评估、阅读失败、找出模式、修改数据、工具或提示词，然后再次比较。单一分数不能替代调查。

在 CI 示例中，测试运行器使用严格的股票代码检查和平均可执行性阈值。这些阈值只是示例选择，不应不考虑真实风险就照搬。

构建失败时会报告哪个验收条件未满足及其原因。同一测试集可以在 CI 中运行，但完整智能体评估适合多频繁执行取决于成本和耗时。

Voss 建议部署后继续评估经过适当处理的真实流量样本，关注持续变化，而不是对每次孤立失败都发出警报。

可以从小处开始：为应用添加追踪，阅读十来条轨迹。然后把观察到的问题变成针对性检查，验证这些检查，再逐步扩展循环。