Harvey如何建AI研究实验室?

一家做应用的公司，为什么要建自己的 AI 研究实验室？

最容易想到的答案是：训练自己的模型，摆脱对基础模型厂商的依赖。但 Harvey 联合创始人兼总裁 Gabe Pereyra 的分享，起点和大部分成功企业类似，先建一套能判断「模型到底能不能把活儿干好」的体系，再决定哪些能力值得自己去拥有。

他在红杉资本 Own Your Intelligence 活动上的这场演讲，主题是「如何在预算约束下建研究实验室」。别误会，所谓预算约束，是相对于前沿模型实验室说的，不是研究可以不花钱。视频没披露 Harvey Labs 的具体预算、人数和投入回报，所以别把它当成一份低成本创业报价单。

如果用一句话概括这场视频，就是：Harvey 先定义真实法律工作的评测标准（benchmark），由律师指导生成可用于评测和训练的合成数据；借助外部研究与基础设施伙伴做后训练（post-train）；再把模型放进已经存在的产品评测、部署和监控体系里，用合规的反馈（feed-back）信号指导下一轮改进。研究实验室因此不再是一块独立于业务的模型部门，而是持续改善产品能力的一套机制。

这条路值得应用公司抄作业，但必须要注意，Harvey 是先主要靠闭源模型，做出了有人用的产品、找到了产品与市场的匹配（PMF），然后才把后训练当成整个系统里的一项新增能力。

先选定要改善的活儿，而不是一开始就去训模型

Pereyra 在问答环节承认，早期他也以为只要做出「最好的模型」，客户就会满意。后来才发现，不同客户有不同偏好，不同模型也各有所长。「最好的模型」这个目标，一旦脱离具体场景，就不成立。

这也解释了 Harvey 为什么第一步是 benchmark（评测基准），而不是招一支明星研究团队。

演讲里介绍了三类数据集：Legal Agent Bench，把大型律所律师的任务按类型组织起来，覆盖复杂文件起草、判例研究这些活儿；合同数据集，用来支持类似企业法务部门的谈判任务；尽职调查数据集，则把模型扔进大型资料室，检验它处理复杂文档关系的能力。Pereyra 说，其中最大的资料室达到 8,000 万 token。

注意，这 8,000 万 token 说的是资料室规模，不是模型能把全部材料一次性塞进上下文窗口。恰恰相反，怎么在这么庞大的材料集合里管理上下文，仍然是他列出的研究难题。

有人问，怎么设计足够难、能区分前沿模型的题目？他的回答不是先琢磨怎么难倒模型，而是尽量真实地重建客户正在干的活。在法律领域，真实业务本身，就已经够难了。

也就是说，立项时，别只写一句「提升领域智能」，要写清楚模型必须完成什么工作、当前在哪里失败、什么结果才算合格。比如，把「增强合同理解」改成「面对相互关联的合同，识别缺失文件、冲突条款和需要律师进一步判断的风险」，后者才可能变成评测，你也才知道训练到底有没有用。

不能训客户数据，就重建任务，而不是只收集答案

Harvey 的一个核心约束是：客户的法律数据极其敏感，受保密要求和法律特权保护。Pereyra 明确表示，这些数据不能放进通用模型训练，甚至不能放进自己的模型训练。

公开数据也填不了这个坑。

以并购为例，公开渠道也许能翻到最终的收购协议，却拿不到促成协议的那些输入材料，比如被收购公司的合同、谈判邮件、会议记录，以及文件之间的关联。只有最终答案，没有产生答案所需的环境，很难训出一个能完成整个工作过程的模型。

Harvey 的办法，是让领域专家指导合成数据的生成。最具体的例子，来自 Pereyra 的弟弟、Harvey 的律师 Julio：先设计评分细则，再反向生成资料室。

律师先确定这个情境里有哪些问题、模型需要发现什么。比如，某份合同缺失了，几份合同之间存在不一致。接着用模型生成包含这些问题、彼此关联的文件，再借 Mercor、Snorkel 这些伙伴，把材料做得更真实。等模型最后生成尽调备忘录时，评测者就能检查，那些事先埋进去的问题，它到底找到没有？

这不是让模型编一些「像合同的文字」。关键在于，专家定义了问题、文件关系和验收标准，模型生成只负责把材料铺开补充完。

