看不到数据时如何打造法律智能体——Legora 首席技术官 Jacob Lauritzen

大家都在问我们 Mythos 之类的东西。但说实话，很多法律工作确实用不着 Mythos 级别的智能。

“律师助理都没了，初级律师也没了，我不需要他们了。”但我们实际看到的并不是这样。

我们碰到过一个问题，模型引用判例不太对。后来下一版模型一发布就解决了，准确率从 70% 涨到 99%。我们什么都没改，效果就上去了。

不过，如果你要做一笔 4 亿美元的并购交易，你肯定会想用 Legora。

我们当初还说，公司以后永远只要 20 个工程师，就能打赢那些规模大得多的对手。现在我们已经有 100 个工程师了，还是觉得人手远远不够。

我最近也在琢磨，我们的产品有多少可以直接由智能体来完成，多少还需要其他东西。

没问题，这样就行。我知道这个姓是丹麦来的。

“sen”就像“某某之子”，比如你会看到一些姓氏里带着这个后缀，所以我的名字大概就是“Lord 的儿子”。

我觉得我们骨子里一直挺谦逊，因为从一开始我们就是挑战者。最初的时候，没人相信一家在斯德哥尔摩地下室里的小创业公司，能和美国那些遥遥领先的巨头竞争。

当然。一切最初就是一个接入了瑞典法律和搜索工具的 ChatGPT，这几乎就是全部。

这个一定得聊聊。

Tabular Review 能批量提取和审阅大量协议，常用于尽职调查、融资等场景。它帮助律师把工作做得更高效、更好。

我们基本上经历了从助手到智能体的转变，大概是一年前吧。

YC 2024。

没错，就是法律工作特别好用的 ChatGPT 同事。它能支持企业内部律师的流程，比如跟进即将出台的法规。后面我们还可以多聊聊产品。

我们会根据任务使用不同模型。

这个问题我们反复讨论过。和其他团队一样，智能体里可以选主模型，但某些工具会用不同的模型，比如 Tabular Review。我们发现，把问题拆成小任务，再按任务路由模型，效果最好。不过目前智能体里确实有模型选择器。我不确定以后会不会一直保留。

没错。我们会让你始终用上最先进的模型，确保体验一直很好，你不必钻研所有细节。

只要能用就行，毕竟他们每小时收费 1,000 美元。

法律行业也跟工程行业一样吗？

不过说实话，大多数法律工作并不需要 Mythos 级别的智能。

我们很长时间都不愿意加这个功能，最后还是让步了：如果你想要这种控制权，那就给你。

要看工作类型。可能有 60% 的工作，我们现在就能做得很好。接下来主要是成本和延迟问题。但剩下的工作，特别是非常复杂的分析，仍需要更强的智能。模型能力越强，可能也会让工作范围扩大。

应该是 Sonnet 4.6，Opus 4.6 也差不多那个时候。

子智能体委派就是一项。现在我们已经能很好地用它来并行展开检索查询，以前这很难。

我们会搭建不同的“世界”，本质上像强化学习环境。律师的工作通常都围绕具体项目展开。比如，给智能体一个有一万份文件的数据室，让它做尽职调查，最后生成一份报告。报告需要包含所有红旗问题，不要塞进无关内容，而且要简洁。

会，是工程师和律师混编的团队，目前大概三名工程师、三名律师。我们还有一批叫“法律工程师”的人，通常在大型律所工作过三四年，有些也有计算机科学学位，技术背景很强。他们加入我们，是想推动这个行业改变。

对，是大型律所的律师。

是。

天哪，这两个领域的交集太难找了。

这种人才确实最难招，但他们也能带来巨大的倍增效果。我们可以请他们参与评测和产品开发。公司有一百位专家每天都在用产品、每天都和客户交流，他们亲身经历过这些工作。我们能借助他们做评测、打磨产品，这是很大的优势。

评测团队是从助手和智能体团队里逐渐发展出来的。直到不久之前，我们一度觉得做复杂评测不太值得，因为所有模型都在变好。与其花很多时间做评测，不如先把智能体框架做好，借助模型整体进步带来的提升；当时模型确实一直在进步。

对，差不多每两三个月就会有进展，直接接入新模型就行。

没错。我们遇到过一个引用不准确、很难追踪的问题，下一版模型就解决了，准确率从 70% 涨到 99%。我们什么都没改，效果就好了。

