2025 年当一家拿过 OpenAI 投资、面向美国法律行业的 AI 公司 Harvey 被报道转用中国开源模型 Kimi K3 来打造专属模型时很多人第一反应是“又一家公司换了底座”。但这件事值得停下来多想一想。它真正释放的信号不是“某家供应商不够强”而是垂直行业 AI 的模型供应链正在从“单一依赖某个闭源 API”走向“开源底座 专属后训练”的组合模式。法律行业通常不是最激进采用新技术的行业恰恰因为它的保守这个变化反而更有参考价值。1. 为什么一家拿了 OpenAI 投资的明星法律 AI 公司会换底座1.1 不是“OpenAI 不行了”而是“不能只有一条路”Harvey 曾经是 OpenAI 投资生态里很有代表性的法律 AI 案例主打合同审查、法律检索、文档分析这些高价值场景。这样的公司选择不再把 OpenAI API 作为唯一底座很多人可能解读为“OpenAI 能力不够了”我不太认同这个判断。更合理的解释是当一家公司把模型能力嵌入到客户的真实业务里尤其是法律这种高风险、强合规的业务里单点依赖会变成一个越来越危险的事情。闭源 API 的接口升级、定价调整、服务条款变化、数据流向政策每一项都可能在某个时间点影响下游产品的成本和合规性。模型能力确实重要但模型的可替换性和模型本身的能力一样重要。对 Harvey 这种面向律所和大型企业法务部的公司来说客户会问的问题往往不是“你的模型是不是最强”而是我的案件数据会不会离开我的合规边界如果模型服务出问题我能不能自己接管我需要调整模型输出风格时你改得了吗如果供应商涨价我的成本会失控吗这些问题决定了像 Harvey 这类公司必须考虑“多条腿走路”。保留 OpenAI 或其他闭源模型作为能力补充同时引入一个可私有化部署、可二次训练的开源基座是一种更稳的模型供应链策略。1.2 成本结构API 按量计费在专业场景里会被放大法律文档处理的 token 消耗量和普通聊天完全不是一个量级。一份长合同可能几万 token一个复杂的尽调项目可能涉及几百份文档如果每条分析都按 API token 计费成本会随着业务量线性膨胀。开源模型改变的不是“贵不贵”而是成本结构。闭源 API 是按次计费用量上来之后是纯变动成本自建开源模型是“固定算力成本 维护成本”前期投入高但稳定用量下更容易预测也更容易在算力池中摊薄。当然这不是说开源一定比闭源便宜。如果你的业务量很小或者团队没有懂推理部署的人直接用 API 反而划算。但一旦业务进入规模化阶段“成本可预测性”就成了产品设计的一部分。这也是 Harvey 这类公司选择开源模型的一个现实原因。1.3 法律行业的合规约束天然要求模型可以私有化法律行业有一个和其他行业不太一样的特点客户对数据边界极度敏感。律师和法务部处理的很多文件涉及商业秘密、并购条款、未公开交易、诉讼策略这些内容一旦离开客户的可控范围就构成合规风险。所以法律科技公司在选择底层模型时不仅要看“模型答得好不好”还要看“模型部署在哪里、数据流向哪里、日志归谁管”。闭源 API 即便提供企业版也未必能满足所有司法管辖区和大型客户的内部合规要求。开源权重模型是解决这个问题的一条可行路径模型可以部署在客户的私有云或本地环境里数据预处理、推理过程、日志审计全都在自己的边界内完成。很多律所不是不接受 AI而是不接受“数据出去”的 AI。Harvey 转用开源模型本质上是在回应这个客户需求。这里需要澄清一个常见的误解使用开源模型不等于把自己的专属模型开源。基座模型开源是为了让别人可部署、可定制而 Harvey 在法律数据上继续做训练后得到的专属模型依然可以作为商业产品保持闭源。两者并不矛盾。2. 法律 AI 真正难的不是“会聊天”而是可审计、可纠错、可追责2.1 法律场景的容错率极低通用聊天模型偶尔答错用户顶多觉得“AI 有点笨”。但法律文书里的一个错误引用、一个遗漏条款、一个不准确的判例都可能带来真实的经济后果和职业风险。法律 AI 的输出必须能回到原始依据必须让律师能审阅、能追溯、能给出最终判断。这意味着法律 AI 的能力评价体系不能只看“生成质量”还要看是否引用了真实的法律条文、合同条款或案例引用是否准确是否有原文对照模型在不确定时是否会明确表示不确定输出结果能否纳入现有的文档管理和知识管理系统。这些要求已经超出“大模型生成能力”本身进入“系统设计和流程控制”的范畴。所以法律 AI 行业真正的门槛不是调一个最好的模型而是构建一套可审计的 AI 业务流程。2.2 开源模型让“可解释”成为可执行的工程任务闭源 API 本质上是一个黑盒。你可以拿到输入和输出但很难拿到中间层表征、注意力分布或者是哪一段上下文导致了这个回答。当业务出问题时你缺少排查手段。开源模型则不同。权重是开放的你可以记录每一层推理日志做针对性探测在特定数据上微调行为甚至可以修复被发现的错误模式。这个过程虽然需要不少工程投入但让“可解释”“可追溯”“可改进”从概念变成了工程能力。对于法律科技公司来说这种能力不是加分项而是基本要求。律师把专业判断交给系统之前必须知道系统为什么给出这个结论如果错了问题出在哪一层。2.3 专属模型不是“从零训练”而是“基座 领域适配”很多人听到“打造专属模型”会以为是从零搞一个参数巨大的模型出来。实际工程上更常见的是选择一个合适的开源基座模型然后在它之上做领域适配。领域适配的手段包括检索增强生成把法律库和案例库接进来指令微调让模型学会“法律助理式”的表达偏好对齐让模型输出的风格和结构更符合律师习惯评测驱动的迭代持续发现短板并修正。Kimi K3 之所以会被 Harvey 这类法律 AI 公司看中一个合理的推测是它在长文本处理和复杂推理方面有比较强的能力同时开放权重可以被用来做私有化部署和二次训练。法律文档普遍很长一个合同、一份判决书、一部法规动辄几万字模型如果处理不了长上下文后面的领域适配就无从谈起。但我也要提醒不要因为一个模型是开源的就默认它适合你的领域。开源只是给你“改造权”适不适合还是要通过你自己的业务评测数据来验证。3. 从 Kimi K3 到“你的模型”本地部署的工程顺序3.1 先看模型卡别被参数量带偏围绕 Kimi K3社区讨论里最常见的是参数量、架构、排行榜分数这类信息。但如果你真的想基于它做专属模型第一步不是研究参数而是看模型卡里的几个关键信息上下文窗口长度推理时的激活参数和显存估算开源协议允许什么商业使用、二次发布、修改预训练和后训练所用的数据语言分布官方推荐的推理框架和版本。参数量大不代表推理时一定需要那么多显存尤其在 MoE 架构下总参数量和激活参数是两个概念。选型阶段重要的是“在你能承受的硬件条件下这个模型的可用上下文和推理质量是否达到业务门槛”。3.2 本地部署一个开源大模型的最小路径如果你在本地或私有云环境部署这类开源模型通常可以按下面的路径走。这里以常见的 Hugging Face 模型仓库格式和 vLLM 推理框架为例具体命令在实际项目中要按环境调整。第一步准备推理环境。你需要至少一台带 NVIDIA GPU 的机器显存大小取决于模型规模和上下文长度。最小验证阶段可以先用小上下文窗口跑通流程。第二步下载模型权重。大部分开源模型会发布在模型仓库中如果下载速度不理想可以使用国内镜像源。第三步启动推理服务。常见写法类似vllm serve /path/to/model \ --tensor-parallel-size 2 \ --max-model-len 128000这里的--tensor-parallel-size表示用几张 GPU 切分模型--max-model-len控制最大上下文长度。实际参数要结合你的显存和模型要求调整。第四步用一条典型的业务样例做验证。不要只问“你好”要拿一段真实的长文档试确认模型能正常接收长输入并返回合理结果。第五步把服务接入你的应用。现在很多推理框架提供 OpenAI 兼容接口上层业务代码可以尽量保持稳定这样以后换模型时改动会小很多。注意不要一上来就把最大上下文窗口拉满也不要在小显存机器上强行加载大模型。先用小窗口、小批量验证流程再逐步放大。3.3 真正要估的不是总参数量而是显存和吞吐量部署大模型最容易算错的就是显存模型权重本身需要显存推理过程中的 KV Cache 需要显存长上下文下KV Cache 会快速膨胀如果多人并发显存压力会叠加。MoE 类模型虽然总参数很大但推理时只激活一部分专家权重显存和激活显存需要分别评估。工程上常用的经验是先按“权重显存 上下文长度的 KV Cache 预留”来做估算再用真实负载压测。如果显存确实不够一个缓解手段是量化。用 8bit 或 4bit 加载模型可以显著降低显存占用但代价是推理效果可能下降。法律场景尤其要小心因为量化后最容易出问题的往往是对数字、条款编号、专有名词的精确引用。如果业务里有很多“必须一字不差”的任务量化后要单独做一轮精度验证。3.4 长文档支持是法律场景的硬门槛法律 AI 很大一部分工作围绕长文档展开。部署时你要确认推理框架支持的上下文上限而不是只依赖模型原始上下文长度。实际使用中还需要关注两个指标长文本下的首 token 延迟模型需要多长时间才开始输出长文本下的准确率上下文越长模型出现“中间遗忘”或“错误注意力”的概率可能越高。建议建立一套“长文档评测集”里面放几份有明确答案的合同或法律文本反复测试不同上下文长度下的效果而不是只看短问答。3.5 服务化之后别忘了日志、权限和审计法律场景下模型服务上线后需要记录谁调用了模型、输入了什么、输出了什么、有没有人工复核。所以部署模型从来不只是“把服务跑起来”还包括日志系统、权限控制、审计追踪和版本回滚。这也是很多技术团队低估的部分。一个模型服务上线简单真正难的是它变成一个稳定、可运维、可审计的内部系统。建议在第一天就把日志结构和权限模型定义好不要等服务被人调用之后再补。4. 基于开源底座做专属模型先 RAG再微调最后对齐4.1 先用 RAG 解决“知识更新”和“引用来源”法律知识的特点是总量大、更新快、权威来源分散。一个模型不可能把所有法律知识都装进参数里及时权威的知识应该放在知识库里。RAG 的基本思路是收到用户问题后先从法律库、案例库、公司内部文档中检索相关片段再把片段和原始问题一起交给模型让模型基于这些材料回答并标注引用来源。对法律场景来说RAG 不只是一个提升准确率的手段更是可审计性的基础。因为答案可以对照检索到的原文用户能看到模型“引用了什么”。如果引用错误可以直接调整检索逻辑而不是重新训练模型。4.2 指令微调解决“行业表达方式”问题当 RAG 无法满足一些固定表达或结构化输出要求时可以考虑指令微调。法律场景有很多固定任务类型例如把一段自然语言契约需求转换成条款清单从一份合同里抽取关键风险点并分类把判决结果改写成特定格式的摘要根据法条和案情给出“是/否/需人工判断”的分类建议。这些任务的输入输出结构相对固定使用一批高质量标注数据对基座模型做有监督微调可以明显提升输出稳定性和格式一致性。这里有一个关键提醒指令微调的样本质量比数量重要。几十条精心构造、覆盖典型边界的样本往往比几千条重复样更有价值。法律场景尤其如此一个边界案例可能比一百个常规案例更能暴露模型的薄弱点。4.3 偏好对齐是深度打磨阶段完成指令微调后模型已经能按任务输出但在表达习惯、逻辑结构、风险提示方式上可能还不完全像一个资深律师。这个阶段可以通过人类反馈来对齐模型偏好。标注人员通常是法律专业人士他们会对模型的多组输出做排序或评分再用 DPO 等方法让模型学会“律师更认可的答案”。这个阶段成本最高周期最长。很多团队会忽略或急于跳过。但真正让模型从“能用”变成“好用”的往往就是这轮反馈对齐。4.4 不要一开始就全做先跑通“最小可用闭环”我更建议的路径是先部署开源基座模型用 RAG 接入领域知识用小规模指令集做一次微调建立评测集验证效果如果效果稳定再引入偏好对齐。不要一上来就规划一个“大模型训练平台”也不要第一版就追求覆盖所有法律场景。先把一条流程跑通再逐步扩展范围。5. 这个变化真正意味着什么基座模型正在变成可替换的基础设施5.1 从“订阅一个超级大脑”到“组装一套模型系统”过去两年很多垂直行业 AI 公司的打法是接入一个强大的闭源模型 API然后在上面写提示词和业务逻辑。这个模式启动快但到了某个阶段会遇到明显瓶颈模型能力超出业务需求的部分你也在付费模型行为和业务规范不完全一致只能靠提示词硬凑供应商一改接口或策略整个产品都要跟着调整。Harvey 转向“开源模型 专属模型”这个组合实质上是在把模型从“单一供应商”变成“可替换基础设施”。未来垂直行业 AI 公司的核心能力将不再是你用了哪家模型而是你如何围绕模型构建数据管道、评测体系、反馈闭环和行业工作流。5.2 垂直行业的护城河不在基座而在数据和反馈闭环基座模型的差距会随着技术迭代逐渐缩小但垂直行业里真正难复制的资产是这些高质量法律数据管道围绕业务场景构建的评测集资深从业者参与反馈标注的机制与客户的信任关系和对流程的深度理解。这些能力需要时间积累也难以通过采购获得。所以对 Harvey 这类公司来说把基座模型换成开源版本并不是放弃技术壁垒而是把研发资源集中在壁垒更高的地方。5.3 团队能力模型也会跟着变化这个变化带来的另一个直接影响是垂直行业 AI 团队的人才结构开始改变。过去一个“懂提示词 会调 API”的团队就可以做一款 AI 产品。现在当模型变成可替换组件之后团队需要补充这些能力推理框架和模型部署能力数据清洗和标注管理能力模型评测和回归测试能力运维监控和审计能力。这不是说每个团队都要变成大模型实验室而是说“能稳定地使用开源模型”正在成为垂直 AI 团队的基础能力。对于技术负责人来说这可能意味着招聘策略、技术栈选型和项目排期都要重新考虑。5.4 对普通开发者的启示把“换模型”纳入架构设计即使你的项目今天还在用闭源 API设计时也应该预留换模型的空间。一个简单的做法是在上层业务逻辑和底层模型之间加一个抽象接口统一输入输出格式尽量使用 OpenAI 兼容接口这类通用协议沉淀一套属于自己项目的评测集对关键 prompt 和上下文模板做版本管理。这样当新的开源模型发布时你可以快速做一次对比评测而不是推倒重来。今天的开源模型生态已经让“换底座”变成一件技术上可行的事剩下的就是业务上要不要换、什么时候换的问题。6. 落地最容易踩的坑以及一条排查链路6.1 部署三座大山显存、版本、上下文超限实际部署开源模型团队最常见的三个问题第一是显存不足。解决思路不是盲目换更大的机器而是先降低上下文长度、开启量化、减少并发确认模型本身能正常工作。第二是版本冲突。PyTorch、CUDA、vLLM、transformers 这些库之间的版本经常互相影响。建议使用虚拟环境或者直接用官方推荐的 Docker 镜像。第三是上下文超限。输入文档过长时服务可能直接报错也可能静默截断。要在接入层设置文档长度检查并在产品上给用户明确提示。下面是一个简单的排查顺序现象先查什么再查什么最后查什么服务启动失败显存是否足够CUDA 和推理框架版本模型文件是否完整请求报长度超限输入文档实际长度服务端上下文上限配置是否有截断逻辑回答明显错误输入文档是否完整RAG 检索结果是否相关提示词是否产生误导并发一高就卡显存占用是否打满队列和超时配置是否需要多卡或负载均衡6.2 效果不好先排查输入和评测别急着换模型很多团队在模型效果不佳时第一反应是“这个模型不行换一个”。但很多时候问题不在模型而在输入侧和评测侧上传的文档格式不对解析后丢了很多内容检索到的知识片段不够完整模型只能基于残缺信息回答提示词里没有约束“依据引用回答”模型自由发挥评测集本身没有标准答案评审者凭感觉打分结论不可复现。正确的排查顺序是从数据输入开始一步步看链路哪里断了。先确认“模型拿到的输入是正确的”再分析“模型的输出为什么偏差”。一个实用的办法是遇到一个错误输出时先把同样的输入分别发给“纯提示词模式”和“RAG 模式”看看差异是否来自检索。如果 RAG 模式更差问题往往在检索到的片段而不是生成模型。6.3 开源协议和维护风险是长期问题使用开源模型还有一个容易被忽略的风险开源协议的边界。不同模型采用不同的许可证商业使用、二次修改、对外提供服务、再分发等场景可能有不同限制。在把某个开源模型纳入产品体系之前建议法务和技术团队一起把模型许可证、依赖组件许可证、训练数据使用条款都审一遍。长期使用还要考虑模型更新节奏、社区活跃度、以及如果项目停止维护你的团队是否有能力接管。建议把模型许可证和依赖版本写进项目的 README 和依赖清单里不要只在部署时临时确认。6.4 一条可复用的落地检查清单如果要把这次讨论落到一个可执行框架可以总结成“先验证、再适配、最后工程化”用一条贴近真实业务的长文档跑通开源模型部署用小规模领域评测集确认基座模型是否够用搭建 RAG 检索链路验证引用准确率用几百条高质量指令样本做一次微调上线前完成日志、权限、审计、回滚和监控持续收集真实反馈把错误案例沉淀进评测集。这套流程对法律 AI 适用对其他垂直行业同样适用。底层的逻辑是一样的技术变化永远会有下一波但围绕业务闭环构建的评测和迭代能力才是长期价值所在。所以如果 Harvey 换底座这件事对你有什么参考价值我的建议很直接不要急着把现有模型换掉而是先在你自己最看重的几个业务任务上准备一份评测集把当前模型的表现记录下来。等下一个开源模型发布时用同一份评测集跑一次用数据决定要不要换。能持续做这件事的团队才是未来垂直行业 AI 竞争里真正有主动权的人。 法律AI换用开源模型背后：垂直行业模型供应链的转型与落地实践
2025 年当一家拿过 OpenAI 投资、面向美国法律行业的 AI 公司 Harvey 被报道转用中国开源模型 Kimi K3 来打造专属模型时很多人第一反应是“又一家公司换了底座”。但这件事值得停下来多想一想。它真正释放的信号不是“某家供应商不够强”而是垂直行业 AI 的模型供应链正在从“单一依赖某个闭源 API”走向“开源底座 专属后训练”的组合模式。法律行业通常不是最激进采用新技术的行业恰恰因为它的保守这个变化反而更有参考价值。1. 为什么一家拿了 OpenAI 投资的明星法律 AI 公司会换底座1.1 不是“OpenAI 不行了”而是“不能只有一条路”Harvey 曾经是 OpenAI 投资生态里很有代表性的法律 AI 案例主打合同审查、法律检索、文档分析这些高价值场景。这样的公司选择不再把 OpenAI API 作为唯一底座很多人可能解读为“OpenAI 能力不够了”我不太认同这个判断。更合理的解释是当一家公司把模型能力嵌入到客户的真实业务里尤其是法律这种高风险、强合规的业务里单点依赖会变成一个越来越危险的事情。闭源 API 的接口升级、定价调整、服务条款变化、数据流向政策每一项都可能在某个时间点影响下游产品的成本和合规性。模型能力确实重要但模型的可替换性和模型本身的能力一样重要。对 Harvey 这种面向律所和大型企业法务部的公司来说客户会问的问题往往不是“你的模型是不是最强”而是我的案件数据会不会离开我的合规边界如果模型服务出问题我能不能自己接管我需要调整模型输出风格时你改得了吗如果供应商涨价我的成本会失控吗这些问题决定了像 Harvey 这类公司必须考虑“多条腿走路”。保留 OpenAI 或其他闭源模型作为能力补充同时引入一个可私有化部署、可二次训练的开源基座是一种更稳的模型供应链策略。1.2 成本结构API 按量计费在专业场景里会被放大法律文档处理的 token 消耗量和普通聊天完全不是一个量级。一份长合同可能几万 token一个复杂的尽调项目可能涉及几百份文档如果每条分析都按 API token 计费成本会随着业务量线性膨胀。开源模型改变的不是“贵不贵”而是成本结构。闭源 API 是按次计费用量上来之后是纯变动成本自建开源模型是“固定算力成本 维护成本”前期投入高但稳定用量下更容易预测也更容易在算力池中摊薄。当然这不是说开源一定比闭源便宜。如果你的业务量很小或者团队没有懂推理部署的人直接用 API 反而划算。但一旦业务进入规模化阶段“成本可预测性”就成了产品设计的一部分。这也是 Harvey 这类公司选择开源模型的一个现实原因。1.3 法律行业的合规约束天然要求模型可以私有化法律行业有一个和其他行业不太一样的特点客户对数据边界极度敏感。律师和法务部处理的很多文件涉及商业秘密、并购条款、未公开交易、诉讼策略这些内容一旦离开客户的可控范围就构成合规风险。所以法律科技公司在选择底层模型时不仅要看“模型答得好不好”还要看“模型部署在哪里、数据流向哪里、日志归谁管”。闭源 API 即便提供企业版也未必能满足所有司法管辖区和大型客户的内部合规要求。开源权重模型是解决这个问题的一条可行路径模型可以部署在客户的私有云或本地环境里数据预处理、推理过程、日志审计全都在自己的边界内完成。很多律所不是不接受 AI而是不接受“数据出去”的 AI。Harvey 转用开源模型本质上是在回应这个客户需求。这里需要澄清一个常见的误解使用开源模型不等于把自己的专属模型开源。基座模型开源是为了让别人可部署、可定制而 Harvey 在法律数据上继续做训练后得到的专属模型依然可以作为商业产品保持闭源。两者并不矛盾。2. 法律 AI 真正难的不是“会聊天”而是可审计、可纠错、可追责2.1 法律场景的容错率极低通用聊天模型偶尔答错用户顶多觉得“AI 有点笨”。但法律文书里的一个错误引用、一个遗漏条款、一个不准确的判例都可能带来真实的经济后果和职业风险。法律 AI 的输出必须能回到原始依据必须让律师能审阅、能追溯、能给出最终判断。这意味着法律 AI 的能力评价体系不能只看“生成质量”还要看是否引用了真实的法律条文、合同条款或案例引用是否准确是否有原文对照模型在不确定时是否会明确表示不确定输出结果能否纳入现有的文档管理和知识管理系统。这些要求已经超出“大模型生成能力”本身进入“系统设计和流程控制”的范畴。所以法律 AI 行业真正的门槛不是调一个最好的模型而是构建一套可审计的 AI 业务流程。2.2 开源模型让“可解释”成为可执行的工程任务闭源 API 本质上是一个黑盒。你可以拿到输入和输出但很难拿到中间层表征、注意力分布或者是哪一段上下文导致了这个回答。当业务出问题时你缺少排查手段。开源模型则不同。权重是开放的你可以记录每一层推理日志做针对性探测在特定数据上微调行为甚至可以修复被发现的错误模式。这个过程虽然需要不少工程投入但让“可解释”“可追溯”“可改进”从概念变成了工程能力。对于法律科技公司来说这种能力不是加分项而是基本要求。律师把专业判断交给系统之前必须知道系统为什么给出这个结论如果错了问题出在哪一层。2.3 专属模型不是“从零训练”而是“基座 领域适配”很多人听到“打造专属模型”会以为是从零搞一个参数巨大的模型出来。实际工程上更常见的是选择一个合适的开源基座模型然后在它之上做领域适配。领域适配的手段包括检索增强生成把法律库和案例库接进来指令微调让模型学会“法律助理式”的表达偏好对齐让模型输出的风格和结构更符合律师习惯评测驱动的迭代持续发现短板并修正。Kimi K3 之所以会被 Harvey 这类法律 AI 公司看中一个合理的推测是它在长文本处理和复杂推理方面有比较强的能力同时开放权重可以被用来做私有化部署和二次训练。法律文档普遍很长一个合同、一份判决书、一部法规动辄几万字模型如果处理不了长上下文后面的领域适配就无从谈起。但我也要提醒不要因为一个模型是开源的就默认它适合你的领域。开源只是给你“改造权”适不适合还是要通过你自己的业务评测数据来验证。3. 从 Kimi K3 到“你的模型”本地部署的工程顺序3.1 先看模型卡别被参数量带偏围绕 Kimi K3社区讨论里最常见的是参数量、架构、排行榜分数这类信息。但如果你真的想基于它做专属模型第一步不是研究参数而是看模型卡里的几个关键信息上下文窗口长度推理时的激活参数和显存估算开源协议允许什么商业使用、二次发布、修改预训练和后训练所用的数据语言分布官方推荐的推理框架和版本。参数量大不代表推理时一定需要那么多显存尤其在 MoE 架构下总参数量和激活参数是两个概念。选型阶段重要的是“在你能承受的硬件条件下这个模型的可用上下文和推理质量是否达到业务门槛”。3.2 本地部署一个开源大模型的最小路径如果你在本地或私有云环境部署这类开源模型通常可以按下面的路径走。这里以常见的 Hugging Face 模型仓库格式和 vLLM 推理框架为例具体命令在实际项目中要按环境调整。第一步准备推理环境。你需要至少一台带 NVIDIA GPU 的机器显存大小取决于模型规模和上下文长度。最小验证阶段可以先用小上下文窗口跑通流程。第二步下载模型权重。大部分开源模型会发布在模型仓库中如果下载速度不理想可以使用国内镜像源。第三步启动推理服务。常见写法类似vllm serve /path/to/model \ --tensor-parallel-size 2 \ --max-model-len 128000这里的--tensor-parallel-size表示用几张 GPU 切分模型--max-model-len控制最大上下文长度。实际参数要结合你的显存和模型要求调整。第四步用一条典型的业务样例做验证。不要只问“你好”要拿一段真实的长文档试确认模型能正常接收长输入并返回合理结果。第五步把服务接入你的应用。现在很多推理框架提供 OpenAI 兼容接口上层业务代码可以尽量保持稳定这样以后换模型时改动会小很多。注意不要一上来就把最大上下文窗口拉满也不要在小显存机器上强行加载大模型。先用小窗口、小批量验证流程再逐步放大。3.3 真正要估的不是总参数量而是显存和吞吐量部署大模型最容易算错的就是显存模型权重本身需要显存推理过程中的 KV Cache 需要显存长上下文下KV Cache 会快速膨胀如果多人并发显存压力会叠加。MoE 类模型虽然总参数很大但推理时只激活一部分专家权重显存和激活显存需要分别评估。工程上常用的经验是先按“权重显存 上下文长度的 KV Cache 预留”来做估算再用真实负载压测。如果显存确实不够一个缓解手段是量化。用 8bit 或 4bit 加载模型可以显著降低显存占用但代价是推理效果可能下降。法律场景尤其要小心因为量化后最容易出问题的往往是对数字、条款编号、专有名词的精确引用。如果业务里有很多“必须一字不差”的任务量化后要单独做一轮精度验证。3.4 长文档支持是法律场景的硬门槛法律 AI 很大一部分工作围绕长文档展开。部署时你要确认推理框架支持的上下文上限而不是只依赖模型原始上下文长度。实际使用中还需要关注两个指标长文本下的首 token 延迟模型需要多长时间才开始输出长文本下的准确率上下文越长模型出现“中间遗忘”或“错误注意力”的概率可能越高。建议建立一套“长文档评测集”里面放几份有明确答案的合同或法律文本反复测试不同上下文长度下的效果而不是只看短问答。3.5 服务化之后别忘了日志、权限和审计法律场景下模型服务上线后需要记录谁调用了模型、输入了什么、输出了什么、有没有人工复核。所以部署模型从来不只是“把服务跑起来”还包括日志系统、权限控制、审计追踪和版本回滚。这也是很多技术团队低估的部分。一个模型服务上线简单真正难的是它变成一个稳定、可运维、可审计的内部系统。建议在第一天就把日志结构和权限模型定义好不要等服务被人调用之后再补。4. 基于开源底座做专属模型先 RAG再微调最后对齐4.1 先用 RAG 解决“知识更新”和“引用来源”法律知识的特点是总量大、更新快、权威来源分散。一个模型不可能把所有法律知识都装进参数里及时权威的知识应该放在知识库里。RAG 的基本思路是收到用户问题后先从法律库、案例库、公司内部文档中检索相关片段再把片段和原始问题一起交给模型让模型基于这些材料回答并标注引用来源。对法律场景来说RAG 不只是一个提升准确率的手段更是可审计性的基础。因为答案可以对照检索到的原文用户能看到模型“引用了什么”。如果引用错误可以直接调整检索逻辑而不是重新训练模型。4.2 指令微调解决“行业表达方式”问题当 RAG 无法满足一些固定表达或结构化输出要求时可以考虑指令微调。法律场景有很多固定任务类型例如把一段自然语言契约需求转换成条款清单从一份合同里抽取关键风险点并分类把判决结果改写成特定格式的摘要根据法条和案情给出“是/否/需人工判断”的分类建议。这些任务的输入输出结构相对固定使用一批高质量标注数据对基座模型做有监督微调可以明显提升输出稳定性和格式一致性。这里有一个关键提醒指令微调的样本质量比数量重要。几十条精心构造、覆盖典型边界的样本往往比几千条重复样更有价值。法律场景尤其如此一个边界案例可能比一百个常规案例更能暴露模型的薄弱点。4.3 偏好对齐是深度打磨阶段完成指令微调后模型已经能按任务输出但在表达习惯、逻辑结构、风险提示方式上可能还不完全像一个资深律师。这个阶段可以通过人类反馈来对齐模型偏好。标注人员通常是法律专业人士他们会对模型的多组输出做排序或评分再用 DPO 等方法让模型学会“律师更认可的答案”。这个阶段成本最高周期最长。很多团队会忽略或急于跳过。但真正让模型从“能用”变成“好用”的往往就是这轮反馈对齐。4.4 不要一开始就全做先跑通“最小可用闭环”我更建议的路径是先部署开源基座模型用 RAG 接入领域知识用小规模指令集做一次微调建立评测集验证效果如果效果稳定再引入偏好对齐。不要一上来就规划一个“大模型训练平台”也不要第一版就追求覆盖所有法律场景。先把一条流程跑通再逐步扩展范围。5. 这个变化真正意味着什么基座模型正在变成可替换的基础设施5.1 从“订阅一个超级大脑”到“组装一套模型系统”过去两年很多垂直行业 AI 公司的打法是接入一个强大的闭源模型 API然后在上面写提示词和业务逻辑。这个模式启动快但到了某个阶段会遇到明显瓶颈模型能力超出业务需求的部分你也在付费模型行为和业务规范不完全一致只能靠提示词硬凑供应商一改接口或策略整个产品都要跟着调整。Harvey 转向“开源模型 专属模型”这个组合实质上是在把模型从“单一供应商”变成“可替换基础设施”。未来垂直行业 AI 公司的核心能力将不再是你用了哪家模型而是你如何围绕模型构建数据管道、评测体系、反馈闭环和行业工作流。5.2 垂直行业的护城河不在基座而在数据和反馈闭环基座模型的差距会随着技术迭代逐渐缩小但垂直行业里真正难复制的资产是这些高质量法律数据管道围绕业务场景构建的评测集资深从业者参与反馈标注的机制与客户的信任关系和对流程的深度理解。这些能力需要时间积累也难以通过采购获得。所以对 Harvey 这类公司来说把基座模型换成开源版本并不是放弃技术壁垒而是把研发资源集中在壁垒更高的地方。5.3 团队能力模型也会跟着变化这个变化带来的另一个直接影响是垂直行业 AI 团队的人才结构开始改变。过去一个“懂提示词 会调 API”的团队就可以做一款 AI 产品。现在当模型变成可替换组件之后团队需要补充这些能力推理框架和模型部署能力数据清洗和标注管理能力模型评测和回归测试能力运维监控和审计能力。这不是说每个团队都要变成大模型实验室而是说“能稳定地使用开源模型”正在成为垂直 AI 团队的基础能力。对于技术负责人来说这可能意味着招聘策略、技术栈选型和项目排期都要重新考虑。5.4 对普通开发者的启示把“换模型”纳入架构设计即使你的项目今天还在用闭源 API设计时也应该预留换模型的空间。一个简单的做法是在上层业务逻辑和底层模型之间加一个抽象接口统一输入输出格式尽量使用 OpenAI 兼容接口这类通用协议沉淀一套属于自己项目的评测集对关键 prompt 和上下文模板做版本管理。这样当新的开源模型发布时你可以快速做一次对比评测而不是推倒重来。今天的开源模型生态已经让“换底座”变成一件技术上可行的事剩下的就是业务上要不要换、什么时候换的问题。6. 落地最容易踩的坑以及一条排查链路6.1 部署三座大山显存、版本、上下文超限实际部署开源模型团队最常见的三个问题第一是显存不足。解决思路不是盲目换更大的机器而是先降低上下文长度、开启量化、减少并发确认模型本身能正常工作。第二是版本冲突。PyTorch、CUDA、vLLM、transformers 这些库之间的版本经常互相影响。建议使用虚拟环境或者直接用官方推荐的 Docker 镜像。第三是上下文超限。输入文档过长时服务可能直接报错也可能静默截断。要在接入层设置文档长度检查并在产品上给用户明确提示。下面是一个简单的排查顺序现象先查什么再查什么最后查什么服务启动失败显存是否足够CUDA 和推理框架版本模型文件是否完整请求报长度超限输入文档实际长度服务端上下文上限配置是否有截断逻辑回答明显错误输入文档是否完整RAG 检索结果是否相关提示词是否产生误导并发一高就卡显存占用是否打满队列和超时配置是否需要多卡或负载均衡6.2 效果不好先排查输入和评测别急着换模型很多团队在模型效果不佳时第一反应是“这个模型不行换一个”。但很多时候问题不在模型而在输入侧和评测侧上传的文档格式不对解析后丢了很多内容检索到的知识片段不够完整模型只能基于残缺信息回答提示词里没有约束“依据引用回答”模型自由发挥评测集本身没有标准答案评审者凭感觉打分结论不可复现。正确的排查顺序是从数据输入开始一步步看链路哪里断了。先确认“模型拿到的输入是正确的”再分析“模型的输出为什么偏差”。一个实用的办法是遇到一个错误输出时先把同样的输入分别发给“纯提示词模式”和“RAG 模式”看看差异是否来自检索。如果 RAG 模式更差问题往往在检索到的片段而不是生成模型。6.3 开源协议和维护风险是长期问题使用开源模型还有一个容易被忽略的风险开源协议的边界。不同模型采用不同的许可证商业使用、二次修改、对外提供服务、再分发等场景可能有不同限制。在把某个开源模型纳入产品体系之前建议法务和技术团队一起把模型许可证、依赖组件许可证、训练数据使用条款都审一遍。长期使用还要考虑模型更新节奏、社区活跃度、以及如果项目停止维护你的团队是否有能力接管。建议把模型许可证和依赖版本写进项目的 README 和依赖清单里不要只在部署时临时确认。6.4 一条可复用的落地检查清单如果要把这次讨论落到一个可执行框架可以总结成“先验证、再适配、最后工程化”用一条贴近真实业务的长文档跑通开源模型部署用小规模领域评测集确认基座模型是否够用搭建 RAG 检索链路验证引用准确率用几百条高质量指令样本做一次微调上线前完成日志、权限、审计、回滚和监控持续收集真实反馈把错误案例沉淀进评测集。这套流程对法律 AI 适用对其他垂直行业同样适用。底层的逻辑是一样的技术变化永远会有下一波但围绕业务闭环构建的评测和迭代能力才是长期价值所在。所以如果 Harvey 换底座这件事对你有什么参考价值我的建议很直接不要急着把现有模型换掉而是先在你自己最看重的几个业务任务上准备一份评测集把当前模型的表现记录下来。等下一个开源模型发布时用同一份评测集跑一次用数据决定要不要换。能持续做这件事的团队才是未来垂直行业 AI 竞争里真正有主动权的人。