把这套思路搬到别的行业，专家的角色就不只是给答案打分，而是设计可供模型练习的工作情境，财务专家可以设计相互勾稽却藏着异常的业务记录，采购专家可以设计约束相互打架的采购任务。注意，这些是对案例的方法延伸，不是 Harvey 在视频里披露的业务。

不过，合成数据只是起点。Pereyra 反复提醒，即便资料室看起来极其真实，也不代表它和线上用户的真实使用分布一致。一个擅长尽调的模型，未必擅长用户随手让它起草的一封邮件。

所以建实验室时，得同时回答两个问题：数据够不够真实？它代不代表我们现在真正在服务的任务？

研究成本不只有训练费，还有反复判断对错的费用

把数据集做出来，训练准备还没完。下一步，是把它变成能高效运行的强化学习环境。

Pereyra 举例，Harvey 的尽调数据集有超过 1,000 个单元测试，拿大模型当裁判来评估输出。如果每次评估都调用最大的模型，再叠加强化学习里海量的试跑，费用会迅速往上蹿。他提到与 LangChain 合作，就是为了把这部分的运行效率提上去。

这意味着，「有预算就多训几轮」并不是完整的成本管理。任务越复杂，判断输出好坏可能就越贵。一套没法经济地重复跑的评测体系，会卡住实验数量，也会拖慢研究。

对准备建实验室的企业，更靠谱的做法是把数据制作、专家审校、评测、训练、部署和线上运行，放进同一张成本表，而不是只盯着 GPU 或 token 单价。这是由视频案例推导出来的管理建议，视频本身没给各项成本占比。

同样，要警惕「benchmark 提升」这个说法的水分。Pereyra 在问答里提到，有些模型在他们的评测上表现很好，但一定程度上过拟合了，放进更通用的助手产品后，一遇到分布之外的请求就露馅。

评测是必要条件，不是充分条件。对新建的实验室，保留独立测试任务、检查评分器和专家判断是否一致、验证模型在相邻任务上有没有退化，都是防止「研究结果很好看，产品却变差」的必要防线。这些属于本文的实践建议，不是对 Harvey 内部流程的逐项转述。

托管基础设施，把内部能力留给领域判断

演讲一开场，Pereyra 就承认这是一场资源不对等的竞争，前沿实验室手里有更多的钱、人才、算力、基础设施和数据。应用公司的机会，不是把这些东西整个复制一遍，而是用好已经长出来的外部生态。

Harvey 和多家外部研究及基础设施伙伴合作，借对方的训练经验、技术方案和平台做后训练。同时，他们也通过 Tinker 一类的 API，以及 Fireworks、Baseten 这些提供的基础设施，逐步把内部后训练的工作加码。

他特别解释了为什么不只押一家伙伴，Harvey 想做的研究项目，已经超出了内部团队或单一合作方的承载力；不同伙伴有不同的技术判断，合作越多，能学习和验证的方向就越多。

但这不等于「新实验室就该同时采购一堆服务商」。Harvey 的理由来自它已经有的项目规模。对刚起步的团队，更重要的反而是先选一个边界清楚的任务，和伙伴一起跑通一个完整实验，再决定要不要扩展合作。

人才策略也因此改变。Pereyra 把早期试图直接争抢顶尖实验室人才，称为自己的一个错误，那时候，需要有人同时解决训练、部署和基础设施问题，这样的人极其稀缺。现在，部分基础能力可以直接拿来用，团队不必第一天就扛同样宽的技术栈。

据此，企业内部必须保留的能力，可以理解为三样：有人知道业务怎样才算做对，有人能把这种判断转成可靠的数据与评测，还有人对模型进产品后的结果负责。它们是职责，不是视频披露的岗位编制。具体几个人、怎么分工，仍取决于现有团队和任务复杂度。

先学会更换模型，再训练自己的模型

目前最容易也最经常被忽略的一点是：部署和评测体系，应该在后训练之前就存在。

Harvey 服务的是不同地区、不同产品入口、不同模型偏好的客户，需要在多个供应商之间设故障回退、满足服务水平要求。这不是「一个聊天界面后面挂一个模型接口」那么简单。

