Legora 的 CTO 说，六成法律活模型今天就能干；剩下四成，他连客户的文件都看不到。这期把产品、评测和几个坑都整理了下来。
本期要点
01 · 00:00 片头 · 地下室 · 产品起点
- 开场剪辑里雅各布就给出全期的主线：「法律工作里很大一部分，根本不需要 Mythos 级别的智能。」
- Legora 2023 年在斯德哥尔摩成立，2024 年 10 月上线平台；雅各布本人是 YC 23 的创始人，公司是 YC 24 的。1
- 他把公司文化归给「一直是弱者」：没人相信斯德哥尔摩地下室里的小公司能打赢美国那个跑在前面的庞然大物，所以一直谦卑，进美国之后才学着更敢说。
- 他在节目里拆自己姓的来历（Lauritzen 里的 sen 就是「儿子」），主持人是 Forward Deployed 的巴兹尔·查塔与 Latent Space 的 swyx。2
02 · 01:54 从法条搜索到真正的 agent
- 一切的开头是「ChatGPT 里塞了一个瑞典法条的搜索工具」，真的就只有这些。
- 法律检索在全世界都是个大市场：律师要花大量时间搞清楚以前有哪些类似案子、判例是什么、别人怎么处理。
- 产品后来分成两条腿：一条是「做活」——把东西写得好、改 Word 文件、搬文件、整理、跑复杂分析，包括 Tabular Review 这种批量提取；另一条是「编排活」——Lists、Intake、Portal，律师对律师、客户对律师、律师对 agent 的协作。
- 从「助手」切到「agent」大约是一年前的事，正好撞上推理模型改变一切。
- Tabular Review 这个词已经成了行业通用叫法，Claude for Legal 也在用他们的术语做产品。
- 底层不止一个模型，按任务分工；具体是哪些他对律师侧不可见，由他们替客户选。
03 · 05:23 模型选择器，与「够不够用」
- agent 里有一个主模型的选择器，某些工具用别的模型；他们的经验是任务切得越细，按切分去路由就越有效。
- 选择器里现在有五档，包括 Fable、Opus、Astra。有人一上来就要最强那档，代价是「额度以快十倍的速度烧掉」。
- swyx 给的 agent lab 定义：领域专用的前沿模型封装，替客户做选择——「你去找一个时薪一千美元的律师，问他这是 Sonnet 的高配任务还是 Opus 的中配，他根本不知道」。
- 雅各布把需求看成幂律分布：大约六成的活现在就能做得非常好，剩下的四成里，复杂分析仍然要更强的智能；而且「Legora 的活」本身会随智能一起扩张。
- 九个月里变化最大的是子 agent 委派，扇出式的检索查询现在效果很好，以前很难。
04 · 09:18 评测：一张热力图与用「世界」造的考场
- 评测团队按执业领域乘任务做了一张大热力图，跟踪所有模型在不同格子上的移动。
- 模型发布经常「在一些任务上进步、在另一些上退步」，这种事的频率比外面想象的高得多。
- 他们的评测环境是许多个「世界」，本质是强化学习环境：一间装一万份文件的数据室、一份尽调报告该有什么不该有什么、要找出哪些红旗。
- 评测团队是混编的：三个工程师加三个律师；外面还有约一百位「法律工程师」的池子——在大律所干过三四年、往往还有计算机学位、每天在用产品的人。2
- 过去做评测并不值得：每两三个月模型一换代，问题自己就没了。他们赌「一切都会变好」——引用准不准从 70% 到 99%，他们什么都没做。
- 这个岗位真正的活，是想五年十年后法律职业长什么样：审计日志、数据留存、受监管行业需要的那些东西，然后是「你一登录就是一个指挥中心」的界面。
05 · 12:18 五年后的律师、合伙制与计费小时
- 律师会把时间挪到当初想做律师的那部分：判断风险画像、战略判断、和客户一起工作；在大部头文件里翻那颗「冒烟的枪」的活会变少。
- 合伙制的成因他讲得很清楚：专业服务公司唯一拥有的资本是人力资本，你没法拥有人，只能租——所以让拥有人力资本的人当股东，人才留得住。
- 他想帮律所积累的，是一种耐久的无形资产：把「我们这家的做法」编码成系统，连判例、文档一起，成为律所自己的知识产权。
- 但激励不对：回报来自 eat what you kill，花时间固化不会加分；而且离开合伙之后，自己建起来的资产一分钱分红都拿不到。
- 计费已经在变：尤其美国，很多活改成按项目收费，偏低的那些有一口价、甚至干脆免费；钱移到战略、诉讼与客户关系上。
- 初级岗两极分化：好的初级律师更值钱，靠 paralegal 起步再读法学院那条路，他说「现在真的不被需要了」。
06 · 19:39 钱去哪了 · 拿自己的产品做尽调 · 两个市场
- 「meat proxy」（肉身代理）是个贬义叫法，他反过来解释：懂 agent、懂工具箱的人不是代理，是在做有意义的工作。
- 他们用自己的产品做并购尽调。Qura 那笔很简单，全在瑞典；加拿大与澳大利亚那两笔涉及 payroll，就请外部律师做战略判断、当陪练。
- 有一次尽调里翻出像红旗的东西，他们踩了刹车——具体是什么，他明确说不能讲。
- 欧洲客户动得慢、更多是买现成；美国客户更靠前，愿意自己定制、自己做集成，甚至想共建全新产品，也更容易把这件事看成存在性威胁。
- 产品指标之外，他们还跑在线评测：用一个很便宜的模型判断「我们这里有没有解决这个问题」，用来按 feature flag 比较灰度前后是变好还是崩掉。
- 这门生意最难受的一点：他们看不到任何 trace。客户手里的数据连律所自己都不拥有，属于律所的客户，而且是高度机密。
07 · 26:12 看不见 trace，怎么做产品
- 因为看不到真实使用，评测团队只能「近似」大家在做什么，再把它做进评测集——他自己管这叫这门生意里一个特别烦人的死结。
- 改述有条界线：改到只剩三个值、你挑其中一个，那没问题；只把名字去掉，也许行也许不行。他们一律选最保守的方式，因为风险应当为零。
- 能做的信号：把失败归类到已知的十到二十种失败模式，或按任务类型、执业领域归类，至少知道概念落在哪儿。
- 基础设施全在 Azure 上，原因是律所已经替微软做完了安全审查——文档都在 Office 365 里。当年他们说「AWS？不行」「谷歌？不行」。
- 三年之内「本地部署」这个词消失了，大家都接受了云更安全，而且可能比你现在自己干的更安全。
- 模型策略是带着客户走完整张地图：各自擅长什么、延迟多少、成本多少、治理如何、区域可用性如何；有些开源权重模型在某些任务上更好就放那儿，有些做后训练。
- 不用 ElevenLabs 是 DPA 的原因——数据处理协议上的供应商极少，任何数据流向都要收得极紧。转写用 Gemini 早期某代和微软的 MAI Transcribe，术语一多就得先用 LM 抽关键词再重跑。
08 · 33:33 Tabular Review、Intake 与 Lists
- Tabular Review 是扇出：一行一份合同、一列一个问题。一万份劳动合同放进去，第一列问终止通知期，下一列问有没有 IP 转让条款，再下一列问解雇要赔多少。3
- 也可以直接把活交给 agent：它自己起一张表、跑完、分析结果、标出红旗，再据此起草给客户的备忘录；整张表可评论、可协作。
- 选表格是因为好用：一眼看到全局，而且所有产出都带回到原文的引用——想确认对不对，点开就审。
- 表格视图默认先跑前 10 行，确认「它给的是不是你以为的东西」，再扇出到一万份。
- Intake 是法律专用的 Slack 入口，作用不是「起一个 agent」，而是起一个 agent 并往 Lists 里加一条任务；活干完回到 Slack，法务团队坐在 Legora 里管。
- Lists 像一个 Notion 数据库，是这堆东西的胶水：agent 能创建列表、列表能起 agent、agent 能读列表，于是 agent 群就活了。
- 客户要定制看板时，法律工程师用它搭现成的生成式界面；他说某种意义上「Legora 里有一个小小的 Lovable」。
09 · 40:15 撞上 Wexler、FDE 与「谁写代码」
- 核心构件就这几个：Lists、Projects（文件的容器与文件系统）、agent、Tabular Review 与表格视图。
- agent 没有名字。以前给过名字，后来停了——「可能会让人困惑」。
- 第一个驻场工程师也是纽约的第一个员工，本人是 YC 创始人，做过两家 YC 公司、在 Meta 做过搜索。4
- 分界线很清楚：法律工程师像重度用户那样配置产品，不写代码；驻场工程师对着 API 写集成，必要时扩展 API，把事跑通。
- 驻场工程师不碰数据，只把系统建起来；需要时才会被当员工接入，拿一台笔记本之类——他说这不常发生。
- 派不派驻场是优先级问题，因为同一个人也可以去做核心产品；他们没有 Palantir 那种「四天在现场、一天回产品」的规则，很多事还在早期。
10 · 47:24 API 之争与「300 斯巴达人」
- API 不是「网页版有什么就都给」：他们有 API，但不是产品的全部界面，这不是现在的承诺。
- 他们大概六个月前才开始做 API，之前抵抗了很久——产品动得太快，不想被「为一个已经改过的数据模型维护旧版 API」拖住；只有 20 个工程师时做不了这件事。
- 平台团队与产品团队分开的价值：驻场工程师就只是平台上的又一个客户，第二个产品也能很容易起来。
- 他正在琢磨一个更怪的问题：agent 能不能就是 API。对一部分场景，客户真正想要的是「触发一次、让它去做」。
- 真正的阻碍是成本、延迟，还有确定性——一百次里有两次它会做出不想要的行为。
- 「300 斯巴达人」：他翻出电影剧照，说这辈子就保持 20 个工程师，然后打赢所有比他们大得多的人。现在是 100 个还嫌少，办法是把能力收进基本构件，让客户觉得建了很多、其实只建了少数几个。
- 他们自己押的两个赌注是没人开口要的：agent 的主动性，和在工作的地方协作（在 Legora 里，而不是邮件与短信里）。
11 · 53:05 后训练、检索与引用系统
- 到今天他们还没有微调过任何模型。但开源权重模型变强之后，对窄任务开始做后训练——法律检索就是典型：它是个扇出检索问题，可以让小模型跑得又快又便宜。
- 他明确说不会去训练自己的 Fable 当主 agent：「那场我们赢不了 Anthropic。」
- 检索还有大量低垂的果实：late interaction、multivector、新的 embedding 模型，在模型之前、在 harness 里面都有。团队里有人一直在推这件事，还找 Turbopuffer 谈过做 multivector。
- harness 才是被烤进去的东西：怎么编辑文件、怎么做分析、怎么做法律检索，以及围绕它的一整套治理。
- 起草其实是检索问题：先找到对的先例，再判断哪一段该从哪份文件里取——「律师不是坐下来就开始敲字」。
- 起草偏好：Fable 与 Opus 极其啰嗦，Astra 写得简洁；啰嗦在合同里就是成本。
- 引用系统可以一层层点下去：从 agent 写的话，到表格里的那一格，再到 PDF 上高亮的那个框。但律师后来不太核——量太大，一个人怎么可能做得完。
12 · 59:00 百万 token、被断供，与招聘
- 长文档推理仍然很难：一份巨大的合同要改，模型得记住改了哪些、定义变了、顺序也变了。最简单的做法是一次性塞进去一次性输出，但他们切块，再编排这些修改。
- 脚手架得跟着模型走：Word 插件在 map-reduce 与「全塞进上下文」之间来回过好几次，模型一变，围着它搭的东西就得改。
- 分块摘要会丢掉块与块之间极相关的东西：两块单独看都跟你的问题无关，合起来才重要。所以他们保留两种检索。
- 拿真实数据的路只有两条：请客户匿名化样例，或者买一家律所。买来的输入很好，输出却难以判断——你只拿到最终结果，得反推是怎么到那儿的。
- 给重 RAG 工作负载的建议：别只看 MTEB 排名、别用默认 embedding，去看 Voyage 或定制 embedding；唯一的注意点是多语言，他们服务很多语言。
- 实验室不会掐断法律这门生意：他们自己在做法律服务，但永远不会做得这么深。「如果你在做一笔四亿美元的并购，你会想要 Legora。」
- 招聘：纽约、斯德哥尔摩、伦敦招工程师，其他岗位到处招。纽约现在 100 人，计划是「能招多少招多少」。
口径与核对
- 官方可查：E 轮 5.5 亿美元、投后 88 亿美元、Atreides 领投、ARR 超 2 亿美元、从 100 万到 1 亿美元不到 18 个月、下一个 1 亿不到 6 个月、1,000 人以上、18 个办公室、14 万从业者、2,400 家机构、80 多个市场、上一轮估值 56 亿美元、美国已成最大收入市场且 AmLaw 50 过半是客户、Q3 新客中 in-house 超 40%。1
- 只有节目里说过的：约六成的活现在就能做好、引用准确率 70% 到 99%、评测团队三个工程师加三个律师、约一百位法律工程师、一万份文件的数据室、「一百万格」、纽约 100 人。
- 口径出入：节目里的「一百万格」是口头说法，官网 Tabular Review 只写「数千份文档」，没有格数上限；「1,000 人以上」是全公司口径，和纽约 100 人、工程师 100 人是三层不同的数。3
- 节目里 Qura 被读成类似「Cura」的音，指的是 Legora 2026 年收购的斯德哥尔摩法律检索公司；同年第 7 个月收购的 Wexler 做的是诉讼事实智能。4
逐句全文翻译
本节按官方章节顺序逐句翻译，只保留中文，不压缩、不摘要、不删减。本期由 Forward Deployed 的巴兹尔·查塔与 Latent Space 的 swyx 共同主持，两位主持人的发言统一标为「主持」，嘉宾标为「雅各布」。
01 · 00:00 片头 · 地下室 · 产品起点
本节对应官方章节 0:00 冷开场、0:40 认识 Legora 的 CTO、1:05 斯德哥尔摩地下室里的一群弱者。
（片头剪辑，摘自本期对话）
雅各布：一直有人来问我们「Mythos 怎么样」。可我认为，法律工作里很大一部分根本不需要 Mythos 级别的智能。
主持：paralegal 没了，初级律师没了，我不需要他们。
雅各布：可我们实际看到的不是这样。我们遇到过一个引用标不准的问题，下一个模型版本一发布就解决了，从 70% 直接到 99%。我们什么都没做，就这样好了。但你如果是在做一笔四亿美元的并购，你还是会想要 Legora。
雅各布：我当时做的那页 PPT 说，我们这辈子就保持 20 个工程师，然后打赢所有比我们大得多的人。现在我们有 100 个工程师，还是觉得人太少了。我现在在想的一件事是：我们产品里到底有多少可以就只是那个 agent，多少得是 agent 之外的东西。
主持： 好，我们在演播室里，今天的嘉宾是 Legora 的 CTO，雅各布·劳里岑。我念对了吗？
雅各布： 这样就行，没关系。
主持： 我知道这是丹麦语的念法。
雅各布： 对，就是。「Lauritzen」里的「sen」就是「儿子」的意思，你有「son」这个后缀，所以就是「Lauritz 的儿子」，我的姓就是这个。
主持： 好听。我们之前碰过几次面，你也在几个活动上讲过。显然 Legora 是法律科技史上增长最快的公司之一。你在开录前说了一句话我觉得特别有意思——你说你们的出身非常「欧洲」，尽管你们现在在纽约和旧金山都在扩张。你们的文化里有什么不一样的东西？
雅各布： 我觉得核心上，我们对自己在做的事大概是非常谦卑的，因为我们从一开始就一直是弱者。没有人相信斯德哥尔摩地下室里那家小创业公司能打赢那个在美国远远跑在我们前面的庞然大物。所以我们一直是弱者，所以一直很谦卑，一直得为活下去而战。当我们进入美国、在美国待得越来越多之后，我们不得不学着更敢说一点，去告诉世界我们有多好——这对我们当中一些人来说，并不是自然而然的事。
主持： 我想先从你们的产品讲起。因为很多法律产品都是捂着的，不该给人看。你能不能先说说这个产品长什么样，你们又是怎么一步步走到今天的？产品迭代的脉络我觉得会很有意思。
02 · 01:54 从瑞典法条搜索到真正的 agent
雅各布： 当然。一切的开头，其实就是 ChatGPT，里面塞了一个瑞典法条的搜索工具。真的就只有这些。
我们就从那儿开始。我们做的是法律检索，这在全世界都是一个巨大的市场——律师要花大量时间搞清楚：以前有哪些类似的案子、判例是什么、别人在这种情形下是怎么处理的。这极其重要。所以法律检索一直是我们产品的一部分。我们是从一个「你问它问题，它去查法条」的 agent 起步的，起点非常简陋。之后它一点点扩出来，扩的方向是这个 agent 能做什么：现在它能把很多东西写得很不错，能编辑 Word 文件，能把你的文件搬走、把东西整理好，能跑很复杂的分析。我们还加了一堆功能。
其中一个功能叫 Tabular Review（表格审阅），现在这个词已经成了行业里的通用叫法，我们很高兴看到 Claude for Legal 也在用我们的术语做他们要做的产品。
主持： 这个我们必须聊。
雅各布： 它本质上是一种批量提取、批量审阅大量协议的方式——你做尽调的时候、融资的时候都会干这件事。所以这是产品的一部分：帮律师把本职工作做得更快、更好。
然后，除了「做活」之外，我们现在也越来越多地帮人「编排活」，这比一年前多得多。我们有一个叫 Lists 的东西，对我们来说有点像 Linear；有 Intake，是和客户协作的方式；还有 Portal，也是协作——律师对律师、客户对律师、律师对 agent、也许 agent 对 agent。我们在这一块投入很多时间，因为说老实话，十年前甚至今天，和一个律师一起工作这件事本身就非常痛苦，这里有巨大的空间可以做得更好。所以大概是两件事：做活，以及编排活。
主持： 你们什么时候开始做 agent 的？
雅各布： 我们基本经历了从「助手」到「agent」的切换，我们自己这么叫。
主持： 我猜大概是一年前？
雅各布： 对。
主持： 给大家一个粗略的时间线：YC 2023。
雅各布： 对。
主持： 你是 YC 的创始人。
雅各布： YC 24，Legora 是 YC 24 的。
主持： 你是 YC 23 的，Legora 是 YC 24 的。
雅各布： 对，我在 YC23，Legora 在 YC24。
主持： 那个时间点，其实 agent 还没有真正起飞，然后推理模型改变了一切。我们刚刚看过产品的一个预览版——我们私下里看的，之后会放一段视频到 YouTube——说白了，它就是「律师版 ChatGPT」，这么说很公道；但侧边栏里有很多很好用的自制工具，比如 Tabular Review，比如我很喜欢的 Intake，还有一堆别的东西。
雅各布： 完全就是这样。它就是一个 coworker，ChatGPT 在法律上真的非常好用。至于工作流，不管是公司法务，还是在找即将出台的监管，这些都覆盖到了，我们可以多聊一些产品。
主持： 你们底下用的是哪些模型？能说吗？
雅各布： 我们用好几个不同的，看任务。
03 · 05:23 模型选择器，与「模型够不够用」
雅各布： ……而这些对律师是不可见的。
主持： 是你们替他们选。
雅各布： 对。这件事我们来回反复过很多次。跟所有人一样。agent 里有一个主模型的选择器，但有些工具我们会用不同的模型，比如 Tabular Review。我们的经验是：把任务切分得越细，按切分去路由就越有效。不过现在 agent 里确实有一个选择器。
说实话，我不确定它会一直留在那儿。
主持： 我稍微补一点背景，因为我是 Cognition 的顾问。我对「什么是一个 agent lab」的判断是：理想情况下，它就是一个领域专用的 GPT 封装。我们才是领域专家，我们会盯着你、服务你的需求，比前沿实验室服务得好得多；同时我们按自己的判断，把前沿实验室里最好的东西给你。所以我们的工作就是替你决定——因为这不是你的活。
雅各布： 正是。
主持： 我们会一直把你放在前沿的边上，保证它一直是好的，你不需要扎进细节里。就着这一点说：你去找一个律师，问他「这份合同你打算起草，你觉得这是 Sonnet 的高配任务还是 Opus 的中配任务」，他们根本不知道。
雅各布： 「给我就是了。」
主持： 「保证它能跑就行。」时薪一千美元。
雅各布： 对，就是「让它能用」。
主持： 我当初来的时候就是这个想法：哦，这就是 Devin 做得不一样的地方。
雅各布： 所以现在我们的模型选择器里有五个东西，包括 Fable、Opus、Astra。人们就是想试试新出的那个酷模型。
主持： 法律这边跟工程那边一样吗？
雅各布： 我觉得一样，但程度上肯定比工程那边轻得多。不过确实有人一上来就想要最强的那一档。而且一直有人来问我们 Mythos 怎么样。
主持： 尽管实际上，很多法律工作并不需要 Mythos 级别的智能。
雅各布： 对，就是这样。基本上就是：好，我们给你这个选项。是你自己要的，但你的额度会以快十倍的速度烧掉。
主持： 我本来很不想……我们抵抗了很久才把它做进去，最后还是让步了，行吧，如果你要这种程度的控制权，那就给你。
主持： 所以你觉得模型现在已经和律师需要的一样好了？不需要再变强了？
雅各布： 我觉得这是一个幂律分布。大概有 60% 的活，我们现在就可以做得非常好，那之后就是成本和延迟的问题。但剩下的那一部分，尤其是非常复杂的分析，我们仍然需要更强的智能。而且我认为工作量本身也在扩张：现在有的是现在这些活，但「Legora 的活」大概也会随着智能一起扩张。
主持： 早期你们刚开始做 agent 的时候，用的是什么模型？我猜大概是 Opus 4.6 这样的版本。
雅各布： 那应该是。Sonnet 4.6、Opus 4.6，大概对。
主持： 那个阶段的 agent 有什么做不好、但九个月后的现在做得很好的事？
雅各布： 子 agent 委派（sub-agent delegation）是其中一个，我们现在做得很好了，像扇出式的检索查询现在效果非常好。这个以前很难。
04 · 09:18 评测：一张热力图，和用「世界」造出来的考场
雅各布： 我们做了跟踪。有一个团队就是专门做评测的。我们跟踪所有模型在不同执业领域、不同任务上的表现——执业领域是法律里的子类，每个领域里又有很多任务。所以我们基本上有一张大热力图。
然后我们能看到它们怎么移动。通常它们在大部分东西上都在进步，但其实有很多次模型发布，是在一些任务上进步、在另一些上退步。
主持： 好。
雅各布： 而且这种事发生的频率比你想象的高得多。
主持： 那些任务具体是什么？你们是怎么跑评测的？你们看的这些细分项是什么？
雅各布： 有一类是关于「框定」的。我们基本上做了很多个「世界」，本质上就是强化学习的那些环境。因为律师几乎总是按项目工作的，所以可以这样设：这里有一个一万份文件的数据室，你在做一笔尽调，最后交付的报告长这样，它包含这些红旗项，不包含那些奇怪的东西，我们希望它简洁等等。我们大概就是照着这个思路搭起来的。
所以里面有不同的任务。一部分是写报告：草稿看起来行不行？该有的东西有没有？措辞站不站得住、分析站不站得住？另一部分是找出红旗项，也就是前面那一层分析。所以我们可以把它再切细一点，评测就是这么跑的。
主持： 有意思。你们的评测团队长什么样？会招律师来做吗？
雅各布： 会，是混合的。我们有工程师，也有律师，而且是一个团队。现在是三个工程师加三个律师。此外我们还有一个池子，我们叫法律工程师（legal engineers）——通常是在大律所干过三四年的人，可能还有计算机学位，非常懂技术，然后他们来我们这儿，因为他们想改变这个行业。
主持： 他们是身在大律所的律师，还是……
雅各布： 他们是身在大律所的律师。
主持： 还有计算机学位。
雅各布： 对。
主持： 天啊，这是文氏图的重叠区。
雅各布： 就是这样。这是我们最难招的一种人。但他们也是巨大的杠杆——评测的事可以拉他们来，产品开发也可以拉他们来。你等于有 100 个专家，他们每天在用这个产品，每天在和客户谈，他们自己也亲身经历过这些，我们只要拉他们来做评测、来帮我们塑形产品，这个优势太大了。
主持： 好奇你们这个团队是什么时候开始的？评测。
雅各布： 评测是从助手／agent 团队里长出来的。有一段时间——一直到不久前——老实说做评测并不太值得，因为所有模型都在变好。所以当时的问题是：我们要不要花大量时间做很复杂的评测，还是就专心做产品？因为把 harness 做得更好能拿到太多东西了，就干脆押注「一切都会变好」，然后一切确实就变好了。
主持： 每两三个月，模型一过，就都好了。
雅各布： 完全对。我们遇到过一个引用标不准的问题，很难跟读，然后下一个模型版本就解决了，从 70% 到 99%，我们什么都没做。
主持： 也许真正的工作是让所有数据保持私密、可打标、可排序，加新功能，比如表格视图，这才是——
雅各布： 你是说在这些之上？
主持： 对。不过现在你们也做评测了，我猜你们对开源模型的使用也在增加，这个我们可以聊。我说这些其实是想问：这个岗位到底是什么？
雅各布： 早期不太是做评测，因为那时候主要是把模型的能力暴露给律师。很大一部分工作其实是：五年、十年后，法律这个职业会是什么样？编码大概领先一两年，所以我们可以稍微往那边看一点。但那之后呢——基本构件是什么？人怎么工作？如果协作不再是 200 封邮件的来回、来回传第五版 Word 文件，那它是什么样？这甚至不一定是纯 AI 的事，这就是把产品体验做好。而且要带着审计日志、数据留存，以及受监管行业里所有真正重要的东西去做。
然后是 AI 那部分：让活更快、更好，以及主动的 agent——东西进来它就反应，你不需要每一件都自己去发起。所以很多工作其实是在想：五年后我们认为它长什么样？如果模型能力继续涨、价格继续跌，我们能做什么？能不能你一登录就是一个指挥中心，说「这五件事是 agent 最近在做、你需要反应一下的」，你审核、检查、改进系统。也许我们就是往那儿去，或者已经在往那儿去了。
05 · 12:18 五年后的律师、合伙制与计费小时
主持： 能不能再深一点讲：几年后法律这个职业会是什么样？
雅各布： 开头要先声明：我不知道。这事谁说得准。但我觉得可以大量参照编码。所有律师都会比过去生产力高得多，他们能做更多事、质量更高、成本更低。这个职业本身、这个工作本身，会改善很多。律师会把更多时间花在他们当初想做律师时想做的那部分：判断什么是合适的风险画像、什么是可管理的风险，用上他们全部的判断力、战略判断，以及和客户一起工作。这部分会做得多得多，而像在大部头文件里翻找那颗「冒烟的枪」、或者干那些繁琐到极点的脏活，会少得多。
主持： 你觉得合伙制会怎么样？会留下来吗？
雅各布： 这个我上周正好认真想过。
因为这些公司的合伙制之所以存在，是因为它们唯一拥有的资本类型是人力资本。不像我们，或者不像软件公司、制造商——你有实物资产，或者一些随着时间累积的无形资产，它们给股东分红。但如果你在专业服务这样的行业里（咨询公司也一样），你全部的价值都在人身上，而你没法真正拥有人力资本。你不能拥有人，但你可以租，可以付钱给他们。所以合伙制本质上是一种结构：让拥有人力资本的人成为公司的所有者，这样他们才会留下来。
主持： 对。
雅各布： 这会变吗？不一定非得变。但我认为我们真正想和 Legora 一起做的，是让律所能够积累某种无形资产、某种耐久的资本——你能建一个学你工作方式的系统。现在很多律所的想法是「这是某律所的做事方式」，我觉得这可以编码，可以做成一个系统，不管是自进化的知识图谱还是别的什么，连同判例文件、文档，形成一套能产出很好结果的工作方式，而那可以是他们的知识产权。也就是把人的专业能力和判断固化进一个系统。我现在是在胡说了，但这是我们想帮忙赋能的方向。
主持： 那这会改变合伙制吗？合伙制里的激励是不一样的，你只要多带客户进来就行。
雅各布： 而且你不会愿意把带客户的时间拿去做「把信息固化下来」这件事。
主持： 因为你的回报来自「吃什么打什么」（eat what you kill）或者锁步制之类的。那得改一点，得设计一套激励结构，让合伙人有动力去固化东西、为公司积累资产。但现在他们没有——因为一旦离开合伙，那些他们建起来的资产，他们一分钱分红也拿不到。
雅各布： 对。
主持： 所以……我觉得整个商业模式都是「看着办」。
雅各布： 对，现在全都在被重新问一遍。
主持： 我另一个判断更多是在低端。合伙制那一层是行业的顶端。我关心的是底端会发生什么。
雅各布： paralegal 没了。
主持： 对，初级律师没了，我不需要他们。
雅各布： 但我们实际看到的不是这样。
主持： 你在工程那边看到的是这样吗？
雅各布： 呃，是。初级工程师基本熟了。你得从大学一出来就是「烤好的」，不然活不下来。我有点为了喜剧效果夸张了。
但我知道很多律师，他们是从 paralegal 做起，再读法学院，一路这样上来，而现在他们不被需要了。真的就是不被需要了。
主持： 有意思的是合伙制这个金字塔会怎么样。我总体认为律师还是需要的，你需要下一代。至少工程这边我的想法是：今天一个好工程师，比两年前值钱得多，因为他们能产出的东西多得多——前提是他们是好的。法律这边我觉得一样：如果是好律师，他们能做的活非常多。所以我更倾向于认为，真正好的律师、好的初级律师，价值高了很多。
雅各布： 一直都是这样。
主持： 是，只是更加两极化了。
主持： 我其实很好奇这一点。整个法律生意基本是按小时收费的。如果每个项目现在都能快很多做完，是不是就会便宜很多？
雅各布： 这个说来有个好玩的故事。我当时在读 Max 的 YC 申请，帮他进 YC——那时候公司叫 Legora 之前的一个名字。这是我当时的一个点……
主持： 好奇一下，那个名字在丹麦语里是不是指什么。
雅各布： 不是丹麦语，是瑞典语。也不是，它什么都不指。有个很好笑的事：早期有一家我觉得是西班牙的报纸写我们，然后解释说那个缩写是「legally efficient Yoda assistant」（合法高效的尤达助手）。
主持： 为什么是尤达？
雅各布： 我也不知道。我当时就想，为什么会是尤达？
主持： 你看，幻觉不是只有模型才有。
雅各布： 不，我觉得是记者会幻觉。
总之它什么都不指。他写了申请，我给他的反馈是：这件事人们试过一百万次了，法律科技从来就没成过，因为律师没有动力——他们为什么要更高效？他们赚得更少。这不合逻辑。
但我认为律师现在确实愿意采用它，是因为他们明白形势的严重性。他们知道商业模式也好、别的也好，都在压力之下，竞争压力太大，他们必须改变。计费模式本身我觉得也会变。我们已经看到，特别是在美国，很多东西实际上在按项目收费，而不是按小时。尤其是光谱上偏低端的那一类，比如小的审阅之类的。说实话有些干脆是免费的，有些就是一口价。
主持： 那钱到底在哪里赚？
雅各布： 战略性的工作。
主持： 我感觉你们聊得很多的是并购，钱都在那儿。
雅各布： 这是最容易举的例子。诉讼也仍然是很大的活，而且非常值钱，律师会在那上面花更多时间。客户关系也极其重要。
主持： 就像一个 CRM。不，就是花更多时间和客户待在一起。很多律所历来就是免费做点事，只为了维持和客户的关系。
雅各布： 对。所以现在他们可以继续这么做，但不必为此亏很多钱。
06 · 19:39 钱去哪了 · 拿自己的产品做尽调 · 两个市场
主持： 我一直以为，付钱给律师就是让他们当我的朋友。这不是 retainer（预聘费）的意思吗？
雅各布： 对。
主持： 你得这么跟我说我才能免费。
雅各布： 对，你只是得找对律师。
主持： 好吧。或者 Latent Space 得长得更大。我不知道。
雅各布： 我们在努力，我们在努力。
主持： 所以你的意思是：战略性的工作、所有这些高价值的活还在，律师费也没降，但你也说 paralegal 没被影响或者说只是在转型。这一点我们在 Cognition 也担心过——人们担心「我们会取代你的初级工程师」这种说法，因为没人喜欢这种话，但事实上其中一部分确实发生了，而另一些初级工程师拥抱了它、变得更有生产力，就像你刚才说的。所以这个角色、这份工作，在你们客户那里有没有一个新叫法在流行？
雅各布： 你是说「超级 AI 初级法务」？我还没找到。也许我们该造一个。
主持： 不就是 legal…… legal engineer 吗？
雅各布： legal engineer，这是我们的叫法，现在也成了行业里的叫法。
主持： 对，CS 加 JD。
雅各布： 正是。也许这些人就是最有条件做这类工作的。还有一个带贬义的说法是「meat proxy」（肉身代理）：你坐在机器前面，别人让你打什么你就打什么，然后机器让你说什么你就说什么。
但我确实认为，一个很好的 meat proxy 就是：你很懂 agent，你很懂 Legora，你知道这是你的工具箱，而每个行业都有工具箱，我可以用我的工具去做你要我做的事。
主持： 但这样你就不是代理了，你是在做有意义的工作。
雅各布： 对。就像我不再……我拿 Tabular Review 举例，这种事经常发生。我有几百、几千、上百万份……
主持： 我们一格能做一百万格（cells）。
雅各布： 在一张表里？那很厉害。
主持： 我们该聊聊那张表和窗口化。我在处理一个大案子，我有一百万份文件，我把它丢进去。通常我会扔一队 paralegal 进去，他们锁在里面干到凌晨四点。
雅各布： 那种事现在不需要发生了。因为他们可以把它抽出来，你可以重新给指令。所以现在我不需要 paralegal 来做这个。但一个很好的「超级 AI paralegal」会去做别的事。
主持： 正是——他们能做更多事，或者把时间花在以前没时间做的事情上。
雅各布： 或者真的去睡觉。
主持： 我有个问题。你们收购了一家公司——Qura，是这么念吗？然后你们用自己的产品做了这笔并购。
雅各布： 对，我们经常这么干。
主持： 那是怎么运作的？能聊聊「吃自己的狗粮」吗？
雅各布： 效果很好，我们经常这么干。我们的法务团队——Intake 就是和他们一起做出来的，因为我们现在有一个 Slack 工作流，大家把东西扔进去，他们就说这很烦。
主持： 对。
雅各布： 对，而且效率不高。所以我们就想，那我们应该为这个做一个产品。
主持： 能不能具体讲一下那个流程长什么样？
雅各布： 当然。很多尽调我们自己就做了，因为用 Tabular Review 和其他工具可以做。我们仍然会请外部律师进来评估某些风险。比如有 payroll（薪酬）在——Qura 那笔很简单，因为全在瑞典；但我们在加拿大做过一笔、在澳大利亚做过一笔，澳大利亚有 payroll，那就要问：这块我们要不要找人更战略地看一眼？那种情况下我们仍然会用律师做战略部分，他们可以真的当陪练，帮我们想清楚怎么把结构搭对。但很多更琐碎的东西，我们自己就能做完。
雅各布： 所以很多早期的东西是我们自己发现的。而且确实有几次，我们发现了某个像红旗一样的东西，然后我们就踩了刹车。
主持： 能聊一点点吗？
雅各布： 不能，我不觉得可以。
主持： 好吧。你早先说你们早期客户是瑞典的，瑞典律所。和瑞典法律市场打交道，跟和美国律所打交道，你看到区别了吗？
主持： 而且你们主要服务大律所，对吧？
雅各布： 我们也服务小所。不，我们确实是从非常大的律所开始的，但 50 个律师的所也在用我们，也拿到很多价值。
主持： 所以你看到瑞典和美国之间的差异了吗？甚至亚洲的？
雅各布： 我觉得欧洲的客户动得慢一些，美国的非常靠前、动得很快。这件事在美国公司议程上的位置也更高，比欧洲公司高。他们会觉得这是一件战略上极其重要、必须大干一场的事。美国公司——不管是企业还是律所——也更愿意自己定制东西，他们都会想做：「我们想和你们一起建这个很大的东西」，随便怎么组织。欧洲人更多是：我们就买现成的。
主持： 他们想自己建的东西，举个例子？
雅各布： 比如集成进他们自己的系统。有些客户自己建 CRM、自己建文档管理系统、自己建各种各样的东西，他们想把这些建起来，然后建触发器：你在 Salesforce 里做一次审阅，出于某种原因它流向某一个人，那个人做点什么，然后进 Legora，再回到系统里。这是简单的一端；也有一些极其野心勃勃的，等于是想和我们一起建一个全新的产品，那种我们真做不了。
但这确实是美国公司比欧洲公司更想做自己那套的地方。
主持： 而欧洲人就是：给你提产品建议。
雅各布： 当然。我们和所有客户合作都很好。他们会说这个很烂、这个很好、我们要更多这个，然后我们就做一个能做到的产品。
主持： 所以他们在自己的生意里看不到存在性威胁。
雅各布： 我觉得，美国公司看到了。
主持： 或者说，那是他们想定制的原因？
雅各布： 我不确定这是不是定制与否的原因。我认为两边都知道这件事对他们律所的成功、对企业的成功极其重要。所以对双方都极其重要，只是实现路径不同。
主持： 好，另一个问题，也许你想提出来：产品指标。你怎么知道我们在这里确实做了一件好事？
雅各布： 怎么想这件事？我猜这也和评测相关。
雅各布： 我们有一些常规的、我们非常在意的产品指标。人们在产品里待的时间长吗？他们看起来拿到很多价值吗？续费吗？回访多吗？作为企业软件，我们的数字很好——DAU 对 MAU 的比值、每月在产品里的使用时长都极高。然后我们也做在线的评测：用一个非常便宜的 LM 去大致判断「我们这里有没有解决这个问题」，做成一个在线指标。这样我们在灰度发布新东西时也能用：按 feature flag 对比，它是变好了，还是灾难性地退化了。
但有一件事对我们的生意特别难，也可能挺有意思：我们基本上看不到任何 trace，看不到任何数据，因为全都是高度机密的。这在工作上极其令人沮丧——你基本上不知道人们在做什么。有一个 agent，它能做那么多惊人的事，而我完全不知道人们实际上在用它做什么。
07 · 26:12 看不见 trace，怎么做产品
主持： 我本来还以为你们和律所签了某种协议，他们会说「没问题」。
雅各布： 我也希望。但问题是，他们手里的很多数据连他们自己都不拥有，那是他们客户的。
而且是高度机密的，所以我们看不到。所以基本上我们有一个评测团队，去近似我们认为大家在做什么，再把它做进评测集里。
这就是这门生意里一个特别烦人的死结。
主持： 能不能做改述（paraphrase）？比如 ChatGPT 有那种反馈入口，可以直接给出完整轨迹。
主持： 对你们来说当然不可能。但你可以用一个 LM 去改述，从真实的轨迹出发，造一个合成的东西，足够接近，但把所有名字改掉、所有细节改掉，可还是……
雅各布： 其实这个是有个区间的。如果你一直改述到只剩三个值、你挑其中一个，那显然没问题；如果你只是把名字去掉，那也许可以，也许不行。
我们一般选最安全的方式，尽可能限制自己，因为我们认为风险应该为零。但有些东西是可以做的：比如我们知道失败模式大概就是这十种、二十种，那我们可以把它归类到其中一种，这就是有用的信号。我们也可以归类到任务类型和执业领域，这样我们就有概念了。这件事我们一直在想怎么做得更聪明。
主持： 隐私这一块，我猜两年前要让律所接受这件事得难到爆炸。他们怎么想自己的数据被发到 Anthropic 那边？这一定是个巨大的问题。
雅各布： 我们所有基础设施都在 Azure 上。主要就是这个原因。我们刚开始的时候，律所的反应是「AWS？不行。」
主持： 「我们不信任 AWS。」
雅各布： 现在不一样了。但当时他们说的是：亚马逊、谷歌，我们不能把任何数据交给他们。所以基本上我们只能把所有东西托管在微软上，因为他们已经有 Office 365。
主持： 哦，所以他们对微软是放心的。
雅各布： 正是。因为他们已经对微软做完了各种各样的安全审查，他们所有的文档、所有的 Word 文件都在那儿。所以在他们心里，微软是一个被批准的供应商。所以我们只能把一切放在 Azure 上。
过去两年这一点变了。现在大家明白：好，我们得上云，我们得做这些事。当时还有更多人在谈本地部署（on-prem），现在这个说法完全消失了。人们理解了：你应该就在云上做，它是安全的，而且大概比你自己现在干的事更安全。
所以变化很大，但这也就是三年的事。
主持： 是个巨大的转变。对你们是好事。但我不觉得法律行业是「忽略了这件事十年」——我觉得是需要 AI 来踢所有人一脚，让大家明白必须稍微改变做法。
主持： 好。另外，开源模型现在真的越来越好了。你怎么想这件事？
雅各布： 就着你的点说：就是把客户带着走在前沿上——带着他们走完整个模型地图：各自擅长什么、延迟多少、成本多少、治理如何、区域可用性如何。我们怎么在所有这些维度上做优化？有些开源权重模型在某些任务上非常好，那我们就用在那儿；有些我们会做后训练；有些就直接用前沿模型。
主持： 你把这叫「模型套利」。你对不同模型有不同偏好。你年初是坚定的 Anthropic 派，Grok 进步很大。能不能举一个整体排名不高、但你想为它说句好话的模型？
雅各布： 我觉得是那种「整体不好」的：Gemini，早期某一代 Gemini，在某些类型的转写和说话人归属上非常好。
主持： 所以你们把它用在转写上。
雅各布： 对。
主持： 所以你们有像 Granola 那样的转写？
雅各布： 我们其实大概会做一个会议类的功能，但现在这个就是语音转文字、文字转语音，嵌在任何别的应用里。我们也会转写文件：你上传庭审录音之类，我们把它转成文字，然后所有分析都能在它上面做。
主持： 不用 ElevenLabs？
雅各布： 不用 ElevenLabs，是 DPA 的原因——数据处理协议。我们的 DPA 上供应商非常少。
主持： 因为要把它控制得极紧。
雅各布： 正是。任何数据的流向都必须收得极紧。所以这其实是 Gemini、OpenAI 这类厂商的一个优势：你来找我们，你需要的大部分东西我们都有，这非常值钱。哪怕它不是最前沿的，只要对大多数任务大致够用，谁在乎？
主持： 绝对的。
雅各布： 我也应该提一下微软的转写模型，他们做了一个 MAI Transcribe。它很好，比老的 Gemini 好。它们在竞技场分数上通常都是前二前三前四，那就够用了。
主持： 对，而且你有全套治理、扩展性也好，那大概就够了。我本来想说，现在的语音转文字是不是已经好到「这里错一个词、那里错一个词」也无所谓了？
雅各布： 不是。我做过很多这种。尤其法律里有些……我们有这么一件事：我忘了是不是在澳大利亚，法庭上对某个人有特定称呼，它一直把它转写成「condom」。
主持： 那种东西你确实不想出现在那里。
雅各布： 对。所以通常我们会在上面跑一层 LM，先抽一些关键词，再带着这些关键词重新跑一遍转写模型。我一贯的做法大概是这样。但只要你是在任何规模上做这件事，只要领域不是日常对话，你就会捞出一大堆转写错误。
主持： 对。
雅各布： 只要里面有术语，就会很难。
主持： 对。我觉得 Whisper 和 ElevenLabs 到现在还会把「Claude Code」转写成「cloud code」。这其实非常常见。
雅各布： 所以这就是为什么，还有很多可以改进的。
08 · 33:33 Tabular Review、Intake 与 Lists
主持： 我想覆盖那些大家必须知道的大件。Tabular Review 本质上是扇出：对每一份文档做同一件事，你可以把所有文档收进一张表里问同一个问题，然后来回改。
主持： 一百万格，很厉害。这里有什么工程上的考虑，或者性能上难的地方？
主持： 在我们讲这个之前，能不能先走一遍律师的用户体验和流程？他们在 Tabular Review 里到底在做什么，然后再讲工程。
雅各布： 好。一个很好的例子就是尽调：我们要审所有的劳动合同、所有的供应合同、所有这类东西。你把一万份劳动合同放进去。
主持： 每一个格子是一份劳动合同。
雅各布： 每一行是一份劳动合同，格子是你提的问题。所以第一列可能是「终止通知期是多久」，它就会给所有人填出来，30 天或者别的什么。下一个问题是「有没有知识产权转让条款」，再下一个是「如果我们解雇他们，要付多少钱」，或者「他们现在的薪酬是多少」，它会把整张表填满。
你也可以直接让 agent 来做：把一万份文件丢进 agent，说「对这个做尽调」，它会自己起一张 Tabular Review，全部跑完，等结束，然后分析结果，并且标出红旗——「这位 CEO 的薪酬高得离谱」，或者「这里有奇怪的奖金结构」。那我们就显然得看一眼。然后 agent 可以据此起草一份给客户的备忘录；也可以只做完审阅，让律师或用户来看：「好，我们看这里，这些是红旗。」它也是可协作的，你可以加评论给别人看。
主持： 为什么选表格这种形式？
雅各布： 因为它好用得多。在表格里工作极其容易，你能非常快地看到全局，审阅也容易。我们产出的所有东西都带回到原始文档的引用，所以如果你想确认对不对，审起来非常快。你还可以标记「这些审过了」「这些被标了」，可以评论、可以协作。比我们试过的任何其他形态都容易。
主持： 我得说，表格这个形态在某些领域很有拉力，但不知怎么没有扩散开。
雅各布： 我也觉得很奇怪。Clay 是 GTM 那边另一个以表格出名的。
主持： 我不知道还有别人在做「大表格 + AI」。
雅各布： 有过 V7 想发布类似 sheets 的东西，金融领域也有。但我说不出一个有把表格做得特别好听的名字。
主持： 我同意。如果你要扇出、对完全相同的事情做提取，表格是理解全局的好形态。
主持： 你们会不会必须导出到 Excel？还是人们就愿意住在你们的表格里？
雅各布： 人们就住在那儿。
主持： 你们用 AG Grid 还是自己写的表格？它看起来是领先的那一个，他们做这个大概十五年了。
雅各布： 对，他们知道怎么做。
主持： 我在表格这件事上很满意。工程上我觉得另一个有意思的是扇出。工程师大概比较能理解这里的权衡：在你把这件事扇出到一百万份文档之前，也许先在两份上试试。
雅各布： 对，这样能跑通再疯。
主持： 他们会这么做吗？
雅各布： 会。我们的表格视图实际上会先跑前 10 行。
主持： 就先检查：这合理吗？它有没有给我们看到我们以为会看到的东西？
雅各布： 对，这非常好。而且对搭这些东西的人来说，在前 10 行上快速迭代、直到拿到想要的结果，然后再全力开跑，这真的很好。
主持： 好，我们往下走。Intake，你们的 Slackbot。每个人都有 Slack bot，你们的有什么不一样？
雅各布： 我们的就是法律专用的。它的作用其实是——我们大概也会做一个纯粹是 agent 界面的，但这个专门用来起一个 agent、然后往我们的 Lists 里加一条任务。我们有一个 Lists 的东西，你可以理解成 Linear，那是最接近的类比。它会加到某个具体的 intake 列表里，然后律师和 agent 进到 Legora 里看：这些是别人发给我们的东西（我们是律所，或者我们是某个大公司的法务团队），我们可以为它们起 agent、可以协作，然后标为完成，它就会回到 Slack 里。
所以它不只是「起一个 agent」，它更像一个店面：这是我要审的东西，好，现在它回来了，谁都不用改什么，法务团队就坐在 Legora 里管理这些 agent 和所有东西。
主持： 我觉得这类东西的数据结构很有意思，因为它基本上就是一个收件箱，装的是所有可能变成这个、变成那个的查询。
雅各布： 对。
主持： 把所有这些和别的功能集成起来难吗？还是你们就不管？
雅各布： 不难。我们有一些非常好用的基本构件。Lists 就是一个很好的构件，因为它极其灵活，本质上像一个 Notion 数据库。
主持： 对，Notion 数据库。
雅各布： 像一个 Notion 数据库，你可以按任何需要去配置它。我们当然投入很多把它做到极度可扩展、极度可靠，你可以在上面挂触发器、自动化。它是一个很好的胶水，可以把一切粘起来：可以因为列表里发生了某件事而起一次 agent 运行，跑完回来填一个字段、加新文档或者别的什么。
所以就像你可能用 Linear 或者某个任务管理工具去协调一堆编码 agent，我们用 Lists 做类似的事。agent 可以创建列表，列表可以创建 agent，agent 可以读列表。于是 agent 群就活了。
主持： 人们会为此兴奋还是被淹没？我觉得这基本上就是终端用户编程，你可以让人搭出疯狂的自动化。
雅各布： 有些人会极度着迷，他们会变成影响者那种。
主持： 值得吗？还是太复杂了？
雅各布： 我们需要这种灵活性，即使我们并不真的把它暴露给终端用户。假设这些全是内部的，那对我们就是一个非常快的方式，让我们的法律工程师这样的人极快地搭出很多产品。你可以搭定制的基金管理看板，基本上用你自己的生成式 UI 建在 Lists 上，然后你就有了一件新产品，一部分人会非常喜欢。我们可以有一个专门产品的市场，全都因为法律工程师可以随时搭新的而极快扩展。他们在客户那儿，客户说「我们想要自己的一套」，那就给你搭一个。
所以某种意义上 Legora 里有一个小小的 Lovable。如果我们不想暴露它，那也是我们自己搭定制功能的方式。
我们还做了另一笔收购，英国的 Wexler，他们做事实智能（fact intelligence），主要给诉讼用：你上传一个案子的上百万份文件，我们用命名实体、日期这些东西把事实抽出来，然后你把所有事实摆在一起，就能看出哪些互相印证、哪些互相矛盾。这极其强大，因为你还可以把一场庭审转写出来，然后说「他这么说了，但这边的邮件显示不是这样」，如果你现场看着，那感觉太酷了。这也可以建在这个基本构件上。
所以我们能在这一个构件上搭出很多很酷的东西。这就是我们的思考方式：随着公司扩张，要解决的问题太多了，我花很多时间想的是——怎么搭一个核心构件，能扩到很多不同的终端产品、做出高度可定制的体验。
09 · 40:15 撞上 Wexler、FDE 与「谁写代码」
主持： 好，那你们有哪些核心构件？给大家复述一下。
雅各布： Lists 是一个核心构件，可配置。Projects 基本上就是文件的容器、文件系统。当然还有 agent，可以用非常不同的配置去起它、跑它。
主持： 顺便问一句，agent 有名字吗？
雅各布： 没有。
主持： 好吧。
雅各布： 你是说我们以前叫它 Legora、给它起过一个名字那种？
主持： 对，那会挺酷的。人们以前把它当成一个有名字的实体来讲。
雅各布： 但我们停了。
雅各布： 也许哪天会拿回来。可能会让人困惑，我不知道。
雅各布： 所以就是 Lists、agent、Tabular Review……表格视图你往下拆可以拆到任意细，但那些大概就是大的几个。
主持： 我其实想聊一下 FTE（驻场工程师），因为这听起来很像那回事。Max 也提过一点：当你接入一个新的大客户，你想尽快给他们价值，这样他们才会留在 Legora。
雅各布： 对。
主持： 这个是怎么演化的？你们什么时候开始有驻场团队的？
雅各布： 我们招的第一个驻场工程师，也是我们在纽约的第一个员工，也是一位 YC 创始人。大概九个月前，我不太确定。
主持： 他们算法律工程师吗？
雅各布： 不算，是工程师。但这里面是我一直在想的事：我们怎么在规模上真正把这件事做起来。我认为一个很核心的问题是：怎么赋能我们的法律工程师、赋能我们的重度用户，让他们能强力地定制这个产品。
当然我们仍然会有驻场工程师帮忙做所有定制集成、做界定、搞清楚什么是可能的，并把这些全部反馈回核心产品开发。所以我的想法大概是：这几乎是一线、二线的分工。法律工程师应该能定制很多很多东西、搭出很好的体验；在他们做不到的地方，或者需要我们改核心产品、做定制集成的时候，我们有驻场工程师。
主持： 他们也会来回轮转一下：有时候只是做产品，有时候和客户一起。
雅各布： 对。
主持： 能不能走一个例子：你刚签下一个新客户，第一步是什么？是「好，我们给你派一个驻场工程师，他会给你搭点东西」吗？
雅各布： 每个客户都很不一样。但如果是一个很大的客户、他们非常投入、脑子里有一堆想做的事，或者更典型的：他们已经试过自己搭一个东西、失败了，然后说这是我们想解决的问题。那我们基本上会给他们配上法律工程师，视情况再加一个驻场工程师，然后说：这些人会来，他们会让你成功——他们会和你的律师坐在一起，教他们怎么用，把你们现在的工作流全部摸清楚、建进 Legora 里。其中一部分只是法律工程师，一部分需要驻场工程师。
主持： 这个分界是什么？
雅各布： 法律工程师像重度用户那样配置产品。
主持： 他们不写代码。
雅各布： 对。
主持： 而驻场工程师基本上是往生产环境里写代码。我猜这就是分界。
雅各布： 对。
主持： 驻场工程师一般是什么背景？你说是创始人。
雅各布： 创始人、普通工程师。
主持： 那位 D 是你的……
雅各布： 对，正是。D 是我们的第一个。她做过两家 YC 公司，在 Meta 做过搜索。她很棒。她是我们在美国的第一批落地的人。
主持： 这是个很高的门槛。
雅各布： 她很好。
主持： 那他们为客户搭的东西，有什么例子吗？有没有那种「所有律所进来第一件事都是这个」的用例？
雅各布： 非常不一样。有些核心工作流每个人都有，那我们直接在 Legora 里做掉——比如「我们这类 NDA 是这么处理的」，你激活一下就行，那更像是技能搭建。对大多数驻场工程师来说，更多的是：有什么我们现在做不到，需要某些构件更灵活一点；或者我们有一个非常复杂的系统需要集成。那他们就出去，对着我们的 API 建集成，必要时扩展我们的 API，把这件事跑通。
主持： 那法律结构上怎么运作？你说你们自己连交易都不能做。
雅各布： 对。
主持： 那他们怎么参与客户的项目？
雅各布： 他们仍然不碰数据。他们只是把系统建起来。但他们有时也会像员工一样被接入：可能会拿到一台笔记本之类的，如果需要的话。
主持： 有意思。这种事不常发生吧？通常他们只是建一个集成，然后它在跑。
雅各布： 对，不常发生，但需要的话可以。
主持： 我猜只有在客户有某个规模时，你们才会往里面派 FTE。
雅各布： 对，得说得通，因为驻场工程师也可以做核心产品。所以这永远是一个优先级问题。
主持： 有没有像 Palantir 那种著名的规则——四天在现场、一天回来说给产品？或者类似的东西？
雅各布： 没有。跟你们说实话，很多这些东西都还在早期。
10 · 47:24 API 之争与「300 斯巴达人」
主持： 未来一年你觉得会往哪儿走？
雅各布： 我不觉得会完全像 Palantir 那样，但我想我们会有一批更大的、持续在流转的驻场工程师：和一个客户坐两个月把这件事搭出来，然后去下一个。我能想象的就是带着法律工程师和驻场工程师一起，去做具体的项目。
主持： API 这件事其实很有意思。因为你也可以定一条规则——
主持： 你是 Legora 平台的 CTO。
雅各布： 对。
主持： 就是「我们在 Legora 网页版里有的所有东西，都会作为 API 提供，你们随便用」。这是你们要做的承诺吗？
雅各布： 那不是我们现在承诺的事。我们确实有 API 可以对着建，但不是产品的全部界面。
主持： 有意思的地方就在这儿：这是策略吗？显然有人会喜欢，因为我不必学一个新工具，我可以直接用现有的工具，比如装上 Legora 处理 Word 文档那部分。
主持： 除此之外，你就得维护它。
雅各布： 正是。这就是我一直的想法，也是我们尽量不去做的原因。我们一直没有 API——我们大概六个月前才开始做 API，抵抗了很久。主要是因为产品动得太快，我不想被「为一个已经改过的数据模型去维护旧版 API」拖慢。现在我们大了一些，情况不一样了，这个成本我们承担得起。但当我们只有 20 个工程师时，我们动得太快，做不了这个。
我一直在琢磨：所有公司都该有平台团队和产品团队，因为产品团队你有一个，只要平台不是死死贴着产品，你就能很容易起第二个。
雅各布： 举个很简单的例子：网页版、移动端，或者网页端、移动端、RTP，再加上别的集成。那你的驻场工程师就只是整个平台上的又一个客户。
主持： 对。我觉得连 agent 都可以这么想：有一个跑 agent 的 harness 团队，然后你在它上面用技能、自动化这些东西搭产品。
雅各布： 这就是亚马逊 AWS 那条著名的命令：贝索斯说不再有后门访问，你只能把 API 提供给别的团队——和你提供给客户的是同一套 API。没有就自己建。
主持： 然后客户也拿到了。
雅各布： 对。我觉得这一点也在变。现在很多 API……我们正在琢磨的一件事是：agent 能不能就是 API？我知道听着很怪，但对某些东西来说，他们真正想做的是触发某些事情发生。对其中一部分，可能就是「你触发 agent，让它去做这件事」。显然这比一个你一直打、稳定的 API 低效得多，但我在琢磨的是：我们产品里到底有多少可以就只是那个 agent，多少得是别的东西。
主持： 那就是无界的执行、成本和延迟。
雅各布： 对。
主持： 这是唯一的阻碍吗？
雅各布： 还有确定性。可能一百次里有两次它会做出我们不想要的行为。
主持： 我们等会儿会聊 harness 和模型微调。但我想这里有一个关于「克制」的产品问题：你不做什么。因为那些你都可以做，显然这是优先级问题——你现在是更倾向于「对大多数事说不，只做很少几件」，还是「不，我们想做更多事，那就再招一百个人」？
雅各布： 很久以来我非常坚定地是第一种：对一切说不，把工程团队控制住。我以前说过，我在 Legora 待了半年后，翻出过一页《300 斯巴达人》的电影剧照，说：我们这辈子就保持 20 个工程师，然后打赢所有比我们大得多的人。现在我们有 100 个工程师，还是觉得人太少。
我本来想那样，但现实是我们身处激烈竞争，人们想要的东西太多了。我可以做一个清教徒，说「不，我们就 20 个人，我们只能建这些」，然后我们就输了，人就去别处了。所以我们必须建更多。那我的工作就是设计一个系统：我们能建很多，但实际上只在少数地方建——客户感觉我们建了一大堆东西，而我们其实只建了少数几个。这是我现在对自己工作的理解。
主持： 基本构件就是对的。
雅各布： 正是。我觉得那会非常强大。至于试新东西、看有没有拉力，然后再决定「不，还是专注主业」——
我们没怎么试过。我们做过一些战略性的赌注，但没有去试那些我们自己都还没什么信心的东西，主要因为我们面前就是一座需求大山：这些都想要。所以对我们来说，「哎这个也许能成」不太说得通，因为有太多人在为别的东西喊。
所以我们主要是建那些。偶尔我们会不同意客户，说「其实这边这个在战略上更说得通」，然后我们还是去做那个。
主持： 对你来说战略上说得通。
雅各布： 对，正是。
主持： 那些具体是什么？
雅各布： 其中一个是 agent。没有人真的在要求「我想让我在用的助手更有主动性、不用我说就去做事」——从来没有。但我们就是认为行业一定往那儿走，这会让你能做很多很酷的事。协作是另一个：我们认为行业会走向在你工作的地方协作，也就是在 Legora 里，而不是在邮件和短信里。有那么几个这样的东西。
11 · 53:05 后训练、检索与引用系统
主持： 那大多还是法律工程师。
雅各布： 对，大多是法律工程师。有些人愿意的话会叫他们「驻场法律工程师」，但本质就是这个。他们进去，帮客户围绕 agent 的能力重新组织工作流。
主持： 你们之前说过——我记得是 Max 说的——早期你们没有微调自己的模型。现在还是这样吗？
雅各布： 到现在我们还没有微调过任何模型。但过去几个月，开源权重模型变得极有能力了，所以对一些任务我们会做：当我们认为前沿模型在成本、延迟上能做的，和我们认为后训练模型能做的之间有巨大差距时。法律检索就是一个好例子：它是一个扇出检索问题，你可以让一个非常有效的模型超快、超便宜、低延迟地跑这些查询。
主持： 所以你们是专门把它们后训练得在非常具体的、有边界任务上更好。
雅各布： 正是。我们不是在训练自己的 Fable 来当主 agent。我觉得那场我们赢不了 Anthropic。最可能的是，还有很多检索、RAG 方向的研究要做。
主持： 那可能没那么光鲜。甚至不一定是模型训练，有时候只是架构和管线。你们和 Turbopuffer 做过一个案例，你们做 late interaction 吗？
雅各布： 其实我们没做。但你说得完全对，这确实是方向。团队里有一个人，他非常在意检索，他经常跑来找我说我们应该做这些、有新的 embedding 模型、我们可以做 late interaction。他其实跟 Turbopuffer 团队谈过，让他们做 multivector，好让我们能做这类事。
但没有，即使在模型之前、甚至在 harness 里面，都还有大量低垂的果实。如果你想给客户做出更好的产出，在训练模型之前就有太多能立刻见效的事可以做。
主持： 什么算是法律行业的好 harness？我猜你们在搭自己的定制 harness。
雅各布： 当然。我们怎么编辑文件很重要，我们怎么做分析很重要，我们怎么做法律检索，全都烤在里面。比如一个问题冒出来，或者你看到某个东西，它知道该怎么去做法律检索、搞清楚答案是什么、判例是什么——这些都极其重要。当然还有围绕它的一整套治理。
主持： 看起来检索大概是你们在定制的最重要的工具，因为如果你拉不进正确的信息——
雅各布： 那就完了。
主持： 你们要检索很多文档，还有分析。
雅各布： 对。检索、分析，大概还有起草。因为起草一份很长的合同其实也一点都不简单。
主持： 不简单在哪里？
雅各布： 假设你从零起草一份很大的合同，你得先找到先例：以前我们是怎么做的、这个条款我们要不要。具体某个律所以前是怎么做的。
主持： 对。
雅各布： 所以我就是那家律所，我要起草一份很大的……NDA 很简单，但有些合同复杂得多。你得先找到正确的先例，因为律师不是坐下来就开始敲字。他们要搞清楚：在类似的交易里我们用过哪些条款？而「类似」可以指很多东西——同一个行业、同类型的公司、同样的什么。所以你得把正确的先例找出来，然后你可能有好几份文档，得判断哪一段该从哪份文档里取，这其实一点都不平凡。所以它本质上也是一个检索问题。
主持： 哪个模型起草最好？
雅各布： 我昨天还在说这件事。Fable 和 Opus 极其话多。你们肯定知道，它们非常啰嗦。
主持： 那就不好。
雅各布： 一般来说不好。我注意到 Astra 写作挺好。
主持： Astra，对，写得挺好，简洁得多。
雅各布： 对。
主持： 你们是不是跑 100 个不同的问题去……
雅各布： 当然，有些事我们可以做。但「话多」这件事对我们来说其实有点难处理。不过 Anthropic 下一个模型大概会好很多。Astra 确实非常简洁。
主持： 我猜他们和你有一个 Slack 频道，你在里面告诉他们这些吧？这对他们不是新闻。
雅各布： 他们知道。然后另一件我很在意的事是幻觉。
主持： 它们会编东西吗？
雅各布： 我们有一套引用系统：基本上就是检查它们写的东西有没有链接。用户有一个链接可以点，它会像在 PDF 里那样用一个框高亮出这段信息是从哪儿来的。我们可以确保它说的东西总能在某处被引用到，甚至是往下好几层——比如 agent 基于一次 Tabular Review 写了东西，它可以引用表格里的那一格或那一行。所以你可以一层层点下去，一路验证上来。
主持： 你们发现律师会去验证这些引用是否正确吗？
雅各布： 一开始会，但现在……就像幻觉出来的最高法院链接，他们不在乎了。
主持： 确实会发生。我觉得这就像编程：有的工程师完全不管，直接把 agent 发出去；有的人会坐下来读每一个逗号。一样的。
雅各布： 而且量太大了，一个人怎么可能做得完。
12 · 59:00 百万 token、被断供，与招聘
主持： 我觉得他们大概只是像我们做代码评审一样：知道该看什么。他们也知道「这个是重要的红点，我只要复核这几处」，然后「这些听起来合理，那大概没问题」。
雅各布： 对。
主持： 就像你收到一个初级律师交来的东西，你做的是同一件事：这个我该复核，这个大概没问题。
主持： 还有别的什么，我们叫它法律推理也好、法律前沿也好，是模型还不够好、你希望下一代模型能解决的？
雅各布： 我现在想不出特别具体的。我觉得长文档推理仍然很难。
主持： 长，比如一百万 token 的上下文。
雅各布： 正是。你有一份巨大的合同，你要在上面做修改，这对今天的模型来说就是难事：你得记住你在这上面改了这些，定义变了，顺序也变了。最简单的做法是一次性全塞进去、一次性输出。但我们不这么做，我们把它切成块，然后编排这些修改。
主持： 对，正是。这也是这个行业里做起来很有意思的事之一：我们的 Word 插件做过 map-reduce，改过，有过一段时间是一次大上下文，然后又回到大上下文，反复好几次。模型一变，我们围着它搭的脚手架就得跟着变。
主持： 我要说，我自己因为做新闻报道，最近从 map-reduce 转向了「把所有东西都塞进上下文」。
雅各布： 而且更好。
主持： 对，但它也不一样。我们在检索上就遇到这个问题：你要在一份巨大的合同里找某些东西，可以用 map-reduce，但如果你是在做某种摘要，它就可能在块与块之间丢掉一些重要的细微之处——如果你只是把各部分分别摘要再拼起来。所以我们这里有这个问题：我们可以做两种检索，另一种是需要在中间各步做推理的。
我努力想一个好例子。有些文档会用两页篇幅详细讨论某件事，其中单独每一个块跟你的检索词、跟你要搞清楚的问题都不一定相关，但合起来就极其相关。这就是那些问题之一。
主持： 而且这一定很难，就像你早先说的：你没法真的去看那些合同、那些真实合同。所以你们会不会问客户：你们能不能做一些跟真实合同相似的样例合同？你们有反馈渠道，可以收到他们的反馈，如果他们愿意配合——或者他们主动来说这很重要、这个跑得不好，那我们就说：太好了，你能把文档和 prompt 匿名化吗？如果我们能复现，我们就能修。
雅各布： 对。这件事的一个版本就是：你买一家律所。
主持： 对，有人在考虑这个。
雅各布： 但这里面有个问题：他们的数据到底是不是他们的数据，还是客户的数据。如果客户都走了，那也许可以。我其实不知道。
主持： 有意思。
雅各布： 但那是一条拿到大量数据的路。就像 Google 那样买下来，一百万或者多少。
主持： 就像你有一家失败的公司，你的 Slack 还在，你可以把 Slack 卖掉。我记得有一家 YC 公司专门收购你失败的公司。
雅各布： 有的。
主持： 因为「我就是想要真人在干活」。
雅各布： 正是，然后就慢慢把东西抽出来。
主持： 正是。买律所数据的问题是：你能拿到全部的输入——真实的输入，这很好；但输出比较麻烦，因为你只拿到最终结果，很难判断，你得反过来推他们是怎么到那儿的。而在我们的产品里，拿到真实用户的真实轨迹，价值极高；但如果只是拿到这个输出、又不知道它是好是坏、是怎么造出来的，就有点难。
我们快收尾了。最后我想给大家指个方向：embedding 上还有很多 alpha。如果你是一个 RAG 很重的工作负载，却只看 MTEB、只拿排名最高的那个模型，你在桌上留了很多东西。你应该看看 Voyage，或者一些定制的 embedding。
主持： 对。
雅各布： 基本上就是：不要用默认 embedding，哪怕是开放的 embedding、Gemini 的 embedding，都无所谓。定制你的 embedding。
主持： 对，你会支持这个。
雅各布： 对，我认为这是对的。唯一要注意的是多语言。我们服务很多语言，所以这一点……（很关键）
主持： 欧洲在这方面是王者。
雅各布： 对。
主持： 对此有帮助。不过到目前为止也没有——他们刚刚融了一大笔钱，所以也许。
雅各布： 对，你们也是。
主持： 他们也融了一大笔钱，来给你们当冠军。
雅各布： 我认为欧洲需要多得多模型公司。
主持： 我想问你有什么预测，比如未来一年，对法律行业？这个我们前面聊了一点。我改成第二个问题：两年后，律师会在 Legora 里做他们的工作吗？还是他们会用别的工具，比如 Claude，或者像你这样的 API？
雅各布： 我觉得两者都有，看情况。如果你是一个大企业，你可能会有 Claude 的 cowork，然后……这有点像我用 Claude 用 Linear，但我还是会去 Linear。我认为企业会那样。而律所会直接用 Legora，因为那更简单、更好。
主持： 这让我想起医学里的 OpenEvidence——你基本上就是法律界的那个。
雅各布： 对，正是。
主持： 编码已经到了一个点：如果你和实验室竞争，它们会掐断你。这种事已经发生过两次。你觉得法律会这样吗？
雅各布： 不，我不这么认为。因为他们自己也在推出法律服务。我们当然跟他们聊很多，但……他们销售代表会说不会——但决定不是他们做的，他们甚至经常不知道实际在发生什么。
我不认为会这样。他们在知识工作上、在企业知识工作上要拿的东西太多了，法律必须是其中一部分，就像数据分析、销售、市场、财务必须是。所以他们必须在那里做出好东西，但他们永远不会像我们做得这么深。如果 Claude 拿走一些小客户、一些中小企业客户，让他们通过 Claude 做一些法律工作，那很好，没关系。但如果你在做一笔四亿美元的并购，你会想要 Legora。
主持： 我有个不太相关的问题，但我很好奇：你们会去法学院，让他们在课上教 Legora 吗？这是怎么运作的？
雅各布： 这确实是一个我们在做的项目，应该已经开始了。我不太清楚我们现在具体走到哪一步，但我们确实希望法学院的人学会用 Legora。
主持： 你觉得法学院在课程上变化大吗？
雅各布： 我不知道，这个我真不知道。
主持： 有意思。
雅各布： 我其实会换个做法：你应该给法学院设奖学金，专门给计算机专业的学生、给工程师。你读完 CS 之后，我们送你去法学院——CS 加上一些软件经验，我们送你去法学院，我们出钱。
主持： 就是那种硕士加 JD 的项目。
雅各布： 硕士那部分你不在乎。
主持： 意思是，很多人本科没读 CS，所以他们读个硕士补一下。
雅各布： 对，我不太常见到这种情况。
主持： 有人读 JD-MBA，那是有的。但 JD-CS，我没见过。
雅各布： 有的。
主持： 好，整体来说，进步非常惊人，恭喜你们所有的成绩。你们还会保持这个节奏吗？我记得你们在旧金山、纽约招人。
雅各布： 我们在招工程师，在纽约、斯德哥尔摩和伦敦。其他所有岗位我们也在到处招。
主持： 你们现在纽约有多少人？
雅各布： 100。
主持： 那你们计划在纽约到多少人？
雅各布： 纽约？很多。能招多少招多少。
主持： 很有攻击性。
雅各布： 对。
主持： 这就是整个公司法务市场，就美国而言。我期待你们买下一家律所，然后……这很让人兴奋。我觉得每个行业，尤其是医生、律师、程序员，都得有两三家 agent lab 完全统治这个空间。你们有一个很好的市场。
雅各布： 我也这么认为。而且我认为它只会大得多，随着法律变化、变得更普及、更多人能用。
雅各布： 另外，我们其实已经非常超前了，但你做的这些问题是知识工作的最前沿。除非你真的是在做科学、做纳维-斯托克斯方程之类，否则大多数工作基本上都会收敛到法律。
主持： 说到底全都是法律。招聘、财务，什么都得咨询我的律师。所以我觉得这是一个非常值得做的东西，因为现代社会在某种意义上就运行在法律之上。
雅各布： 对。好了，就到这里，谢谢。
主持： 谢谢。
References
- 1Legora 宣布 5.5 亿美元 E 轮
legora.com
- 2本期单集页
latent.space
- 3Legora · Tabular Review
legora.com
- 4Legora 收购 Wexler
legora.com
Comments