61. 在Harvey训练大模型是什么体验？- Joey Wang

大家好，欢迎大家收听苔藓之火新的一期节目。今天我们非常高兴邀请到来自 Harvey 的 Joey。Harvey 是一家非常特别、在美国很有名的垂直法律应用公司，估值达到 155 亿美元，目前有 3,500 家客户，覆盖 85 个国家。我们经常会问，垂直应用公司的门槛到底是什么？之前我们看到很多垂直领域的公司，在大模型一波一波的迭代中失去了护城河和竞争力，有些被收购了，有些发展得不太好。但 Harvey 作为一家垂直应用公司，为什么反而发展得越来越好？这件事很神奇，而且它现在已经进入大模型这个竞争极其激烈的领域。今天我们很高兴请到 Joey，跟我们分享在 Harvey 训练模型是什么体验。

大家好，我是 Joey，现在在 Harvey 负责一些 agent 功能，主要在做我们内部的云端 agent 平台，叫 Spire。我大概 3 年前加入 Harvey，早期做过 History 和 Vault，主要是想办法把用户的历史记录和核心数据存储在 Harvey 里，让我们能更好地利用这些数据，帮他们做 AI 相关的工作。

加入 Harvey 之前，我在 Figma 做第一个移动应用工程师。再之前我在 Uber 做过司机端和乘客端的应用，也参与过 Uber Elevate，就是当年那个飞行汽车项目，做软件相关的工作。

简单介绍一下 Harvey：我们最早从美国起步，现在已经服务全球的法律客户，主要是律所和企业法务。美国前 100 家律所里，大概有 80% 在使用 Harvey。对律师来说，我们是一个很好的 AI 工具，能把阅读材料、研究、审查合同、起草等工作交给 agent。我们也希望律师能看到每一步审查过程，了解 agent 是怎么得出结果的，并且能够追溯信息来源。这些都是我们现在主要负责的核心工作。

这很有意思。Joey，你当时加入 Harvey 的时候，公司还在很早期。今天 Harvey 已经是一家很大的公司，估值超过 100 亿美元，但你加入的时候，公司应该才成立一年多。你大概是 2023 年加入的吧？那时候是 GPT-3.5 出来一年左右，公司规模还比较小。你之前在 Figma 和 Uber 的职位都已经很高了，为什么会去 Harvey？

1. Why Joey Joined Harvey

2022、2023 年的时候，GPT 刚出来，大家对大语言模型都很感兴趣。我在硅谷工作，在 Figma 接触过 GPT-2 和 GPT-3。具体是 GPT-2.5 还是 GPT-2，我不太记得了；反正很早的时候，我们也尝试过 GPT-3 和 GPT-3.5，想看看它能不能用来做设计相关的事，或者生成内容。当时我在帮忙做 Figma Slides，也在看能不能用 AI 做幻灯片。

早期我已经看到了 AI 很强的地方，但感觉模型还不够理解设计这样的领域，可能是数据不够，也可能是模型还没有足够的 taste。我认识 Harvey 也是机缘巧合。当时有一位 PhD 在经营自己的 Twitter 账号，我关注他有一段时间。他是个很有意思的 influencer，后来也介绍我去了解 Harvey。事实证明，他后来成了 Harvey 的第一位 recruiter，也成功把我招进了 Harvey。

当时我觉得，一个 PhD 对这个领域很了解，也愿意去做这家公司的 recruiter，说明他对这件事很有 conviction。我自己和创始人聊了一段时间之后，也理解了他们对这个领域的展望。我觉得这可能是下一代软件公司诞生的样子，所以很想加入一家早期公司看看。

这很有意思。当时你从 Figma 到 Harvey，之前还在 Uber，工作体验上最大的差别是什么？我想问的是，在传统移动互联网或者 SaaS 公司，和在垂直 AI 应用公司工作，最大的差别是什么？

2. Building at Startup Speed

我加入 Uber 的时候，它虽然已经比较大，但还是一家创业公司，也还没 IPO，所以节奏很快。我加入 Harvey，是想要一个更快的节奏。大公司有很多政策和组织上的因素，导致事情推进得没那么快。

我加入 Figma 的时候，它也是一家中型创业公司，早期能经历各种快速决策，也会尝试很多新产品。我当时提出不少新想法，都能被采纳。但到了后期，做很多事情都需要审批，部门之间也会有很多拉扯。

我个人很喜欢把事情做出来。到了 Harvey 之后，感觉又回到了刚加入 Uber 和 Figma 时的状态：我有想法，客户也确实需要这些东西，我把事情做出来，客户就会很开心。这一直是我很喜欢的部分。

明白。我最近在硅谷也听到一件很有意思的事：很多大厂员工都在抱怨组织结构太复杂，很多事情做不出来。比如 DeepMind 的一些人也在抱怨这个问题。很多人离开，并不是因为不喜欢原来的公司，只是真的很想把自己的想法做出来。亲自动手、真正去 build、去 ship，这种体验非常好，但公司越大，这种体验就越少，所以他们开始创业，或者寻找规模更小的公司。

说到 Harvey 的产品，我想具体问一下。大部分听众可能不是在律所工作的人，我自己也没见过这个产品。它有什么事情是 GPT 做不了、但 Harvey 能交付价值的？律师的工作本身也偏语言类，那大模型聊天框做不到的部分是什么？

3. Harvey Beyond the Chatbox

我觉得首先要想清楚律师平时的工作是什么。做垂直应用最重要的一点，是要贴合客户现在的工作方式。如果要把客户拉到一个新平台上，让他们重新学习，其实很难，因为他们很难把新平台映射到已经习惯的工作流程里。

