法律 AI 的核心不是聊天，而是把项目当作检索边界｜AI Engineer × Simon Eskildsen、Jacob Lauritzen

先说结论

法律 AI 的难点并不只是把向量库做大，而是让检索系统理解法律工作的组织边界：项目、租户、司法管辖区、时间有效性、法规例外和客户加密要求，都决定了“相关文档”到底是什么意思。Legora 与 turbopuffer 的分享说明，面对数十亿文档时，一个更可行的方向是把项目作为检索和生命周期管理的基本单位，让热数据保留低延迟索引，让冷项目回到对象存储，同时把复杂的法律关系交给上层应用继续处理。中文深度整理，非逐字翻译。

原始来源：Connect AI to Billions of Legal Documents。节目：AI Engineer。嘉宾：Simon Eskildsen、Jacob Lauritzen。原始日期：2026-09-16。时长：约 20 分钟。内容类型：技术演讲 / 企业检索与法律 AI。

这期内容在讨论什么

Legora 是面向律师事务所和企业法务团队的协作式 AI 平台，使用场景包括合同审查、合同起草和法律研究。它面对的不是一批静态知识库，而是大量持续变化的客户项目：项目会创建、活跃、归档，文档有不同的权限与保密等级，查询还可能同时涉及不同法域和时点。

因此，系统的目标不是做一个“把所有文档扔进向量库”的演示，而是在大规模数据、低延迟查询、租户隔离和成本之间做结构化取舍。演讲以 Legora 从 Elasticsearch 到 Postgres，再到 turbopuffer 的演进为线索，展示了这些取舍如何被实际工作负载推动。

核心观点

第一，项目是比单个文档更有用的组织单位。系统最初把大量项目混在少数分区中，活跃项目和长期不查询的项目共享空间。随着规模增长，这种分区方式会让冷热数据相互影响，也使得权限和生命周期管理变得复杂。按项目建立命名空间后，每个项目可以独立索引、回收和迁移；大约四千个分区不再只是存储切片，而成为业务边界的映射。

第二，对象存储很便宜，但不能直接承担交互式检索。直接读对象存储可以容纳海量冷数据，却要付出数百毫秒级的访问延迟。要让律师在工作流中得到及时反馈，系统必须在对象存储之外维护足够轻量的索引、查询计划和缓存，把昂贵的随机读取次数压到很少。这个取舍不是“对象存储或数据库”二选一，而是让不同生命周期的数据走不同路径。

第三，安全要求会反过来塑造性能架构。企业客户可能要求磁盘缓存也必须加密。团队在实际负载上测试后发现，关闭 SSD 缓存对部分工作负载仍然可接受，于是可以先满足客户的密钥与数据驻留要求，再决定是否投入额外工程实现加密缓存。安全不是上线前附加的一层，而是索引、缓存和租户设计的约束条件。

推理链与关键例子

法律搜索常常需要多次扇出。用户不是单纯问“哪段文字和我的问题最相似”，而是可能需要同时考虑某个司法管辖区的层级、条款何时生效、法规之间的例外，以及一个项目内部的事实背景。检索系统负责快速找到候选文档，应用层还要根据这些关系重新组织证据。

这解释了为什么单纯追求向量相似度并不够。相似段落可以帮助定位，但法律推理往往要把多个来源连在一起：一份合同中的定义、一项法规的例外、一份判例的适用范围，可能分别落在不同文档里。系统需要把检索结果放回项目、租户和法域结构中，才有机会支持可靠的后续生成。

演讲还强调了多租户运维的现实成本。Legora 有七十多个租户，并且租户数量持续增长。如果每个租户都维护一套独立 Elasticsearch 集群，运维和成本会迅速失控。能够按项目或租户隔离命名空间、把冷索引置于低成本存储，同时共享底层服务，才让团队把精力放回产品本身。

边界、保留意见与争议

这期内容是工程团队的案例分享，不是一份适用于所有企业的基准测试。项目数量、文档大小、查询分布、租户隔离级别和合规要求不同，都会改变热数据比例和最优存储组合。

另外，检索系统解决的是“把候选证据找出来”，不是自动保证法律结论正确。司法管辖区和时间有效性等关系仍然需要明确建模，生成模型也需要引用、审查和人工责任链。一个很快的搜索系统，如果返回的证据边界不清，反而可能让错误判断传播得更快。

整理后的观察

这期最值得借鉴的不是某个数据库名称，而是架构的出发点：先把业务生命周期和权限边界写清楚，再选择检索存储。法律 AI 的“上下文”不只存在于文本段落里，也存在于项目归属、客户关系、法域和时间线上。

对其他企业知识库也是如此。一个通用向量检索接口很容易开始，却未必能支撑真实工作流。更稳的路线是把文档放回业务结构中，区分活跃与冷却数据，允许并行的多路检索，再由应用层负责组合证据。这样，模型可以专注于解释和推理，基础设施则负责让它看到正确、可授权、可追溯的材料。