跳转至

Jacob Lauritzen(Legora CTO)

Legora 的 CTO(法律 AI,瑞典起家;本库此前已有同公司 CEO Max 的 2026-07 商业侧材料)。⚠️ 姓名拼写按视频标题,转录稿里公司名几乎每次出现都被字幕讹写成不同形态(Lora / Legore / Lorra / Agora / Lagora / Luora / "L space" 等),本库统一写作 Legora。

本库收录他的理由:他给了五样本库此前完全没有的东西——① 一条把"评估权在买方"整条线反过来的结构性约束("我们基本上看不到任何 trace"),而原因是客户的数据本身不属于客户;② 一条来自买方的模型发布观察(改善与回退同时发生,"频率比你以为的高得多"),它与卖方侧的 eval 调查偏差咬合成同一机制的两端;③ 一条关于合伙制为什么挡着知识沉淀的产权解释,且自带可检验推论;④ 一条对"买律所拿数据"的反驳:输入买得到,过程买不到;⑤ 一个本库此前没有的产品问题——"agent 能不能就是 API?"

⚠️ 立场:Legora 的 CTO,全部产品效果、客户反响与规模为自述、无第三方来源。 ✅ 但本库判定这一期的厂商色彩很轻,依据是五处对自己不利的陈述:① 把自家生意最难看的那条结构性缺陷当成全期主线自己说出来;② 对"初级律师没了"这个会抬高自家价值的说法直接答"那其实不是我们看到的情况";③ 承认"直到最近做复杂 eval 其实不太值得,因为模型自己会变好",并举了"我们什么都没做,70% 变 99%"的例子;④ 对自家 API 战略直接说"我们抗了很久,而且现在也不承诺";⑤ 主动说自己那个"永远只要 20 个工程师"的判断错了。 ⚠️⚠️ 而本库必须标出一处被主持人当场叫住、却整期没有回来的话题(见末节)。

核心观点(2026-11)

来源:Latent Space × Legora:看不见 trace 时怎么做 eval、合伙制与知识沉淀、"agent 能不能就是 API"

⚠️ 自动字幕的专名问题:⚠️⚠️ 一个被当作最强档模型的名字 "mythos" 无法确证(出现在"很多法律工作其实并不需要 mythos 级别的智能"一句里);⚠️ "Sonnet 46" / "OP 46" 为他对约九个月前所用模型的称法;"Zakur" 应为 Cura、"turboper" 应为 Turbopuffer;⚠️⚠️ "100" 在本期指向三个不同的东西且转录稿未消歧(一池 100 位专家 / 100 个工程师 / 纽约 100 人),本库三处分别照录、不合并成公司规模数字。

⚠️⚠️ 一、"我们基本上看不到任何 trace"

([00:26:18]–[00:28:20])✅ 本库认为这是他最该被长期引用的一段,也是本期真正的主线(YouTube 原标题即 "Building Legal Agents When You Can't See the Data")。

⚠️⚠️ "我们基本上看不到任何 trace。我们看不到任何数据,因为它全都是高度机密的。而这在工作时极其令人沮丧,因为你基本上不知道人们在做什么。所以就是:这里有一个 agent,它能做那么多惊人的事,而我这边完全不知道人们实际在干什么。"

  • ⚠️⚠️ 而它不可能靠谈判解决,理由把这件事从商务问题变成了结构问题:"我倒是希望。但问题是,他们手上很多数据甚至不是他们的,是他们客户的。" ✅ 本库标注:数据的所有权不在他的客户手里,所以即便律所愿意给,它也没有权利给——这与"客户不信任我们"是完全不同的一类约束。
  • 于是 eval 变成反向工程:"我们基本上有一个 eval 团队,在试着近似我们认为大家在做的事,然后把那个建进 eval 集里。" ⚠️ 他的定性是"这就是这门生意一个烦人的怪癖"。
  • 🔗 ⚠️⚠️ 而这与本库既有材料构成一次正面反转:本库此前把"评估权在买方"当成反复出现的结构性优势(Retell AI、Decagon),而两天前 Arca 把它推到极致——"我们有能力要求他们给我们反馈"。 ✅ 本库的归纳:Arca 的"我们就是那家机构本身"所买到的那样东西,在这一期被精确地标出了价格——它不是销售效率,而是可观测性。
  • ✅ 在看不见的前提下他明确说可以做三件事,而它们有一个共同点:① 失败模式归到已知的 10–20 个桶("那是一个有用的信号");② 归类任务类型与业务领域;③ 用"一个超便宜的 LM 消息"做在线总分,并按 feature flag 比灰度("它是改善了,还是灾难性地下降了")。⚠️⚠️ 本库归纳:三者都是把高维 trace 压成低维类别标签——在不能看原始数据的场景里,可观测性的设计目标不是拿到数据,而是设计一个足够粗、但仍可行动的分类空间。
  • ⚠️ 而改写成合成样本有一条尺度:"如果你一路改写到只剩三个取值、然后你从里面挑一个,那显然没问题。如果你只是把名字去掉,那大概就不行。" ⚠️ 他们取最保守一端:"我们一般挑最安全的做法,尽可能地限制自己,因为应该一点风险都没有。" ⚠️ 拿到真实样本的唯一通道是客户自己也疼时主动匿名化提供。