我们的产品形式和很多 AI 产品一样：有一个主页面，有聊天框，用户输入之后会得到结果。但对很多律师来说，实际工作是在 Microsoft Word、Excel 或 Outlook 里完成的。他们要审查合同、比较客户或客户员工的资料，也会在很大的 spreadsheet 里比较各种合同。他们每天还会在邮件里回复、协调、查资料、做事情。

如果客户接入了我们的 connector，就可以用 Harvey 管理邮件和文档系统，帮他们生成新文档，或者对文档进行修改。举个例子，你可以把一份 NDA 交给 ChatGPT，让它帮你审查。NDA 是双方约定不能透露某些信息的协议，比如我和客户交流时，双方可能会签 NDA，好让彼此能更坦诚地沟通。

普通的 ChatGPT 可能会按照比较通用的方向审查。你可以告诉它自己平时怎么审查，但它不一定会像律师那样考虑：有些条款绝对不能改成某种形式，有些条款一定要改成另一种形式，还有些可以在中间协商。一个律师和另一个律师，或者律师和对方，最后协商出来的结果，不一定是所有条款都向我这边倾斜。有些事我不太在意，就可以照顾对方；有些条款则要尽可能争取对我有利。这些都是律师平时会做的判断。

我们会学习客户之前的工作方式。当然，这是建立在他们信任我们、把数据放到他们自己的云服务里，并允许我们访问这些数据的基础上。这样我们才能把数据用到他们之后的工作流程里。我觉得这里既需要对业务的理解，也需要用律师习惯的方式呈现最终结果。

最后呈现出来的可能还是一个 Word 文档，但 Harvey 生成的是我们称为 redline 的版本：划掉一段文字，换成一段新的文字，并解释为什么这么改。律师很喜欢这样的结果。

我以前做投行的时候，见过上万份 NDA。我觉得可以从几个方面来理解这个产品。

第一个是 M&A 的文件系统。两家公司合并时会有非常多的内部文件和合同。如果让人一份一份地读，再确认合并之后公司控制权归谁、合同由谁管理，会花律师非常多时间。那些比较重复、但只需要抓住核心条款并排定优先级的工作，就很适合用大型文件系统来处理。这可能和你刚才说的 connector 有关，它可以接入客户的文档系统。

第二个是 domain knowledge。律师双方各自关心 NDA 的哪些部分、应该让步到什么程度，这些知识也能用起来。

第三个是你说的 redline。我以前一直以为 Harvey 是直接生成文档，没想到是 redline。生成一个文件和生成 redline 是两件事。给大家解释一下：Word 有一个 track changes 版本，也就是修改后的版本。法律文件改了之后，不是直接把原文覆盖，而是用修订模式标出来，让律师逐项检查、接受或拒绝。可以把它想象成一个 paralegal 或 junior 律师先做了修改，你再逐项确认。

这个价值很大。如果你把所有东西都悄悄改掉，律师还得重新读一遍，变成“大家来找茬”，工作反而更多。但如果是 redline，律师的工作就变少了，只需要逐项检查。这样理解对吗？

对，因为这还涉及是谁做了修改，以及为什么要改。如果你在和 Harvey 的 agent 聊天，它会告诉你哪些改动是 Harvey 做的，哪些是客户或对方律师做的。律师需要知道谁改了什么、为什么改。

这和工程师用 PR 确认代码怎么修改很像。每个 PR 里可能有不同的 commit，能看出是我、Claude 还是 Cursor 做了修改。这些都是为了审计、追溯，也就是 audit trail 和 change tracking。对律所来说，追溯编辑是怎么来的非常重要。

用户把文档导出给别人时，我们会把 Harvey 做的所有修改都显示成用户自己的名字。这样，文档里显示的是他的同事、客户或对方律师对文件做了哪些修改。有时他并不会接受某个修改，只是先把它作为 track changes 的历史保留下来，最后再形成 final version。他检查完 Harvey 的修改后，可能会觉得“这确实也是我会提的修改”，然后把文件发给别人，让对方理解他的修改建议和思路。

我想问一个尖锐的问题：你们公司为什么不叫 Mike？我知道公司名字应该来自美剧 Suits。照这个说法，Harvey 的定位更像里面那个资深律师，而 Mike 是下面那个年轻律师。按这个逻辑，公司不是应该叫 Mike 吗？

作为一家法律 AI 公司的员工，我不能承认或否认公司名字的来源。其次，假设这个名字确实来自 Suits 里的 Harvey 或 Mike，我觉得我们的宗旨是要能参与法律决策，而不只是做繁琐的工作。我们希望能提供 intelligence，也就是在法律决策上给出有 taste 的建议。

有个客户之前跟我们聊过，他说 Harvey 帮他做了很多繁琐的工作之后，他开始和 Harvey 讨论一些以前没想过的问题，Harvey 提出了很多他之前没想到的点。这让我受益匪浅。

大语言模型终究是生成式模型。大家会用它写文章、生成社交媒体内容，甚至进行一些创作。比如把 temperature 从 0 调到 1，输出就会从非常稳定变得更有创造性。法律工作也是这样：有很多繁琐的部分 Harvey 能帮忙做。做完之后，律师可以和 Harvey 讨论接下来如何规划项目。Harvey 有很多上下文，也有很多法律知识，能像合伙人一样和律师交流。当然，这还是一个愿景。现在有些厉害的 partner 已经会用 AI 做这些事，但不代表所有人都能直接把 AI 当成 partner。

