← 跨层研究

Jargon RL：通过共同演化的领域验证器弥合验证鸿沟

将验证器套件本身变为与模型共同演化之物——以施工计划验证语言 CPML 为例的元对齐范式。

跨层连接器。 上游概念：知识层 (knowledge/) 的框架/策略/事实三层结构，部署层 — IWE 的运行时失败日志。下游作用于：部署层 — IWE 的策略层生长机制，领域层 (domains/) 的 CPML 验证器套件演化。Jargon RL 是知识资产的演化引擎——它回答"验证器套件如何与模型在同一回路中共同进化"。

摘要

基于可验证奖励的强化学习（RLVR）能提供精确无噪的训练信号，但覆盖域窄；基于评分准则的强化学习（RbRL）覆盖域广，却引入主观噪声与奖励破解。本文提出 Jargon RL，一种将验证器套件本身变为与模型共同演化之物的元对齐范式。其核心是将领域专业知识视作一套结构化、可执行的"行话"——即一组确定性验证规则，随着模型训练交替扩展。我们以现代 Python 工具链（pydantic、yaml、pytest）给出可立即部署的工程实现，并以施工计划建模语言 CPML 作为首个完整的旗舰实例。CPML 是一套领域专用语言及编译器，可对施工计划的空间碰撞、资源容量、状态递进、许可在场和材料流速进行确定性验证。在 Jargon RL 的两阶段交替循环中，CPML 的验证器套件根据模型失败日志持续生长，模型则在不断收紧的验证约束下通过纯 RLVR 学习。实验结果表明，Jargon RL 将验证器从静态的外部前置条件转变为学习回路内动态可进化的组件，系统性地缩小了自动可验证域与理论正确性之间的鸿沟。

1. 引言

强化学习已成为将大型语言模型与复杂、不精确的人类意图相对齐的强大后训练范式。任何 RL 流程的核心都是奖励信号的设计。目前两种宽泛的策略占据主导地位：

基于可验证奖励的强化学习（RLVR） 依赖自动化的、确定性的验证器——单元测试、编译器检查、精确答案匹配——来评判模型输出。这些奖励完全准确，但只覆盖了理论可验证域的一小部分。大量中间推理、对领域惯例的遵守以及部分正确性依然不可见。

基于评分准则的强化学习（RbRL） 则采用由人类或通用 LLM 法官评分的评价准则。虽然这样的准则原则上几乎可以捕捉任何抽象要求，但它们引入了主观性、噪声、高延迟和奖励黑客行为。信号广泛但模糊，使得细粒度优化不稳定。

这两种范式之间的差距构成了一个根本瓶颈：如何既保留自动验证器的确定性准确性，又将其触角延伸到专家自然用来判断正确性的丰富、结构化的知识？

行话的启示

我们从人类专家应对这一挑战的方式中获得灵感。当一个领域成熟时，实践者会发明行话——高度专业化的、特定领域的术语，具有四个关键属性：

| 属性 | 含义 | |------|------| | 领域特异性 | 仅标记领域内的核心概念 | | 精确性 | 领域内无歧义 | | 简洁性 | 支持简短、无矛盾的推理链 | | 动态性 | 与领域共同演化 |

化学领域的一个经典例子：为避免元素铬（chromium）和镉（cadmium）的混淆，中国化学家将"铬"重读为 luò，创造了一个清脆、无歧义的标签，将关键信息压缩进一个单音中。

Jargon RL

我们提出 Jargon RL，一种新的训练范式，通过将领域行话系统性地形式化为可扩展的自动验证器套件，在 RLVR 和 RbRL 之间架起一座桥梁。在 Jargon RL 中，学习问题被定义为提交一个能通过所有验证器的仓库补丁——这正是 RLVR 的任务——但验证器本身并非静态。它们被组织成三个层次：

  1. 框架（pydantic 模型），声明领域中哪些概念和关系是重要的。
  2. 事实（yaml），为特定问题实例化这些概念。
  3. 策略，由 pydantic 验证器（字段级与子图级）、pytest 断言以及刻意最小化的审查项组成，后者仅捕捉残余的模糊方面。

