看不到客户数据，如何打造法律 AI 智能体：Legora 的 Jacob Lauritzen 专访

Legora 首席技术官 Jacob Lauritzen 与 swyx、Basil Chatha 讨论如何为律师打造 AI 工具。他把公司在斯德哥尔摩的起步经历形容为长期处于劣势的一方：进入美国市场后，团队需要学会更自信地向客户介绍自己的成果。

Legora 最初是一个接入瑞典法律搜索工具的 ChatGPT 式界面。法律研究需要查找相关的既往案件和先例；此后，产品逐步扩展到起草、编辑 Word 文档、整理文件和开展更复杂的分析。

其中一项扩展是表格审阅，用来从大量协议中批量提取信息。另一项是工作协调：列表用于组织任务，请求接收和门户则帮助律师、客户与智能体协作。Lauritzen 认为，机会既在于完成法律工作，也在于改善工作在人与人之间的流转。

团队把产品的演进称为从助手转向能力更强的智能体。Lauritzen 估计这一变化发生在访谈前约一年；主持人则指出这一领域进展很快。Legora 参加了 Y Combinator 2024 年批次，Lauritzen 本人此前单独参加过 2023 年批次。

Legora 针对不同任务使用不同模型。用户可以选择智能体的主模型，具体工具则可能把子任务交给其他模型。Lauritzen 说，团队长期不愿加入选择器，但有些客户希望自己掌控，并使用新模型，即使某项任务未必需要额外能力。

主持人将垂直领域智能体提供商视作替用户跟踪模型发展的一层中介。律师不应该每次起草合同时都判断该用哪个模型档位。Lauritzen 希望兼顾质量、成本与速度，同时承认仍有用户想亲自试验。

Lauritzen 估计，现有系统已经能较好地处理约 60% 的法律工作，对这部分工作而言，成本与延迟仍是重要约束。他认为，更复杂的分析仍需要更强能力，而更好的系统也可能扩大律师愿意开展的工作范围。这是他的估计，并非经过测量的行业基准。

他说，把检索分派给子智能体是进步明显的领域之一。Legora 用热力图跟踪各模型在不同法律业务领域和任务上的表现。他说，新版本通常会总体进步，但某些任务也可能退步，因此应当测试，而不是假设每一次更新都更好。

评估时，团队会构造类似法律项目的场景。一个模拟尽职调查资料室可能包含 1 万份文件，要求报告找出特定风险，同时避免引入无关说法。团队可以把分析质量与报告是否清晰、完整分开评估。

专门的评估团队由工程师和律师组成；Lauritzen 说，访谈时双方各约有三人。团队还能借助更大的法律工程师群体：他们通常有大律所工作经验，对技术感兴趣，既使用产品，也与客户交谈，因而能参与产品设计和评估。

早期，团队往往只需通过更好的产品和智能体框架，让律师用上不断进步的模型。Lauritzen 回忆，团队曾遇到一个引用问题，后续模型版本在该项问题上的表现从约 70% 升至 99%，团队自身无需改动。他并未将其称为整体引用准确率。

产品设计还需要设想五年或十年后的法律工作方式。Lauritzen 希望减少冗长的邮件往返和文档版本交换，同时保留审计日志、数据保留控制等受监管工作所需的功能。未来，主动智能体也许会把待处理事项呈给律师审阅，而不必等待每一条指令。

Lauritzen 特别强调，这只是预测：没人确切知道法律行业将变成什么样。他预计律师会花更多时间进行战略判断、评估风险和维护客户关系，减少繁琐的文档查找。结果既取决于技术进步，也取决于律所如何重新设计工作。

谈到合伙制时，Lauritzen 指出，专业服务公司的价值历来依赖人的专业能力，所有权结构因此也承担留住人才的作用。他想知道，律所能否将方法、先例与判断沉淀为其他同事可以使用的系统，从而建立更持久的资产。

这一设想带来了激励问题。如果合伙人的回报主要来自带来客户，他们可能缺少动力投入时间建设自己离开后仍属于律所的资产。Lauritzen 并不声称已经解决商业模式问题；他认为，如何激励机构知识的长期积累仍待探索。

主持人追问初级律师和律师助理是否会消失。Lauritzen 说，他目前没有看到这种情况：律所仍需要下一代人才，而能力出色的初级员工借助更好的工具可能更有效率、也更有价值。讨论将可以自动化的单项任务，与对整个职业的确定性预测区分开来。

