法律 AI 怎么落地：Legora 的评测、产品与交付实践

法律 AI 的难点，不只是让模型读懂合同。客户数据高度保密、任务质量难以衡量、产品需要接入律所工作流程，这些约束都会影响系统设计。

Legora CTO Jacob Lauritzen 分享的实践，围绕三个问题展开：看不到客户数据时如何评测，如何把复杂法律工作拆成可复用能力，以及如何让工具真正进入律师的日常工作。

一、看不到客户数据，如何评测智能体？

许多智能体团队会通过查看执行轨迹来定位问题，但 Legora 无法这样做。用户上传的材料几乎都具有保密性，其中不少属于律所的客户，而非律所自身。

Legora 的做法是重建客户任务，而不是读取客户任务记录。

其评测团队由三名工程师和三名律师组成，搭建模拟客户工作的强化学习环境。例如，构造一个包含一万份文件的虚拟资料室，让智能体执行尽职调查，并检查最终报告是否识别出了应当发现的风险。

评测结果按法律业务领域和任务类型绘制成热力图。Jacob 提到，新模型并不意味着所有任务都会改善：某些法律工作的表现可能提高，另一些却会退步。

此外，团队还会：

基础设施选择同样受到客户要求影响。Jacob 表示，Legora 起步时，律所不接受 AWS 或 GCP，而微软已凭借 Microsoft 365 进入获批供应商名单，因此团队选择了 Azure。

Legora 曾长期抵制加入模型选择器，后来才开放这一功能。Jacob 的观点是：律师不应该先判断一份合同适合哪个模型、哪个推理档位，才能开始工作。

平台需要在以下因素之间权衡：

Jacob 估计，模型已经能很好地处理约 60% 的法律工作。对这些任务，优化重点更多是成本与延迟；涉及百万 token 级合同的复杂分析和跨文档编辑，仍然需要更强的模型能力。这一比例是他的判断，并非适用于整个法律行业的统一测量结果。

Legora 也开始针对法律检索等窄任务，对开放权重模型进行后训练，但没有训练自有前沿模型的计划。

在降低幻觉风险方面，系统为智能体生成的内容配上引用，并支持定位到对应 PDF 的具体区域。这提供了核查路径，但并不等于输出必然正确。

Legora 的 Tabular Review（表格审查）把批量文档分析组织成二维表：

例如，导入一万份劳动合同后，可以分别提取解约通知期、知识产权归属条款和离职补偿条件。

这项功能最多支持一百万个单元格，但不会一开始就处理全部内容，而是先运行十行，让用户检查并修改提示词，再扩展到其余文档。

这一流程为大规模执行提供了小样本校准环节，避免用户在尚未确认问题表达是否合适时，就直接启动整批任务。

Legora 围绕几类基础模块构建产品：

智能体可以创建、读取列表，列表变化也能触发智能体。例如，Slack 中的请求可以被转成列表里的工单，再进入后续流程。

法律工程师能够在这些模块上配置新产品，而不必编写代码。Jacob 希望通过这种方式，让团队交付有限的底层能力，却能覆盖更多客户场景。

Legora 将领域配置与工程集成分成两类工作。

法律工程师更像熟悉法律业务的高级用户，负责理解任务、配置产品，不编写代码。

**前线部署工程师（FDE）**则负责生产代码和系统集成，例如对接律所的客户关系管理系统或文档管理系统，并把交付中发现的需求反馈到核心产品。他们同样不接触客户数据。

对于参与度高的大客户，Legora 会先安排法律工程师，需要工程集成时再加入 FDE。Jacob 还计划采用轮转方式，让 FDE 在客户现场工作数月，完成建设后再转向其他项目。

Jacob 最初对法律科技的疑问很直接：如果律师按小时收费，效率提高意味着计费时间减少，为什么要购买提效工具？

他的观察是，律所承受的商业压力正在改变这一逻辑。在美国，部分常规审查工作已经转向固定项目收费，有些律所甚至免费提供此类服务以维系客户，收入重心则转向并购、诉讼和客户沟通。

但这不意味着初级律师一定会被替代。Jacob 表示，Legora 看到的情况是，优秀初级律师能够完成更多工作，其价值反而提高了。这是公司的业务观察，而不是对整个行业就业趋势的定论。

对构建企业级智能体的团队而言，Legora 的实践展示了一个具体路径：围绕真实任务设计评测，以可复用模块承载工作流，再用领域人员与工程人员协作完成交付。模型能力只是其中一环。