一台 A100，用 QLoRA 微调 Llama-3-8B，4 小时跑完。模型进入测试环境后，却无法区分“客户经理”和“理财经理”，排查又花了三天。这份微调实战记录给法律 AI 项目提了个醒：训练任务结束，只能说明工程链路能跑，术语边界有没有学对，还得看数据和测试集。
法律文书里的称谓、主体、金额和例外条件都可能改变审核结论。数据中没有保留这些关系，模型参数再多也很难补救。项目启动时，应该先明确审核任务：识别风险条款、检查缺失项、匹配法律依据，还是给出修改建议。任务口径含糊，后面的微调和评估都会跟着摇摆。
先把 PDF 变成可审核的数据
文本型 PDF 可以优先用 PyMuPDF 或 LangChain Document Loaders 解析；扫描件再交给 OCR，并抽样检查识别结果。不要只留一整段纯文本。条款编号、页码、主体、金额、附件关系和表格层级都值得保留。
上交所披露的一份审核问询函回复中，同一部分材料包含“不超过 100,000.00 万元”的募集资金、“灵擎”“灵助”“灵智”三个项目，以及 77.5%、77.0% 和 75.77% 三组资本化支出比例。解析时一旦丢掉项目名称或段落层级，金额、比例就可能匹配到错误对象。
训练样本可以围绕这些字段组织：
document_id：文书标识；clause_no：条款编号；party：合同主体；amount：金额及币种；clause_content：待审核原文；risk_label：律师确认的风险标签；legal_basis：对应的法律名称和条款；review_comment：判断理由及修改意见。
脱敏应在数据进入训练集之前完成。自然人姓名、身份证号、银行卡号等信息，可以用正则表达式配合 Stanford NER 等命名实体识别工具处理。替换符要保持一致，例如同一个人在全文中始终写成 PERSON_01，否则模型会失去主体之间的指代关系。《个人信息保护法》涉及的具体处理边界，仍需由法务结合数据用途确认。
模板合同的重复内容很多。可以先用 SimHash 找出相似度超过 90% 的文本，但不要直接全部删除。标准条款本来就可能高度相似，真正需要剔除的是重复标注和无信息增量的样本。训练集与测试集也应按合同来源或模板族拆分，避免同一模板同时出现在两边，造成评估结果虚高。
模型型号先核对，硬件结论别外推
模型选型表里经常直接写上 Llama 4-70B 或 Qwen2.5-110B。具体型号、许可、上下文长度和硬件需求，必须以官方模型卡和实际测试为准。现有可引用素材只提供了 Llama-3-8B 在一台 A100 上进行 QLoRA 微调、4 小时完成的记录，不能据此外推 70B 或 110B 模型在单卡 A100、H800，或双 RTX 4090 上的训练表现。昇腾 910D 是否适用，也要结合框架支持、量化方式和算子兼容性验证。
更稳妥的做法，是先用较小模型跑通数据、输出和评估闭环。确认模型确实学会了审核口径，再决定是否扩大参数规模。
使用 LLaMA-Factory 或 Unsloth 时，可以从下面这组 LoRA 参数开始做小规模对照：
config = {
"base_model": "<已核对的基础模型>",
"lora_r": 16,
"lora_alpha": 32,
"lora_dropout": 0.05,
"target_modules": [
"q_proj", "k_proj", "v_proj", "o_proj",
"gate_proj", "up_proj", "down_proj"
],
"epochs": 3,
"batch_size": 4
}
16、32、0.05、3 和 4 都只是实验起点。目标模块要与模型结构对应，批量大小则按实际显存调整。显存紧张时可以考虑 QLoRA，但量化不能替代数据质量检查。
合同审核还要专门训练输出格式。建议固定 risk_level、clause_content、legal_basis 和 suggestion 四个字段，让后续系统能够稳定解析。训练数据中既要有风险条款，也要有无需修改的正常条款和边界案例。检索不到明确法律依据时，应输出“待人工复核”，不要让模型自行补写条文。
会更新的法律依据交给 RAG
微调主要用来固定任务边界、判断方式和输出格式。法律条文、司法解释及内部审核规则需要持续更新，更适合放进 RAG 知识库。
构建知识库时，可以将经确认有效的《民法典》《公司法》和相关司法解释按条、款切分，并保留文书名称、条款编号、效力状态和来源链接。随意按固定字符数截断，容易把前提条件与法律后果拆开。
向量库可以选择 Milvus 或 ChromaDB。检索层建议同时保留稠密向量和 BM25：向量检索负责语义相近的表达，BM25 更容易抓住“连带责任”“表见代理”等明确术语。推理流程可以压缩成三步：
- 根据合同条款检索相关法律依据；
- 将检索结果连同原文交给微调后的模型；
- 要求模型只引用给定材料，并返回法律名称、条款编号和审核建议。
RAG 本身不会自动带来正确答案。检索遗漏、旧版本法规和错误切片，都会传导到最终输出。因此，检索命中率和法规版本也要单独测试，不能只看生成结果是否流畅。
评估时，先看模型错在哪里
训练 Loss 下降，只能反映模型对训练数据的拟合情况。法律审核需要把误报、漏报、依据错误和格式失败分开统计。
| 检查项 | 需要回答的问题 |
|---|---|
| Precision | 模型标出的风险中，有多少得到律师确认？ |
| Recall | 基准答案中的风险点，模型找出了多少？ |
| F1-Score | 精确率和召回率是否保持合理平衡？ |
| 依据核验 | 法律名称、条款编号和引用内容是否对应？ |
| 格式稳定性 | JSON 能否解析，原文片段是否被擅自改写？ |
| 人工复核 | 律师选择接受、修改还是驳回，原因是什么？ |
误报和漏报要分别建立案例集。例如，把标准的“不可抗力”表述识别成违约风险，属于需要单独归因的误报；没有识别出责任上限或主体变化，则应检查标签、上下文长度和检索结果。
资深律师的复核仍是上线前的关键关卡。可以记录每条建议的接受、修改和驳回结果，再将确认后的样本送回下一轮训练。未经复核的模型输出，不宜直接当成新的标准答案。
本地部署也要管住数据流
本地部署可以减少敏感合同离开组织边界的机会，但服务器上的训练副本、向量数据库、推理日志、临时文件和备份仍要纳入权限管理。只关注模型权重，没有处理这些数据路径，隐私风险依然存在。
上线初期可以让系统以只读方式生成审核报告，由律师确认后再进入合同流程。每次输出最好能够追溯到原始条款、模型版本、LoRA 适配器版本、知识库版本、检索片段和人工处理结果。
等误报、漏报和引用错误稳定在团队可接受的范围内，再把审核能力封装成 Agent，对接 OA 或合同管理系统。判断系统是否可交付，有一个直接标准：每个风险结论能否回到原文、法律依据和复核记录。做不到这一点，继续增加参数量也解决不了流程上的缺口。