有意思。大语言模型一直进步得很快。过去几年，很多投资人和行业外的人都会担心，模型升级之后，会不会直接取代垂直应用里的一些功能。过去几年有没有发生过这种情况？比如 Harvey 花很多力气做了一个新功能，结果大模型一出来，就把它整体碾压了？

4. When Models Replace Workflows

我觉得不能说有，也不能说没有。我先简单解释一下 Harvey 和模型的关系。

Harvey 刚出来的时候，我们的创始人很早就用 GPT-3.5 做了很多法律相关的 demo。他们把真正的法律流程用 GPT-3.5 跑完，再和人做出来的结果比较，发现很多时候效果已经很好。后来，他们把结果展示给 OpenAI 的 general counsel，也就是 OpenAI 的法律负责人。对方发现 OpenAI 自己的模型在法律领域效果这么好，于是给了我们的 co-founder GPT-4 的 early access。他们用新模型做了一些产品，并把产品卖给了一些律所。Harvey 就是这样发展起来的，所以我们和模型之间一直是相辅相成的关系。

现在，我们能接触到各家公司最新的模型，有时甚至有 early access。我们也会作为法律领域的评测专家，帮助不同模型厂商了解怎样把模型调得更适合法律工作。所以对我们来说，模型提升是意料之中的事，它能帮助我们把已有功能发挥得更好。最后还是要看我们如何理解模型的发展，如何设计产品，以及如何设计背后的 AI infrastructure。

当然，随着模型迭代，有些东西也会慢慢减少使用。举个例子，我们去年夏天做过一个叫 Workflow Builder 的功能。律师可以定义每一步要做什么：哪一步需要用户反馈，哪一步需要用户上传文件，哪一步需要 prompt。把这些步骤打包后，系统会根据结果走 A 或 B 分支，最后生成具体文件。律师可以把同一个 workflow 发布给自己的团队或整个律所，让大家都使用同样的工作流。

那时 agent 或模型能力还不够强。如果直接用一个 prompt 让 agent 做事情，它可能做一半就忘了要做什么，或者没做完就结束，也可能没向用户要必要的信息就直接生成结果。所以我们做 Workflow Builder，让真正懂流程的人把它 codify，变成一个结构，让其他人也能用，agent 再沿着这个结构执行。

今年我们把它转成了 Agent Builder。现在可能只需要一个 prompt，再加上它所需要的原始文件或数据源。比如 prompt 加上日本和新加坡的法律材料，要求生成一份 PPT，就能取代之前 Workflow Builder 所实现的结果。在模型提升之后，功能从一个更需要人维护的东西，变成用户能更自由地定义 agent，并由 agent 直接交付结果的方式。

我大概理解了。我想再往前问一步：你们是什么时候开始想要自己做模型的？

先不谈技术细节，聊战略。你们一开始和 OpenAI 的关系很好。我没记错的话，OpenAI 也是你们的投资人，你们的 co-founder 也有人来自 OpenAI。你们和大模型公司的关系一直很好。后来是什么时候发现，现成的好模型不够用了，开始觉得要自己训练模型？是什么触发了这个决定？

5. Why Harvey Trains Models

先简单纠正一下：我们的 co-founder 有人之前在 Google DeepMind，也有人在 Meta 的 FAIR。你说得没错，我们早期和 OpenAI 合作很深，OpenAI 也是我们的投资人。他们甚至和我们一起做过一些 pre-training。

我们公司很早就开始做 legal research 和法律模型研究，一直在研究这些模型能不能比通用模型做得更好。这个过程其实一直没停过，并不是今年才开始做；只是今年我们发现它开始有商业化的可能。

这和我们对客户的理解越来越多有关。早期做 post-training 时，数据没有那么多；做 pre-training 又需要大量数据，我们没有那么多数据。所以我们曾和 PwC 合作做过一个 text model，也是 pre-training 的模型，再一起把它卖给更多客户。但我们发现，通用模型变得更好的时候，这样一个 pre-training 模型可能慢慢就不如通用模型。

数据不够时，我们做 post-training 的效果也不一定比模型公司自己的迭代快。Anthropic、OpenAI，甚至 Gemini 的迭代速度，可能都比我们用有限的数据做 post-training 快很多。

今年有两个变化。第一，我们的客户非常多。他们提供的很多产品反馈和 AI 反馈，不涉及客户数据和隐私，已经足够让我们慢慢构建对整个法律市场的理解，知道大家有哪些使用场景。即使不知道具体细节，也可以通过描述让 agent 模拟出法律场景，生成 synthetic data，比如模拟几十种或几百种不同的情况，做成 benchmark。

第二，我们学会了怎么通过模拟，让 benchmark 更贴近用户的实际场景。有了 benchmark，就可以评测不同模型。做 post-training 时，我们也能用 benchmark 产生的 synthetic data 来训练，取得更好的效果，并在效果、价格和 latency 之间找到平衡。

我是不是可以这样理解：如果还有其他垂直应用公司想做自己的模型，首先要考虑的是用户规模够不够大，能不能形成一个 post-training 环境，提供足够多、足够丰富的数据，让模型经过你的领域训练之后，产生差异化价值？

我觉得不只是数据，还有对数据的 taste。比如说，什么样的数据才合适？做 pre-training 的时候，大家会考虑怎么清理各种数据，让它们变成模型可以训练的原始数据。对我们来说，也要考虑生成的数据能不能真正反映客户每天的工作。

我们的团队慢慢培养出了一种判断力，知道什么数据好、什么数据不好、什么情况下数据不够、还要补什么。补了之后，现有模型的评测到底是对还是错，这里面也有很多判断。

