简介：LexiLaw 是一套面向法律从业者、法学院学生及对法律知识有需求的普通用户的中文法律大模型资源，基于 ChatGLM-6B 架构在法律领域数据集上微调而成，可用于法律咨询、条款解读、案例解析与法规查询等场景，帮助读者理解大模型在法律垂直领域的落地方式。资源包共 60 个文件，以 28 个 Python 脚本和 16 个 pyc 编译文件为核心，覆盖 LoRA、P-Tuning、Freeze 等多种微调与推理流程，另含 3 个 Markdown 说明、3 个 Shell 脚本、2 个 JSON 配置、2 个 JavaScript 与 2 张 PNG 图示，以及 whl、css、ico、txt 等辅助文件，压缩包约 1.48MB，目录结构清晰，便于按模块查阅。目前已有 339 人学习下载。读者可从中获取完整的微调与推理脚本、模型配置、指令数据示例及知识库构建代码，并参考作者分享的微调经验与最佳实践，快速复现中文法律问答流程，为开发同类垂直领域大模型提供可借鉴的工程思路。
1. 中文法律大模型落地：LexiLaw 到底能替谁省下哪段工时
第一次听到“人工智能-预训练大语言模型-LexiLaw - 中文法律大模型”这个组合，很多同行第一反应是“又一个套壳问答”。但真正在做法务系统、合同审查工具或者法律知识库的人会立刻意识到，通用大模型在中文法律场景里有个绕不开的硬伤：它能把“不可抗力”解释得头头是道，却经常把《民法典》里的具体条文号记串，更别提区分“连带责任”和“按份责任”在判决书里的适用边界。LexiLaw 这类中文法律大模型要解决的，就是让模型在预训练阶段就吃进足量的中文法律语料，再通过指令微调对齐法律问答、文书生成、案情摘要这几类高频任务。它适合两类人：一是想给现有法律检索或合同系统加一层自然语言交互能力的工程师，二是需要本地化部署、数据不出内网的法务技术团队。如果你只是想要一个能聊天的法律百科，通用模型加提示词就够了；但如果你要的是稳定输出条文引用、格式规整的法律意见草稿，那往下看。
2. 从基座到法律专家：LexiLaw 的选型逻辑与数据管线
2.1 为什么不是直接拿通用模型加提示词
通用大模型在法律场景翻车，根子不在参数量，而在预训练语料的分布。中文法律文本有几个鲜明特征：条文编号密集、长句嵌套、大量“的”字结构、以及“应当”“可以”“不得”这类情态动词的精确用法。通用模型在预训练时见过法律网页，但占比极低，导致它对“第三百九十七条”这种具体指代缺乏稳定记忆。LexiLaw 的思路是在基座模型（常见做法是选一个中文能力尚可的开源基座，比如 6B 到 13B 量级）之上，用法律领域语料做继续预训练，再用指令数据做监督微调。继续预训练阶段喂进去的通常是裁判文书、法律法规条文、法律问答对、合同范本这几类。这一步的目标不是让模型背法条，而是让它学会法律文本的“语感”——比如看到“本院认为”就知道后面跟的是说理，看到“判决如下”就知道要输出主文格式。
2.2 数据管线的四个关键环节
法律语料的质量直接决定微调上限。我一般会把管线拆成采集、清洗、分段、标注四步。采集环节，裁判文书和法规条文相对好拿，但要注意脱敏——当事人姓名、身份证号、具体地址必须替换成占位符，否则模型会学会生成看似真实的个人信息。清洗环节最耗时，法律文本里混着大量页眉页脚、扫描件 OCR 噪声、以及重复的“此致某某法院”。分段环节要按法律语义切，不能按固定字数切，否则会把一个完整的“经审理查明”段落拦腰截断。标注环节针对指令微调，需要构造“问题-答案”对，答案里要包含条文引用和推理步骤。
# 法律语料清洗与分段的最小示例 import re def clean_legal_text(raw: str) -> str: # 去除页眉页脚常见模式 raw = re.sub(r'第\s*\d+\s*页\s*共\s*\d+\s*页', '', raw) # 去除多余空白但保留段落分隔 raw = re.sub(r'[ \t]+', ' ', raw) raw = re.sub(r'\n{3,}', '\n\n', raw) # 脱敏：替换身份证号（简化正则，实际需更严格） raw = re.sub(r'\b\d{17}[\dXx]\b', '[身份证号]', raw) # 脱敏：替换手机号 raw = re.sub(r'\b1[3-9]\d{9}\b', '[手机号]', raw) return raw.strip() def split_by_legal_semantic(text: str, max_len: int = 512) -> list: # 按法律文书结构切分，优先在“本院认为”“判决如下”等标记处断开 markers = ['本院认为', '经审理查明', '判决如下', '裁定如下', '综上'] segments = [] current = '' for para in text.split('\n'): if any(m in para for m in markers) and len(current) > max_len * 0.5: segments.append(current.strip()) current = para else: current += '\n' + para if current.strip(): segments.append(current.strip()) return segments这段代码里clean_legal_text做的是基础清洗和脱敏，split_by_legal_semantic按法律文书固有结构切分。参数max_len控制单段最大长度，设 512 是因为多数基座模型的位置编码在这个量级表现稳定。注意脱敏正则只是示意，实际生产环境要结合命名实体识别模型，否则会漏掉“某省某市某区”这类地址信息。
2.3 继续预训练与指令微调的分工
继续预训练用因果语言建模目标，让模型预测下一个 token，数据量通常在 GB 级。指令微调用“输入-输出”对，数据量小得多，几千到几万条即可，但质量要求极高。一个常见误区是把两者混在一起训，结果模型既没学好法律语感，又过拟合了少量指令模板。我的做法是分两阶段：第一阶段用法律语料跑 1 到 2 个 epoch，学习率设小一点，比如 1e-5 到 2e-5；第二阶段用指令数据跑 3 到 5 个 epoch，学习率再降一个量级。指令数据的构造要覆盖三类任务：条文检索问答、案情摘要生成、法律意见草稿。每类至少几百条，且答案里必须显式引用条文号，否则模型学不会“先引条文再给结论”的输出习惯。
3. 本地跑通 LexiLaw 推理：环境、加载与量化部署
3.1 环境准备与依赖版本
本地跑法律大模型，第一道坎是显存。以 6B 参数模型为例，FP16 加载需要约 12GB 显存，加上推理时的 KV Cache，实际要留 16GB 以上。如果只有单张消费级显卡，量化是必选项。常见做法是用 4-bit 量化，显存占用能压到 6GB 左右，代价是生成质量略有下降，但在法律问答这种对精确度要求高的场景，我建议至少用 8-bit，除非实在没卡。依赖方面，transformers、torch、accelerate 这三个是基础，量化还要 bitsandbytes。版本上不要追最新，transformers 4.36 到 4.40 之间比较稳，torch 2.1 以上支持 FlashAttention，能省不少显存。
# 创建虚拟环境并安装核心依赖 python -m venv lexilaw_env source lexilaw_env/bin/activate pip install torch==2.1.2 --index-url https://download.pytorch.org/whl/cu118 pip install transformers==4.38.2 accelerate==0.27.2 bitsandbytes==0.42.0 pip install sentencepiece protobuf这里指定 torch 2.1.2 配 cu118，是因为很多云主机预装驱动对这个组合兼容性最好。bitsandbytes 0.42.0 对 4-bit 和 8-bit 量化的支持比较完整，再新的版本有时会报 CUDA 版本不匹配。装完可以用python -c "import torch; print(torch.cuda.is_available())"验证。
3.2 模型加载与量化配置
加载法律大模型时，tokenizer 要特别注意。中文法律文本里有很多生僻字和异体字，如果 tokenizer 的词表覆盖不够，会被拆成多个 token，影响生成质量。常见做法是直接用基座模型自带的 tokenizer，不要自己重训，除非你有大量领域特有词汇。量化配置通过 BitsAndBytesConfig 控制，load_in_4bit和load_in_8bit二选一，bnb_4bit_compute_dtype设成 torch.float16 能加速计算。
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig import torch model_path = "path/to/lexilaw-model" # 替换为实际模型目录 # 8-bit 量化配置，显存不够再换 4-bit bnb_config = BitsAndBytesConfig( load_in_8bit=True, llm_int8_threshold=6.0, # 异常值阈值，法律文本长句多可适当调高 ) tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_path, quantization_config=bnb_config, device_map="auto", # 自动分配到可用显卡 trust_remote_code=True, ) model.eval()llm_int8_threshold这个参数控制的是异常值检测的阈值，默认 6.0。法律文本里长句和嵌套结构多，激活值分布比通用文本更分散，如果发现生成结果不稳定，可以试着调到 8.0 或 10.0。device_map="auto"让 accelerate 自动分配层到多张卡，单卡就全放一张卡上。加载完后用model.hf_device_map看一眼分配情况，避免有些层被放到 CPU 上拖慢速度。
3.3 推理参数与提示词模板
法律问答的提示词不能像通用聊天那样随意。我一般用固定模板，把“系统角色”“用户问题”“参考条文”三部分分开。参考条文可以留空，让模型自己回忆，但如果有检索系统返回的条文，填进去能显著提升准确率。生成参数里temperature设 0.1 到 0.3，法律场景不需要创造性；top_p设 0.9；repetition_penalty设 1.1 防止重复输出同一条文；max_new_tokens根据任务定，问答 256 够用，文书生成要 512 以上。
def legal_qa(question: str, context: str = "") -> str: prompt = f"""你是一个中文法律助手，请根据以下参考条文回答问题。 参考条文：{context if context else '无'} 问题：{question} 回答要求：先引用具体条文号，再给出结论，最后简要说明理由。 回答：""" inputs = tokenizer(prompt, return_tensors="pt").to(model.device) with torch.no_grad(): outputs = model.generate( **inputs, max_new_tokens=256, temperature=0.2, top_p=0.9, repetition_penalty=1.1, do_sample=True, pad_token_id=tokenizer.eos_token_id, ) response = tokenizer.decode(outputs[0], skip_special_tokens=True) # 只取“回答：”之后的部分 return response.split("回答：")[-1].strip() # 调用示例 print(legal_qa("合同因不可抗力无法履行，能否免除违约责任？"))这段代码里pad_token_id显式设成 eos_token_id 是为了避免生成时的警告。do_sample=True配合 temperature 0.2 让输出有一定灵活性但不跑偏。注意response.split("回答：")[-1]这种截取方式依赖模板一致性，如果模型输出里本身包含“回答：”字样会截错，更稳的做法是用特殊 token 标记输出边界。
4. 避坑与排查：法律大模型落地时最容易翻车的五件事
4.1 条文引用张冠李戴
现象：模型回答里引用了“《民法典》第五百七十七条”，但内容其实是第五百七十八条的。原因：继续预训练时条文语料没有和条文号强绑定，模型学到的只是“条文号+内容”的共现概率，不是精确映射。解决：在指令微调数据里加入“条文号-内容”配对任务，让模型做填空；推理时如果有检索系统，把候选条文作为 context 传入，让模型做选择而非回忆。
4.2 长合同输入被截断
现象：用户贴了一份 3000 字的合同让模型审查，模型只分析了前 500 字。原因：基座模型的位置编码长度有限，常见是 2048 或 4096，超出部分被 tokenizer 直接截断。解决：先做合同分段，每段单独送模型，再用一个汇总步骤合并意见；或者用支持长上下文的基座，但要注意长上下文下注意力稀释，条文引用准确率会下降。
4.3 量化后生成质量断崖
现象：FP16 下回答规整，换成 4-bit 后开始胡言乱语，甚至输出英文。原因：4-bit 量化对激活值中的异常值敏感，法律文本的长句嵌套导致异常值更突出。解决：改用 8-bit；或者在 4-bit 配置里把bnb_4bit_quant_type设成nf4，bnb_4bit_use_double_quant设为 True，能缓解一部分。如果还不行，只能加显存。
4.4 提示词里的“参考条文”被忽略
现象：明明在 context 里给了正确条文，模型还是按自己记忆回答。原因：指令微调时模型习惯了“自己回忆”的模式，对 context 的注意力权重低。解决：在提示词里用更强的指令，比如“必须且只能依据以下条文回答，不得引用其他条文”；或者在微调数据里加入“带 context”的样本，让模型学会依赖外部输入。
4.5 生成结果格式不稳定
现象：有时输出“根据《民法典》第X条”，有时输出“民法典X条”，有时干脆不写条文号。原因：指令数据里格式不统一，模型学到了多种模式。解决：在微调数据里强制统一格式，比如所有答案都以“依据《法律名称》第X条：”开头；推理时用正则后处理，把各种变体归一化。
5. 让 LexiLaw 输出更稳的两个进阶技巧
第一个技巧是“条文检索+模型重排”的两段式。不要指望模型自己记住所有条文，而是先用一个轻量检索模型（比如基于 BM25 或向量检索）从法规库里召回 top-5 候选条文，再把候选条文和问题一起送进 LexiLaw，让模型做“选择+解释”。这样条文引用准确率能从纯生成的 60% 左右提到 85% 以上。检索库的构建要注意条文粒度，按“条”切而不是按“章”切，否则召回内容太长会挤占上下文。
第二个技巧是“自洽性校验”。法律问答最怕模型一本正经地胡说，我一般会让模型对同一个问题生成三次回答（temperature 设 0.3 到 0.5），然后比对三次回答里引用的条文号是否一致。如果三次引用的条文号不同，说明模型对这个知识点不确定，这时候要么降级到检索结果直接返回，要么提示用户“建议人工复核”。这个校验逻辑用几十行代码就能实现，但能挡掉相当一部分高风险输出。
def self_consistency_check(question: str, n: int = 3) -> dict: answers = [] for _ in range(n): ans = legal_qa(question) # 复用前面的推理函数，temperature 调高到 0.4 answers.append(ans) # 提取条文号（简化正则） import re citations = [] for ans in answers: found = re.findall(r'第[一二三四五六七八九十百千\d]+条', ans) citations.append(set(found)) # 三次引用的交集 common = citations[0] & citations[1] & citations[2] return { "answers": answers, "consistent_citations": list(common), "is_stable": len(common) > 0 and all(c == citations[0] for c in citations) }这个函数返回的is_stable为 True 时，说明三次生成引用的条文号完全一致，可以相对放心地展示给用户；为 False 时，建议只展示检索到的条文原文，不展示模型生成的解释。n设 3 是成本和稳定性的折中，设 5 更稳但推理时间翻倍。条文号提取的正则只覆盖了中文数字和阿拉伯数字的常见写法，实际要处理“第 五百 条”这种带空格的变体。
最后说个我自己的教训：早期做法律问答时，我总想把 temperature 调到 0 追求确定性，结果模型输出变得极其死板，同一个问题换个问法就答非所问。后来把 temperature 放到 0.2 到 0.3，配合自洽性校验，反而整体可用性更高。法律场景要的不是绝对确定，而是“不确定的时候能识别出来并交给人工”。希望帮到你。
本文还有配套的精品资源，点击获取
