AI执法办案辅助审核实战：规则引擎与大模型如何协同

审核员一天的工作量，很多时候不是被复杂案件压垮的，而是被几千份雷同文书里的数百个数字和日期磨掉的。我们接到某地执法单位的试点需求时，第一反应并不是“用AI取代审核”，而是先问了一个不那么性感的问题：这个流程里，到底哪些动作是重复且机械的？这篇内容想分享的，就是我们围绕AI执法办案辅助审核系统做的一次完整落地实践——从场景拆解、三层技术管线搭建，到数据迭代、人工复核闭环设计，再到实测效果与踩过的坑。如果你的工作也涉及大量文书审核、材料比对，或者你想在业务系统里引入辅助审核能力，这篇应该能给你一些直接能用的思路。

1. 先把“人在回路”里最累的环节找出来

1.1 高频耗时集中在三处

我们做需求调研时，把审核员的日常工作拆成了动作粒度，统计下来发现耗时最重的并不是“思考案件本身”，而是一堆看起来简单、但量极大的机械操作。第一类是要素级比对，比如一份案卷里当事人的名称、证件号码、金额、日期在多个文件中是否一致，这一项几乎占了将近四成的时间。第二类是形式完整性审查，比如文书中的签字、盖章、页码、附件清单是否齐全，日期先后顺序是否合理，这些规则非常明确，但人眼盯着屏幕逐项核对，效率天然很低。第三类是引用一致性校验，也就是案件事实的描述和最终结论之间的对应关系是否成立，常见问题包括事实部分提到了某个情节，但结论依据里却没有回应，或者两个位置的说法自相矛盾。

这三类工作的共同特点是：重复、机械、大量出现，但出事概率又很低。正是因为低概率，审核员容易疲劳，反而在真正需要判断力的环节上精力不足。我们当时就意识到，系统最该先介入的，不是“读懂案情”，而是先把这些确定性高、规则可描述的活儿接住。

1.2 系统边界：规则引擎与模型的分工

需求拆完以后，团队内部争论最激烈的问题就是：什么东西用规则写，什么东西交给模型学。我们的结论是，判断标准只看一条——这个校验项能不能被业务人员用几句话说清楚。能说清楚的，比如“日期不能早于立案日期”“文号格式必须是年份加序号”“金额必须等于各项之和”，全部做成规则引擎。说不清楚的，比如“描述的事实是否支持这个结论”“表述是否存在明显矛盾”，才交给自然语言处理模型。

这个边界如果划早了，后面一定会返工。项目里有个同事一开始特别想把所有东西都塞给模型，理由是“规则写起来太土了，不智能”。后来我们做了一个专项对比，发现凡是能被规则覆盖的项，模型准确率再高也拼不过规则引擎的稳定性和可解释性。规则引擎的响应是毫秒级的，而每次模型推理少说也要几百毫秒，更重要的是规则出错时可以立刻定位哪行代码的问题，模型出错了你只能从头训数据。

1.3 为什么“辅助”比“自动”更合适

系统命名里带着“辅助”两个字，是我们刻意为之的。一开始甲方也问过，既然模型已经能识别文书问题，为什么不能直接自动生成审核结论？我们的回答比较直接：审核结果直接影响案件处理质量，一旦出错，责任归属和纠错成本都不可控。自动输出一个“通过”容易，但谁为这个“通过”负责？

另一个原因是信任曲线。业务人员对系统的接受度，是靠一次次“它提示的问题确实存在”积累起来的。如果系统第一天就试图全自动处理，碰到一次误报，后续再想让人工复核就很难推进了。我们的策略是让系统永远停留在“提示建议”的位置，最终确认必须由人完成。这个设计原则，在整个开发周期里反复救了项目好几次。

2. 三层技术管线：解析、规则与大模型护栏

2.1 文档解析：结构化是一切的前提

