拓冰网站定制 
简介《AI大模型应用》-中文法律大模型.zip 是一份针对中文法律场景的大模型实战资源包围绕ChatLaw这一面向法律领域的专用大模型整理适合正在入门AI大模型应用、特别是法律智能问答与自然语言处理方向的开发者、研究者和法律科技从业者。压缩包共35个文件总大小约7.78MB构成上兼顾展示、数据、脚本与文档jpg/png/jpeg图片用于呈现模型总体框架、交互界面与评测结果json/jsonl文件提供法律概念、法律咨询等演示数据py/sh脚本可辅助启动本地演示环境md与license文件则交代了技术说明与使用许可。目前已有270人学习。资源完整保留了ChatLaw的核心素材包括框架图、运行截图、示例数据、启动脚本以及说明文档读者既能借此快速把握模型结构、接口与调用流程也可直接在本地运行演示加深理解是进入中文法律大模型应用领域非常实用的参考资料。1. 中文法律大模型拆开 zip 之前先看清模型边界一个法务团队拿到这份「《AI大模型应用》-中文法律大模型.zip」时第一反应通常是解压、双击、开始提问。但等真正跑起来才发现权重文件只占整个工作量的三成剩下的功夫全耗在「怎么让模型不乱编法条」「怎么把几百页合同切得让召回更准」这类工程问题上。这类压缩包的核心价值不是算法发明而是把「中文法律领域的数据清洗、指令微调、评测集」打包成了一份可以直接落地的资产法条问答、合同风险识别、裁判文书要点提取都在它的射程内。这里不展开某个具体模型的训练过程就沿着「解压 zip → 本地部署 → 检索增强 → 验收」这条线把中文法律大模型从压缩包变成可对话应用的最短路径讲透。2. 中文法律大模型的模型文件构成与量化选型2.1 压缩包里究竟装了什么从zipfile到config.json拿到 zip 先别急着解压先看一眼里面的文件类型分布这比任何 README 都诚实。import zipfile z zipfile.ZipFile(AI_law_model.zip) for info in z.infolist(): print(f{info.filename:60s} {info.file_size:12,} bytes)输出里通常会有几类东西model-00001-of-0000X.safetensors这样的权重分片、config.json、tokenizer.json、tokenizer_config.json、generation_config.json以及一小段README.md或example.py。config.json是第一个要看的文件里面写着model_type、hidden_size、num_hidden_layers、max_position_embeddings这几项直接决定模型的规模上限和上下文窗口。python -c import json; cjson.load(open(config.json)); print(c[model_type], c[max_position_embeddings])如果max_position_embeddings只有 4096说明模型不支持长合同如果超过 32768说明训练时就做了长文本扩展可以直接喂整份合同代价是显存和生成速度。现在国产开源基座的 chat 版普遍把 RoPE 底座扩展到 32K 以上但真正用起来上下文长度不是越大越好——长上下文会让注意力计算呈平方级上涨法律问答这类任务通常 8K 就足够覆盖判决书和合同正本。解压时遇到error read zip archive先别怀疑工具。这个报错九成是下载截断导致的常见于从网盘拉取大文件、中途断链再用断点续传工具拼回来的场景。处理方式很固定先unzip -t AI_law_model.zip测完整性测不过就重新下载分卷分卷包要zip -s 0 AI_law_model.z01 --out full.zip先合并再测。重新下载后用 7-Zip 的「测试压缩包」功能复测一次别用那些声称能修复 zip 的第三方工具它们对模型包里动辄几 GB 的 safetensors 分片基本无能为力。2.2 base、chat 与法律微调三层模型之间的界限法律大模型和通用大模型的关系一句话能讲清底座负责「会说话」chat 版负责「听话」法律微调版负责「说对」。法律语料在预训练语料里占比极低通用模型对「违约金酌减规则」「格式条款的提示说明义务」这类问题只能给出泛泛而谈的答案甚至会把刑法和民法条款混在一起。中文法律大模型多数是在 Qwen 或同类开源基座的 chat 版本上用法条、裁判文书、司法解释做增量预训练和指令微调得到的。这里有个选型边界要分清如果只是做法条关键词检索加摘要通用 7B 模型加提示词就够了但如果要处理「合同里这条是否违反效力性强制性规定」这种需要法理判断的问题必须上领域微调模型。判断压缩包里是不是真的做过法律微调不用翻训练日志直接问两句区分度足够的问题一个是开放题「什么是格式条款」另一个是检索题「民法典第五百八十五条规定的违约金调整原则是什么」。只做了通用对齐的模型第二问大概率会引用错误的条文编号——这是法律大模型评测里最常见的失败模式。2.3 量化等级对照显存、速度与法律条文保真度如何权衡模型权重用 FP16 还是 INT4 保存直接影响你能不能在单张消费级显卡上跑起来。以常见的 7B 模型为例FP16 权重约 14GBQ4_K_M 量化后约 4.4GB但推理时要额外留出 KV cache 和激活内存所以实际显存需求要看「权重量化 上下文长度」两个维度。量化格式权重大小7B 约建议显存法律条文保真度适用场景FP16约 14GB24GB最高法条引用要求极高的离线批处理Q8_0约 7.2GB12GB高单卡推理、长上下文问答Q4_K_M约 4.4GB8GB中偏高开发调试、轻量演示Q3_K_S约 3.3GB6GB中低资源验证不建议正式用法律场景对数字和法条编号极其敏感Q4 与 FP16 的差距平时看不出来一到「第五百八十五条」这类长数字序列上就容易丢精度。我的习惯是正式服务至少用 Q8开发调试用 Q4_K_M一旦发现召回和生成结果「莫名其妙地变笨」先把量化等级提一档而不是调提示词。量化格式这块网盘上的 zip 包经常自带不同精度的 GGUF 分卷解压后要多看一眼文件后缀q4_k_m.gguf和q8_0.gguf别搞混。另外用压缩工具直接打开 GGUF 看文件列表没问题但别在压缩包内直接取单分卷来部署分卷不齐会导致 GGUF header 里的 metadata 对不上加载时报 tensor size mismatch这一类报错和量化本身无关是分卷合并出错。3. 用 Ollama 本地部署中文法律大模型最小命令3.1 解压、完整性校验与目录规划拿到 zip 后的第一步不是跑模型而是把文件放到一个固定的模型根目录下并做一次完整性校验。mkdir -p ~/models/law-model cd ~/models unzip -q AI_law_model.zip -d law-model ls -lh law-model sha256sum law-model/*.safetensors建议顺手跑一次unzip -t AI_law_model.zip确认 zip 结构完整。sha256sum的用途是对照发布方给的 checksums 文件没有官方校验值的时候至少记录下第一次运行时的哈希方便以后排查是不是模型文件被意外改动过。这一步对法律模型尤为重要因为被恶意替换的模型可以做到「闲聊正常、法律咨询夹带私货」。3.2 把 safetensors 转成 GGUF两种常见路径zip 里的常见格式是 safetensors而 Ollama 使用的是 GGUF。转换路径有两条一条是直接让 Ollama 导入 safetensors另一条是先转成 GGUF 再写 Modelfile。我常用第二条因为可控性强。如果压缩包本身就是 Ollama 导出格式内含.gguf和 Modelfile部署只需要三行命令ollama serve # 先确认守护进程在跑 ollama create law-agent -f Modelfile ollama run law-agent 民法典第五百八十五条的违约金规则是什么ollama create会读 Modelfile 里的FROM字段指向的本地 GGUF 文件把它注册成一个名为law-agent的模型。名字可以带命名空间例如internal/law-agent方便团队内区分版本。如果是 safetensors 权重常见做法是先转换再到 Ollamapip install transformers python -m transformers.llm.convert_safetensors_to_gguf.py --model law-model --output law-model.gguf --quantize q8 ollama create law-agent -f Modelfile注意命令里的--quantize参数不是所有模型都支持不支持时就生成 FP16 的 GGUF 再交给ollama create在 Modelfile 里用PARAMETER指定量化反而更灵活。对应的 Modelfile 长这样FROM ./law-model.gguf PARAMETER temperature 0.2 PARAMETER top_p 0.8 PARAMETER num_ctx 8192 SYSTEM 你是中文法律助手。回答法律问题时必须优先引用你检索到的法条原文无法确认的法条编号明确回答无法确认。temperature 0.2是法律问答的关键法律生成任务的随机性必须压到极低才能避免同一个问题两次回答引用不同条款。num_ctx 8192决定上下文窗口模型加载后显存占用会随它线性增长别贪大。3.3 本地部署配置的显存推算与并发控制给出一个快速估算方法权重量化大小 num_ctx * 层数 * 头数 * 2byte约等于显存下限。实际跑起来时直接看ollama ps和nvidia-smi更准确。ollama ps # 查看已加载模型的内存占用和上下文预算 nvidia-smi --query-gpumemory.used,memory.total --formatcsv如果并发请求多设置环境变量OLLAMA_NUM_PARALLEL1保持单请求串行否则多个并发请求会各开一份 KV cache显存瞬间翻倍。这也是「AI 大模型本地部署配置」里最常见的翻车点。注意num_ctx改大后ollama ps显示的进程内存会明显上升这是正常的。如果出现cuda out of memory优先降num_ctx而不是换更小量化。4. 用 RAG 把法律知识库接进 AI 大模型应用4.1 硬记不如检索法律场景为什么绕不开 RAG有一个很诱人的简化方案把整本民法典塞进上下文。但上下文 8192 个 token 最多容纳约三万字民法典有十几万条即使长文本模型也装不下全部法条。而且法条会修订模型权重里没有「当前生效版本」的概念——2021 年施行的民法典和相关司法解释更新模型训练数据是固定的。RAG 的价值就体现在这里先检索再生成让模型只在召回的证据上作答。常见技术栈是 LangChain或自己组合 embedding 模型和向量库加 OllamaEmbeddings 加 Chroma。法律场景的「查得准」取决于两件事切分是否尊重法律文本结构以及检索 top_k 是否够用。4.2 法律文本的分块策略按「条」而不是按「字数」固定 500 字切分对新闻类文本没问题对法律文本就是灾难。法律法规的最小引用单位是「条第款」一条可能只有几十字也可能长到几百字按固定窗口切分会把一条完整的规则切成两半检索时天然丢失一半信息。我一般按条切用正则把「第X条」作为切分边界import re def split_law_by_article(text: str) - list[str]: articles re.split(r(?第[一二三四五六七八九十百零\d]条), text) return [a for a in articles if len(a.strip()) 0] def chunks_by_article(text: str, max_chars: int 600) - list[dict]: docs [] for idx, article in enumerate(split_law_by_article(text)): if len(article) max_chars: docs.append({id: idx, text: article}) else: sub_parts re.split(r(?[。]), article) for j, part in enumerate(sub_parts): docs.append({id: f{idx}-{j}, text: part}) return docs代码逻辑先用正向零宽断言在「第X条」前切开把每条作为独立文档再对单条超长的条款按句号二次切分。id里带父条款编号是为了后面返回结果时能拼回「本判决依据第 X 条第 Y 款」这类可追溯的引用格式。4.3 检索 生成一条龙的执行代码from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain_community.llms import Ollama from langchain_core.prompts import PromptTemplate from langchain_core.runnables import RunnablePassthrough emb OllamaEmbeddings(modelbge-m3) vectordb Chroma.from_documents(embeddingemb, documentsdocs, persist_directory./law_db) retriever vectordb.as_retriever(search_kwargs{k: 4}) llm Ollama(modellaw-agent, temperature0.2, num_ctx8192) prompt PromptTemplate.from_template( 你是一个严谨的中文法律助手。请仅根据【参考条文】回答不要引用未给出的法条。 【参考条文】 {context} 【问题】 {question} 【回答要求】先给出结论再列出条文编号和原文关键词。 ) rag_chain {context: retriever, question: RunnablePassthrough()} | prompt | llm print(rag_chain.invoke(合同约定的违约金过高法院会如何处理))检索参数k4是经验值法律场景中 top_1 召回的法条往往不够top_4 能覆盖多个上位法条款超过 8 之后噪音条文会稀释生成质量。OllamaEmbeddings用中文 embedding 模型bge-m3对「违约金」「格式条款」这类法律术语的相似度区分比通用英文 embedding 好得多。5. 部署后的验收清单从 zip 报错排错到五连法条测试5.1 解压验证与路径安全排掉最蠢的坑有一种流传很广的说法模型 zip 包有密码要用 zip 压缩包密码破解工具或 zip 密码移除工具解开。实际情况是——正规发布的模型包不会加密。绑定密码的模型包反而要警惕它常见于二手分发渠道无法校验原始哈希。与其花时间研究密码工具不如重新到官方渠道拿分卷包并对比 SHA256。若压缩包里有../../路径条目解压时要盯紧避免路径穿越覆盖掉同级目录的代码文件。5.2 五连法条引用测试与运行健康检查用一套固定五问集做每日回归条款引用、合同风险点、错误条文拒答、上下文稳定性、性能基线。五问全过才能算当次部署有效。测试维度验证方式通过标准条款引用问「违约金酌减的请求由谁提出」回答中出现正确的条文号合同风险给一段含「单方解除权」条款的合同指出该条款可能的无效情形拒答能力问「未满十八岁转让合同是否当然无效」不编造明确说需要更多事实上下文稳定性粘贴 3000 字合同后连续问三个问题回答不前后矛盾性能基线curl测首 token 时延单并发首 token 小于 2 秒视硬件最后贴一条可放进 CI 的最小健康检查命令curl -s http://localhost:11434/api/generate \ -d {model:law-agent,prompt:民法典第五百八十五条规定的违约金调整规则,stream:false} \ | python -c import json,sys; rjson.load(sys.stdin); print(OK if 违约金 in r[response] else CHECK)这条命令把 Ollama 的原生/api/generate接口当作探针如果回答里没出现「违约金」关键词直接打印CHECK让部署流水线在模型退化时尽早发现异常。本文还有配套的精品资源点击获取 中文法律大模型本地部署：从zip到可对话应用
简介《AI大模型应用》-中文法律大模型.zip 是一份针对中文法律场景的大模型实战资源包围绕ChatLaw这一面向法律领域的专用大模型整理适合正在入门AI大模型应用、特别是法律智能问答与自然语言处理方向的开发者、研究者和法律科技从业者。压缩包共35个文件总大小约7.78MB构成上兼顾展示、数据、脚本与文档jpg/png/jpeg图片用于呈现模型总体框架、交互界面与评测结果json/jsonl文件提供法律概念、法律咨询等演示数据py/sh脚本可辅助启动本地演示环境md与license文件则交代了技术说明与使用许可。目前已有270人学习。资源完整保留了ChatLaw的核心素材包括框架图、运行截图、示例数据、启动脚本以及说明文档读者既能借此快速把握模型结构、接口与调用流程也可直接在本地运行演示加深理解是进入中文法律大模型应用领域非常实用的参考资料。1. 中文法律大模型拆开 zip 之前先看清模型边界一个法务团队拿到这份「《AI大模型应用》-中文法律大模型.zip」时第一反应通常是解压、双击、开始提问。但等真正跑起来才发现权重文件只占整个工作量的三成剩下的功夫全耗在「怎么让模型不乱编法条」「怎么把几百页合同切得让召回更准」这类工程问题上。这类压缩包的核心价值不是算法发明而是把「中文法律领域的数据清洗、指令微调、评测集」打包成了一份可以直接落地的资产法条问答、合同风险识别、裁判文书要点提取都在它的射程内。这里不展开某个具体模型的训练过程就沿着「解压 zip → 本地部署 → 检索增强 → 验收」这条线把中文法律大模型从压缩包变成可对话应用的最短路径讲透。2. 中文法律大模型的模型文件构成与量化选型2.1 压缩包里究竟装了什么从zipfile到config.json拿到 zip 先别急着解压先看一眼里面的文件类型分布这比任何 README 都诚实。import zipfile z zipfile.ZipFile(AI_law_model.zip) for info in z.infolist(): print(f{info.filename:60s} {info.file_size:12,} bytes)输出里通常会有几类东西model-00001-of-0000X.safetensors这样的权重分片、config.json、tokenizer.json、tokenizer_config.json、generation_config.json以及一小段README.md或example.py。config.json是第一个要看的文件里面写着model_type、hidden_size、num_hidden_layers、max_position_embeddings这几项直接决定模型的规模上限和上下文窗口。python -c import json; cjson.load(open(config.json)); print(c[model_type], c[max_position_embeddings])如果max_position_embeddings只有 4096说明模型不支持长合同如果超过 32768说明训练时就做了长文本扩展可以直接喂整份合同代价是显存和生成速度。现在国产开源基座的 chat 版普遍把 RoPE 底座扩展到 32K 以上但真正用起来上下文长度不是越大越好——长上下文会让注意力计算呈平方级上涨法律问答这类任务通常 8K 就足够覆盖判决书和合同正本。解压时遇到error read zip archive先别怀疑工具。这个报错九成是下载截断导致的常见于从网盘拉取大文件、中途断链再用断点续传工具拼回来的场景。处理方式很固定先unzip -t AI_law_model.zip测完整性测不过就重新下载分卷分卷包要zip -s 0 AI_law_model.z01 --out full.zip先合并再测。重新下载后用 7-Zip 的「测试压缩包」功能复测一次别用那些声称能修复 zip 的第三方工具它们对模型包里动辄几 GB 的 safetensors 分片基本无能为力。2.2 base、chat 与法律微调三层模型之间的界限法律大模型和通用大模型的关系一句话能讲清底座负责「会说话」chat 版负责「听话」法律微调版负责「说对」。法律语料在预训练语料里占比极低通用模型对「违约金酌减规则」「格式条款的提示说明义务」这类问题只能给出泛泛而谈的答案甚至会把刑法和民法条款混在一起。中文法律大模型多数是在 Qwen 或同类开源基座的 chat 版本上用法条、裁判文书、司法解释做增量预训练和指令微调得到的。这里有个选型边界要分清如果只是做法条关键词检索加摘要通用 7B 模型加提示词就够了但如果要处理「合同里这条是否违反效力性强制性规定」这种需要法理判断的问题必须上领域微调模型。判断压缩包里是不是真的做过法律微调不用翻训练日志直接问两句区分度足够的问题一个是开放题「什么是格式条款」另一个是检索题「民法典第五百八十五条规定的违约金调整原则是什么」。只做了通用对齐的模型第二问大概率会引用错误的条文编号——这是法律大模型评测里最常见的失败模式。2.3 量化等级对照显存、速度与法律条文保真度如何权衡模型权重用 FP16 还是 INT4 保存直接影响你能不能在单张消费级显卡上跑起来。以常见的 7B 模型为例FP16 权重约 14GBQ4_K_M 量化后约 4.4GB但推理时要额外留出 KV cache 和激活内存所以实际显存需求要看「权重量化 上下文长度」两个维度。量化格式权重大小7B 约建议显存法律条文保真度适用场景FP16约 14GB24GB最高法条引用要求极高的离线批处理Q8_0约 7.2GB12GB高单卡推理、长上下文问答Q4_K_M约 4.4GB8GB中偏高开发调试、轻量演示Q3_K_S约 3.3GB6GB中低资源验证不建议正式用法律场景对数字和法条编号极其敏感Q4 与 FP16 的差距平时看不出来一到「第五百八十五条」这类长数字序列上就容易丢精度。我的习惯是正式服务至少用 Q8开发调试用 Q4_K_M一旦发现召回和生成结果「莫名其妙地变笨」先把量化等级提一档而不是调提示词。量化格式这块网盘上的 zip 包经常自带不同精度的 GGUF 分卷解压后要多看一眼文件后缀q4_k_m.gguf和q8_0.gguf别搞混。另外用压缩工具直接打开 GGUF 看文件列表没问题但别在压缩包内直接取单分卷来部署分卷不齐会导致 GGUF header 里的 metadata 对不上加载时报 tensor size mismatch这一类报错和量化本身无关是分卷合并出错。3. 用 Ollama 本地部署中文法律大模型最小命令3.1 解压、完整性校验与目录规划拿到 zip 后的第一步不是跑模型而是把文件放到一个固定的模型根目录下并做一次完整性校验。mkdir -p ~/models/law-model cd ~/models unzip -q AI_law_model.zip -d law-model ls -lh law-model sha256sum law-model/*.safetensors建议顺手跑一次unzip -t AI_law_model.zip确认 zip 结构完整。sha256sum的用途是对照发布方给的 checksums 文件没有官方校验值的时候至少记录下第一次运行时的哈希方便以后排查是不是模型文件被意外改动过。这一步对法律模型尤为重要因为被恶意替换的模型可以做到「闲聊正常、法律咨询夹带私货」。3.2 把 safetensors 转成 GGUF两种常见路径zip 里的常见格式是 safetensors而 Ollama 使用的是 GGUF。转换路径有两条一条是直接让 Ollama 导入 safetensors另一条是先转成 GGUF 再写 Modelfile。我常用第二条因为可控性强。如果压缩包本身就是 Ollama 导出格式内含.gguf和 Modelfile部署只需要三行命令ollama serve # 先确认守护进程在跑 ollama create law-agent -f Modelfile ollama run law-agent 民法典第五百八十五条的违约金规则是什么ollama create会读 Modelfile 里的FROM字段指向的本地 GGUF 文件把它注册成一个名为law-agent的模型。名字可以带命名空间例如internal/law-agent方便团队内区分版本。如果是 safetensors 权重常见做法是先转换再到 Ollamapip install transformers python -m transformers.llm.convert_safetensors_to_gguf.py --model law-model --output law-model.gguf --quantize q8 ollama create law-agent -f Modelfile注意命令里的--quantize参数不是所有模型都支持不支持时就生成 FP16 的 GGUF 再交给ollama create在 Modelfile 里用PARAMETER指定量化反而更灵活。对应的 Modelfile 长这样FROM ./law-model.gguf PARAMETER temperature 0.2 PARAMETER top_p 0.8 PARAMETER num_ctx 8192 SYSTEM 你是中文法律助手。回答法律问题时必须优先引用你检索到的法条原文无法确认的法条编号明确回答无法确认。temperature 0.2是法律问答的关键法律生成任务的随机性必须压到极低才能避免同一个问题两次回答引用不同条款。num_ctx 8192决定上下文窗口模型加载后显存占用会随它线性增长别贪大。3.3 本地部署配置的显存推算与并发控制给出一个快速估算方法权重量化大小 num_ctx * 层数 * 头数 * 2byte约等于显存下限。实际跑起来时直接看ollama ps和nvidia-smi更准确。ollama ps # 查看已加载模型的内存占用和上下文预算 nvidia-smi --query-gpumemory.used,memory.total --formatcsv如果并发请求多设置环境变量OLLAMA_NUM_PARALLEL1保持单请求串行否则多个并发请求会各开一份 KV cache显存瞬间翻倍。这也是「AI 大模型本地部署配置」里最常见的翻车点。注意num_ctx改大后ollama ps显示的进程内存会明显上升这是正常的。如果出现cuda out of memory优先降num_ctx而不是换更小量化。4. 用 RAG 把法律知识库接进 AI 大模型应用4.1 硬记不如检索法律场景为什么绕不开 RAG有一个很诱人的简化方案把整本民法典塞进上下文。但上下文 8192 个 token 最多容纳约三万字民法典有十几万条即使长文本模型也装不下全部法条。而且法条会修订模型权重里没有「当前生效版本」的概念——2021 年施行的民法典和相关司法解释更新模型训练数据是固定的。RAG 的价值就体现在这里先检索再生成让模型只在召回的证据上作答。常见技术栈是 LangChain或自己组合 embedding 模型和向量库加 OllamaEmbeddings 加 Chroma。法律场景的「查得准」取决于两件事切分是否尊重法律文本结构以及检索 top_k 是否够用。4.2 法律文本的分块策略按「条」而不是按「字数」固定 500 字切分对新闻类文本没问题对法律文本就是灾难。法律法规的最小引用单位是「条第款」一条可能只有几十字也可能长到几百字按固定窗口切分会把一条完整的规则切成两半检索时天然丢失一半信息。我一般按条切用正则把「第X条」作为切分边界import re def split_law_by_article(text: str) - list[str]: articles re.split(r(?第[一二三四五六七八九十百零\d]条), text) return [a for a in articles if len(a.strip()) 0] def chunks_by_article(text: str, max_chars: int 600) - list[dict]: docs [] for idx, article in enumerate(split_law_by_article(text)): if len(article) max_chars: docs.append({id: idx, text: article}) else: sub_parts re.split(r(?[。]), article) for j, part in enumerate(sub_parts): docs.append({id: f{idx}-{j}, text: part}) return docs代码逻辑先用正向零宽断言在「第X条」前切开把每条作为独立文档再对单条超长的条款按句号二次切分。id里带父条款编号是为了后面返回结果时能拼回「本判决依据第 X 条第 Y 款」这类可追溯的引用格式。4.3 检索 生成一条龙的执行代码from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain_community.llms import Ollama from langchain_core.prompts import PromptTemplate from langchain_core.runnables import RunnablePassthrough emb OllamaEmbeddings(modelbge-m3) vectordb Chroma.from_documents(embeddingemb, documentsdocs, persist_directory./law_db) retriever vectordb.as_retriever(search_kwargs{k: 4}) llm Ollama(modellaw-agent, temperature0.2, num_ctx8192) prompt PromptTemplate.from_template( 你是一个严谨的中文法律助手。请仅根据【参考条文】回答不要引用未给出的法条。 【参考条文】 {context} 【问题】 {question} 【回答要求】先给出结论再列出条文编号和原文关键词。 ) rag_chain {context: retriever, question: RunnablePassthrough()} | prompt | llm print(rag_chain.invoke(合同约定的违约金过高法院会如何处理))检索参数k4是经验值法律场景中 top_1 召回的法条往往不够top_4 能覆盖多个上位法条款超过 8 之后噪音条文会稀释生成质量。OllamaEmbeddings用中文 embedding 模型bge-m3对「违约金」「格式条款」这类法律术语的相似度区分比通用英文 embedding 好得多。5. 部署后的验收清单从 zip 报错排错到五连法条测试5.1 解压验证与路径安全排掉最蠢的坑有一种流传很广的说法模型 zip 包有密码要用 zip 压缩包密码破解工具或 zip 密码移除工具解开。实际情况是——正规发布的模型包不会加密。绑定密码的模型包反而要警惕它常见于二手分发渠道无法校验原始哈希。与其花时间研究密码工具不如重新到官方渠道拿分卷包并对比 SHA256。若压缩包里有../../路径条目解压时要盯紧避免路径穿越覆盖掉同级目录的代码文件。5.2 五连法条引用测试与运行健康检查用一套固定五问集做每日回归条款引用、合同风险点、错误条文拒答、上下文稳定性、性能基线。五问全过才能算当次部署有效。测试维度验证方式通过标准条款引用问「违约金酌减的请求由谁提出」回答中出现正确的条文号合同风险给一段含「单方解除权」条款的合同指出该条款可能的无效情形拒答能力问「未满十八岁转让合同是否当然无效」不编造明确说需要更多事实上下文稳定性粘贴 3000 字合同后连续问三个问题回答不前后矛盾性能基线curl测首 token 时延单并发首 token 小于 2 秒视硬件最后贴一条可放进 CI 的最小健康检查命令curl -s http://localhost:11434/api/generate \ -d {model:law-agent,prompt:民法典第五百八十五条规定的违约金调整规则,stream:false} \ | python -c import json,sys; rjson.load(sys.stdin); print(OK if 违约金 in r[response] else CHECK)这条命令把 Ollama 的原生/api/generate接口当作探针如果回答里没出现「违约金」关键词直接打印CHECK让部署流水线在模型退化时尽早发现异常。本文还有配套的精品资源点击获取