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

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

摘要

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

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

相似文章

重新审视智能体框架演进的评估

arXiv cs.AI

本文重新评估了 LLM 智能体自动框架演进的方法论，指出其收益可能源于额外的测试时搜索而非改进的框架设计，并且在相同基准上的评估存在过拟合风险。实验表明，框架演进并不始终优于更简单的测试时扩展方法。

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

Reddit r/AI_Agents

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

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

arXiv cs.AI

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