简介聚焦中文法律大模型ChatLaw这份《AI大模型应用》资源包面向AI大模型开发者、自然语言处理研究者及法律科技从业者围绕法律知识理解与问答场景系统呈现大模型从数据准备、模型微调到效果评估与部署应用的全链路方案帮助读者快速形成端到端认知。压缩包共35个文件大小约7.78MB文件类型涵盖图片、数据、脚本与文档多张jpg/png展示模型整体框架、Web页面和评测对比结果json/jsonl文件提供法律概念、法律咨询及多组测试数据py与sh脚本包含Web应用与一键运行入口md文档则对方案和模型合并流程进行说明资源结构清晰便于按模块查阅。目前已有270人学习下载内容具有实际参考价值。资源将框架示意图、样例数据、评测结果与可执行脚本整合于一体既适合用作技术调研和方案验证也可直接作为二次开发的基础能显著减少从零收集资料与配置环境的成本是了解中文法律大模型落地应用的有效素材。1. 中文法律大模型应用包里到底有什么先把它当黑匣子拆开看你下载了一份「《AI大模型应用》-中文法律大模型.zip」第一反应大概率是解压、读README、然后跑demo。但这类zip往往不是单个模型文件而是混合体可能包含量化权重、推理脚本、微调代码、甚至一整套带Web界面的工程。直接双击解压或急着跑main.py翻车概率很高。我处理过不少这类法律模型压缩包最常见的问题不是模型不够好而是环境依赖与目录结构没对齐。这篇笔记围绕中文法律大模型从解压到落地讲清楚目录识别、推理、微调、服务化以及排错路径适合拿到zip却不知道怎么跑、或跑通后不知道怎么接入业务的人。2. 解压与目录识别先看清zip里的工程结构再动手2.1 三类常见zip包结构权重包、推理包、完整工程包拿到zip先别急着找模型文件。中文法律大模型相关的zip常见做法是三类打包方式。第一类是纯权重包里面是pytorch_model.bin、config.json、tokenizer相关文件解压后要自己写加载脚本第二类是推理包带requirements.txt和infer.py解压后装依赖就能跑第三类是完整工程包包含训练、微调、推理、前端结构类似一个GitHub仓库的快照。三类包处理方式完全不同识别方法是先看顶层文件列表。用zipinfo列出内容再决定怎么做。如果顶层直接是config.json和权重文件这是纯权重包如果顶层是src、scripts、requirements.txt这是工程包如果只有一堆.rar或.tar.gz则可能是二次压缩要逐层解。另一个值得注意的细节是文件大小一个7B模型的完整权重通常有13GB以上如果zip里只有几百MB说明是量化版或演示版推理效果和完整版会有差距不要被README里的指标迷惑。一个容易踩的坑是zip里的英文目录名干干净净解压到Windows本地后出现中文乱码或路径过长报错尤其是判决文书数据集的目录层级很深时。所以先看列表比先解压更安全。2.2 用Linux命令解压和校验完整性zipinfo、unzip、校验和我一般在Linux服务器上处理这类zip因为后续跑模型也需要GPU环境。先校验完整性再解压是避免读到坏权重文件的底线操作。很多人解压完直接加载模型报错后反复查代码最后才发现是权重文件在传输中损坏白白浪费几个小时。# 查看zip内容不实际解压注意看是否有加密标志和文件层级 zipinfo -l Chinese_Legal_LM.zip | head -50 # 校验文件CRC是否完整损坏的文件会在这里暴露 unzip -t Chinese_Legal_LM.zip | tail -20 # 解压到指定目录保留原始文件名编码 unzip -O UTF-8 Chinese_Legal_LM.zip -d /data/legal_lm命令说明zipinfo -l列出每个文件的压缩前后大小和CRC校验值head限制输出行数适合快速看结构unzip -t做完整性测试输出末尾的OK或错误信息能告诉你zip是否损坏。解压时-O UTF-8指定文件名编码避免中文文件名在Linux下乱码。如果unzip版本老不支持-O换用第2.4节的Python方案。如果遇到zip伪加密unzip -t会报错。伪加密是zip头部的general purpose bit被置位实际数据没有加密unzip按真加密处理就会停下来。常见做法是用Python的zipfile模块强制读取把文件重压一份再去掉加密位。注意这不是破解密码伪加密本来就没有真实密码只是文件头标记异常。真加密的zip只能靠密码解压暴力破解不属于本文讨论范围也不建议碰。如果是在Linux离线环境没有现成的unzip命令常见做法是用Python自带的zipfile模块。Python在大多数服务器上默认存在不需要额外安装兼容性比系统自带的解压工具更稳定。2.3 依赖对齐requirements.txt与conda环境的三个检查点解压后第一步不是跑demo而是对齐依赖。法律大模型常见依赖包括transformers、torch、tokenizers、accelerate、sentencepiece。我见过最多的问题是requirements.txt里写了transformers版本下限但本机torch是CPU版装完GPU用不了。建议用conda建立一个独立环境不要直接装进base存量环境。# 创建Python 3.10环境法律模型对Python版本不挑但3.10兼容性最稳 conda create -n legal_lm python3.10 -y conda activate legal_lm # 先装PyTorch再用pip装其余依赖 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install -r requirements.txt依赖安装有顺序讲究。先装torch再装transformers因为transformers在安装时会探测torch版本决定是否启用某些特性反过来装偶发API不兼容。检查点有三个torch.cuda.is_available()是否为Truetransformers版本是否与模型权重兼容tokenizer是否依赖sentencepiece。法律数据里法条数字和标点符号多分词异常时先怀疑tokenizer版本。如果zip里没有requirements.txt也不要慌。看config.json里的model_type和architecture字段搜一下对应基座模型的官方依赖如果权重目录里有model_index.json里面通常会写pipeline_tag和依赖说明。这三个检查点过了再进入加载模型环节。2.4 用Python解压解决中文文件名乱码与伪加密命令行工具解决不了的问题Python的zipfile基本都能处理。zipfile默认按cp437编码解析文件名而Windows压出来的中文zip通常是gbk编码直接extractall会得到一堆乱码文件名。下面的脚本逐个处理子文件把编码纠正回来同时绕过伪加密标志import zipfile import os src Chinese_Legal_LM.zip dst /data/legal_lm with zipfile.ZipFile(src) as z: for info in z.infolist(): raw info.filename try: # zipfile默认用cp437解码中文文件名要转回gbk filename raw.encode(cp437).decode(gbk) except Exception: filename raw target os.path.join(dst, filename) os.makedirs(os.path.dirname(target), exist_okTrue) with z.open(info) as src_f, open(target, wb) as dst_f: dst_f.write(src_f.read())逻辑说明先尝试把文件名从cp437强行解码为gbk成功就说明是中文Windows压出来的包如果抛异常则保留原始文件名。z.open(info)对伪加密文件也能正常读取因为伪加密没有真正加密数据流。我自己用这个脚本处理过十几个法律模型包基本没失手过。注意如果文件名既有中文又有日文或韩文上面的gbk转换会失败这种极端情况建议直接手动重命名关键目录模型加载只认路径不认文件名是否好看。3. 把中文法律大模型跑起来从加载权重到第一条法律问答3.1 选择加载路径transformers 与 vLLM 的取舍中文法律大模型的推理常见做法是两条路transformers的AutoModelForCausalLM直接加载适合调试和单轮问答vLLM作为推理后端适合批量测试和把模型接成HTTP服务。对单个zip里的demo来说transformers足够如果你要拿法律模型做判决文书批处理或问答评测vLLM能带来3到5倍的吞吐提升但显存占用和安装复杂度也会上升。对比项transformers 直接加载vLLM 加载显存占用高约模型精度的1.2倍低支持PagedAttention吞吐低适合交互调试高适合批量评测安装复杂度低pip即可较高依赖xformers等长文本处理需自己截断自带连续批处理更好适用场景跑通单条demo、看输出服务化、批量推理初次跑通建议用transformers因为报错信息更直观。vLLM对模型结构的兼容性有门槛如果你的法律大模型是基于ChatGLM或Qwen结构vLLM支持良好如果是小众架构先检查官方的模型列表避免装完发现不支持。我踩过一次坑zip里是一个基于LLaMA改架构的法律模型vLLM装好后直接报「KeyError: model type not supported」最后只能退回transformers。3.2 最小推理脚本让模型回答一个法律问题这是整个落地的核心步骤。一个可复现的最小推理脚本如下import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_dir /data/legal_lm/weights tokenizer AutoTokenizer.from_pretrained(model_dir, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_dir, trust_remote_codeTrue, torch_dtypetorch.float16, device_mapauto ).eval() prompt 当事人没有借条只有转账记录能证明借贷关系吗 messages [ {role: user, content: prompt} ] inputs tokenizer.apply_chat_template( messages, return_tensorspt, return_dictTrue ).to(model.device) outputs model.generate( **inputs, max_new_tokens512, do_sampleFalse, top_p0.9 if do_sample else None, temperature0.3 if do_sample else None, repetition_penalty1.05 ) response tokenizer.decode(outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue) print(response)逻辑说明apply_chat_template把用户消息转成模型需要的对话格式这一步是很多翻车现场。现在主流基座模型都内置对话模板直接用API即可不要手工拼“用户…\n助手…”这种旧格式结构不同会导致回答牛头不对马嘴。解码时outputs[0]是整个生成序列inputs[input_ids].shape[1]是输入token数取后面那段才是新生成的内容直接整段解码会把用户的提问再打印一遍。生成参数里法律问答建议do_sampleFalse。贪心解码保证同一问题每次回答一致这是法律业务里很重要的一点给用户解释时不能被随机性打脸。repetition_penalty设到1.05左右因为法律模型容易在判决部分重复“本院认为”。top_p和temperature在关闭采样后不生效但我保留了一个写法方便你临时切到采样模式对比效果。参数说明max_new_tokens控制在512以内法律问答大多在几百字内过长容易让模型漂移到编造内容。temperature在关闭采样后不生效如果开启采样法律场景要低温度0.1到0.3比较稳。device_mapauto让模型自动分布到可用GPU如果你是单卡环境这个参数和直接写devicecuda:0效果相同。3.3 词表和对话模板中文法律问答最常见的两个报错加载模型时最容易撞见的两个报错一个是「tokenizer class not found」一个是「chat template not found」。前者通常发生在权重包里只有tokenizer.model、没有tokenizer_config.json的情况解决方法是找同基座模型的官方tokenizer配置补上或者改用trust_remote_codeTrue从远程代码加载。后者发生在老基座模型上对话模板没有写进配置解决方法是先检查tokenizer.chat_template是否为空为空就退回手动拼模板。if getattr(tokenizer, chat_template, None) is None: prompt f用户{question}\n助手 inputs tokenizer(prompt, return_tensorspt).to(model.device) else: messages [{role: user, content: question}] inputs tokenizer.apply_chat_template(messages, return_tensorspt, return_dictTrue).to(model.device)这个备选方案不是最优但能救命。手动拼模板时注意“用户”和“助手”之间的换行有些模型要求\n有些要求空格报错信息里经常会带一个示例格式照着写就行。法律文本里的特殊字符也值得注意。法条里的“第一条”、“一”、“1.”这些序号如果词表里没有单独token会被切成碎片影响检索和生成质量。判断词表是否够用可以跑一段法条做编码再解码如果还原文本和原文不一致说明分词或词表有问题。常见做法是微调时把法条序号加入词表让模型把“第十六条”当作一个整体token去记忆而不是每次拼碎片。3.4 长文本与显存边界法律文书动辄几千字怎么办法律场景里用户提问不见得长但系统往往要拼上案情摘要或判决书片段再提问。几千字一发prompt阶段就爆显存。两个方向一是在请求侧截断保留事实部分舍弃案号、日期等噪音二是用FlashAttention或xformers降低显存占用。transformers里开启flash_attention需要模型实现支持Qwen和ChatGLM较新版本已经内置老架构还是只能靠截断。如果显存真的不够最省事的方案是量化。把模型用bitsandbytes的4bit加载显存占用能降到原来的四分之一代价是生成速度略慢法律场景下回答质量损失不明显。量化加载只需要改一行model AutoModelForCausalLM.from_pretrained( model_dir, trust_remote_codeTrue, load_in_4bitTrue, device_mapauto )需要提前安装bitsandbytes并在加载前确认GPU驱动支持。4bit加载最常见的坑是bitsandbytes版本和CUDA版本不匹配报错信息会出现「CUDA Setup failed」解决方法是按官方表格安装对应版本。这里有个血泪经验4bit模型不要和vLLM混合用vLLM不支持bitsandbytes的4bit权重直接加载需要先合并或转成AWQ格式否则会报「illegal memory access」。4. 用法律数据微调从通用模型变成能引用法条的模型4.1 法律指令数据长什么样问答对、法条引用、文书结构化zip里如果带了微调数据目录名通常是data或dataset格式多为json或jsonl。中文法律大模型微调数据的典型结构是三种问答对、带法条引用的问答对、结构化判决文书。问答对最简单就是“问题-答案”带引用的会在答案里标注依据法条结构化文书则是把起诉书、判决书拆成段落和字段。数据质量决定模型输出质量网络公开的法律问答数据噪音大常见做法是自己清洗。一个可用的数据样例[ { instruction: 借款纠纷中只有转账记录没有借条能否认定借贷关系, input: , output: 可以认定。根据《最高人民法院关于审理民间借贷案件适用法律若干问题的规定》第十六条原告仅依据金融机构的转账凭证提起民间借贷诉讼被告抗辩转账系偿还双方之前借款或其他债务的被告应当对其主张提供证据证明。 } ]这种结构可以直接被LLaMA-Factory和大多数微调框架识别。字段命名不同有的用prompt和completion有的用conversations需要按框架要求转换。关键点在法律问答里output不能只给结论要给出法条名称和条文序号这样微调出来的模型才具备“援引法条”的习惯。数据清洗有两个必须做的动作。第一是数字归一化把“第一百零六条”统一成“第一百零六条”这种全角格式或者全部转半角不要混用第二是去重法律问答网站上大量问题措辞不同但答案完全一样直接用这些数据训练会让模型过拟合到少数高频答案。我一般会用simhash对instruction做去重相似度超过0.9的只保留一条。4.2 用LLaMA-Factory做LoRA微调的最小配置微调中文法律大模型常见做法是LoRA。全参数微调需要至少四张24G显卡LoRA一张24G卡就能跑7B到13B模型。LLaMA-Factory是目前最省事的工具支持多数中文基座。以下是YAML配置model_name_or_path: /data/legal_lm/weights template: qwen stage: sft finetuning_type: lora lora_rank: 16 lora_alpha: 32 dataset: legal_qa cutoff_len: 2048 learning_rate: 5.0e-5 num_train_epochs: 3.0 per_device_train_batch_size: 4 gradient_accumulation_steps: 4 lr_scheduler_type: cosine warmup_ratio: 0.03 logging_steps: 10 save_steps: 500 output_dir: outputs/legal_lora参数说明cutoff_len2048是法律文本的一个平衡点法条引用和案情描述经常超过1024太短会截断依据太长则显存压力大。lora_rank16和lora_alpha32是业内常见配置rank越大模型表达能力越强但过拟合风险也大法律数据通常在几万条以内rank8到16足够。learning_rate5e-5是中文SFT的标准起点如果loss震荡就降到2e-5。启动训练的命令llamafactory-cli train configs/legal_lora.yaml训练日志里重点看两个指标loss是否持续下降以及eval_loss与train_loss的差距。法律数据如果混入大量相似的民间借贷问题模型容易过拟合表现为eval_loss不降反升。常见做法是数据里去重或者把相似问题合并成模板降低重复分布。如果数据集本身只有几千条epoch可以提到3到4但要配合早停避免模型死记硬背。4.3 关键参数学习率、max_seq_len、lora_rank对法律文本的影响参数法律场景推荐影响learning_rate2e-5 ~ 5e-5过高导致法条数字错乱过低收敛慢cutoff_len2048过短截断法条引用过长显存压力大lora_rank8 ~ 16过大过拟合过小表达力不够num_train_epochs2 ~ 3法律数据量少多轮容易背题warmup_ratio0.03 ~ 0.05稳定训练前期损失法律场景里学习率的影响比想象中大。学习率偏高模型会在数字上翻车比如把“第十六条”改写成“第六十条”学习率偏低模型学会的是输出格式但不会真正记忆条文。如果你的训练集里有大量法条原文建议先做一遍数字替换清洗把常用数字统一成阿拉伯数字减少模型对数字的混淆。cutoff_len的选择要看你实际跑过的数据分布。我统计过一份民间借贷问答集80%的答案长度在800字以内但带上案情摘要后平均1400字所以2048够用。如果你的业务涉及审查合同动辄5000字的合同原文那就别指望截断直接把模型切到长文本模式并调大显存否则训练等于白做。4.4 合并LoRA权重与导出一个可部署的模型目录训练完的LoRA权重只是适配器推理时要先合并回主干模型。LLaMA-Factory提供了导出命令llamafactory-cli export \ --model_name_or_path /data/legal_lm/weights \ --adapter_name_or_path outputs/legal_lora \ --template qwen \ --finetuning_type lora \ --export_dir /data/legal_lm/merged \ --export_size 4 \ --export_legacy_format false导出命令说明adapter_name_or_path指定训练出的LoRA目录export_dir是合并后的模型输出位置。合并过程中会做量化重排export_size4表示按4GB分片存储方便后续移动复制。这里有个后悔药级别的建议合并前先备份LoRA权重合并动作不可逆如果合完发现导出的模型质量异常还能回来调整参数重新合并。合并完成后直接用第3章的推理脚本把model_dir改到/merged即可。如果合并后模型回答风格异常先检查模板是否一致很多现象是导出时template配错导致推理时对话格式不对。另一个验证方式是把合并后的模型加载起来问一遍训练集里的经典题目再问一遍没见过的新题对比两个答案的长度和法条引用密度能大概判断模型是学会了还是背题了。5. 法律大模型落地避坑从zip到法律问答服务的5个常见问题5.1 zip伪加密和损坏解压到一半报错现象unzip -t提示CRC错误或权限错误文件解压出来不完整模型权重文件只有几百MB就停了。原因这类zip在打包时压了伪加密位或者下载过程中文件损坏。伪加密会在zip头部标记需要密码但数据本身没有加密unzip会误判为加密文件拒绝解压。损坏则是网络传输或存储介质问题。解决先用Python的zipfile模块读取伪加密的情况下zipfile会正常解压损坏的情况下zipfile会报错并指出哪个子文件坏了。如果是伪加密用第2.4节的脚本重新压一份解压后就可以正常使用。如果extractall也报错说明文件确实损坏需要重新下载。注意tar、7z等二次压缩包里的子文件损坏unzip不会报要解压完再对模型文件做一次md5校验和README里给的校验和比对。5.2 中文路径和模型名乱码导致加载失败现象AutoTokenizer.from_pretrained报错找不到模型但ls看文件明明在。错误信息里出现的路径是一串乱码比如“鏉冮噸”这种。原因zip内的中文文件名在解压时被转成了cp437编码Linux终端显示时又按UTF-8解码两级偏差叠加路径彻底对不上。解决解压后不要用GUI拖动用命令行重命名或直接改model_dir到一个全英文路径。我惯用的处理是把所有模型权重目录统一命名为weights数据目录命名为data全英文小写。这样既避免后续服务化时路径转义的坑也方便写自动化脚本。路径里有空格和括号的zip包在shell里调用时要加引号不如一开始就重命名干净。5.3 显存不足OOM发生在prompt拼接阶段现象加载模型时显存刚好够但一生成就报CUDA out of memory。有时加载完还能跑通一次多问几个问题后突然崩了。原因generate阶段要缓存KV tensorprompt长度越长缓存越大。如果服务里直接把用户原文和历史消息全部拼进prompt几轮对话后显存就会爆。解决先用tokenizer把prompt编码查看input_ids的长度如果超过1000考虑截断或增量生成。另一个办法是降低per_device_batch_size到1并开启torch.inference_mode()减少显存碎片import torch with torch.inference_mode(): outputs model.generate(**inputs, max_new_tokens512)还有一个容易被忽略的点modelscope或huggingface下载缓存目录会占空间不影响显存但影响加载速度。如果OOM发生在load阶段而不是generate阶段先检查transformers版本和device_map老版本transformers的device_mapauto在某些卡上会把embedding放到CPU拖慢生成。5.4 法律幻觉模型编造法条和判决结果现象回答头头是道但引用的法条号是编的或判决金额和事实对不上。把“第十六条”说成“第六十条”甚至编一个不存在的司法解释名称。原因通用基座或小模型没有真正记忆法律条文靠生成惯性凑出一条“看似合理”的答案。这个现象在7B和13B模型上尤其明显参数量不够时模型倾向于填一个顺口的数字进去。解决微调数据里强制每条输出都带法条引用推理时开启do_sampleFalse降低随机性并把max_new_tokens控制住。如果业务要求高还要加一层检索增强把真实法条检索后拼进prompt而不是让模型凭记忆生成。我的做法是准备一个法律条文数据库用户提问后先用BM25检索相关条文把条文原文和问题一起交给模型回答时法条命中率能提高一大截。给新人的一个检验技巧把模型回答里引用的法条号提取出来用正则或直接搜法律文本库确认存在且内容匹配。这一步看起来麻烦但它能帮你快速判断模型到底是学会了还是背了个空壳。5.5 对话模板不一致导致回答变成「机器翻译」现象模型输出的内容中文通顺但没有多轮对话记忆或者第一句多了一个“用户”。有时回答开头是“关注: ”或“助手: ”这种杂音。原因手工拼模板和训练时模板不一致。训练用的模板是qwen推理时却用了ChatGLM的手工格式模型无法正确识别指令边界。解决检查tokenizer_config.json里的chat_template尽量用apply_chat_template方法不要自己拼。涉及多轮问答时要把历史消息以列表形式传给apply_chat_templatemessages [ {role: user, content: 欠条丢失了怎么办}, {role: assistant, content: 可以主张以转账记录和聊天记录佐证必要时申请法院调取证据。}, {role: user, content: 法院会支持吗} ] inputs tokenizer.apply_chat_template(messages, return_tensorspt, return_dictTrue).to(model.device)这部分的报错信息经常藏在生成的前几个token里如果回答开头是“关注: ”多半是模板没走对。另一个排查方式是打印inputs的input_ids前20个token对照词表看一下是不是正确的系统提示词。多轮场景里history截断策略也很重要只保留最近两轮不然prompt会无限膨胀。6. 把模型变成一个小服务FastAPI封装与验证6.1 封装一个带流式输出的法律问答接口模型跑通后最终要接入业务。我常用的做法是用FastAPI包一层提供HTTP接口内部调用transformers的generate。以下是一个最小服务from fastapi import FastAPI, Request from pydantic import BaseModel import uvicorn, torch from transformers import AutoModelForCausalLM, AutoTokenizer app FastAPI() model_dir /data/legal_lm/merged tokenizer AutoTokenizer.from_pretrained(model_dir, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained(model_dir, trust_remote_codeTrue, torch_dtypetorch.float16, device_mapauto).eval() class QARequest(BaseModel): question: str max_new_tokens: int 512 app.post(/legal/qa) def legal_qa(req: QARequest): messages [{role: user, content: req.question}] inputs tokenizer.apply_chat_template(messages, return_tensorspt, return_dictTrue).to(model.device) with torch.inference_mode(): outputs model.generate(**inputs, max_new_tokensreq.max_new_tokens, do_sampleFalse, repetition_penalty1.05) answer tokenizer.decode(outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue) return {question: req.question, answer: answer} if __name__ __main__: uvicorn.run(app, host0.0.0.0, port8000)接口逻辑说明POST /legal/qa接收question返回answer。这里刻意没做多轮对话法律问答服务大多数是单轮咨询多轮会引入上下文管理复杂度优先把单轮质量做稳。uvicorn的host设0.0.0.0是为了内网其他服务调用端口按需修改。生产环境建议去掉debug模式并加一层鉴权。6.2 验证方法用真实法条题目做回归测试服务上线前我会准备一组固定测试题覆盖民间借贷、婚姻财产、劳动争议、合同违约和刑事量刑五个方向每个方向20道题。测试题目不要用训练集里的要用真实法律咨询网站的公开问答防止模型背题。验证命令curl -X POST http://127.0.0.1:8000/legal/qa \ -H Content-Type: application/json \ -d {question: 公司拖欠工资三个月员工可以直接离职并要求赔偿吗, max_new_tokens: 512}回归测试我建议写成脚本批量跑完后人工抽检。重点看三点回答是否引用具体法条且条号正确焦点问题是否直接回答还是绕圈子同一问题重复问两次输出是否一致。法律场景里一致性很重要随机采样会让同一个问题每次答案都不同所以我坚持把do_sample设为False作为默认。我自己的习惯是留一份标准答案集每次微调完都跑一遍回归把准确率写到模型目录的README里后续换参数或换数据都有对比依据。这条路从zip到服务走完基本就能判断这个模型值不值得投入希望帮到你。本文还有配套的精品资源点击获取