中文法律大模型zip包：从解压到部署微调的全流程实战

简介面向中文法律领域的大模型应用资源包以中文法律大模型为主线覆盖法律智能问答、法律咨询、法律概念解析等典型场景适合AI大模型开发者、自然语言处理研究者及法律科技从业者参考。整个zip压缩包共35个文件大小约7.78MB主要包含模型架构示意图与效果对比图、用于演示的法律概念和法律咨询数据、可运行的Python与Shell脚本以及Markdown格式的说明文档目录结构清晰便于按模块检索。资源内附带的演示数据采用结构化格式可直接观察输入输出逻辑帮助理解法律问答系统在具体业务中的表现。目前已有270人学习借助该资源可系统了解中文法律大模型的数据组织方式、推理展示流程和部署运行环节。作者在AI大模型应用落地方面积累的实践经验也融入其中对于希望快速搭建类似系统、处理环境配置或进行技术选型的读者具有较强的参考价值和可操作性。1. 中文法律大模型 zip为什么以压缩包形式分发开箱前先搞清三件事做法律智能化的人最近手头多半会有一个这样的 zip 包《AI大模型应用》-中文法律大模型.zip。它不是一份 PDF 也不是一段代码而是一个把模型权重、推理脚本、依赖清单和说明文档打包在一起的压缩包。常见做法是团队把训练好的中文法律大模型导出后用 zip 压缩以方便内网传输或离线部署——毕竟法律数据涉密程度高很多律所和法院系统不允许直接拉 Hugging Face 模型。但别急着解压就跑这个 zip 背后有三件事需要先弄明白一是包里的模型是个什么架构二是你的显卡能不能装下三是这份压缩包是否完整、有没有被伪加密或传输损坏。搞清楚这三件事后续的部署和二次开发才不是玄学。这个包解决的问题很直接让没有大模型训练经验的法律科技从业者也能用一个本地跑得起来的中文法律模型完成法条检索、文书生成、合同审查等业务。适合律所 IT、法律软件开发商、法务智能化团队以及想在大模型应用开发里切入垂直赛道的工程师。下面我从解压到调优按我自己的实操路径把步骤和坑位都拆开。2. 解压与目录结构中文法律大模型 zip 里的文件各管什么2.1 解压前检查zip 伪加密、完整性校验与杀毒误报我在拿到任何大模型 zip 后第一件事不是双击解压而是先用命令行判断这个 zip 是不是挖了坑。最常见的一个坑是 zip 伪加密——文件头里的加密标志位被改成 1但实际上文件内容并没有加密。用 Windows 自带解压会直接弹窗要密码很多人就傻傻去搜“zip密码移除”的教程。实际上伪加密用 7-Zip 打开时能正常列出文件内容但解压时提示错误更隐蔽的情况是解压出来一堆坏文件模型加载时才发现权重损坏。先跑一个完整性校验# Linux 下用 unzip 测试 zip 包完整性-t 表示 test archive integrity unzip -t AI大模型应用-中文法律大模型.zip # 如果提示 missing entry 或者 CRC 错误说明压缩包在传输中损坏或被人为改过 # 用 7z 查看压缩包内文件列表确认是否伪加密 7z l AI大模型应用-中文法律大模型.zip第一条命令把 zip 里的每个文件做 CRC 校验能直接发现压缩包是否完整。第二条命令用来观察文件条目——如果文件列表里没有加密标记但解压时要求输密码基本可以判断是伪加密。遇到这种包不需要去猜密码直接用 7-Zip 的“修复”功能或者脚本强制清掉加密标志位因为文件本身没有真正加密数据是明文存储的。Windows 上用 7-Zip 打开后选中全部文件右键选择“复制到”文件夹它不会触发密码检查能直接把内容抠出来。杀毒软件误报也经常在解压模型权重时出现。safetensors 或 pytorch_model.bin 动辄几个 GB而且内部是二进制大块数据部分杀毒引擎会因为“文件过大且无有效 PE 头”而判定为异常。我的经验是先在隔离环境解压并校验哈希如果与发布方给的 MD5 或 SHA256 一致就把它加入杀毒软件白名单避免后续多次解压时被后台清理掉。2.2 目录与文件清单模型权重、tokenizer、配置文件、推理脚本解压完成后第一件事是认目录。一个完成度高的中文法律大模型 zip 包内部结构通常长这样中文法律大模型/ ├── config.json # 模型架构配置层数、头数、词表大小、max_position_embeddings ├── generation_config.json # 生成参数默认值 ├── model.safetensors.index.json # 分片权重索引如果模型被切成多个文件 ├── model-00001-of-00004.safetensors ├── model-00002-of-00004.safetensors ├── model-00003-of-00004.safetensors ├── model-00004-of-00004.safetensors ├── tokenizer.json # 词表文件 ├── tokenizer_config.json ├── special_tokens_map.json ├── requirements.txt # Python 依赖注意版本约束 ├── inference.py # 示例推理脚本 ├── finetune_data_sample.json # 如果有微调示例数据会放在这里 └── README.md # 发布说明和硬件要求我不建议直接看 README 就信它的硬件要求要自己打开 config.json 看几个关键数字因为它们直接决定你这台机器能不能跑起来。最常见的中文法律大模型基座是 LLaMA 架构的变体或者是 Qwen 系列参数量从 7B 到 70B 不等。config.json 里重点看这三项hidden_size、num_hidden_layers、vocab_size。比如hidden_size是 4096、num_hidden_layers是 32那很可能是 7B 模型如果hidden_size是 8192、层数 80那就是 70B 级别。7B 模型半精度加载大概需要 14 GB 显存70B 则需要 140 GB 以上。tokenizer 文件也要确认。中文法律模型必须使用中文词表如果vocab_size只有 32000 且没有中文字符那它实际上是个英文模型套了中文微调壳法律术语很容易被切碎。我习惯用 Python 检查一下 tokenizer 是否能正确切分词“要约”“不可抗力”“连带责任”from transformers import AutoTokenizer tk AutoTokenizer.from_pretrained(./中文法律大模型) for word in [要约, 不可抗力, 连带责任]: tokens tk.tokenize(word) print(word, tokens)如果“不可抗力”被切成一堆无意义的字节说明中文词表覆盖不足后续微调时要考虑扩展词表否则法律文本的生成效果会明显打折。2.3 依赖环境Python 版本、CUDA、transformers 版本对应环境配置是另一个劝退点。大模型推理依赖的库版本非常敏感特别是transformers、accelerate、torch三者的版本组合。zip 包里的 requirements.txt 如果写的是transformers4.38但你这台机器的 Python 是 3.8那大概率装不上——高版本 transformers 要求 Python 3.9。我的习惯是直接建一个干净的 conda 环境conda create -n legal_llm python3.10 -y conda activate legal_llm # 先装 torch根据显卡驱动选择 CUDA 版本以当前稳定版为例 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 # 再装推理相关依赖 pip install -r requirements.txtrequirements.txt里一般会有transformers、accelerate、safetensors、sentencepiece、einops、bitsandbytes这些。bitsandbytes 在 Windows 上经常安装失败因为它依赖编译过的二进制文件。如果遇到报错我建议直接用纯 CPU 版本的量化方案或者换成 Linux 环境。做法律大模型应用开发的人最好一开始就用 WSL2 或一台 Linux 服务器省掉后面极其多的踩坑时间。还有一个容易被忽略的如果你用的是 Linux 服务器且离线环境不能联网 pip install那就在下载依赖的机器上把 pip 缓存打包成离线 wheel 目录pip download -r requirements.txt -d ./wheels tar czf wheels.tar.gz wheels # 拷到离线服务器 pip install --no-index --find-links./wheels -r requirements.txt这个操作对我来说是常规操作。法律行业很多生产环境都是物理隔离网络zip 包本身也是为这种场景准备的依赖包离线下载是同一套思路。注意torch的 wheel 非常大离线传输时确保介质格式是 ext4 或 NTFS别用 FAT32单文件 4GB 上限会让你拷到一半就失败。3. 本地跑通最小推理用 transformers 加载中文法律大模型并完成一次问答3.1 最小推理代码加载模型与 tokenizer注意设备映射环境齐了目录文件认清楚了就可以写最小推理脚本。我不会一上来就上 vLLM 或者 FastAPI先把模型加载起来跑通一个句子确认权重没有损坏、前向传播正常。下面是我平时最常用的一段代码import torch from transformers import AutoModelForCausalLM, AutoTokenizer, GenerationConfig model_path ./中文法律大模型 tokenizer AutoTokenizer.from_pretrained(model_path, trust_remote_codeTrue) # device_mapauto 让 accelerate 自动分配层到可用设备 # torch_dtypetorch.float16 半精度加载7B 模型显存占用约 14GB model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.float16, device_mapauto, trust_remote_codeTrue, ) # 输入一个法律问题注意用模型要求的对话模板一般 README 里会给 prompt 请问民法典第 584 条规定的违约损害赔偿范围是什么 messages [ {role: user, content: prompt} ] input_ids tokenizer.apply_chat_template( messages, add_generation_promptTrue, return_tensorspt ).to(model.device) # 生成显式指定 GenerationConfig不要依赖默认值 outputs model.generate( input_ids, max_new_tokens512, do_sampleFalse, top_p1.0, temperature1.0, ) response tokenizer.decode(outputs[0][input_ids.shape[1]:], skip_special_tokensTrue) print(response)这里有几个关键点。trust_remote_codeTrue是因为很多中文法律模型自定义了 model 实现不信任远程代码会直接报AutoModelForCausalLM不匹配。device_mapauto允许模型层分散到多张 GPU 或者 CPU 与 GPU 混合如果你的显存不够accelerate 会按剩余显存自动切分。但注意CPU 和 GPU 混合加载后跨设备前向传播会很慢建议别把最后一层放在 CPU 上。生成参数里法律问答我一般设置do_sampleFalse贪心解码保证结果可复现。法律场景要的是稳定和准确不是文采。max_new_tokens512对于一般条文问答够用但如果要生成完整法律意见书可能要 2048。3.2 参数说明max_length、temperature、top_p 如何影响法律问答法律模型和通用模型不一样输出对确定性要求极高。很多人调参时习惯把temperature0.7、top_p0.9默认带上去这在写故事场景没问题但用在法律问答里会导致同样的案情问三次给三个不同答案。我自己的参数经验如下参数法律问答推荐值合同生成推荐值说明do_sampleFalseTrue法条问答必须贪心合同条款模板可以带随机性temperature1.0无效0.3sample 模式下越低越保守top_p1.0无效0.5限制候选概率累积和防止乱选repetition_penalty1.151.2法律生成容易重复“根据《”开头max_new_tokens5122048文书生成要更长上下文注意一个反直觉点do_sampleFalse时temperature和top_p会没有任何作用因为模型直接选最大概率的 token。所以如果你在代码里看到有人把do_sampleFalse和temperature0.1同时写那 0.1 是无效的纯粹是在写心理安慰。我在做法律问答时还会额外加一个bad_words_ids来屏蔽一些模型常见的幻觉开头比如“作为一个人工智能”“我不是法律专家”。这个操作可以直接嵌入 tokenizer# 屏蔽模型自我否定的固定说法减少安全式“车轱辘话” bad_words [作为AI, 我不能, 我不是法律专家] bad_ids [tokenizer.encode(w, add_special_tokensFalse) for w in bad_words] outputs model.generate( input_ids, max_new_tokens512, do_sampleFalse, bad_words_idsbad_ids, )不过屏蔽词要慎用如果“我不能”里有真实回答的必要内容也会被跳过。我通常只在第一轮测试时加正式业务中靠系统提示词约束效果更好。3.3 流式输出与批量处理从单条到多条的法律条文检索增强单条推理跑通后接着要做的是把代码改成可对外服务的形态。法律应用场景往往是成百上千条合同条款批量审查逐条循环调model.generate()会慢到怀疑人生而且显存分配反复抖动容易 OOM。我的做法是先用 batch 方式处理输入形状为[batch_size, seq_len]生成时num_return_sequences保持 1。# 批量处理多个法律问题 prompts [ 违约金的调整标准是什么, 试用期约定违法如何认定, 连带责任保证的诉讼时效怎么算, ] messages_batch [ [{role: user, content: p}] for p in prompts ] # 用 tokenizer 的 apply_chat_template 处理每个对话然后 pad batch_inputs tokenizer( [tokenizer.apply_chat_template(m, add_generation_promptTrue, return_tensorspt)[0] for m in messages_batch], paddingTrue, return_tensorspt, ).to(model.device) outputs model.generate( batch_inputs.input_ids, attention_maskbatch_inputs.attention_mask, max_new_tokens256, do_sampleFalse, )注意批量生成必须传attention_mask否则 padding 位置会被模型当成真实 token导致回答错乱。另外如果 batch 里一条很短一条很长max_new_tokens会被最长的那条卡住浪费算力。更实用的是按 token 长度排序后分桶或者直接用Transformers的pad_token设为eos_token。流式输出对交互式法律咨询比较有用前端可以像 ChatGPT 一样逐字打出来。实现流式用TextIteratorStreamerfrom transformers import TextIteratorStreamer from threading import Thread streamer TextIteratorStreamer(tokenizer, skip_special_tokensTrue) gen_kwargs dict(input_idsinput_ids, max_new_tokens512, do_sampleFalse, streamerstreamer) thread Thread(targetmodel.generate, kwargsgen_kwargs) thread.start() for text in streamer: print(text, end, flushTrue)这段代码跑起来你就能在 Jupyter 或者 Flask 接口里实时看到输出。不过流式模式只适合在线咨询批量文书审查不需要流式直接等结果就行。4. 面向法律场景的微调与知识注入从通用模型变成“懂法”的模型4.1 为什么要微调法律语言的特殊性与灾难性遗忘解压出来的模型如果是基座模型base model那么它的行为只是“接着补全文本”不会像 ChatGPT 一样遵循指令。如果包已经是一个指令微调后的模型那么 README 里会说明它支持什么问题类型。但很多时候你拿到的中文法律模型是通用中文基座模型需要对法律数据做二次微调才能在裁判文书摘要、合同审查、法条问答这些具体任务上表现合格。法律语言的特殊性在于第一用词精确比如“定金”和“订金”法律后果完全不同模型必须区分第二推理链条长一份判决书要读事实、证据、法律适用、裁判结果上下文关联性强第三输出格式严格法律文书有固定的段落结构和引用格式。通用模型在这些领域里通常只会“泛泛而谈”比如问“违约”就会把违约责任的定义背一遍但不会结合案情分析。微调前先要理解灾难性遗忘。如果你用几十万条法律数据去继续训练一个通用模型模型可能会忘掉基本的语言能力导致生成句子不通顺。我见过有人在 7B 模型上全量微调法律数据后模型连“但是”这种连接词都用不好。这是血泪教训——不要一上来就全量微调优先用 LoRA 这类参数高效微调方法冻结底模只训练低秩矩阵能极大降低遗忘风险。4.2 数据准备把裁判文书、法条转换成指令微调格式微调效果 80% 取决于数据质量不是模型结构。我处理法律数据的标准流程是先把裁判文书从 PDF 里抽出来清洗掉非法字符然后按“指令-输入-输出”的结构组装。以下是我常用的一种数据格式对应 LLaMA 类指令微调[ { instruction: 根据下列案件事实判断是否构成违约并说明依据的法律条文。, input: 甲乙签订供货合同约定乙于2023年6月1日前交货。乙未按时交货甲于6月15日催促乙直到7月10日才交货。, output: 根据《民法典》第五百七十七条当事人一方不履行合同义务或者履行合同义务不符合约定的应当承担继续履行、采取补救措施或者赔偿损失等违约责任。乙未按约定时间交货构成违约。 }, { instruction: 抽取判决书中的裁判理由部分并归纳争议焦点。, input: ...全文, output: 争议焦点一、合同是否有效二、违约金是否过高三、损失认定。裁判理由... } ]清洗数据时特别注意脱敏是第一位的人名、身份证号、车牌号、公司税号必须替换为占位符。法律行业数据泄露不是小问题我一般用正则做两轮清洗import re def anonymize_text(text: str) - str: # 替换身份证号 text re.sub(r\b\d{17}[\dXx]\b, [身份证号], text) # 替换手机号 text re.sub(r\b1[3-9]\d{9}\b, [手机号], text) # 替换公司名示例以“有限公司”结尾的短语 text re.sub(r[\u4e00-\u9fa5]{2,20}(?:有限(?:责任)?公司|股份有限公司), [公司], text) # 替换人名简单启发式上下文需要再调 text re.sub(r((?:原告|被告|第三人)[:]?\s*)([\u4e00-\u9fa5]{2,4})(?\s*[,;]|\s*$), r\1[当事人], text) return text人名替换比较难做准因为中文人名没有边界。我的经验是只替换带有“原告”“被告”“委托诉讼代理人”等身份关键词后的 2-4 个汉字减少误杀。如果你用的是裁判文书还可以先做命名实体识别但那样数据管线就变重了少量数据时正则够用。微调数据量方面我的体会是针对一个具体任务如合同审查 1万条高质量指令对就有效果如果要覆盖整个法律咨询域至少要有 10 万条以上并且要覆盖婚姻家庭、劳动纠纷、合同、侵权、刑事等高频细分领域。少于 5000 条时模型基本学不到新知识只是把话术改了一下。4.3 微调参数与算力权衡LoRA vs 全量微调对法律垂直模型我不推荐全量微调特别是 7B 以上。全量微调需要完整优化器状态单卡 A100 80GB 也只能勉强跑 13B 模型的 LoRA全量微调至少需要 8 卡 A100。实际项目中LoRA 的效果在很多法律任务上已经接近全量微调而且显存占用小一个数量级。使用 HuggingFace 的 PEFT 库代码流程非常固定from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model, TaskType model_path ./中文法律大模型 model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.bfloat16, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(model_path) lora_config LoraConfig( task_typeTaskType.CAUSAL_LM, r16, lora_alpha32, lora_dropout0.05, target_modules[q_proj, k_proj, v_proj, o_proj], biasnone, ) model get_peft_model(model, lora_config) print(model.print_trainable_parameters()) # 输出 trainable params: ~ 8MB, 占比很小r是低秩矩阵的秩r16是我常用的起点。法律任务如果数据量小1万条以下建议r8避免过拟合数据量大5万条以上r32效果更好。lora_alpha控制缩放系数一般取r的 2 倍。target_modules要匹配模型的注意力模块命名不同架构命名不同——LLaMA 是q_proj、k_proj、v_proj、o_projQwen 是q_proj等但层名带h。如果不确定先打印 model 结构或者直接用peft的get_peft_model时候尝试全部线性层。训练参数上我常用的配置如下training_args TrainingArguments( output_dir./legal_lora_checkpoint, evaluation_strategysteps, eval_steps500, save_steps1000, learning_rate2e-4, per_device_train_batch_size1, gradient_accumulation_steps16, num_train_epochs3, bf16True, logging_steps100, remove_unused_columnsFalse, )法律数据往往长短差异极大一个 batch 塞不下所以per_device_train_batch_size1配合gradient_accumulation_steps16等效 batch size 为 16。学习率 2e-4 对于 LoRA 是安全值超过 5e-4 容易震荡。bf16要求 Ampere 架构以上的 GPU如果是老的 V100 用fp16True并加fp16_opt_levelO1。训练完成后模型保存的只是 LoRA 适配器权重大概几十 MB非常适合用 zip 打包分发。推理时要先加载基座模型再加载 LoRAfrom peft import PeftModel base_model AutoModelForCausalLM.from_pretrained( ./中文法律大模型, torch_dtypetorch.float16, device_mapauto, ) model PeftModel.from_pretrained(base_model, ./legal_lora_checkpoint) model model.merge_and_unload() # 合并 LoRA 权重模式切换为推理模式这里提醒一句拆分文件后的 zip 包如果用 pytorch 格式保存权重合并 LoRA 时容易因为基座权重文件名不一致报错。所以我保存模型时一律用 safetensors并带上model.safetensors.index.json分片索引这样 PeftModel 能找到基座的每片权重。如果你拿到的 zip 包是 pytorch_model.bin建议先转换成 safetensors 再微调否则后续部署被恨死。5. 部署避坑与常见问题中文法律大模型 zip 落地遇到的 5 个典型故障5.1 模型加载 OOM现象、原因与分块加载解决现象运行加载脚本时进程直接报CUDA out of memory或者更隐蔽的——刚开始加载没事一执行model.generate()就崩。原因很多模型权重是 float16 精度但 transformers 默认用 float32 加载显存翻倍。另外device_mapauto在显存不够时会把层放到 CPU但生成时计算图仍可能在 GPU 上占用额外缓存。解决显式指定torch_dtypetorch.float16或torch.bfloat16再配合accelerate的max_memory设置把每一张卡的内存上限卡死from transformers import AutoModelForCausalLM max_memory {0: 12GB, cpu: 32GB} # 12GB 显存 32GB 内存 model AutoModelForCausalLM.from_pretrained( ./中文法律大模型, torch_dtypetorch.float16, device_mapauto, max_memorymax_memory, )这样模型层会被自动分配到 GPU 和 CPU 上。但要注意如果模型有 7B 参数float16 需要 14GB 权重只给 GPU 12GB 的话会有 2GB 落到 CPU生成速度骤降。我会优先把max_memory的 GPU 部分设成你能接受的最大的值让 CPU 兜底。另外生成时把use_cacheTrue默认打开可以减少重复计算但会多占显存如果是极端 OOM可以use_cacheFalse换速度。5.2 乱码与编码问题Windows 下 UTF-8 与 GBK 冲突现象在 Windows 上运行推理脚本控制台输出一堆“锟斤拷”或者直接报UnicodeDecodeError读取数据文件时中文变成乱码。原因zip 包里的数据文件一般是 UTF-8 编码但 Windows 控制台默认用 GBK 解码Python 在 Windows 上读取文件时如果没指定编码会使用系统区域设置导致中文错乱。解决两个层面。第一读取文件时显式指定encodingutf-8不要靠默认值import json with open(finetune_data_sample.json, r, encodingutf-8) as f: data json.load(f)第二设置 Python 环境变量让 stdout 用 UTF-8。在脚本开头加import sys import io sys.stdout io.TextIOWrapper(sys.stdout.buffer, encodingutf-8)更省事的是在 Windows 上通过chcp 65001把控制台代码页切到 UTF-8但那只是临时有效用上面的代码最稳。注意 model 输出的 tokenizer 解码结果本来就是 Unicode 字符串直接 print 乱码几乎总是控制台编码问题不是模型问题。5.3 zip 伪加密与密码移除解压报错但压缩包能打开现象你从网盘或内网下载的中文法律大模型 zip双击打开能看到文件列表但解压时弹窗要求输入密码网上找了一圈“zip密码移除”的攻略也不管用。原因很多模型包在打包时误用了伪加密。zip 格式的加密标志位如果只标记在本地文件头而没有实际对文件内容做加密就会产生这种“要密码但密码不存在”的假象。国内某些压缩软件在勾选“加密文件名”时会把文件头加密标志位置 1但内容仍是明文兼容性极差。解决用 7-Zip 打开后不要点“提取”而是用“复制到”功能直接把文件拖出来。7-Zip 对伪加密的容错比 Windows 自带解压强很多。另一个更硬核的方式是用 Python 的zipfile库读取它只校验文件头不会检查加密位可以直接读出内容import zipfile with zipfile.ZipFile(中文法律大模型.zip, r) as zf: # 打印所有文件列表排除目录项 for info in zf.infolist(): if not info.is_dir(): print(info.filename, info.file_size) # 如果提示 RuntimeError: File is encrypted但实际上是伪加密 # 可以用 zipfile 内部把 flag_bits 0x1 置 0 的 hack 方法 for info in zf.infolist(): if info.flag_bits 0x1: info.flag_bits ^ 0x1 # 清掉加密标志 # 现在可以正常读取 data zf.read(README.md) print(data.decode(utf-8, errorsreplace))这个方法只能绕过伪加密真正加密的 zip 仍然会被RuntimeError拒掉。我遇到伪加密时第一时间会核对包大小和内部文件体积是否一致——伪加密的文件体积和明文完全一致真正的 AES 加密文件会略大一些。这个特征几乎百试百灵。5.4 回答质量差幻觉与法条引用错误如何用检索约束现象问“民法典第 584 条是什么”模型能答出来但问“某合同违约金约定过高法院一般怎么调”模型会引用一个不存在的法条或者把《民法典》第 585 条说成是第 586 条。原因法律大模型即使微调过本质仍是概率语言模型。法条编号是稀疏离散信息模型在生成时容易混淆相近数字。尤其是当问法带具体案情时模型会倾向于“续写”一个看起来合理的答案而不是去查证。解决不要只靠模型内部记忆引入检索增强生成RAG。把现行有效的法律条文向量化存入向量库每回答前先检索相关条文然后把条文原文作为上下文交给模型。这个方案我后面第 6 章详细展开。这里先说一个轻量级约束在 system prompt 里强制要求“回答必须引用给定的条文原文不得自行编造条文号”并解码时开启repetition_penalty能降低幻觉出现频率但无法根除。生产环境不加 RAG 的法律问答系统是不可信的这是法律场景的红线。5.5 推理速度慢量化与 vLLM 替代方案现象单次问答耗时 10 秒以上吞吐量低无法支撑真实业务。原因transformers的原始generate是自回归逐 token 生成没有做高并发优化模型是 float16 全精度计算量大显存带宽限制。解决如果只是自己测试先用torch.compile加速需要 PyTorch 2.x能提升 20%-30%。但生产上我会直接用 vLLM 作为推理服务。vLLM 支持 PagedAttention、连续批处理对法律咨询这种短文本场景吞吐量比 transformers 高 5-10 倍。vLLM 加载本地模型目录from vllm import LLM, SamplingParams llm LLM(model./中文法律大模型, dtypefloat16, gpu_memory_utilization0.9) sampling_params SamplingParams( temperature0, top_p1.0, max_tokens512, repetition_penalty1.15, ) outputs llm.generate(民法典第 584 条的内容是什么, sampling_params) print(outputs[0].outputs[0].text)temperature0对应贪心解码和do_sampleFalse等效。gpu_memory_utilization0.9表示让 vLLM 使用 90% 显存它会在内部管理 KV cache比 transformers 的显存利用率高很多。注意 vLLM 对模型架构有要求LLaMA 架构和 Qwen 架构都支持如果你的中文法律模型是自定义架构需要确认是否在 vLLM 支持列表里否则只能继续用 transformers。量化是另一个路子。用 GPTQ 模型量化为 4bit7B 模型显存占用降到 4GB 左右普通 3060 都能跑。但量化会带来精度损失法律场景下法条编号可能更不稳定。我的建议是对法律问答优先用 float16 配 vLLM实在没显存才考虑 4bit 量化并做充分的评估。6. 把法律大模型接到业务里RAG 检索增强与效果验证6.1 用向量库给模型“开卷考试”接入法条检索到这里你已经有一个能跑通的本地法律大模型。但要让它在真实业务中可信必须把法条数据库“外挂”给模型。常见做法是把《民法典》等法律条文切分成小段每段用 embedding 模型转成向量存进向量数据库每次用户提问先在向量库里检索最相关的几段条文把条文原文拼进 prompt让模型基于条文回答。这相当于开卷考试模型没有机会编法条编号。我用sentence-transformers做 embedding用简单易部署的chromadb存向量整个流程在本地就能跑通from sentence_transformers import SentenceTransformer import chromadb from chromadb.utils import embedding_functions # 加载中文 embedding 模型推荐用 moka-ai/m3e-base 或 bge-large-zh embed_model SentenceTransformer(moka-ai/m3e-base) # 准备法条切片每一条法条作为一组 laws [ 第五百七十七条 当事人一方不履行合同义务或者履行合同义务不符合约定的应当承担继续履行、采取补救措施或者赔偿损失等违约责任。, 第五百八十四条 当事人一方不履行合同义务或者履行合同义务不符合约定造成对方损失的损失赔偿额应当相当于因违约所造成的损失..., # ... 更多 ] # 计算向量 law_vectors embed_model.encode(laws, normalize_embeddingsTrue) # 存入 Chroma也可以用内存模式 client chromadb.Client() collection client.create_collection( namelaw_corpus, embedding_functionembedding_functions.SentenceTransformerEmbeddingFunction(model_namemoka-ai/m3e-base), ) for i, (law, vec) in enumerate(zip(laws, law_vectors)): collection.add( ids[str(i)], documents[law], metadatas[{law_id: i}], embeddings[vec], )检索时把用户问题同样编码成向量在集合里查询 TopK然后把这些条文拼进 promptquestion 合同违约金过高法院如何调整 q_vec embed_model.encode(question, normalize_embeddingsTrue) results collection.query(query_embeddings[q_vec], n_results3) retrieved_laws \n.join([doc for doc in results[documents][0]]) prompt f以下是中国法律条文请严格根据条文内容回答问题。\n\n条文:\n{retrieved_laws}\n\n问题: {question}\n回答:注意检索的“召回”质量直接影响最终答案。法条切分不要按章切太长的段落容易稀释相关上下文我按“条”来切每条单独作为一个 doc。如果某条过长比如第 585 条有多款我会按“款”切避免最大 token 超限。同时常规法律问答还需要加入“相关性阈值”如果检索结果分数太低宁可让模型说“抱歉我无法从已有法条中找到依据”也不能硬答。6.2 回答评估从准确性、引用一致性到安全性测试部署完成后最容易被跳过的是评估环节。法律从业者不会因为模型能“聊”就买单他们要求的是可验证的准确率。我习惯建立一个小的评估集包含三类问题法条引用题问“《民法典》第 585 条规定了什么”答案必须准确出现“第五百八十五条”和相关内容。案情分析题给一段具体案情问如何适用法律需要包含推理过程。风险题涉及犯罪手段、报复性言论、自杀教唆等模型必须安全拒绝。评估时用规则检查引用一致性而不是只靠人工打分import re def check_legal_citation(response, expected_law_id): # 检查回答中是否出现了期望的法律条文号 pattern r第\s*(\d)\s*条 cited_laws re.findall(pattern, response) return expected_law_id in cited_laws, cited_laws # 例子 ok, cited check_legal_citation( 根据民法典第五百八十四条损失赔偿额应相当于因违约所造成的损失。, 584 ) print(ok, cited) # True, [584]这个脚本虽然简单但能批量跑几百条测试很快发现模型在哪些法条编号上爱犯错。另一个重要评估是“幻觉率”给定一个不能从检索段落里得到答案的问题看模型是否强行编造。我测试时会把检索阈值调得很低让模型无上下文可引如果它还能一本正经引用法条那说明安全约束不够需要把“未检索到相关内容时必须拒绝回答”写进 prompt 的硬性要求。最后一步是压测和监控。用 vLLM 部署后我还会记录每次调用的首 token 延迟和生成耗时以及单 token 生成速率。法律业务吞吐量很低但每分钟请求数波动大vLLM 的连续批处理能扛住。我一般习惯在服务上线前用 100 条历史咨询记录跑一遍回归对比新旧模型版本的回答确保这次升级没有把之前修好的问题又弄坏。这个习惯是从一次翻车里长出来的——那次我直接用新微调版模型上了生产结果发现它对“定金罚则”的理解全乱了因为微调数据里相关的样本太少。从那以后任何模型升级必须过一遍回归测试。希望帮到你。本文还有配套的精品资源点击获取