辅助审核系统面对的第一道难题，不是算法，而是“把纸面内容变成结构化的数据”。案卷材料里既有扫描件，也有电子文档，还有大量表格和手写签名，版式五花八门。我们搭了一套分层解析管线：第一层做图像预处理和OCR，把扫描件转成文本；第二层做版式分析，识别段落、表格、页眉页脚；第三层做字段抽取，把人名、日期、金额、文号等关键要素从文本中定位出来。

这里最容易踩的坑是“重识别、轻布局”。刚开始我们只关注OCR的准确率，后来发现很多字段即使识别对了，位置信息丢了，规则引擎根本没法判断它到底属于哪个区块。比如同样一串数字，出现在“立案日期”和“结案日期”两个字段里，含义完全不同。我们后来把每一条OCR结果都带上坐标和所属区块标签，再喂给下游抽取模块，整体准确率才有明显起色。

2.2 规则引擎：确定性问题用断言搞定

文档结构化做完以后，规则引擎的活儿就非常直接了。我们把每个校验项定义成一堆布尔断言，传入解析后的结构化字段，逐条触发。举一个很简单的例子，日期先后关系的校验逻辑大概长这样：

def check_date_sequence(record, field_before, field_after): date_before = record.get(field_before) date_after = record.get(field_after) if not date_before or not date_after: return {"pass": False, "reason": "日期字段缺失"} if date_after < date_before: return {"pass": False, "reason": f"{field_after}早于{field_before}", "expected": f"{field_after}应晚于{field_before}" "actual": f"{field_before}: {date_before} / {field_after}: {date_after}"} return {"pass": True}

实际工程里规则远比这复杂，但结构是一致的：每个规则都返回“是否通过、问题级别、原因描述、涉及原文位置”。这样审核员看到提示时，不需要自己重新推导一遍，直接看理由就能判断到底是不是误报。我们的规则全部采用配置化管理，业务人员可以自己在后台调整某个阈值或启用状态，不用每次改逻辑都找研发。这一点在长期维护里价值很大。

2.3 大模型：做语义判断，但必须有护栏

语义类的校验，比如“事实描述与结论的对应性”“两份材料中表述冲突”，规则没法写全，我们选择用基础模型来做。这里必须说清楚一点：大模型在这个场景里不是用来生成内容的，而是用来做判别和抽取的。我们让模型输出固定结构的JSON，包含问题类型、风险级别、相关原文引用、判断理由，并且强制模型对每个结论引用文本片段作为证据。

护栏是这一层的核心。我们在模型调用外面包了一层校验模块，专门检查模型输出格式是否符合约定，JSON字段是否完整，引用片段是否真的存在于原文中。如果模型输出的引用没有找到原文，宁可丢弃这条结果，也不要把它展示给审核员。另外所有模型判断都附带置信度分数，低于阈值的直接不展示，避免给审核员增加噪声。实测下来，这个“宁可少报不可错报”的设计，比任何prompt调优都管用。

2.4 选型对比与本地化部署

关于模型选型，我们做过一轮实际对比，这里可以作为一个参考。自研规则和小模型负责确定性问题，开源基座模型负责语义理解，商用接口负责兜底，但最终在执法数据不能出域的限制下，商用接口方案基本被排除。我们的选择是本地化部署一套开源基座模型，配合蒸馏出来的小模型做高频简单任务。

这个对比表看着简单，背后是有代价的。本地部署基座模型意味着要投入GPU服务器和专门的运维人力，项目预算一下子涨了一截。但考虑到数据安全相关制度要求，这是绕不开的投入。我们在方案汇报里用了很朴素的一句话来说服甲方：系统可以被替换，数据流出去收不回来，这笔账一定要算清楚。

3. 数据集与迭代：从“能跑”到“可信”

3.1 标注规范先行

模型效果的地基是标注数据，而标注数据的质量取决于一套能让不同人执行出相同结果的规范。我们刚开始迭代时，最大的问题不是模型，而是标注团队对“什么是问题”的理解不一致。同样一段文字，A标注员觉得是矛盾，B标注员觉得只是表述冗余，C标注员干脆标成无问题。这种情况下模型学到的全是噪声。