早期评测可能没那么重要，因为当时主要是把模型能力开放给律师使用。

很大一部分工作，是想清楚五年、十年后法律行业会是什么样。编程领域可能领先一两年，我们可以从那里找些参考，但我们还得弄清楚基本工作单元是什么、人们会如何协作。未来协作会是什么样？难道还要靠两百封邮件来回传 v5 版 Word 文件吗？

先说我也不知道，谁能说得准呢？不过我觉得可以多看看编程行业。律师的效率会大幅提高，能以更低成本做更多、更高质量的工作，整个法律行业和工作本身都会变好。

我上周刚认真想过这个问题。合伙制的出现，部分是因为律所拥有的资本只有人力资本。制造业或软件公司会积累实物资产或无形资产，再给股东带来收益；专业服务公司和咨询公司则主要靠人才创造价值。人不能被拥有——奴隶制已经废除了——但可以雇用。合伙制本质上是让人力资本的所有者成为公司的所有者，这样他们才会留下来。

整套商业模式都值得重新审视，之后再看吧。

初级律师也会消失，我们不需要他们了。

律所的金字塔结构会怎样？我觉得仍然需要培养下一代。至少在工程领域，我的看法是，优秀工程师今天比两年前更值钱，因为他们能产出更多。如果能力够强，就能做很多好工作。法律行业也一样：优秀的律师，甚至优秀的初级律师，会更有价值。

说个有趣的事：我当时读 Max 的 YC 申请，帮他把当时还叫 Leia 的公司申请进 YC。我当时就想，大家已经试过无数次法律科技了，为什么这次会成功？律师为什么要提高效率，赚得反而更少？这在经济上说不通。

不是，是瑞典语……不，其实也没有特别含义。早期有家西班牙报纸写我们，还把 Leia 解释成“Legal Efficient Yoda Assistant”（高效法律尤达助手），我也不知道为什么是尤达。我觉得记者也会“幻觉”。

你们常说并购是价值所在。

这是个很容易理解的例子。诉讼也仍然是很重要、很有价值的工作，律师会把更多时间投入那里。

不是说要做 CRM，而是要花更多时间陪客户。过去很多律所会免费做些事，只为维系客户关系。现在他们也能这么做，不必因此亏很多钱。

找对律师就行。（笑）

你是说“超级 AI 初级法律人才”吗？我还没听到合适的叫法，也许我们该造一个。

对，这已经成了行业里的说法。

我们能处理多达一百万个单元格。

正是如此，他们能做更多事情，或把更多时间花在以前顾不上的工作上。

对，我们一直这么做。

很好。我们的 Intake 功能就是和内部法务团队一起做出来的。大家以前把各种请求都扔进 Slack 工作流里，觉得很麻烦，我们就想把这个流程改好。

这个我就不方便说了。（笑）

我们也和小律所合作。起步时客户确实都是很大的律所，但只有 50 名律师的律所也在用我们，觉得很有价值。

欧洲律所的行动速度稍慢。美国律所更积极，推进很快，也把这件事放在战略议程的前列。美国企业和律所都更愿意定制开发。他们会说：“我们想和你们一起打造一个大系统。”欧洲客户则更倾向于直接使用现成产品。

有些客户会自建 CRM、文档管理系统，还想做各种流程触发器。比如在 Salesforce 里做完审查后，任务先分给某个人处理，再流入 Legora，完成后回到原系统。这是比较简单的例子。也有更雄心勃勃的客户想和我们一起做一个全新产品——这我们还真做不了。（笑）

所以他们不会觉得这是生存威胁，而美国客户会？

我不确定这是不是他们愿意定制开发的原因。我觉得双方都知道这对律所和企业的成功极其重要，只是实现方式不同。

我们会看常规产品指标：用户是否常用、是否觉得有价值、是否续约、会不会经常回来。对于企业软件来说，我们的 DAU/MAU 和用户每月在产品里花的时间都非常高。

我也希望如此。但很多数据甚至不属于律所，而是属于他们的客户，保密级别很高，我们没法查看。所以评测团队只能尽量推测大家会做什么，再把这些场景建进评测集里。

这件事有个尺度问题。如果把内容彻底抽象成几个选项，再挑一个，通常没问题；但如果只是删掉姓名，未必就够安全。我们尽量采用最谨慎的方式，把风险压到最低。另一方面，我们也知道常见失败模式大概就十到二十种，可以把问题分到某一类，这会提供有用信号。我们还可以按任务类型和法律业务领域分类。目前我们一直在想办法更聪明地处理这些问题。