归根结底，还是要更了解客户，知道自己的 taste，知道自己做的决策是不是和客户的实际效果强相关。如果我训练一个模型，要求它非常简洁，每次都用一句话概括所有事情，这可能不是法律客户想要的。律师可能需要长篇大论，而且每句话都要有索引，能追溯来源。

所以对很多拿不到客户数据的垂直领域来说，需要思考自己的 taste 和客户的 taste 有多相关，以及能不能通过这种 taste 模拟出合适的数据。

这个对 taste 的定义很有意思。我经常问别人 taste 是什么意思，因为它听起来很虚幻。你刚才举的例子很有意思：很多人觉得简短比较好，但在 Harvey 的场景里，简短不一定好。在律师的语境下，长可能反而更好。

我觉得中国开源模型的发展也给了你们一个历史性的机会，让你们在自己做模型这件事上有更多选择。你们当时是怎么考虑模型选择的？

模型选择不是看某家公司出的模型，也不是看参数多少、价格多少。更多是因为我们有了刚才说的 benchmark，可以做评测。我们的方向不是做一个大而全的模型，而是做一些小而美、在特定领域能做得很好的模型。

我们会针对不同场景做评测，然后用在评测集上表现最好的开源模型做 post-training。公开提到过的有 Kimi、GLM 和其他模型。我们也会和一些新的 labs 合作做 post-training，可能基于更多中国的开源模型。如果某个模型在某个场景下表现最好，我们就会选择它。比如 DeepSeek Flash 可能在某些不需要特别强的智能、但需要批量处理的任务上做得很好，我们就会对它做 post-training 或 fine-tuning。

这件事我不是特别理解，能不能给我扫盲一下？假设 Kimi 在 litigation 上比较好，DeepSeek 在 text law 上比较好，那你们会分别给 litigation 和 tax law 做 post-training，对吧？不同模型本身可能有不同的训练数据，所以在不同领域表现会有些差异。那这样一来，法律的每个细分领域都会有一个单独的小模型，听起来不是会很复杂吗？

对，但最后可以用一个更大的模型来调度。现在有很多 agent 或 delegation 架构，一个比较厉害的 agent 能把任务分配给不同的细分模型。

我觉得这和公司组织架构很像：你是要一个特别聪明的人，一下子把产品设计、前端、后端、infra 和 security 全做了，还是通过有能力的领导，把任务分给专业人士，让每个人做好自己的工作，最后由领导把产品呈现出来？这么多年来，后者往往是更好的组织方式。我觉得模型训练和模型应用也有点像，这只是我个人的想法。

明白。也就是说，你们最后打造的是一个图书馆，每本书都是你们精挑细选、经过 post-training 的模型，律师的问题交给最合适的模型回答？

对。但律师可能不需要自己挑书，他只要问图书馆前台“帮我把这件事做了”，前台就会找到合适的书来完成任务。

明白。实际挑选模型和做 post-training 的过程中，我还想追问一下。你们公开文章里提到过 Kimi、GLM、千问都试用过。除了用 benchmark 衡量模型在特定领域的表现之外，还会考虑什么因素？你们怎么判断这些不同的大模型在实际使用中的权重？

我觉得目前没有什么特别的原因。我们可以提供 Anthropic、OpenAI、Gemini、Grok 等不同模型，基本没有偏好，更多是看用户想要什么。有些用户在当地不能用 Anthropic 模型，就只能用 OpenAI。也有用户希望默认用 Claude。那我们就要和他们解释，根据我们和 Anthropic 的政策，使用 Claude 的话，数据会在 Anthropic 那边保留 30 天；我们看不到，但 Anthropic 能看到。如果律所或企业法务愿意接受，就可以用 Claude。

我们不会在中间加一些额外的 feature，而是尽量按照用户的选择，帮他们争取 access 和 capacity，同时保证 reliability 和 performance。

你提到了 Claude，我们之后可以再聊。我其实想问得更具体一点：Kimi、GLM 或千问经过 post-training 后，形成你们自己的模型。这个模型统一叫 Tanner 吗？Tanner 是一个单独模型，还是指这一系列训练出来的模型？

我觉得 Tanner 更多是一个方向，目前它可能是我们几个训练模型里比较有前景、规模也比较大的一个。我们还有其他模型，不一定都有名字，可能只是在具体场景里使用，也会进行测试和部署。

它现在在 M&A 或 due diligence 相关的工作上表现比较好。我们做其他模型尝试时，也能逐渐知道怎样训练出一个表现好的模型。之后不管换什么基模，都可能在这个领域做得比较好，再和另一个领域里表现好的模型结合起来。

所以 Tanner 的基模是什么，我也不太清楚。它不一定固定对应某个模型。我们研究的是怎么做模型、怎么评测模型，而不是只研究某个具体的基模。比如今天可能用 Kimi 做了 Tanner 1.0。

听下来有几点。第一，Tanner 是 Harvey 内部比较旗舰的训练模型；目前用的是 Kimi K3，但之后也可能换。Tanner 更像是你们把模型训练出来的一种方式，而不是只能用某个基模，对吧？

对，不是说我们只能训练 Kimi K2，或者 Kimi K2 训练完之后就不能训练其他模型。我们可能和一个 vendor 一起训练 Kimi K3，也可能和另一个 vendor 训练其他模型。每个 vendor 做 post-training 和 evaluation 的方式都不一样，也会对 inference cost、reliability 和 performance 做不同的权衡。所以我们一直在尝试。