后来我们花了两周时间，专门做了一版标注指南，核心原则是：任何标注都要落到“原文可引用的证据”上。比如判断“表述不一致”，必须同时标出两处冲突的文本位置；判断“事实与结论不符”，必须标出事实段落的哪句话对应了结论里的哪句话。除此之外还设计了双人标注加争议仲裁流程，每个批次抽一部分样本做一致性校验，不一致的样本全部重新讨论。规范定下来以后，标注效率反而提高了，因为分歧少了，返工少了。

3.2 种子集、回灌与半监督

冷启动阶段没有足够的历史数据，我们先让规则引擎跑一遍存量文书，把机器判定“有问题”的结果交给业务骨干修正，修正后的数据作为种子集。这个过程听起来土，但非常有效。业务骨干在修正过程中，顺带会写一句“为什么这不是问题”，这些评语就成了我们后来训练误报判断模型的最宝贵语料。

系统上线以后，反馈数据开始持续回流，我们构建了一个闭环：审核员每天对AI提示做出的“确认/驳回”操作，全部进入样本池，筛选清洗后定期加入训练集。再配合半监督聚类，把模型嵌入表示相近但没有标签的文本聚在一起，由标注员集中检查聚类结果，经常能发现一些业务上没提前预料到的新问题类型。比如有一类“金额大写与小写不一致”的问题，就是用聚类发现的，后来专门加了一条规则处理。

3.3 评价指标：准确率不是唯一答案

辅助审核系统的指标体系和普通分类模型很不一样。离线阶段我们看召回率和误报率，在线阶段更看重几个业务指标：

其中很容易被忽略的是“人工确认率”。有些项目汇报时模型准确率很高，但审核员根本不点系统提示，说明提示太泛，或者理由不清楚。我们后来把“人工确认率”作为每周复盘的第一指标，这个数字持续上升，才说明系统真正进入了工作流。

4. 上线闭环：让审核员愿意接住AI的提示

4.1 交互设计决定使用率

系统做出来没人用，等于没做。我们第一版原型把问题列在文档下方，审核员需要在两个区域来回切换查看，结果试用反馈非常差。后来改成完全嵌入式的交互：文本原文就是操作界面，有问题的句子直接高亮，鼠标悬停或者点击时，浮层会展示规则命中的原因、涉及字段、相关原文片段。比如“日期逻辑异常”这条提示，点一下就能跳到两个日期各自所在的段落，原因栏直接写明“结案日期早于立案日期”。

这个改动表面上只是前端交互，实际上是业务逻辑的深刻变化。审核员每天要面对上百条提示，如果每一条都要来回找原文，很快就会烦躁。只有把“为什么提示”放到眼前，他们才愿意继续使用。这一版上线后，人工确认率明显提升，说明问题不在于审核员抗拒AI，而在于系统有没有提供足够的上下文。

4.2 反馈闭环：每条提示都要有去处

系统里有一个不成文的规定：任何一条提示都不能“下落不明”。审核员看到提示后有三个操作按钮——确认、驳回、忽略，每个操作都要填原因，驳回和忽略的区别在于“问题确实不存在”还是“问题存在但本次不影响结果”。这些反馈数据每天汇总，每周开一次复盘会，业务骨干和研发坐在一起，逐类看误报和漏报。

复盘会开几周以后，产生了一个很有意思的效果：业务人员开始主动提“能不能加一条校验规则”，因为他们发现自己经常犯某类低级错误，而系统还没覆盖。当业务人员从“被系统提示”变成“给系统提需求”时，这个项目的信任问题就基本解决了。我们后来还做了一个小功能，审核员可以自己给某类提示设置敏感级别，比如“金额问题必须逐条确认，格式问题自动折叠”，把控制权交给使用者，系统就不再是一种打扰。

4.3 权限、留痕与数据安全

