通用基座+领域后训练：Harvey Tenet的法律AI实践拆解

当一家专注法律 AI 的公司决定基于通用大模型做垂直后训练时它其实是在回答一个很现实的问题通用能力已经很强了为什么客户还是不满意这个问题放到法律行业尤其尖锐——大模型能背下法条却未必懂得“应当”和“可以”之间的分寸能写出像模像样的文书却可能在关键引注上出错。Harvey 近期宣布推出基于 Kimi K3 的后训练模型 Harvey Tenet恰好是观察“通用基座 领域后训练”这一路线的好样本。这篇文章不会只停留在新闻解读层面而是会从技术视角拆解后训练到底是什么、为什么 Harvey 要选 Kimi K3 作为基座、领域后训练的关键步骤有哪些、落地时又会踩到哪些坑。无论你是做大模型应用开发、关注垂直行业解决方案还是想自己动手做一次领域模型后训练这篇文章都值得收藏备用。1. 背景Harvey、Kimi K3 与 Harvey Tenet 是什么1.1 Harvey法律 AI 的明星公司Harvey 在 AI 法律科技领域算是知名度很高的公司核心产品是面向律所和法务团队开发的 AI 助手。它做的不是简单套一个 ChatGPT 壳子而是围绕律师真实工作流构建服务比如合同审查、法律检索、尽职调查、文书起草、案例归纳等。法律场景有一个非常突出的特点错误成本极高。普通聊天机器人答错一个问题用户可能只是觉得“不太聪明”法律 AI 如果引用错一条法规、忽略一个例外条款、或者把合同中的责任条款理解反带来的后果可能是真实的商业损失和执业风险。因此Harvey 这类公司不能只依赖通用模型它们必须对模型做深度的领域适配。1.2 Kimi K3高难度通用基座Kimi 系列是月之暗面Moonshot AI推出的通用大模型在长文本处理、复杂推理、中文能力等方面有比较强的表现。从公开信息看Kimi K3 采用 MoEMixture of Experts混合专家架构总参数量达到 2.8T 级别同时通过激活少量专家来控制推理成本。这类“大而稀疏”的设计是当前主流大模型平衡能力与成本的方式。Kimi K3 的另一张牌是长上下文。法律文档动辄几十页甚至上百页传统模型在处理超长文本时会出现注意力分散、信息遗忘、中间内容“迷失”等问题。Kimi 系列一直把长上下文作为核心卖点这正好和法律场景高度契合。1.3 Harvey Tenet一次“能力 领域”的结合Harvey Tenet 是 Harvey 基于 Kimi K3 做的后训练模型。所谓“后训练模型”指的是在通用基座模型之上用特定领域的数据和训练方法让模型掌握垂直场景的专业能力。这里需要区分一个概念Harvey Tenet 不是从零训练的模型也不是简单“微调”一下就行。它是在 Kimi K3 这种通用能力很强的基座上通过高质量法律数据、对齐训练、评测迭代等一整套后训练流程最终得到法律领域表现更好的专用模型。这种“基座选型 领域后训练”的模式正在成为垂直 AI 应用的主流技术路线。2. 后训练模型为什么基座模型不够用2.1 预训练与后训练的分工要理解后训练先要理解大模型的两个阶段。预训练阶段模型在海量互联网文本上学习语言规律、世界知识和推理能力。这个阶段的模型通常叫“基座模型”Base Model它的特点是“什么都会一点”但不会很好地回答问题。你问基座模型“帮我写一份保密协议”它可能给你续写出一堆不相关的内容因为它只学会了预测下一个 token没有学会“用户问什么我就答什么”。后训练阶段则是让基座模型学会“如何被使用”。通过指令数据训练模型学会理解用户意图通过人类反馈对齐模型学会输出符合人类偏好的内容通过领域数据训练模型学会专业场景的表达方式和判断标准。我们日常使用的 ChatGPT、Kimi、DeepSeek 等对话产品内部模型都经历了复杂的后训练流程。2.2 从 SFT 到 RLHF/DPO 的进化后训练不是单一操作而是一条流水线。第一步通常是有监督微调SFTSupervised Fine-Tuning。这一步用“用户指令 标准答案”这样的数据教会模型基本的问答格式和服务形态。SFT 数据质量直接决定模型能力的上限因为模型在模仿答案的同时也在学习答案背后的思维方式和专业习惯。第二步是对齐训练常见的有 RLHF基于人类反馈的强化学习和 DPO直接偏好优化。这一步的目的是让模型不仅“答得对”还“答得让人满意”。具体来说标注人员会对同一问题的多个回答排序模型学习到哪种回答更优。对于法律场景这意味着模型要学会引用法条时给出出处、不确定时明确说明、避免给出绝对化结论。再往后会加入更针对性的能力训练比如工具调用、结构化输出、长文档理解、多轮对话一致性等。每一层训练都在为模型叠加新的能力维度。2.3 垂直行业后训练的独特价值通用模型和垂直模型的核心差异不在于“知道多少”而在于“如何输出”。以法律场景为例通用模型可能知道合同的核心要素有哪些但一个合格的法律 AI 需要做到能按照律所的标准格式输出审查意见能区分“强制性规定”和“任意性规定”的不同表述能准确引用法条、司法解释和指导案例能在信息不充分时主动提问而不是强行编造答案。这些能力很难通过通用后训练覆盖完整必须结合领域数据做定向优化。Harvey Tenet 选择基于 Kimi K3 做后训练本质上就是看中 Kimi K3 在通用能力和长上下文上的优势再把法律领域的高质量知识“注入”进去。3. Harvey Tenet 核心技术思路拆解3.1 法律数据的重新组织从“语料”到“训练集”后训练的第一步是数据。法律领域数据有几个特点文本质量高但数量有限、专业性强但分布不均、公开语料多但可用指令少。在法律场景中常见的数据来源包括法律法规库法条原文、立法说明、司法解释裁判文书法院判决书、裁定书、调解书合同文本各类合同模板、审查意见、修改记录法律咨询记录用户提问与律师回答的问答对内部知识库律所沉淀的法律研究、备忘录、培训材料。原始数据不能直接用于训练需要经过清洗、标注、改写等环节。一个典型的法律后训练样本会包含一段用户咨询、一段专业律师的回答、以及回答引用的法条依据。有些公司会借助更强的模型如 Kimi K3 或 GPT 级别模型做数据增强生成更多高质量的指令数据但必须经过人工审核避免模型“自以为是”地生成错误法律知识。3.2 领域对齐与输出稳定性法律领域的对齐训练重点不是让模型“更礼貌”而是让模型“更可靠”。这里有几个关键问题需要解决法条引用一致性模型回答中出现的法条名称、条款序号、生效状态必须准确结论严谨性模型不能把“可能”说成“一定”不能把“倾向性意见”说成“确定性结论”格式规范性法律文书有固定格式模型输出需要对齐专业排版风险提示意识合同审查中模型需要识别高风险的免责条款、违约责任不明、争议解决约定缺失等问题。这些目标不能只靠 SFT 完成往往需要在 RLHF/DPO 阶段设计专门的偏好数据。比如同一个合同风险点一个回答直接给出结论另一个回答给出“结论 法律依据 修改建议 风险等级”训练目标就是让模型学会后者。3.3 长上下文与复杂法律文档法律场景对长上下文的依赖非常高。一份并购合同可能有上百页一份诉讼材料可能包含几十份证据附件。模型需要做到从长文档中定位关键条款对前后矛盾的内容进行识别结合全文上下文回答具体问题在超长输入下保持输出质量不退化。Kimi K3 在长上下文方面有先天优势这也是 Harvey 选择它作为基座的重要原因之一。在模型能力的基础之上工程层面通常还会配合 RAG检索增强生成、分段处理、关键信息抽取等手段共同解决超长文档的应用难题。3.4 评测体系设计法律模型怎么“考试”后训练必须配套评测体系否则就是“盲调”。法律领域模型的评测通常分几个层次通用能力评测用公开数据集验证模型在推理、语言理解、知识问答上的基础能力没有明显退化法律知识评测用律师资格考试题、法条问答、法律案例分析等数据验证模型的法律知识掌握程度业务场景评测模拟律师真实工作流输入一份合同或一段案情描述让模型完成审查、起草、归纳等任务再由资深律师打分红队测试主动构造刁钻提问、诱导性问题、敏感内容边界测试模型的鲁棒性和安全性。Harvey Tenet 这类产品级模型评测一定是靠“资深律师人工评估 自动化指标”双轨推进。真正决定模型能不能上线的不是 benchmark 数字而是律师在实际工作中愿不愿意使用。4. 从模型到应用Harvey Tenet 的落地架构4.1 一条完整的调用链路后训练只是第一步从模型到可用的产品还需要一套完整的工程链路。下图用文字描述一条典型链路用户请求 ↓ 网关层认证、限流、权限校验 ↓ 应用层对话管理、提示词组装、上下文处理 ↓ 模型推理层Kimi K3 基座 / Harvey Tenet 后训练模型 ↓ 检索增强层法律知识库、案例库、合同库 ↓ 后处理层格式校验、法条校验、风险回调 ↓ 响应返回在实际业务中Harvey Tenet 不会单独工作。它通常需要和检索系统配合当用户问“某个条款是否有效”时模型先触发检索组件从法规库中召回相关法条然后基于召回内容组织回答。这样可以显著降低模型“记忆模糊”导致的引用错误。4.2 推理部署与成本控制2.8T 总参数量的 MoE 模型本地完整部署的成本非常高。工程上通常有以下几种做法完整部署配备多张高端 GPU加载完整模型适合对延迟和效果要求极高的场景量化部署采用 INT8、INT4 等量化方式降低显存占用但可能带来一定精度损失云 API 调用通过官方 API 或第三方平台调用按 token 计费适合中小企业和快速原型混合部署推理层用通用 API关键场景才调用完整模型或专用后训练模型。对于 Harvey 这类 To B 服务公司成本控制非常关键。它们的推理架构可能会考虑批处理优化、缓存命中、动态路由等策略让简单问题走轻量模型、复杂问题走大模型从而降低平均调用成本。4.3 RAG 与后训练模型的协同RAG检索增强生成和模型后训练不是“二选一”而是互补关系。后训练解决的是“模型会不会答”的问题模型是否掌握法律文书的表述习惯、是否知道如何引用法条、是否能在回答中体现专业逻辑。RAG 解决的是“模型依据什么答”的问题每一次回答都有实时检索到的资料作为依据法条更新、新案例发布、客户特定文档库中的内容都可以即时接入。在 Harvey Tenet 的架构中长上下文模型本身可以处理大量输入材料但面对海量知识库时仍然需要先用检索缩小范围再交给模型生成答案。两者结合的典型做法是用户问题 → 意图识别判断需要检索还是直接回答 → 检索从法规库/案例库/知识库召回 Top-K 内容 → 组装将检索结果与用户问题拼接到上下文中 → 生成Harvey Tenet 基于完整上下文输出回答 → 校验检查回答中的引用是否与检索结果一致这种模式下模型的“专业性”和“事实准确性”都能得到保障。5. 面向开发者的后训练实操思路虽然我们无法复现 Harvey Tenet 的全部细节但可以梳理一套通用“垂直领域后训练”的实操路径。下面的示例以代码形式演示重点展示思路实际训练时需根据数据量和硬件条件调整。5.1 数据准备JSONL 指令集后训练数据最常用的格式是 JSONLJSON Lines每行一条样本。SFT 阶段的核心格式如下{ instruction: 请审查以下合同条款的风险并给出修改建议。, input: 甲方因业务需要委托乙方提供技术服务服务费用为人民币贰拾万元整该费用包含所有税费甲方无需另行承担任何其他费用。, output: 风险点该条款中包含所有税费的表述过于宽泛未明确税费种类和承担方式可能导致实际执行中的争议。建议修改为服务费用为人民币贰拾万元整该费用包含增值税及其他附加税费除此之外甲方无需承担任何其他费用。修改依据根据《中华人民共和国民法典》第五百一十条合同内容约定不明确的可以协议补充不能达成补充协议的按照合同相关条款或者交易习惯确定。 }实际构建数据时需要注意以下原则每条数据都要有明确的任务类型标签如“合同审查”“法条问答”“文书起草”“案例分析”回答要尽量完整包含结论、理由、依据三个部分不同律所、不同业务线的格式规范可能不同数据要按业务场景分层。5.2 训练代码骨架SFT 阶段以 Hugging Face TRL 库为例SFT 训练的核心逻辑如下。这是一个简化示例实际训练需要根据模型和硬件调整参数# 文件路径train_sft.py # 说明这是一个 SFT 训练的通用示例请根据实际模型与数据量调整参数 from datasets import load_dataset from transformers import AutoModelForCausalLM, AutoTokenizer from trl import SFTTrainer, DataCollatorForCompletionOnlyLM import torch # 1. 加载基座模型和 tokenizer model_name your-base-model # 示例中为基座模型路径 model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.bfloat16, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(model_name) tokenizer.pad_token tokenizer.eos_token # 2. 加载训练数据 dataset load_dataset(json, data_fileslegal_sft_data.jsonl, splittrain) # 3. 构建指令模板 def format_instruction(example): return { text: f### 指令\n{example[instruction]}\n\n f### 输入\n{example[input]}\n\n f### 回答\n{example[output]} } formatted_dataset dataset.map(format_instruction) # 4. 配置训练器 trainer SFTTrainer( modelmodel, tokenizertokenizer, train_datasetformatted_dataset, max_seq_length8192, dataset_text_fieldtext, argsTrainingArguments( output_dir./legal-sft-checkpoints, per_device_train_batch_size1, gradient_accumulation_steps16, learning_rate2e-5, num_train_epochs3, logging_steps10, save_steps500, fp16False, bf16True, ), ) trainer.train()### 5.3 从 SFT 到偏好优化DPO 简化示例 SFT 完成后模型已经具备了基础的领域问答能力但还需要进一步对齐。以 DPO 为例数据格式包含“提示词”“偏好回答”和“非偏好回答”三部分 json { prompt: 当事人询问合同违约金过高是否可以请求调整请给出专业答复。, chosen: 根据《中华人民共和国民法典》第五百八十五条约定的违约金过分高于造成的损失的当事人可以请求人民法院或者仲裁机构予以适当减少。具体的判断标准需要结合实际损失、合同履行情况等因素综合认定。, rejected: 违约金过高可以自己直接不付只要说太高了就行。 }DPO 训练的核心思路是让模型在“偏好回答”和“非偏好回答”之间学会选择更优的输出。训练代码通常基于DPOTrainer实现# 文件路径train_dpo.py # 说明这是一个 DPO 训练的通用示例请按实际库版本调整 from datasets import load_dataset from transformers import AutoModelForCausalLM, AutoTokenizer from trl import DPOTrainer, DPOConfig model AutoModelForCausalLM.from_pretrained(your-sft-model) tokenizer AutoTokenizer.from_pretrained(your-sft-model) dataset load_dataset(json, data_fileslegal_dpo_data.jsonl, splittrain) dpo_config DPOConfig( output_dir./legal-dpo-checkpoints, per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate1e-6, bf16True, max_length4096, ) trainer DPOTrainer( modelmodel, ref_modelNone, argsdpo_config, train_datasetdataset, tokenizertokenizer, ) trainer.train()### 5.4 推理验证 训练完成后需要验证模型效果。用 OpenAI 兼容接口的方式比较通用也可以用简单的 transformers 推理 python # 文件路径inference.py # 说明模型推理验证示例 from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_path ./legal-dpo-checkpoints/final model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.bfloat16, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(model_path) prompt 请对以下条款进行风险审查任何一方违约均应向对方支付违约金违约金为合同总金额的50%。 messages [{role: user, content: prompt}] inputs tokenizer.apply_chat_template( messages, add_generation_promptTrue, return_tensorspt, ).to(model.device) outputs model.generate( inputs, max_new_tokens1024, temperature0.3, do_sampleTrue, top_p0.9, ) response tokenizer.decode(outputs[0][inputs.shape[1]:], skip_special_tokensTrue) print(response)这里的推理参数非常关键。法律场景建议使用较低的温度如 0.2~0.4降低输出的随机性提升回答的一致性。同时需要结合法条校验、格式校验等后处理环节确保最终输出是可靠的。 ## 6. 常见问题与排查思路 垂直领域后训练在实施过程中会遇到很多问题下面整理了一份高频问题清单方便你对照排查。 | 问题现象 | 常见原因 | 排查思路与解决方案 | | --- | --- | --- | | 训练后模型在通用能力上明显退化 | 领域数据占比过高导致灾难性遗忘 | 减少领域数据比例增加通用指令数据混入降低学习率在训练过程中加入通用能力评测集观察指标变化 | | 模型回答中引用错误法条 | 训练数据中引注不准确或模型依赖记忆而非检索 | 建立法条引用校验机制回答生成后与法规库交叉比对将关键回答改为“检索 生成”链路 | | 长文档场景下模型丢失上下文 | 单轮输入过长模型注意力分散检索召回不精准 | 对长文档做分段处理利用长上下文模型微调加入“定位 总结”任务优化 RAG 的 chunk 划分策略 | | 模型输出格式不符合法律文书规范 | SFT 数据中格式样本不足 | 提高标准文书数据比例在 prompt 中加入格式示例训练后用规则校验格式不符合则重试 | | 训练 loss 下降但业务效果没提升 | 评测指标与业务目标脱节 | 增加业务场景评测集邀请领域专家进行人工盲评检查训练数据是否覆盖真实业务场景 | | 推理延迟高成本难以接受 | MoE 模型参数规模大部署配置不合理 | 使用 vLLM、SGLang 等推理加速框架开启前缀缓存考虑量化对简单问题分流到轻量模型 | | 模型容易给出确定性法律结论 | 对齐训练中缺少对“不确定性表达”的偏好数据 | 在 DPO 阶段构造“结论 不确定性说明 建议咨询律师”样本设置输出边界提示词 | ## 7. 最佳实践与工程建议 ### 7.1 数据质量永远是第一优先级 后训练的效果上限很大程度上由数据质量决定。领域后训练不是“数据量越大越好”而是“高质量数据占比越合理越好”。一条由资深律师撰写、包含完整法律逻辑和法条依据的回答其训练价值可能远高于一百条从网上爬来的问答。 建议建立数据分级制度核心数据资深律师审核过的标准问答用于训练辅助数据经过脱敏的客户文档用于扩展场景覆盖噪声数据未经验证的网络内容只做预训练补充。 ### 7.2 先小步验证再全量训练 在正式启动大规模训练之前建议先用小规模数据做一次“冒烟测试”确认以下事项 - 数据格式是否符合代码要求 - 训练流程能否跑通 - 模型输出是否符合预期格式 - 显存、耗时、 loss 曲线是否正常。 小步验证可以大幅降低训练失败的成本。尤其对于 MoE 大模型一次训练失败可能意味着数万元的成本浪费。 ### 7.3 建立“评测—训练—回归”闭环 领域后训练最忌讳“只训练、不评测”。建议在训练过程中设置多个评测节点训练前评测基座模型的基线表现SFT 中间阶段做快速评测最终训练完成后做全面评测。 评测集至少要包含三部分通用能力集防止模型变傻、法律知识集确认专业能力提升、业务场景集确认用户问题可解决。每次新增训练数据或调整训练策略都要回到这套评测体系做回归。 ### 7.4 安全与合规优先 法律 AI 涉及大量敏感信息在数据合规方面需要特别注意 - 训练数据必须经过脱敏处理禁止使用真实客户名称、案件细节、个人隐私信息 - 模型输出需要包含免责声明说明 AI 建议不构成正式法律意见 - 涉及律所内部知识时需要获得明确的授权 - 模型上线前应做内容安全测试防止被诱导输出不当内容。 ### 7.5 关注长上下文的收益与成本 在类似 Harvey Tenet 这种长文本场景中长上下文能力意味着更好的体验但也会带来更高的推理成本。工程上建议 - 对输入内容做预处理去除无关信息后再送入模型 - 对超长文档采用“先检索、后阅读”的策略而不是直接把全部内容塞给模型 - 合理设置 max_length避免无效计算。 ## 8. 结语垂直领域后训练会走向哪里 Harvey 推出 Harvey Tenet 这件事释放了一个明确的信号通用大模型的竞争正在进入“能力外溢”阶段——模型基础能力越来越强真正的差异化在于谁能把通用能力转化成特定行业的可用价值。 从技术路线来看长期占据主流的方式很可能不是“从零训练行业大模型”而是“优秀基座 深度后训练 领域知识工程”的组合。基座负责通用能力后训练负责领域专业性RAG 和工具链负责事实准确性和业务闭环。 对于正在考虑做自己领域模型的团队我的建议是先用现成的通用模型搭配 RAG 和提示词工程跑通场景找出真实瓶颈如果瓶颈确实是模型能力不足再启动后训练。后训练不是万能的但它确实是在通用模型走到天花板之后进一步拉开差距的有效手段。 最后补充一句模型参数规模、训练数据、评测体系、工程架构这些元素单看都能理解但真正决定一个领域模型成败的是整套体系的配合。Harvey Tenet 是这套思路的一个参照样本后面的路还很长。