你们训练 Kimi K2 和 Tanner 的过程是在 Fireworks 上完成的，对吧？我看到你们和很多不同的团队合作。这样就变成一个矩阵：底层模型有 Kimi、GLM、千问，合作方这边又有 Fireworks 等等。两边都不一样，这个矩阵听起来挺复杂。你们当时是怎么考虑的？

一部分原因是我们的 bandwidth 有限，不可能自己把矩阵里的每一种组合都做一遍 post-training 或 fine-tuning。和不同的 labs 合作，一方面能学习他们是怎么做的，另一方面硅谷的生态整体比较偏向交流和合作。尤其是 research 领域，大家更多是在探索。

我们会和不同的 labs 用不同的方式、不同的基模做尝试。中间学到的东西也会互相交流。通过这些交流，我们可能发现一种方法在法律领域更好，另一个基模在某个法律子领域更好，然后再重新尝试。

很多时候，我们会把 research 过程公开交流。我们公开过很多训练模型的方法，但这些未必是真正的 moat。真正重要的可能是，我们认为一个模型达到什么程度才算好的法律模型，达到什么程度律师才真的会用。哪些因素构成真正的分水岭，是模型公司或 lab 很难替我们判断的。就算他们自己做 post-training，也没办法替我们说这个模型在法律领域会更好。

我是不是可以这样理解：垂直公司积累了足够多的数据、足够多的 taste，又有活着的生产环境，所以判断什么是好、什么是不好的 benchmark 能力，反而成了最重要的能力？

6. Benchmarks as the Legal Moat

对。很多 benchmark，比如某些代码或软件工程 benchmark，可能会有固定的数据，也会不断增长，但不一定总有人根据大型企业实际的软件工程工作更新它。随着 agent 越来越强，实际使用场景可能会和 benchmark 越来越偏离。

我们的想法是，怎么让 benchmark 越来越接近用户正在使用的场景，甚至包含用户未来才会用到的场景。整个 benchmark 也会一直更新。有时我们会生成额外的 benchmark，然后在还不确定的情况下，和用户的具体场景一起做 shadow run 和 A/B test。

我觉得很有意思。Benchmark 是垂直应用最强的 moat，这句可以剪到我的片头。

我还有个疑问。以前我和律师打交道时，经常发现针对同一份法律文件，律师说法并不一样。法律不是 1+1=2，也不是理科那样有一个板上钉钉的绝对答案；很多时候是大家对法律条文的理解不同，再根据不同的商业操作推导出不同的做法。

所以我突然觉得律师领域的 benchmark 很难做。今天给 10 个资深律师一个 case，让他们打分或给意见，可能最后都能吵起来。你说的 benchmark，是不是最后先达成共识，制定一个标准，再按照这个标准打分？但律师是不是很难达成共识？

我觉得可以分层来看。一开始也不是说要做一个涵盖所有法律问题的 benchmark，而是先针对比较稳定、能衡量的任务做评测。

比如 NDA 通常会有 playbook，也就是在 A 情况下怎么做、在 B 情况下怎么做。我们会和内部法律团队一起写这些评测。他们一直在审查 NDA 和合同，也会把 redline 返给别人，所以已经积累了很多 yes/no 的判断过程，有点像早期 Cursor 的 Tab。

当内部积累了足够多的数据，我们就能做评测，再不断优化。不管是 post-training、fine-tuning、RAG，还是其他方法，整个 hill climbing 的过程都会更好。

公司也会招越来越多各领域的法律专家。他们可能在公司做法律、做 research、做 sales，或者做 forward deploy。他们的经验能让 benchmark 数据越来越丰富。最开始可以做一些比较稳定、可重复的评测；之后再慢慢加入人才的 taste，以及他们对法律的理解，看看能不能反映最前沿法律人士的判断。

这也会反映在招聘上：我们招的人是不是客户愿意交流的人？他们对法律的理解能不能转化成 agent 的工作方式，写进 benchmark rubric，最后反映到模型和 harness 里？

听下来，让 benchmark 更可信大概有两种方式。第一是大数法则，让更多人做 yes/no 判断，积累得足够多，就会逐渐接近法律界的共识。第二是建立一个丰富的法律人才库。

除了自己招聘和内部的法律人才，你们会和其他数据公司合作吗？比如 Mercor、Scale AI、Surge 这些公司，他们也会做法律方面的数据。

我觉得这其实是一个 scaling problem。我们内部会先决定做什么方向，早期可能会做 vibe check，或者用很小的规模判断这件事值不值得做。如果值得做，就先弄清楚 sample query 和 result 大概是什么样，每个 benchmark item 需要多少评测标准。这些工作一开始一般都留在内部。

等最初的 10 个或 50 个做好了，觉得方向不错，就要考虑怎么从 50 个扩展到 500 个、5,000 个。这时候就要把流程标准化，可能会和硅谷的 vendor，比如 Mercor，合作，找到合适的人来完成这些工作。

如果和这类公司合作，他们是提供很多律师帮忙给 benchmark 打分吗？具体会怎么合作？

可能会有标注，也可能会有打分。语言模型可以做一些评估，但不能完全只相信模型，不然模型本身就成了瓶颈，训练上限也会被评估上限限制。

对我们来说，早期的 label 和后期的评测打分，都会有不同程度的人工参与。

有没有发生过这样的情况：模型训练时，内部测得很好，Mercor 也帮忙测过，结果产品推出去之后，客户却不买账？

可能会有，但在我的印象里，整个过程一直都在迭代。用户不买账，我们就可以修改数据集，把事情做得更好。至于具体哪个 feature 或产品，我已经没有很清楚的印象了。