按小时计费带来另一种张力。Lauritzen 回忆，自己曾质疑律所为什么会采用让计费工作变快的技术。他现在认为竞争压力正促使律所改变；他说，尤其在美国，一些较简单的工作已经采用项目费或固定收费，而非严格按小时计费。

按照 Lauritzen 的说法，战略工作、重大交易、诉讼和客户关系仍然有价值。有些律所过去为了维系关系，会免费提供部分服务；减少日常工作量可能改变这类服务的经济账。他并未声称所有法律费用都会下降。

嘉宾讨论了监督智能体所需的技能。了解法律工作流、熟悉工具并能完善输出，本身可以是有意义的工作。Lauritzen 说，常规批量审阅可能减少员工通宵手工提取信息的需要，让他们有时间承担其他职责。

Legora 在收购尽职调查中使用过自己的工具。Lauritzen 说，表格审阅有助于团队及早发现问题，而外部律师仍会就战略风险和其他司法辖区的工资事务等本地问题提供建议。他说团队曾发现导致交易暂停的风险，但拒绝透露交易细节。

按 Lauritzen 的经验，美国客户总体行动更快，也更愿意定制系统和集成；欧洲客户则更常从现成产品开始并提供反馈。他提醒不要因此认为其中一方不重视 AI：在他看来，双方只是采用不同方式实现共同的战略目标。

公司跟踪回访频率、产品使用时间和续约等常见信号，也开展在线评估，对比功能上线前后的表现，以发现改进或严重退步。特殊的限制是团队通常不能查看客户的底层工作轨迹：保密材料往往属于律所的客户。

主持人问，能否让模型改写真实交互，制作安全示例。Lauritzen 说，仅删除姓名可能仍不够，因此公司通常采取更严格的做法。把失败归入少量类别，或标记任务类型与业务领域，可以在不暴露底层案件的情况下获得部分信号。

客户的数据要求也影响基础设施选择。Lauritzen 说，Legora 最初采用 Azure 托管，部分原因是律所已经熟悉 Microsoft 这一供应商。他描述的是客户选择随时间发生的变化，并不是对任何特定部署安全性的保证。

对每项任务，公司都要权衡模型质量、延迟、价格、治理要求和地区可用性。Lauritzen 说，一些开放权重模型适合特定工作，另一些任务仍适合前沿模型。他希望针对边界明确的任务进行后训练，而非假定一个模型处处最好。

他举例说，早期某个 Gemini 模型在特定转录和说话人识别任务上表现不错。供应商选择也受数据处理协议影响：即便其他专用模型很有吸引力，缩短供应商名单也有助于简化治理。

嘉宾提醒，语音识别遇到专业词汇时仍会出现后果严重的错误。他们讨论的一种工作流是先让语言模型提取可能的关键词，再带着这些提示重新转录。Lauritzen 说，大规模使用或处理日常对话以外的内容时，错误尤其容易显现。

话题回到产品设计：智能体、表格审阅，以及 Word 和 Outlook 集成都是主要组成部分。在尽职调查表格中，每一行可以代表一份雇佣合同，每一列对应一个问题，例如通知期、知识产权转让条款或薪酬。

智能体可以启动批量审阅，等待完成后分析结果，向律师标出异常，也可以协助起草备忘录。表格便于快速浏览结果、协作、标记已审事项，并通过引用查看原始文件。Lauritzen 说，团队处理过多达 100 万个单元格的表格。

在把问题应用到大量文件之前，产品会先运行前 10 行，让用户检查并改进查询。主持人把它比作大规模并行处理前先测小样本：快速反馈可以发现问题是否没有提取出律师想要的信息。

请求接收功能不只是一个普通的 Slack 机器人。请求可以变成法律团队列表中的事项，由律师和智能体处理、标记完成，再通过 Slack 返回结果。发起请求的员工不必切换界面，法律团队则有共享空间管理工作。

Lauritzen 将列表称为一种灵活的基础组件，类似可配置数据库。触发器和自动化可以启动智能体；智能体也能读取或更新列表字段、添加文档。同一组组件让法律工程师配置专门工作流和仪表盘，公司不必从头构建每一种体验。

他还提到收购 Wexler 后的诉讼事实分析场景：从文档中提取带日期的事实和命名实体，再比较支持或反驳某项主张的证据。他将其视为平台基础组件的一种应用，而不是律师判断的替代品。