⚠️⚠️ 二、买方侧的模型发布观察:改善与回退同时发生

([00:08:05]–[00:09:06])

  • 设施:"我们有一个团队就专门做 eval。我们追踪所有模型在不同业务领域和那些领域里不同任务上的表现。所以我们基本上有一张很大的热力图。"
  • ⚠️⚠️ 观察:"通常它们会改善大多数东西。但确实有很多次模型发布,是改善了一些、同时在另一些上回退了。而这件事发生的频率比你以为的要高得多。"
  • 🔗 ✅ 本库标注这与 Joseph Kim(OpenAI)在两天前指认的卖方调查偏差("数字看起来好,研究员就假定模型变强了,然后不去调查它")咬合成同一机制的两端:⚠️⚠️ 卖方的指标是聚合的、且只在下降时被调查;买方的指标是分格的、于是能看见聚合值掩盖掉的回退。本库认为这两条不是互相印证的轶事,而是同一个机制的两端——聚合度决定了什么样的退化可以被发现。
  • ⚠️ 而他对"模型够不够好"给了分布式回答([00:07:03]–[00:08:05]):"这是一个幂律分布。大概有 60% 的工作,我们现在就能做得非常好,而从现在起那就是个成本和延迟的问题了。但剩下那部分,尤其是非常复杂的分析,我们还需要更多智能。" ✅ 外加限定:"而且工作本身大概也会随着智能一起扩张。" 🔗 与 Arca 的"它太慢了,而且花了很多钱" 同向。
  • ⚠️ eval 环境是按交付物反推的([00:09:06]):"基本上像一个个世界,本质上就是 RL 环境"——"这里有一个 10,000 份文件的数据室,你在做一次尽职调查,而最后那份报告应该长这样——它包含所有这些红旗,而且它不包含那些奇怪的东西,而且我们希望它简洁。" ✅ 本库标注这是上一条约束的直接后果:看不到真实 trace,eval 就只能从"交付物该长什么样"这一端重建——这也解释了为什么 eval 团队必须一半是律师(3 工程师 + 3 律师)。
  • ⚠️⚠️ 领域 taste 携带者是瓶颈(本库第三个独立样本):legal engineer = "在大所干过大概三四年、通常可能还有一个 CS 学位、非常 tech forward 的人",⚠️ "那是我们最难招的人",✅ 但"巨大的力量放大器……一池 100 位专家,每天用这个产品、每天去跟客户谈"。🔗 与 Joseph Kim 新设的 subject matter expert 岗、Arca 把知识库交给领域专家 构成模型层/应用层/垂直层的三个版本——✅ 本库判三者已足够构成结论而非巧合。

⚠️ 三、脚手架半衰期的买方版本,且是正面承认的