从公司角度来说，一个东西不可能永远完美。但如果能从用户角度理解它不完美在哪里，再改变评测和数据集，不断丰富、优化，我们就能持续积累，逐渐成为用户信任的产品。用户有时看到的不是一个完美的 Harvey，而是一个不断进步的 Harvey。

明白。我还想围绕模型训练再问几个问题。如果我是垂直应用公司的负责人，或者想要建立护城河，我会觉得训练自己的模型很重要。Cursor 后来也训练了自己的 Composer 模型，好像也是基于 Kimi 训练的，还是 GLM，我记不清了。很多垂直应用公司有了足够的生产环境和数据集之后，训练自己的模型似乎会成为很自然的选择。

我的第一个问题是人才。你们以前更像是套壳公司，现在又增加了模型公司的能力，人才结构很不一样。当时在人才方面遇到什么困难？团队要怎么补齐？

7. What Model Building Requires

我们遇到的可能正好是反过来的问题。早期团队里大多是做模型的 research 人员，后来发现真正的瓶颈是做产品。我加入的时候，PM 和 designer 都还没到位，所以很多产品设计和真正的产品 spec 都是我自己做的。我们当时主要缺的是产品人才。

后来真的开始做模型时，我们发现做模型不一定需要很多 research 人员。现在很多事情都能通过 reinforcement learning，甚至一些 loop 来做 hill climbing。真正重要的是怎么 validate，怎么让 agent 不断验证自己的结果。benchmark 反而成了核心。

产生 benchmark 的人多，不一定就能把事情做好；了解领域的专家可能更重要。很多 research 人员虽然没有法律背景，但能和内部的 legal research 团队，也就是我们的法律人士，交流得很好。

所以我觉得人才不一定要对模型有特别深的理解，反而要理解法律或其他专业领域。你不一定要自己懂，但要能和懂的人一起提炼他们的想法，甚至 enable 他们把事情做出来。很多 benchmark 和 evaluation engine，甚至是律师写的。律师知道什么对、什么错，也可以用 coding agent 来搭建这些东西。我们的 researcher 会和他们一起，教他们怎么做。

方便问一下，Harvey 有多少员工？

大概 1,500 到 1,600 人吧。

已经很大了。我最近也听说有些垂直公司，比如医疗领域的公司，开始训练自己的模型。我觉得这很正常，很多公司往后发展都会想走这条路。

但有些公司训练失败了。比如他们在特定 benchmark 上用 OpenAI 跑到 80 分，自己训练出来的东西却只有 65 分，本来希望能到 83 分，结果很糟糕，没法发布。所以我想问，你觉得最大的坑是什么？风险应该怎么评估？

从我们的角度来说，做了评测集之后，不是马上就要自己训练模型。评测集先能帮模型公司理解应该怎么优化。优化着优化着，你会发现有些开源模型在法律上的能力，甚至能超过 OpenAI 或 Anthropic。这个时候再做 post-training，你才有机会做得更好。

也就是说，我们做 benchmark 并不是说一定要自己做模型。做完 benchmark 之后，你会看到一个下限，也就是表现最好的开源模型。如果用它来训练，它就是你的下限。如果这个下限已经超过 OpenAI 和 Anthropic，那训练出来的模型就有机会更好。

假设今天 OpenAI 是 80 分，Kimi K3 是 78 分。我希望通过 post-training 把它从 78 提到 82，因为成本、隐私和部署等方面，自己有模型会更好。但有些公司可能跳不过这个坎。你觉得他们跳不过去的核心风险是什么？

我觉得 B2B 是一个比较好的 position，因为我们会和硅谷最厉害的 labs 合作。他们会做很多不同的尝试，不一定只关注 quality，也会考虑 latency、cost、reliability、可解释性，或者怎么提高律师的满意度。

所以 benchmark 怎么设计、能不能反映实际使用场景，本身就是一个权衡。最后训练出来的东西也不一定马上部署给用户。很多时候它更像一种学习方式，我们在意的是这些学习能不能应用到未来。

也许这次训练最后做出来的模型从 78 分掉到了 75 分，但过程中学到的东西可能让下一个模型做到 76 分，甚至开始冲到 80 多分。所以现在发布出来的东西看起来分数更好了，但之前有很多失败。你可以认为我们从公司刚开始就一直在失败，因为我们一直做 post-training、pre-training、fine-tuning，也一直在做 eval 和 benchmark。只是积累到今天，规模效应起来了，整个硅谷生态也发展起来了，成功的机会更多，我们才看到了成功的曙光。

你的意思是，你们从最早像应用公司的阶段，就一直在 benchmark、eval 和各种 harness 上投入；过去的失败积累到今天，变成了在模型上发挥作用的技能。

对。过去的失败不会写进 blog post，也不会公开发布，让大家说“Harvey 当年模型做得不好，我们不应该用”。我们一直认为，模型做得好不好，最后还是看用户用不用。我们的理解应该来自用户的使用情况。给用户一个便宜但不好用的模型，不是他们想要的东西，所以我们当时不会公开说这件事。

明白。这对很多创业公司应该很有启发。我想回到最初的问题：Harvey 到底创造了什么价值？

我记得你们很早以前写过一篇文章，叫《Why Prompting Fails Lawyers》，讲为什么 prompting 不适合法律人士。当时有个观点是，法律领域的 prompt 太复杂了，需要交代很多上下文和背景。如果律师不能像 prompt engineer 那样写 prompt，就很难用好 AI。早期你们在 prompt engineering 上做了很多工作，所以 Harvey 比其他同类产品好用。这些成功更偏工程和产品设计，用今天的话说就是 harness，对吗？

