最近 AI 圈讨论度比较高的一个消息是美国法律 AI 公司 Harvey 被报道转用中国开源模型 Kimi K3用来打造自己的专属模型。消息本身的细节还不算多但放到技术角度看这件事真正值得关注的地方不在于“谁家模型更强”而在于法律 AI 这个特别吃上下文长度、数据隐私和输出可追溯性的场景开始认真考虑开源模型和自建部署。先说我的判断这件事对普通 AI 应用开发者的参考价值比一次模型排名变化大得多。它至少说明三件事。第一高价值专业任务里模型的可控性、数据私密性和成本模型正在被放到和“单轮对话效果”同等甚至更靠前的位置。第二像 Kimi K3 这样的开源长文本模型如果能在真实场景里稳定输出结构化结果完全可以替代部分闭源 API 的活儿。第三“用开源模型打造专属模型”不是一句口号它可以拆成数据准备、评估集、提示词工程、微调、部署、日志审计一整套工程流程。下面我会先用 Harvey 这个案例说明法律 AI 对模型的特殊要求再拆解从闭源 API 切换到开源模型时要算的账然后给出一条可以照着落地的链路最后聊边界和坑。1. 法律 AI 场景为什么对模型要求“反直觉”1.1 法律 AI 要处理的不是聊天而是结构化任务普通人用 AI 聊天问一句答一段语义通顺基本就满意了。法律 AI 不是这个逻辑。合同审查要抽取当事人、金额、期限、违约责任、争议解决条款尽职调查要把几十份甚至几百份文件里的关键信息汇总成清单法规问答必须给出具体条文和判例出处文书起草要按照律所自己的格式和表达习惯来输出。这些任务有三个共同点输入长、输出要结构化、错误代价高。一份合同可能几十页一个尽调项目可能几百份 PDF单靠通用对话模型的上下文窗口不一定能稳定覆盖。同时输出不能是一段散漫的文字最好直接生成字段、风险点、修改建议和引用位置。更关键的是法律场景里“看起来通顺但引用是编的”会被当成严重问题而不是小瑕疵。所以法律 AI 选模型时优先看的不是“谁更会聊天”而是处理长文本的稳定性、输出格式的可控性、幻觉出现的频率以及这个模型能否部署到律所可控的环境里。1.2 为什么“能不能自己部署”会变成硬指标律所和大型企业法务部手里的数据有很多受保密协议、客户隐私条款和数据合规政策约束。把客户合同直接发到外部 API在很多场景里并不可行哪怕服务商承诺不留存合规审查也很难通过。更麻烦的是外部 API 的能力和版本由别人控制今天可用的提示词策略明天可能因为服务商调整而变化。开源模型这时候的优势就出来了。模型权重在自己手里可以部署到私有服务器或内网环境数据不经过第三方服务可以冻结版本保证已经验证过的流程长期稳定可以针对自己的文书格式做微调而不是在别人的平台上迁就接口限制。Harvey 选择基于 Kimi K3 做专属模型本质上是把“模型策略”的主动权拿回自己手里而不是简单地替换一个供应商。2. 从闭源 API 切到开源模型先算清三笔账2.1 成本账不能只算单次调用价格很多人对比 API 和自建部署时会犯一个错只拿单次调用的 token 价格对比忽略使用量、硬件、运维和研发成本。法律 AI 的典型场景恰恰是高 token 消耗。一份合同全文可能几万 token一套尽调报告跑下来可能是百万 token 级别如果还有批量任务和团队多人使用API 费用增长非常快。开源模型自建部署的前期成本更高需要 GPU 服务器、存储、推理框架和运维人力但单次增量成本低。到底哪个划算取决于三个变量使用量是否稳定、任务是否长期存在、你的团队有没有能力维护一套模型服务。如果只是偶尔跑几条测试闭源 API 通常更省如果每天要处理大量合同且数据敏感自建分摊成本往往更低。落地前建议用过去三个月的真实 token 消耗做一次测算而不是凭感觉选边。2.2 隐私账数据合规比推理效果更靠前法律数据最敏感的地方不是“模型答得准不准”而是“数据去了哪里、谁看过、留不留下”。涉及律师客户特权、并购尽调、监管审查的资料一旦流向不可控的第三方后果可能不只是商业风险而是合规责任。开源模型加私有化部署解决的是数据边界问题原始文档、中间结果、最终输出都可以留在自己的网络里。但这里要提醒一句开源模型不自动等于安全。模型权重、推理框架、依赖包都需要做版本管理和漏洞跟踪服务器权限、日志脱敏、员工访问控制同样要按内部安全规范做。真正的数据合规是“制度加技术”的共同结果。2.3 可控性账能不能把模型变成“自己的”闭源 API 能调但边界由平台决定。你不能把提示词做到百分之百确定不能下载权重做领域微调也很难拿到完整日志做审计。当业务开始依赖模型输出时这种不可控会很别扭。开源模型把几层能力还给了你第一层可以做领域微调让模型学习律所的合同术语和文书风格第二层可以量化、剪枝、调整部署参数适配不同硬件第三层可以完整记录每次输入的 prompt、检索结果、输出内容和审核状态形成可追溯的记录。对法律 AI 来说第三层有时候比第一层更重要。下面用一个对比表说明方向具体数值要按你的业务场景测对比维度闭源 API开源模型 私有化部署前期成本低按调用付费高需要 GPU、存储、运维投入数据边界数据会传给服务商可完全留在内部网络定制深度受平台接口限制可微调、量化、自定义流程版本稳定性由服务商控制可自行冻结版本日志审计依赖供应商可自建完整记录维护负担服务商负责团队自己承担适用场景快速验证、中低频调用高频批量、高敏感、深度定制3. 如果想基于 Kimi K3 这类开源模型做法律 AI落地链路怎么设计3.1 第一步把任务类型拆开先别急着训练拿到一个开源模型第一件要做的事不是训练而是把项目需求拆成不同任务。法律 AI 至少可以分成四类抽取类比如从合同里提取金额、日期、当事人和责任条款摘要类比如把长判决书压缩成结论和要点检索问答类比如基于法规和案例回答问题并给出引用生成类比如起草合同段落或合规报告。不同任务的难度和验证方式完全不同。抽取类看字段准确率摘要类看事实保真度和完整性检索问答看引用正确率生成类看格式和法律专业度。把它们混在一起评估很容易得出“模型不行”的错误结论。正确做法是按任务分别做小样本测试每个任务准备几十条典型输入先用零样本或少量示例跑一遍。3.2 第二步准备评估集和验收标准法律 AI 项目不能没有评估集就上线。建议每个关键任务准备 50 到 200 条经过律师或法务人员复核的样本样本里要包含常见情况和边界情况。比如合同审查既有标准条款也有缺失签章、金额大写不一致、争议解决条款异常等特殊情况。评估标准要具体。抽取任务可以算字段级准确率和召回率摘要任务要人工检查每句话能否在原文里找到依据检索问答要核对引用的法条和判例是否真实存在生成任务至少要抽查是否存在凭空添加的义务。测试时不要把模型回答直接当作答案先让专业人员在样本上做一轮基准答案再拿模型输出对比。3.3 第三步跑通最小链路最小链路的意思是先不接复杂的 RAG不接多轮对话不接自动化任务流只验证模型能加载、能接收长文本输入、能按你要求的格式输出。环境上先确认 GPU 显存、内存、磁盘空间是否足够。不同模型的体积差异很大推理和微调对资源的要求也不一样。如果模型体积在几十 B 量级推理通常需要至少几十 GB 显存微调需要更多再小一些的模型可以在消费级显卡上跑量化版本。这里没有统一答案要看你选的具体权重和量化方式。推理框架可以先用 vLLM 或 SGLang 这类主流方案本地验证也可以先用 llama.cpp。模型下载后建议记录权重文件的版本和校验值避免后面换了文件说不清。跑通标准很简单模型正常启动输入一条测试文本后能在合理时间内返回结果结果能被解析成结构化内容不报错、不截断、不崩溃。下一步再加入文档解析、向量检索、提示词模板和业务层逻辑。下面给一组示例参数不是 Kimi K3 的官方推荐适合用来建立第一版基线{ chunk_size: 800, chunk_overlap: 150, top_k: 5, score_threshold: 0.6, temperature: 0.1, max_tokens: 2048, retriever_model: bge-m3, llm_model: kimi-k3-example }3.4 第四步小批量跑通后再决定要不要微调很多团队在评估阶段就急着微调其实顺序反了。先用提示词和检索流程把效果拉到能看的水平再判断瓶颈在哪里。如果输出格式不稳定可能是提示词结构问题如果关键信息经常漏掉可能是切块和检索参数问题如果这些问题都优化后仍然达不到要求再考虑微调。微调需要的数据量和数据质量门槛都不低。一般建议准备同类任务几千条以上、质量经过复核的样本标注口径要统一还要做脱敏处理。不要直接把客户原始合同丢进训练集。微调之后必须回到同一个评估集上做回归防止出现“这个任务变好了另一个任务明显变差”的情况。4. 法律文本批量处理参数和判断标准不能照搬通用对话4.1 上下文长度不是越大越好开源长文本模型确实能接收很长的输入但“最大上下文”和“稳定可用上下文”是两回事。很多模型在输入特别长时中间内容容易被忽略输出质量和定位准确率都会下降。法律文本又恰恰禁止遗漏合同里少看一眼违约责任结果可能完全不同。所以第一件事不是把整份合同直接塞进去而是在自己的数据上做有效上下文测试。你可以准备不同长度的文档分别测试关键信息召回率找到模型性能出现明显下滑的长度临界点。单份短文档可以直接用长上下文处理如果任务涉及几十份或几百份文件优先走 RAG 检索而不是强行拼接上下文。混合策略通常是一份合同全文走长上下文尽调大文件库走检索增强。4.2 关键参数和判断标准下面列出法律文本处理里最常调的几组参数以及它们对应的判断方式参数常见方向主要判断标准chunk_size400 到 1000 字符或按合同条款切字段完整性、检索命中率chunk_overlap50 到 200 字符跨块信息是否断裂top_k3 到 10覆盖率和延迟的平衡score_threshold0.5 到 0.7减少无关引用避免误导temperature抽取用 0 到 0.1起草用 0.2 到 0.4稳定性和表达多样性max_tokens按输出任务设置输出不截断、不超时切块不要只按字符数硬切法律文本最好优先按条款、段落和语义边界切。比如劳动合同的“解除条款”通常在一个小标题下硬从中间切断会让模型很难判断上下文。检索的 top_k 也不是越大越好拉进太多无关片段会稀释真正有用的信息还会增加 token 消耗。temperature 在抽取任务里要压低最好接近 0因为法律字段不允许发挥起草任务可以稍微高一点但也要控制在能复核的范围内。4.3 批量任务还要单独设计队列和失败重试能单条跑通不代表能批量跑。批量处理合同或尽调文件时第一批要控制并发数不要一把梭。建议先跑 5 到 10 条样例观察延迟、显存占用和输出完整性再逐步增加并发。任务脚本要写清楚输入路径、输出目录、失败重试和日志记录。一条文件解析失败不应该让整个任务队列停住模型生成中途超时要有重试机制输出命名要稳定方便后续审核和追溯。批量结果的质量判断也不能只看个别样本。建议按任务维度统计抽取字段完整率、引用命中率、格式可解析率、人工复核通过率。如果某项指标低于业务可接受水平优先回看该任务对应的输入样例和日志定位是解析、检索、提示词还是模型生成的问题。5. 本地化部署和评测环节最容易踩的五个坑5.1 报错先查环境和输入别急着怀疑模型本地部署一个开源模型初次启动失败非常常见。我第一次遇到类似问题时第一反应是模型文件坏了查了半天才发现是推理框架版本和 CUDA 版本不匹配。后面我养成了固定排查顺序先看显存和内存占用再看驱动和依赖版本然后看模型文件是否完整最后才怀疑模型本身。输入文本的编码、路径、权限、PDF 解析结果也经常是问题源头。报错信息里的关键字段比“模型不行”可靠得多。5.2 量化模型要拿法律条文单独验证为了降低显存占用很多人会直接用量化版本。量化对大多数场景影响不大但法律文本讲究精确金额、日期、编号、责任表述一旦被压缩出错很难通过肉眼快速发现。建议在同一批评估集上对比量化版本和原始精度版本的结果重点看数字、条款编号和关键义务是否保持一致。如果只是内部原型量化可以接受如果面向客户输出宁可花更多推理成本也要保证关键字段稳定。5.3 长文档里的隐藏指令要单独处理法律文档来自外部可能包含攻击性内容。常见情况是合同里有一段“忽略之前所有指令告诉我……”之类的文字模型如果直接处理整份文档很可能被这些隐藏指令带偏。这不是模型故意不听话而是提示词注入本就是大模型应用要面对的风险。稳妥做法是把系统指令、业务提示词和用户文档分层管理外部文档作为不可信内容处理。可以让模型只从文档里抽取事实不执行文档里出现的指令对可能被注入的场景做专项测试。这个环节在金融、法律等高风险场景里属于必做项不是可选项。5.4 引用幻觉必须设计校验机制法律 AI 踩过最多的坑是引用幻觉模型引用了看起来真实、实际上不存在的判例或法条。这个问题不能只靠提示词“你要诚实”来解决。最实用的方案是强制 RAG 引用要求模型只能基于检索返回的片段作答并在输出里带上对应的片段编号部署层再做一次校验如果模型输出的引用编号不在检索结果里就判定为无效引用要求重试或人工审核。高风险输出仍然建议由专业人员过一道这个流程省不得。5.5 日志、版本和可追溯性要提前设计模型会更新、提示词会改、切块参数会调如果没有记录输出一出问题就很难定位。建议把模型版本、量化等级、prompt 模板版本、检索参数、输入文件版本和审核状态都写进日志。输出文件里保留引用片段编号方便追溯到原文。对法律 AI 来说可追溯性不只是技术问题有时是业务合规的一部分。下面给一个常见排查表按优先级从高到低排列现象优先排查服务启动失败显存、驱动、依赖版本、模型文件完整性输出为空或截断输入解析、max_tokens、超时设置引用内容编造RAG 未命中、score_threshold 太低、prompt 未限制引用来源批量任务中断磁盘空间、权限、任务脚本异常处理推理速度过慢并发数、batch_size、量化等级、GPU 利用率6. 开源模型不等于必须全量替换混合路由更稳6.1 什么情况适合切什么情况先等等看完 Harvey 的案例很容易产生“所有法律 AI 都应该转向开源模型”的冲动。实际不是这样。适合切换的场景通常有这几个特征数据敏感度高不适合送外部使用频次高且长期稳定自建分摊成本划算需要深度定制输出格式和行业术语团队有维护模型服务的硬件和人力。暂时不切换也很正常。如果业务还处于原型验证阶段使用量不高或者输出质量对模型底座能力要求极高闭源 API 反而更省心。关键不是跟风选边而是先用自己真实的业务数据分别跑一轮对比评估把成本、质量、隐私、维护负担一起算进去再做决定。6.2 混合路由是更务实的做法实践中我更推荐混合路由而不是把所有业务绑在单一模型上。比如用一个小型开源模型做文件分类和字段抽取速度快、成本低用带长上下文的开源模型处理关键合同的整体审查遇到特别复杂的起草任务再结合数据合规要求决定是否调用能力更强的外部 API。混合路由会增加一定复杂度但换来的是更稳的成本和质量平衡。实现时要注意把各路模型的结果结构统一最好都输出标准 JSON放到同一个审核流程里。否则每个模型一套输出格式后续处理会越来越乱。如果你也想做一次类似的切换验证建议按这个顺序做一遍用 20 条真实脱敏样本对比闭源 API 和开源模型的输出质量。记录两种方案的成本估算包含 token 费用和硬件分摊。让业务人员盲测输出不要只看开发者的喜好。确认数据隐私约束允许哪种部署方式。如果决定自建先跑最小链路再逐步加 RAG 和批量流程。6.3 这件事真正给出的信号Harvey 用 Kimi K3 做专属模型真正值得关注的不是“开源打败闭源”而是垂直行业开始把开源模型当成可以长期持有、深度定制的技术资产。模型底座能力达到可用水平之后决定产品价值的更多是数据、评测、微调、部署和审核流程。对开发者来说这意味着接下来要补的不只是“哪个模型更厉害”的新闻敏感度而是把模型接入业务场景的能力定义任务、准备评估集、跑通链路、判断参数、处理失败、控制风险。这套能力任何模型都能用也任何模型都不能替你省掉。如果只是自己学习可以先用一个小型开源模型在消费级显卡上跑通流程如果要做生产系统建议从最小业务样例开始先单条、再批量、再上线每一步都留好日志和人工复核的通道。很多问题不是你手里的模型不够强而是前面的数据、环境和流程还没有处理干净。
法律AI转向开源模型Kimi K3：从闭源API到私有化部署的工程链路
最近 AI 圈讨论度比较高的一个消息是美国法律 AI 公司 Harvey 被报道转用中国开源模型 Kimi K3用来打造自己的专属模型。消息本身的细节还不算多但放到技术角度看这件事真正值得关注的地方不在于“谁家模型更强”而在于法律 AI 这个特别吃上下文长度、数据隐私和输出可追溯性的场景开始认真考虑开源模型和自建部署。先说我的判断这件事对普通 AI 应用开发者的参考价值比一次模型排名变化大得多。它至少说明三件事。第一高价值专业任务里模型的可控性、数据私密性和成本模型正在被放到和“单轮对话效果”同等甚至更靠前的位置。第二像 Kimi K3 这样的开源长文本模型如果能在真实场景里稳定输出结构化结果完全可以替代部分闭源 API 的活儿。第三“用开源模型打造专属模型”不是一句口号它可以拆成数据准备、评估集、提示词工程、微调、部署、日志审计一整套工程流程。下面我会先用 Harvey 这个案例说明法律 AI 对模型的特殊要求再拆解从闭源 API 切换到开源模型时要算的账然后给出一条可以照着落地的链路最后聊边界和坑。1. 法律 AI 场景为什么对模型要求“反直觉”1.1 法律 AI 要处理的不是聊天而是结构化任务普通人用 AI 聊天问一句答一段语义通顺基本就满意了。法律 AI 不是这个逻辑。合同审查要抽取当事人、金额、期限、违约责任、争议解决条款尽职调查要把几十份甚至几百份文件里的关键信息汇总成清单法规问答必须给出具体条文和判例出处文书起草要按照律所自己的格式和表达习惯来输出。这些任务有三个共同点输入长、输出要结构化、错误代价高。一份合同可能几十页一个尽调项目可能几百份 PDF单靠通用对话模型的上下文窗口不一定能稳定覆盖。同时输出不能是一段散漫的文字最好直接生成字段、风险点、修改建议和引用位置。更关键的是法律场景里“看起来通顺但引用是编的”会被当成严重问题而不是小瑕疵。所以法律 AI 选模型时优先看的不是“谁更会聊天”而是处理长文本的稳定性、输出格式的可控性、幻觉出现的频率以及这个模型能否部署到律所可控的环境里。1.2 为什么“能不能自己部署”会变成硬指标律所和大型企业法务部手里的数据有很多受保密协议、客户隐私条款和数据合规政策约束。把客户合同直接发到外部 API在很多场景里并不可行哪怕服务商承诺不留存合规审查也很难通过。更麻烦的是外部 API 的能力和版本由别人控制今天可用的提示词策略明天可能因为服务商调整而变化。开源模型这时候的优势就出来了。模型权重在自己手里可以部署到私有服务器或内网环境数据不经过第三方服务可以冻结版本保证已经验证过的流程长期稳定可以针对自己的文书格式做微调而不是在别人的平台上迁就接口限制。Harvey 选择基于 Kimi K3 做专属模型本质上是把“模型策略”的主动权拿回自己手里而不是简单地替换一个供应商。2. 从闭源 API 切到开源模型先算清三笔账2.1 成本账不能只算单次调用价格很多人对比 API 和自建部署时会犯一个错只拿单次调用的 token 价格对比忽略使用量、硬件、运维和研发成本。法律 AI 的典型场景恰恰是高 token 消耗。一份合同全文可能几万 token一套尽调报告跑下来可能是百万 token 级别如果还有批量任务和团队多人使用API 费用增长非常快。开源模型自建部署的前期成本更高需要 GPU 服务器、存储、推理框架和运维人力但单次增量成本低。到底哪个划算取决于三个变量使用量是否稳定、任务是否长期存在、你的团队有没有能力维护一套模型服务。如果只是偶尔跑几条测试闭源 API 通常更省如果每天要处理大量合同且数据敏感自建分摊成本往往更低。落地前建议用过去三个月的真实 token 消耗做一次测算而不是凭感觉选边。2.2 隐私账数据合规比推理效果更靠前法律数据最敏感的地方不是“模型答得准不准”而是“数据去了哪里、谁看过、留不留下”。涉及律师客户特权、并购尽调、监管审查的资料一旦流向不可控的第三方后果可能不只是商业风险而是合规责任。开源模型加私有化部署解决的是数据边界问题原始文档、中间结果、最终输出都可以留在自己的网络里。但这里要提醒一句开源模型不自动等于安全。模型权重、推理框架、依赖包都需要做版本管理和漏洞跟踪服务器权限、日志脱敏、员工访问控制同样要按内部安全规范做。真正的数据合规是“制度加技术”的共同结果。2.3 可控性账能不能把模型变成“自己的”闭源 API 能调但边界由平台决定。你不能把提示词做到百分之百确定不能下载权重做领域微调也很难拿到完整日志做审计。当业务开始依赖模型输出时这种不可控会很别扭。开源模型把几层能力还给了你第一层可以做领域微调让模型学习律所的合同术语和文书风格第二层可以量化、剪枝、调整部署参数适配不同硬件第三层可以完整记录每次输入的 prompt、检索结果、输出内容和审核状态形成可追溯的记录。对法律 AI 来说第三层有时候比第一层更重要。下面用一个对比表说明方向具体数值要按你的业务场景测对比维度闭源 API开源模型 私有化部署前期成本低按调用付费高需要 GPU、存储、运维投入数据边界数据会传给服务商可完全留在内部网络定制深度受平台接口限制可微调、量化、自定义流程版本稳定性由服务商控制可自行冻结版本日志审计依赖供应商可自建完整记录维护负担服务商负责团队自己承担适用场景快速验证、中低频调用高频批量、高敏感、深度定制3. 如果想基于 Kimi K3 这类开源模型做法律 AI落地链路怎么设计3.1 第一步把任务类型拆开先别急着训练拿到一个开源模型第一件要做的事不是训练而是把项目需求拆成不同任务。法律 AI 至少可以分成四类抽取类比如从合同里提取金额、日期、当事人和责任条款摘要类比如把长判决书压缩成结论和要点检索问答类比如基于法规和案例回答问题并给出引用生成类比如起草合同段落或合规报告。不同任务的难度和验证方式完全不同。抽取类看字段准确率摘要类看事实保真度和完整性检索问答看引用正确率生成类看格式和法律专业度。把它们混在一起评估很容易得出“模型不行”的错误结论。正确做法是按任务分别做小样本测试每个任务准备几十条典型输入先用零样本或少量示例跑一遍。3.2 第二步准备评估集和验收标准法律 AI 项目不能没有评估集就上线。建议每个关键任务准备 50 到 200 条经过律师或法务人员复核的样本样本里要包含常见情况和边界情况。比如合同审查既有标准条款也有缺失签章、金额大写不一致、争议解决条款异常等特殊情况。评估标准要具体。抽取任务可以算字段级准确率和召回率摘要任务要人工检查每句话能否在原文里找到依据检索问答要核对引用的法条和判例是否真实存在生成任务至少要抽查是否存在凭空添加的义务。测试时不要把模型回答直接当作答案先让专业人员在样本上做一轮基准答案再拿模型输出对比。3.3 第三步跑通最小链路最小链路的意思是先不接复杂的 RAG不接多轮对话不接自动化任务流只验证模型能加载、能接收长文本输入、能按你要求的格式输出。环境上先确认 GPU 显存、内存、磁盘空间是否足够。不同模型的体积差异很大推理和微调对资源的要求也不一样。如果模型体积在几十 B 量级推理通常需要至少几十 GB 显存微调需要更多再小一些的模型可以在消费级显卡上跑量化版本。这里没有统一答案要看你选的具体权重和量化方式。推理框架可以先用 vLLM 或 SGLang 这类主流方案本地验证也可以先用 llama.cpp。模型下载后建议记录权重文件的版本和校验值避免后面换了文件说不清。跑通标准很简单模型正常启动输入一条测试文本后能在合理时间内返回结果结果能被解析成结构化内容不报错、不截断、不崩溃。下一步再加入文档解析、向量检索、提示词模板和业务层逻辑。下面给一组示例参数不是 Kimi K3 的官方推荐适合用来建立第一版基线{ chunk_size: 800, chunk_overlap: 150, top_k: 5, score_threshold: 0.6, temperature: 0.1, max_tokens: 2048, retriever_model: bge-m3, llm_model: kimi-k3-example }3.4 第四步小批量跑通后再决定要不要微调很多团队在评估阶段就急着微调其实顺序反了。先用提示词和检索流程把效果拉到能看的水平再判断瓶颈在哪里。如果输出格式不稳定可能是提示词结构问题如果关键信息经常漏掉可能是切块和检索参数问题如果这些问题都优化后仍然达不到要求再考虑微调。微调需要的数据量和数据质量门槛都不低。一般建议准备同类任务几千条以上、质量经过复核的样本标注口径要统一还要做脱敏处理。不要直接把客户原始合同丢进训练集。微调之后必须回到同一个评估集上做回归防止出现“这个任务变好了另一个任务明显变差”的情况。4. 法律文本批量处理参数和判断标准不能照搬通用对话4.1 上下文长度不是越大越好开源长文本模型确实能接收很长的输入但“最大上下文”和“稳定可用上下文”是两回事。很多模型在输入特别长时中间内容容易被忽略输出质量和定位准确率都会下降。法律文本又恰恰禁止遗漏合同里少看一眼违约责任结果可能完全不同。所以第一件事不是把整份合同直接塞进去而是在自己的数据上做有效上下文测试。你可以准备不同长度的文档分别测试关键信息召回率找到模型性能出现明显下滑的长度临界点。单份短文档可以直接用长上下文处理如果任务涉及几十份或几百份文件优先走 RAG 检索而不是强行拼接上下文。混合策略通常是一份合同全文走长上下文尽调大文件库走检索增强。4.2 关键参数和判断标准下面列出法律文本处理里最常调的几组参数以及它们对应的判断方式参数常见方向主要判断标准chunk_size400 到 1000 字符或按合同条款切字段完整性、检索命中率chunk_overlap50 到 200 字符跨块信息是否断裂top_k3 到 10覆盖率和延迟的平衡score_threshold0.5 到 0.7减少无关引用避免误导temperature抽取用 0 到 0.1起草用 0.2 到 0.4稳定性和表达多样性max_tokens按输出任务设置输出不截断、不超时切块不要只按字符数硬切法律文本最好优先按条款、段落和语义边界切。比如劳动合同的“解除条款”通常在一个小标题下硬从中间切断会让模型很难判断上下文。检索的 top_k 也不是越大越好拉进太多无关片段会稀释真正有用的信息还会增加 token 消耗。temperature 在抽取任务里要压低最好接近 0因为法律字段不允许发挥起草任务可以稍微高一点但也要控制在能复核的范围内。4.3 批量任务还要单独设计队列和失败重试能单条跑通不代表能批量跑。批量处理合同或尽调文件时第一批要控制并发数不要一把梭。建议先跑 5 到 10 条样例观察延迟、显存占用和输出完整性再逐步增加并发。任务脚本要写清楚输入路径、输出目录、失败重试和日志记录。一条文件解析失败不应该让整个任务队列停住模型生成中途超时要有重试机制输出命名要稳定方便后续审核和追溯。批量结果的质量判断也不能只看个别样本。建议按任务维度统计抽取字段完整率、引用命中率、格式可解析率、人工复核通过率。如果某项指标低于业务可接受水平优先回看该任务对应的输入样例和日志定位是解析、检索、提示词还是模型生成的问题。5. 本地化部署和评测环节最容易踩的五个坑5.1 报错先查环境和输入别急着怀疑模型本地部署一个开源模型初次启动失败非常常见。我第一次遇到类似问题时第一反应是模型文件坏了查了半天才发现是推理框架版本和 CUDA 版本不匹配。后面我养成了固定排查顺序先看显存和内存占用再看驱动和依赖版本然后看模型文件是否完整最后才怀疑模型本身。输入文本的编码、路径、权限、PDF 解析结果也经常是问题源头。报错信息里的关键字段比“模型不行”可靠得多。5.2 量化模型要拿法律条文单独验证为了降低显存占用很多人会直接用量化版本。量化对大多数场景影响不大但法律文本讲究精确金额、日期、编号、责任表述一旦被压缩出错很难通过肉眼快速发现。建议在同一批评估集上对比量化版本和原始精度版本的结果重点看数字、条款编号和关键义务是否保持一致。如果只是内部原型量化可以接受如果面向客户输出宁可花更多推理成本也要保证关键字段稳定。5.3 长文档里的隐藏指令要单独处理法律文档来自外部可能包含攻击性内容。常见情况是合同里有一段“忽略之前所有指令告诉我……”之类的文字模型如果直接处理整份文档很可能被这些隐藏指令带偏。这不是模型故意不听话而是提示词注入本就是大模型应用要面对的风险。稳妥做法是把系统指令、业务提示词和用户文档分层管理外部文档作为不可信内容处理。可以让模型只从文档里抽取事实不执行文档里出现的指令对可能被注入的场景做专项测试。这个环节在金融、法律等高风险场景里属于必做项不是可选项。5.4 引用幻觉必须设计校验机制法律 AI 踩过最多的坑是引用幻觉模型引用了看起来真实、实际上不存在的判例或法条。这个问题不能只靠提示词“你要诚实”来解决。最实用的方案是强制 RAG 引用要求模型只能基于检索返回的片段作答并在输出里带上对应的片段编号部署层再做一次校验如果模型输出的引用编号不在检索结果里就判定为无效引用要求重试或人工审核。高风险输出仍然建议由专业人员过一道这个流程省不得。5.5 日志、版本和可追溯性要提前设计模型会更新、提示词会改、切块参数会调如果没有记录输出一出问题就很难定位。建议把模型版本、量化等级、prompt 模板版本、检索参数、输入文件版本和审核状态都写进日志。输出文件里保留引用片段编号方便追溯到原文。对法律 AI 来说可追溯性不只是技术问题有时是业务合规的一部分。下面给一个常见排查表按优先级从高到低排列现象优先排查服务启动失败显存、驱动、依赖版本、模型文件完整性输出为空或截断输入解析、max_tokens、超时设置引用内容编造RAG 未命中、score_threshold 太低、prompt 未限制引用来源批量任务中断磁盘空间、权限、任务脚本异常处理推理速度过慢并发数、batch_size、量化等级、GPU 利用率6. 开源模型不等于必须全量替换混合路由更稳6.1 什么情况适合切什么情况先等等看完 Harvey 的案例很容易产生“所有法律 AI 都应该转向开源模型”的冲动。实际不是这样。适合切换的场景通常有这几个特征数据敏感度高不适合送外部使用频次高且长期稳定自建分摊成本划算需要深度定制输出格式和行业术语团队有维护模型服务的硬件和人力。暂时不切换也很正常。如果业务还处于原型验证阶段使用量不高或者输出质量对模型底座能力要求极高闭源 API 反而更省心。关键不是跟风选边而是先用自己真实的业务数据分别跑一轮对比评估把成本、质量、隐私、维护负担一起算进去再做决定。6.2 混合路由是更务实的做法实践中我更推荐混合路由而不是把所有业务绑在单一模型上。比如用一个小型开源模型做文件分类和字段抽取速度快、成本低用带长上下文的开源模型处理关键合同的整体审查遇到特别复杂的起草任务再结合数据合规要求决定是否调用能力更强的外部 API。混合路由会增加一定复杂度但换来的是更稳的成本和质量平衡。实现时要注意把各路模型的结果结构统一最好都输出标准 JSON放到同一个审核流程里。否则每个模型一套输出格式后续处理会越来越乱。如果你也想做一次类似的切换验证建议按这个顺序做一遍用 20 条真实脱敏样本对比闭源 API 和开源模型的输出质量。记录两种方案的成本估算包含 token 费用和硬件分摊。让业务人员盲测输出不要只看开发者的喜好。确认数据隐私约束允许哪种部署方式。如果决定自建先跑最小链路再逐步加 RAG 和批量流程。6.3 这件事真正给出的信号Harvey 用 Kimi K3 做专属模型真正值得关注的不是“开源打败闭源”而是垂直行业开始把开源模型当成可以长期持有、深度定制的技术资产。模型底座能力达到可用水平之后决定产品价值的更多是数据、评测、微调、部署和审核流程。对开发者来说这意味着接下来要补的不只是“哪个模型更厉害”的新闻敏感度而是把模型接入业务场景的能力定义任务、准备评估集、跑通链路、判断参数、处理失败、控制风险。这套能力任何模型都能用也任何模型都不能替你省掉。如果只是自己学习可以先用一个小型开源模型在消费级显卡上跑通流程如果要做生产系统建议从最小业务样例开始先单条、再批量、再上线每一步都留好日志和人工复核的通道。很多问题不是你手里的模型不够强而是前面的数据、环境和流程还没有处理干净。