Jargon RL 在两个交替阶段中运行：

  • 范式更新阶段：人类专家（初期）或自动故障日志挖掘（框架稳定后）扩展框架和策略以覆盖新发现的失败模式。
  • 模型学习阶段：语言模型针对当前验证器套件进行纯 RLVR 训练。

因为验证器是确定性的，奖励信号保持纯净；因为套件随时间增长，有效可验证域稳步向理论域扩展。

本文贡献

  1. Jargon RL 的概念化：一种元范式，通过使领域行话可执行化，调和 RLVR 的准确性与 RbRL 的覆盖度。
  2. 具体的工程实施方案：基于现代 Python 技术栈（pydantic、yaml、pytest），使该方法可立即部署。
  3. 两阶段交替工作流的描述及其从专家引导到半自动演化的路径。
  4. 旗舰级领域实例 CPML：我们将上述范式落地为施工计划建模语言 CPML，给出其作为 Jargon RL 第一个完整存在证明的实证结果。

2. 相关工作

2.1 基于可验证奖励的强化学习（RLVR）

利用完全自动、确定性检查的奖励设计在代码生成（单元测试通过率）、数学推理（最终答案等价性）和导航（目标状态）等领域取得了成功。代表性工作包括 CodeRL、AlphaCode，以及使用 LEAN 或 SymPy 的数学求解器训练。这些方法的共同特性是粗粒度的成功/失败信号廉价且无歧义，但它们几乎不提供中间步骤的反馈，也无法奖励跨领域的定性规范（代码风格、证明优雅性等）。

2.2 基于评分准则的 RL 与 LLM-as-Judge

为扩展奖励覆盖面，最近的一些方法定义多维评分准则，并聘请人类标注者或大型语言模型进行打分。在 RLHF 变体中，奖励模型根据人类偏好训练；在其他方法中，以准则提示的 LLM 直接输出标量分数。这些方法能捕捉开放式需求，但分数的主观性会引入校准漂移、标注者偏见，以及模型投机取巧、利用表面模式满足准则而不追求真正正确性的倾向。

2.3 奖励塑形与过程监督

过程奖励模型（PRM）旨在为每个推理步骤提供细粒度反馈。然而，训练可靠的 PRM 通常需要昂贵的人类步骤级标注或可能不具泛化性的启发式方法。Jargon RL 与之不同，它不是通过学习模型来"塑造"奖励，而是通过一组不断增长的手工或半自动挖掘的验证器来直接编码领域专业知识。

2.4 领域专用语言与形式化验证

将领域知识嵌入形式规范语言（Z、VDM、TLA+）和自动定理证明器有着悠久的传统。在软件工程中，诸如 Frama-C 或 Dafny 等工具能够实现高保障验证，但需要大量人工形式化工作。Jargon RL 采用一种更轻量的数据验证方法，使用 pydantic 和 pytest，在降低形式化负担的同时仍提供确定性检查。

2.5 软件工程与补丁生成

将模型输出构建为"仓库补丁"的做法将 Jargon RL 与自动程序修复和基于 LLM 的补丁生成（如 SWE-bench）联系起来。这些工作通常针对静态测试套件评估补丁；Jargon RL 可被视为使测试套件本身成为动态、与模型共同演化的制品。

2.6 基于概念与神经符号的系统

先前的一些工作将人类可解释的概念嵌入神经网络（概念瓶颈模型），或使用符号推理指导学习。Jargon RL 共享了将领域概念显式化的精神，但聚焦于可执行验证而非可解释性本身。

3. 方法论：Jargon RL

3.1 问题设定

设目标领域可被专家部分形式化。一个 Jargon 配置由框架 F 和策略 S 构成。给定问题实例的事实 f（F 的具体填充），模型需生成一个计划（或补丁）p，使得策略中的所有验证器 v ∈ S 均返回真。

奖励是这些确定性判断的合取：

\[ R(p; f, S) = \bigwedge_{v \in S} v(p, f) \]

最大化该奖励即为一个标准 RLVR 问题。

3.2 框架、事实与策略

框架（F，pydantic 模型）：定义领域的本体——概念、属性、关系。它回答"本领域什么重要"。例如数学题中的 MathSolution 或代码任务中的 FilePatch。