对。我觉得在法律或垂直领域，做好这些事情一直都很重要。

我想接着问：harness 更偏工程，模型更偏 research，两种努力方向不太一样。怎么评估哪方面更值得投入？

假设公司今天还有 100 块钱，可以再请一位工程师。应该请他优化工程部分，也就是刚才说的 harness，还是让他尝试下一个 post-training 模型？如果需要取舍，应该怎么想？

8. Engineering Before Model Training

我觉得还是要看用户能马上感知到什么。和用户聊多了之后，你会发现他们对模型的体会，很多时候没有对工程的体会那么直接。这也是我一直注重工程的原因。

模型一直是我们在 experiment 的事情，很难说现在能让 50% 的工程师都去做模型。实际来说，模型提升是一个非常长期的过程；工程上的提升往往能立刻见效。工程上有很多 low-hanging fruit，做好一些工程工作，模型的表现也能更好。

举个例子，如果 document search 从 2 秒变成 200 毫秒，那么在用户想要了解全部法律文件的 1 分钟里，系统可能就能从搜索 30 个文件变成搜索 300 个文件。如果再从一次只能搜一个文件，变成可以并行搜 10 个文件，就能从 300 个变成 3,000 个文件。agent 能看到 30 个文件，和能看到 3,000 个文件，结果会很不一样。无论用什么模型，看到 3,000 个文件的 agent 都会有更好的收获。

所以工程上还有很多 low-hanging fruit，而且效果可以很快反映到用户反馈里。模型可能要等工程做到足够好，或者公司需要长期规划时才更重要。公司最后要盈利，也要考虑 profit margin。模型会影响公司能不能像上市公司一样有好的利润率。我觉得 Harvey 到了现在这个阶段可以思考这些问题，但很多早期创业公司不一定适合先把资源投在这里。

听懂了。模型更像长期的事情，短期回报没那么明确；但长期来看，自己的模型成本更可控，对未来的 profit margin 有帮助，所以还是要做，只是目前仍然是投入期。

方便问一下，现在 Harvey 自有模型，比如 Tanner，在调用量里大概占多少？或者自有模型的使用量大概占多少？

这个数据不太方便公开。用户使用时可以自己选择，也会涉及他们的偏好。我们会把所有选择都交给用户，具体使用量可能在一些 dashboard 上能看到，但我不太清楚；即使知道，也不太方便透露。

明白。我是不是可以理解为，目前自研模型使用量还比较少，主要还是 OpenAI 和 Anthropic 的模型？

对。Anthropic 的模型在写作上确实比较长篇大论，很多人会觉得啰嗦，但对律师来说，有时候反而是好事，因为它会解释这么做的原因。

OpenAI 是你们的投资人。你们现在在 OpenAI 和 Anthropic 的模型之间有偏好吗？OpenAI 会不会干预你们用什么模型？

我觉得 OpenAI 从投资我们的那一刻起就不怎么干预。我们需要他们的时候，他们会提供一些反馈，或者帮我们联系到相关的人，这会有帮助。

但在硅谷，投资通常不是“我投了你，你就得用我”这种纯关系的事。更多是互相交流，交换一些一手资料，或者进行资源互换。

了解。再问一个关于你个人的问题。你之前做了一个产品叫 Spectre。听下来，它现在是公司内部的一个协作工具。能不能给听众介绍一下 Spectre 是什么、为什么叫这个名字、现在有什么作用、将来有什么期望？

9. Inside Harvey's Shared Agent

最早大概是今年 2 月，我发现公司很多时候用不上 background agent 或 sandbox agent，也就是能运行在云端的 agent。于是我做了个 prototype，把 Claude Code、Codex、Cursor、Devin 这类大家日常在用的 coding agent harness，打包成能在 sandbox 里运行的 agent。

我做 sandbox agent，首先是觉得这能让工作流变得非常并行，甚至大大提高效率。否则你天天跟自己的电脑聊，会受到电脑硬件的限制。如果都跑到 sandbox 里，给 agent 很多权限，它就可以更自由地运行。

其次，我来自 Figma。当时我想的是，大家每天都在自己的电脑上跑 agent。可能 manager 说了一句话，5 个 engineer 就各自在用 Claude Code 或 Codex，跑完之后再把结果分享出来，但大家都不知道结果是怎么来的，没法验证。

所以我想，如果大家能在同一个 agent runtime 或 conversation context 里交流，各自把想法告诉 agent，再由 agent 做协调，最后产出结果，大家就能看到它的整个 thinking 和 tool call trace。这样一来，最后的结果更容易得到大家认可，也能更快放进真正运行的产品里。我觉得这是一个很好的 closed loop。

最后它做成了一个 sandbox agent。你可以直接在 Slack 里和它一起工作，把它当作队友，和它一起完成事情。国内的听众听起来可能会觉得像 work party。

听起来和 Claude for Slack 有点像。

对。我大概 2 月做的时候，觉得第一步就是做成 Slack bot，而且大家都能 tag 它。不是我 tag 了之后只有我能和它说话，别人 tag 它又重新开一个对话。

Claude for Slack 好像是六七月份出来的。我当时在内部群里开玩笑，说我预测了未来的工作方式。其实我知道 Claude 一直在做这个，而且他们内部也用得很好。

不过这种产品推出去会有很多数据安全和隐私方面的 concern。大家都能和同一个 agent 聊时，agent 怎么判断信息是公开的还是私有的？它能不能拿到别人的信息？我们在测试过程中必须把 security boundary 写进 agent 的逻辑里。这确实是个很难部署的产品。