([00:11:08]、[00:58:29]–[00:59:29])

  • ⚠️⚠️ eval 团队的出现时点本身就是证据:"我觉得直到最近,老实说做这个其实不太值得——因为模型就是都变好了……因为把 harness 做得更好能拿到的收益太大了,而且某种程度上就顺着'一切都会改善'这件事去,然后一切也确实都改善了。"
  • ⚠️⚠️ 例子很干净:"我们有一个问题,是它不能正确地标引用……结果下一个模型发布就解决了。它从大概 70% 变成了 99%。我们什么都没做,而且挺好的。"
  • ⚠️⚠️ 而脚手架本身在反复被重写:"我们的 Word 插件就是——我们做过 map reduce,我们改过,有过一个大的,有过好几次大的。就是随着模型变化,我们一直在改我们围着它搭的那套脚手架。"
  • ✅ 本库标注这条比"脚手架会过时"更具体:⚠️⚠️ 过时的不只是脚手架,还包括测量脚手架的那套设施,而后者的投入时机本身是一个可以判断错的决策——而他的答案在 2026 年之前是"不该投"。 🔗 接本库既有的半衰期线:Serval 的示例库、Lovable 的 skills、Anthropic 的"智能看起来越来越饱和"。
  • ⚠️ 而他点的前沿缺口是长文档推理(跨整份大合同做修改、记住定义变了顺序变了);做法是切块 + 编排修改,⚠️ 而切块失效有一个具体形状:"有些文档会就某件事连着讲两页左右,而每一个单独的块都不见得与检索词相关,但它们合起来极其相关。" 🔗 ⚠️ 主持人给了方向相反的一手经验:"我最近从 map reduce 转成了全部丢进 context,而且它更好。"

⚠️⚠️ 四、合伙制为什么挡着知识沉淀

([00:14:09]–[00:16:10])✅ 本库认为这是他最原创的一段,而且与既有的律所经济学材料不重叠。

  • 合伙制的存在理由:"这些公司唯一拥有的那类资本就是人力资本……你全部的价值都在你的人身上,而你没法真正拥有人力资本。" ⚠️ "你没法拥有人,奴隶制已经被废除了。但你可以租他们——你付他们钱。所以合伙制本质上是一种结构:你把人力资本变成公司的所有者,这样他们就留下。"
  • Legora 想造的是律所从来没有的那种资产:"让律所能够建起某种无形资本、某种持久的资本——你可以建一个会学习你们怎么工作的系统";把"我们这家律所的做事方式"编码下来("不管那是一张自我改进的知识图谱还是别的什么,加上先例文件和文档"),"而那可以成为他们的 IP"。
  • ⚠️⚠️ 而激励是反的,这是本库认为这一段最值钱的部分:

    "我们需要搞出一种激励结构,让合伙人有动力去把东西编码下来、为公司建一项资产。但现在他们没有动力——因为他们一旦离开合伙制,就拿不到他们建起来的那些资产的任何分红。"

  • ✅ 本库标注这是一条产权解释而不是态度解释,且自带可检验推论:⚠️⚠️ 知识沉淀需要有人承担当下的成本、而收益归属于一个他离开后就不再分配给他的资产。于是推论很明确——如果有律所真的开始大规模沉淀知识,那么它的合伙人分配机制里应该先出现对应的改动。本库认为这个推论比任何关于 AI 采用速度的预测都更容易被观察到。
  • 🔗 而它与 Eve 的供给约束与结果定价、Legora CEO 的"软件只占 4%"与 billable hour 颠覆 接上另一头:✅ 即便需求与定价都松动了,知识沉淀这一步仍然卡在产权结构上。

⚠️ 五、"为什么这次不一样"的一个反面陈述,与计费侧观察

([00:18:11]–[00:20:11])

  • ⚠️⚠️ 他自述当年劝退 CEO 的理由:"这件事人们已经试过一百万次了。legal tech 从来没成过,因为律师没有动机去提高效率——他们会赚得更少。这根本说不通。"
  • ⚠️ 改变原因是外部压力而不是内部意愿:"他们明白了形势的严重性。他们知道商业模式和一切都在承压。他们必须变,因为竞争压力太高了。"
  • ⚠️ 计费已在动:"特别是在美国,一堆东西实际上是按项目费而不是按小时费定价的"——"特别是谱系上偏低端的那些……老实说其中一部分现在是免费做的,还有一部分就是按一个固定价。" 价值向战略与诉讼侧集中;✅ 而客户关系那类历史上白做的事被 AI 改了成本结构:"现在他们还能那么做,但不必在上面亏很多钱了。"

⚠️ 六、对"初级岗位没了"的直接否定

