kimi-k2.6 在「时序数据插值与缺失值填充SQL」的评测结果

这是该 AI 模型在此测试用例上的详细评测结果。

基本信息

  • 模型名称：kimi-k2.6
  • 用例名称：时序数据插值与缺失值填充SQL
  • 测试类型：文本生成
  • 评测维度：SQL 数据库能力

系统提示词（System Prompt）

这是给 AI 模型的背景设定和角色指令：

你是一名资深数据库工程师，擅长 SQL 查询编写与时序数据处理。 回答要求： 1. 给出完整可运行的 SQL 语句 2. 对关键步骤添加注释说明 3. 说明所使用的核心函数或语法 4. 最终答案需明确标出

用户提示词（User Prompt）

这是用户给 AI 模型的具体任务要求：

有一张传感器温度记录表 `sensor_readings`，表结构如下： ```sql CREATE TABLE sensor_readings ( id BIGINT PRIMARY KEY, recorded_at TIMESTAMP NOT NULL, -- 记录时间（精确到秒） temperature FLOAT NOT NULL -- 温度值（摄氏度） ); ``` 请编写一条 SQL 查询，统计**过去 24 小时内每分钟的平均温度**。 要求： - 以每分钟为粒度进行聚合（即将同一分钟内的多条记录取平均值） - 只需返回**有数据的分钟**，不需要处理缺失分钟 - 结果按时间升序排列 - 输出列：`minute_slot`（分钟时间戳）、`avg_temperature`（该分钟平均温度）

任务要求

AI 模型需要满足以下要求：

  1. 正确使用 DATE_TRUNC 或等效函数将时间截断到分钟粒度
  2. 正确使用 WHERE 子句过滤过去 24 小时的数据
  3. 正确使用 GROUP BY 对每分钟进行聚合，并计算 AVG(temperature)
  4. 结果按 minute_slot 升序排列
  5. 输出列名与题目要求一致

评测结果

综合得分

该模型在此用例的得分为：96.8 分（满分 100 分），已通过

基础难度评测结果

  • 得分：96.8 分
  • 通过状态：已通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

