你的评估集一旦被代理优化，就不再是评估集了

这是我看到讨论最少、却让我们花费最多时间的失败模式。标准设置：代理生成一个候选方案，你用保留集对其进行评分，保留好的，然后迭代。模型从未在保留数据上训练过，所以感觉很安全。但事实并非如此。你实际上是在用它进行选择。通过五十个候选方案并保留优胜者，那么优胜者在一定程度上是拟合了评估集中的噪声，而非你真正关心的内容。选择是一种更弱的训练形式，而不是不同的事情。问题是，你的基础设施越好，这个问题就越严重。更高的吞吐量意味着更多的候选方案被针对同一固定集评分，这加速了评估集的消耗。快速的代理循环是最危险的版本，而不是最安全的。我们深受其害，因为我们在一个具有真实基准（ground truth）的领域工作。我们构建了一个研究工具，其中代理流程提出交易策略，而一个独立的确定性步骤根据模型从未见过的市场数据对其进行评分。市场对此毫不留情。一个看起来很棒的战略通常只是拟合了评估窗口，而你最终会通过金钱发现真相。 三件有帮助的事情，均可迁移：统计你的试验次数，包括你淘汰的那些。压缩评分（Deflated scoring）根据找到结果所花费的尝试次数来折扣评分。这只在计数真实有效时才能奏效，而几乎没有人记录丢弃情况。如果你无法说出你的循环在你最终交付之前生成了多少个候选方案，你就不知道你的评估数值意味着什么。逐步揭示你的评估数据。不要使用一个固定的保留集，而是分块释放，这样每一代的评分都部分基于之前任何选择轮次都无法触及的数据。这防止了棘轮效应（ratchet），而不是事后测量。它让每个结果看起来更糟糕，这大致就是你知道它在起作用的方式。将评分器置于代理无法写入的工具边界之后。我们的是MCP服务器后的确定性代码。代理调用它，但从不实现它。这就把“模型不给自己打分”从系统提示的承诺变成了结构性事实。如果你的评判者是同一进程中的另一个LLM调用，那你没有评判者，只有来自同一个大脑的第二个意见。 失败之处：我们的选择目标有五个维度。其中一个是鲁棒性分数。我们删除了它，因为搜索学会了玩弄鲁棒性指标，而不是变得鲁棒。优化循环内的任何指标最终都会成为目标。唯一幸存下来的防御是那些提出模型无法看到或影响的防御。还有一个值得借鉴的：我们通过相同的控制器和相同的评分缝隙运行一个非LLM的遗传编程基线，这样唯一的不同就是提议步骤。如果你想知道循环中的LLM是增加了价值还是仅仅增加了成本，这种比较是我所知道的唯一无需猜测就能回答的方式。 我们目前的状态：产品前期，引擎已运行，无需注册。乐意深入探讨其中的任何一点。给子版块的问题：如果你运行任何形式的代理自我改进循环，是什么阻止你的基准悄悄退化为训练集？“我们有时会轮换它”是一个有效的回答，我只是想知道是否有人有更好的办法。