执法数据的安全要求等级天然高，这部分没有任何妥协空间。系统里所有账号按角色分级，普通审核员只能看到自己承办范围内的案卷，组长可以看组内统计，管理员才能配置规则引擎。每一个AI提示的生成、审核员每一次确认或驳回，全部写进不可篡改的审计日志，日志包含操作人、操作时间、原始输入、模型输出版本。为什么要记录模型版本？因为模型更新后，行为可能变化，如果没有版本信息，后续排查问题几乎无从下手。

数据脱敏也是上线前的硬性要求。我们在系统入口做了一层动态脱敏，模型训练数据全部去掉可识别身份信息，展示层则做了权限控制。这块投入的工时不算少，但必须做扎实。我们内部常说一句话：业务功能做得再好，安全不过关就不能上线，这不是技术问题，是底线问题。

5. 实测效果与翻车复盘

5.1 试点数据：节省时间不等于替代判断

试点运行了两个月，范围控制在某类数量较大、标准化程度较高的案卷上。统计下来，审核员处理单卷文书的时间平均减少约三成，其中形式审查类环节的耗时下降最明显，从十几分钟缩短到几分钟。系统提示的人工确认率稳定在四成左右，误报率控制在可以接受的范围内。数字看起来不错，但要提醒一句：试点范围有限，且人工确认率四成说明系统提示的质量还有提升空间，距离“每个提示都靠谱”还远。

更值得关注的是漏报回收。审核员自己发现问题而系统没提示的情况，在第一个月还比较常见，主要集中在新出现的文书模板变动上。我们后来在巡检流程里加了一条：每周统计漏报类型，反馈到规则配置和模型训练计划里。到试点结束时，漏报率出现了比较明显的下降，说明反馈闭环确实在起作用。

5.2 三个典型翻车现场

第一个翻车是OCR识别错误。数字“2023-10-01”里的数字“1”被识别成了小写字母“l”，业务字段和日期规则全乱了，系统疯狂误报。修复方案不是换OCR引擎，而是在字段解析层增加格式校验，识别结果不符合日期格式的，统一标记为“疑似识别异常”，进入人工复核队列而不是交给规则引擎。第二个问题是模型对否定句的误判。原文写着“不存在未告知当事人权利的情形”，模型把它理解成存在违规情形，反手报了一条“程序缺失”。后来我们在模型训练数据里大量增加否定表达样本，同时在提示词里要求模型先判断语气再判断事实。第三个问题是规则引擎自己的边界条件写太死，比如“金额不得低于某值”这个规则没有考虑特殊情况下的合法例外，导致一批合规文书被误报。最后的修复是给每条规则增加了“豁免条件”配置和一些组合规则的判定能力，让规则也能表达“虽然有异常，但如果同时满足某些条件则放行”。

这三个问题有一个共同教训：辅助审核系统的故障，往往不是单一组件的责任，而是组件之间缺少兜底校验。OCR出错靠格式校验兜底，模型误判靠阈值和人工复核兜底，规则过严靠豁免条件兜底。

5.3 坚决不交给AI的环节

最后说一下我们主动划掉的范围。这个系统从头到尾做的是“辅助审核”，但有三件事我们明确不做：最终结论的签名确认，必须由具备权限的审核员完成；涉事事实的争议认定，当审核员与系统判断不一致时，以人的判断为准；需要个别沟通和裁量的事项，系统完全保持沉默。

之所以划出这些边界，不是技术能力做不到，而是责任和信任的问题。系统可以提醒，可以提示风险，可以帮人节省时间，但把判断权从人手里拿走，反而会破坏整个工作流程的稳定。我们内部有一条不成文的规定：任何AI提示最终都需要人工确认，系统的目标永远是让人更轻松地做出正确决定，而不是替人做决定。

这次做完最大的体会是，辅助审核系统真正难的不是模型准确率，而是让审核员愿意接住这些提示。业务方对你的信任，不是一个上线通知就能建立的，而是靠每一次提示都有据可循、每一次反驳都有回应积累起来的。下次再做类似系统，我会先花更多时间在业务语义的对齐上，把规则边界、交互方式、反馈闭环想清楚后再动手写模型代码，这条路走起来慢，但确实稳。