下面是基于 **PostgreSQL** 语法的实现方案（时序场景最常用的方言）。如果你的数据库是 MySQL / SQL Server / SQLite，文后也附上了对应的核心函数对照，方便你快速改写。 ### 核心思路 1. **截断到分钟**：使用 `DATE_TRUNC('minute', recorded_at)` 将秒和毫秒归零，得到整点分钟时间戳。 2. **范围过滤**：在 `WHERE` 中限定只取过去 24 小时的数据，确保走 `recorded_at` 索引。 3. **分组聚合**：按分钟分组后对该组温度求 `AVG`。 4. **天然去缺失**：`GROUP BY` 只会返回有原始数据的分钟，无需额外处理缺失值。 --- ### 完整 SQL（PostgreSQL） ```sql SELECT DATE_TRUNC('minute', recorded_at) AS minute_slot, -- 截断到整分，秒置 00 AVG(temperature) AS avg_temperature -- 该分钟内温度的算术平均值 FROM sensor_readings WHERE recorded_at >= NOW() - INTERVAL '24 hours' -- 过滤条件：过去 24 小时 GROUP BY DATE_TRUNC('minute', recorded_at) -- 按分钟粒度分组 ORDER BY minute_slot ASC; -- 按时间正序排列 ``` --- ### 关键步骤与函数说明 | 步骤 | 函数 / 语法 | 作用说明 | |------|-------------|----------| | **时间截断** | `DATE_TRUNC('minute', recorded_at)` | 将 `recorded_at` 的秒及更小精度归零，返回该分钟的起始 `TIMESTAMP`。 | | **范围过滤** | `NOW() - INTERVAL '24 hours'` | 获取当前时间往前推 24 小时的边界值；写在 `WHERE` 里以便命中索引。 | | **分组聚合** | `GROUP BY ...` + `AVG(temperature)` | 对同一分钟内的多条记录求平均温度。 | | **排序** | `ORDER BY minute_slot ASC` | 保证结果按时间轴从小到大展示。 | --- ### 其他数据库快速对照（如需移植） | 数据库 | 截断到分钟的写法（替代 `DATE_TRUNC`） | 过去 24 小时过滤写法 | |--------|--------------------------------------|----------------------| | **MySQL 8.0+** | `FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(recorded_at) / 60) * 60)` | `recorded_at >= DATE_SUB(NOW(), INTERVAL 24 HOUR)` | | **SQL Server** | `DATEADD(minute, DATEDIFF(minute, 0, recorded_at), 0)` | `recorded_at >= DATEADD(hour, -24, GETDATE())` | | **SQLite** | `DATETIME(STRFTIME('%Y-%m-%d %H:%M:00', recorded_at))` | `recorded_at >= DATETIME('now', '-24 hours')` | | **Oracle** | `TRUNC(recorded_at, 'mi')` | `recorded_at >= SYSDATE - INTERVAL '24' HOUR` | --- ### 【最终答案】 ```sql SELECT DATE_TRUNC('minute', recorded_at) AS minute_slot, AVG(temperature) AS avg_temperature FROM sensor_readings WHERE recorded_at >= NOW() - INTERVAL '24 hours' GROUP BY DATE_TRUNC('minute', recorded_at) ORDER BY minute_slot ASC; ```

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【CLAUDE】候选答案在正确性、规范性和解释说明三个维度均表现优秀。SQL 逻辑准确无误，完全满足题目要求；代码规范且注释清晰；解释说明不仅覆盖核心函数，还提供了跨数据库移植方案，展现出扎实的工程实践能力。唯一微小差异是未对平均温度做精度控制（保留两位小数），但题目未强制要求，不影响整体质量。综合来看，这是一份高质量的标准答案级回复。 【GEMINI】这是一个非常优秀的回答。SQL 逻辑严谨，完全覆盖了题目中的所有技术要点（时间截断、时序过滤、聚合统计）。代码注释清晰，文档化的说明和多数据库兼容性建议展示了专业的数据库工程师素养。 【KIMI】整体而言，该SQL查询很好地满足了题目要求，逻辑正确，代码规范，关键步骤有注释说明。解释说明也比较到位，只是略有欠缺。考虑到参考答案提供了更多数据库的兼容性说明，而该回答主要针对PostgreSQL，因此在解释说明上略有不足。

进阶难度评测结果

  • 得分：95.2 分
  • 通过状态：已通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