([00:16:10]–[00:17:10])

  • ⚠️⚠️ 主持人给的是一个会抬高他产品价值的说法("初级律师助理没了。初级律师没了。我不需要他们了"),⚠️ 而他直接否定:"那其实不是我们看到的情况。" ✅ 本库标注这是一处对自己不利的让步,因为"我们消灭了初级岗位"恰恰是这类产品最有力的销售说法。
  • 替代判断是分化而不是消失:"总体上你还是需要下一代人……你今天有一个好工程师,他比两年前值钱得多,因为他能产出多得多的东西。而我觉得法律里是同一件事……真正好的初级律师值钱得多了。" ⚠️ 他同意"这是在更进一步极化"。
  • ⚠️ 术语:legal engineer("现在也成了行业用语")、CSJDs;贬义词 "meat proxy"("你就坐在机器前面,把别人叫你打的东西打进去,然后把机器告诉你的话重复出来"),✅ 而他给了反转:"一个非常好的 meat proxy 就是——你很懂 agent、你很懂 Legora……这是我的工具箱,而每个行业都有一个工具箱。"

⚠️⚠️ 七、"agent 能不能就是 API?",与靠少数 primitive 撑住的产品策略

([00:47:26]–[00:51:27]、[00:38:24]–[00:42:25])

  • ⚠️ API 战略:"那不是我们现在承诺的事……不是产品的全部表面";"我们大概六个月前才开始做我们的 API。我们抗了很久。主要是因为——我就是不想因为要为一个我们已经改掉的数据模型维护旧 API 版本而被拖慢。" ✅ 而这个判断是规模相关的:"当我们是 20 个工程师的时候,我们动得太快,根本做不了这个。"
  • ⚠️⚠️ 而那个问题本身是本库此前没有的:

    "我们在琢磨的一件事是:agent 能不能就是那个 API?我知道这听起来很怪,但对这里面有些东西,他们真正想做的事就是触发某些事情发生。" ⚠️⚠️ "我在脑子里琢磨的是:我们产品里有多少可以就是那个 agent,而不是其它所有东西?"

  • 两条拦路理由:① "无界的执行、成本和延迟";② "还有确定性——可能一百次里有两次它会干出我们不想要的离谱事。"
  • ✅ 本库标注这是第一条问"agent 能否取代集成接口本身"的材料,而两条障碍都是可量化、会随时间变化的。 🔗 ⚠️⚠️ 与 Arca 把 agent 输出强制降格成受约束表示 是同一光谱的两端,而两期给出的障碍是同一个:非确定性。
  • 核心 primitive 三个:lists("像一个 Notion 数据库",带 trigger/automation,"把所有东西粘起来的很好的胶水")、projects(文件容器/文件系统)、agent。
  • ⚠️⚠️ "agent 能创建 list,list 能创建 agent,agent 能读 list。于是这个 agent 蜂群就活起来了。" 🔗 ✅ 与 Arca 的"审计日志同时就是 agent 的事件总线" 是同一手法的两个样本——本库归纳:多 agent 系统的协调层倾向于长成一个既有的工作流对象,而不是一个新的消息队列。
  • ⚠️ lists 的第二用途是内部产品工厂:"有点像 Legora 内部的一个 Lovable",legal engineer 用它建带 generative UI 的专用看板。
  • ⚠️⚠️ 而那条自陈的判断错误与由此来的工作定义([00:50:27]):斯巴达三百勇士那张片子——"我们接下来整个公司历史都只会是 20 个工程师,而我们会打赢所有比我们大得多的人" → ⚠️ "我们现在是 100 个工程师,而且感觉我们还是太小了";否定理由是竞争不是理念("我本可以当个清教徒……但那我们就输了,而人们会去别处");✅ 而工作定义是:

    "所以我的工作是搞清楚:我怎么建一个系统,让我们能建很多东西——但实际上客户感觉我们建了超多东西,而我们其实只建了很少几样。"

  • ✅ 本库标注这正是 primitive 策略的目标函数,于是那套架构是对"既要广度又要小团队"的直接回应。
  • ⚠️ 两处逆客户需求的战略赌注:agent 本身——⚠️⚠️ "其实没人在要这个。'我希望我在用的这个助手有更多 agency、在我不叫它的时候就去做事'——从来没人这么说过"——以及协作。 ⚠️ 而他说几乎不做试探性产品,理由是"我们就是有一座需求的大山"。

⚠️ 八、受监管行业的三条具体约束,以及由此重构的选型函数