事实（f，YAML）：对特定问题实例化框架，提供已知的具体值：问题陈述、初始环境、允许的资源等。

策略（S，验证器 + 断言 + 审查项）：

  • pydantic 验证器：在字段和模型层面强制执行结构性与逻辑性约束。
  • pytest 断言：在沙箱中执行生成产物并检查运行时行为。
  • 审查项：保留给无法硬化的极少数模糊需求，作为后续范式更新的优先自动化目标。

3.3 两阶段交替工作流

Jargon RL 在两个阶段间循环迭代：

阶段一：范式更新

范式更新并非单一操作，而是包含两种性质根本不同的修改路径：

路径 A：框架修改。 当失败模式暴露的不是个别规则的缺失，而是框架抽象本身的不足——现有场类型无法表达某种物理约束、现有关系模型无法捕捉因果传递——架构师需要修改框架 F。这类修改是结构性的：引入新的原语、调整本体层级、或重新定义场的组合语义。它们频率极低，不可逆，且不能被当前的自动化流程生成——它们来自架构师对领域本质和工程约束的同时理解。

路径 B：策略修改。 当框架足够表达问题但缺少具体检查时——例如新增一个已知风险模板的断言组合，或补充一条字段级的 pydantic 验证器——这些修改由失败日志驱动。聚类器识别常见错误模式，辅助 LLM 根据当前框架生成候选验证器，通过冲突检测后进入人工审核队列。这类修改频率高、可累加、且半自动化可行。

两种修改服务于同一个目标——扩大有效可验证域 V(S)——但它们的知识来源不同：路径 A 来自架构师的设计判断，路径 B 来自模型的失败数据。范式更新阶段结束时，输出更新后的配置 (F′, S′)。

阶段二：模型学习

  • 设置：实例化一个标准策略梯度算法（PPO、GRPO 等），用 S′ 对生成的方案进行确定性奖励计算。
  • 训练：优化模型 π_θ 经 T 步。所有未通过全部验证器的轨迹均被记录，用于下一轮范式更新。
  • 完成：当验证性能饱和或计算预算耗尽时结束本阶段。

两阶段交替进行，每个周期都使有效可验证域 V(S) 扩大，逐步逼近理论可验证域。模型从未见过带噪奖励。

这个区分是 Jargon RL 演化健康性的关键保障。如果范式更新只在策略层面堆积规则而不修正框架，验证器套件将退化为一组平铺的、隐含冲突的、无人能说清其架构的补丁集合——每个失败模式被单独修补，但没有人能说清这些规则之间的结构关系。健康的演化要求框架保持对策略的领先：当策略层的规则数量膨胀到某个程度，意味着框架抽象需要一次重新审视与升级。

3.4 从专家主导到数据驱动的行话演化

Jargon 的定义本身是一项软件工程任务。理解什么可以自动化、什么不可以，是理解 Jargon RL 可行性的关键。

框架的设计本质。 三层的 Jargon 配置中存在一种根本的非对称性：框架 F 的结构性约束决定了整个验证器套件的表达能力边界，而策略 S 中的具体验证器仅在这个边界内填充细节。F 的初始设计——例如 CPML 的场-探针-投影抽象——不是从失败日志中推导出来的，也并非形式化需求的机械映射。它来自架构师对领域本质的判断：什么概念是原语，什么概念是派生；什么约束是结构的，什么是实例的；在哪条线上切一刀，可以既覆盖足够多的真实失败模式，又保持框架本身的简洁性。

这种判断无法被当今的任何自动化流程替代，因为它的输入不是数据，而是约束之下的取舍。在任何软件架构开始之前，前后端分离、存储逻辑分离、逻辑接口分离等启发式蓝图已经存在——架构师真正的决策不是发明这些模式，而是根据项目的人力、工期、性能需求等实际约束，判断哪些模式不能砍、哪些可以简化。Jargon RL 的框架设计正是这个性质的工作：它是演化回路的初始条件，是所有后续验证器生长的组织原则。

半自动化演进。 一旦框架稳定，策略层的生长可以通过下述机制半自动化：

  1. 失败日志挖掘：无监督聚类未能通过特定验证器的轨迹。
  2. 自动建议：利用辅助 LLM，根据当前框架和事实模式，生成能拒绝这些失败模式的 pydantic 验证器或 pytest 测试。
  3. 护栏：自动检查新验证器不会拒绝真值解，且不与现有验证器冲突，通过后进入人工审核队列。