Legora 的法律工程师与前线部署工程师分工不同。法律工程师以资深用户身份配置工作流，并帮助客户采用产品；需要时，前线部署工程师编写生产代码、构建集成，并把需求反馈给核心产品团队。客户项目需要哪些人员取决于具体范围。

常见工作流可能直接在产品中完成配置，但复杂集成或缺失的基础能力可能需要工程开发。Lauritzen 说，前线部署工程师构建系统时仍不需要查看案件机密数据；必要时，客户也可能像接纳员工一样为他们办理入职手续。

公司提供 API，但没有承诺产品的每一项功能都会通过 API 开放。Lauritzen 说，团队曾推迟开放 API，因为产品变化太快，不想长期维护与已变更数据模型对应的旧版本。随着公司扩大，团队才更有能力承担维护成本。

他还在思考，触发智能体能否满足部分原本需要传统 API 的集成需求。这只是探索中的想法，并非已经宣布的产品承诺。参与者指出其中的取舍：与固定接口相比，智能体执行可能更慢、更贵，也不够确定。

Lauritzen 曾设想将工程团队保持在 20 人，以小团队与更大的对手竞争。他说，团队后来已增至约 100 名工程师，相对于需求仍显得人手不足。他的目标是构建少量可复用的基础组件，支撑范围广得多的客户功能。

客户需求决定了大部分路线图，但团队有时也会在客户明确提出之前做战略押注。Lauritzen 举例说，包括向更自主的智能体转型，以及在产品内协作。随后，法律工程师会帮助律所围绕这些客户可能从未想到要提出的能力调整工作流。

Lauritzen 说，访谈时 Legora 尚未微调自己的模型。他预计会针对法律研究中的某些环节等边界明确的任务，选择性地对开放权重模型做后训练，以改善高频检索的成本与延迟。他并不打算训练通用前沿模型来替代主智能体。

无需训练模型，检索流程和智能体框架仍有大量改进空间。Lauritzen 提到改进嵌入模型和后期交互等可能性，同时澄清团队目前没有使用后期交互。更好的搜索、分析、文件编辑与治理都能改善最终结果。

起草复杂合同在某种程度上也是检索问题。律师需要寻找可比交易中的条款和先例；所谓可比，可能是指行业、交易对手或交易类型相近，然后再决定从多份文件中取用哪些部分。找到正确材料并不是写作之前一件简单的小事。

为了让生成的结论可供检查，Lauritzen 介绍了一套引用机制：链接可以指向原始文档中高亮的位置。基于表格审阅得出的结论可以先链接到单元格，再进一步链接到文件。链接有助于核查，但不能取代人对哪些结论和来源需要检查的判断。

他将审查方式与代码审查相比：不同人检查输出的仔细程度不同，有经验的审查者可能把精力放在高风险点上。长文档推理仍然困难，尤其是对合同中的定义或顺序进行修改后，需要在全文保持一致。

把长文档拆分成多个部分有助于协调编辑，但如果各自独立总结，也可能遗漏只有跨段落才能理解的内容。团队会随着模型进步调整框架，并根据材料和问题考虑不同搜索方法。

如果客户愿意配合，客户反馈有时可以提供匿名化文档和提示词，帮助团队复现失败。嘉宾还讨论了获取法律数据，但 Lauritzen 指出，律所记录究竟属于律所还是其客户，存在不确定性。仅有最终产出，也未必能看出产生它的推理过程或过程质量。

主持人建议针对实际检索工作测试嵌入模型，而不是仅凭基准测试选择默认模型。Lauritzen 表示赞同，并补充说，多语言表现对 Legora 的用户很重要，尤其是在欧洲不同语言之间。

展望未来，Lauritzen 预计，一些企业会通过更通用的工具和 API 使用专业法律能力，而律所可能直接使用 Legora。他认为模型供应商会构建通用法律功能，但专业产品有望在要求较高的工作流上走得更深。这是他对竞争的预测，而非对未来产品的保证。

谈到法学院时，Lauritzen 说公司希望学生学习使用这些工具，但他并不声称了解课程正在如何变化。对话最后转向招聘以及法律工作对组织的广泛意义：财务、雇佣和其他商业决策经常依赖法律判断。

Lauritzen 说，Legora 正在纽约、斯德哥尔摩和伦敦招聘工程师，其他岗位也在更多地点招聘。主持人最后回到法律工作的广度：雇佣、财务和组织生活中的许多环节都涉及法律专业知识，这也是 Lauritzen 认为这项工作很有吸引力的原因。