从逻辑上说，这就像公司多了一个员工。这个员工参与很多项目，知道上下文和前因后果，能帮你分析、解释。但它也可能把老板的行程告诉你，或者把老板偷偷用公司钱买了两瓶酒的事告诉你。

早期比如在 OpenClaw 群聊里，两个人可以各自加一个小龙虾，也有点类似这种情况，对吧？产品的实现思路本身不难，最难的是落地：它能给谁什么信息，怎么管理权限和隐私。实际落地时，花最多时间的可能就是这个。

对，核心是怎么定义安全边界。要知道每个 tag 它的人有什么权限、能访问什么信息，也要判断分享发生在公开 channel 还是私有 channel。

我们会和安全部门、IT 部门协商，了解他们能开放什么、我们能拿到什么，以及有哪些设计要求。比如每一个新的 agent 在读取信息时都要符合某些规定，不能违反这些规则。

内部还会要求每段代码都要有两个人 review，才能提交到 production。agent 写代码时会不会绕过这个 rule？一个人会不会让另一个人的 agent 改代码，再直接提交？我们都要考虑这些 edge case 和安全问题，做好保护，让大家愿意把数据放上去，并且相信自己的数据是安全的。

比如我今天和 Spectre 聊的内容，明天老板也拿不到，这件事非常重要。如果你觉得 agent 能知道自己的信息，也能知道别人的信息，而自己的信息还可能被别人知道，你就不会和 agent 分享任何东西。

此外，还要让大家信任 agent harness。比如为什么我会选择 Claude Code、Codex 和 Cursor？因为程序员本来就在用这些 agent harness，会觉得它们更安全，而且交互方式和本地 agent 的运行逻辑、语言输出都很像。这种对 harness 的信任，也是我做产品时考虑的原因。

Harvey 一直强调要赢得用户的 trust。要不断告诉用户产品能带来什么，自己要的并不多，但能带给他们很多价值，并一步步让他们理解产品的作用。这可能也是同样的思路。

这听起来确实很复杂，需要花很多时间去落地。我记得 Shopify 的 CEO 也提过类似的事：公司里只能跟一个 agent 对话，形成一个上下文统一的系统。张一鸣也讲过把公司当作产品来管理，让员工的上下文尽量统一。

但即使上下文统一，每个人能听到的内容也不一定完全一样。所以我觉得这个产品很复杂。实现上可能不难，真正难的是组织层面的思考：谁应该知道什么，谁应该被怎样鼓励，大家应该如何协作。这更像是 AI 时代组织发生变化之后，我们怎么提供产品去适配这个组织。

对。

我还有一个业务问题。上次在 Assembly 的会上碰到你时，我就想问这个问题，只是没有机会充分聊。Harvey 现在主要面向美国的大律所和大公司里的 GC。但美国很多律所其实是小律所，可能只有两三个人。我理解 Harvey 主要是中大型律所在用。你们怎么考虑中小型律所市场？还是说完全不在乎？

10. Serving Smaller Law Firms

我觉得小律所需要的东西可能和我们现在提供的不一样，或者他们不在乎我们已经做出来的某些东西。你有了这些功能之后，也不一定能让他们理解它的好处在哪里。

我原本想的是，Harvey 目前还是偏 SLG，不是 PLG。大律所走 SLG，小律所可能就像 Figma 一样走 PLG。说不定可以有一个叫 Small Harvey 的产品，或者叫 Mike，给小律所用。

我觉得还是和法律软件本身的性质有关。把软件交给用户之后，究竟是你对结果负责，还是用户对结果负责？比如 coding agent，用户自然知道结果要由自己负责。但法律 agent 不一样。如果做成 self-serve，用户可能会过度相信结果，最后认为 Harvey 要对结果负责，但其实不是。这会带来很多市场教育的问题，因为法律的后果比代码更严重。

明白。

我觉得我们现在不是急着扩张到让所有人都用，而是要找到合适的 design partner。他们有一定的规章制度，确实能用好 Harvey，也能管理好使用 Harvey 的结果。他们信任 Harvey，Harvey 也能信任他们。现阶段我们更看重这一点。

今天非常感谢 Joey 的时间。我们今天学到很多：第一，加入像 Harvey 这样成功的公司，在 Harvey 里的工作体验如何；第二，也充分交流了垂直应用公司如何在原有基础上增加训练模型的能力。我觉得这也是很多创业公司可以思考的问题。

在这里做个小广告：如果大家想见 Joey，她会在 11 月 5 日到 6 日来到上海虹桥，参加 AI Engineering 大会。AIE 大会第一次来到中国、来到上海，汇聚全球一线 builder。你可以听到 agent 怎么做、模型怎么选、产品怎么落地，还有很多技术 demo 和演讲。如果想看更多 AI 创业者、CTO 和一线工程师，可以带着项目和问题来这里寻找潜在的合作伙伴。这次有很多不同的公司，包括 Cursor、Manus、Wordlabs、EXA、Based、Arena、Agent、Meta、Gemini，各个公司都会派出杰出的代表，包括来自 Harvey 的 Joey，都会来到上海和大家见面。买票链接以及专属于苔藓之火粉丝的折扣码也会放在 show notes 里，大家可以参考。今天非常感谢 Joey 的时间，谢谢。

谢谢。好。嗯。

Help me, tell me I'll be okay. How long till I’m out of this place? How long? How low can I bend till I break? All I know is I can’t carry this no more. So how low?