下面是分步骤实现的完整方案，使用 **PostgreSQL** 语法。 --- ### 一、查询思路拆解（CTE 步骤） | 步骤 | CTE 名称 | 作用 | |------|----------|------| | 1 | `time_slots` | 利用 `generate_series` 精确生成过去 24 小时共 **1440 个分钟槽**（左闭右开，避免多出一行）。 | | 2 | `minute_avg` | 对原始表按分钟截断聚合，仅保留**有数据**的分钟及其平均温度。 | | 3 | `joined` | 将完整时间序列左连接聚合结果，无数据分钟自然为 `NULL`。 | | 4 | `filled` | **核心**：使用窗口函数 `COUNT(非空列) OVER (ORDER BY ...)` 构造“前向填充分组”`fill_grp`。 | | 5 | 最终 SELECT | 按 `fill_grp` 分区，用 `MAX()` 将最近有效值广播到缺失行；同时输出 `is_filled` 标记。 | --- ### 二、完整可运行 SQL ```sql -- ========================================== -- 步骤 1：生成过去 24 小时完整的 1440 个分钟槽 -- ========================================== WITH time_slots AS ( SELECT date_trunc('minute', now() - interval '24 hours') + (n * interval '1 minute') AS minute_slot FROM generate_series(0, 1439) AS n -- 0..1439 保证恰好 1440 行 ), -- ========================================== -- 步骤 2：计算原始数据中每分钟的平均温度 -- ========================================== minute_avg AS ( SELECT date_trunc('minute', recorded_at) AS minute_slot, AVG(temperature) AS avg_temperature FROM sensor_readings WHERE recorded_at >= date_trunc('minute', now() - interval '24 hours') AND recorded_at 0）时，标记为 TRUE (f.avg_temperature IS NULL AND f.fill_grp > 0) AS is_filled FROM filled f ORDER BY f.minute_slot; ``` --- ### 三、关键语法注释 1. **`generate_series(0, 1439)`** 生成 0 到 1439 的整数序列，与 `interval '1 minute'` 相乘后加到起始时间戳上，确保结果**恰好 1440 行**。 2. **`COUNT(column) OVER (...)`** 这是实现前向填充的灵魂。与 `COUNT(*)` 不同，`COUNT(column)` **忽略 NULL**。因此时间轴上每出现一个有数据的分钟，计数器才累加；缺失分钟继承前方最新计数，形成相同的 `fill_grp`。 3. **`MAX(...) OVER (PARTITION BY fill_grp)`** 在每个由 `fill_grp` 划分的窗口里，最多只有一行带有原始平均温度（非 NULL），其余都是 NULL。`MAX()` 会取出该有效值并“涂抹”到整组，完成前向填充。 若序列**开头**全为 NULL（`fill_grp = 0`），组内无有效值，`MAX()` 返回 `NULL`，符合题目要求。 4. **`is_filled` 标记逻辑** `fill_grp > 0` 确保序列头部完全没有数据的 `NULL` 行不会被误标为填充值；只有“前面已有数据、本分钟缺失”的情况才标记为 `TRUE`。 --- ### 四、前向填充的实现原理 该方案本质上是 SQL 中经典的 **“携带有效值向前”（Carry-Forward / Last-Observation-Carried-Forward, LOCF）** 技巧： 1. **分组标识**：通过 `COUNT(non_null) OVER (ORDER BY time)`...

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【CLAUDE】这是一份高质量的 SQL 时序数据处理方案。候选答案不仅在功能实现上完全正确（甚至在时间序列生成精度上优于参考答案），而且代码结构清晰、注释详尽、解释深入。特别值得称赞的是：(1) 使用 generate_series(0, 1439) 精确控制行数，避免了常见的「多一行」陷阱；(2) 前向填充逻辑采用业界标准的「累计非空计数分组」方案，实现简洁高效；(3) 解释说明部分用「旗子编号」比喻将复杂的窗口函数逻辑可视化，展现了优秀的技术表达能力；(4) 额外提供性能优化建议，体现工程实践深度。综合来看，这是一份可直接用于生产环境且具有教学价值的优秀答案。 【GEMINI】这是一份教科书级别的 SQL 解决方案。模型准确理解了“前向填充”这一复杂时序处理逻辑，并利用 CTE 和窗口函数给出了优雅且健壮的实现。代码注释详尽，原理说明清晰，边界情况（如序列开头缺失）处理得当，完全满足并超出了预期要求。 【KIMI】该方案在正确性、实现方案合理性和解释说明方面都表现良好。方案正确实现了题目要求的各项功能，逻辑清晰，前向填充的实现方法合理。解释说明也比较到位，能够帮助理解方案的实现思路。但部分解释稍显冗长，可以进一步优化以提高方案的整体可读性。

困难难度评测结果

  • 得分：94.1 分
  • 通过状态：已通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

