法律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項目的閒聊信息量低，可跳過。