简介面向中文法律领域的大模型应用与自然语言处理研究者ChatLaw 中文法律大模型素材包以模型配置、演示与评估为主线浓缩了项目从运行到验证的完整素材。压缩包内共 35 个文件涵盖 JSON/JSONL 配置与数据集、Python/Shell 运行脚本、Markdown 说明文档、LICENSE 协议以及大量 JPG/PNG 框架图、界面截图和演示图片整体仅 7.78MB便于快速下载并按目录梳理模型结构。文档与脚本覆盖模型部署、启动运行、法律概念问答、法律咨询等典型场景同时提供 ELO 评估数据与多阶段演示数据可帮助读者理解中文法律大模型的数据组织、评估方式与落地流程。已有 270 人浏览学习适合具备一定自然语言处理基础、希望快速上手中文法律大模型应用与二次开发的开发者参考使用。1. 一套能直接跑起来的中文法律大模型工程ChatLaw 资源包拆解从文件清单能看到什么demo 数据、web.py、run.sh、MERGE.md、ELO_val、truthfulqa.jpg……这不是一个扔给你权重的压缩包而是把数据、训练、部署、评估串成一条线的完整工程。ChatLaw 的目标不是让你去和 GPT 比闲谈而是解决法律咨询、法条检索、文书生成这类对事实性要求极高的场景。通用大模型在术语上会一本正经地胡说八道领域微调是当前最落地的做法。如果你在做 AI 大模型应用开发或者正在给企业做知识库问答这套资源可以直接作为参考基线先跑通 webui再替换自己的法律数据最后用 ELO 和 TruthfulQA 验证效果。按本地部署大模型的通常路径从数据、部署、微调到评估逐层拆解整个过程不依赖闭源 API。2. 模型侧设计法律领域微调的数据形态与评估依据2.1 基座选择与领域适配的逻辑ChatLaw 没有从零预训练而是在中文能力较强的开源底座上做领域适配这类底座常见的是 Ziya-LLaMA、BELLE 等。为什么这么选法律语料虽然量大但高质量、带专家标注的问答数据很少从头训练一个法律模型成本高且难收敛。站在已有底座上做增量预训练和指令微调能用更少的数据拿到更稳的效果。法律领域与通用闲聊有一个本质区别术语必须保持单一语义。普通对话里“不可抗力”可以口语化成“不能预料的情况”但法律回复里必须严格对应民法中的定义和适用条件。另一个痛点是法条有版本时效训练数据一旦混入已废止条文模型就会以极高的置信度引用错误法条。所以领域适配的重点不是让模型会说话而是让它在限定概念空间里做选择。从资源包的文件结构能看出设计意图demo_data_法律概念.jsonl负责基础概念注入demo_data_法律咨询.jsonl负责用户场景化问答而demo_data_stage2.json则承担更复杂的指令顺应与多轮对话。MERGE.md的存在说明权重很可能是以 LoRA 或类似低秩适配形式发布使用前需要合并回基座模型。对做 AI 大模型应用落地的人来说这套分层数据组织方式比单一大杂烩数据更容易复现和迁移。2.2 三类 demo 数据的结构与用途解压后先别急着跑模型把数据文件打开看几行信息量比 README 大得多。三个数据文件对应三个不同的训练目标数据文件代表样本类型训练阶段典型字段demo_data_法律概念.jsonl名词解释、制度说明领域概念注入instruction / outputdemo_data_法律咨询.jsonl用户场景化提问指令微调instruction / input / outputdemo_data_stage2.json多轮对话、复杂指令指令顺应强化messages / system / tools以法律咨询为例数据行大致长这样{instruction: 我在公司工作半年未签订劳动合同现在被辞退能主张什么赔偿, input: , output: 可以主张未签订劳动合同的二倍工资差额以及违法解除劳动合同的赔偿金。具体标准建议咨询当地劳动争议仲裁委员会并保存工资流水与解除通知作为证据。}每个字段各有用途instruction是用户侧问题input用来放附加背景或参考材料output是标准回复。input不是必填项空字符串表示只有单轮问答。stage2的文件结构会更复杂常见的是类似 OpenAI 的 messages 数组支持 system 角色约束回答风格也支持多轮历史拼接。标注质量直接决定模型上限同一事实换几种问法各写几条比写一百条同质问题有用得多。2.3 事实性评估与偏好排序TruthfulQA 和 ELO 为什么同时出现资源包里同时出现truthfulqa.jpg和ELO_val目录这不是巧合。TruthfulQA 考察的是模型生成内容是否与事实一致对法律场景尤其关键回复可以不够流畅但不能编造法条和案号。ELO_val 则对应偏好排序让两个版本的模型对同一组问题作答由人工或裁判模型打分再更新 Elo 积分最后产出类似win_rate.png的胜率对比图。我的判断是中文法律大模型不能只看 PPL 或 ROUGE这两项指标都抓不住“引用了错误法条但表述流畅”的问题。因此考虑用 TruthfulQA 做硬性过滤用 ELO 做版本对比的软性排序。要注意 ELO 的裁判提示词会对结果产生很大干扰固定裁判模板、乱序匿名对比是最基本的操作。如果以后自己搭评估集建议覆盖劳动纠纷、民间借贷、婚姻家事等高频案由否则 Elo 涨上去也可能只是在少数题上过拟合。3. 本地部署和 Web 界面跑通 run.sh再改 web.py3.1 先看机器和依赖部署一个 13B 级别的中文法律大模型显存是绕不开的约束。ChatLaw 这类模型用 fp16 推理大概需要 26GB 显存做 4bit 量化后可以降到 12GB 左右。我的建议是16GB 显存适合量化推理24GB 以上再考虑微调不然 OOM 会反复打断调试节奏。资源包里没有看到 requirements.txt不过这不妨碍我们补齐依赖。我的习惯是按这个最小集安装pip install transformers4.30.2 peft0.4.0 accelerate0.21.0 gradio3.41.2 einops sentencepiece版本锁定是有原因的transformers 太新时AutoModelForCausalLM对老格式权重的兼容性会变差经常出现权重加载一半直接报 key 不匹配。gradio 3.x 和 4.x 的 API 差异也较大queue()、launch()参数都不太一样。先按这个组合跑通再逐版本上探更稳妥。3.2 run.sh 里到底写了什么正常发布的工程包里run.sh 一般负责导出环境变量并启动 Web 服务。一个典型的启动脚本如下#!/bin/bash export CUDA_VISIBLE_DEVICES0 export MODEL_PATH./models/chatlaw-13b export PORT7860 python web.py \ --model_path $MODEL_PATH \ --port $PORT \ --max_new_tokens 1024 \ --temperature 0.3脚本很短但参数都值得过一遍。CUDA_VISIBLE_DEVICES指定使用哪块 GPU多卡机器上写错编号会导致模型跑到空闲但显存小的卡上。MODEL_PATH指向合并后的完整模型目录不是 LoRA 适配器目录很多新手在这里翻车。temperature调到 0.3 是为了让法律回答偏向保守避免随机性过大导致法条引用出错。max_new_tokens设 1024 是因为法律回复需要同时包含结论、依据和解释512 通常会截断后半部分。实际跑的时候大概率会遇到两个问题。第一是MODEL_PATH写成相对路径而 run.sh 的执行位置不在工程根目录导致 tokenizer 加载失败。第二是量化代码写法过时比如在from_pretrained里传load_in_8bitTrue但 transformers 版本不支持。我的排查顺序是先跑一条最小加载命令确认权重文件本身没问题再回头查脚本参数。3.3 web.py 的对话循环逻辑web.py 本质上是把模型包装成一个 Gradio 应用核心逻辑可以拆成三段加载模型、构造对话模板、流式返回生成结果。import gradio as gr from transformers import AutoModelForCausalLM, AutoTokenizer model_dir ./models/chatlaw-13b tokenizer AutoTokenizer.from_pretrained(model_dir, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained(model_dir, torch_dtypetorch.float16, device_mapauto) def chat(message, history): # history 是 [(用户, 助手), ...] 列表拼接成模型能看懂的对话模板 prompt build_chat_prompt(message, history) inputs tokenizer(prompt, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokens1024, temperature0.3, top_p0.85, do_sampleTrue, repetition_penalty1.05 ) answer tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokensTrue) return answergenerate 参数里最值得调的是temperature和repetition_penalty。法律场景我一般把temperature放在 0.2 到 0.4 之间repetition_penalty放在 1.03 到 1.05 之间否则模型会在解释法条时反复绕圈。top_p保持 0.85 附近即可不需要和 ChatGPT 那样激进。拼接多轮对话时要注意角色模板LLaMA 系和 ChatGLM 系的 human/assistant 标记不同ChatLaw 这类模型要遵循基座自带的模板不能只把最近的几条消息拼起来否则多轮之后模型会分不清谁在说话。4. 数据改造实战把杂乱的咨询记录变成可微调的语料4.1 清洗与转结构实际项目里拿到的数据大概率不是干净的 instruction/input/output而是客服对话、裁判文书或留言片段。我一般会先写一个脚本做三件事去重、去敏感信息、转指令格式。import json def convert_case_to_sample(case: dict) - dict: raw_q case[question].strip() raw_a case[answer].strip() if len(raw_q) 10 or len(raw_a) 20: return None # 过短样本直接丢弃避免教坏模型 return { instruction: raw_q, input: case.get(context, ), output: raw_a } with open(legal_cases.jsonl, r, encodingutf-8) as fin, \ open(legal_cases_sft.jsonl, w, encodingutf-8) as fout: for line in fin: sample convert_case_to_sample(json.loads(line)) if sample: fout.write(json.dumps(sample, ensure_asciiFalse) \n)这个脚本把自然语言问答映射到训练模板需要的字段同时过滤掉过短样本。注意output字段如果包含法条尽量保持原文引用不要口语化转述否则模型会学成“意思对但法条编号错”。input字段适合放案件背景、当事人关系、争议焦点等结构化信息训练后模型会更习惯用input约束输出范围。4.2 对话长度截断与滑动处理13B 模型的训练上下文一般是 2048 或 4096但法律纠纷描述经常超过这个长度尤其是带判决书摘要的样本。直接从头截断会丢掉结尾的判决依据从尾截断会丢掉事实背景。我常用的办法是保头保尾中间做标记PREFIX_LEN 300 SUFFIX_LEN 700 def trim_long_text(text: str) - str: chars list(text) if len(chars) PREFIX_LEN SUFFIX_LEN: return text return .join(chars[:PREFIX_LEN] [ ...[中间省略]... ] chars[-SUFFIX_LEN:])注意字符截断和 token 截断有差异中文场景下按字符截断通常偏差不大但如果数据里混了大量英文法条名称建议改用 tokenizer 计算长度。多轮对话样本则要先拼成完整文本再截断不能逐轮单独截断否则会丢失跨轮指代信息。4.3 微调时的高频坑位这个环节我踩过的坑大概能列一屏挑四个最常见的说。基座模板不统一训练时用 Ziya 的模板推理时换成别的模板效果立刻下降。模板必须和基座模型严格对应。法条被模型意译这其实是数据问题标注员为了方便把法条改写成白话模型就学会了凭感觉生成而不是引用原文。padding 侧不一致训练时用左 padding生成时用右 paddingbatch 推理会出现严重乱码。统一用padding_sideleft可以解决绝大多数问题。训练 loss 很低但生成依然乱来优先检查验证集是否混入训练数据重复样本太多时模型会背答案而不是学泛化。提示当验证集 loss 和训练集 loss 差得很小但生成结果仍然出现明显错乱时先检查 tokenizer 的 pad_token 是否配置而不是急着调学习率。5. 评估验证与权重合并让模型真正可用前的最后两步5.1 ELO 评估的落地操作ELO_val目录里应该是评估脚本和中间结果。如果你要复现同等对比一个实用的方案是准备 30 到 50 条法律咨询组成的固定测试集然后让旧模型和新模型分别生成再做两两对比。Elo 积分更新函数很简洁def elo_update(ra, rb, score): ea 1 / (1 10 ** ((rb - ra) / 400)) eb 1 - ea k 32 return ra k * (score - ea), rb k * (score - eb)score取 1 表示 A 胜0 表示 A 负0.5 表示平局。每队样本跑 50 轮后看胜率图超过 55% 的新权重才值得替换线上模型。如果只有一两道题的胜率差异基本可以判定是随机波动。5.2 用 MERGE.md 把 LoRA 权重合回基座ChatLaw 这类开源模型经常会以 LoRA 适配器形式发布目的是减小分发体积。MERGE.md讲的就是合回基座的操作。常见做法是用 PEFT 自带脚本python merge_peft_adapter.py \ --base_model ./models/ziya-llama-13b \ --adapter_model ./output_chatlaw_lora \ --output_model ./models/chatlaw-13b合并逻辑是把低秩增量加回原始参数另存为一个完整模型。合并后必须做一致性验证加载合并前的 LoRA 模型和合并后的完整模型输入同一句测试文本确认生成结果完全一致。如果对不上优先检查adapter_config.json里的base_model_name_or_path是否与真实基座路径匹配这个字段错了会导致权重错位。5.3 发布前的一组冒烟测试正式替换模型前我会跑一组只有 10 条的冒烟测试覆盖民法、刑法、劳动法各三道题再加一道完全无关的闲聊看模型会不会被带偏。验证时不要通过 Gradio 前端直接用本地推理接口最小化验证避免前端缓存干扰结果python - PY from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained(./models/chatlaw-13b, device_mapauto) tok AutoTokenizer.from_pretrained(./models/chatlaw-13b) prompt 失业金可以领多久 inputs tok(prompt, return_tensorspt).to(model.device) out model.generate(**inputs, max_new_tokens64, temperature0.3, do_sampleFalse)[0] print(tok.decode(out[inputs.input_ids.shape[1]:], skip_special_tokensTrue)) PY如果闲聊问题被一本正经地回复法律条文先不要重新训练把 generation 的temperature降到 0.2或者在 system prompt 里明确写上“不在知识范围内时礼貌说明无法回答”。这个操作比重新微调便宜得多往往能救回一版模型。本文还有配套的精品资源点击获取 开源法律大模型ChatLaw工程解析：从数据微调到本地部署全流程
简介面向中文法律领域的大模型应用与自然语言处理研究者ChatLaw 中文法律大模型素材包以模型配置、演示与评估为主线浓缩了项目从运行到验证的完整素材。压缩包内共 35 个文件涵盖 JSON/JSONL 配置与数据集、Python/Shell 运行脚本、Markdown 说明文档、LICENSE 协议以及大量 JPG/PNG 框架图、界面截图和演示图片整体仅 7.78MB便于快速下载并按目录梳理模型结构。文档与脚本覆盖模型部署、启动运行、法律概念问答、法律咨询等典型场景同时提供 ELO 评估数据与多阶段演示数据可帮助读者理解中文法律大模型的数据组织、评估方式与落地流程。已有 270 人浏览学习适合具备一定自然语言处理基础、希望快速上手中文法律大模型应用与二次开发的开发者参考使用。1. 一套能直接跑起来的中文法律大模型工程ChatLaw 资源包拆解从文件清单能看到什么demo 数据、web.py、run.sh、MERGE.md、ELO_val、truthfulqa.jpg……这不是一个扔给你权重的压缩包而是把数据、训练、部署、评估串成一条线的完整工程。ChatLaw 的目标不是让你去和 GPT 比闲谈而是解决法律咨询、法条检索、文书生成这类对事实性要求极高的场景。通用大模型在术语上会一本正经地胡说八道领域微调是当前最落地的做法。如果你在做 AI 大模型应用开发或者正在给企业做知识库问答这套资源可以直接作为参考基线先跑通 webui再替换自己的法律数据最后用 ELO 和 TruthfulQA 验证效果。按本地部署大模型的通常路径从数据、部署、微调到评估逐层拆解整个过程不依赖闭源 API。2. 模型侧设计法律领域微调的数据形态与评估依据2.1 基座选择与领域适配的逻辑ChatLaw 没有从零预训练而是在中文能力较强的开源底座上做领域适配这类底座常见的是 Ziya-LLaMA、BELLE 等。为什么这么选法律语料虽然量大但高质量、带专家标注的问答数据很少从头训练一个法律模型成本高且难收敛。站在已有底座上做增量预训练和指令微调能用更少的数据拿到更稳的效果。法律领域与通用闲聊有一个本质区别术语必须保持单一语义。普通对话里“不可抗力”可以口语化成“不能预料的情况”但法律回复里必须严格对应民法中的定义和适用条件。另一个痛点是法条有版本时效训练数据一旦混入已废止条文模型就会以极高的置信度引用错误法条。所以领域适配的重点不是让模型会说话而是让它在限定概念空间里做选择。从资源包的文件结构能看出设计意图demo_data_法律概念.jsonl负责基础概念注入demo_data_法律咨询.jsonl负责用户场景化问答而demo_data_stage2.json则承担更复杂的指令顺应与多轮对话。MERGE.md的存在说明权重很可能是以 LoRA 或类似低秩适配形式发布使用前需要合并回基座模型。对做 AI 大模型应用落地的人来说这套分层数据组织方式比单一大杂烩数据更容易复现和迁移。2.2 三类 demo 数据的结构与用途解压后先别急着跑模型把数据文件打开看几行信息量比 README 大得多。三个数据文件对应三个不同的训练目标数据文件代表样本类型训练阶段典型字段demo_data_法律概念.jsonl名词解释、制度说明领域概念注入instruction / outputdemo_data_法律咨询.jsonl用户场景化提问指令微调instruction / input / outputdemo_data_stage2.json多轮对话、复杂指令指令顺应强化messages / system / tools以法律咨询为例数据行大致长这样{instruction: 我在公司工作半年未签订劳动合同现在被辞退能主张什么赔偿, input: , output: 可以主张未签订劳动合同的二倍工资差额以及违法解除劳动合同的赔偿金。具体标准建议咨询当地劳动争议仲裁委员会并保存工资流水与解除通知作为证据。}每个字段各有用途instruction是用户侧问题input用来放附加背景或参考材料output是标准回复。input不是必填项空字符串表示只有单轮问答。stage2的文件结构会更复杂常见的是类似 OpenAI 的 messages 数组支持 system 角色约束回答风格也支持多轮历史拼接。标注质量直接决定模型上限同一事实换几种问法各写几条比写一百条同质问题有用得多。2.3 事实性评估与偏好排序TruthfulQA 和 ELO 为什么同时出现资源包里同时出现truthfulqa.jpg和ELO_val目录这不是巧合。TruthfulQA 考察的是模型生成内容是否与事实一致对法律场景尤其关键回复可以不够流畅但不能编造法条和案号。ELO_val 则对应偏好排序让两个版本的模型对同一组问题作答由人工或裁判模型打分再更新 Elo 积分最后产出类似win_rate.png的胜率对比图。我的判断是中文法律大模型不能只看 PPL 或 ROUGE这两项指标都抓不住“引用了错误法条但表述流畅”的问题。因此考虑用 TruthfulQA 做硬性过滤用 ELO 做版本对比的软性排序。要注意 ELO 的裁判提示词会对结果产生很大干扰固定裁判模板、乱序匿名对比是最基本的操作。如果以后自己搭评估集建议覆盖劳动纠纷、民间借贷、婚姻家事等高频案由否则 Elo 涨上去也可能只是在少数题上过拟合。3. 本地部署和 Web 界面跑通 run.sh再改 web.py3.1 先看机器和依赖部署一个 13B 级别的中文法律大模型显存是绕不开的约束。ChatLaw 这类模型用 fp16 推理大概需要 26GB 显存做 4bit 量化后可以降到 12GB 左右。我的建议是16GB 显存适合量化推理24GB 以上再考虑微调不然 OOM 会反复打断调试节奏。资源包里没有看到 requirements.txt不过这不妨碍我们补齐依赖。我的习惯是按这个最小集安装pip install transformers4.30.2 peft0.4.0 accelerate0.21.0 gradio3.41.2 einops sentencepiece版本锁定是有原因的transformers 太新时AutoModelForCausalLM对老格式权重的兼容性会变差经常出现权重加载一半直接报 key 不匹配。gradio 3.x 和 4.x 的 API 差异也较大queue()、launch()参数都不太一样。先按这个组合跑通再逐版本上探更稳妥。3.2 run.sh 里到底写了什么正常发布的工程包里run.sh 一般负责导出环境变量并启动 Web 服务。一个典型的启动脚本如下#!/bin/bash export CUDA_VISIBLE_DEVICES0 export MODEL_PATH./models/chatlaw-13b export PORT7860 python web.py \ --model_path $MODEL_PATH \ --port $PORT \ --max_new_tokens 1024 \ --temperature 0.3脚本很短但参数都值得过一遍。CUDA_VISIBLE_DEVICES指定使用哪块 GPU多卡机器上写错编号会导致模型跑到空闲但显存小的卡上。MODEL_PATH指向合并后的完整模型目录不是 LoRA 适配器目录很多新手在这里翻车。temperature调到 0.3 是为了让法律回答偏向保守避免随机性过大导致法条引用出错。max_new_tokens设 1024 是因为法律回复需要同时包含结论、依据和解释512 通常会截断后半部分。实际跑的时候大概率会遇到两个问题。第一是MODEL_PATH写成相对路径而 run.sh 的执行位置不在工程根目录导致 tokenizer 加载失败。第二是量化代码写法过时比如在from_pretrained里传load_in_8bitTrue但 transformers 版本不支持。我的排查顺序是先跑一条最小加载命令确认权重文件本身没问题再回头查脚本参数。3.3 web.py 的对话循环逻辑web.py 本质上是把模型包装成一个 Gradio 应用核心逻辑可以拆成三段加载模型、构造对话模板、流式返回生成结果。import gradio as gr from transformers import AutoModelForCausalLM, AutoTokenizer model_dir ./models/chatlaw-13b tokenizer AutoTokenizer.from_pretrained(model_dir, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained(model_dir, torch_dtypetorch.float16, device_mapauto) def chat(message, history): # history 是 [(用户, 助手), ...] 列表拼接成模型能看懂的对话模板 prompt build_chat_prompt(message, history) inputs tokenizer(prompt, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokens1024, temperature0.3, top_p0.85, do_sampleTrue, repetition_penalty1.05 ) answer tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokensTrue) return answergenerate 参数里最值得调的是temperature和repetition_penalty。法律场景我一般把temperature放在 0.2 到 0.4 之间repetition_penalty放在 1.03 到 1.05 之间否则模型会在解释法条时反复绕圈。top_p保持 0.85 附近即可不需要和 ChatGPT 那样激进。拼接多轮对话时要注意角色模板LLaMA 系和 ChatGLM 系的 human/assistant 标记不同ChatLaw 这类模型要遵循基座自带的模板不能只把最近的几条消息拼起来否则多轮之后模型会分不清谁在说话。4. 数据改造实战把杂乱的咨询记录变成可微调的语料4.1 清洗与转结构实际项目里拿到的数据大概率不是干净的 instruction/input/output而是客服对话、裁判文书或留言片段。我一般会先写一个脚本做三件事去重、去敏感信息、转指令格式。import json def convert_case_to_sample(case: dict) - dict: raw_q case[question].strip() raw_a case[answer].strip() if len(raw_q) 10 or len(raw_a) 20: return None # 过短样本直接丢弃避免教坏模型 return { instruction: raw_q, input: case.get(context, ), output: raw_a } with open(legal_cases.jsonl, r, encodingutf-8) as fin, \ open(legal_cases_sft.jsonl, w, encodingutf-8) as fout: for line in fin: sample convert_case_to_sample(json.loads(line)) if sample: fout.write(json.dumps(sample, ensure_asciiFalse) \n)这个脚本把自然语言问答映射到训练模板需要的字段同时过滤掉过短样本。注意output字段如果包含法条尽量保持原文引用不要口语化转述否则模型会学成“意思对但法条编号错”。input字段适合放案件背景、当事人关系、争议焦点等结构化信息训练后模型会更习惯用input约束输出范围。4.2 对话长度截断与滑动处理13B 模型的训练上下文一般是 2048 或 4096但法律纠纷描述经常超过这个长度尤其是带判决书摘要的样本。直接从头截断会丢掉结尾的判决依据从尾截断会丢掉事实背景。我常用的办法是保头保尾中间做标记PREFIX_LEN 300 SUFFIX_LEN 700 def trim_long_text(text: str) - str: chars list(text) if len(chars) PREFIX_LEN SUFFIX_LEN: return text return .join(chars[:PREFIX_LEN] [ ...[中间省略]... ] chars[-SUFFIX_LEN:])注意字符截断和 token 截断有差异中文场景下按字符截断通常偏差不大但如果数据里混了大量英文法条名称建议改用 tokenizer 计算长度。多轮对话样本则要先拼成完整文本再截断不能逐轮单独截断否则会丢失跨轮指代信息。4.3 微调时的高频坑位这个环节我踩过的坑大概能列一屏挑四个最常见的说。基座模板不统一训练时用 Ziya 的模板推理时换成别的模板效果立刻下降。模板必须和基座模型严格对应。法条被模型意译这其实是数据问题标注员为了方便把法条改写成白话模型就学会了凭感觉生成而不是引用原文。padding 侧不一致训练时用左 padding生成时用右 paddingbatch 推理会出现严重乱码。统一用padding_sideleft可以解决绝大多数问题。训练 loss 很低但生成依然乱来优先检查验证集是否混入训练数据重复样本太多时模型会背答案而不是学泛化。提示当验证集 loss 和训练集 loss 差得很小但生成结果仍然出现明显错乱时先检查 tokenizer 的 pad_token 是否配置而不是急着调学习率。5. 评估验证与权重合并让模型真正可用前的最后两步5.1 ELO 评估的落地操作ELO_val目录里应该是评估脚本和中间结果。如果你要复现同等对比一个实用的方案是准备 30 到 50 条法律咨询组成的固定测试集然后让旧模型和新模型分别生成再做两两对比。Elo 积分更新函数很简洁def elo_update(ra, rb, score): ea 1 / (1 10 ** ((rb - ra) / 400)) eb 1 - ea k 32 return ra k * (score - ea), rb k * (score - eb)score取 1 表示 A 胜0 表示 A 负0.5 表示平局。每队样本跑 50 轮后看胜率图超过 55% 的新权重才值得替换线上模型。如果只有一两道题的胜率差异基本可以判定是随机波动。5.2 用 MERGE.md 把 LoRA 权重合回基座ChatLaw 这类开源模型经常会以 LoRA 适配器形式发布目的是减小分发体积。MERGE.md讲的就是合回基座的操作。常见做法是用 PEFT 自带脚本python merge_peft_adapter.py \ --base_model ./models/ziya-llama-13b \ --adapter_model ./output_chatlaw_lora \ --output_model ./models/chatlaw-13b合并逻辑是把低秩增量加回原始参数另存为一个完整模型。合并后必须做一致性验证加载合并前的 LoRA 模型和合并后的完整模型输入同一句测试文本确认生成结果完全一致。如果对不上优先检查adapter_config.json里的base_model_name_or_path是否与真实基座路径匹配这个字段错了会导致权重错位。5.3 发布前的一组冒烟测试正式替换模型前我会跑一组只有 10 条的冒烟测试覆盖民法、刑法、劳动法各三道题再加一道完全无关的闲聊看模型会不会被带偏。验证时不要通过 Gradio 前端直接用本地推理接口最小化验证避免前端缓存干扰结果python - PY from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained(./models/chatlaw-13b, device_mapauto) tok AutoTokenizer.from_pretrained(./models/chatlaw-13b) prompt 失业金可以领多久 inputs tok(prompt, return_tensorspt).to(model.device) out model.generate(**inputs, max_new_tokens64, temperature0.3, do_sampleFalse)[0] print(tok.decode(out[inputs.input_ids.shape[1]:], skip_special_tokensTrue)) PY如果闲聊问题被一本正经地回复法律条文先不要重新训练把 generation 的temperature降到 0.2或者在 system prompt 里明确写上“不在知识范围内时礼貌说明无法回答”。这个操作比重新微调便宜得多往往能救回一版模型。本文还有配套的精品资源点击获取