当智能体框架一半是非确定性的，你如何实际测试它？

Reddit r/AI_Agents 新闻
agent-testing non-determinism llm-as-judge golden-tests software-engineering testing-practices

摘要

关于测试包含非确定性组件的AI智能体框架所面临的挑战的讨论，探讨了黄金输出差异比较和使用LLM作为评判者等方法，同时质疑这些方法的有效性。

在Lium遇到了这个问题，我很好奇其他人是怎么处理的？框架中确定性的部分很容易测试。重试逻辑、解析、路由等，都可以像普通代码一样进行单元测试。但一旦模型必须做出真正的判断，你该如何为它编写测试呢？你是检查精确输出并接受它会很脆弱，因为模型每次运行的措辞都可能不同？你使用另一个模型作为评判者，如果是这样，谁来测试评判者？你是运行五十次然后凭感觉判断是否足够正确？我首先尝试了黄金输出差异比较。即使智能体做对了，也常常失败，只是措辞不同。然后我改用LLM作为评判者一段时间，这效果更好，但我现在有了一个非确定性测试来评价一个非确定性系统，感觉这只是在将问题向上移动一层，而不是解决它。有人找到了真正有效的方法吗？大家是否已经接受智能体测试比普通软件测试更模糊，还是我遗漏了什么模式？
查看原文

相似文章

最好的智能代理工具会这样做……

Reddit r/AI_Agents

作者分享了构建高效智能代理工具的见解：最好的工具最大限度地减少对大语言模型（LLM）在琐碎任务上的依赖，将其保留用于复杂推理，从而将真正的代理工具与简单的包装器区分开来。

停止在不公开执行框架的情况下比较LLM智能体

arXiv cs.AI

这篇立场论文认为，在长期跨度的LLM智能体任务中，执行框架（即围绕语言模型的上下文构建、工具交互、编排和验证的基础设施层）往往比模型本身更能决定性能，而当前的基准测试错误地将框架层面的提升归因于模型改进。它提出了一种框架感知的评估框架，包含披露标准和方差分解协议。

不是能力问题：LLM智能体层级间的控制敏感度是非单调的

arXiv cs.AI

本文通过实证测试了“更结构化的控制（harness）能普遍提高LLM智能体可靠性”这一常见假设，发现不同模型层级间存在非单调关系。它引入了HEAT-24基准，并揭示了严格的控制可能会损害前沿聊天模型，但有利于推理模型。

面向执行轨迹的推理时对齐框架

arXiv cs.LG

本文研究LLM智能体的框架设计，将其分解为任务拆解和引导执行，并展示了更精细的框架并非一致更好；它揭示了失败模式，并提出了部分框架的有效性。