Quartz 4

业界方法调研

13 min read

基于Judge的方法

Arize 24-08

Judge模型

直接用 OpenAI GPT‑4 Turbo 做 LLM‑as‑a‑judge

效果

  • Spider/BIRD 等基准上的 SQL 正误判别能拿到大约 0.70–0.76 的 F1（prompt 里甚至不含 Schema 信息）
  • prompt 里给足 schema 信息的情况下F1 能到 0.82。

LLM优势

  • 零值分桶 (Zero-count bins)
    • 常见于带有 GROUP BY 和 LEFT JOIN 的聚合查询中。
    • 场景示例： 统计每个部门的员工人数。
      • SQL A (标准答案): 使用 LEFT JOIN，会列出“行政部：0人”。
      • SQL B (生成答案): 使用 INNER JOIN，结果中直接跳过了没有员工的部门。
    • 为何失效： 从业务逻辑上看，SQL B 漏掉了重要信息（即哪些部门是空的）。
      • 但在某些传统评测中，如果数据库中恰好所有部门都有人，SQL A 和 B 的结果集是一样的。无法识别模型是否具备处理“零值”边界情况的能力。
  • 数值输出的轻微差异
    • 场景示例： 计算过去一年的平均销售额。
      • 结果 A: 1234.5678
      • 结果 B: 1234.57 (模型在 SQL 中主动添加了 ROUND 函数)
    • 为何失效： 在精确数据匹配（Exact Data Matching）模式下，这两个结果会被视为完全不同。
      • 然而在工业界（如汽车金融或销售分析）中，这种因舍入精度导致的差异往往是可接受的，甚至是更符合报表展示需求的。传统方法无法区分“精度不同”和“计算错误（如算成了 2234.57）”。

Scale

数据组织

  • 75% 数据用于 SFT，25% 用于 RLHF（这一部分通过schema shuffle 顺序进行了扩充）
  • 对保留数据集（25%）的补充有助于RLHF算法（Context C1，C2，C3，C4 的重新排列，扩充出来 4 倍—schema shuffling）

RL 算法选型

  1. 在线 KTO 是 Text2SQL 中最好的强化学习算法（在 PPO, DPO, KTO, and both their online (ref) and offline versions中）

    • KTO 适用于数据不平衡情况
    • DPO 在特殊标记多的情况下不好（LLaMA3 论文）

  2. 留出来一部分用于 RL 而不是全部 SFT 数据重新 RL

    • 会限制从RLHF本身的学习
    • 原因：通过微调，模型已经学会了训练集中的所有样本，因此在RLHF期间出错少，因此获得完美奖励，进而奖励分数非常稀疏，对对齐没有帮助。

  3. LLM和数据库的执行本身作为奖励模型都不够，但结合起来，能传递出良好的信号（奖励的设计）

    • 仅 LLM 无 executor 的结果： 说明仅 LLM 的 reward还是不太可靠的

小红书QP-OneModel 26-02

2026-02-11 论文解读

整体架构

  • 将整个QP工作流重新表述为统一的序列到序列生成任务。
  • 给定输入查询q、静态任务指令I、可配置业务规则R和动态上下文信息C（如用户改写历史、候选笔记），模型以生成包含所有QP子任务结果的JSON结构化输出。

渐进式三阶段对齐

Stage 1: 知识注入（混合SFT）

针对人工标注样本不足的问题

解决方案：采用任务分解策略，从大规模历史用户日志构建辅助数据集：

  • 具体做法：
    • 任务拆解与伪标签生成：利用已有的旧系统（Legacy Pipeline）对海量的历史搜索日志（约 条）进行处理，生成各个子任务的伪 label 。
    • 混合训练 (Mixed-SFT)：将少量高质量人工标注数据与海量含噪声伪label数据混合在一起训练 。
  • 收益：模型虽然接触到了噪声，但通过海量数据掌握了社交媒体中极其多样化的查询模式和非正式语言表达 。
Stage 2： 目标分布对齐 (Target Distribution Alignment)

核心目的：消除第一阶段引入的噪声，让模型精确对齐当前的业务逻辑和线上数据分布 。

  • 具体做法：
    • 抛弃第一阶段、伪标签数据，仅使用最新人工标注统一数据集进行微调 。
  • 关键点：
    • 模式一致性：确保模型生成的 JSON 格式在所有子任务上是高度一致且互不冲突的

Stage 3：逻辑内化 (Logic Internalization)

核心目的：引导模型真正内化复杂的业务逻辑 。

  • SFT容易让模型面对没见过的长尾 Case 时，逻辑推理能力不足 。
  • 具体做法：

    1. 强化学习 (RL)：采用 GRPO ，无需额外RM。

    2. 复合奖励设计：包含 NER、分词、词权重和分类任务的综合奖励函数

      其中 ：子任务的离线评估指标（ F1 分数之类的）， ：权重 。

    3. 任务隔离采样：筛选出在特定任务上表现有差异、而在其他任务上保持一致的样本进行训练，以实现更精准的奖励归因。

  • 收益：模型在需要深度语义理解的任务（如“词权重”提升 1.35%）上表现出更强的逻辑稳定性

快手OpenOneRec 26-02

其中 LLM-as-a-judge 部分 包含3个步骤:

  • Information Point Extraction: 将描述性文本分解为结构化的“信息点（Weighted Information Points, WIPs）”列表，每个信息点包含一个事实陈述和一个重要性评分。
  • Semantic Matching: 将模型生成的信息点与真实信息点进行语义匹配，识别出匹配项、幻觉（模型生成但真实中不存在的信息点）和漏报（真实存在但模型未生成的信息点）。
  • Weighted Scoring: 根据信息点的重要性和匹配质量，计算最终的评分，以衡量生成描述的质量, 这里会对幻觉和漏报进行惩罚，鼓励模型生成高质量且全面的描述(具体计算公式见论文)

