今日 slides：research-radar-2026-07-10

每日文献雷达：2026-07-10

你有没有想过一个问题：当 LLM 已经能写 SQL 了，为什么企业里的数据分析师还在手动写？

答案不是”模型不够强”。今天的五篇论文从不同角度指向同一个结论——问题不在生成能力，而在系统性差距：基准测不准、Schema 会变化、文件之间有依赖、数据本身是脏的、候选答案选不对。

今天入选的五篇论文正好构成了一条链路：从数据清洗到 Schema 适应，从 SQL 生成到结果选择，再到整个工作区的文件依赖推理。我把它们画成了一张图。

flowchart LR
    subgraph L1["数据层：准备与清洗"]
        A["LLMs Clean Up
Your Mess?
数据清洗综述"]
    end
    subgraph L2["Schema 层：适应演化"]
        B["EvoSchema
Schema 演化
鲁棒性基准"]
    end
    subgraph L3["生成层：NL2SQL"]
        C["NL2SQLBench
模块化评估
框架"]
        D["DivSkill-SQL
残差技能优化
集成选择"]
    end
    subgraph L4["工作区层：文件依赖"]
        E["Workspace-Bench
多文件依赖
Agent 基准"]
    end
    L1 --> L2 --> L3 --> L4
    style A fill:#fff3cd,stroke:#f0ad4e
    style B fill:#d1ecf1,stroke:#0c5460
    style C fill:#d4edda,stroke:#155724
    style D fill:#d4edda,stroke:#155724
    style E fill:#e2d9f3,stroke:#6f42c1

上图从左到右，就是一条数据从”脏”到”能被 Agent 理解和操作”的完整链路。今天的五篇论文恰好覆盖了每一层。

---

NL2SQLBench：你测的模型，可能根本没测对

作者：Shizheng Hou, Wenqi Pei, Nuo Chen, Quang-Trung Ta, Peng Lu, Beng Chin Ooi · 发表：VLDB · 代码：github.com/neurdb/NL2SQLBench

想象一下你去医院体检，但体检报告只告诉你”身体还行”，不告诉你哪个器官有问题。这就是当前 NL2SQL 评估的现状——只看端到端准确率，不看每个模块到底哪里出了问题。

NL2SQLBench 把 NL2SQL 管线拆成了三个模块，每个模块独立打分：

模块	做什么	核心指标	发现的问题
Schema Selection	从几十张表中选出相关的表/列	Precision/Recall/F1	过度选择——选了太多无关表
Candidate Generation	生成候选 SQL	Correct Rate / Error Rate	语义错配远多于执行错误
Query Revision	修正错误 SQL	Correctness Improvement Rate	最高改进率仅 26.32%

最惊人的发现是：用 Gold Schema 后，C3-SQL 准确率从 37.94% 跳到 45.63%（+20.27%）。这意味着 Schema Selection 是整个管线的最大瓶颈，而不是 SQL 生成本身。

他们还发现 BIRD 数据集里存在大量不准确的 Gold SQL 标注——你用来训练模型的标准答案，可能本身就是错的。这就像考试的标准答案有误，学生还怎么考高分？

---

Workspace-Bench：你的 Agent 还看不懂你的文件夹

作者：Zirui Tang, Xuanhe Zhou, Yumou Liu 等 · 代码：github.com/OpenDataBox/Workspace-Bench

你打开一个数据分析师的桌面，会看到什么？Excel 表格、Python 脚本、CSV 数据、PDF 报告、JSON 配置文件……这些文件之间不是孤立的——一个 Python 脚本读取一个 CSV，输出一个 Excel，Excel 又被另一个脚本引用。

这就是 Workspace-Bench 要测的东西：Agent 能不能理解文件之间的依赖关系？

这个基准的规模让人印象深刻：5 个角色工作区（运营经理、物流经理、产品经理、后端开发、研究员），20,476 个文件，74 种文件类型，388 个任务，每个任务都标注了文件依赖图。

结果呢？最佳 Agent 只有 60% pass rate，而人类+工具是 80.7%。差距最大的不是”找不到文件”，而是”理解文件之间的关系”——Edge F1 显著低于 Node F1。翻译成人话：Agent 知道文件在哪，但不知道文件之间怎么互相影响。

---

Can LLMs Clean Up Your Mess?：数据不干净，后面的都白搭

作者：Wei Zhou, Jun Zhou, Haoyu Wang 等 19 人 · 代码：github.com/weAIDB/awesome-data-llm

这篇综述的标题就很直白——“LLM 能帮你收拾烂摊子吗？” 它调研了数百篇文献，把 LLM 时代的数据准备归纳为三个核心任务：

flowchart TB
    subgraph DC["数据清洗 Data Cleaning"]
        S1["标准化
Standardization"]
        S2["错误处理
Error Processing"]
        S3["缺失补全
Imputation"]
    end
    subgraph DI["数据集成 Data Integration"]
        S4["实体匹配
Entity Matching"]
        S5["Schema 匹配
Schema Matching"]
    end
    subgraph DE["数据增强 Data Enrichment"]
        S6["数据标注
Annotation"]
        S7["数据画像
Profiling"]
    end
    DC --> DI --> DE
    style DC fill:#fff3cd,stroke:#f0ad4e
    style DI fill:#d1ecf1,stroke:#0c5460
    style DE fill:#d4edda,stroke:#155724

核心洞察是：从规则驱动到 prompt 驱动的范式转变。以前的数据清洗是写死规则（正则表达式、if-else 逻辑），现在 LLM 可以理解”这个字段应该是电话号码格式”的语义。但代价也很明显——幻觉和规模化成本。在百万行数据上用 LLM 逐行清洗？你会破产的。

---

EvoSchema：你以为训练好的模型，上线就废了

作者：Tianshu Zhang, Kun Qian, Siddhartha Sahai 等（Adobe + Ohio State） · 发表：VLDB · 代码：github.com/zhangtianshu/EvoSchema

数据库 Schema 是会变的——今天加一列，明天改个表名，后天合并两个表。你的 NL2SQL 模型在静态测试集上拿了 90% 准确率，一上线就掉到 60%。

EvoSchema 定义了 10 种 Schema 演化扰动类型，分列级别和表级别：

扰动级别	示例	影响程度
列级别	重命名列、添加列、删除列、修改列类型	中等
表级别	重命名表、拆分表、合并表、添加表、删除表	严重

关键发现：表级别变动的性能影响远大于列级别变动。而且，在演化后的 Schema 上训练，模型会学会”区分 Schema 差异”而不是”记住表面的列名映射”——这比在单一静态 Schema 上训练出来的模型鲁棒得多。

---

DivSkill-SQL：不是生成更多候选，而是生成互补的候选

作者：Jiongli Zhu, Haoquan Guan 等（UCSD + Snowflake）

Text-to-SQL 的常见做法是生成 K 个候选 SQL，然后选一个最好的。但问题是：如果 K 个候选都在同一个地方犯错呢？

这就是 DivSkill-SQL 的核心洞察：当前的集成方法靠随机解码或 prompt 变体来制造多样性，但候选之间高度相关，导致”集体翻车”。

他们的做法很优雅：残差技能优化。每训练一个新技能，只优化当前集成还做不对的样本。这保证了每个新技能都提供”边际贡献”，而不是重复已有的能力。

效果：Spider2-Lite 上 Snowflake +11.1 分，BigQuery +8.3 分。更重要的是，跨 SQL 方言迁移不需要重新训练——Snowflake 上优化的技能，迁移到 SQLite 和 BIRD-Critic 依然有效。幻觉引用减少了 3 倍。

---

今天五篇论文的交叉点

回头看看开篇那张图——五篇论文正好覆盖了从”脏数据”到”Agent 能操作”的完整链路。它们共同指向一个结论：

Data Analysis Agent 的瓶颈不在模型能力，在系统设计。 数据清洗、Schema 适应、模块化评估、文件依赖推理、互补候选生成——这些不是独立的子问题，而是一条链路上的连环关卡。任何一个环节掉链子，整条链路就断了。

真正好的 Data Analysis Agent，不是最强的 LLM，而是最诚实的系统。

检索说明

• 检索层：arXiv（deepxiv）+ Semantic Scholar + Google Scholar，每日查询轮换，保证论文多样性。
• 阅读层：优先获取 arXiv HTML 全文，使用结构化三元组 + 公众号 storytelling 风格拆解论文逻辑。
• 深度阅读方法论参考 /readpaper 技能。
• 自动分析用于雷达筛选，重要论文仍需人工复核。