我们的基础设施都在 Azure 上，主要就是因为这个。刚开始时律所会说：“AWS？不行，绝对不行。”他们不信任 AWS，也不想把数据交给 Amazon 或 Google。所以我们必须托管在微软，因为他们已经在用 Microsoft 365。

对，他们已经审核过微软的安全性、文件和 Word 等服务，在他们看来微软是获批供应商，所以我们得用 Azure。过去两年情况变了很多，大家开始接受上云，也逐渐不再要求本地部署。人们认识到云端是安全的，甚至可能比自己现在的做法更安全。

这就是所谓的“模型套利”。你年初明显更偏 Anthropic，现在 Grok 进步也很大。有没有整体排名不算高、但某方面出乎意料好用的模型？

Gemini 早期有个版本，在某些类型的转录上特别好，比如转录和说话人识别，我们用它来做转录。

我们还没有，不过可能会做会议产品。目前只是应用里的语音转文字、文字转语音功能。用户也能上传庭审等文件，我们会转成文本，再做分析。

因为数据处理协议（DPA）的原因，我们协议里能列的供应商很少，必须严格控制数据会流向哪里。Gemini、OpenAI 这种服务的优势之一，是用户可以找一家供应商满足大多数需求；即使模型不是最先进，只要多数任务够用，就很有价值。

微软也有自己的转录模型。

对，微软的模型表现不错。通常它们在排行榜上都排前二、前三或前四，足够好了。再加上治理能力和可扩展性，也就够用了。

我做过不少这方面的事。法律领域会碰到特殊问题：有个法庭人员的称呼，具体在澳大利亚还是别处我忘了，模型总把它识别成“避孕套”。有些词确实不该出这种错。

有行话就更难。

对，还有 Word 插件也很重要，因为很多人就在 Word 里工作。Outlook 插件也一样。

一个典型场景是尽职调查：需要审阅所有劳动合同、供应合同等等。比如放进一万份劳动合同，每一行代表一份合同，每一列对应一个问题。第一列可能问合同的解约通知期，系统会把每份合同的答案填进去，比如 30 天。下一列可以问有没有知识产权转让条款，再下一列问解雇时要付多少补偿、薪酬是多少，整个表格都会填好。

表格很容易上手，也能迅速看清整体情况、方便审阅。我们生成的内容都有来源文件引用，用户可以很容易核查。还可以标记已审阅的内容、标出问题、评论和协作。我们试过其他形式，表格最好用。

以前 V7 试过，金融领域也有些表格产品，但还没有特别领先的。

我同意。要是把同一个任务并行分发到很多文档里，提取结果，表格就是非常合适的形式，让人一眼看清发生了什么。

他们愿意直接在我们的表格里用。

他们确实很懂这个。

对，我们的表格视图会先处理前十行。

我们这个专门为法律工作设计。它会启动一个智能体，再把任务加入 Lists。Lists 有点像法律团队用的 Linear。请求会进入特定的 Intake 清单，律师和智能体可以在 Legora 里处理，合作完成后标记结束，结果再发回 Slack。

不难。我们有些很实用的基础构件。Lists 是个很灵活的构件，有点像 Notion 数据库，可以按需要配置。我们让它能扩展，也支持触发器和自动化，用它把各部分连起来。清单里发生某件事时，可以启动智能体；智能体完成后再回填字段、添加文件等。

有些人会特别沉迷，甚至成了这类自动化的影响者。灵活性还是很重要，即使我们不把所有功能都直接开放给终端用户。

即使只供内部使用，这些基础构件也能让我们的法律工程师很快做出产品。比如用 Lists 加上生成式界面，就能做定制的基金管理仪表板；也可以建立专门产品的市场。法律工程师在客户现场听到需求，可以很快给客户做一个。某种程度上，就像在 Legora 里放了个 Lovable。即使不把功能开放给用户，我们也能借此打造自己的定制功能。

可配置的 Lists、存放文件的 Projects，以及能用不同配置启动的智能体。

目前没有。以前有人把它叫作 Layer，但我们后来不用了，也许会再捡起来，可能会有点混淆。Lists、智能体、Tabular View 大概是最主要的几个构件。

