金融合同解析与交易日历规则引擎项目

金融合同解析与交易日历规则引擎，是一条从长合同文本到标准业务规则、再到逐日交易日历的工程链路。输入是资管计划 / 基金合同，输出是费用、业绩报酬、申购赎回开放规则和全年开放状态。

这个项目不是公开 SaaS，也没有公开仓库或在线 demo。这里把它作为脱敏工程项目记录，重点放在架构、模块边界和取舍。

问题定义

合同抽取在这个场景里不是生成摘要，而是给业务系统准备结构化规则。

系统需要处理几类问题：

十万字量级合同无法在内网算力约束下一次塞进模型。
费用和业绩报酬存在分档表、隐含区间、中文数字、百分比和字段边界。
申购赎回开放日要从自然语言变成 9 类周期规则。
顺延、提前、工作日、交易日和连续休市块会影响最终日历。
每次改 prompt、分块或清洗逻辑，都要知道字段结果有没有回归。

技术栈

核心实现以 Python 为主。抽取部分使用 LLM，工程侧重点放在合同分块、模块化 prompt、结果融合、枚举和数值清洗、标准规则 VO、交易日历规则引擎、参数指纹缓存和 EDD 离线评测。

没有公开 repoUrl 或 demoUrl。公开联系方式保留在 GitHub 主页和站点联系入口。

架构

合同文本
  -> 分块定位（chunk=8000, overlap=800）
  -> 5 模块抽取
  -> 双提示词候选（重点模块）
  -> 候选融合与确定性清洗
  -> 标准规则 VO
  -> 交易日历规则引擎
  -> 逐日申赎开放状态
  -> EDD 字段级评测与回归对比

抽取侧和日历侧通过标准规则 VO 解耦。抽取侧可以保留模型输出和清洗逻辑，日历侧只关心扁平规则字段，不依赖抽取内部结构。

核心模块

1. 合同抽取模块

合同被拆成费用、业绩报酬、申购流动性、赎回流动性和其他 5 个模块。费用、业绩报酬、申购流动性使用双提示词风格，单个 case 最多并发 8 路 LLM 调用。

这样做是为了提高分档表、数字规则和流动性字段的召回。双提示词比单提示词约 +3pp，代价是 token 成本更高。

2. 融合与清洗模块

模型输出不会直接进业务规则。清洗层负责：

枚举模糊匹配：如 T+2 / T+2日 / N+2 -> n2。
语义数值解析：如「千分之五」「百分之二十五」「正收益」。
KV 结构归一：把裸值补成下游可处理的结构。
paramList 合并：按左边界 key 去重。
非空字段择优：选择信息更完整的候选对象。

这层的目标不是让模型「更聪明」，而是让输出更稳定。

3. 交易日历规则引擎

日历引擎支持 9 种周期类型：

每月第 X 日
每季第 X 日
每周周 N
每月第 M 周周 N
按月倒数第 X 日
按季倒数第 X 日
每年 Y 月第 X 日
每年 Y 月第 M 周周 N
每年 Y 月倒数第 X 日

所有周期先按自然日取号，再处理交易日历和假期对齐。openDay=32 表示当月最后一日。

4. 假期对齐模块

顺延和提前共用一套对齐算法。系统识别候选日所在的连续休市块，同一休市块内多个候选日按日期升序编号。顺延取节后第 i 个交易日，提前取节前第 i 个交易日。

这个设计避免多个开放日全部挤到同一个节后交易日。

5. EDD 离线评测

评测包含 L0-single、L1-dual、L2-dual-chunk 三档消融，逐级只改变一个变量。它还会抓 expected null 和 spurious 输出，用多模型一致性判断问题更像模型差异、抽取难点，还是 prompt / 金标定义。

我负责的部分

我主要负责：

5 模块抽取链路与双提示词策略。
抽取结果融合、枚举清洗、数值归一和 KV 结构处理。
标准规则 VO 与日历侧解耦。
9 类开放日周期规则实现。
顺延 / 提前的连续休市块对齐逻辑。
参数 md5 指纹缓存策略。
EDD 消融评测与多模型一致性归因。

业务规则口径由我和产品一起确认，对外不写成单人决定全部业务含义。

难点与边界

内网上下文不能拉满，十万字合同不能一次性放进模型，所以分块定位是必要设计，不是性能优化装饰。

双提示词提高了召回，但没有消灭错误。某些语义推断字段还没有完全收口，这类内容不会写成已解决结果。

日历引擎对边界采取保守策略。假期前后最多游走 400 天，找不到交易日就丢弃候选，不硬画日期。

结果

用户补充的结果是，合同处理耗时从数小时缩短到约 2 分钟，字段级结果从 60% 多提升到 90% 左右。系统仍然保留人工复核，尤其是高风险字段和冲突字段。

这个项目给我的经验是：合同抽取能不能用，不只看模型输出，还要看标准规则、日历引擎、评测和人工复核是否一起成立。

金融合同解析与交易日历规则引擎