([00:28:20]–[00:32:20])

  • ⚠️⚠️ Azure-only,理由是客户的既有审批而不是技术:"我们刚起步的时候,律所说 AWS?不行。完全不可能……所以我们基本上必须把一切托在微软上,因为他们已经有 365 了。" ✅ 机制是复用既有供应商审查:"在他们心里微软是一个已批准的供应商。" ⚠️ 而这在两年里变了,"当时还有很多人在谈 on-prem,那也完全消失了",⚠️ 他加了一句"但这才只过了三年"。
  • ⚠️⚠️ DPA 名单是硬约束:"我们的数据处理协议上供应商非常少,因为我们需要把数据去哪儿这件事守得极紧" → 语音转写不用 ElevenLabs,"因为 DPA 的原因"。
  • ⚠️⚠️ 而由此来的选型函数重构,本库认为是这一段最值得保存的:"这确实是 Gemini 和 OpenAI 这类的一个好处——他们是'你来我们这儿,我们有你需要的大部分东西',而那其实非常有价值。" ✅ 判据很直白:"即便它不一定是 state-of-the-art,只要它对所有任务都大体够好,谁在乎呢?"、"你有全部的治理,而且它超级可扩展,那大概就够好了。"
  • ✅ 本库标注这是第一条把捆绑式平台的优势落在合规开销、而不是能力或价格上的材料:⚠️⚠️ 在受监管行业里,供应商数量本身是成本(每加一个要过一次 DPA),于是"一家供应商覆盖大部分任务"的价值可以超过"每个任务都用最好的模型"。 🔗 ⚠️ 与 Joseph Kim 那条"把数据买进来自营" 是同一逻辑的两种落点:两边都在用"减少外部依赖的数量"换别的东西,那边换可靠性,这边换合规面。
  • ⚠️ 模型路由是多目标的:能力、延迟、成本、治理、区域可用性;三档并存(开放权重 / 自做后训练 / 前沿模型);⚠️ 自述年初"坚定的 Anthropic",点名 Grok 在大幅改善;⚠️⚠️ "某个早期的 Gemini,对某些类型的转录和说话人归属极其好",⚠️ 微软的转写模型"比旧的 Gemini 更好"。
  • ⚠️ 一条领域转写失败与对策:澳大利亚法庭上某类人的称谓"一直被转写成 condom";🔗 主持人的工作流:"通常你在它上面跑一层 LM,抽出一些关键词,然后带着关键词再跑一遍转写模型。" ✅ 一般化:"如果你在任何大规模上做过这件事,你会在任何不是普通日常对话的领域上捡到一大堆一大堆的转写错误。"

⚠️ 九、两个岗位最干净的一条定义

([00:42:25]–[00:46:25])

⚠️⚠️ "legal engineer 像一个高级用户那样配置产品。他们不写代码。" ⚠️⚠️ "而一个 forward deployed engineer 基本上是往生产里写代码。"

  • 用法是"一线二线",FDE 在产品与客户之间轮转;⚠️ 第一位 FDE 是纽约的第一个 hire、也是一位 YC 创始人,"大概九个月前"(背景画像:创始人、常规工程师;他举的那位"两家 YC 公司,在 Meta 做过搜索")。
  • ⚠️⚠️ 而第一节那条约束在这里再次出现,本库认为这是一处很好的内部一致性:"他们仍然不碰数据。所以他们只是把系统建起来。" ⚠️ 例外是偶尔被当成员工入职("他们可能会拿到一台笔记本之类"),但"这不太经常发生"。
  • ⚠️ 还没有 Palantir 那种驻场制度:被问"四天驻场一天回来反哺产品"的规则,答 "没有,我们没有。老实跟你们说,这一切还都在很早期。"
  • ⚠️ 欧美客户差异的形态是定制意愿:"欧洲的动得慢一些。美国的非常前倾",⚠️⚠️ 而"美国公司对自己定制搭东西的胃口也大得多"(自建 CRM/DMS、Salesforce→Legora→回去的触发链);⚠️ 最激进那类他明确拒绝:"有些极其有野心,是他们想跟我们一起建一个全新的产品,而那个我们真做不了。" ✅ 他同时否认这是威胁感差异。

⚠️⚠️ 十、对"买律所拿数据"的反驳:输入买得到,过程买不到