以下给出三个任务的完整 PostgreSQL 实现。所有方案均采用 **CTE（Common Table Expression）** 逐层拆解，确保逻辑清晰、可维护、可调试。为便于阅读，三个任务共用相同的基础 CTE（时间边界、传感器列表、分钟网格、实际聚合），仅在填充与检测层做差异化处理。 --- ## 任务一：多传感器前向填充（Forward Fill） ```sql WITH time_bounds AS ( /* 定义查询窗口：过去24小时，精确到分钟 */ SELECT date_trunc('minute', now() - interval '24 hours') AS start_time, date_trunc('minute', now()) AS end_time ), sensors AS ( /* 仅选取在时间窗口内有读数的传感器，避免生成无效笛卡尔积 */ SELECT DISTINCT sensor_id FROM sensor_readings WHERE recorded_at >= (SELECT start_time FROM time_bounds) AND recorded_at = (SELECT start_time FROM time_bounds) AND recorded_at = (SELECT start_time FROM time_bounds) AND recorded_at = (SELECT start_time FROM time_bounds) AND recorded_at = (SELECT start_time FROM time_bounds) AND recorded_at = (SELECT start_time FROM time_bounds) AND recorded_at 3 倍标准差 且 标准差非空（窗口至少 2 个有效点） */ SELECT sensor_id, minute_slot, avg_temperature, CASE WHEN avg_temperature IS NOT NULL AND window_std IS NOT NULL AND ABS(avg_temperature - window_mean) > 3 * window_std THEN TRUE ELSE FALSE END AS is_anomaly FROM window_stats ), cleaned AS ( /* 将异常值强制置为 NULL，使其在后续填充中被视为缺失 */ SELECT sensor_id, minute_slot, CASE WHEN is_anomaly THEN NULL ELSE avg_temperature END AS avg_temperature, is_anomaly FROM anomaly_flagged ), with_grp AS ( /* 复用任务一的前向填充组号法 */ SELECT sensor_id, minute_slot, avg_temperature, is_anomaly, COUNT(avg_temperature) OVER ( PARTITION BY sensor_id ORDER BY minute_slot ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS grp FROM cleaned ), filled AS ( SELECT sensor_id, minute_slot, avg_temperature, is_anomaly, MAX(avg_temperature) OVER ( PARTITION BY sensor_id, grp ) AS filled_temperature FROM with_grp ) SELECT sensor_id, minute_slot, filled_temperature AS avg_temperature, is_anomaly, (avg_temperature IS NULL AND filled_temperature IS NOT NULL) AS is_filled FROM filled ORDER BY sensor_id, minute_slot; ``` ### 任务三实现思路 1. **滑动窗口统计**：在分钟级网格上使用 `ROWS BETWEEN 5 PRECEDING AND 5 FOLLOWING` 构造严格以当前分钟为中心、覆盖前后各 5 分钟的时间窗口（共 11 分钟）。计算窗口内非空值的均值与样本标准差。 2....

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【CLAUDE】这是一份高质量的 SQL 时序数据处理方案。候选答案在三个任务的核心逻辑实现上几乎完美，充分展现了对 PostgreSQL 窗口函数、CTE、时序数据处理的深刻理解。代码结构清晰，注释详尽，复用性强。性能分析部分专业且全面，索引建议、分区策略、并行优化等内容均符合生产环境最佳实践。边界情况处理基本到位，虽有个别细节（如序列开头全 NULL 行的输出处理、极端异常数据的容错）可进一步完善，但不影响整体方案的正确性和实用性。解释说明部分深入浅出，既有数学原理又有 SQL 实现细节，具有很强的参考价值。综合来看，该方案在正确性、合理性、性能优化等方面均达到了优秀水平，完全满足生产环境对多传感器时序数据清洗与补全的需求。 【GEMINI】这是一份极高水平的 SQL 实现方案。模型不仅准确地完成了所有功能要求，还展现了对 PostgreSQL 特性的深刻理解（如窗口函数范围定义、EPOCH 处理、覆盖索引等）。代码逻辑严密，处理边界情况稳健，性能优化建议具有很强的实战指导意义，完全符合‘资深数据库工程师’的人设要求。 【KIMI】整体而言，该方案在正确性、实现方案合理性、边界与异常处理、解释说明与性能分析等方面都表现优秀。SQL 逻辑正确，代码结构清晰，关键步骤有详细的解释说明，性能优化建议合理。在边界处理和性能优化方面还有一定提升空间，如任务二中线性插值的时间归一化处理可以进一步优化。

相关链接

您可以通过以下链接查看更多相关内容：

加载中...
100%