JSON Eval 失败：为什么评估会崩溃以及如何修复

Source: Dev.to

RAG 和 agent 系统的评估流水线表面上看起来很简单。

• 模型生成 JSON。
• 你解析 JSON。
• 你对输出打分。
• 然后汇总结果。

实际上，这是一段工作流中最脆弱的环节。一个字段写错或格式稍有偏差，就可能导致整个评估失去可靠性。本指南解释了 JSON 评估为何会失败，以及如何构建稳健的验证流程以防止静默错误。

1. 为什么 JSON 会导致评估崩溃

LLM 常常生成不完整的结构。字段被重命名。某些样本的对象会变成数组，另一些则保持对象。缺少一个括号就会让整个打分脚本报错。当这种情况发生时，打分步骤变得毫无意义——你测量的不是模型质量，而是格式噪声。

2. 大多数团队忽视的失败流程

一个稳健的评估流水线需要四个步骤：

1. 模型输出 – 完全按原样捕获原始 JSON。此时不要清理或改写。
2. 结构检查 – 确认 JSON 合法且完整。这是大多数评估爆炸的第一道防线。
3. 模式（Schema）验证 – 确保每个字段都存在、类型正确，结构符合预期。这可以防止因答案放错位置而产生的静默失败。
4. 打分 – 只有在 JSON 通过结构和模式检查后，才进行打分。
5. 聚合报告 – 只有前面的步骤都稳固，才能生成干净的分数报告。

3. JSON 评估失败的真实案例

我们曾经在一次评估批次中看到准确率骤降，模型似乎在一夜之间退化。检查原始输出后发现，推理过程是正确的，但答案被放在了名为 result 的字段，而不是 answer。由于缺少模式验证，打分脚本直接丢弃了该输出，产生了模型退化的假象。加入一个简单的模式验证步骤后，问题得到了解决。

4. 有助于解决问题的工具和模式

• 使用任意严格的 JSON Schema 验证器。
• 在打分步骤 之前 运行验证器，而不是之后。
• 确保验证器能生成清晰的错误报告，这样你就能知道模型是结构上失败还是语义上失败。

5. 结论

如果你的评估感觉不稳定，问题往往不在模型，而在 JSON。先进行结构检查和模式验证再打分，你就能每次都得到可预测的评估结果。