LLM裁判并不可靠：一项Text-to-SQL生产审计的启示

导语

在Text-to-SQL系统中，生成SQL只是前半程。许多生产管线还会用一个大语言模型充当“裁判”，判断SQL是否忠实回答了用户问题。然而，裁判本身是否可靠，往往没有经过与人工标注的系统对照。arXiv上的一项新研究，正是对这一盲区进行审计。

核心发现

• 研究团队检查了生产环境中使用的gpt-4o-mini裁判。在一个专门放大模型分歧的测试集上，它与两位作者共同形成的人工金标准之间，Cohen’s kappa仅为0.04；在均匀随机抽样的检查集上也只有0.42。
• 在分歧增强集里，模型把77.1%由人工判定为FAITHFUL的样本标记为有问题，说明“过度挑错”比漏掉错误更突出。
• 大多数误报可追溯到研究者命名的“GRADE-HALLUCINATION”机制：裁判在评估时引入了输入中并不存在的评分依据或错误前提。
• 更换裁判后，结果明显改善。自托管Qwen3.6-27B的kappa为0.72，与Claude Opus 4.7的0.71处于相近水平。两者正面比较只有96个样本，证据仍然有限，但Qwen的单次调用成本约为Claude的三百分之一。
• 盲目集成并不会自动带来收益。将较弱裁判与较强裁判配对，反而降低一致性；三个强裁判采用“一致同意”路由时，kappa达到0.79，自动处理覆盖率为89.7%。

这意味着什么

这项工作首先提醒工程团队：LLM-as-Judge不是天然可信的基础设施，而是一种需要单独验收的模型组件。单看模型名称、调用成本或个别案例，很难判断它是否适合生产环境。至少应建立与人工标注对齐的抽样集，并分别检查随机样本和高分歧样本，否则整体指标可能掩盖严重的系统性误报。

其次，成本与质量并不总是对立。研究中的自托管Qwen替代方案，在有限比较中接近更昂贵的闭源模型，显示模型选择应同时考虑准确性、可部署性和调用成本，而不是默认使用最知名的API模型。

最后，集成策略需要围绕风险设计。多个裁判的投票规则、升级人工复核的条件，以及自动覆盖率之间存在权衡。研究团队将同一审计方法应用到域外的BIRD-financial数据后，发现25.5%的专家编写金标准SQL被标记为潜在问题。这不等于这些SQL一定错误，却说明评估集本身也可能含有歧义，金标准需要持续审计。

对Text-to-SQL及其他自动评测系统而言，真正可复用的经验不是某个模型的单一分数，而是一套闭环：预注册评估、分析错误机制、比较替代裁判、设计保守路由，并定期复查金标准。

来源：arXiv