给 LLM 做评测得用这种带约束的轨道测试才靠谱

很多号称在 Benchmark 上拿高分的模型，实际用起来简直是灾难，原因就在于现在的评测集太容易被“刷榜”了。我最近在看 Agents on Rails 这个项目，它的核心逻辑很有意思，不像传统的问答测试，而是给模型设定一套极其严格的“轨道”（Rails），强制它在特定的流程和约束下执行任务。这就好比考试不再是让你写作文，而是让你在规定时间内、用规定的格式、完成一个复杂的拼图，没法靠概率性地猜对答案来蒙分。

我试着把几个主流模型跑了一遍，发现一个很诡异的现象：那些在通用能力上很强的模型，在面对这种强约束的实操任务时，反而经常因为“太聪明”而尝试跳出轨道，结果导致整个工作流崩溃。而一些参数量稍小但指令遵循能力极强的模型，反而跑得异常稳健。

这种测试方式最硬核的地方在于它能暴露出模型在处理复杂逻辑链时的“断裂点”。比如在执行一个多步骤的 Agent 任务时，模型可能在前三步表现完美，但一旦进入到需要严格格式化输出的第四步，它就开始胡言乱语。

如果你想在本地部署一套类似的验证机制，可以参考这种逻辑构建你的测试集。一个简单的验证脚本大概长这样：

def verify_rail_constraint(output, expected_format):
    # 强制检查输出是否严格符合预设的JSON模式，不允许任何多余的解释性文字
    import json
    try:
        data = json.loads(output)
        return all(key in data for key in expected_format)
    except json.JSONDecodeError:
        return False

# 模拟一个强约束的测试用例
test_case = {
    "instruction": "仅输出JSON，禁止任何开场白，格式为 {'status': 'success', 'value': 100}",
    "expected_format": ["status", "value"]
}

说白了，现在的模型不需要更多的“知识”，需要的是更强的“纪律性”。如果一个模型不能在预设的轨道上稳定运行，那么把它交给复杂的企业级工作流，最后大概率会变成一个随机数生成器。