一般做法

  • 通用强模型做 judge
  • 大量数据场景：
    • 执行 + 一些 cheap heuristics 先预过滤，把垃圾样本大量删掉；
    • 只对“疑难样本 / 高价值样本 / 近边界样本”调用强 LLM‑judge，这样把成本压下去。
      • 先纯 Ex直接执行，不通过直接判错
      • 然后LLM‑as‑a‑judge
        • 用在以下 case：
          • EX 相同但 SQL 结构差异较大；
          • EX 不同，但仍可能语义接近（弱等价）；
          • 或没有 gold SQL，只有 NL 问题 + schema + candidate SQL。（我们有 gold SQL）

LLM-as-a-judge 的 prompt

  • 提供完整 schema 与必要数据分布提示 ；可用目前的 schema retrieval 部分

    • CoT 分步骤评价

      • 逐字段比对，多维度检查

      • few-shot包含典型错误模式

      • 输出结构化判定

    {

      		  "equivalence": "strong|weak|none",

  		  "reasons": "...",

  		  "schema_violations": ["field_not_exist", "wrong_table"],

  		  "logic_issues": ["direction_error", "missing_filter"]

  		}	

  	~~~

Judge 模型的训练与微调

判别数据集构造

正样本 + 多类型负样本

从 Arize、FLEX、LLM‑equiv 和 TRUST‑SQL 等论文归纳：

**（1）正样本

  • 来源：标准benchmark（Spider、BIRD 等）已验证正确的 gold SQL，或者内部专家审核过的“高置信度 SQL”。
  • 标签：
    • 与 gold 完全语义等价；
    • 可以进一步细化为“强等价”（完全相同结果空间）和“弱等价”（在当前数据分布下等价，如多余冗余谓词）。​

（2）负样本类型（最好覆盖）：

  1. 语法错误 / 执行错误 SQL

    • 构造方式：对正确 SQL 做随机 token 修改、删括号、打乱 JOIN 顺序导致语法错误，或者注入不存在的字段/表。
    • 标签：语法 invalid / execution error。

  2. 逻辑矛盾 / 错误谓词

    • 例如把 >= 变成 <=；把 status = 'active' 变成 status = 'inactive'；改变聚合方向（MAX ↔ MIN）。
    • 有些 variant 在特定数据集上执行结果可能仍然相同，但语义明显不对，这在 LLM‑equiv 和 FLEX 中被标为“不等价”。

  3. Schema 幻觉

    • 注入不存在的表/字段/别名；
    • 或使用 schema 中存在但与 NL 问题语义不匹配的字段（比如用户问“销量”，SQL 却用“库存”列）。

  4. 执行结果偏移 / 部分覆盖

    • 如漏掉 WHERE 条件导致结果 superset；
    • 漏 join 条件导致笛卡尔积；
    • 聚合维度不完全匹配（group-by 列缺失）。
    • FLEX 的设计就是要抓这种“EX 通过但专家认为不对”或“EX 未通过但其实是等价”的细粒度情况。

  5. 对 schema 解释错误但碰巧 EX 正确

    • Snowflake Cortex Analyst 的案例说明，有些 GPT‑4o 生成的 SQL 在特定数据子集上结果看似正确，但在“非连续日期”这种边缘 case 下会暴露逻辑问题。​
    • 这类样本非常适合标为“逻辑不健壮”，并在 Judge 训练时区分。

训练集可以设计为多标签 / 层级标签：

  • 一级：Correct / Incorrect；
  • 二级：Incorrect 的具体类型（Syntax, Schema, Logic, Coverage）。
    Judge 输出可以是：二分类分数 + 细粒度 error category。

提升 Judge – 专家一致性

  • TRUST‑SQL — Dual‑Track GRPO（美团）

    • 把执行奖励和 schema 奖励分开做 token‑level advantage mask，实现 agent 在工具交互中的稳定学习。

    • 加入了鲁棒性指标；对 NL 做轻微改写（同义词、语序变化），观察 SQL / JSON 输出是否保持等价

    • 四阶段交互协议 (EPGC Protocol)

      为了防止模型产生幻觉（Fabrication），TRUST-SQL 强制模型遵循结构化的四个阶段 ：

      1. Explore（探索）：使用工具查询数据库元数据（如表结构、外键、采样值） 。
      2. Propose（建议）：关键认知检查点。模型必须显式列出它已验证并决定使用的架构子集 。这大大降低了幻觉率（比基准降低 9.4 倍） 。
      3. Generate（生成）：基于建议的架构生成候选 SQL 。
      4. Confirm（确认）：验证执行结果并提交最终答案 。

    • ​ 将轨迹分解为 Schema Track（优化探索质量，使用 ）和 Full Track（优化最终执行结果） 。确保探索阶段（探索 schema）生成的 Token 只接收 Schema 奖励，生成阶段的 Token 只接收执行奖励

结论：

  1. 前期用 通用强模型 做 teacher‑judge，顺带产出高质量标注集；
  2. 中期训练自研 Judge 小模型 + RLAIF 对齐，把大部分数据过滤迁移到小模型上；
  3. 对“小模型信心不足 / 靠近决策边界”的样本继续调用 强模型做二次判决，实现成本与质量的折中。

Graph View