法律AI最大的工程难题不是模型，是永远看不到真实数据
客户数据大多连律所自己都无权查看，Legora的evals团队只能靠分类和改写后的合成数据，去猜测律师们真实在做什么。
原视频在 YouTube 上放不出来，用音频听：
核心论点 · 点时间戳可跳到原声
最难招的人是懂代码的大所律师
Legora的evals团队由工程师和律师混合组成，另外还有一批「法律工程师」——在大所执业三四年、同时有CS背景的律师。这类人懂法律实务又懂技术，是招聘里最难凑齐的交集，Jacob直接说这是公司最难招的岗位。但他们价值极高：既能做评测，又能直接影响产品设计，因为他们自己每天用产品、也每天见客户，是能拉出一百人专家池去塑造产品的力量倍增器。
— Jacob LauritzenAI未必能救得了律所合伙人制度
合伙人制存在的原因很简单：律所唯一的资本是人力资本，留不住人就留不住公司，于是干脆把人变成股东。Jacob认为AI本该让律所把经验和工作方法沉淀成可复用的系统——比如一个会自我迭代的知识图谱——从而积累一种不属于某个人的无形资产。但现实是合伙人靠「吃掉自己猎到的」方式计费，花时间编码经验反而耽误拉新客户，一旦离开合伙人身份，这些资产也分不到自己头上。这个激励错位目前没有答案。
— Jacob Lauritzen初级律师没被淘汰，而是被两极分化
主持人抛出「律师助理没用了、初级律师没用了」的论断，Jacob直接反驳说这不是他们看到的现实。他拿工程师类比：一个优秀的工程师今天比两年前值钱得多，因为借助AI能产出远超从前的工作量；律师同理，好的初级律师会因为能用AI做出更多、更高质量的产出而变得更值钱。这种分化一直存在，只是现在被放大了，而不是整个群体消失。
— Jacob Lauritzen看不到任何用户真实数据怎么做评测
Legora最大的工程难题不是模型能力，而是几乎看不到客户在产品里做什么——数据全程保密，很多时候甚至不属于律所自己，而属于律所的客户，连看一眼都不被允许。公司只能靠单独的evals团队去猜测、近似真实使用场景，再把猜测编进评测集。改写、脱敏后生成的合成轨迹是唯一可行的替代品，而脱敏越偏向「绝对安全」，信号就越弱，这被Jacob称作业务里最烦人的一个结。
— Jacob Lauritzen三年前律所连AWS都不敢用
Legora的全部基础设施建在Azure上，原因很直接：创业早期律所客户明确表示不信任AWS、不信任Google，理由是没人替它们做过安全评审；但微软因为已经是Office 365的供应商，在律所眼里早就「过审」了，于是顺理成章成为唯一能用的云。Jacob说这种对公有云的抵触在过去三年里几乎完全消失，连关于私有化部署的讨论也一起消失了——这个行业的云迁移，是被AI倒逼着在三年内走完的。
— Jacob Lauritzen法律工程师不写代码，前线工程师才写
Legora把现场支持拆成两层：「法律工程师」是大所出身、懂产品也懂客户工作流的人，负责像高级用户一样配置产品，不碰代码；「前线部署工程师」才是真正写代码、对接客户内部系统API的工程师，通常是连续创业者或大厂背景。大客户的定制需求先交给法律工程师处理，处理不了、需要改产品或做深度集成时才升级给前线工程师，这套两层分工让公司不必为每个大客户配一整个工程团队。
— Jacob Lauritzen二十个工程师打败所有对手的想法放弃了
Jacob曾打算让公司永远只保留二十名工程师去打败规模大得多的对手，现在团队已经一百人，他却觉得还是太少——激烈竞争和客户的海量需求让这种极简主义难以维持。他现在的思路是把产品收敛成少数几个核心原语（Lists、Projects、Agent），客户感觉公司做了很多东西，但背后其实只是这几个原语的组合；他甚至在设想未来「agent本身就是API」，用一次agent调用取代原本要长期维护的整套接口。
— Jacob Lauritzen大模型公司会不会把Legora这种公司挤掉
过去Anthropic和OpenAI已经两次在编程和搜索领域，把依赖它们模型吃饭的创业公司挤出局，Jacob被问到法律行业会不会重演。他的判断是不会：大模型公司要覆盖企业知识工作的方方面面——法务、数据分析、销售、财务都要兼顾，不可能在法律这一个垂直领域做到足够深；小客户用Claude顺手处理一点法务没问题，但做一笔四亿美元的并购交易，企业还是会选择专门做深做透的Legora。
— Jacob Lauritzen原话 · 已逐字校验
Paralegals, gone. Yeah. Junior lawyers, gone. I don't need them.
律师助理，没用了。对。初级律师，也没用了。我不需要他们。
something that I'm toying with is, like, how much of our product can just be the agent versus all the other stuff?
我一直在琢磨的一件事是，我们的产品到底有多少部分可以干脆就是那个agent本身，而不是其他所有附加的东西？
Jacob Lauritzen0:00
we had one problem where, like, it wouldn't cite properly, and so it would be difficult to follow, and it was like next model release solved.
我们有一个问题，就是它引用得不对，导致很难看懂它的论证过程，结果就是下一次模型发布就把它解决了。
Jacob Lauritzen11:00
we can't look at any traces, basically. We can't look at any data 'cause it's all super confidential.
我们基本上没法看任何轨迹数据。我们什么数据都看不了，因为这一切都是高度保密的。
Jacob Lauritzen27:00
when we started, law firms were like, "AWS? No."
我们刚起步的时候，律所的反应是：「AWS？不行。」
Jacob Lauritzen29:00
we're just gonna be twenty engineers for the rest of the company's history, and, like, we're gonna beat everyone who's much bigger. And we're a hundred engineers now, and it feels like we're way too small.
我们公司往后余生就只招二十个工程师，然后把所有比我们大得多的对手都打败。而我们现在已经有一百名工程师了，却感觉还是太小。
Jacob Lauritzen50:45
But if you're doing a, you know, $400 million M&A transaction, you're gonna want Legora.
但如果你要做一笔四亿美元的并购交易，你会想要用Legora。
Jacob Lauritzen1:04:00
数字与实体
| 引用错误经模型升级后修复的准确率 | 从70%提升到99% | 11:00 |
| Tabular Review单次处理的单元格数量 | 最多一百万个 | 21:50 |
| 尽职调查数据房示例规模 | 一万份雇佣合同/文件 | 9:39 |
| 团队规模变化 | 从「永远20名工程师」的目标涨到现在约100名工程师 | 50:45 |
| 纽约团队人数 | 约100人 | 1:05:00 |
| 被反复举例的并购交易规模 | 4亿美元 | 1:04:00 |
术语
- Tabular Review表格式批量审查
- 让agent对成千上万份文档逐一提问、把结果汇总成表格的功能
- Forward Deployed Engineer前线部署工程师
- 入驻大客户、直接写代码做深度定制集成的工程师
- Legal Engineer法律工程师
- 有CS背景、曾在大所执业的律师，负责产品配置和评测，不写代码
- Pareto frontier帕累托前沿
- 在能力、成本、延迟之间始终选当下最优模型组合的策略
- DPA数据处理协议
- 规定数据可流向哪些供应商的合同，决定了能接入哪些AI模型或工具
收听指南
企业级AI产品经理、法律科技从业者、关心数据隐私约束下如何做产品与评测的工程师。
结尾关于法学院奖学金和CS转JD项目的闲聊信息量低，可跳过。