做了几年司法领域的AI应用架构有个感受特别深文书生成这类任务上线前大家最担心的是模型不够聪明上线后挨骂最多的反而是它太“聪明”——会一本正经地编出一个不存在的案号、引用一段已经废止的法条、把当事人身份信息写错。这种错误跟“生成速度快不快”“语句通不通顺”没关系它属于质量问题会直接触碰司法文书的严肃性。今天想聊的就是我们架构师在设计和落地司法AI文书生成系统时如何从架构层面把错误率压下去、把质量兜住。这篇内容不是某个现成产品的使用教程而是我在项目里实际验证过的工程思路如何通过分层校验、结构化约束、人机协同、全链路追溯把大模型的不确定性锁在笼子里。适合正在做法律科技、政务文书、金融合规报告这类“严肃文本生成”方向的朋友参考。你可以直接拿去对照自己的系统设计逐条检查哪些防线还没建。1. 先搞清楚危险都在哪文书生成的典型错误分类大多数架构设计失败不是方案不够高级而是“没定义清楚错误长什么样”就开始动手。我习惯把司法文书生成的错误分成三类幻觉类、规范类、一致性类。这三类错误性质完全不同对应的防御手段也完全不同。1.1 幻觉类错误模型“一本正经地胡说八道”幻觉是大模型天生的毛病。在司法场景里它表现得非常具体编造一个看起来合法的案号、给当事人分配一个现实中不存在的地址、引用一段根本不在法条库里的条文、把一个侵权事实写成违约事实。这类错误的可怕之处在于“语法完全正确、语气非常专业”普通人根本看不出来。我做过一个内部统计在没有约束的纯自由生成模式下500份测试文书里约有12%包含至少一处幻觉类错误其中案号和法条引用占了大头。这个比例在演示环境里大家还能接受一旦上到真实业务线任何一份文书出错都可能引发严重后果。所以架构设计的第一原则就是永远不要让模型直接从空气里生成关键事实字段。1.2 规范类错误格式、称谓、日期、数字的“小问题”这类错误看起来很不起眼但在司法文书里非常致命。比如法院名称的规范写法不对、审判员和法官助理称谓混淆、日期格式不统一“二〇二四年”和“2024年”混用、金额的中文大写数字和小写数字对不上。裁判文书有严格的制作规范格式乱、不统一直接影响公文的严肃性和权威性。规范类错误用大模型本身很难根除因为模型是按概率生成token的它不理解“这个位置必须长成什么样”。格式问题恰恰是确定性最高的部分——应该用模板和规则去卡而不是靠模型“自觉”。1.3 一致性类错误前后矛盾、与事实脱节还有一种错误最隐蔽文书前后表述不一致。比如事实部分写的是原告主张赔偿5万元判项部分却写成了5千元证据列表里有一份鉴定意见正文的说理部分却完全没有引用裁判依据引用的是新修订的某部法律但说理时还在用已经废止的旧条文表述。这种错误往往不是模型单次生成造成的而是“要素抽取-生成-格式化”链条中某个环节丢失了信息。架构角度来说本质上是输入和数据流设计出了问题得靠结构化字段的强约束和前后一致性校验来解决。我用一张表总结这三类错误的特征。后面所有架构设计都围绕这张表展开错误类型典型表现根因防御手段幻觉类编造案号、法条、事实模型自由生成要素回填/检索约束/知识库比对规范类格式、称谓、数字错误概率生成不理解规范模板约束/规则引擎/后处理一致性类前后矛盾、要素丢失数据流断裂结构化字段/一致性校验/全链路追溯2. 架构设计的总体思路别把宝全押在模型上很多团队做文书生成一开始的思路就是“选一个大模型把案件事实丢进去让它写”。结果通常是demo惊艳、试点拉胯、上线翻车。原因很简单——大模型本质是一个概率系统它可以在你有上下文约束时表现很好但只要你放松约束它就自由发挥。2.1 质量不应该是模型单点责任我做这套系统时给自己定了一个很朴素的原则模型负责“写得好不好”架构负责“写得对不对”。“对不对”指的是事实要素准确、引用准确、格式规范、逻辑前后一致。这些不应该是模型的义务而是整个系统通过约束机制强制的。换句话说架构师要做的不是找一个大到足够聪明的模型而是设计一套让“再普通的模型也犯不了大错”的防御体系。这个思路我在后续多个项目中反复验证过比单纯追新模型版本要稳定得多。2.2 分层防线四道关卡我把质量保障拆成四道关卡每道关卡只解决一类问题输入层从案件材料里稳定抽取结构化要素建好“事实底座”。生成层用模板加检索增强约束模型的输出空间把自由写作限制在“规范骨架”里。校验层用规则引擎和知识库把输出的关键字段、法条、格式全部扫一遍。复核层用置信度分级把低置信度内容送回给人类复核同时记录全链路日志。这个思路和软件工程里的防御式编程完全一致每一层都假设上一层会出错并做好兜底。这样即使某个环节出了问题最终到用户手里的文书也还是可控的。2.3 人机协同人工复核不是机械操作有一个必须想清楚的点司法文书的特殊性决定了人工复核不可能被完全替代。但人工复核不等于“让法官在AI生成的草稿上从头改一遍”。好的做法是让系统把低置信度的地方用高亮标出来把可疑的案号、引用、金额单独拉出来让复核人确认。人的精力是稀缺资源系统应该把人的注意力引导到最可能有错的地方。同样复核人的确认结果要回灌到系统中形成闭环优化。这一点在架构设计里容易被忽略——没有反馈闭环系统只是“看起来在用AI”实际上质量一直没有提升。3. 核心模块的具体实现每一层的工程细节这一部分我尽量按实际落地时踩过的坑来讲。每层具体怎么做有哪些参数、哪些取舍都会说明背后的原因。3.1 输入侧要素抽取与结构化文书生成的前提是“要素齐整”。我通常先让系统从起诉状、判决书原文、证据清单里抽取固定字段定义成一个JSON结构例如{ case_id: 2024某法院民初1234号, court_name: 某市中级人民法院, plaintiff: {name: 张三, type: 自然人, address: 某省某市某路1号}, defendant: {name: 某科技公司, type: 法人, address: 某省某市某园区}, claims: [判令被告支付货款人民币500万元, 判令被告承担本案诉讼费用], evidence: [{name: 采购合同, type: 书证, key_points: 双方约定付款期限}], legal_basis: [{statute_id: CL001234, name: 合同编相关条文}], hearing_date: 2024-06-18 }要素抽取有两种主流做法一种是传统的序列标注模型速度稳定但遇到长文本和多义表达时容易漏另一种是直接用大模型加结构化输出约束抽取。我更推荐后者因为输出协议能把结果限制成合法JSON准确率整体更高。抽取完成之后需要做一次“字段完整性校验”——必填字段缺失时直接返回人工补全而不是带着缺失数据往下走。这一步很关键宁可让流程慢一点也不能让文书在关键字段缺失的情况下生成。我在实际项目里遇到过一个典型问题被告是法人时统一社会信用代码经常缺失如果不卡住后续生成的文书就会出现“被告基本信息不完整”的低级错误复核阶段还要全部退回重来反而更慢。3.2 生成侧模板约束加检索增强司法文书的正文虽然看起来自由但它有很强的结构约定。比如判决书正文一般包括当事人信息、诉辩意见、经审理查明的事实、本院认为说理、判决主文、审判人员署名、日期等。这些部分是固定的骨架不该让模型自由发挥。我的做法是把文书模板做成“带变量的结构化模板”变量由要素抽取阶段的结果回填只有“本院认为”这种需要语义推理的段落才交给大模型生成。这样既保证了文书格式规范又保留了AI在说理上的能力。说理部分为了防止引用错误法条我把它做成检索增强流程把现行有效的法律条文、司法解释切段后放入向量库生成时先检索相关法条再把命中的法条原文拼进上下文同时要求模型只能引用检索结果中的法条并且输出时附上法条ID。后续校验阶段会拿着这个ID去法条库核对保证引用闭环。这里有一个容易忽略的坑如果检索时不过滤法条的时效性很容易把已经废止的条文也检索出来。所以向量库最好支持按生效日期、废止日期做条件过滤。比如生成一份2024年的判决书检索到的法条必须是2024年时仍然有效的版本。时间过滤看似小细节实际能拦下一大批“引用过时法条”的错误。3.3 校验侧规则引擎设计规则引擎是质量保障的核心。不要一听“规则引擎”就觉得技术含量低恰恰因为规则是确定的它才能对抗模型的不确定性。我把校验拆成多个独立的校验器每一个只做一件事然后串成管道。比较重要的校验器有这么几类案号校验正则匹配“20XX某法院民初XXXX号”等格式同时与库里已有案号比对防止编造。日期校验所有日期必须转成统一格式YYYY-MM-DD并检查逻辑顺序比如判决日期必须晚于立案日期。金额校验提取所有金额小写数字和中文大写数字做双向转换比对防止出现“500万元”和“伍佰圆”这种对不上的情况。法条校验根据法条ID查库确认该法条在生成时点有效且不在废止列表中。人称一致性校验同一当事人在全文中的称谓必须统一比如“原告”不能时而变成“申请人”免得读者一头雾水。规则引擎能做到什么程度我在一个模拟的法院智能文书项目里做过统计单纯靠规则引擎能够拦截掉大约70%的规范类和幻觉类错误。剩下的30%才需要靠更重的手段去兜底。所以规则引擎的性价比极高架构上优先做。3.4 输出侧置信度分级与人工复核输出侧最容易被忽略。很多系统生成完就结束了其实输出侧有两个关键功能。一是置信度标记。我通常让生成模块在关键字段旁额外输出一个confidence字段。怎么算简单方式是这样要素回填部分置信度几乎为1法条引用部分如果由检索命中置信度可以设为0.95自由生成的说理部分则由一个独立的“语义一致性检查模型”打分。最终根据置信度把文书分成三档高置信度直接出稿、中置信度进入快速复核、低置信度必须退回人工重新撰写。这个档位划分直接决定了人力投入的多少。二是一致性校验模型。我实际用的是双模型投票对低置信度的段落用两个不同架构的模型分别生成然后做相似度和要点对齐比对差异过大的段落自动标记为“存疑”。双模型虽然成本翻倍但只在低置信度段落上启用整体成本可控。注意自动修正和人工复核要分开。能确定是错的比如日期格式不一致可以自动修正不能确定的比如案号可疑必须交给人工确认。自动修正做得太激进会让系统替人做了不该做的决定这一点后面还会展开说。4. 实操落地从一个简单流程看完整链路理论知识讲完了我按实际项目落地的方式把整个流程串一遍方便你直接照搬。4.1 端到端流程流程大概是这样的材料上传用户上传起诉状PDF、证据扫描件系统先做OCR和文本抽取。要素抽取大模型将文本转成结构化JSON缺失字段直接标红。模板匹配根据案由合同纠纷、侵权、劳动争议等自动匹配文书模板。骨架回填把要素写入模板生成“骨架稿”。说理生成对“本院认为”部分先做法条检索再生成说理段。规则校验全字段扫描所有错误、存疑点统一汇总。自动修正对能确定的错误比如格式问题自动修正对不确定的比如案号可疑标记人工复核。人工复核复核人打开界面只看高亮标记的存疑点确认或修改后定稿。日志入库把每次生成用的要素、模板版本、模型版本、提示词版本、校验结果全部写入审计日志。关键在于第6、7步校验和修正要能区分“确定错误”和“疑似错误”并且分开处理。确定错误直接改疑似错误必须让人看不要自动改。这个原则我吃了好几次亏才总结出来。4.2 关键参数与工程细节几个工程细节值得单独说。第一固定随机种子。在配置中心里设置seed同一个模板加同一份要素生成结果必须可重复。如果两次生成内容完全不一样说明系统不稳定这个问题要在上线前暴露出来而不是上线后被投诉后才发现。第二结构化输出协议。无论用哪个模型底座生成侧都强制走结构化输出协议确保输出是合法JSON。这一步不要只靠提示词要配合输出约束能力不然模型一旦多输出一个逗号下游解析就会崩。第三模板版本化。文书模板不是一次性写好就完的法院规范会调整。我把模板做成版本化配置每次生成都记录使用的模板版本这样后续排查问题时能知道“这一版文书是用哪版模板生成的”。第四法条库版本化。法条的更新对系统的正确性影响极大。我把法条库的快照也做成版本化保证文书的生成时间点“看到”的法条版本是确定的、可追溯的。这样即使后来法条废改了也能还原当时的生成逻辑。第五幂等生成。对同一个案件多次生成如果只是求一个“最合理的稿子”可以保留第一次的结果。但如果要做“生成-校验-修正”闭环那每次修正后的重生成都必须基于修正前的结果避免模型在修正过程中引入新错误。5. 常见问题与排查技巧实录把我在项目里真实遇到、也最容易被新手忽略的几类问题梳理一下。5.1 模型总是编案号怎么办案号幻觉是司法文书生成里最典型的问题。我的处理方式是“案号不从生成器里来从数据库里来”案号要么来自上游案件管理系统要么由规则引擎根据规则生成绝不交给模型自由输出。如果模型输出的正文里出现了案号必须正则提取后与数据库比对比对不上的直接标记为存疑。这是在架构上就把它卡死而不是靠提示词“请别编造案号”。5.2 法条引用旧版本法条引用错版本的问题根源在于模型知识的时效性滞后。模型训练完之后知识的“截止时间”就固定了后续法条更新它不知道。我们的方案是强制检索增强生成说理段之前必须先从当前有效法条库检索并且把检索命中结果拼进上下文。同时在校验阶段用法条库元数据里的生效日期和废止日期做过滤。只要有一环不满足这整段说理就会被打回重写。5.3 输入太长导致关键信息丢失大模型上下文窗口再大处理几百页的案卷材料也扛不住。我遇到的实际问题是长文档被截断后当事人信息或证据信息会丢但生成的文书依然很流畅完全看不出缺失。这种“流畅的错”最难防。解决办法是“先摘要、后填充”先把原始材料按段落做摘要把摘要压缩成要素字段生成时只使用要素字段不直接灌原始材料。一句话把上下文从“原材料”变成“精炼后的结构化数据”信息密度高很多模型也不容易丢信息。5.4 生成结果不稳定、同一案件每次出来不一样先排查是不是随机参数没固定常见是temperature和seed没设置。其次是模板变量取值不规范比如上游传过来的日期格式一会是“2024年6月18日”一会是“2024/06/18”模型就会跟着乱。解决方法是上游数据入库前强制统一格式下游生成时只认一种格式。别小看这种数据规范问题它引起的“不稳定”占了相当大比例。5.5 校验器误报太多复核人烦了规则引擎如果设置得太严格会把合法文书也拦下来导致复核人大量处理无效告警整体效率反而下降。这个问题的核心是“校验器的精准率要优先于召回率”。我一般会给校验器分等级红色告警必须人工看黄色告警仅做提示。经过一段时间的反馈数据再逐步调整各类规则的比例。下面用一张表把上面的排查技巧汇总一下可以直接当速查表用常见问题核心原因排查与解决路径案号乱编模型自由生成案号来自系统或规则生成禁止自由输出法条引用旧版本模型知识时效性滞后强制检索增强法条库生效/废止日期过滤长文档丢信息上下文截断或压缩丢失先摘要后填充只用结构化要素生成结果不稳定参数未固定或数据格式不统一固定seed、统一输入格式校验误报过多规则过于严格、未分级分级告警、优先精准率6. 工具与模型选型的一些经验最后聊几句选型。文书生成方向底层模型我倾向于不追求“最强”而是追求“可控”。所谓可控指的是支持结构化输出约束能在生成阶段就限定JSON格式有良好的指令遵循能力能在几个示例的引导下不跑偏部署形态灵活能在私有化环境跑。司法数据不能出域是硬约束所以我对纯云服务天然排斥。检索增强部分我用的向量库要能支持过滤条件比如按法条生效日期过滤不然检索出来的法条可能是失效的。这一点很关键很多团队栽在“检索出了法条但没过滤版本”。模型评估上我建议自建一个“司法文书评测集”不要只靠通用基准测试。评测集里要有意识地加入“错误诱导”样本比如故意在材料里放一些相似案由、容易混淆的法律概念看模型会不会被带偏。选型时拿评测集跑一遍效果一目了然。我自己的经验是宁可选择“约束能力强但说理稍弱”的模型也不选“文章写得好但经常不听指令”的模型。因为在文书生成这个场景说理可以靠检索材料、引用权威文书来增强但“不听指令”导致的错误是架构难以兜底的。写到这里我再做一次偏个人视角的收尾做司法AI文书生成架构师一定不要沉浸在“模型能力论”里。模型是资源架构才是质量的上限。我一直用的方法是把质量控制拆成一道道可独立测试的闸门每一道闸门都要有明确的输入输出和通过标准。宁可前期多花时间在规则引擎、模板化、数据标准化这些“不性感”的工作上也不要在模型调优上孤注一掷。如果你也在做严肃文本生成类系统先把“正确”的边界画清楚再把“智能”放进去这个顺序千万不能反。最后分享一个小技巧上线初期每次生成后可以加一道“复核人评价”环节让复核人给每个存疑点打“命中/误报”标签这些数据攒下来就是优化规则引擎和模型提示词最宝贵的弹药。