演化健康性的保障。 范式更新中存在一个必须警惕的退化趋势：如果每次更新只在策略层添加规则而不回顾框架抽象，"验证器套件"将逐渐退化为针对表面症状的补丁集合——三条规则覆盖同一个语义约束的不同表现形式，规则之间隐含冲突靠添加顺序决定优先级，无人能说清全局"架构"是什么。与之相反，健康的演化要求在添加新验证器之前，先判断"这个失败模式是否暴露了框架抽象的错误或缺失"。如果是，应修改框架——引入新的场类型、泛化现有场的语义、或调整本体层级——而不是在策略层写一个特化检查。换言之：好的演化不是堆积规则，而是规则的规则在生长。

该混合回路模仿人类行话的演化：由创始人积极协商形成核心术语体系，随后被社区编纂与传授，偶因异常积累而被系统性地改革。

4. 实验设置：CPML 施工计划建模语言

为实证检验 Jargon RL，我们构建了 CPML——一个完整的施工计划验证语言与编译器，并将其作为 Jargon RL 三层结构的具体实例。

4.1 CPML 作为 Jargon 实例的映射

| Jargon 层 | CPML 对应 | |-----------|----------| | 框架 (F) | 6 种场类型（Occupancy、Capacity、Scalar、Presence、Rate 等），几何体素，活动依赖与时序模型，语法糖与模板。定义"什么重要"：空间冲突、资源容量、状态递进、许可有效性、流速监控。 | | 事实 (f) | 一个具体的 .cpml 文件，包含 geometries、activities、timespan、depends_on 等实例化数据。 | | 策略 (S) | CPML 编译器的全套检查逻辑，包括 AABB/GJK/遮挡剔除碰撞检测、场值叠加与断言求值、依赖循环检测等。诊断分 Error/Warning，任何 Error 均导致奖励为 0。 |

4.2 CPML 核心机制概要

场-探针-投影模型：活动通过投影向场写入影响（如占据空间、消耗资源），通过探针从场读取状态并做出断言（如"该区域必须为空"、"混凝土强度 ≥ 0.7"）。

语法糖（如 collision > demands > structure）将高频模式压缩为简洁声明，降低模型生成难度。

活动模板：预定义不可剥离的风险包络（如焊接操作自动带有火源、可燃气体敏感性），防止模型遗漏物理上必然伴生的约束。

编译器：将 CPML 文件按时间轴展开为关键帧，在每个关键帧求值所有场与断言，输出诊断、风险指数和工期。

场-探针-投影作为架构决策。 上述抽象不是从模型失败日志中涌现的——它是在任何训练开始之前被确立的架构决策。它的替代方案很多：可以用约束求解器（将施工计划编码为 CSP）、时序逻辑（TLA+ 风格的状态机）、或 Petri 网（对资源流动建模）。这些蓝图在形式化方法领域都是已知的。架构师的角色不是发明全新抽象，而是根据 CPML 的实际约束——需要用 YAML 声明、需要用 pydantic 验证、需要让领域工程师能读懂、需要覆盖空间/资源/时序/速率四类约束——做出裁剪：场-探针-投影走到哪一层抽象足够，哪一层可以简化为语法糖。这个决策的质量，决定了后续所有策略层验证器生长的方向与上限。

4.3 CPML 的演化能力

CPML 在设计上即支持 Jargon RL 的范式更新。初始的场种类和验证器仅覆盖基础约束；随着模型训练暴露新失败模式（如吊装与喷漆虽不碰撞但产生可燃气体积聚），领域工程师或失败日志挖掘器可向策略中新增场类型、活动模板或断言组合，并自动完成与真值解的冲突检查。这一能力使 CPML 的验证边界能够与模型能力同步扩张。

4.4 任务与模型

  • 任务定义：给定项目的 BIM 导出信息、合同工期、资源上限等事实，模型需生成对应的 .cpml 计划文件。
  • 奖励：由 cpml check 是否检出 Error 决定，无 Error 则奖励 1，否则为 0。
  • 训练流程：监督微调初始化 + GRPO 强化学习，每轮学习后收集失败计划用于下一轮范式更新。

