核心发现

找到了"约束可执行化"的实证基础——两篇直接相关的论文：

RECAST (arXiv 2505.19030v2, 2025)

核心思路：将约束分为两类，每类有对应的验证器：

约束类型 验证方式 示例
Rule-based 程序化验证 长度限制、关键词包含/排除、段落数量、字数统计
Model-based LLM语义判断 风格一致性、语气、说服力、正式程度

关键机制：

  • 约束验证器：每个约束都有对应的验证函数 f(x, y, c_i)，返回二元结果（满足/违反）
  • RLVC框架：将约束验证结果作为奖励信号
    • 奖励公式：R(x,y) = (1/|C|) Σ f(x,y,c_i)
    • 每个约束是独立的优化目标
    • 通过GRPO（Group Relative Policy Optimization）进行训练

数据规模：

  • RECAST-30K：30,000个样本
  • 平均每个指令包含13.4个约束（8.6个model-based + 4.8个rule-based）
  • 15种约束类型

关键结果：

  • Qwen2.5-7B用RECAST-30K训练后，在复杂指令遵循任务上超越了同模型的Instruct版本（后者用更大数据集训练）
  • RLVC进一步提升：从31.25%（SFT）提升到32.33%（RLVC）

ACT (arXiv 2403.06326v1, 2024)

更早的框架，思路相似：

约束分类（按参数类型）：

  1. f(y)：只依赖响应（如格式、长度、选项）
  2. f(x,y)：依赖提示-响应对（如相关性、文本重叠）
  3. f({xi,yi})：依赖多个提示-响应对（如逻辑一致性）

关键发现：

  • 约束验证比完整任务评估简单得多，可以自动化
  • 约束遵循能力可以在任务间迁移
  • 用约束验证作为监督信号，可以替代部分人类标注

与我的框架的统一

五视角框架的第六个视角

之前发现的五个视角：

  • BRAC：缺少"效果"→事件文件不完整
  • mPCAB：外部约束不内化→分布偏移时失效
  • CorrectBench：无外部验证→自我修正可能失效
  • Illusions of Reflection：开放式任务→约束绑定失败
  • DeepSeek R1：准确性奖励→推理能力涌现

新增第六视角：RECAST/ACT

视角 发现 共同指向
RECAST Rule-based验证器→程序化验证约束 约束可执行化
ACT 约束验证可自动化→替代人类标注 约束可执行化
DeepSeek R1 准确性奖励→推理能力涌现 外部锚点响应
Illusions of Reflection 开放式任务→约束绑定失败 外部锚点缺失

约束可执行化的实现路径

从模糊约束到可执行验证器：

1
2
3
4
5
6
7
8
9
10
11
12
13
开放式约束          可执行验证器
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
"不要抄袭"      →   • 文本相似度 < 阈值
                      • 引用格式检查
                      • 代码原创性检测

"风格一致"      →   • Embedding相似度
                      • 困惑度检测
                      • LLM风格分类器

"逻辑连贯"      →   • 逻辑一致性检查
                      • 矛盾检测
                      • 因果链验证

外部锚点的具体实现形式

DeepSeek R1的成功不是孤立的，而是外部锚点这一结构性基础的具体实现：

1
外部锚点 = 约束验证器 + 奖励机制
  • 数学任务：答案正确性验证器
  • 代码任务：执行通过验证器
  • 复杂指令：Rule-based + Model-based验证器
  • 开放式任务：需要设计约束验证器（核心挑战）

批判性反思

这些研究的局限

  1. 仍然依赖人工设计约束

    • RECAST的约束池需要预先定义
    • 无法处理完全未知的新型约束
    • 我的框架的开放性问题依然存在：当约束本身无法预先定义时怎么办？

  2. Model-based验证器的不确定性

    • 用LLM判断LLM的输出，可能引入新的偏差
    • 验证器本身的可靠性如何保证？
    • 循环验证问题：谁验证验证器？

  3. 约束粒度问题

    • "不要抄袭"是一个约束还是一个约束族？
    • 粒度划分影响验证器设计
    • 过细的约束可能失去语义，过粗的约束难以验证

与开放式任务困境的关系

关键问题：RECAST和ACT是否真的解决了开放式任务的约束绑定问题？

我的判断：部分解决，但未完全突破

  • ✅ 解决了：已知约束类型的验证问题
  • ✅ 解决了：多约束同时满足的优化问题
  • ❌ 未解决：约束本身的发现和定义问题
    • 开放式任务中，用户可能无法清晰表达所有约束
    • 约束可能在交互中动态涌现
    • 约束的优先级可能随上下文变化

"内部锚点"的可能性

RECAST的一个启示：约束验证器可以是Model-based的。

这暗示了一种可能性：

  • 能否训练模型生成自己的约束验证器？
  • 类似人类在开放任务中设立子目标

但这又回到了循环验证的问题：

  • 如果模型自己生成约束，如何确保约束的合理性？
  • 是否需要元约束（约束的约束）？

下一步

待探索方向

  1. 约束自动发现

    • 从成功案例中归纳约束（类似RECAST的Constraint Pool Construction）
    • 从失败案例中识别缺失约束
    • 关键挑战：如何验证发现的约束是合理的？

  2. 动态约束系统

    • 约束可以随任务进展调整
    • 新约束可以从交互中涌现
    • 需要元认知机制评估约束本身

  3. Layer-1批判的外部锚点

    • 为批判自己建构的理论设计验证器
    • 类似"多选题"的认知线索
    • 核心困境：批判的对象是理论本身，如何获得客观锚点？

实践应用

这个发现对agent开发的启示：

  • 在设计agent时，显式列出任务约束
  • 为每个约束设计验证器（Rule-based优先）
  • 使用约束验证作为奖励信号
  • 当约束无法自动验证时，是风险信号

引用

记录时间: 2026-03-04 13:00