定义问题，项目成功的第一步

发布于 2025-09-23 分类: AI
系列文章: GRPO实战指南
第 1 部分: 从“代码补全”到“逻辑优化” 第 2 部分: 定义问题，项目成功的第一步 (当前) 第 3 部分: GRPO的数据集，告别“标准答案” 第 4 部分: 奖励函数，模型能力的“铸魂师” 第 5 部分: 模型选择与训练实战 第 6 部分: 评估、迭代与总结

第一步：明确问题——从模糊想法到可验证任务

在上一章中，我们确立了目标：要将一个代码“通才”模型，通过 GRPO 训练成一个 SQL 优化“专才”。现在，我们将踏上实战的第一步，这也是整个项目中最关键、最容易被忽视的一步：精确地定义问题。

这听起来可能有些理论化，但请相信我，一个定义模糊的问题是导致AI项目失败的首要原因。这就像在没有设计图纸的情况下开始盖楼，你可能会建起一些东西，但它很可能不是你想要的，甚至可能会在你入住前就坍塌。

1. 为什么这是第一步也是最重要的一步？

你无法训练一个模型去做一件连你自己都说不清楚的事情。机器学习，尤其是强化学习，本质上是一个优化过程。模型会朝着你设定的目标（奖励）不断调整自己。如果你的目标是模糊的，那么模型的行为就会是混乱和不可预测的。

我们需要把一个模糊的想法，比如“让模型会写高效的SQL”，转化为一个有明确输入 (Input)、输出 (Output) 和评价标准 (Evaluation Criteria) 的可计算任务。

  • 模糊的想法：“我想要一个会写SQL的AI。”
  • 可计算的任务：“给定一个自然语言问题和数据库结构，模型需要生成一个SQL查询字符串。这个字符串必须满足语法正确、逻辑正确、遵守特定约束这三个条件，并且要以执行时间最短为最终优化目标。”

看到了吗？后者为我们接下来的所有工作——数据准备、奖励函数设计、模型评估——都提供了清晰的指导。

2. 案例解析：“带约束的 SQL 查询生成”问题定义

让我们以本指南的核心案例为例，一步步将其“规格化”。

输入 (Input)

模型的输入必须是结构化的，包含解决问题所需的所有信息。

  1. 一个自然语言问题 (Natural Language Question)：这是用户最原始的需求。

    • 示例："找出上个月所有‘电子产品’类别中，销售额超过 $1000 且利润率最高的前五种商品。"

  2. 一个数据库的 Schema 定义：模型需要知道它在哪个“世界”里操作。这包括表结构、字段名、数据类型以及表之间的外键关系。没有这个，模型就像一个不知道厨房里有什么食材的厨师。

    • 示例：
      CREATE TABLE products (
  product_id INT PRIMARY KEY,
  product_name VARCHAR(255),
  category VARCHAR(50),
  cost_price DECIMAL(10, 2)
);

CREATE TABLE sales (
  sale_id INT PRIMARY KEY,
  product_id INT,
  sale_date DATE,
  quantity INT,
  sale_price DECIMAL(10, 2),
  FOREIGN KEY (product_id) REFERENCES products(product_id)
);

  3. 一个额外的“约束列表” (Constraint List)：这是我们任务的特色，也是提升难度的关键。它为模型增加了额外的挑战，迫使它不能只满足于“能用”，而是要“用得巧”。

    • 示例：["查询执行时间不能超过5秒", "禁止使用子查询", "必须使用 CTE (Common Table Expressions)"]
任务目标 (Goal)

我们的目标是让模型生成一个最终的SQL查询。这个查询必须像通过层层关卡一样，满足一系列严格的规则 (Rules)：

  1. 规则1：语法正确性 (Syntactic Correctness)

    • 这是最基本的要求。生成的SQL必须能被数据库引擎（如PostgreSQL, MySQL）无误地解析。一个有语法错误的SQL是完全无用的。

  2. 规则2：语义正确性 (Semantic Correctness)

    • SQL必须能够正确地回答输入的问题。它不仅要选对表和字段，还要正确地实现筛选、连接、聚合等逻辑。

  3. 规则3：约束合规性 (Constraint Compliance)

    • SQL必须遵守输入中提供的所有额外约束。如果约束说“禁止使用子查询”，那么生成的SQL里就不能出现 SELECT ... WHERE id IN (SELECT ...) 这样的结构。

  4. 核心优化目标：最大化查询效率 (Efficiency Optimization)

    • 在满足以上所有硬性规则的前提下，我们追求的终极目标是让查询的执行时间越短越好。这是区分“专才”和“通才”的核心指标。
输出格式 (Output Format)

为了更好地引导模型进行思考并方便我们调试，我们规定一个特殊的输出格式。模型必须先输出一段它的思考过程，然后才是最终的代码。

  • 示例：
    <think>