在模型上线前，Harvey 既跑通用评测，也做人工并排比较；针对具体产品，还要检查关键用户旅程、跑自动化产品测试、安排人工产品测试。最终上不上线，还得看成本、延迟和区域可用性。上线之后，再结合 A/B 测试、使用情况、可用性、token 效率和客户反馈，判断模型该不该继续留在生产环境。

这些要求，对闭源模型、开源模型和自家后训练模型，一视同仁。

Pereyra 甚至建议，在部署后训练模型之前，先做简单的开源模型替换：找出不需要最强模型的产品环节，验证能不能直接换成开源模型；不能整体替换的，再试试按请求路由，把合适的任务交给不同的模型。

这个顺序背后的理由是，只有先学会稳定地部署、比较和更换模型，才不会在第一次自训模型上线时，同时面对训练、集成、线上运行三类不确定性。

所以，一家企业建 AI Research Lab 的起点，完全可能是不训练任何模型。先把现有模型用好，建起基线，确定还有哪些失败是上下文管理、工具调用或产品改造解决不了的，然后再评估后训练值不值得投入。注意，这是对 Harvey 路径的归纳，不是「所有企业都该训自己的模型」的结论。

开源 benchmark，让外部创新变得可验证

Harvey 开放部分数据集，不只是为了让更多人看到研究成果。

Pereyra 给的第一个理由是质量，如果没足够多人拿这套数据集去训练，就很难知道它有哪些毛病。开放之后，其他团队会来提修改、挑缺陷，模型实验室也开始拿这些数据集报告表现。

第二个理由，更像一种合作筛选机制。过去，外部团队带着新技术来找 Harvey，内部未必有精力逐一验证。现在，可以先让对方在公开数据集上试；有效，再考虑投入合作。

当然，开放也会让别的模型厂商和竞争者沾光。Pereyra 没有否认这种可能性。他的判断是：帮助基础模型变好，也会改善 Harvey 的产品；更长期的价值，在于帮律所建立起适合自身工作方式的系统。

这给应用公司的启示是，值得长期保留的优势，未必是把每份评测数据都锁起来，也可能是持续理解真实工作、把能力接入产品、服务具体组织的能力。开不开放、开放多少，得看数据权利和竞争条件，不能机械照抄。

实验室最终要服务组织，而不只是刷高模型分数

演讲最后，Pereyra 把产品方向从个人生产力扩展到了组织生产力。

起草一段文字，是单个律师的活。但大型律所还要协调持续数月、数十人参与的客户项目，管理外部参与方，在众多项目之间排资源，并保证工作质量和盈利。Pereyra 认为，越来越多产品建设会涉及对人和 Agent 的协调，而不只是让个人更快地写文件。

这个方向也划定了研究实验室的边界。后训练只是更大系统里的一个输入，不是全部。更好的上下文管理、更可靠的工具使用、更合适的任务分配，都可能比训一个新模型更贴近业务问题。

他还列了尚未解决的挑战，合成数据与生产使用之间的差距，超大规模资料室里的上下文管理，以及如何在保护客户数据的前提下，让客户自己的 AI 系统持续改进，最后这一点是研究目标，不是已经完成的能力。

所以，从 Harvey 的经验出发，一家应用公司的合理起步路线是：选定一个真实且有价值的任务，建起当前模型的能力基线；由专家设计评分标准和合法可用的数据；先验证系统能不能稳定部署不同模型，再和外部伙伴开展有明确目标的后训练；只有当改进经得住产品测试和线上验证时，才扩大投入。

一个值得建的 AI Research Lab，不是为了证明公司也有能力训模型，而是为了更准确地判断：哪些活还干不好，问题到底出在哪，以及下一笔研究预算该花在什么地方。

结语

通观 Pereyra 的整场分享，自建AI实验室这条路径，大体可以拆成三步：

首先，别急着训模型，先选定一个真实、有价值的任务，把「什么算做得好」定义成评测标准；

其次，用专家指导的合成数据、外部伙伴的基础设施，跑通「评测—训练—部署—反馈」的闭环，把内部能力留给领域判断；

最后，只有当改进经得住产品测试和线上验证，才扩大投入，研究实验室的价值，不在模型分数，而在判断下一笔预算该花在哪。

说到底，Harvey 的答案只有一句话：先拥有判断模型好坏的能力，再谈要不要训练自己的模型。