规则学习不是自动写规则：一条受控生产流水线

把制度文件交给大模型并要求“生成规则”，看起来是最短路径，却把多个高风险步骤压缩进一次不可控输出：条款是否识别正确、字段是否真实存在、例外是否遗漏、规则能否执行，都失去了独立检查点。

更稳妥的设计是把规则学习建设成一条受控生产流水线。

flowchart LR
  A[制度文档] --> B[文档解析]
  B --> C[条款理解]
  C --> D{要素存在?}
  D -- 是 --> E[候选编译]
  D -- 否 --> F[要素缺口]
  E --> G[验证与发布]
  F --> H[人工补充]
  H --> D

阶段一：文档解析

上传后先计算文件哈希，识别重复与版本关系。解析需要保留页码、段落、表格和坐标；扫描件进入 OCR。章节结构优先由确定性规则识别，大模型只处理复杂歧义。

输出不是一段纯文本，而是可定位、可修订的条款实体和解析任务记录。

阶段二：条款理解

模型按固定 Schema 提取主体、行为、对象、条件、阈值、单位、例外、后果和引文。服务端随后校验枚举、数值和引文是否真实存在。

模型可以帮助解释语言，但不能自由决定执行协议。

阶段三：要素对齐

先用术语词典和别名做确定匹配，再从现有字段、标准表、词库和数据源中召回候选，最后让模型排序并说明理由。候选必须来自白名单，低置信映射交给人工确认。

如果制度要求的要素不存在，应生成“要素缺口”，而不是让模型编造字段。

阶段四：候选编译

模型输出中间表示，由确定性编译器转换为平台已有检查类型或规则 DSL¹。编译器负责操作符白名单、数据类型、条件树、引用存在性和静态冲突检查。

无法安全编译的条款可以降级为人工复核建议，这比生成一条貌似完整的错误规则更有价值。

阶段五：验证与发布

候选依次通过语法校验、引用校验、样例试算、历史回放、人工审阅和发布审批。发布后形成不可变规则版本，并固化制度条款、字段映射、模型与提示版本。

这条流水线的真正产物

规则学习的产物不只是规则，还包括条款知识、映射关系、要素缺口、测试样例、评测报告和来源血缘。它把“生成能力”放进可以追责的工程过程里，也为后续规则进化建立了共同底座。