用户的目标是找出上个月销售额超过$1000且利润率最高的五种电子产品。
1.  首先，我需要计算每种产品的总销售额和总利润。销售额 = quantity * sale_price，利润 = (sale_price - cost_price) * quantity。
2.  数据来源是 `sales` 表和 `products` 表，需要通过 `product_id` 进行连接。
3.  时间范围是“上个月”，需要用日期函数进行筛选。
4.  筛选条件是类别为“电子产品”且总销售额 > 1000。
5.  最后，按利润率 (总利润 / 总销售额) 降序排列，取前五名。
6.  约束要求禁止使用子查询，我将使用 JOIN 和 GROUP BY 来完成所有计算。
</think>
<code>
SELECT
    p.product_name
FROM
    products p
JOIN
    sales s ON p.product_id = s.product_id
WHERE
    p.category = '电子产品'
    AND s.sale_date >= date('now', 'start of month', '-1 month')
    AND s.sale_date < date('now', 'start of month')
GROUP BY
    p.product_id, p.product_name
HAVING
    SUM(s.quantity * s.sale_price) > 1000
ORDER BY
    SUM(s.quantity * (s.sale_price - p.cost_price)) / SUM(s.quantity * s.sale_price) DESC
LIMIT 5;
</code>
    强制模型输出 <think> 标签中的内容，是在变相地引导它进行思维链 (Chain-of-Thought) 推理，这通常能显著提高复杂逻辑任务的准确率。

3. 关键概念：“可验证领域” (Verifiable Domain)

我们刚刚定义的“SQL生成”问题，是一个典型的“可验证”问题。这是什么意思呢？

可验证领域，指的是对于模型生成的任何一个答案，我们都有一套确定的、可以通过程序自动判断其好坏的流程。

这正是强化学习（以及GRPO）能够大放异彩的舞台。因为“自动验证流程”可以直接转化为我们的“自动裁判”——奖励函数。

让我们看看对于一个生成的SQL，这个自动化验证流程是怎样的：

graph TD
    subgraph 自动化验证流水线
        A[模型生成的SQL] --> B{1. 语法验证};
        B -- 语法错误 --> F1[失败, 得分=0];
        B -- 语法正确 --> C{2. 约束验证};
        C -- 违反约束 --> F2[失败, 得分=0];
        C -- 遵守约束 --> D{3. 执行验证};
        D -- 执行报错 --> F3[失败, 得分=0];
        D -- 执行成功 --> E{4. 正确性验证};
        E -- 结果错误 --> F4[失败, 部分得分];
        E -- 结果正确 --> G[成功, 获得基础分];
        G --> H{5. 效率评估};
        H --> I[计算最终奖励分数];
    end

    %% --- 样式定义 (高对比度) ---

    %% 失败节点样式: 红底黑字
    classDef fail fill:#F8D7DA,stroke:#721C24,stroke-width:2px,color:#000;
    
    %% 部分成功节点样式: 黄底黑字
    classDef partial fill:#FFF3CD,stroke:#856404,stroke-width:2px,color:#000;
    
    %% 成功节点样式: 绿底黑字
    classDef success fill:#D4EDDA,stroke:#155724,stroke-width:2px,color:#000;

    %% --- 应用样式 ---
    class F1,F2,F3 fail;
    class F4 partial;
    class I success;
  • 1. 语法验证：我们可以用一个SQL解析库（如 sqlparse）来检查SQL语法是否合法。
  • 2. 约束验证：通过字符串匹配或AST（抽象语法树）分析，检查SQL是否包含“子查询”等被禁止的模式。
  • 3. 执行验证：在一个真实的（或测试用的）数据库上执行它，捕获任何运行时异常，并记录执行时间。
  • 4. 正确性验证：将查询结果与一个预先准备好的“标准答案结果集”进行对比，判断查询逻辑是否正确。
  • 5. 效率评估：基于记录的执行时间，给予最终的效率分数。

为什么“可验证”如此重要？

因为它给了我们一个明确的、可量化的靶子。我们可以将上述所有验证步骤组合成一个复杂的打分函数，从而设计出精确的奖励信号来引导模型学习。代码生成、数学定理证明、API调用序列规划、组合优化问题（如旅行商问题）等，都属于可验证领域。

至此，我们已经完成了最困难也最重要的第一步：将一个模糊的想法转化为了一个清晰、明确、可验证的机器学习任务。我们现在拥有了一张精确的“项目蓝图”。

在下一章，我们将基于这张蓝图，开始准备我们的“建筑材料”——数据集。你会发现，GRPO对数据集的要求与SFT截然不同，它更加灵活，也更能体现我们作为“架构师”而非“搬砖工”的价值。

-- 感谢阅读 --