--- id: "bJBEFzlKPoQ" title: "看不到数据时如何打造法律智能体——Legora 首席技术官 Jacob Lauritzen" channel: "Latent Space" host: ["Basil Chatha","swyx"] guests: ["Jacob Lauritzen"] date: "2026-11-02" updated: "2026-11-03" duration: "1:07:22" duration_seconds: 4042 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=bJBEFzlKPoQ" canonical: "https://pod-exp.pages.dev/bJBEFzlKPoQ/" transcript_jsonl: "https://pod-exp.pages.dev/bJBEFzlKPoQ/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["AI 智能体","企业软件","模型评测"] series: ["AI 与软件"] --- # 看不到数据时如何打造法律智能体——Legora 首席技术官 Jacob Lauritzen > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** Legora 从一个接入瑞典法律搜索的 ChatGPT 起步，逐步发展为能研究法律、起草与审阅文件、批量分析合同并协调工作流程的法律智能体。Jacob Lauritzen 介绍了模型路由、模拟客户工作环境做评测、在无法查看机密轨迹时用合成数据定位失败类型，以及 Tabular Review、Intake、Lists 和前线部署工程师如何协同。他还谈到法律服务的计费模式、律所合伙人制、初级法律工作的变化、数据隐私和 Azure、开放权重模型、搜索与长合同推理，以及如何让律所把专业判断沉淀为长期资产。 ## [0:01] 冷开场 · YouTube **Jacob Lauritzen：** 大家都在问我们 Mythos 之类的东西。但说实话，很多法律工作确实用不着 Mythos 级别的智能。 **Jacob Lauritzen：** “律师助理都没了，初级律师也没了，我不需要他们了。”但我们实际看到的并不是这样。 **Jacob Lauritzen：** 我们碰到过一个问题，模型引用判例不太对。后来下一版模型一发布就解决了，准确率从 70% 涨到 99%。我们什么都没改，效果就上去了。 **Jacob Lauritzen：** 不过，如果你要做一笔 4 亿美元的并购交易，你肯定会想用 Legora。 **Jacob Lauritzen：** 我们当初还说，公司以后永远只要 20 个工程师，就能打赢那些规模大得多的对手。现在我们已经有 100 个工程师了，还是觉得人手远远不够。 **Jacob Lauritzen：** 我最近也在琢磨，我们的产品有多少可以直接由智能体来完成，多少还需要其他东西。 ## [0:41] 认识 Legora 首席技术官 Jacob Lauritzen · YouTube **Basil Chatha：** 好，我们现在在录音室，欢迎特别嘉宾、Legora 的首席技术官 Jacob Lauritzen。我念对了吗？Lauritzen？ **Jacob Lauritzen：** 没问题，这样就行。我知道这个姓是丹麦来的。 **Basil Chatha：** 这个姓有什么特别的来历吗？ **Jacob Lauritzen：** “sen”就像“某某之子”，比如你会看到一些姓氏里带着这个后缀，所以我的名字大概就是“Lord 的儿子”。 **Basil Chatha：** 挺有意思。我们之前也碰过几次面，你还讲过几次。显然，Legora 是法律科技史上成长最快的公司之一。 ## [1:05] 从斯德哥尔摩地下室里的挑战者起步 · YouTube **Basil Chatha：** 你刚才在节目开始前提到，你们的根基很欧洲化，虽然现在显然正在纽约和旧金山扩张。你觉得这种文化有什么不同？ **Jacob Lauritzen：** 我觉得我们骨子里一直挺谦逊，因为从一开始我们就是挑战者。最初的时候，没人相信一家在斯德哥尔摩地下室里的小创业公司，能和美国那些遥遥领先的巨头竞争。 所以我们一直把自己当成挑战者，也一直很谦逊。我们得不断争取活下去。我觉得随着我们进入美国、在美国投入越来越多，我们也学着变得更大胆一些，主动告诉全世界我们有多厉害。这对我们当中的一些人来说，其实不是自然而然就会做的事。 **Basil Chatha：** 我想先从你们的产品聊起…… ## [1:56] Legora 如何从瑞典法律版 ChatGPT 发展成法律智能体 · YouTube **Basil Chatha：** 我想聊聊你们的产品。很多法律产品似乎都藏得很深，不太方便展示。你能说说产品现在是什么样、你们是怎么走到这一步的吗？一路上经历过哪些产品迭代？ **Jacob Lauritzen：** 当然。一切最初就是一个接入了瑞典法律和搜索工具的 ChatGPT，这几乎就是全部。 我们从法律研究起步。这是个很大的市场：律师会花很多时间找类似的先例、研究法律依据，看看以前遇到这种情况的人是怎么处理的。这非常重要，所以法律研究一直是我们产品的一部分。最初它就是个能回答问题、查询法律条文的智能体，产品非常简单。 后来它能做的事越来越多。现在它可以起草很多内容、编辑 Word 文件、整理文件，还能做很复杂的分析。我们也添了不少功能。其中一个叫 Tabular Review，这个名字现在已经被行业沿用了。我们很高兴看到 Harvey Legal 也在用我们的术语。 **主持人：** 这个一定得聊聊。 **Jacob Lauritzen：** Tabular Review 能批量提取和审阅大量协议，常用于尽职调查、融资等场景。它帮助律师把工作做得更高效、更好。 除了直接帮律师做事，我们现在也比一年前更深入地协调整个工作流程。我们有一个叫 Lists 的功能，有点像我们自己的 Linear；还有 Intake，帮助律师和客户协作；以及 Portal，用于律师与律师、客户与律师、律师与智能体，甚至智能体与智能体之间协作。 我们在这方面投入很多，因为坦白说，十年前、甚至今天，人们和律师打交道的方式都很折腾，改进空间很大。所以我觉得重点有两个：帮他们做事，也帮他们协调工作。 ## [4:12] 从助手转向智能体 · YouTube **Basil Chatha：** 你们什么时候开始做智能体的？ **Jacob Lauritzen：** 我们基本上经历了从助手到智能体的转变，大概是一年前吧。 **Basil Chatha：** 给大家个时间概念：你们是 YC 2023 的？ **Jacob Lauritzen：** YC 2024。 **Basil Chatha：** 对，我是 YC 2023 的，Legora 是 2024。那时智能体还没真正兴起，后来推理模型又彻底改变了局面。我们刚才看了产品的预览，之后会把视频放到 YouTube 上。它看起来基本就是法律版 ChatGPT，侧边栏还有 Tabular Review、Intake 等定制工具。 **Jacob Lauritzen：** 没错，就是法律工作特别好用的 ChatGPT 同事。它能支持企业内部律师的流程，比如跟进即将出台的法规。后面我们还可以多聊聊产品。 ## [5:23] Legora 使用哪些模型，以及为何加入模型选择器 · YouTube **Basil Chatha：** 你们底层用了哪些模型？能聊聊吗？ **Jacob Lauritzen：** 我们会根据任务使用不同模型。 **Basil Chatha：** 律师看不到具体用的是哪个模型，对吧？ **Jacob Lauritzen：** 这个问题我们反复讨论过。和其他团队一样，智能体里可以选主模型，但某些工具会用不同的模型，比如 Tabular Review。我们发现，把问题拆成小任务，再按任务路由模型，效果最好。不过目前智能体里确实有模型选择器。我不确定以后会不会一直保留。 **swyx：** 我补充一点背景：我是 Cognition 的顾问。我加入时对智能体实验室的设想之一，是它应该像一个垂直领域的 GPT 包装层。我们懂这个行业，会更关注用户需求，也能按照自己的判断提供最好的前沿模型。我们的职责是替用户做选择，毕竟律师的工作不是研究模型。 **Jacob Lauritzen：** 没错。我们会让你始终用上最先进的模型，确保体验一直很好，你不必钻研所有细节。 **swyx：** 你不会让律师自己选模型：你要基于某个判例起草合同，还得问他想用 Sonnet、High 还是 Opus？他们不会知道，只会说“给我做好就行”。 **主持人：** 只要能用就行，毕竟他们每小时收费 1,000 美元。 **swyx：** 正是如此。我一开始就是这么想的：这正是 Devon 的不同之处。可现在模型选择器里有五种模型，包括 Fable、Opus 和 Astra，大家想试试最新、最厉害的模型。 **主持人：** 法律行业也跟工程行业一样吗？ **swyx：** 我觉得是，但法律行业的比例肯定低得多。还是有人一上来就想要最强的模型，之前大家也一直问我们 Mythos 之类的模型。 **Jacob Lauritzen：** 不过说实话，大多数法律工作并不需要 Mythos 级别的智能。 **swyx：** 对。我们可以把选择权给用户，但他们用这种模型会快十倍地烧掉额度。 **Jacob Lauritzen：** 我们很长时间都不愿意加这个功能，最后还是让步了：如果你想要这种控制权，那就给你。 ## [7:48] 现在的模型已经满足律师需求了吗？ · YouTube **Basil Chatha：** 你觉得现在的模型已经够好，律师不需要它们再进步了吗？ **Jacob Lauritzen：** 要看工作类型。可能有 60% 的工作，我们现在就能做得很好。接下来主要是成本和延迟问题。但剩下的工作，特别是非常复杂的分析，仍需要更强的智能。模型能力越强，可能也会让工作范围扩大。 ## [8:20] 九个月前智能体还做不到什么 · YouTube **Basil Chatha：** 想想你们刚开始转向智能体的时候，那时用的是什么模型？Opus 4.6？ **Jacob Lauritzen：** 应该是 Sonnet 4.6，Opus 4.6 也差不多那个时候。 **Basil Chatha：** 那时智能体有哪些做不好的事，九个月后已经进步很大？ **Jacob Lauritzen：** 子智能体委派就是一项。现在我们已经能很好地用它来并行展开检索查询，以前这很难。 我们有专门做评测的团队，会追踪各个模型在不同法律业务领域和任务上的表现，整理成一张大热力图。模型通常会有整体进步，但也有不少版本是有些方面改善、另一些方面退步。这种情况比你想的常见得多。 ## [9:18] 在模拟环境和一万份文件的数据室里测试智能体 · YouTube **Basil Chatha：** 能举些任务的例子吗？你们评测时会看哪些细分领域？ **Jacob Lauritzen：** 我们会搭建不同的“世界”，本质上像强化学习环境。律师的工作通常都围绕具体项目展开。比如，给智能体一个有一万份文件的数据室，让它做尽职调查，最后生成一份报告。报告需要包含所有红旗问题，不要塞进无关内容，而且要简洁。 我们会把任务拆开评估：报告草稿写得好不好、该包含的信息有没有覆盖、措辞和分析是否可靠；还会单独评估前一步的红旗识别。大致就是这样拆分并运行评测。 ## [10:07] 评测团队与 Legora 的 100 名法律工程师 · YouTube **Basil Chatha：** 你们的评测团队是什么构成？会请律师参与吗？ **Jacob Lauritzen：** 会，是工程师和律师混编的团队，目前大概三名工程师、三名律师。我们还有一批叫“法律工程师”的人，通常在大型律所工作过三四年，有些也有计算机科学学位，技术背景很强。他们加入我们，是想推动这个行业改变。 **Basil Chatha：** 所以他们是在大型律所执业的律师？ **Jacob Lauritzen：** 对，是大型律所的律师。 **Basil Chatha：** 而且有计算机科学学位？ **Jacob Lauritzen：** 是。 **主持人：** 天哪，这两个领域的交集太难找了。 **Jacob Lauritzen：** 这种人才确实最难招，但他们也能带来巨大的倍增效果。我们可以请他们参与评测和产品开发。公司有一百位专家每天都在用产品、每天都和客户交流，他们亲身经历过这些工作。我们能借助他们做评测、打磨产品，这是很大的优势。 ## [11:03] 评测曾经看起来不划算，而一次模型更新把引用准确率从 70% 提升到 99% · YouTube **Basil Chatha：** 你们什么时候开始组建评测团队的？ **Jacob Lauritzen：** 评测团队是从助手和智能体团队里逐渐发展出来的。直到不久之前，我们一度觉得做复杂评测不太值得，因为所有模型都在变好。与其花很多时间做评测，不如先把智能体框架做好，借助模型整体进步带来的提升；当时模型确实一直在进步。 **主持人：** 对，差不多每两三个月就会有进展，直接接入新模型就行。 **Jacob Lauritzen：** 没错。我们遇到过一个引用不准确、很难追踪的问题，下一版模型就解决了，准确率从 70% 涨到 99%。我们什么都没改，效果就好了。 **swyx：** 所以真正重要的工作也许是把数据保护好、做好标签和分类，再加上 Tabular Review 这样的新功能？ **Basil Chatha：** 你是说这些之外？现在你们也在做评测了，我猜开源模型的使用也在增加。我们可以聊聊。总之，我想问的是，这份工作的核心究竟是什么？ **Jacob Lauritzen：** 早期评测可能没那么重要，因为当时主要是把模型能力开放给律师使用。 ## [12:18] 五到十年后，法律工作会变成什么样 · YouTube **Jacob Lauritzen：** 很大一部分工作，是想清楚五年、十年后法律行业会是什么样。编程领域可能领先一两年，我们可以从那里找些参考，但我们还得弄清楚基本工作单元是什么、人们会如何协作。未来协作会是什么样？难道还要靠两百封邮件来回传 v5 版 Word 文件吗？ 这不完全是 AI 的问题，也是在做更好的产品体验。当然，在受监管行业里，审计日志、数据留存等重要事项也必须处理好。AI 则能让工作更快、更好，让智能体主动响应新进来的事务，而不是每件事都等人手动启动。 所以，我们要想象五年后会是什么样：如果模型能力继续提高、价格继续下降，律师登录系统后看到的会不会像一个指挥中心，告诉他们最近智能体做了哪五件事，需要他们审核、检查，并据此改进系统？我们可能正朝这个方向走。 **Basil Chatha：** 你能展开讲讲吗？几年后法律行业会变成什么样？ **Jacob Lauritzen：** 先说我也不知道，谁能说得准呢？不过我觉得可以多看看编程行业。律师的效率会大幅提高，能以更低成本做更多、更高质量的工作，整个法律行业和工作本身都会变好。 律师会把更多时间花在他们当初选择这个职业真正想做的事上：判断风险水平、哪些风险可以接受、运用战略判断，以及和客户合作。他们就不用再花那么多时间翻厚厚的文件找关键证据，或者做那些枯燥又恼人的琐碎工作了。 ## [14:18] 律所合伙人制度会存续下去吗？ · YouTube **Basil Chatha：** 你觉得律所的合伙人制度会怎么变化？它会继续存在吗？ **Jacob Lauritzen：** 我上周刚认真想过这个问题。合伙制的出现，部分是因为律所拥有的资本只有人力资本。制造业或软件公司会积累实物资产或无形资产，再给股东带来收益；专业服务公司和咨询公司则主要靠人才创造价值。人不能被拥有——奴隶制已经废除了——但可以雇用。合伙制本质上是让人力资本的所有者成为公司的所有者，这样他们才会留下来。 这会改变吗？不一定。但我们希望律所能建立某种无形且持久的资本，比如能逐渐了解律所工作方式的系统。律所有自己的办事方法，可以把它编码下来，建立持续改进的知识图谱，积累判例和文件，让一套工作方式持续产出高质量结果。这些都可以成为律所的知识产权，把人的专业经验和判断沉淀进系统里。这是我们希望帮助实现的事。 **Basil Chatha：** 这会影响合伙制吗？合伙人的激励机制是拉来更多客户，他们不希望花时间把知识沉淀下来。 **swyx：** 对，现在合伙人可能按“多劳多得”或锁步制获得回报。我们需要设计新的激励方式，让合伙人愿意把知识编码下来，为律所建立资产。现在他们没有动力这样做，因为一旦离开合伙关系，就无法再从自己建立的资产中获得分红。 **Jacob Lauritzen：** 整套商业模式都值得重新审视，之后再看吧。 **Basil Chatha：** 是啊，现在一切都还在变化。 ## [16:40] 律师助理和初级律师会怎样？ · YouTube **swyx：** 合伙人制度说的是行业顶端。我更关心底层会怎样：律师助理会消失吗？ **Jacob Lauritzen：** 初级律师也会消失，我们不需要他们了。 **Basil Chatha：** 但这不是我们实际看到的情况。你觉得工程行业会这样吗？ **swyx：** 初级工程师现在处境挺危险的。你可能得从大学退学，而且已经什么都会了，不然就没戏了（笑）。我为了搞笑说得有点夸张，但我认识很多律师，他们从律师助理做起，再去读法学院。现在那些工作可能真的不再需要人了。 **Jacob Lauritzen：** 律所的金字塔结构会怎样？我觉得仍然需要培养下一代。至少在工程领域，我的看法是，优秀工程师今天比两年前更值钱，因为他们能产出更多。如果能力够强，就能做很多好工作。法律行业也一样：优秀的律师，甚至优秀的初级律师，会更有价值。 **swyx：** 这一直都成立吧？但现在价值分化会更明显。 ## [18:00] 按小时计费，以及法律科技过去为何没做起来 · YouTube **Basil Chatha：** 律所基本按小时收费。如果现在每个项目都能快很多，是不是也会便宜很多？ **Jacob Lauritzen：** 说个有趣的事：我当时读 Max 的 YC 申请，帮他把当时还叫 Leia 的公司申请进 YC。我当时就想，大家已经试过无数次法律科技了，为什么这次会成功？律师为什么要提高效率，赚得反而更少？这在经济上说不通。 **swyx：** Leia 是丹麦语里的什么词吗？ **Jacob Lauritzen：** 不是，是瑞典语……不，其实也没有特别含义。早期有家西班牙报纸写我们，还把 Leia 解释成“Legal Efficient Yoda Assistant”（高效法律尤达助手），我也不知道为什么是尤达。我觉得记者也会“幻觉”。 我给 Max 的反馈是：法律科技试过很多次，但一直没做成，因为律师没有动力变得更有效率，效率高了收入就少。不过律师现在愿意采用这些工具，是因为他们意识到情况很严峻，商业模式正承受压力，竞争也迫使他们改变。收费方式本身也会变化。尤其在美国，很多工作开始按项目收费，而不是按小时收费。低端的一些小型审查，有些甚至免费做，有些则收固定费用。 ## [19:39] 现在的钱会从哪里赚？ · YouTube **Basil Chatha：** 那钱会从哪里赚？是不是战略性工作？ **主持人：** 你们常说并购是价值所在。 **Jacob Lauritzen：** 这是个很容易理解的例子。诉讼也仍然是很重要、很有价值的工作，律师会把更多时间投入那里。 **swyx：** 客户关系也很重要。 **Jacob Lauritzen：** 不是说要做 CRM，而是要花更多时间陪客户。过去很多律所会免费做些事，只为维系客户关系。现在他们也能这么做，不必因此亏很多钱。 **Basil Chatha：** 我以为我得付钱给律师，才能让他当我的朋友——这就是聘用费的作用吗？ **Jacob Lauritzen：** 找对律师就行。（笑） **swyx：** 或者 Latent Space 得做得更大。（笑） **Basil Chatha：** 你是说战略性、高附加值工作仍然有市场。但你也说律师助理不会消失，而是转去做别的。工程行业也有人担心“初级工程师会被取代”，没人喜欢这么说，但确实会发生一部分；另一些初级工程师拥抱工具后，生产力提高了。客户有没有给这种新岗位起什么名字？ **Jacob Lauritzen：** 你是说“超级 AI 初级法律人才”吗？我还没听到合适的叫法，也许我们该造一个。 **swyx：** 法律工程师？ **Jacob Lauritzen：** 对，这已经成了行业里的说法。 **swyx：** 也许兼有计算机科学和法律学位的人最适合做这类工作。有人用贬义词“肉身代理”，形容一个人坐在机器前，照别人说的输入，再把机器的回答转述出去。但如果你很懂智能体，也很懂 Legora，知道行业工具箱里有什么，并且能用这些工具解决别人需要的问题，那就不只是代理，而是在做有意义的工作。 **Basil Chatha：** Tabular Review 就是个例子。一个案件可能有成百上千，甚至上百万份文件。 **Jacob Lauritzen：** 我们能处理多达一百万个单元格。 **swyx：** 太厉害了。比如一个大案子有一百万份文件，通常会让一队律师助理一直干到凌晨四点；其实现在没必要，他们可以批量提取信息、反复调整提示。那种整理工作不需要律师助理了，但厉害的“超级 AI 律师助理”可以转去做别的事。 **Jacob Lauritzen：** 正是如此，他们能做更多事情，或把更多时间花在以前顾不上的工作上。 **Basil Chatha：** 也可以好好睡一觉。谁知道呢？ ## [22:44] Legora 如何用自家产品做并购尽调 · YouTube **Basil Chatha：** 我想问问，你们收购了 Kura？你们还用自家产品做并购尽调？ **Jacob Lauritzen：** 对，我们一直这么做。 **Basil Chatha：** 内部试用的效果怎么样？ **Jacob Lauritzen：** 很好。我们的 Intake 功能就是和内部法务团队一起做出来的。大家以前把各种请求都扔进 Slack 工作流里，觉得很麻烦，我们就想把这个流程改好。 我们自己做了很多尽调，用 Tabular Review 等工具处理，也会请外部律师评估某些风险。比如工资税务问题，Kura 的情况比较简单，因为都在瑞典；我们也在加拿大和澳大利亚做过收购，那边的工资税务就会需要更专业的意见。战略层面我们仍会请律所一起讨论，帮助我们设计合适的交易结构；但许多琐碎工作我们能自己完成。我们也曾在尽调中发现红旗，然后叫停交易。 **Basil Chatha：** 能具体说说是什么问题吗？ **Jacob Lauritzen：** 这个我就不方便说了。（笑） ## [23:59] 瑞典与美国律所有何不同 · YouTube **Basil Chatha：** 你们早期客户是瑞典律所。和瑞典、美国律所合作，有什么差别？你们主要服务大型律所吗？ **Jacob Lauritzen：** 我们也和小律所合作。起步时客户确实都是很大的律所，但只有 50 名律师的律所也在用我们，觉得很有价值。 **Basil Chatha：** 瑞典和美国的客户有什么不同？甚至亚洲客户呢？ **Jacob Lauritzen：** 欧洲律所的行动速度稍慢。美国律所更积极，推进很快，也把这件事放在战略议程的前列。美国企业和律所都更愿意定制开发。他们会说：“我们想和你们一起打造一个大系统。”欧洲客户则更倾向于直接使用现成产品。 **Basil Chatha：** 他们想自己开发什么？ **Jacob Lauritzen：** 有些客户会自建 CRM、文档管理系统，还想做各种流程触发器。比如在 Salesforce 里做完审查后，任务先分给某个人处理，再流入 Legora，完成后回到原系统。这是比较简单的例子。也有更雄心勃勃的客户想和我们一起做一个全新产品——这我们还真做不了。（笑） 我们和欧洲客户的合作也很好，他们会告诉我们哪些功能好用、哪些不好用、还想要什么，我们再据此做产品。 **主持人：** 所以他们不会觉得这是生存威胁，而美国客户会？ **Jacob Lauritzen：** 我不确定这是不是他们愿意定制开发的原因。我觉得双方都知道这对律所和企业的成功极其重要，只是实现方式不同。 ## [26:12] 看不到使用轨迹时，怎么衡量产品效果 · YouTube **Basil Chatha：** 你们怎么判断产品是不是做得好？这也和评测有关吧？ **Jacob Lauritzen：** 我们会看常规产品指标：用户是否常用、是否觉得有价值、是否续约、会不会经常回来。对于企业软件来说，我们的 DAU/MAU 和用户每月在产品里花的时间都非常高。 我们也做线上评测，用很便宜的小模型大致判断任务有没有解决。推出新功能时，可以用功能开关做对比，看看指标有没有改善，或者是不是出现灾难性下滑。 我们业务里很难的一点是，基本上不能查看任何使用轨迹或数据，因为内容高度机密。这很让人沮丧：产品能做很多事，我们却不知道用户实际在做什么。 **Basil Chatha：** 我原以为你们能和律所签协议，让他们开放这些数据。 **Jacob Lauritzen：** 我也希望如此。但很多数据甚至不属于律所，而是属于他们的客户，保密级别很高，我们没法查看。所以评测团队只能尽量推测大家会做什么，再把这些场景建进评测集里。 ## [27:41] 把使用轨迹改写成合成数据，并归纳失败类型 · YouTube **swyx：** 你们能不能把真实使用轨迹改写成合成内容？比如 ChatGPT 有反馈功能，能提供完整过程；你们不能这样做，但能不能让模型把真实案例改写一下，换掉姓名和细节？ **Jacob Lauritzen：** 这件事有个尺度问题。如果把内容彻底抽象成几个选项，再挑一个，通常没问题；但如果只是删掉姓名，未必就够安全。我们尽量采用最谨慎的方式，把风险压到最低。另一方面，我们也知道常见失败模式大概就十到二十种，可以把问题分到某一类，这会提供有用信号。我们还可以按任务类型和法律业务领域分类。目前我们一直在想办法更聪明地处理这些问题。 ## [28:42] 出于数据隐私，Legora 把基础设施都放在 Azure · YouTube **Basil Chatha：** 隐私方面，几年前让律所接受把数据发给 Anthropic 肯定很困难吧？ **Jacob Lauritzen：** 我们的基础设施都在 Azure 上，主要就是因为这个。刚开始时律所会说：“AWS？不行，绝对不行。”他们不信任 AWS，也不想把数据交给 Amazon 或 Google。所以我们必须托管在微软，因为他们已经在用 Microsoft 365。 **Basil Chatha：** 所以他们信任微软？ **Jacob Lauritzen：** 对，他们已经审核过微软的安全性、文件和 Word 等服务，在他们看来微软是获批供应商，所以我们得用 Azure。过去两年情况变了很多，大家开始接受上云，也逐渐不再要求本地部署。人们认识到云端是安全的，甚至可能比自己现在的做法更安全。 变化确实很大，不过这才三年而已。法律行业过去十年都没怎么动，可能需要 AI 来推一把，让大家意识到该改变了。 ## [30:04] 开放权重模型与模型套利 · YouTube **Basil Chatha：** 开源模型现在越来越强，你们怎么看？ **swyx：** 我们想做的是带客户跟上模型前沿，持续了解各个模型擅长什么，以及它们的延迟、成本、治理要求和地区可用性，再综合优化。有些任务适合开放权重模型，就用它们；有些可以做后训练，有些则继续用前沿模型。 **主持人：** 这就是所谓的“模型套利”。你年初明显更偏 Anthropic，现在 Grok 进步也很大。有没有整体排名不算高、但某方面出乎意料好用的模型？ ## [30:55] 转录模型，以及 Legora 为什么不用 ElevenLabs · YouTube **Jacob Lauritzen：** Gemini 早期有个版本，在某些类型的转录上特别好，比如转录和说话人识别，我们用它来做转录。 **Basil Chatha：** 所以你们有类似 Granola 的会议转录？ **Jacob Lauritzen：** 我们还没有，不过可能会做会议产品。目前只是应用里的语音转文字、文字转语音功能。用户也能上传庭审等文件，我们会转成文本，再做分析。 **swyx：** 不用 ElevenLabs？ **Jacob Lauritzen：** 因为数据处理协议（DPA）的原因，我们协议里能列的供应商很少，必须严格控制数据会流向哪里。Gemini、OpenAI 这种服务的优势之一，是用户可以找一家供应商满足大多数需求；即使模型不是最先进，只要多数任务够用，就很有价值。 **主持人：** 微软也有自己的转录模型。 **Jacob Lauritzen：** 对，微软的模型表现不错。通常它们在排行榜上都排前二、前三或前四，足够好了。再加上治理能力和可扩展性，也就够用了。 **Basil Chatha：** 现在语音转文字模型是不是已经够好，偶尔错一两个词也没关系？ **Jacob Lauritzen：** 我做过不少这方面的事。法律领域会碰到特殊问题：有个法庭人员的称呼，具体在澳大利亚还是别处我忘了，模型总把它识别成“避孕套”。有些词确实不该出这种错。 **swyx：** 所以通常要再叠一层语言模型，从上下文提取关键词，然后把关键词交给转录模型再跑一遍。这是我目前的流程。但只要规模够大，在日常对话以外的领域都会碰到大量转录错误。 **Jacob Lauritzen：** 有行话就更难。 **swyx：** Whisper 和 ElevenLabs 现在还会把 “Claude Code” 转成 “cloud code”。这很常见，也说明还有不少改进空间。 ## [33:33] 智能体、Tabular Review、项目空间与 Word 插件 · YouTube **Basil Chatha：** 我们再聊聊智能体产品。刚才提到 Tabular Review、Intake，还有其他功能。先说最重要的两个：智能体和 Tabular Review？ **Jacob Lauritzen：** 对，还有 Word 插件也很重要，因为很多人就在 Word 里工作。Outlook 插件也一样。 **swyx：** Tabular Review 本质上是把很多文档并行处理，对所有文档问同一个问题，把结果收集到表格里，再来回审阅。 **Basil Chatha：** 能处理一百万份真厉害。工程上有什么难点或性能问题？ ## [34:24] 律师如何使用 Tabular Review · YouTube **Basil Chatha：** 先讲讲律师使用 Tabular Review 的体验和流程吧。 **Jacob Lauritzen：** 一个典型场景是尽职调查：需要审阅所有劳动合同、供应合同等等。比如放进一万份劳动合同，每一行代表一份合同，每一列对应一个问题。第一列可能问合同的解约通知期，系统会把每份合同的答案填进去，比如 30 天。下一列可以问有没有知识产权转让条款，再下一列问解雇时要付多少补偿、薪酬是多少，整个表格都会填好。 用户也可以把一万份文件交给智能体，要求做尽调。智能体会自动启动 Tabular Review，跑完后分析结果并标出红旗，比如 CEO 薪酬高得离谱，或奖金结构有问题。律师就可以重点查看这些问题。智能体还能据此起草发给客户的备忘录；或者律师自己审阅结果、查看红旗，并和同事协作评论。 ## [35:51] 为什么用表格，以及前十行能告诉你什么 · YouTube **Basil Chatha：** 为什么选择电子表格的形式？ **Jacob Lauritzen：** 表格很容易上手，也能迅速看清整体情况、方便审阅。我们生成的内容都有来源文件引用，用户可以很容易核查。还可以标记已审阅的内容、标出问题、评论和协作。我们试过其他形式，表格最好用。 **swyx：** 表格形式在某些领域很有吸引力，但好像还没普及。 **Basil Chatha：** GTM 领域的 Clay 就很出名，不过我想不出还有谁在做大型 AI 表格。 **主持人：** 以前 V7 试过，金融领域也有些表格产品，但还没有特别领先的。 **Jacob Lauritzen：** 我同意。要是把同一个任务并行分发到很多文档里，提取结果，表格就是非常合适的形式，让人一眼看清发生了什么。 **Basil Chatha：** 用户会导出到 Excel，还是直接在你们的表格里工作？ **Jacob Lauritzen：** 他们愿意直接在我们的表格里用。 **swyx：** 你们用 AG Grid，还是自己做的？他们这类产品做了十五年了。 **Jacob Lauritzen：** 他们确实很懂这个。 **Basil Chatha：** 工程师能理解并行处理的取舍：把任务分发给一百万份文件前，先在两份文件上试试，看看结果对不对，再全面跑。 **Jacob Lauritzen：** 对，我们的表格视图会先处理前十行。 **swyx：** 先检查结果是否符合预期。 **Basil Chatha：** 这设计很好。用户也可以在前十行上快速迭代，拿到满意结果后再大规模运行。 ## [37:53] Slack 法律 Intake 机器人怎么工作 · YouTube **Basil Chatha：** 接下来聊 Intake，也就是你们的 Slack 机器人。大家都有 Slack 机器人，你们有什么不同？ **Jacob Lauritzen：** 我们这个专门为法律工作设计。它会启动一个智能体，再把任务加入 Lists。Lists 有点像法律团队用的 Linear。请求会进入特定的 Intake 清单，律师和智能体可以在 Legora 里处理，合作完成后标记结束，结果再发回 Slack。 所以它不只是启动智能体，更像一个服务窗口：有人提交“我想审查这件事”，之后结果返回给他。法律团队在 Legora 里管理智能体，不需要改变其他流程。这个数据结构挺有意思：它就像各种请求的收件箱，这些请求可以进一步转成不同工作。 **Basil Chatha：** 把这些功能整合在一起难吗？ ## [39:11] 智能体能创建清单，清单也能启动智能体 · YouTube **Jacob Lauritzen：** 不难。我们有些很实用的基础构件。Lists 是个很灵活的构件，有点像 Notion 数据库，可以按需要配置。我们让它能扩展，也支持触发器和自动化，用它把各部分连起来。清单里发生某件事时，可以启动智能体；智能体完成后再回填字段、添加文件等。 就像用 Linear 或任务管理工具协调一群编程智能体，我们也能用 Lists 来协调法律智能体。智能体可以创建清单，清单可以启动智能体，智能体还能读取清单，于是整个智能体群就活起来了。（笑） **Basil Chatha：** 用户会为此兴奋，还是觉得复杂？这有点像让终端用户编程，可以搭各种自动化。 **Jacob Lauritzen：** 有些人会特别沉迷，甚至成了这类自动化的影响者。灵活性还是很重要，即使我们不把所有功能都直接开放给终端用户。 ## [40:17] 用同一套构件快速做产品，并收购 Wexler · YouTube **Jacob Lauritzen：** 即使只供内部使用，这些基础构件也能让我们的法律工程师很快做出产品。比如用 Lists 加上生成式界面，就能做定制的基金管理仪表板；也可以建立专门产品的市场。法律工程师在客户现场听到需求，可以很快给客户做一个。某种程度上，就像在 Legora 里放了个 Lovable。即使不把功能开放给用户，我们也能借此打造自己的定制功能。 我们还在英国收购了 Wexler，他们做的是事实情报，主要面向诉讼。你可以上传一百万份诉讼文件，我们从中提取实体、日期等事实，再把事实互相核对，看哪些能互相印证、哪些存在矛盾。还可以转录庭审，发现证人说了某件事，但邮件里却有相反证据。现场看到这种效果很震撼。 我们可以基于同一套核心构件开发很多产品。公司越大，需要解决的问题越多，所以我一直在想，怎样打造能扩展到不同终端产品的基础构件，让体验既可定制又能规模化。 **Basil Chatha：** 你们有哪些核心构件？ **Jacob Lauritzen：** 可配置的 Lists、存放文件的 Projects，以及能用不同配置启动的智能体。 **Basil Chatha：** 智能体有名字吗？ **Jacob Lauritzen：** 目前没有。以前有人把它叫作 Layer，但我们后来不用了，也许会再捡起来，可能会有点混淆。Lists、智能体、Tabular View 大概是最主要的几个构件。 ## [42:37] Legora 的前线部署工程师负责什么 · YouTube **swyx：** 我想聊聊前线部署工程师（FDE）。新大客户刚入驻时，你们希望尽快让他们获得价值，团队是什么时候开始做这类工作的？ **Jacob Lauritzen：** 大约九个月前，我们招了第一位前线部署工程师，也是我们在纽约的第一位员工；她还是一位 YC 创业者。我们一直在想，怎样才能规模化地支持这项工作。关键是让法律工程师和高级用户能强力定制产品。同时，前线部署工程师会负责定制集成、评估需求、判断可行性，并把反馈带回核心产品团队。 我把它看成两道防线：法律工程师应该能自行配置很多东西、打造良好体验；如果他们做不到，或者需要改核心产品、做定制集成，就由前线部署工程师介入。他们有时会和客户合作，有时也会回到产品团队工作。 ## [43:52] 法律工程师和前线部署工程师如何帮助大客户上线 · YouTube **Basil Chatha：** 举个例子吧。你们刚签下一家新客户，第一步是什么？会派前线部署工程师去给他们开发产品吗？ **Jacob Lauritzen：** 每家客户都不一样。大型客户通常很投入，有许多设想，或者已经试过自己开发但失败了，想解决某个具体问题。我们会安排法律工程师，必要时再配前线部署工程师。他们会和客户的律师一起工作，教大家使用产品，梳理现有流程，并把流程配置进 Legora。有些事情法律工程师就能完成，有些则需要前线部署工程师。 **Basil Chatha：** 两种角色的分工是什么？ **Jacob Lauritzen：** 法律工程师像高级用户一样配置产品，不写代码；前线部署工程师则会把代码写进生产系统。 **Basil Chatha：** 前线部署工程师通常是什么背景？ **Jacob Lauritzen：** 创业者、普通工程师都有。我们的第一位是 YC 创业者，之前在 Meta 做搜索。她是美国团队第一个真正落地的人。 **Basil Chatha：** 他们通常给客户搭建什么工作流？ **Jacob Lauritzen：** 差别很大。一些常见流程可以直接在 Legora 里配置，例如处理某类 NDA，这更像是构建技能。若现有构件不够灵活，或者客户有复杂系统需要集成，前线部署工程师就会用我们的 API 做集成，必要时也扩展 API。 **Basil Chatha：** 你们说过自己不能参与客户交易，那前线部署工程师怎么处理客户项目？ **Jacob Lauritzen：** 他们不会接触客户数据，只负责搭建系统。有时客户会像给员工一样为他们办入职、提供笔记本电脑，但大多时候只是开发集成。要不要给客户安排前线部署工程师，取决于客户规模和项目是否值得；他们也可能回去做核心产品，所以这是持续的优先级取舍。 ## [46:46] 未来一年，前线部署团队会如何发展 · YouTube **Basil Chatha：** Palantir 有个做法是每周四天在客户现场、一天回去改进产品。你们也这样吗？ **Jacob Lauritzen：** 目前还没有，说实话这块还在早期阶段。 **Basil Chatha：** 未来一年你觉得会怎么发展？ **Jacob Lauritzen：** 我觉得会有更大规模、持续轮转的前线部署团队，不一定完全照搬 Palantir。团队可能在一家客户那里待两个月，做出一个项目，再转去下一家。我能想象法律工程师和前线部署工程师一起进场，专门负责具体项目。 ## [47:24] Legora 为什么迟迟不做 API · YouTube **swyx：** API 也是平台策略的一部分。你们会承诺把 Web 应用里的所有功能都做成 API 吗？ **Jacob Lauritzen：** 目前不会承诺。我们有一些 API，客户可以基于它们开发，但并没有覆盖整个产品。 **swyx：** 这样用户不用学新工具，可以继续用现有工具，也不必自己维护整套系统。 **Jacob Lauritzen：** 对，这就是我们一直不太愿意做 API 的原因。大约六个月前我们才开始做，之前抗拒了很久。产品迭代太快，我不想因为必须维护旧版 API、适配已经变化的数据模型而拖慢速度。现在公司规模大了，这个成本可以承担；只有二十名工程师时，我们动得太快，做不了这件事。 我也想过，所有公司是不是都应该有平台团队和产品团队。产品团队可以快速做新产品，只要平台和具体产品没有绑得太死。 **swyx：** 这样就像 Web 应用、手机应用、MCP 以及其他集成，都是平台的不同客户端。前线部署工程师也是平台的一种用户。 **Jacob Lauritzen：** 没错。甚至可以把智能体也这样看：有一个团队负责智能体运行框架，然后再在它上面围绕技能和自动化做产品。 **swyx：** 这很像亚马逊云服务的要求：不允许团队走后门，只能用面向客户的同一套 API；没有就自己建，然后客户也能使用。 ## [49:26] 智能体能不能成为 API？ · YouTube **Jacob Lauritzen：** API 的概念可能也在变化。我们正在想：智能体能不能成为 API？听起来有点奇怪，但有些时候客户只想触发某件事。也许他们可以直接启动智能体，让它完成任务。当然，这肯定比直接调用专用 API 效率低得多，但我一直在琢磨，我们的产品有多少可以由智能体承担，多少需要其他东西。 **swyx：** 但这样执行时间、成本和延迟都不受限。 **Jacob Lauritzen：** 对，还有可预测性：也许一百次里有两次会做出我们不想要的事。 ## [50:12] “300 斯巴达人”幻灯片，以及只用 20 名工程师的计划 · YouTube **Basil Chatha：** 我们稍后还会聊 Harness 和模型微调。先谈产品取舍：你们现在是尽量拒绝需求、只专注少数事情，还是想多做一些、再多招一百个人？ **Jacob Lauritzen：** 很长一段时间里，我都坚决主张前者：什么都拒绝，工程团队保持精简。我在 Legora 半年后做过一张“300 斯巴达人”的电影幻灯片，说我们公司往后永远只要 20 个工程师，就能打赢那些大得多的对手。现在我们已经有 100 名工程师，却还是觉得人手远远不够。 现实是竞争很激烈，客户的需求也很多。我当然可以坚持只留 20 个人、只做很少的东西，但那样就会输，客户也会转向别家。所以我们得做更多。我的工作是设计一套系统，让我们看起来好像做了很多产品，实际上只需要打造少数几个核心构件，再由它们组合出更多体验。 **swyx：** 核心构件这个思路是对的。 **Jacob Lauritzen：** 对，我觉得这样很有力量。 ## [51:32] Legora 主动押注了哪些没人要求的方向 · YouTube **Basil Chatha：** 你们会做一些新产品，看看有没有需求；如果没有，就回到核心业务吗？ **Jacob Lauritzen：** 我们确实做过一些战略押注，但没怎么尝试自己都没把握的东西，因为手头已经有一大堆客户需求。我们主要去做客户反复要求的功能。有时我们也会和客户意见不同，觉得某件事对公司战略更重要，还是会去做。 **Basil Chatha：** 举个战略上主动做、但客户没要求的例子？ **Jacob Lauritzen：** 智能体就是一个。以前没人说“我希望助手能更自主，不用我开口就帮我行动”，但我们认为行业会走向那里，它能让用户完成很多很酷的事。协作也是如此：我们相信法律行业应该在工作平台 Legora 里协作，而不是靠邮件和短信。 **Basil Chatha：** 让律所学会使用智能体需要不少培训。你们会派前线部署工程师进去教他们吗？ **Jacob Lauritzen：** 主要是法律工程师，有人也会叫他们“前线部署法律工程师”。他们会帮助律所围绕智能体能力重新组织工作流。 ## [53:05] 为法律研究后训练开放权重模型 · YouTube **Basil Chatha：** 以前你们似乎没有微调自己的模型，现在还是这样吗？ **Jacob Lauritzen：** 到现在为止我们都没有微调过模型。不过最近几个月开放权重模型变得很强，我们会考虑在某些任务上做后训练，尤其是前沿模型与后训练模型之间，在成本和延迟上差距很大的任务。法律研究就是好例子：它是并行展开的检索问题，可以训练一个很有效的模型，用很低延迟和成本快速处理这些查询。 **swyx：** 也就是说专门针对边界清晰的具体任务做后训练？ **Jacob Lauritzen：** 正是如此。我们不是要训练自己的 Fable，打造主智能体。我们大概率赢不了 Anthropic 这样的公司。不过搜索、检索和 RAG 还有很多研究空间。 ## [54:05] 搜索、检索与后期交互 · YouTube **swyx：** 这些工作可能没那么光鲜，也未必涉及模型训练，有时只是架构和流程设计。你们做后期交互检索吗？ **Jacob Lauritzen：** 目前没有。不过你说得完全对。团队里有个人特别关注搜索，经常来找我说应该试试新嵌入模型和后期交互。他还联系 Turbo 团队，推动他们构建多向量支持，好让我们试这些方法。 不过，在模型和 Harness 上动手之前，还有大量容易实现、效果立竿见影的改进。只要想给客户更好的结果，我们还有很多事情可以做。 ## [54:51] 法律智能体的 Harness，以及起草合同为何是搜索问题 · YouTube **Basil Chatha：** 法律行业里，一个好的智能体 Harness 应该是什么样？ **Jacob Lauritzen：** 文件编辑方式很重要，分析方式很重要，法律研究的能力也得融进去。出现问题时，智能体要知道如何做法律研究、找到答案和先例，当然还要有相应的治理机制。 **swyx：** 搜索可能是最需要定制的工具？如果找不到正确的信息，后面就全完了。 **Jacob Lauritzen：** 对，搜索和分析都重要。起草合同也并不简单。比如从头起草一份大型合同，得先找过去的先例，判断需要哪些条款，以及这家律所以前是怎么处理的。律师不会直接坐下来敲字，他们先找类似交易里用过的条款。“类似”可能指同一行业、同类公司，或其他相似条件。然后还要从多份文件里挑出该采用哪些部分。这其实就是一个搜索问题。 ## [56:25] 哪个模型最擅长起草？ · YouTube **Basil Chatha：** 哪个模型最擅长起草？ **Jacob Lauritzen：** 我昨天刚提过，Fable 和 Opus 确实特别爱说，输出很冗长。 **swyx：** 这通常不是好事。我发现 Astra 写作挺不错。 **Jacob Lauritzen：** 对，Astra 写得更简洁。我们当然会对不同任务做测试，但模型太啰嗦这个问题不太好解决。Anthropic 下一代模型可能会好很多。Astra 其实很精炼。 **Basil Chatha：** 他们都有和你们的 Slack 群吧，你们会把这些反馈告诉他们？ ## [57:03] 幻觉，以及 Legora 的引用系统 · YouTube **Jacob Lauritzen：** 他们知道这些。另一个我很在意的问题是幻觉。 **Basil Chatha：** 模型会编内容吗？ **Jacob Lauritzen：** 我们有一套引用系统，会检查它写的内容能否链接到来源。用户可以点击链接，PDF 里会用边框框出信息来源。我们希望所有内容都有出处，即使信息经过了好几层处理也一样。比如智能体根据 Tabular Review 写内容时，可以引用表格里的某个单元格或某一行。用户可以一层层点进去，验证内容。 ## [57:41] 律师会核实引用吗？ · YouTube **Basil Chatha：** 你们发现律师会核实引用是否正确吗？ **Jacob Lauritzen：** 一开始他们会查，但后来就不怎么查了。 **swyx：** 假链接甚至可能会指向最高法院的文件。 **Jacob Lauritzen：** 对，这种事确实会发生。我觉得这和编程一样：有些工程师不怎么看代码，就把智能体的结果直接交出去；也有人会把每个逗号都看一遍。 **Basil Chatha：** 人怎么可能把所有东西都查完？ **Jacob Lauritzen：** 但他们大概知道该检查什么，就像代码审查一样。他们会找到重要问题和红旗，把关键处再核对一遍。如果其他内容听起来合理，可能就会接受。 ## [58:19] MapReduce 还是把百万 Token 合同一次放进上下文？ · YouTube **Basil Chatha：** 收到初级律师交来的东西，你也会再检查一遍，觉得大概没问题，是吧？还有哪些法律推理能力是模型还不够好、你希望下一代模型补上的？ **Jacob Lauritzen：** 现在我想不到特别具体的事。长文档推理仍然很难。 **swyx：** 比如一百万 Token 的上下文？ **Jacob Lauritzen：** 对。一份很长的合同要在全文不同位置修改，模型得记住前面改了什么、定义和顺序怎么变了，这很难。最简单的做法是一次把所有内容放进去，一次生成结果，但我们不会那样做，而是把文档分块，再编排修改。 **swyx：** 这正是这个行业有意思的地方。你们的 Word 插件里尝试过 MapReduce，也试过一次塞进一个大上下文；随着模型变化，我们会不断调整外围的脚手架。 我做新闻报道时，最近也从 MapReduce 改成把内容全放进上下文，效果更好。 **Jacob Lauritzen：** 但两种做法各有不同。比如在大型合同里搜索，MapReduce 可能会在分块总结时丢掉重要细节。某些内容要跨几页一起看，每一块单独看都和搜索目标不相关，合起来却非常重要。所以我们会做不同类型的搜索，有些还需要在不同步骤之间进行推理。 ## [1:00:17] 获取匿名案例，以及收购律所获取数据的想法 · YouTube **Basil Chatha：** 你们甚至看不到真实合同，要改进模型肯定很难。会不会请客户提供和真实合同类似的示例？ **Jacob Lauritzen：** 客户可以给我们反馈。如果某件事对他们特别重要、效果却不好，我们可以请他们把相关文件和提示词匿名化。如果我们能复现问题，就能修复。 **swyx：** 还有一种方式是直接收购一家律所。 **Jacob Lauritzen：** 确实有人在考虑。不过有个问题：律所的数据到底属于律所，还是属于客户？如果客户都走了，也许就可以，但我也不确定。收购律所确实能得到很多数据，像 Google 收购机器人公司一样。 **swyx：** 公司倒闭后还有 Slack 数据，也可以卖掉。有 YC 公司专门收购失败的初创企业，就因为还留着真人做事的记录。 **Jacob Lauritzen：** 收购律所数据的优点是能拿到真实输入，但输出端比较困难：你只知道最后结果是什么，却得反向推断它是怎么做出来的。在我们的产品里，拿到真实用户的完整轨迹非常有价值；如果只看到输出，不知道它好不好、是怎么生成的，就很难判断。 ## [1:01:53] Jacob 建议不要直接用默认嵌入模型 · YouTube **swyx：** 快结束了。最后提醒大家，嵌入模型还有很多优化空间。如果你的工作流大量依赖 RAG，却直接采用现成的默认模型，就会错过很多提升。可以看看 Voyage 或定制嵌入模型。 **Jacob Lauritzen：** 所以不要直接用默认嵌入，包括开源模型或 Gemini 的嵌入都一样，应该按需求定制。 **swyx：** 对，你们会支持客户这么做吧？ **Jacob Lauritzen：** 我觉得可以，不过要考虑多语言。我们的服务要覆盖很多语言。 **主持人：** 欧洲在多语言方面最有经验。 **Jacob Lauritzen：** 是的，这方面很有帮助。 **swyx：** 不过直到现在才拿到很多钱吧？他们刚融资不少。 **Jacob Lauritzen：** 欧洲需要更多模型公司。 ## [1:02:44] 律师会在 Legora 工作，还是通过 Claude 工作？ · YouTube **Basil Chatha：** 对法律行业未来一年的预测是什么？换个问法，两年后律师会在 Legora 里工作，还是会通过 Claude 这类工具和 API 工作？ **Jacob Lauritzen：** 我觉得两种都会有，具体看客户。大型企业可能在 Claude Cowork 里工作，同时也会用 Legora，就像我通过 Claude 使用 Linear，但仍会直接打开 Linear。律所可能会直接用 Legora，因为更简单、效果也更好。 **swyx：** 你们有点像医疗领域的 OpenEvidence。 **Jacob Lauritzen：** 对。 ## [1:03:26] 模型实验室会不会切断 Legora 的服务？ · YouTube **Basil Chatha：** 编程领域已经发生过两次：模型实验室会因为你和它们竞争而切断服务。法律行业也会这样吗？ **Jacob Lauritzen：** 我觉得不会，因为它们自己也在推出法律服务。 **swyx：** 你们经常和它们沟通，但你敢直接问它们会不会这么做吗？ **Basil Chatha：** 销售肯定会说不会，但他们也不一定能拍板。（笑） **Jacob Lauritzen：** 我不太担心。企业知识工作涵盖很多方面，法律必须包含在内，就像数据分析、销售、市场和财务一样。它们会做法律产品，但永远不会像我们这样深入。如果 Claude 服务小型企业、承接一些法律工作，那很好，也没关系。但要做一笔 4 亿美元的并购交易，你会想用 Legora。 ## [1:04:25] 法学院，以及给计算机专业学生的奖学金 · YouTube **Basil Chatha：** 你们会去法学院，让学校在课堂上教 Legora 吗？ **Jacob Lauritzen：** 这确实是我们正在推进的项目。我不清楚现在具体进展到哪一步，但我们希望法学院学生学会使用 Legora。 **Basil Chatha：** 你看到法学院大幅调整课程了吗？ **Jacob Lauritzen：** 这方面我不太了解。 **swyx：** 我会换个思路：给计算机专业毕业生提供法学院奖学金。你学完计算机科学，再积累一些软件经验，我们就资助你去读法学院。 **Basil Chatha：** 是联合硕士和 JD 学位那种项目？ **swyx：** 不一定非要有硕士。很多人本科没读计算机，后来读硕士补基础。我不确定这种情况有多普遍。JD/MBA 很常见，但 JD/计算机科学好像不太常见。 ## [1:05:28] 在纽约、斯德哥尔摩和伦敦招聘 · YouTube **Basil Chatha：** 总体来说，你们发展得很快，恭喜。还会保持这个速度吗？我看到你们在旧金山和纽约招人。 **Jacob Lauritzen：** 工程师目前在纽约、斯德哥尔摩和伦敦招聘，其他岗位则全球都在招。 **Basil Chatha：** 纽约现在有多少人？ **Jacob Lauritzen：** 一百人。 **Basil Chatha：** 你们打算在纽约招多少？ **Jacob Lauritzen：** 越多越好。 **Basil Chatha：** 招聘力度真大。（笑） **swyx：** 这就是美国公司法的全貌，对吧？ ## [1:06:11] 大多数工作最终都会变成法律工作 · YouTube **Basil Chatha：** 我等着看你们收购一家律所。很令人期待。医生、律师、程序员这些行业，都会有两三家智能体实验室完全主导市场。你们所在的市场很不错，而且随着法律变革、更多人能用上法律服务，市场还会变得更大。 **swyx：** 我们已经聊超时了，不过你们解决的问题确实位于知识工作的前沿。 **Basil Chatha：** 对，除非你是在做 Navier–Stokes 方程之类的科学研究，否则大多数工作最后都会归到法律上。 **swyx：** 最后什么都是法律：招聘、财务，所有事情最后都得问律师。这也是我觉得法律特别值得做的原因，现代社会在某种程度上就是靠法律运转的。 **Basil Chatha：** 好，今天就到这里。谢谢大家。 **Jacob Lauritzen：** 谢谢。