5. 实验

（本节暂留空，用于后续呈现交替训练实验、验证域扩展曲线、模型性能对比、消融实验及案例研究等。）

6. 结论

本文提出了 Jargon RL，一种将领域行话转化为可执行、可生长验证器的新型对齐范式。通过建立三层结构（框架、事实、策略）和两阶段交替工作流，Jargon RL 将 RLVR 的确定性优势与 RbRL 的广覆盖潜力统一起来，同时避免了前者的静态窄化和后者的噪声与奖励破解。我们不仅在概念上论证了该范式的必要性，还提供了基于现代 Python 工具链的可行工程方案。

以 CPML 作为旗舰实例，我们展示了 Jargon RL 在复杂真实领域的完整落地路径。CPML 从初始的几类场和基础断言出发，在与模型训练的交替演化中，逐步生长出覆盖空间碰撞、资源容量、状态递进、许可管理、流速监控和风险模板的丰富验证体系。模型在没有任何人类主观评分的情况下，学会了生成通过所有这些硬性检查的施工计划。

Jargon RL 的核心启示在于：对齐不应只被视为评分问题，而更应被视作一个持续集成的系统工程问题，其中领域验证器与模型同等重要，且二者必须在同一回路中共同进化。这一视角突破了当前 LLM 对齐中对"更大更好的奖励模型"的路径依赖，为可扩展监督提供了一种基于形式化行话的替代方案。

设计原则与开放挑战

Jargon RL 的实践暴露了几个值得进一步讨论的问题。

规模与可理解性。 CPML 的一条 collision > demands > structure 是可读的，但一个真实项目的 CPML 可能包含数百条活动与数十种场的叠加——读得懂每条规则，不代表能追踪全局因果链。这是所有形式化系统的宿命：软件工程师无法逐行理解 Linux 内核的因果链，但这不意味着 C 语言是失败的。形式化的意义不在于让全局变得"可读"，而在于让关键局部精确可查，并让正确性判断从人脑转移到机器。但这提出了一项工程要求：验证器套件的生长必须伴随相应的可解释性基础设施。当验证器数量膨胀，需要自动生成因果摘要来回答"这 5 项活动的延迟是因为哪个场的什么约束"，需要从统计指标到原始断言的分级下钻路径，需要每一条被触发的验证器本身提供可理解的失败原因。可解释性不应是事后补救的仪表盘，而应被设计为验证器套件的内建属性。

框架与策略的演化非对称性。 本文第 3.3 节区分了框架修改与策略修改。这一区分的实际后果是：演化回路中需要一个明确的审查节点——在添加新验证器之前，判断"这个失败模式是否暴露了框架抽象的错误或缺失"。如果是，应修改框架而非在策略层堆积特化检查。忽略这一审查的长期代价是验证器套件的退化：规则平铺、隐含冲突、整体架构不可追溯。这个审查节点目前在 CPML 的工作流中由人类架构师承担；如何在框架稳定后为它提供半自动化的辅助决策支持，是一个值得进一步研究的问题。

行话的可迁移性。 为 CPML 构建的场-探针-投影框架在多大程度上可复用于其他空间-资源-时序约束领域（如芯片布局、物流调度）？如果每个领域都需要从零设计框架，Jargon RL 的边际成本将过高。我们预期不同领域的框架将共享一定数量的抽象原语——场、容量、约束传播等概念并非施工独有——但这些共享原语的具体形式与粒度仍是开放问题。

未来工作

  1. 自动化范式更新：利用 LLM 从失败轨迹中挖掘新规则，并自动完成冲突检测和迁移。
  2. 跨领域推广：将 Jargon RL 推广到芯片布局验证、合规审查、物流调度等其他具有丰富结构化知识的领域，并在过程中检验框架原语的跨领域可复用性。
  3. 审查项硬化：探索将残留的软性审查项逐步硬化的一般方法，最终实现全自动、零主观的领域对齐闭环。
  4. 可解释性内建：将因果摘要生成、分级下钻和验证器自解释能力作为验证器套件的设计约束而非事后补救。