大约九个月前，我们招了第一位前线部署工程师，也是我们在纽约的第一位员工；她还是一位 YC 创业者。我们一直在想，怎样才能规模化地支持这项工作。关键是让法律工程师和高级用户能强力定制产品。同时，前线部署工程师会负责定制集成、评估需求、判断可行性，并把反馈带回核心产品团队。

每家客户都不一样。大型客户通常很投入，有许多设想，或者已经试过自己开发但失败了，想解决某个具体问题。我们会安排法律工程师，必要时再配前线部署工程师。他们会和客户的律师一起工作，教大家使用产品，梳理现有流程，并把流程配置进 Legora。有些事情法律工程师就能完成，有些则需要前线部署工程师。

法律工程师像高级用户一样配置产品，不写代码；前线部署工程师则会把代码写进生产系统。

创业者、普通工程师都有。我们的第一位是 YC 创业者，之前在 Meta 做搜索。她是美国团队第一个真正落地的人。

差别很大。一些常见流程可以直接在 Legora 里配置，例如处理某类 NDA，这更像是构建技能。若现有构件不够灵活，或者客户有复杂系统需要集成，前线部署工程师就会用我们的 API 做集成，必要时也扩展 API。

他们不会接触客户数据，只负责搭建系统。有时客户会像给员工一样为他们办入职、提供笔记本电脑，但大多时候只是开发集成。要不要给客户安排前线部署工程师，取决于客户规模和项目是否值得；他们也可能回去做核心产品，所以这是持续的优先级取舍。

目前还没有，说实话这块还在早期阶段。

我觉得会有更大规模、持续轮转的前线部署团队，不一定完全照搬 Palantir。团队可能在一家客户那里待两个月，做出一个项目，再转去下一家。我能想象法律工程师和前线部署工程师一起进场，专门负责具体项目。

目前不会承诺。我们有一些 API，客户可以基于它们开发，但并没有覆盖整个产品。

对，这就是我们一直不太愿意做 API 的原因。大约六个月前我们才开始做，之前抗拒了很久。产品迭代太快，我不想因为必须维护旧版 API、适配已经变化的数据模型而拖慢速度。现在公司规模大了，这个成本可以承担；只有二十名工程师时，我们动得太快，做不了这件事。

没错。甚至可以把智能体也这样看：有一个团队负责智能体运行框架，然后再在它上面围绕技能和自动化做产品。

API 的概念可能也在变化。我们正在想：智能体能不能成为 API？听起来有点奇怪，但有些时候客户只想触发某件事。也许他们可以直接启动智能体，让它完成任务。当然，这肯定比直接调用专用 API 效率低得多，但我一直在琢磨，我们的产品有多少可以由智能体承担，多少需要其他东西。

对，还有可预测性：也许一百次里有两次会做出我们不想要的事。

很长一段时间里，我都坚决主张前者：什么都拒绝，工程团队保持精简。我在 Legora 半年后做过一张“300 斯巴达人”的电影幻灯片，说我们公司往后永远只要 20 个工程师，就能打赢那些大得多的对手。现在我们已经有 100 名工程师，却还是觉得人手远远不够。

对，我觉得这样很有力量。

我们确实做过一些战略押注，但没怎么尝试自己都没把握的东西，因为手头已经有一大堆客户需求。我们主要去做客户反复要求的功能。有时我们也会和客户意见不同，觉得某件事对公司战略更重要，还是会去做。

智能体就是一个。以前没人说“我希望助手能更自主，不用我开口就帮我行动”，但我们认为行业会走向那里，它能让用户完成很多很酷的事。协作也是如此：我们相信法律行业应该在工作平台 Legora 里协作，而不是靠邮件和短信。

主要是法律工程师，有人也会叫他们“前线部署法律工程师”。他们会帮助律所围绕智能体能力重新组织工作流。

到现在为止我们都没有微调过模型。不过最近几个月开放权重模型变得很强，我们会考虑在某些任务上做后训练，尤其是前沿模型与后训练模型之间，在成本和延迟上差距很大的任务。法律研究就是好例子：它是并行展开的检索问题，可以训练一个很有效的模型，用很低延迟和成本快速处理这些查询。

正是如此。我们不是要训练自己的 Fable，打造主智能体。我们大概率赢不了 Anthropic 这样的公司。不过搜索、检索和 RAG 还有很多研究空间。

