"我们基本上看不到任何 trace……这里有一个 agent,它能做那么多惊人的事,而我这边完全不知道人们实际在干什么":一家法律 AI 的 CTO 谈在看不见数据的前提下做 eval、合伙制为什么挡着知识沉淀,以及"agent 能不能就是 API"(Latent Space × Legora,2026-11-02)¶
- 嘉宾: Jacob Lauritzen — Legora 的 CTO(法律 AI;本库此前已有 Legora CEO Max 的 2026-07 材料,⚠️⚠️ 本期是同一家公司四个月后的技术侧视角,并澄清了本库此前一处读错的事实,见第七节)
- 主持: swyx 与一位未被点名的共同主持(⚠️ 转录稿只在开头出现一次自我介绍,不足以确证第二位主持身份),人物页见 Latent Space 主播
- 来源: YouTube · 67 分钟
- 转录稿: sources/latent-space/20261102-bJBEFzlKPoQ(⚠️ 自动字幕 en-orig,无说话人标签;转录稿用
>>标换人,归属为编辑判断)
⚠️ 立场:他是 Legora 的 CTO,全部产品效果、客户反响与规模陈述为自述、无第三方来源。 ✅ 但本页认为这一期的厂商色彩很轻,依据是五处:① 他把自家生意最难看的那条结构性缺陷当成全期的主线自己说出来——"我们看不到任何 trace";② 对"初级律师没了"这个会抬高自家价值的说法直接答"我们看到的不是这样";③ 承认"直到最近做复杂 eval 其实不太值得,因为模型自己会变好",并举了一个"我们什么都没做,70% 变 99%"的例子;④ 对自家 API 战略直接说"我们抗了很久,而且现在也不承诺";⑤ 主动说自己那个"永远只要 20 个工程师"的判断错了。 ⚠️⚠️ 而本页必须标出一处被主持人当场叫住、却整期没有回来的话题(见末节)。
⚠️ 自动字幕的专名问题,本页照录并标为不可确证: - ⚠️⚠️ 公司名几乎每次出现都不同(Lora / Legore / Lorra / Lordu / Agora / Lagora / Luora / Gora / "L space");本页统一写作 Legora。 - ⚠️⚠️ 一个被当作最强档模型的名字 "mythos" 无法确证(出现在"很多法律工作其实并不需要 mythos 级别的智能"一句里);本页照录写法、不作型号采信。 ⚠️ "table one" 疑亦为模型名的讹写。 - ⚠️ "Sonnet 46" / "OP 46"(Opus 46)为他对约九个月前所用模型的称法;"fable"、"Astra"、"Grock"(Grok)照录。 - ⚠️ 被收购公司名 "Zakur" 应为 Cura;"turboper" / "Turbo teams" 应为 Turbopuffer;"M helpful there" 一句疑指 Mistral;两位员工只以 "D" 与 "son" 出现,本页不记姓名。 - ⚠️⚠️ "100" 这个数字在本期出现三次、指向三个不同的东西且转录稿没有消歧:"一池 100 位专家"(legal engineers,[00:10:06])、"我们现在是 100 个工程师"([00:50:27])、**被问"你们现在纽约有多少人"答"100"([01:05:32])。✅ 本页三处分别照录、不合并成一个公司规模数字。
✅ 本页认为这一期值得长期保存的是八处,其中五处是本库此前完全没有的: ① ⚠️⚠️ 一条把"评估权在买方"整条线反过来的结构性约束:"我们基本上看不到任何 trace……我这边完全不知道人们实际在干什么",而原因是"他们手上很多数据甚至不是他们的,是他们客户的"。 ② ⚠️⚠️ 一条来自买方、关于模型发布的可靠观察,而它正好咬住昨天那期的 eval 调查偏差:"确实有很多次模型发布是改善了一些、同时在另一些上回退了。而这件事发生的频率比你以为的高得多。" ③ ⚠️⚠️ 一条关于合伙制为什么挡着知识沉淀的分析,而它是一条可被检验的制度性论断:合伙制存在是因为"你没法拥有人力资本",而"合伙人一离开合伙制,就拿不到他们建起来的那些资产的任何分红"——于是没人有动机去沉淀。 ④ ⚠️⚠️ 一条对"买一家律所来拿数据"的直接反驳,而理由是输入与输出的不对称:"你拿到的是全部真实的输入,这很好。但输出就难办了,因为你只拿到最终结果……你得反过来把他们是怎么走到那儿的逆推出来。" ⑤ ⚠️⚠️ 一个本库此前没有的产品问题:"agent 能不能就是 API?" 与 "我们产品里有多少可以就是那个 agent,而不是其它所有东西?",以及他给的两条拦路理由。 ⑥ ⚠️ 一条脚手架半衰期的买方版本,且他是正面承认的:"直到最近,做真的很复杂的 eval 其实不太值得,因为模型就是都变好了" + "我们什么都没做,从大概 70% 变成 99%" + "随着模型变化,我们一直在改我们围着它搭的那套脚手架"。 ⑦ ⚠️ 一条很干净的岗位定义:"legal engineer 像一个高级用户那样配置产品,他们不写代码;forward deployed engineer 往生产里写代码。" ⑧ ⚠️ 一条对"模型厂商会不会下场把我们掐掉"的否定回答,而理由不是能力而是深度:"他们永远不会做到我们这么深。"
一、⚠️⚠️ 全期的主线:一家看不见自己 trace 的 agent 公司¶
([00:26:18]–[00:28:20])✅ 本页认为这是全期最该被长期保存的一段,而它也是本期真正的标题(YouTube 原标题就是 "Building Legal Agents When You Can't See the Data")。
- ⚠️⚠️ 他是在被问产品指标时自己把这条拐出来的:
"因为有一件事可能挺有意思——这对我们的生意来说很难:我们基本上看不到任何 trace。我们看不到任何数据,因为它全都是高度机密的。而这在工作时极其令人沮丧,因为你基本上不知道人们在做什么。所以就是:这里有一个 agent,它能做那么多惊人的事,而我这边完全不知道人们实际在干什么。"
- ⚠️⚠️ 而主持人问"你们难道没跟律所签个协议吗"时,他给的理由把这件事从商务问题变成了结构问题:
"我倒是希望。但问题是,他们手上很多数据甚至不是他们的,是他们客户的。"
- ✅ 本页标注这条为什么不可能靠谈判解决:⚠️⚠️ 数据的所有权不在他的客户手里,所以即便律所愿意给,它也没有权利给。这与"客户不信任我们"是完全不同的一类约束,而本库此前的材料里没有这一类。
- 于是 eval 变成了一件反向工程的事:"所以我们基本上有一个 eval 团队,在试着近似我们认为大家在做的事,然后把那个建进 eval 集里。" ⚠️ 他对这件事的定性是:"这就是这门生意一个烦人的怪癖。"
- ⚠️⚠️ 而本页认为这一段与本库既有材料构成一次正面反转,值得单独记:🔗 本库此前把"评估权在买方"当成一条反复出现的结构性优势——Retell AI 的企业采购即事实 benchmark、Decagon 的自建 eval 是应用层真实门槛,而两天前 Arca 更把它推到极致——"那是我们作为这门生意本身、而不是一家 SaaS 公司的另一个优势——我们有能力要求他们给我们反馈。"** ⚠️⚠️ 而这一期是同一条轴的另一端:卖软件给受托保密的专业机构,意味着你连自己产品被怎么用都看不到。 ✅ 本页的归纳:Arca 的"我们就是那家机构本身"所买到的那样东西,在这一期被精确地标出了价格——它不是销售效率,而是可观测性。
⚠️ 在看不见的前提下还能做什么:三条他明确说可以的,和一条明确说不可以的¶
([00:27:18]–[00:28:20]、[01:00:29])
- ⚠️⚠️ 主持人提了一个具体方案(用 LLM 改写成合成样本:改掉所有名字与细节但保留结构),而他的回答给了一条很有用的尺度:
"这个总是有一个范围的。如果你一路改写到只剩三个取值、然后你从里面挑一个,那显然没问题。如果你只是把名字去掉,那大概就不行。"
- ⚠️ 而他们的选择是取最保守的一端:"我们一般挑最安全的做法,尽可能地限制自己,因为应该一点风险都没有。"
- ✅ 可以做的三件事:
- ① 失败模式归类([00:28:20]):"但有些东西是这样——我们知道失败模式大概就是这 10 个或 20 个。所以我们可以把它归到其中一个里,而那是一个有用的信号。"
- ② 任务类型与业务领域(practice area)归类:"我们也可以把它归到任务类型和业务领域里,然后我们就有个大概的概念。"
- ③ 在线 eval 用极廉价模型打一个总分([00:26:18]):"我们也做某种在线 eval,就是试着大致判断——我们这次把问题解决了吗?就用一个超便宜的 LM 消息,试着拿到一个在线指标。" ✅ 用途是灰度对比:"我们上新东西的时候就按 feature flag 比一下:它是改善了,还是灾难性地下降了。"
- ⚠️ 而拿到真实样本的唯一通道是客户主动配合,且触发条件是客户自己也疼([01:00:29]):"如果他们愿意配合——他们会说,嘿这个对我们超重要而且效果不好——那我们就说,太好了,你能把文档和 prompt 之类匿名化一下吗?如果我们能复现出来,我们就能修。"
- ✅ 本页标注这组方法的性质:⚠️⚠️ 三条可做的事有一个共同点——它们都是把高维的 trace 压成低维的类别标签,于是信息量被主动降到隐私可接受的水平。本页认为这是一条可以直接搬用的模式:在不能看原始数据的场景里,可观测性的设计目标不是"拿到数据",而是"设计一个足够粗、但仍可行动的分类空间"。
二、⚠️⚠️ 一条来自买方的模型发布观察:改善与回退同时发生,且比你以为的频繁¶
([00:08:05]–[00:09:06])✅ 本页认为这是本期第二条最该被 评估与 Benchmark 长期保存的材料。
- 他们的度量设施:"我们有一个团队就专门做 eval。我们追踪所有模型在不同业务领域(也就是法律的各个子领域)和那些领域里不同任务上的表现。所以我们基本上有一张很大的热力图。"
- ⚠️⚠️ 而那条观察是:
"然后我们能看到它们在动,而通常它们会改善大多数东西。但确实有很多次模型发布,是改善了一些、同时在另一些上回退了。" ⚠️⚠️ "而这件事发生的频率比你以为的要高得多。"
- 🔗 ✅ 本页标注这条与昨天那期的咬合,因为两者合起来才是完整的一件事:⚠️⚠️ Joseph Kim(OpenAI)在 10-31 指认了卖方侧的调查偏差——"数字看起来好,研究员就假定模型变强了,然后不去调查它"。而这一期给了买方侧的对应观测:有一张跨领域×跨任务的热力图的人,看到的回退"比你以为的频繁得多"。 ✅ 本页的归纳:卖方的指标是聚合的、且只在下降时被调查;买方的指标是分格的、于是能看见聚合值掩盖掉的回退。这两条不是互相印证的轶事,而是同一个机制的两端——聚合度决定了什么样的退化可以被发现。
- ⚠️ 而他对"模型够不够好"给了一个分布式的回答,本页记为买方的能力充分性证词([00:07:03]–[00:08:05]):
"这是一个幂律分布。所以大概有 60% 的工作,我们现在就能做得非常好,而从现在起那就是个成本和延迟的问题了。但剩下那部分,尤其是非常复杂的分析,我们还需要更多智能。"
- ✅ 他还补了一句本页认为很重要的限定:"而且工作本身大概也会随着智能一起扩张。"
- 🔗 ⚠️ "对已经够用的那 60% 来说真正的变量是成本与延迟"与 Arca 那条"它太慢了,而且花了很多钱" 同向;✅ 本页认为两条合起来支持同一个判断:在相当大一部分专业工作上,买方的选型函数已经从能力切换到了单位成本与延迟。
- ⚠️ 而九个月前欠缺、现在好了的那一项他说得很具体([00:08:05]):"子 agent 委派是其中一个,我们现在把它跑得很好了——用于那种 fan out 式的检索查询,现在对我们来说效果极好。而以前这很难。"(⚠️ 他把当时用的模型称作 "Sonnet 46" / "OP 46"。)
⚠️ eval 环境长什么样:按项目建成"RL environment"¶
([00:09:06]–[00:10:06])
- ⚠️⚠️ 结构是按真实工作的交付物反推的:"有不同的……基本上像一个个世界,本质上就是 RL 环境。因为律师的工作差不多总是以项目为单位。所以就是:这里有一个 10,000 份文件的数据室,你在做一次尽职调查,而最后那份报告应该长这样——它包含所有这些红旗,而且它不包含那些奇怪的东西,而且我们希望它简洁,等等等等。"
- 任务被拆开分别评:"所以有不同的任务——一部分是起草报告:草稿看起来好不好?它包含所有该有的东西吗?措辞站得住吗?分析站得住吗?还有一部分是找出红旗,也就是在那之前的分析。"
- ✅ 本页标注这个拆法与第一节的约束是配套的:⚠️⚠️ 因为看不到真实 trace,eval 必须从"交付物应该长什么样"这一端重建,而不是从"用户实际怎么用"那一端采样。于是"报告该包含什么、不该包含什么、该多简洁"成了唯一可被规定的锚点。本页认为这解释了为什么他们的 eval 团队必须一半是律师。
⚠️ eval 团队的人员构成,以及一个本库值得记的招聘瓶颈¶
([00:10:06])
- 团队:"3 个工程师和 3 个律师,是一个团队。"
- ⚠️⚠️ 外加一池 legal engineers:"在大所干过大概三四年、通常可能还有一个 CS 学位、非常 tech forward 的人",⚠️ 而他对招聘难度的定性值得记:"那是我们最难招的人。但他们也是巨大的力量放大器,因为 eval 和产品开发我们都能调用他们——你有一池 100 位专家,他们每天用这个产品、每天去跟客户谈,而且他们就活在这件事里、过去也活在这件事里。"
- ✅ 本页标注这与本库既有材料的关系:🔗 Joseph Kim 为同一个缺口新设了 subject matter expert 岗位,理由是"训模型的人自己懂什么叫好代码,但到金融我们没有那个优势";🔗 Arca 把知识库交给领域专家而不是工程师。 ⚠️⚠️ 而这一期给的是同一现象的第三个版本,且它把稀缺性量化了:这个交集(大所执业经历 + CS 学位)是他们最难招的岗位。 ✅ 本页的归纳:三期分别来自模型层、应用层与垂直应用层,而三者都把"领域 taste 的携带者"指认成瓶颈——本库认为这已经足够构成一条稳定的结论,而不是三个巧合。
三、⚠️ 脚手架的半衰期:买方自己正面承认的一次¶
([00:11:08]、[00:58:29]–[00:59:29])✅ 本页认为这是本库"脚手架半衰期"那条线上第一个由应用层正面承认、且不带防御的样本。
- ⚠️⚠️ eval 团队本身的出现时点就是一条证据([00:11:08]):
"我觉得直到最近,老实说做这个其实不太值得——因为模型就是都变好了。所以就是:我们要花很多时间做真的很复杂的 eval,还是我们就去建?因为把 harness 做得更好能拿到的收益太大了,而且某种程度上就顺着'一切都会改善'这件事去,然后一切也确实都改善了。"
- ⚠️⚠️ 而那个例子很干净:
"我们有一个问题,是它不能正确地标引用,所以很难溯源。结果下一个模型发布就解决了。它从大概 70% 变成了 99%。我们什么都没做,而且挺好的。"
- ⚠️⚠️ 另一处是脚手架本身在反复被重写([00:58:29]):他说长文档推理仍然困难——"你有一份很大的合同,你在跨着它做修改,这对今天的模型来说都很难:要记得你在上面改了这些东西,定义变了,顺序变了,等等";最朴素的做法是一次性全喂进去一次性输出,"你不会那么做。你把它切成块,然后编排修改"。✅ 而他对此的总结是:
"而这就是在这个行业里挺有意思、挺好玩的那类事。我们的 Word 插件就是——我们做过 map reduce,我们改过,有过一个大的,有过好几次大的。就是随着模型变化,我们一直在改我们围着它搭的那套脚手架。"
- 🔗 ⚠️ 而主持人给了一个方向相反的一手经验([00:58:29]–[00:59:29]):"我最近从 map reduce 转成了全部丢进 context,而且它更好。"
- ⚠️ 他对切块的具体代价说得很准([00:59:29]):"有些文档会就某件事连着讲两页左右,而每一个单独的块都不见得与检索词相关,但它们合起来极其相关。" ✅ 本页标注这条是 chunking 失效的一个可检验的形状,而不是泛泛的"切块损失上下文"。
- 🔗 ✅ 本页标注这与本库既有材料的位置:本库此前的半衰期材料是——Serval 的示例库被模型吃掉、Lovable 的 skills 被模型吃掉、Anthropic 的"智能看起来越来越饱和"。 ⚠️⚠️ 而这一期补上的是最有行动含义的一条:他把"该不该投入建复杂 eval"这个决定,明确地当成了与模型进步赛跑的一个时点判断,而他的答案在 2026 年之前是"不该"。 ✅ 本页认为这比"脚手架会过时"更具体——过时的不只是脚手架,还包括测量脚手架的那套设施,而后者的投入时机本身是一个可以判断错的决策。
四、⚠️⚠️ 合伙制为什么挡着知识沉淀:一条可被检验的制度性论断¶
([00:14:09]–[00:16:10])✅ 本页认为这是全期最原创的一段,而且它与本库既有的律所经济学材料不重叠。
- ⚠️⚠️ 他先给了合伙制存在的理由,而推理链很短:
"合伙制之所以存在,差不多是因为这些公司唯一拥有的那类资本就是人力资本。不像我们、不像一家软件工程公司、不像一个制造商——你有实物资产、或者某种随时间累积的无形资产,而它们给股东付股息。但如果你在专业服务这样的行业里(咨询之类也一样),你全部的价值都在你的人身上,而你没法真正拥有人力资本。" ⚠️ "你没法拥有人,奴隶制已经被废除了。但你可以租他们——你付他们钱。所以合伙制本质上是一种结构:你把人力资本变成公司的所有者,这样他们就留下。"
- ⚠️⚠️ 而 Legora 想做的事正好是给律所造出一种它从来没有过的资产([00:15:10]):
"我们真的想用 Legora 做的,是让律师、让律所能够建起某种无形资本、某种持久的资本——你可以建一个会学习你们怎么工作的系统。" "现在很多律所会想:好,有'我们这家律所的做事方式',而我认为我们可以把它编码下来。我们可以建一个系统,不管那是一张自我改进的知识图谱还是别的什么,加上先例文件和文档——那里有一种做事方式,它产出真的很好的结果,而那可以成为他们的 IP。"
- ⚠️⚠️ 然后主持人追到了激励问题上,而他给的回答是本页认为这一段最值钱的部分:
"因为你是靠'吃你杀到的'或者 lockstep 之类拿到回报的……这个得变一点。我们需要搞出一种激励结构,让合伙人有动力去把东西编码下来、为公司建一项资产。但现在他们没有动力——因为他们一旦离开合伙制,就拿不到他们建起来的那些资产的任何分红。"
- ⚠️ 他对自己这段的定性是"我们再看吧":"我觉得整个商业模式……我们再看吧。"
- ✅ 本页标注这条论断为什么值得长期保存,以及它为什么可被检验:⚠️⚠️ 它不是"律所抗拒变化"这类态度解释,而是一条关于产权的解释:知识沉淀需要有人承担当下的成本、而收益归属于一个他离开后就不再分配给他的资产。于是这条论断给出了一个明确的可检验推论——如果有律所真的开始大规模沉淀知识,那么它的合伙人分配机制里应该先出现对应的改动。本页认为这个推论比任何关于 AI 采用速度的预测都更容易被观察到。
- 🔗 ⚠️⚠️ 而它与本库既有材料正好接上另一头:Eve 在 10-30 把原告律师业的瓶颈指认成供给约束与 5,000 美元费用线;Legora CEO 在 2026-07 说"法律服务 1 万亿/年但软件只占 4%"、并把 billable hour 的颠覆当成前提。 ✅ 而这一期指出的是:即便需求与定价都松动了,知识沉淀这一步仍然卡在合伙制的产权结构上——本页认为这是本库目前对"为什么法律行业的知识资产一直没有被建起来"最具体的一个解释。
⚠️ 配套的计费侧观察,以及他当年劝退 CEO 的那条理由¶
([00:18:11]–[00:20:11])
- ⚠️⚠️ 他自述当年给 Max 的 YC 申请提的反对意见,本页认为这条是整期最好的一个"为什么这次不一样"的反面陈述:
"我的反馈是:这件事人们已经试过一百万次了。legal tech 从来没成过,因为律师没有动机去提高效率——他们会赚得更少。这根本说不通。"
- ⚠️ 而他给的改变原因是外部压力而不是内部意愿:"但我认为律师现在确实想采用这个,是因为他们明白了形势的严重性。他们知道商业模式和一切都在承压。他们必须变,因为竞争压力太高了。"
- ⚠️ 计费模式已经在动([00:19:11]):"计费模式本身我认为也会变。我们已经在看到,特别是在美国,一堆东西实际上是按项目费而不是按小时费定价的"——"特别是谱系上偏低端的那些,比如小规模的审阅之类。老实说其中一部分现在是免费做的,还有一部分就是按一个固定价。"
- 钱转去哪里:"诉讼里大的活仍然在那里而且非常值钱,所以律师会把更多时间花在那里。" ⚠️ 外加客户关系——"很多律所会、或者历史上一直会为了维持跟客户的关系基本上免费做些事",✅ 而 AI 改变的是它的成本:"所以现在他们还能那么做,但不必在上面亏很多钱了。"
- 🔗 ⚠️ 本页标注这与 Eve 的结果定价 不是同一件事:Eve 谈的是把定价挂到结果上;这一期描述的是低端工作的定价正在塌成固定价或零,而价值向战略与诉讼侧集中。 ✅ 本页认为两条可以并列,因为它们描述的是同一个行业里不同层级的两种定价迁移。
⚠️ 对"初级岗位没了"的直接否定¶
([00:16:10]–[00:17:10])
- ⚠️⚠️ 主持人给的是一个会抬高他产品价值的说法:"初级律师助理没了。初级律师没了。我不需要他们了。"
- ⚠️ 而他的回答是直接否定:"那其实不是我们看到的情况。"
- ✅ 本页标注这是一处对自己不利的让步,因为"我们消灭了初级岗位"恰恰是这类产品最有力的销售说法。
- 他给的替代判断是分化而不是消失:"总体上你还是需要下一代人。而至少在工程上,我的想法是:你今天有一个好工程师,他比两年前值钱得多,因为他能产出多得多的东西。而我觉得法律里是同一件事——如果他们好,他们确实能做很多真的很好的工作。所以我更倾向于说,真正好的初级律师值钱得多了。"
- 🔗 ⚠️ 主持人在同一段里把工程侧说得更重("初级工程师基本上是熟了"),✅ 但随即自己收回了力度:"我觉得我有点为了搞笑而夸张了。" ⚠️ 本页照录两边,并标注工程侧那句是主持人的印象、无数据。
- ⚠️ 而术语侧有两处本页记为行业用语的材料([00:21:13]):"legal engineer"(他说这现在也成了行业用语)、"CSJDs";⚠️⚠️ 以及一个贬义词 "meat proxy"——"你就坐在机器前面,把别人叫你打的东西打进去,然后把机器告诉你的话重复出来"。✅ 而他对它给了一个反转:"但我确实觉得,一个非常好的 meat proxy 就是——你很懂 agent、你很懂 Legora,你知道怎么……这是我的工具箱,而每个行业都有一个工具箱,我能用我的工具去做你需要我做的事。" ⚠️ 主持人当场接:"那你就不是 proxy 了,你其实就是在做有意义的工作。"
五、⚠️⚠️ "agent 能不能就是 API",以及一套靠少数 primitive 撑住的产品策略¶
([00:47:26]–[00:51:27]、[00:38:24]–[00:42:25])
⚠️ 先记 API 战略本身:抗了很久,而理由是版本维护¶
- ⚠️ 他对"会不会把产品全部表面开放成 API"直接给了否定([00:47:26]):"那不是我们现在承诺的事。我们确实有 API 可以对着建,但不是产品的全部表面。"
- ⚠️⚠️ 而抗拒的理由很具体:"我们大概六个月前才开始做我们的 API。我们抗了很久。主要是因为——我就是不想因为要为一个我们已经改掉的数据模型维护旧 API 版本而被拖慢。" ✅ 而他说清了这个判断是规模相关的:"现在我们更大了,情况不一样,所以这是一个我们能承担的成本了。但当我们是 20 个工程师的时候,我们动得太快,根本做不了这个。"
- 🔗 主持人把它接到 Bezos 的 AWS mandate 上([00:48:26]):不许走后门,你只能把你给客户的那同一套 API 给别的团队;没有就去建。 ⚠️ 而他给的回应是组织结构版本:"一般来说所有公司都该有一个平台团队和一个产品团队……甚至 agent 你也可以这么想:有一个 harness 团队在跑那个 agent,然后你可以在它外面建产品——用 skill、automation 之类。"
⚠️⚠️ 而那个问题本身是本库此前没有的¶
([00:49:26])✅ 本页认为这是本期最值得单独引用的一条产品判断。
⚠️⚠️ "我觉得这个也在稍微变。现在很多 API……我们在琢磨的一件事是:agent 能不能就是那个 API?我知道这听起来很怪,但对这里面有些东西,他们真正想做的事就是触发某些事情发生。" ⚠️⚠️ "显然这比你有一个一直打的 API 要低效得多……但我在脑子里琢磨的是:我们产品里有多少可以就是那个 agent,而不是其它所有东西?"
- ⚠️ 而他给了两条拦路理由,本页认为这两条正好是边界:
- ① 资源不设界:"无界的执行、成本和延迟。"
- ② 非确定性:"还有确定性——可能一百次里有两次它会干出我们不想要的离谱事。"
- ✅ 本页标注这条为什么值得保存:⚠️⚠️ 本库此前关于"agent 取代什么"的材料都在讨论它取代人的工作;这一条问的是它能不能取代集成接口本身——也就是把 API 这一层整个换成自然语言触发。而他自己给的拒绝理由(不设界的成本 + 2% 的离谱率)恰好说明了这件事今天为什么不成立,而它们都是可量化的、会随时间变化的。 🔗 ⚠️⚠️ 与 Arca 的"所有安全限制都完全是确定性的,把决策权从 agent 手里拿掉" 正好相对:✅ 本页认为两者描述的是同一条光谱的两端——Arca 的做法是把 agent 的输出强制降格成受约束表示,而"agent 即 API"是把受约束表示整个取消。而两期给出的障碍是同一个:非确定性。
⚠️ primitive 策略,以及一个与 Arca 同形的"一套设施两种用途"¶
([00:38:24]–[00:42:25])
- 核心 primitive 他明确列了三个([00:41:25]):lists(可配置)、projects("基本上是文件的容器、文件系统")、agent("当然,你可以把它拉起来,并且以非常不同的配置去跑");⚠️ 而 tabular view 他自己说"我们在考虑它其实是不是一种实例化"。
- ⚠️⚠️ lists 的性质是通用而不是法律专用:"lists 是一个很好的 primitive,因为它本质上极其灵活。它就像一个 Notion 数据库。" 可以挂 trigger 与 automation,✅ 而他对它的定位是胶水:"它就像一个把所有东西粘起来的很好的胶水,因为你可以基于一个 list 在某件事发生时拉起一次 agent 运行,然后它回来填一个字段、或者加新文档。"
- ⚠️⚠️ 而那句概括本页认为该记:
"就像你可能用 Linear 或某种任务管理工具去协调一堆 coding agent,我们可以用 lists 做类似的事。所以 agent 能创建 list,list 能创建 agent,agent 能读 list。于是这个 agent 蜂群就活起来了。"
- 🔗 ✅ 本页标注这与 Arca 的"审计日志同时就是 agent 的事件总线" 是同一种设计手法的两个样本:⚠️⚠️ 两家都把一件为别的目的建的设施(那边是合规审计日志,这边是任务管理数据结构)复用成 agent 的协调基底,于是人的动作与 agent 的动作走同一条总线。 ✅ 本页认为这已经可以归纳成一条:多 agent 系统的协调层倾向于长成一个既有的工作流对象,而不是一个新的消息队列。
- ⚠️ 而 lists 的第二个用途是内部的产品工厂([00:40:24]):"就算我们不把它暴露给终端用户也需要这个灵活性。假设这全是内部的,那它就是一条让我们的人——比如我们的 legal engineer——极快地建出大量产品的路径。" 具体形态是自带 generative UI 的定制看板,✅ 而他的类比是:"所以有点像 Legora 内部的一个 Lovable。" ⚠️ 设想是一个由 legal engineer 建出来的专用产品市场。
- ⚠️ 收购 Wexler(英国)带来的 fact intelligence 被他当成同一 primitive 上的建造([00:40:24]–[00:41:25]):诉讼向——"你为一场官司上传一百万份文档,我们用命名实体、日期之类把事实抽出来,然后当你拿到所有事实,你基本上可以把它们互相对照,看哪些被佐证、哪些是互相矛盾的";⚠️⚠️ 而他给的用法很具体:"你也可以把一场庭审转录下来,然后就是:哦,他说了这个事,但其实这边这封邮件……"
⚠️⚠️ "20 个工程师到永远":一次他自己说出来的判断错误,以及由此来的工作定义¶
([00:50:27]–[00:51:27])
- ⚠️⚠️ 他主动讲了一张自己做的片子:"我在 Legora 待了半年之后,有一次我把斯巴达三百勇士那张图拉出来,然后我说:我们接下来整个公司历史都只会是 20 个工程师,而我们会打赢所有比我们大得多的人。" ⚠️ 而结果是:"我们现在是 100 个工程师,而且感觉我们还是太小了。"
- ⚠️ 他对自己那个立场的否定理由不是理念而是竞争:"我本来想那么做,但在真实世界里我们处在激烈竞争中。人们想要的东西太多了……我本可以当个清教徒、说不行我们必须保持 20 人、我们只能建这些。但那我们就输了,而人们会去别处。"
- ⚠️⚠️ 而他由此给出的工作定义,本页认为是本期最该被产品侧引用的一句:
"所以我的工作是搞清楚:我怎么建一个系统,让我们能建很多东西——但实际上客户感觉我们建了超多东西,而我们其实只建了很少几样。"
- ✅ 本页标注这正是上面 primitive 策略的目标函数,于是那套 primitive 不是架构偏好,而是对"既要广度又要小团队"这个约束的直接回应。
- ⚠️ 而他说他们几乎不做试探性产品,理由是需求过载([00:51:27]):"我们没试过任何我们本来没有很大信心的东西,主要因为我们就是有一座需求的大山。" ✅ 两处例外(逆客户需求的战略赌注)他点了名:agent 本身——⚠️⚠️ "其实没人在要这个。'我希望我在用的这个助手有更多 agency、在我不叫它的时候就去做事'——从来没人这么说过。但我们就是觉得这绝对是行业要去的方向。"——以及协作("行业要去的地方是你能在你工作的地方里协作,也就是 Legora 里,而不是在邮件和短信里")。
六、⚠️ 受监管行业的工程现实:Azure-only、DPA 名单,以及"够好就行"的选型函数¶
([00:28:20]–[00:32:20])✅ 本页认为这一段的价值在于它把"合规是货币"从口号落成了几条具体的约束。
- ⚠️⚠️ 基础设施全在 Azure,而理由是客户的既有审批而不是技术:"我们所有基础设施都在 Azure 上。主要就是因为这个——因为我们刚起步的时候,律所说 AWS?不行。完全不可能。" → "他们说亚马逊、谷歌,我们不能把任何数据交给他们。所以我们基本上必须把一切托在微软上,因为他们已经有 365 了。" ✅ 机制是复用既有的供应商审查:"因为他们已经对他们所有文档、所有 Word 之类做过安全审查了。所以在他们心里微软是一个已批准的供应商。"
- ⚠️ 而这件事在两年里变了:"现在人们明白:好,我们需要上云。" ⚠️⚠️ "当时还有很多人在谈 on-prem,那也完全消失了。" ✅ 他对时间尺度加了一句:"但这才只过了三年。"
- ⚠️⚠️ DPA 名单是一条硬约束,而它的后果很具体([00:31:20]):"我们的数据处理协议上供应商非常少,因为我们需要把数据去哪儿这件事守得极紧。" → 所以语音转写不用 ElevenLabs,"因为 DPA 的原因"。
- ⚠️⚠️ 而他由此推出的一条对大平台的评价本页认为值得记:"我觉得这确实是 Gemini 和 OpenAI 这类的一个好处——他们是'你来我们这儿,我们有你需要的大部分东西',而那其实非常有价值。" ✅ 判据被他说得很直白:"即便它不一定是 state-of-the-art,只要它对所有任务都大体够好,谁在乎呢?" ⚠️ "通常它们在 arena 分数上都是前二、前三、前四,而那就够好了。你有全部的治理,而且它超级可扩展,那大概就够好了。"
- ✅ 本页标注这条是对"模型选型"这个问题的一次重新框定:⚠️⚠️ 在受监管行业里,供应商数量本身是一项成本(每加一个就要过一次 DPA),于是"一家供应商覆盖大部分任务"的价值可以超过"每个任务都用最好的模型"。本页认为这是本库第一条把捆绑式平台的优势落在合规开销而不是能力或价格上的材料。 🔗 ⚠️ 而它与 Joseph Kim 那条"把数据买进来自营" 是同一个逻辑的两种落点:两边都在用"减少外部依赖的数量"换别的东西,那边换的是可靠性,这边换的是合规面。
- ⚠️ 而他对模型路由的口径是多目标的([00:30:20]):"就是把我们的客户带上前沿……那张所有模型的地图、它们擅长什么、它们的延迟、它们的成本、它们的治理、它们的区域可用性。我们怎么在这一切上面做优化?" ✅ 三档并存:"有些开放权重模型对某些任务很好,我们就在那儿用;有些我们会做后训练;有些就直接用前沿模型。"
- ⚠️ 他自述年初是"坚定的 Anthropic",⚠️ 并点名 Grok 在大幅改善;⚠️⚠️ 而那个"总体不强但某项极好"的例子是:"某个早期的 Gemini,对某些类型的转录和说话人归属极其好。" ⚠️ 他另点名微软的转写模型"比旧的 Gemini 更好"。
- ⚠️ 一条很具体的领域转写失败([00:32:20]):在澳大利亚有一个法庭上对某类人的特定称谓,模型"一直把它转写成 condom"。 🔗 ⚠️ 主持人给的对策是本库可直接搬用的一条工作流:"通常你在它上面跑一层 LM,抽出一些关键词,然后带着关键词再跑一遍转写模型。" ✅ 而他加的那句一般化本页记:"如果你在任何大规模上做过这件事,你会在任何不是普通日常对话的领域上捡到一大堆一大堆的转写错误。"(⚠️ 他举的自嘲例子是 Whisper 与 ElevenLabs 仍然把 Claude Code 转写成 "cloud code"。)
⚠️ 两个岗位的定义,以及 FDE 怎么在摸不到数据的前提下交付¶
([00:42:25]–[00:46:25])
- ⚠️⚠️ 分界他说得极干净,本页认为这是本库目前对这两个岗位最清楚的一条定义:
"legal engineer 像一个高级用户那样配置产品。他们不写代码。" "而一个 forward deployed engineer 基本上是往生产里写代码。"
- 分层的用法是"一线二线"([00:43:25]):"legal engineer 应该能定制很多东西、建出很好的体验;而他们做不到的地方、或者我们需要改核心产品、做定制集成之类的时候,我们有 forward deployed engineer。" ⚠️ 而 FDE 会在产品与客户之间轮转。
- ⚠️ 时间线与背景:第一位 FDE 是他们在纽约的第一个 hire、也是一位 YC 创始人,"大概九个月前,我其实不太确定";背景画像是"创始人、常规工程师",⚠️ 他举的那位是"两家 YC 公司,在 Meta 做过搜索"。
- ⚠️⚠️ 而第一节那条约束在这里又出现了一次,本页认为这是本期一处很好的内部一致性([00:45:25]):被问 FDE 怎么在客户项目上工作,他答:"他们仍然不碰数据。所以他们只是把系统建起来。" ⚠️ 例外是偶尔会被当成员工入职("他们可能会拿到一台笔记本之类"),但"这不太经常发生"。
- ⚠️ 他明确说还没有 Palantir 那种制度([00:46:25]):被问有没有"四天驻场一天回来反哺产品"的规则,答 "没有,我们没有。老实跟你们说,这一切还都在很早期。" ✅ 方向是:"我确实觉得会变成——也许不完全像 Palantir,但我们会有一个更大的、在不断轮转的 FD 组,可能跟一个客户坐两个月把某一件事建出来,然后去下一个。"
- ⚠️ 欧美客户差异([00:24:16]–[00:25:18]):"欧洲的动得慢一些。美国的非常前倾、动得非常快。" ⚠️⚠️ 而差异的形态是定制意愿:"美国公司,无论是企业还是律所,对自己定制搭东西的胃口也大得多"(例子:自建 CRM、自建文档管理系统,以及"你在 Salesforce 里做一次审阅,它去到某一个人那里,他做点什么,然后进 Legora,再回去"这类触发链);而欧洲的"更倾向于就拿现成的"。 ⚠️ 他对最激进的那类定制明确拒绝:"有些极其有野心,是他们想跟我们一起建一个全新的产品,而那个我们真做不了。" ✅ 他同时否认这是因为威胁感不同:"我不知道定不定制是不是因为这个原因。我认为他们都知道这对律所和企业的成功极其重要。"
七、⚠️⚠️ 与本库既有 Legora 材料的时间线对照,含一处本库此前读错的事实¶
([00:52:27]–[00:54:28])✅ 本页认为这一节是本期对本库最有价值的部分之一,因为它直接修正了一条本库此前写下的断言。
- ⚠️⚠️ 微调的真实状态:主持人问"你们早期不自己微调模型,现在还是这样吗",他的回答是——
"是的,到现在为止我们一个模型都没微调过。" "我觉得现在,过去这几个月,开放权重模型变得极其能干了,所以对某些任务我们会做——那些我们认为'一个前沿模型在那个成本和延迟下能做到的'与'一个后训练过的模型能做到的'之间有巨大差值的任务。"
- 他给的那个任务是法律检索:"这是一个 fan out 检索问题,而你可以让一个真的很有效的模型以很低的延迟、超快超便宜地跑那些查询。"
- ⚠️ 范围他划得很窄:"我们不是想训我们自己的 fable 来当那个主 agent。我觉得那个我们赢不了,对上 Anthropic 大概赢不了。"
- ⚠️⚠️ 而本库必须记下这与自己此前的记载不一致:本库的 Legora CEO 页(2026-07) 写的是"不做通用法律智能模型,只做窄任务微调模型降本降延迟(如 tabular review 万次调用用微调抽取模型)",读起来像是当时已经在用微调模型。 ✅ 本页的处理:按 CTO 这条一手且对自己不利的陈述("到现在为止我们一个模型都没微调过")修正时间线——那是一条路线主张,而落地发生在 2026 年下半年、且范围被收窄成检索一类的限定任务。 ⚠️⚠️ 本页按本库约定不删旧记载,而是在两处都标注时间线;方向性(只做窄任务、不训通用法律模型)两期完全一致,差异只在"已经做了"还是"准备做"。
- ✅ 而本页标注他在同一段里给出的一条优先级判断,因为它对工程侧更有用([00:54:28]):
"但总的来说,甚至在模型之前、甚至在 harness 里,就有一大堆低垂的果实。老实说,如果你只是想为我们的客户做出更好的输出,有太多我们能做、而且立刻就有影响的事,都在训模型之前。"
- ⚠️ 他另点出检索侧还有研究空间,但形态朴素:"搜索和检索研究、或者 RAG 研究还有很多可做的……那也许不那么光彩。它其实甚至不是模型训练。有时候它就是架构和流水线。"
- ⚠️ 本页另记两条与既有 Legora 材料一致、但更具体的:
- 自用做并购([00:22:14]–[00:23:15]):收购 Cura(瑞典)与 Wexler(英国),尽调大量自己用 tabular review 做,⚠️ 但战略部分仍请外部律所("比如在澳大利亚有薪酬相关的事,好,我们是不是想找人更战略地看一下");⚠️⚠️ 而他给了一个不展开的事实:"我们确实有过几次,发现了某个像红旗一样的东西,然后我们踩了刹车。" → 被问细节时直接答 "不,我觉得不行。" ✅ 本页标注这是一处明确的拒答,照录不推测。
- 客户规模谱([00:24:16]):"我们确实是从非常非常大的律所开始的,但 50 个律师的也在用我们,而且拿到很多价值。"
八、⚠️ 引用系统、以及"律师到底有没有在核对引用"¶
([00:56:28]–[00:57:29])
- ⚠️ 他说自己最在意的模型问题是幻觉,而对策是把每一句话绑到可点击的来源上:"我们有一套引用系统,基本上会检查它写的东西有没有一个链接。所以用户有一个链接可以点,它会在 PDF 之类里用一个框高亮出这条信息是从哪儿取的。"
- ⚠️⚠️ 而多层溯源这一点本页认为值得单独记:"如果 agent 是基于一次 tabular review 写了什么,它可以引用 tabular view 里的那个单元格、或者那一行。所以你其实可以往下点好几层,一路验证上来。"
- ⚠️⚠️ 但被问"律师是不是真的在核对这些引用"时,答案是否定的,而主持人补的那句更重:
- 他答:"最初会,但现在……" ⚠️⚠️ 主持人接的是:"那种编出来的最高法院链接。他们不在乎。" → 他承认"这确实会发生"。
- ⚠️ 而他给的类比把它放回了一个既有现象里:"我觉得这就像写代码。你有那种完全不在乎、就是甩 agent 的工程师,也有那种坐下来读每一个逗号的人。" ✅ 他给的乐观版本是选择性核查:"但我觉得他们大概就像我们在 code review 里知道该看什么一样。他们也知道:好,这些是关键的、这是重要的那条,我就重点复核这几样。而这些听起来合理,所以大概没问题。"
- ⚠️⚠️ 而他最后那句把责任框架说清楚了:"就跟你从一个初级律师那里收到东西一样,你做的也是同一件事——我应该复核这个,而这个大概没问题。"
- ✅ 本页标注这组对话的位置,因为它与昨天那期直接对上:🔗 ⚠️⚠️ Joseph Kim 把"安全画像塑造成一个人"当成设计原则,依据是银行的层级复核本来就是为人的错误建的。而这一期给了同一个框架在真实部署里的观测结果:律师确实在按"收到初级律师交来的东西"那套习惯处理 agent 的输出——也就是抽样复核关键项、其余按合理性放过。 ⚠️⚠️ 本页的判断:这既支持了那条设计原则(人确实会复用既有习惯),也正好暴露了本页在昨天那期标出的风险——抽样复核能挡住独立的错误,而"这些听起来合理,所以大概没问题"恰恰是对相关性错误最没有抵抗力的那种复核方式。 ✅ 本页认为这两期放在一起读,才构成一个完整的、带观测的论证链。
- ⚠️ 另记一条模型写作风格的买方评价([00:56:28]):"fable 和[另一个]绝对非常话多……非常冗长。" ⚠️ 他对此的评价是"这一般来说不好",而"Astra 写东西挺好,简洁得多";⚠️⚠️ 他补了一句本页认为重要的限定:"但话多/冗长这件事对我们来说其实有点难办。" ✅ 本页标注这意味着风格问题不是靠 prompt 就能压掉的——而这是一条可被别人复测的说法。
- ⚠️ 他说厂商都知道这些:被问"他们都有跟你们的 Slack 频道、你会告诉他们这些吧",答"不不,他们知道这些"。
九、⚠️⚠️ 对"买律所拿数据"的反驳,以及对"模型厂商会不会下场掐掉我们"的否定¶
([01:00:29]–[01:03:30])
⚠️⚠️ 输入与输出的不对称¶
- 主持人提的方案是"你买一家律所",⚠️ 他先给了一条法律上的不确定:"但那边有一些关于他们的数据到底是不是他们的、还是客户的的事。所以如果客户都走了,那也许就没问题。我其实不知道。"
- ⚠️⚠️ 而真正的反驳在后面,本页认为这是本期第四条最值得长期保存的材料:
"买律所数据的问题是:你拿到的是全部真实的输入,这很好。但输出就难办一些了,因为你只拿到最终结果是什么,而很难搞清楚……你基本上得反过来把他们是怎么走到那儿的逆推出来。" ⚠️⚠️ "所以在我们产品里,当我们拿到真实用户的真实 trace 时,那是极高价值的。但如果我们只是拿到这个输出、而我们不知道它是好还是坏、也不知道它是怎么被做出来的,那就有点难办。"
- ✅ 本页标注这条为什么重要,以及它对本库既有材料的修正作用:⚠️⚠️ 本库记过多条"数据是护城河"的主张(Eve 的数据不可爬、Legora CEO 的"数据要全不要 80%"、以及 Joseph Kim 把数据列为 plugin 生意的秘方之一)。而这一条指出"数据"这个词在这里是两样不同的东西:输入语料与过程 trace。 ✅ 本页的归纳:存量文档买得到,而"怎么从输入走到输出"的过程买不到——于是数据护城河的真正稀缺项不是语料规模,而是带过程的样本。 ⚠️⚠️ 而这恰好让第一节那条约束变成了本期最大的讽刺:他比谁都清楚过程 trace 的价值,而他的生意结构让他看不到它。本页认为这个张力本身是本期最该被记住的东西。
⚠️ 对模型厂商下场的判断:理由是深度,不是能力¶
- ⚠️ 主持人指出在编码领域实验室已经掐过竞争者,"而这发生过两次",并问法律会不会一样。
- ⚠️ 他的回答是否定的,而理由分两层:
- ① 他们必须覆盖知识工作的全部:"他们在知识工作、或者说企业的知识工作里有太多东西要拿下,所以法律必须是其中一部分,就像数据分析必须是、销售、市场、财务都必须是。所以他们必须在那些地方做出好东西。"
- ⚠️⚠️ ② 但深度到不了:"但他们永远不会做到我们这么深。" ✅ 而他对分层给了一个具体的切点:"如果 Claude 拿下小客户、小企业客户,他们有些法务通过 Claude 做,那挺好的,没问题。但如果你在做一笔四亿美元的并购,你会想要 Legora。"
- ⚠️ 他对厂商口风的不信任也记一笔:主持人说"你们的销售代表当然会说不会",他接:"对,那不是他们能定的。而且他们往往根本不知道实际在发生什么。"
- 🔗 ✅ 本页标注这条与同周两期构成一组三方对照,而三者的位置各不相同:⚠️⚠️ Joseph Kim(模型厂商)说"95% 是创业公司也能做的"、并预测会有十亿美元生意建在一个 ChatGPT plugin 之上;Arca(应用层)拒绝 managed agents,理由是"拥有记忆与运营知识就是拥有你的智能";而这一期(垂直应用层)既不拒绝也不依附,判断是"他们必须做,但做不深"。 ✅ 本页认为这一条的可检验性最高,因为它给了一条明确的分界线——交易规模。而"四亿美元并购会来找我们、小企业法务走 Claude"是一个可以在两年内被观察到对或错的预测。
- ⚠️ 而他对两年后的使用形态给了一个双轨答案([01:02:30]):"我觉得两者都会有。如果你是大企业,你可能有 Claude 在用,然后……我觉得这类似于我怎么用 Linear——我通过 Claude 用它,但我还是会去 Linear。我觉得企业会那样。我觉得律所就会直接用 Legora,因为那更简单也更好。" ⚠️ 本页标注后半句是立场陈述、无依据。
十、⚠️⚠️ 一处被主持人当场叫住、却整期没有回来的话题¶
- ⚠️⚠️ 在介绍 tabular view 时他自己带出了一句([00:03:02]):
"我们有一个功能叫 tabular view,这现在也成了行业里在用的名字,而我们很高兴看到 Claude for legal 用我们的术语来称他们在建的东西。"
- ⚠️⚠️ 主持人当场叫住了它:"我们得聊聊这个。我们得聊聊这个。"(转录稿在此处标了笑声与惊呼。)
- ⚠️⚠️ 而本期再也没有回到这个话题。 ✅ 本页必须标出这一点,因为"模型厂商的法律产品是否在直接对位复制垂直厂商的功能与术语"恰恰是第九节那条"他们做不深"判断的最直接反证候选,而它被跳过了。
- ⚠️ 本页的处理:只记录这句话被说过、以及它没有被展开;不推测 Claude for legal 的产品形态,也不把"沿用术语"读成任何更强的结论。
本页认为值得长期保存的¶
| 条目 | 内容 |
|---|---|
| ⚠️⚠️ 一家看不见自己 trace 的 agent 公司 | "我们基本上看不到任何 trace。我们看不到任何数据,因为它全都是高度机密的……这里有一个 agent,它能做那么多惊人的事,而我这边完全不知道人们实际在干什么";⚠️⚠️ 而它不可能靠谈判解决:"他们手上很多数据甚至不是他们的,是他们客户的";于是 eval 团队的工作是"在试着近似我们认为大家在做的事",⚠️ 他的定性是"这门生意一个烦人的怪癖";✅ 本页判这是本库"评估权在买方"那条线的另一端——Arca 的"我们有能力要求他们给我们反馈" 所买到的那样东西,在这里被标出了价格:不是销售效率,是可观测性 |
| ⚠️ 在看不见的前提下还能做什么 | 能做三件:失败模式归到已知的 10–20 个桶、归类任务类型与业务领域、用"超便宜的 LM 消息"做在线总分并按 feature flag 比灰度;⚠️ 改写合成有尺度:"一路改写到只剩三个取值再挑一个,显然没问题;只是把名字去掉,那大概不行",而他们"挑最安全的做法,因为应该一点风险都没有";真实样本只能靠客户自己疼时主动匿名化提供;✅ 本页归纳的可搬用模式:不能看原始数据时,可观测性的设计目标是设计一个足够粗但仍可行动的分类空间 |
| ⚠️⚠️ 来自买方的模型发布观察 | 跨业务领域×任务的"一张很大的热力图",⚠️⚠️ "确实有很多次模型发布,是改善了一些、同时在另一些上回退了。而这件事发生的频率比你以为的要高得多";🔗 ✅ 与 Joseph Kim 的卖方调查偏差 咬合成同一机制的两端——卖方的指标是聚合的且只在下降时被查,买方的是分格的于是能看见被聚合掩盖的回退 |
| ⚠️ 买方的能力充分性证词 | "这是一个幂律分布。大概有 60% 的工作我们现在就能做得非常好,而从现在起那就是个成本和延迟的问题了",剩下的(尤其复杂分析)还需要更多智能,✅ 外加限定"工作本身大概也会随着智能一起扩张";⚠️ "很多法律工作其实并不需要 mythos 级别的智能"(⚠️ 模型名不可确证);🔗 与 Arca 的"它太慢了,而且花了很多钱" 同向 |
| ⚠️ eval 环境按交付物反推,而不是按用户行为采样 | "基本上像一个个世界,本质上就是 RL 环境":10,000 份文件的数据室 + 一次尽调 + 最终报告"包含所有这些红旗、不包含那些奇怪的东西、而且简洁";任务拆成起草报告与找红旗分别评;✅ 本页判这个拆法是第一节那条约束的直接后果——看不到真实 trace,eval 就只能从交付物该长什么样这一端重建,这也解释了为什么 eval 团队必须一半是律师(3 工程师 + 3 律师) |
| ⚠️ 领域 taste 携带者是瓶颈(本库第三个独立样本) | legal engineer = 大所三四年 + 常有 CS 学位 + tech forward,⚠️ "那是我们最难招的人",✅ 但"巨大的力量放大器……一池 100 位专家,每天用产品、每天跟客户谈";🔗 与 Joseph Kim 新设的 subject matter expert 岗、Arca 把知识库交给领域专家 构成模型层/应用层/垂直层的三个版本——✅ 本页判三者已足够构成结论而非巧合 |
| ⚠️ 脚手架半衰期的买方版本,且是正面承认的 | ⚠️⚠️ "直到最近,老实说做这个其实不太值得——因为模型就是都变好了……把 harness 做得更好能拿到的收益太大了";"它不能正确标引用……下一个模型发布就解决了。它从大概 70% 变成 99%。我们什么都没做";⚠️⚠️ "随着模型变化,我们一直在改我们围着它搭的那套脚手架"(Word 插件经历过 map reduce 等多轮);✅ 本页判这比"脚手架会过时"更具体——过时的还包括测量脚手架的那套设施,而它的投入时机本身是个可以判断错的决策;🔗 接 Serval、Lovable、Anthropic 那条线 |
| ⚠️ 切块失效的一个具体形状 | "有些文档会就某件事连着讲两页左右,而每一个单独的块都不见得与检索词相关,但它们合起来极其相关";⚠️ 而长文档推理仍是他点的前沿缺口(跨整份大合同做修改、记住定义变了顺序变了);🔗 主持人给了方向相反的一手经验:"我最近从 map reduce 转成了全部丢进 context,而且它更好" |
| ⚠️⚠️ 合伙制为什么挡着知识沉淀 | 合伙制存在是因为"你全部的价值都在你的人身上,而你没法真正拥有人力资本……但你可以租他们",于是"把人力资本变成公司的所有者,这样他们就留下";Legora 想造的是律所从来没有的那种资产——"一个会学习你们怎么工作的系统"、把"我们这家律所的做事方式"编码成"他们的 IP";⚠️⚠️ 而激励是反的:"合伙人一旦离开合伙制,就拿不到他们建起来的那些资产的任何分红","我们需要搞出一种激励结构";✅ 本页判这是一条产权解释而不是态度解释,且自带可检验推论:真有律所开始大规模沉淀知识,其合伙人分配机制里应先出现对应改动 |
| ⚠️ "为什么这次不一样"的一个反面陈述 | 他当年劝退 CEO 的理由:⚠️⚠️ "legal tech 从来没成过,因为律师没有动机去提高效率——他们会赚得更少。这根本说不通";而改变原因是外部压力不是内部意愿:"他们明白了形势的严重性……竞争压力太高了";⚠️ 计费已在动:低端"按项目费而不是按小时费"、"其中一部分现在是免费做的,还有一部分就是按一个固定价",✅ 而客户关系那类白做的事"现在他们还能那么做,但不必在上面亏很多钱了" |
| ⚠️ 对"初级岗位没了"的直接否定 | 主持人给了会抬高产品价值的说法("初级律师助理没了。初级律师没了"),⚠️ 他答"那其实不是我们看到的情况";判断是分化:"真正好的初级律师值钱得多了"、"总体上你还是需要下一代人";⚠️ 主持人在工程侧说得更重("初级工程师基本上是熟了")但随即自认"有点为了搞笑而夸张了";⚠️ 术语:legal engineer / CSJDs / "meat proxy"(他给了反转:"一个非常好的 meat proxy 就是——这是我的工具箱,而每个行业都有一个工具箱") |
| ⚠️⚠️ "agent 能不能就是 API?" | "他们真正想做的事就是触发某些事情发生……我们产品里有多少可以就是那个 agent,而不是其它所有东西?";⚠️ 两条拦路理由:"无界的执行、成本和延迟" + "可能一百次里有两次它会干出我们不想要的离谱事";✅ 本页判这是本库第一条问"agent 能否取代集成接口本身"的材料,而两条障碍都是可量化、会随时间变化的;🔗 与 Arca 把 agent 输出强制降格成受约束表示 是同一光谱的两端,而障碍是同一个:非确定性 |
| ⚠️ API 战略:抗了很久,理由是版本维护 | "那不是我们现在承诺的事……不是产品的全部表面";"我们大概六个月前才开始做 API。我们抗了很久。主要因为我就是不想因为要为一个我们已经改掉的数据模型维护旧 API 版本而被拖慢";✅ 而他说清这个判断是规模相关的:"当我们是 20 个工程师的时候,我们动得太快,根本做不了" |
| ⚠️ primitive 策略,与一个与 Arca 同形的"一套设施两种用途" | 核心 primitive 三个:lists("像一个 Notion 数据库",带 trigger/automation,"把所有东西粘起来的很好的胶水")、projects(文件容器/文件系统)、agent;⚠️⚠️ "agent 能创建 list,list 能创建 agent,agent 能读 list。于是这个 agent 蜂群就活起来了";🔗 ✅ 与 Arca 的"审计日志同时就是 agent 的事件总线" 是同一手法的两个样本——本页归纳:多 agent 系统的协调层倾向于长成一个既有的工作流对象,而不是一个新的消息队列;⚠️ 第二用途是内部产品工厂("有点像 Legora 内部的一个 Lovable",legal engineer 建专用看板) |
| ⚠️⚠️ "20 个工程师到永远":一次自陈的判断错误,与由此来的工作定义 | 斯巴达三百勇士那张片子:"我们接下来整个公司历史都只会是 20 个工程师,而我们会打赢所有比我们大得多的人" → ⚠️ "我们现在是 100 个工程师,而且感觉我们还是太小了";否定理由是竞争不是理念("我本可以当个清教徒……但那我们就输了,而人们会去别处");⚠️⚠️ 而工作定义是:"我怎么建一个系统,让我们能建很多东西——但实际上客户感觉我们建了超多东西,而我们其实只建了很少几样";✅ 本页判这正是 primitive 策略的目标函数,于是那套架构是对"既要广度又要小团队"的直接回应 |
| ⚠️ 两处逆客户需求的战略赌注 | agent 本身:⚠️⚠️ "其实没人在要这个。'我希望我在用的这个助手有更多 agency、在我不叫它的时候就去做事'——从来没人这么说过";以及协作(把协作搬进工作发生的地方而不是邮件与短信);⚠️ 而他说几乎不做试探性产品,理由是"我们就是有一座需求的大山" |
| ⚠️ 受监管行业的三条具体约束 | ① Azure-only,理由是客户的既有审批:"律所说 AWS?不行。完全不可能"→ 复用微软在 365 上已过的安全审查,⚠️ 而"当时还有很多人在谈 on-prem,那也完全消失了"、"但这才只过了三年";② DPA 名单:"我们的数据处理协议上供应商非常少"→ 语音转写不用 ElevenLabs"因为 DPA 的原因";⚠️⚠️ ③ 由此来的选型函数重构:"即便它不一定是 state-of-the-art,只要它对所有任务都大体够好,谁在乎呢"、"你有全部的治理,而且它超级可扩展,那大概就够好了";✅ 本页判这是本库第一条把捆绑式平台的优势落在合规开销、而不是能力或价格上的材料 |
| ⚠️ 模型路由是多目标的,外加一条"总体不强但某项极好" | 优化维度:能力、延迟、成本、治理、区域可用性;三档并存(开放权重 / 自做后训练 / 前沿模型);⚠️ 自述年初"坚定的 Anthropic",点名 Grok 在大幅改善;⚠️⚠️ "某个早期的 Gemini,对某些类型的转录和说话人归属极其好",⚠️ 微软的转写模型"比旧的 Gemini 更好" |
| ⚠️ 领域转写错误与一条可搬用的对策 | 澳大利亚法庭上某类人的称谓"一直被转写成 condom";🔗 主持人的工作流:"通常你在它上面跑一层 LM,抽出一些关键词,然后带着关键词再跑一遍转写模型";✅ 一般化:"如果你在任何大规模上做过这件事,你会在任何不是普通日常对话的领域上捡到一大堆一大堆的转写错误"(⚠️ 自嘲例:Whisper 与 ElevenLabs 仍把 Claude Code 转成 "cloud code") |
| ⚠️ 两个岗位最干净的一条定义 | ⚠️⚠️ "legal engineer 像一个高级用户那样配置产品。他们不写代码。" / "forward deployed engineer 基本上是往生产里写代码。";用法是"一线二线",FDE 在产品与客户间轮转;⚠️ 第一位 FDE 是纽约第一个 hire、YC 创始人,"大概九个月前";⚠️⚠️ 而第一节的约束在这里再次出现:"他们仍然不碰数据。所以他们只是把系统建起来";⚠️ 还没有 Palantir 那种驻场制度("老实跟你们说,这一切还都在很早期") |
| ⚠️ 欧美客户差异的形态是定制意愿 | "欧洲的动得慢一些。美国的非常前倾",⚠️⚠️ 而差异落在"美国公司对自己定制搭东西的胃口也大得多"(自建 CRM/DMS、Salesforce→Legora→回去的触发链);⚠️ 最激进那类他明确拒绝:"有些极其有野心,是他们想跟我们一起建一个全新的产品,而那个我们真做不了";✅ 他同时否认这是威胁感差异:"我认为他们都知道这对律所和企业的成功极其重要" |
| ⚠️⚠️ 修正本库此前一处读错的事实 | ⚠️⚠️ "是的,到现在为止我们一个模型都没微调过" → "过去这几个月开放权重模型变得极其能干了,所以对某些任务我们会做"(例:法律检索,一个 fan out 检索问题);⚠️ 范围划得很窄:"我们不是想训我们自己的 fable 来当那个主 agent。我觉得那个我们赢不了";✅ 本页据此修正 Legora CEO 页(2026-07) 里"已在用微调抽取模型"的读法——那是路线主张,落地在 2026 年下半年且范围收窄;方向性两期一致,差异只在"已经做了"还是"准备做" |
| ⚠️ 一条优先级判断,对工程侧比模型侧有用 | "甚至在模型之前、甚至在 harness 里,就有一大堆低垂的果实……有太多我们能做、而且立刻就有影响的事,都在训模型之前";⚠️ 检索侧仍有空间但形态朴素:"那也许不那么光彩。它其实甚至不是模型训练。有时候它就是架构和流水线" |
| ⚠️ 引用系统与"律师到底在不在核对" | 每句话绑可点击来源 + PDF 里框高亮,⚠️⚠️ 多层溯源:"如果 agent 是基于一次 tabular review 写了什么,它可以引用那个单元格或那一行……你可以往下点好几层,一路验证上来";⚠️⚠️ 但"最初会,但现在……"+ 主持人补的"那种编出来的最高法院链接。他们不在乎"(他承认确实发生);他的类比是 code review 式的选择性复核:"这些听起来合理,所以大概没问题"、"就跟你从一个初级律师那里收到东西一样";✅ 🔗 本页判这给 Joseph Kim 那条"把安全画像塑造成一个人" 提供了真实部署里的观测——既支持了它(人确实复用既有习惯),又正好暴露本页在那期标出的风险:抽样复核最不抵抗的就是相关性错误 |
| ⚠️ 一条模型写作风格的买方评价 | "fable 和[另一个]绝对非常话多……非常冗长",⚠️ "这一般来说不好";"Astra 写东西挺好,简洁得多";⚠️⚠️ 而限定很重要:"话多/冗长这件事对我们来说其实有点难办"——意味着不是靠 prompt 能压掉的,而这可被复测 |
| ⚠️⚠️ 对"买律所拿数据"的反驳:输入与输出不对称 | "你拿到的是全部真实的输入,这很好。但输出就难办一些了,因为你只拿到最终结果是什么……你基本上得反过来把他们是怎么走到那儿的逆推出来";⚠️⚠️ "在我们产品里,当我们拿到真实用户的真实 trace 时,那是极高价值的。但如果我们只是拿到这个输出、而不知道它是好还是坏、也不知道它是怎么被做出来的,那就有点难办";✅ 本页判这修正了本库多条"数据是护城河"的主张——数据在这里是两样东西(输入语料 vs 过程 trace),而真正稀缺的是后者;⚠️⚠️ 而这让第一节成了本期最大的讽刺:他比谁都清楚过程 trace 的价值,而他的生意结构让他看不到它 |
| ⚠️ 对模型厂商下场的判断:理由是深度不是能力 | "他们在知识工作里有太多东西要拿下,所以法律必须是其中一部分" 但 ⚠️⚠️ "他们永远不会做到我们这么深";✅ 分界线给得很具体、因此可被检验:"如果 Claude 拿下小企业客户……那挺好的。但如果你在做一笔四亿美元的并购,你会想要 Legora";⚠️ 他对厂商口风不信任:"那不是他们能定的。而且他们往往根本不知道实际在发生什么";🔗 ✅ 与 Joseph Kim("95% 创业公司也能做"+十亿美元 plugin) 和 Arca(拒绝 managed agents) 构成三方对照,而本页判这一条可检验性最高,因为它把界线划在交易规模上 |
| ⚠️⚠️ 一处被叫住却没回来的话题 | "我们很高兴看到 Claude for legal 用我们的术语来称他们在建的东西"([00:03:02])→ 主持人当场"我们得聊聊这个。我们得聊聊这个" → ⚠️⚠️ 整期再也没有回到这个话题;✅ 本页判这是本期最该被标出的缺口,因为"模型厂商的法律产品是否在直接对位复制垂直厂商的功能与术语"恰恰是"他们做不深"那条判断的最直接反证候选 |
| ⚠️ 产品与规模的事实项(自述) | 起点是"ChatGPT 里塞一个瑞典法律检索工具,字面上就是全部";今天两件事:做工作 + 编排工作;tabular review 规模"单次最多大概一百万个单元格"(行=文档、列=问题;可由 agent 从丢进去的 10,000 份文件自动拉起→分析→标红旗→起草备忘),⚠️ 表格形态"比我们试过的任何别的形态都容易得多"、用户"乐意就住在里面"不导出 Excel、用 ag-grid;✅ fan out 前先跑前 10 行校验;收购 Cura(瑞典)与 Wexler(英国,fact intelligence:抽事实→互相对照看哪些被佐证哪些矛盾);自用做并购尽调,战略部分仍请外部律所,⚠️⚠️ "我们确实有过几次,发现了某个像红旗一样的东西,然后我们踩了刹车"(细节直接拒答);客户谱系从超大所到"50 个律师";⚠️⚠️ "100" 在本期出现三次且指向三个不同的东西(一池 100 位专家 / 100 个工程师 / 纽约 100 人),本页不合并 |
相关页面¶
- Jacob Lauritzen(Legora CTO)
- Max(Legora CEO)(⚠️⚠️ 同一家公司四个月前的商业侧视角;本页修正了其中"已在用微调抽取模型"的读法,并在两处标注时间线)
- Latent Space 主播(swyx 的 agent lab 命题在本期被部分证伪——"现在我们的 model picker 里有五个东西";另给了转写加关键词重跑与 embedding 定制两条一手方法)
- Joseph Kim(OpenAI)(⚠️⚠️ 两天前的卖方视角:eval 调查偏差与本期的买方热力图回退咬合;"把安全画像塑造成一个人"在本期拿到了真实部署的观测)
- Aman Singh(Arca)(⚠️⚠️ "我们有能力要求他们给我们反馈"正是本期缺的那样东西;而审计日志即事件总线与本期的 lists 是同一手法的两个样本)
- Jay(Eve)(法律行业经济学的另一侧:供给约束与结果定价;而本期指出"数据护城河"的稀缺项是过程 trace 而非语料)
- 评估与 Benchmark(看不见 trace 时的 eval 重建、跨领域热力图上的模型回退、eval 环境按交付物反推、在线廉价 LM 评分 + feature flag 灰度)
- AI 商业化与价值捕获(合伙制与人力资本的产权解释、计费模式迁移、对模型厂商下场的交易规模分界、"agent 即 API"、primitive 策略与"客户感觉建了超多")
- LLM 实用方法论(脚手架半衰期与 eval 投入时机、切块失效的形状、fan out 前跑前 10 行、转写加关键词重跑、引用多层溯源与选择性复核)
- LLM 安全(DPA 名单作为硬约束、Azure-only 与既有供应商审批、FDE 不碰数据、"一百次里有两次干出离谱事"作为 agent 即 API 的障碍)
- AI 与就业(对"初级岗位没了"的直接否定与分化判断、legal engineer / CSJD / meat proxy、合伙制金字塔)
- LLM 训练流程(到 2026 年下半年才开始做窄任务后训练、"我们不是想训自己的 fable 当主 agent"、检索侧的朴素空间)