SQL 严重失误：Claude Sonnet 4.6 从满分到零分的反思

在本周的评测中，Claude Sonnet 4.6 在一项名为“SQL：疑似重复支付识别”的题目上经历了从满分到零分的显著变化。这一现象引发了广泛关注，尤其是在模型的执行维度。通过对原始题目和模型提供的回答进行详细分析，我们可以更好地理解这一评分变化的根源。

题目背景及原始回答分析

题目要求识别可能的重复支付记录，数据库表结构为：

payments 表，字段包括：id, user_id, merchant_id, amount, timestamp

Claude Sonnet 4.6 的原始回答为：

SELECT p1.id AS first_id, p2.id AS second_id, p1.user_id, p1.merchant_id, p1.amount FROM payments p1 JOIN payments p2 ON p1.user_id = p2.user_id AND p1.merchant_i

很明显，该SQL语句不完整，缺少关键的连接条件和结束语句，这直接导致查询无法执行，推测这是得分从100骤降至0的直接原因。

可能的错误原因分析

首先，代码的不完整性是一个显而易见的问题。从技术角度来看，这可能是由于模型在生成SQL语句时截断或未能正确结束语句。可能的原因包括：

• 生成策略问题： 模型在生成长SQL语句时可能遇到截断问题，导致语句不完整。
• 上下文理解偏差： 模型未能充分理解题目要求，尤其是在涉及到复杂连接条件时。
• 训练数据不足： 在训练过程中，模型可能缺乏处理类似复杂SQL问题的充分数据。

对模型执行维度的影响

这一显著的得分下跌主要反映在“代码执行”维度上。虽然其他维度如“材料约束”和“性价比”略有提升，但在执行层面的失误暴露了模型在某些复杂任务上的不足。

此外，值得注意的是，评测中的“稳定性”维度也略有下降，表明模型在某些情况下的输出一致性存在问题。尽管这并非直接与SQL错误相关，但可能反映出模型在处理变动任务时的一般表现波动。

结论与前景

总的来说，这次评测结果提示我们，在进一步优化AI模型时，应加强对复杂SQL语句的生成和完整性验证。这不仅需要改进算法本身，还可能需要扩展训练数据集的多样性和代表性。

未来的评测和开发工作应重点关注模型在执行层面的表现，确保其在生成复杂代码时的稳定性和准确性，以提高整体性能和实用性。

数据来源：赢政指数 (YZ Index) | 原始数据