目前没有。不过你说得完全对。团队里有个人特别关注搜索，经常来找我说应该试试新嵌入模型和后期交互。他还联系 Turbo 团队，推动他们构建多向量支持，好让我们试这些方法。

文件编辑方式很重要，分析方式很重要，法律研究的能力也得融进去。出现问题时，智能体要知道如何做法律研究、找到答案和先例，当然还要有相应的治理机制。

对，搜索和分析都重要。起草合同也并不简单。比如从头起草一份大型合同，得先找过去的先例，判断需要哪些条款，以及这家律所以前是怎么处理的。律师不会直接坐下来敲字，他们先找类似交易里用过的条款。“类似”可能指同一行业、同类公司，或其他相似条件。然后还要从多份文件里挑出该采用哪些部分。这其实就是一个搜索问题。

我昨天刚提过，Fable 和 Opus 确实特别爱说，输出很冗长。

对，Astra 写得更简洁。我们当然会对不同任务做测试，但模型太啰嗦这个问题不太好解决。Anthropic 下一代模型可能会好很多。Astra 其实很精炼。

他们知道这些。另一个我很在意的问题是幻觉。

我们有一套引用系统，会检查它写的内容能否链接到来源。用户可以点击链接，PDF 里会用边框框出信息来源。我们希望所有内容都有出处，即使信息经过了好几层处理也一样。比如智能体根据 Tabular Review 写内容时，可以引用表格里的某个单元格或某一行。用户可以一层层点进去，验证内容。

一开始他们会查，但后来就不怎么查了。

对，这种事确实会发生。我觉得这和编程一样：有些工程师不怎么看代码，就把智能体的结果直接交出去；也有人会把每个逗号都看一遍。

但他们大概知道该检查什么，就像代码审查一样。他们会找到重要问题和红旗，把关键处再核对一遍。如果其他内容听起来合理，可能就会接受。

现在我想不到特别具体的事。长文档推理仍然很难。

对。一份很长的合同要在全文不同位置修改，模型得记住前面改了什么、定义和顺序怎么变了，这很难。最简单的做法是一次把所有内容放进去，一次生成结果，但我们不会那样做，而是把文档分块，再编排修改。

但两种做法各有不同。比如在大型合同里搜索，MapReduce 可能会在分块总结时丢掉重要细节。某些内容要跨几页一起看，每一块单独看都和搜索目标不相关，合起来却非常重要。所以我们会做不同类型的搜索，有些还需要在不同步骤之间进行推理。

客户可以给我们反馈。如果某件事对他们特别重要、效果却不好，我们可以请他们把相关文件和提示词匿名化。如果我们能复现问题，就能修复。

确实有人在考虑。不过有个问题：律所的数据到底属于律所，还是属于客户？如果客户都走了，也许就可以，但我也不确定。收购律所确实能得到很多数据，像 Google 收购机器人公司一样。

收购律所数据的优点是能拿到真实输入，但输出端比较困难：你只知道最后结果是什么，却得反向推断它是怎么做出来的。在我们的产品里，拿到真实用户的完整轨迹非常有价值；如果只看到输出，不知道它好不好、是怎么生成的，就很难判断。

所以不要直接用默认嵌入，包括开源模型或 Gemini 的嵌入都一样，应该按需求定制。

我觉得可以，不过要考虑多语言。我们的服务要覆盖很多语言。

欧洲在多语言方面最有经验。

是的，这方面很有帮助。

欧洲需要更多模型公司。

我觉得两种都会有，具体看客户。大型企业可能在 Claude Cowork 里工作，同时也会用 Legora，就像我通过 Claude 使用 Linear，但仍会直接打开 Linear。律所可能会直接用 Legora，因为更简单、效果也更好。

对。

我觉得不会，因为它们自己也在推出法律服务。

我不太担心。企业知识工作涵盖很多方面，法律必须包含在内，就像数据分析、销售、市场和财务一样。它们会做法律产品，但永远不会像我们这样深入。如果 Claude 服务小型企业、承接一些法律工作，那很好，也没关系。但要做一笔 4 亿美元的并购交易，你会想用 Legora。

这确实是我们正在推进的项目。我不清楚现在具体进展到哪一步，但我们希望法学院学生学会使用 Legora。

这方面我不太了解。

工程师目前在纽约、斯德哥尔摩和伦敦招聘，其他岗位则全球都在招。

一百人。

越多越好。

谢谢。