([01:00:29]–[01:01:29])

  • ⚠️ 他先给了一条法律上的不确定:"那边有一些关于他们的数据到底是不是他们的、还是客户的的事。所以如果客户都走了,那也许就没问题。我其实不知道。"
  • ⚠️⚠️ 而真正的反驳在后面:

    "买律所数据的问题是:你拿到的是全部真实的输入,这很好。但输出就难办一些了,因为你只拿到最终结果是什么,而很难搞清楚……你基本上得反过来把他们是怎么走到那儿的逆推出来。" ⚠️⚠️ "所以在我们产品里,当我们拿到真实用户的真实 trace 时,那是极高价值的。但如果我们只是拿到这个输出、而我们不知道它是好还是坏、也不知道它是怎么被做出来的,那就有点难办。"

  • ✅ 本库标注这条修正了多条"数据是护城河"的主张(Eve 的数据不可爬、Legora CEO 的"数据要全不要 80%"、Joseph Kim 把数据列为 plugin 生意的秘方):⚠️⚠️ "数据"在这里是两样不同的东西——输入语料与过程 trace。存量文档买得到,而"怎么从输入走到输出"买不到,于是数据护城河的真正稀缺项不是语料规模,而是带过程的样本。
  • ⚠️⚠️ 而这让第一节成了本期最大的讽刺,本库记这处张力:他比谁都清楚过程 trace 的价值,而他的生意结构让他看不到它。

⚠️ 十一、对模型厂商下场的判断:理由是深度,不是能力

([01:03:30])

  • 主持人指出在编码领域实验室已经掐过竞争者,"而这发生过两次"。
  • ⚠️ 他的回答是否定的,分两层:① "他们在知识工作、或者说企业的知识工作里有太多东西要拿下,所以法律必须是其中一部分,就像数据分析必须是、销售、市场、财务都必须是";⚠️⚠️ ② 但"他们永远不会做到我们这么深"。
  • ✅ 而分界线给得很具体、因此可被检验:"如果 Claude 拿下小客户、小企业客户,他们有些法务通过 Claude 做,那挺好的,没问题。但如果你在做一笔四亿美元的并购,你会想要 Legora。"
  • ⚠️ 他对厂商口风不信任也记一笔:"那不是他们能定的。而且他们往往根本不知道实际在发生什么。"
  • 🔗 ✅ 本库标注这与同周两期构成三方对照,位置各不相同:Joseph Kim(模型厂商)说"95% 是创业公司也能做的"、并预测会有十亿美元生意建在一个 ChatGPT plugin 之上;Arca(应用层)拒绝 managed agents,理由是"拥有记忆与运营知识就是拥有你的智能";而他(垂直应用层)既不拒绝也不依附,判断是"他们必须做,但做不深"。 ✅ 本库认为这一条的可检验性最高,因为它把界线划在交易规模上——"四亿美元并购会来找我们、小企业法务走 Claude"是一个可以在两年内被观察到对或错的预测。
  • ⚠️ 两年后的使用形态他给了双轨答案:"如果你是大企业,你可能有 Claude 在用……类似于我怎么用 Linear——我通过 Claude 用它,但我还是会去 Linear。我觉得律所就会直接用 Legora,因为那更简单也更好。" ⚠️ 本库标注后半句是立场陈述、无依据。

⚠️ 十二、引用系统,与"律师到底在不在核对引用"

([00:56:28]–[00:57:29])

  • 他说自己最在意的模型问题是幻觉,对策是把每句话绑到可点击来源上:"我们有一套引用系统,基本上会检查它写的东西有没有一个链接……它会在 PDF 之类里用一个框高亮出这条信息是从哪儿取的。"
  • ⚠️⚠️ 多层溯源:"如果 agent 是基于一次 tabular review 写了什么,它可以引用 tabular view 里的那个单元格、或者那一行。所以你其实可以往下点好几层,一路验证上来。"
  • ⚠️⚠️ 但被问律师是不是真的在核对时答案是否定的:他答"最初会,但现在……",⚠️⚠️ 主持人补的是"那种编出来的最高法院链接。他们不在乎",他承认"这确实会发生"。
  • 他的类比是 code review 式的选择性复核:"你有那种完全不在乎、就是甩 agent 的工程师,也有那种坐下来读每一个逗号的人";"他们也知道:好,这些是关键的……我就重点复核这几样。而这些听起来合理,所以大概没问题";⚠️⚠️ "就跟你从一个初级律师那里收到东西一样。"
  • ✅ 🔗 本库标注这给 Joseph Kim 那条"把安全画像塑造成一个人" 提供了真实部署里的观测:⚠️⚠️ 既支持了那条设计原则(人确实会复用既有习惯),又正好暴露了本库在那期标出的风险——抽样复核能挡住独立的错误,而"这些听起来合理,所以大概没问题"恰恰是对相关性错误最没有抵抗力的那种复核方式。 ✅ 本库认为这两期放在一起读,才构成一个完整的、带观测的论证链。
  • ⚠️ 一条模型写作风格的买方评价:"fable 和[另一个]绝对非常话多……非常冗长"(⚠️ "这一般来说不好");"Astra 写东西挺好,简洁得多";⚠️⚠️ 而限定很重要——"话多/冗长这件事对我们来说其实有点难办",意味着不是靠 prompt 能压掉的,而这可被复测。

