简介一份围绕人工智能裁判文书生成模型展开的系统性技术文档适合法律信息化从业者、司法领域算法工程师以及对法律大模型应用感兴趣的研究者阅读。内容从构建必要性切入梳理自然语言处理、机器学习、知识图谱与语义理解等关键技术基础并覆盖数据收集与预处理、特征工程、模型训练与优化等完整流程。文档还结合具体案例分析模型应用效果给出算法优化、系统性能与用户体验层面的改进策略并针对数据质量、模型泛化能力等现实挑战进行总结与展望。资源为1个docx文档压缩包大小69KB已有155人学习。文档目录结构完整章节层次清晰既有理论框架也有应用案例便于读者快速建立从技术原理到工程落地的整体认知可作为相关课题研究、方案设计或课程参考的实用资料。1. 裁判文书生成的第一性约束结构先于语义一个盗窃案的起诉意见和查明事实都齐了生成模型跑出来的“本院认为”却把罪名定性成诈骗。这不是模型不会写而是它没有把结构约束当成第一目标。裁判文书生成模型与普通文本生成最大的区别就在这里不是生成得流畅而是生成得不越位。它要同时满足案件事实到法律要件的推断链、法条引用的可验证性、说理段落的顺序不可颠倒这三件事。这篇文章按“数据构建 → 模型训练 → 生成优化 → 评估上线”的顺序梳理一套不依赖封闭平台的裁判文书生成模型构建与优化路径。适合正在做法治信息化、法律科技或合规 AI 系统的 NLP 工程师也适合想把领域生成任务从 demo 推到可验收状态的算法工程师。2. 裁判文书语料的清洗、要素抽取与监督微调样本构建2.1 原始文书解析与文本清洗公开渠道或者内部系统导出的裁判文书最常见的问题不是缺少内容而是格式噪声太多。Word 导出的文本里频繁出现全角空格和不间断空格网页来源的文书夹杂 HTML 残留部分扫描件转文字后还会把“本院认为”拆成“本院 认为”。第一步的清洗如果做得太激进会把后续要素定位要依赖的句读和段落边界一并破坏。import re def clean_document(raw: str) - str: text raw.replace(\u3000, ) # 全角空格 text text.replace(\xa0, ) # 不间断空格 text re.sub(r[^], , text) # 去 HTML 标签 text re.sub(r[ \t], , text) # 压缩连续空格与制表符 # 把连续两个及以上的换行压成一个保留段落边界 text re.sub(r(\r?\n)\s*\1, r\1, text) return text.strip()一个容易被忽视的点是顺序必须先去 HTML 标签再压缩空白否则p内容/p里残留的换行会被当成正文结构保留下来。这套清洗只处理空白字符不转换标点半角全角。原因是后续的关键词定位依赖“本院认为”“判决如下”这些字符串的原始形态全角转半角一旦把中文标点转坏关键词匹配会大面积失效。清洗之后还要做一次段落层的裁剪。裁判文书正文一般以当事人信息开头、以“审 判 长”“书记员”等落款结尾这部分内容不进入要素抽取和模型训练。裁剪规则就是先定位“公诉机关”或“原告”作为正文起点再以“书记员”作为终点中间部分才送到下一环节。2.2 要素抽取把自然语言段落变成结构化字段裁判文书虽然各家法院措辞不完全一致但骨架非常固定“公诉机关指控”“经审理查明”“本院认为”“判决如下”。这些关键词本身就能当段落边界用。用关键词定位再切段比训练一个序列标注模型去做段落分割更可靠、更容易排查错误覆盖率在日常语料上通常能到八成以上。要素字段定位关键词抽取后的用途指控与请求诉称 / 指控生成模型的案情输入查明事实经审理查明与指控事实做对比信号本院认为本院认为监督微调的主要生成目标判决主文判决如下输出完整性校验字段def extract_sections(text: str) - dict: order [ (claims, 诉称), (facts, 经审理查明), (reasoning, 本院认为), (holding, 判决如下), ] positions [] for key, marker in order: pos text.find(marker) if pos 0: positions.append((pos, key)) positions.sort() sections {} for i, (pos, key) in enumerate(positions): end_pos positions[i 1][0] if i 1 len(positions) else len(text) sections[key] text[pos:end_pos].strip() return sections这段代码取的是每个关键词首次出现的位置按位置排序后逐个截段。用首次出现而不是最后一次是因为“判决如下”出现后主文里偶尔会重复“本院认为”的引述第一次出现才是结构起点。匹配不到“本院认为”的文书直接进人工队列不要强行塞进训练集。数据噪声比数据量更致命这一阶段的目标是把原始语料整理成干净、可追踪的领域知识库后续检索增强和对抗样本构造都从这份知识库里取数据。2.3 构造指令微调样本的模板策略监督微调样本的设计决定了模型的能力上限。把整篇文书丢给模型让它背诵是错误做法模型会学会输出模式但学不会“事实决定定性定性决定量刑”的因果链。合理的样本构造方式是输入只放案情侧的描述输出只放裁判说理侧的文本。{ template: 根据起诉指控与查明事实生成裁判文书中的“本院认为”部分。, input: { crime: 盗窃罪, claims: 被告人张某于某日凌晨进入被害人住宅窃取手机一部价值人民币6800元。, facts: 经审理查明张某以撬锁方式进入被害人住所窃取财物后逃离次日被抓获。 }, response: 本院认为被告人张某以非法占有为目的入户窃取他人财物数额较大其行为已构成盗窃罪。公诉机关指控罪名成立。鉴于其到案后如实供述罪行依法从轻处罚。, meta: { case_type: 刑事, court_level: 基层 } }response 就是监督信号只包含应当生成的“本院认为”和量刑理由不包含判决主文。判决主文涉及刑期确定格式和逻辑跟说理段落差异很大混在一起训练会让模型在段落衔接处频繁出错。meta 字段用来记录案件类型和法院层级训练时按案由分流评估时也能据此按细分领域统计错误率。几百条高质量手写模板能确定输出格式真正提升说理质量靠的是一两万条经过 2.2 抽取整理的段落对这个数量级已经足够让 LoRA 适配收敛。3. 面向文书生成的基座选型与模型训练3.1 基座模型选择的关键维度“法律大模型”这个标签本身不构成选型依据。一个流利的通用中文底座跟一个在法律 QA 数据上做过增量预训练的底座在续写裁判文书时表现可能不相上下因为裁判文书生成考的不是法条记忆而是对“指控—查明—说理—判决”这个固定逻辑链的遵循能力。选型先看四个维度词表对法律专名的切分能力、上下文长度、开源许可、参数量。选型维度检查方法经验结论中文词表质量观察“犯罪嫌疑人”能否被连续切分中英混合词表的底座通常更好最大上下文统计“查明事实”段落的长度分布4K 起步建议 8K开源许可查看权重衍生品的商用条款商用前必须确认参数量对应显存和推理时延7B 到 13B 性价比最合适选型阶段不要看榜单分数直接做一个探测实验拿十篇真实文书的“查明事实”段落喂给底座要求续写“本院认为”。如果底座在两句之后就跳出说理腔调开始复述案情说明对文书结构的适配能力弱领域微调成本会很高。如果输出里频繁出现生造词说明词表和法言法语的匹配度不够这个底座可以直接放弃。3.2 监督微调的训练脚本与参数训练方式选择 LoRA 而不是全参微调。裁判文书是强格式任务领域知识集中在段落结构、要件逻辑和固定表达上不需要模型改变通用语言能力。LoRA 在低数据量下收敛更快训练产物是几十 MB 的 adapter 文件叠加在量化基座上就能部署。超参数推荐值说明learning_rate1e-4 到 3e-4超过 5e-4 会破坏底座原有的指令遵循能力lora_rank16 或 32训练样本少于 1 万条选 16数据量更大再升 32 或 64num_epochs2 到 4超过 5 轮模型开始背模板段落多样性明显下降per_device_batch1长文书显存占用高用梯度累积补全局 batchgradient_accumulation16 或 32与单卡 batch 相乘约等于 16 或 32 的全局 batchmax_length4096 或 8192由“指控事实 查明事实 说理”拼起来的总长度决定from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments model AutoModelForCausalLM.from_pretrained(base_model_path, trust_remote_codeTrue) tokenizer AutoTokenizer.from_pretrained(base_model_path) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, v_proj], lora_dropout0.05, ) model get_peft_model(model, lora_config) training_args TrainingArguments( output_dir./judgment_model, per_device_train_batch_size1, gradient_accumulation_steps16, learning_rate2e-4, num_train_epochs3, logging_steps10, save_strategysteps, save_steps200, fp16True, ) trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_dataset, # 已按模板处理好 input_ids 与 labels ) trainer.train()两个参数需要特别解释。target_modules 中的q_proj、v_proj是多数开源底座注意力模块里的实际命名如果基座结构不同要用model.named_modules()先确认投影层名称直接照抄会把 LoRA 挂到不存在的模块上训练报错前很难察觉。gradient_accumulation_steps 配合 batch_size 是本场景的显存解法长文本单条样本可能占用十几 GB 显存多卡数据并行放不下梯度累积可以在单卡甚至单条样本下维持有意义的全局 batch代价只是训练时间变长。监督微调阶段还必须处理标签掩码问题。只让模型对 response 部分计算损失instruction 和 input 部分要用-100掩掉否则模型会在推理时把输入重新复述一遍来降低 loss。常见做法是在 tokenize 时把 input 段的 label 全部置为 -100保留 response 段的真实 token id。这一步做错训练 loss 会很好看但生成的文书开满“复读机式”的案情重述。3.3 LoRA 与全参微调的决策线LoRA 不是所有场景的正确答案。训练样本不足五万条时LoRA 的收敛速度和改写幅度都更合适当领域语料到了几十万条量级且任务要求“从基础格式到深层论证风格”全面对齐全参微调的上限更高。判断是否需要切换的实用信号是 LoRA 是否在验证集上出现“段落结构对了但说理层次错乱”的现象比如把量刑情节写进定罪段落。这说明低秩适配已经耗尽加 rank 或加数据都解决不了需要换全参微调。全参微调的显存压力远大于 LoRA长文本条件下 13B 模型通常需要张量并行或序列并行。工程上更常见的折中方案是冻结大部分底层 Transformer 层只微调靠近输出层的高层参数这种做法介于 LoRA 和全参之间适合训练数据在十万条上下、又不需要保留太多通用能力的场景。无论选哪条路都要在训练前把 transformers、peft、accelerate 的版本固定下来。构建本地依赖时这几个库的大版本之间 adapter 保存格式不完全兼容训练完加载不了权重是领域微调项目最常见的返工原因。4. 生成阶段的确定性控制与质量优化4.1 解码参数对文书可读性与重复问题的抑制训练完成后生成阶段的参数优化是成本最低、见效最快的一步。裁判文书是一种“低随机性”文本过高的采样随机性会让模型在“本院认为”之后开始发散过低的随机性则会让每篇文书的说理结构趋同。参数调优的起点不是看单个指标而是找“重复”和“呆板”之间的平衡点。参数推荐区间作用temperature0.7 到 0.9低于 0.7 说理句式单调top_p0.85 到 0.95配合 temperature 控制候选词集合repetition_penalty1.05 到 1.15抑制“依法”“酌情”等高词频局部循环max_new_tokens700 到 1000视“本院认为”历史长度调整num_beams1长文书 beam search 速度慢且收益低from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained(./judgment_model) tokenizer AutoTokenizer.from_pretrained(./judgment_model) inputs tokenizer(案件输入文本, return_tensorspt, max_length4096, truncationTrue) output model.generate( **inputs, temperature0.8, top_p0.9, repetition_penalty1.1, max_new_tokens800, ) print(tokenizer.decode(output[0][inputs.input_ids.shape[1]:], skip_special_tokensTrue))repetition_penalty 是这几个参数里对文书影响最大的一个。法律长句中“依法”“酌情”“予以支持”出现频率极高模型在长距离生成时容易陷入这三四个词的局部循环惩罚因子会对重复出现的 n-gram 做逐步降权把循环打断。注意 penalty 不要超过 1.2超过之后模型会开始回避正常重复的法律术语出现“被 告人”中间加空格之类的断裂表达。4.2 结构化约束解码把“一段生成”拆成“逐段生成”裁判文书生成最典型的失控场景是结构跳变还在“本院认为”的说理过程中突然抛出“判决如下”。这本质上不是解码参数问题而是把过长序列的生成目标压给了一次采样。常见做法是把单一生成任务拆成“案情摘要 → 本院认为 → 判决主文”三个独立生成步骤每一步的输入输出边界清晰模型不需要自己决定在哪里收尾。def generate_reasoning(model, tokenizer, claims, facts): prompt ( f根据以下起诉与查明事实只生成裁判文书的“本院认为”部分。\n f指控{claims}\n f查明{facts}\n ) inputs tokenizer(prompt, return_tensorspt, truncationTrue, max_length4096) output model.generate( **inputs, temperature0.8, top_p0.9, repetition_penalty1.1, max_new_tokens800, ) reasoning tokenizer.decode(output[0][inputs.input_ids.shape[1]:], skip_special_tokensTrue) if 判决如下 in reasoning: reasoning reasoning.split(判决如下)[0] return reasoning.strip()拆段之后仍然可能跨段原因在于训练语料里“本院认为”段落和“判决如下”段落是紧挨着的模型学到了相邻关系。代码里的split(判决如下)是最后的兜底拦截只保留说理段。这种“要素级分段生成 边界截断”的做法在真实数据上能把结构错乱率从两位数降到个位数。判决主文的生成要单独处理。主文的本质是结构化决策结果“一、被告人张某犯盗窃罪判处有期徒刑六个月并处罚金人民币一千元”。它适合用规则模板或者受限生成来实现模板填充的量刑数值来自案情要素抽取而不是让模型自由发挥。把主文交给生成模型得到的是流畅的错误不是可用的判决结果。4.3 法条幻觉抑制法条白名单与检索增强生成模型在说理中编造“《中华人民共和国刑法》第九百九十九条”这类不存在的条文是这个场景最不能接受的一类错误。法条必须可验证这是裁判文书与普通文本生成在质量要求上的本质差异。抑制法条幻觉不能靠模型自身“记住”需要引入外部约束。import re def validate_statutes(text: str, statute_db: set) - list: refs re.findall(r《[^》]》第[一二三四五六七八九十百千0-9]条, text) invalid [ref for ref in refs if ref not in statute_db] return invalid黑名单只能防“不存在的法条”防不了“用错的法条”。把“用错”的概率也压下去靠的是检索增强按案由和罪名召回相关法条把法条原文注入 prompt 的参考字段让模型在有限的法条集合里选择。这套做法把法条正确性从模型记忆问题转变成检索问题检索出的法条不对可以单独排查知识库不污染生成模型本身。实现上知识库构建就是 2.2 抽取结果按案由建立索引后的检索服务query 用“罪名 关键量刑情节”拼出来召回 top 5 法条文本拼接方式放在 prompt 的“参考法条”位置。5. 要素可控性测试与事实一致性抽检的上线检查5.1 结构校验和要素命中率怎么跑上线前要建立一套不依赖人工逐篇阅读的自动检查管线。第一层是结构完整性检查验证输出是否包含“本院认为”和“判决如下”第二层是要素命中率从参考文书中抽出金额、刑期、罪名等关键词集合检查模型输出对这个集合的覆盖比例。这两个检查都能用确定性代码跑完适合放进 CI 流程。def check_outline(text: str) - dict: required [本院认为, 判决如下] return {kw: (kw in text) for kw in required} def element_hit_rate(prediction: str, keywords: list) - float: hit sum(1 for kw in keywords if kw in prediction) return hit / len(keywords)要素命中率要按案由分开统计。盗窃案看金额和刑期交通肇事案看责任认定和赔偿数额混合统计会把问题稀释掉。每类案件抽两百篇作为评估集命中率低于 0.85 的案由要回到数据构建阶段补充对应样本这个回流路径比盲目调解码参数有效得多。5.2 抽检中容易漏掉的三类错误自动指标只能发现“缺了什么”“多了什么”必须靠人工抽检。准备一批专门修改过金额、日期、当事人身份的对抗样本检查模型是否跟随着修改输出。要特别留意一个现象模型倾向沿用训练分布中高频出现的量刑区间对抗样本把盗窃金额从低档改成高档模型可能仍然输出原来区间的刑期这是要素失控而不是表述问题。人工抽检还要覆盖模型输出的偏见信号。训练语料本身携带社会偏见生成模型会把高频案件模式放大成刻板判断比如对特定职业人群使用模式化的主观评价。这类问题不对应自动指标需要在抽检清单里单独列出复核项。最后是两个工程细节。长文本生成时截断位置不能按字符数硬切要优先保留“判决如下”之后的主文内容说理部分可以压缩到生成预算之外再处理。“本院认为”段落结尾缺少收束语是微调样本量不足的典型症状补少量以“综上”开头的收尾模板比整体加大训练数据更省成本。用户修改过的生成结果要回流到训练集回流时把整段响应按 2.3 的模板重新打包直接并入下一轮增量训练。本文还有配套的精品资源点击获取 裁判文书生成模型构建与优化：从数据清洗到LoRA微调
简介一份围绕人工智能裁判文书生成模型展开的系统性技术文档适合法律信息化从业者、司法领域算法工程师以及对法律大模型应用感兴趣的研究者阅读。内容从构建必要性切入梳理自然语言处理、机器学习、知识图谱与语义理解等关键技术基础并覆盖数据收集与预处理、特征工程、模型训练与优化等完整流程。文档还结合具体案例分析模型应用效果给出算法优化、系统性能与用户体验层面的改进策略并针对数据质量、模型泛化能力等现实挑战进行总结与展望。资源为1个docx文档压缩包大小69KB已有155人学习。文档目录结构完整章节层次清晰既有理论框架也有应用案例便于读者快速建立从技术原理到工程落地的整体认知可作为相关课题研究、方案设计或课程参考的实用资料。1. 裁判文书生成的第一性约束结构先于语义一个盗窃案的起诉意见和查明事实都齐了生成模型跑出来的“本院认为”却把罪名定性成诈骗。这不是模型不会写而是它没有把结构约束当成第一目标。裁判文书生成模型与普通文本生成最大的区别就在这里不是生成得流畅而是生成得不越位。它要同时满足案件事实到法律要件的推断链、法条引用的可验证性、说理段落的顺序不可颠倒这三件事。这篇文章按“数据构建 → 模型训练 → 生成优化 → 评估上线”的顺序梳理一套不依赖封闭平台的裁判文书生成模型构建与优化路径。适合正在做法治信息化、法律科技或合规 AI 系统的 NLP 工程师也适合想把领域生成任务从 demo 推到可验收状态的算法工程师。2. 裁判文书语料的清洗、要素抽取与监督微调样本构建2.1 原始文书解析与文本清洗公开渠道或者内部系统导出的裁判文书最常见的问题不是缺少内容而是格式噪声太多。Word 导出的文本里频繁出现全角空格和不间断空格网页来源的文书夹杂 HTML 残留部分扫描件转文字后还会把“本院认为”拆成“本院 认为”。第一步的清洗如果做得太激进会把后续要素定位要依赖的句读和段落边界一并破坏。import re def clean_document(raw: str) - str: text raw.replace(\u3000, ) # 全角空格 text text.replace(\xa0, ) # 不间断空格 text re.sub(r[^], , text) # 去 HTML 标签 text re.sub(r[ \t], , text) # 压缩连续空格与制表符 # 把连续两个及以上的换行压成一个保留段落边界 text re.sub(r(\r?\n)\s*\1, r\1, text) return text.strip()一个容易被忽视的点是顺序必须先去 HTML 标签再压缩空白否则p内容/p里残留的换行会被当成正文结构保留下来。这套清洗只处理空白字符不转换标点半角全角。原因是后续的关键词定位依赖“本院认为”“判决如下”这些字符串的原始形态全角转半角一旦把中文标点转坏关键词匹配会大面积失效。清洗之后还要做一次段落层的裁剪。裁判文书正文一般以当事人信息开头、以“审 判 长”“书记员”等落款结尾这部分内容不进入要素抽取和模型训练。裁剪规则就是先定位“公诉机关”或“原告”作为正文起点再以“书记员”作为终点中间部分才送到下一环节。2.2 要素抽取把自然语言段落变成结构化字段裁判文书虽然各家法院措辞不完全一致但骨架非常固定“公诉机关指控”“经审理查明”“本院认为”“判决如下”。这些关键词本身就能当段落边界用。用关键词定位再切段比训练一个序列标注模型去做段落分割更可靠、更容易排查错误覆盖率在日常语料上通常能到八成以上。要素字段定位关键词抽取后的用途指控与请求诉称 / 指控生成模型的案情输入查明事实经审理查明与指控事实做对比信号本院认为本院认为监督微调的主要生成目标判决主文判决如下输出完整性校验字段def extract_sections(text: str) - dict: order [ (claims, 诉称), (facts, 经审理查明), (reasoning, 本院认为), (holding, 判决如下), ] positions [] for key, marker in order: pos text.find(marker) if pos 0: positions.append((pos, key)) positions.sort() sections {} for i, (pos, key) in enumerate(positions): end_pos positions[i 1][0] if i 1 len(positions) else len(text) sections[key] text[pos:end_pos].strip() return sections这段代码取的是每个关键词首次出现的位置按位置排序后逐个截段。用首次出现而不是最后一次是因为“判决如下”出现后主文里偶尔会重复“本院认为”的引述第一次出现才是结构起点。匹配不到“本院认为”的文书直接进人工队列不要强行塞进训练集。数据噪声比数据量更致命这一阶段的目标是把原始语料整理成干净、可追踪的领域知识库后续检索增强和对抗样本构造都从这份知识库里取数据。2.3 构造指令微调样本的模板策略监督微调样本的设计决定了模型的能力上限。把整篇文书丢给模型让它背诵是错误做法模型会学会输出模式但学不会“事实决定定性定性决定量刑”的因果链。合理的样本构造方式是输入只放案情侧的描述输出只放裁判说理侧的文本。{ template: 根据起诉指控与查明事实生成裁判文书中的“本院认为”部分。, input: { crime: 盗窃罪, claims: 被告人张某于某日凌晨进入被害人住宅窃取手机一部价值人民币6800元。, facts: 经审理查明张某以撬锁方式进入被害人住所窃取财物后逃离次日被抓获。 }, response: 本院认为被告人张某以非法占有为目的入户窃取他人财物数额较大其行为已构成盗窃罪。公诉机关指控罪名成立。鉴于其到案后如实供述罪行依法从轻处罚。, meta: { case_type: 刑事, court_level: 基层 } }response 就是监督信号只包含应当生成的“本院认为”和量刑理由不包含判决主文。判决主文涉及刑期确定格式和逻辑跟说理段落差异很大混在一起训练会让模型在段落衔接处频繁出错。meta 字段用来记录案件类型和法院层级训练时按案由分流评估时也能据此按细分领域统计错误率。几百条高质量手写模板能确定输出格式真正提升说理质量靠的是一两万条经过 2.2 抽取整理的段落对这个数量级已经足够让 LoRA 适配收敛。3. 面向文书生成的基座选型与模型训练3.1 基座模型选择的关键维度“法律大模型”这个标签本身不构成选型依据。一个流利的通用中文底座跟一个在法律 QA 数据上做过增量预训练的底座在续写裁判文书时表现可能不相上下因为裁判文书生成考的不是法条记忆而是对“指控—查明—说理—判决”这个固定逻辑链的遵循能力。选型先看四个维度词表对法律专名的切分能力、上下文长度、开源许可、参数量。选型维度检查方法经验结论中文词表质量观察“犯罪嫌疑人”能否被连续切分中英混合词表的底座通常更好最大上下文统计“查明事实”段落的长度分布4K 起步建议 8K开源许可查看权重衍生品的商用条款商用前必须确认参数量对应显存和推理时延7B 到 13B 性价比最合适选型阶段不要看榜单分数直接做一个探测实验拿十篇真实文书的“查明事实”段落喂给底座要求续写“本院认为”。如果底座在两句之后就跳出说理腔调开始复述案情说明对文书结构的适配能力弱领域微调成本会很高。如果输出里频繁出现生造词说明词表和法言法语的匹配度不够这个底座可以直接放弃。3.2 监督微调的训练脚本与参数训练方式选择 LoRA 而不是全参微调。裁判文书是强格式任务领域知识集中在段落结构、要件逻辑和固定表达上不需要模型改变通用语言能力。LoRA 在低数据量下收敛更快训练产物是几十 MB 的 adapter 文件叠加在量化基座上就能部署。超参数推荐值说明learning_rate1e-4 到 3e-4超过 5e-4 会破坏底座原有的指令遵循能力lora_rank16 或 32训练样本少于 1 万条选 16数据量更大再升 32 或 64num_epochs2 到 4超过 5 轮模型开始背模板段落多样性明显下降per_device_batch1长文书显存占用高用梯度累积补全局 batchgradient_accumulation16 或 32与单卡 batch 相乘约等于 16 或 32 的全局 batchmax_length4096 或 8192由“指控事实 查明事实 说理”拼起来的总长度决定from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments model AutoModelForCausalLM.from_pretrained(base_model_path, trust_remote_codeTrue) tokenizer AutoTokenizer.from_pretrained(base_model_path) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, v_proj], lora_dropout0.05, ) model get_peft_model(model, lora_config) training_args TrainingArguments( output_dir./judgment_model, per_device_train_batch_size1, gradient_accumulation_steps16, learning_rate2e-4, num_train_epochs3, logging_steps10, save_strategysteps, save_steps200, fp16True, ) trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_dataset, # 已按模板处理好 input_ids 与 labels ) trainer.train()两个参数需要特别解释。target_modules 中的q_proj、v_proj是多数开源底座注意力模块里的实际命名如果基座结构不同要用model.named_modules()先确认投影层名称直接照抄会把 LoRA 挂到不存在的模块上训练报错前很难察觉。gradient_accumulation_steps 配合 batch_size 是本场景的显存解法长文本单条样本可能占用十几 GB 显存多卡数据并行放不下梯度累积可以在单卡甚至单条样本下维持有意义的全局 batch代价只是训练时间变长。监督微调阶段还必须处理标签掩码问题。只让模型对 response 部分计算损失instruction 和 input 部分要用-100掩掉否则模型会在推理时把输入重新复述一遍来降低 loss。常见做法是在 tokenize 时把 input 段的 label 全部置为 -100保留 response 段的真实 token id。这一步做错训练 loss 会很好看但生成的文书开满“复读机式”的案情重述。3.3 LoRA 与全参微调的决策线LoRA 不是所有场景的正确答案。训练样本不足五万条时LoRA 的收敛速度和改写幅度都更合适当领域语料到了几十万条量级且任务要求“从基础格式到深层论证风格”全面对齐全参微调的上限更高。判断是否需要切换的实用信号是 LoRA 是否在验证集上出现“段落结构对了但说理层次错乱”的现象比如把量刑情节写进定罪段落。这说明低秩适配已经耗尽加 rank 或加数据都解决不了需要换全参微调。全参微调的显存压力远大于 LoRA长文本条件下 13B 模型通常需要张量并行或序列并行。工程上更常见的折中方案是冻结大部分底层 Transformer 层只微调靠近输出层的高层参数这种做法介于 LoRA 和全参之间适合训练数据在十万条上下、又不需要保留太多通用能力的场景。无论选哪条路都要在训练前把 transformers、peft、accelerate 的版本固定下来。构建本地依赖时这几个库的大版本之间 adapter 保存格式不完全兼容训练完加载不了权重是领域微调项目最常见的返工原因。4. 生成阶段的确定性控制与质量优化4.1 解码参数对文书可读性与重复问题的抑制训练完成后生成阶段的参数优化是成本最低、见效最快的一步。裁判文书是一种“低随机性”文本过高的采样随机性会让模型在“本院认为”之后开始发散过低的随机性则会让每篇文书的说理结构趋同。参数调优的起点不是看单个指标而是找“重复”和“呆板”之间的平衡点。参数推荐区间作用temperature0.7 到 0.9低于 0.7 说理句式单调top_p0.85 到 0.95配合 temperature 控制候选词集合repetition_penalty1.05 到 1.15抑制“依法”“酌情”等高词频局部循环max_new_tokens700 到 1000视“本院认为”历史长度调整num_beams1长文书 beam search 速度慢且收益低from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained(./judgment_model) tokenizer AutoTokenizer.from_pretrained(./judgment_model) inputs tokenizer(案件输入文本, return_tensorspt, max_length4096, truncationTrue) output model.generate( **inputs, temperature0.8, top_p0.9, repetition_penalty1.1, max_new_tokens800, ) print(tokenizer.decode(output[0][inputs.input_ids.shape[1]:], skip_special_tokensTrue))repetition_penalty 是这几个参数里对文书影响最大的一个。法律长句中“依法”“酌情”“予以支持”出现频率极高模型在长距离生成时容易陷入这三四个词的局部循环惩罚因子会对重复出现的 n-gram 做逐步降权把循环打断。注意 penalty 不要超过 1.2超过之后模型会开始回避正常重复的法律术语出现“被 告人”中间加空格之类的断裂表达。4.2 结构化约束解码把“一段生成”拆成“逐段生成”裁判文书生成最典型的失控场景是结构跳变还在“本院认为”的说理过程中突然抛出“判决如下”。这本质上不是解码参数问题而是把过长序列的生成目标压给了一次采样。常见做法是把单一生成任务拆成“案情摘要 → 本院认为 → 判决主文”三个独立生成步骤每一步的输入输出边界清晰模型不需要自己决定在哪里收尾。def generate_reasoning(model, tokenizer, claims, facts): prompt ( f根据以下起诉与查明事实只生成裁判文书的“本院认为”部分。\n f指控{claims}\n f查明{facts}\n ) inputs tokenizer(prompt, return_tensorspt, truncationTrue, max_length4096) output model.generate( **inputs, temperature0.8, top_p0.9, repetition_penalty1.1, max_new_tokens800, ) reasoning tokenizer.decode(output[0][inputs.input_ids.shape[1]:], skip_special_tokensTrue) if 判决如下 in reasoning: reasoning reasoning.split(判决如下)[0] return reasoning.strip()拆段之后仍然可能跨段原因在于训练语料里“本院认为”段落和“判决如下”段落是紧挨着的模型学到了相邻关系。代码里的split(判决如下)是最后的兜底拦截只保留说理段。这种“要素级分段生成 边界截断”的做法在真实数据上能把结构错乱率从两位数降到个位数。判决主文的生成要单独处理。主文的本质是结构化决策结果“一、被告人张某犯盗窃罪判处有期徒刑六个月并处罚金人民币一千元”。它适合用规则模板或者受限生成来实现模板填充的量刑数值来自案情要素抽取而不是让模型自由发挥。把主文交给生成模型得到的是流畅的错误不是可用的判决结果。4.3 法条幻觉抑制法条白名单与检索增强生成模型在说理中编造“《中华人民共和国刑法》第九百九十九条”这类不存在的条文是这个场景最不能接受的一类错误。法条必须可验证这是裁判文书与普通文本生成在质量要求上的本质差异。抑制法条幻觉不能靠模型自身“记住”需要引入外部约束。import re def validate_statutes(text: str, statute_db: set) - list: refs re.findall(r《[^》]》第[一二三四五六七八九十百千0-9]条, text) invalid [ref for ref in refs if ref not in statute_db] return invalid黑名单只能防“不存在的法条”防不了“用错的法条”。把“用错”的概率也压下去靠的是检索增强按案由和罪名召回相关法条把法条原文注入 prompt 的参考字段让模型在有限的法条集合里选择。这套做法把法条正确性从模型记忆问题转变成检索问题检索出的法条不对可以单独排查知识库不污染生成模型本身。实现上知识库构建就是 2.2 抽取结果按案由建立索引后的检索服务query 用“罪名 关键量刑情节”拼出来召回 top 5 法条文本拼接方式放在 prompt 的“参考法条”位置。5. 要素可控性测试与事实一致性抽检的上线检查5.1 结构校验和要素命中率怎么跑上线前要建立一套不依赖人工逐篇阅读的自动检查管线。第一层是结构完整性检查验证输出是否包含“本院认为”和“判决如下”第二层是要素命中率从参考文书中抽出金额、刑期、罪名等关键词集合检查模型输出对这个集合的覆盖比例。这两个检查都能用确定性代码跑完适合放进 CI 流程。def check_outline(text: str) - dict: required [本院认为, 判决如下] return {kw: (kw in text) for kw in required} def element_hit_rate(prediction: str, keywords: list) - float: hit sum(1 for kw in keywords if kw in prediction) return hit / len(keywords)要素命中率要按案由分开统计。盗窃案看金额和刑期交通肇事案看责任认定和赔偿数额混合统计会把问题稀释掉。每类案件抽两百篇作为评估集命中率低于 0.85 的案由要回到数据构建阶段补充对应样本这个回流路径比盲目调解码参数有效得多。5.2 抽检中容易漏掉的三类错误自动指标只能发现“缺了什么”“多了什么”必须靠人工抽检。准备一批专门修改过金额、日期、当事人身份的对抗样本检查模型是否跟随着修改输出。要特别留意一个现象模型倾向沿用训练分布中高频出现的量刑区间对抗样本把盗窃金额从低档改成高档模型可能仍然输出原来区间的刑期这是要素失控而不是表述问题。人工抽检还要覆盖模型输出的偏见信号。训练语料本身携带社会偏见生成模型会把高频案件模式放大成刻板判断比如对特定职业人群使用模式化的主观评价。这类问题不对应自动指标需要在抽检清单里单独列出复核项。最后是两个工程细节。长文本生成时截断位置不能按字符数硬切要优先保留“判决如下”之后的主文内容说理部分可以压缩到生成预算之外再处理。“本院认为”段落结尾缺少收束语是微调样本量不足的典型症状补少量以“综上”开头的收尾模板比整体加大训练数据更省成本。用户修改过的生成结果要回流到训练集回流时把整段响应按 2.3 的模板重新打包直接并入下一轮增量训练。本文还有配套的精品资源点击获取