头部券商资管合同解析与交易日历规则引擎

金融合同解析与交易日历规则引擎，是把资管合同里的自然语言条款抽成标准规则，再生成全年逐日开放状态的系统。这个案例服务于某 A+H 上市头部券商的资管业务，重点不是做一个抽取 demo，而是让结果能进入后续规则和复核流程。

背景

资管产品合同通常是十万字量级。业务需要从合同里整理费用、业绩报酬、申购赎回开放规则、确认方式、锁定期、封闭期等信息，再维护到内部系统。

第一版功能上线后，实际价值有限。原因很直接：准确率偏低，合同自然语言映射到标准规则这一步经常出 bug。比如业绩报酬分档里，合同可能只写「8% 到 15% 收取 5%，15% 以上收取 10%」，但业务上还隐含一个 8% 以下收取 0% 的分档。模型如果没补出来，后面的标准规则就是缺的。

真正麻烦的地方

这不是普通文档抽取。合同条款抽出来之后，还要继续变成可计算的规则。

费用和业绩报酬涉及分档表、中文数字、百分比、隐含区间和字段边界。申购赎回涉及开放日、顺延、提前、自然日、工作日、交易日。一个开放规则可能写成「每年 9 月第三个周五下一周的周二及此后两个工作日，遇非工作日顺延」，这句话必须拆成枚举字段，再结合交易日历生成具体日期。

如果只返回一个 JSON，看上去像完成了。真正接到业务系统时，问题才开始暴露。

我负责的部分

我主导了合同解析、标准规则映射、EDD 评测和交易日历规则引擎的工程实现。

抽取侧，我把合同解析拆成 5 个模块：费用、业绩报酬、申购流动性、赎回流动性和其他。重点模块跑两套不同风格的 prompt，单个 case 最多并发 8 路 LLM 调用。双提示词比单提示词约 +3pp，主要价值是把分档表和数字规则更多地拉进候选结果。

清洗侧，我实现了枚举模糊匹配和数值语义归一化。比如把 T+2、T+2日、N+2 归到同一个确认方式，把「顺延」「工作日」「千分之五」「正收益」这类自然语言表达转换成系统能处理的字段。

日历侧，我把开放规则拆成「自然日取号 -> 交易日历处理 -> 假期对齐」。规则引擎支持 9 种周期类型，openDay=32 表示当月最后一日。顺延和提前使用同一套对齐逻辑，只改变查找方向。

方案与取舍

双提示词不是为了显得复杂，而是因为单提示词在分档表上不稳。代价是 token 成本上升，但高风险字段多进入复核范围，比省调用成本更重要。

确定性清洗也是类似取舍。枚举归一、百分比转换、KV 结构补全放在代码里，比靠 prompt 反复提醒更可复现。但我也保留了边界：清洗可以兜底格式和常见语义，不能替代业务定义。没有收口的字段，不写成系统已经解决。

交易日历里有一个关键细节：同一连续休市块里的多个候选开放日，不能全部顺延到节后第一天。系统会先给候选日排序编号，再顺延到节后第 i 个交易日，或者提前到节前第 i 个交易日。这样日历不会被挤成错误的一天。

缓存侧用规则参数 md5 指纹隔离结果。查询时只有 taskId、年月和参数指纹都一致才用旧数据；参数变了就现算，避免旧日历污染新规则。

结果

用户补充的结果是：合同处理耗时从数小时缩短到约 2 分钟，字段级结果从 60% 多提升到 90% 左右。双提示词相对单提示词约 +3pp。

这套系统没有把金融合同处理变成无人值守流程。它更像是把最重复、最容易漏的部分前置给系统：先生成结构化规则、证据、冲突和日历，再让人工复核高风险字段。

我的判断是，金融合同自动化的可靠性不只来自模型，也来自三个更朴素的东西：字段级评测、确定性清洗，以及愿意承认哪些地方还要人工看。

相关链接

• 案例列表
• 项目列表
• GitHub

如果你正在做合同抽取、文档解析、字段评测或金融业务规则引擎，可以通过下方微信二维码或邮件沟通，邮箱：contact@aildnc.com。