⚠️⚠️ 十三、一条对本库既有记载的修正

([00:52:27]–[00:54:28])

  • ⚠️⚠️ "是的,到现在为止我们一个模型都没微调过。" → "过去这几个月,开放权重模型变得极其能干了,所以对某些任务我们会做——那些我们认为'一个前沿模型在那个成本和延迟下能做到的'与'一个后训练过的模型能做到的'之间有巨大差值的任务。"(例:法律检索,一个 fan out 检索问题)
  • ⚠️ 范围划得很窄:"我们不是想训我们自己的 fable 来当那个主 agent。我觉得那个我们赢不了。"
  • ✅ 本库据此修正 CEO 页(2026-07) 里"已在用微调抽取模型"的读法:⚠️⚠️ 那是一条路线主张,落地发生在 2026 年下半年且范围被收窄成检索一类的限定任务。方向性(只做窄任务、不训通用法律模型)两期完全一致,差异只在"已经做了"还是"准备做"。本库按约定不删旧记载,在两处都标注时间线。
  • ✅ 而他在同一段给的优先级判断对工程侧更有用:"甚至在模型之前、甚至在 harness 里,就有一大堆低垂的果实……有太多我们能做、而且立刻就有影响的事,都在训模型之前。" ⚠️ 检索侧仍有空间但形态朴素:"它其实甚至不是模型训练。有时候它就是架构和流水线。"

⚠️⚠️ 一处被叫住却没回来的话题

  • ⚠️⚠️ 在介绍 tabular view 时他自己带出了一句([00:03:02]):"这现在也成了行业里在用的名字,而我们很高兴看到 Claude for legal 用我们的术语来称他们在建的东西。"
  • ⚠️⚠️ 主持人当场叫住了它("我们得聊聊这个。我们得聊聊这个"),而本期再也没有回到这个话题。
  • ✅ 本库必须标出这一点,因为"模型厂商的法律产品是否在直接对位复制垂直厂商的功能与术语"恰恰是第十一节那条"他们做不深"判断的最直接反证候选。 ⚠️ 本库只记录这句话被说过、以及它没有被展开;不推测产品形态,也不把"沿用术语"读成更强的结论。

产品与规模的事实项(自述)

  • 起点([00:02:00]):"ChatGPT 里塞一个瑞典法律检索工具,字面上就是全部。" 今天做两件事:做工作 + 编排工作。
  • tabular review:行=文档、列=问题(终止期、有没有 IP 归属条款、解雇要付多少);"单次最多大概一百万个单元格";可由 agent 从丢进去的 10,000 份文件自动拉起 → 分析 → 标红旗 → 起草备忘;⚠️ 表格形态"比我们试过的任何别的形态都容易得多"、用户"乐意就住在里面"不导出 Excel、用 ag-grid;✅ fan out 前先跑前 10 行校验。
  • 收购:Cura(瑞典)、Wexler(英国,fact intelligence:抽事实带命名实体与日期 → 互相对照看哪些被佐证哪些矛盾 → 可与庭审转录对质);自用做并购尽调,战略部分仍请外部律所,⚠️⚠️ "我们确实有过几次,发现了某个像红旗一样的东西,然后我们踩了刹车"(细节直接拒答:"不,我觉得不行")。
  • 客户谱系:从超大所到"50 个律师的也在用我们,而且拿到很多价值"。
  • 产品指标:DAU/MAU 与月均花费"对一家企业软件来说非常高"(⚠️ 无具体数字)。
  • 招聘:工程在纽约、斯德哥尔摩、伦敦。
  • ⚠️⚠️ "100" 在本期指向三个不同的东西且转录稿未消歧(一池 100 位专家 / 100 个工程师 / 纽约 100 人),本库不合并成一个公司规模数字。

相关页面