法律AI的RAG如何落地到千万文档规模？Harvey的真实经验

一场来自Harvey与LanceDB的联合分享，首次系统讲清楚企业级RAG在法律场景下面临的真实难题：复杂查询、超大规模数据、严格安全要求，以及为什么“评估”比算法本身更重要。

为什么法律场景的RAG，比你想象的难得多

如果你只在通用问答或客服场景做过RAG（检索增强生成），很容易低估法律行业的复杂度。Calvin Qi 在分享一开始就点破：Harvey 面对的是“跨海量、超复杂法律文档的 tough RAG problems”。这些文档不仅数量巨大，而且极其密集、冗长，充满精确到条款和日期的细节。

Harvey的产品形态本身就带来了三种完全不同的检索规模：一是类似ChatGPT上传文件的“即时助手”，通常只有1到50份文档；二是用于具体交易或诉讼项目的“Vaults”，可能囊括合同、邮件、诉讼材料；三是国家级别的法律语料库，如某一国家完整的法律、法规和判例体系。规模从几十份文件，直接跳到“数千万文档”。

更棘手的是查询本身。Calvin现场展示了一条“中等复杂度”的真实用户问题，涉及特定日期前后法律适用、多个欧盟指令与条款、缩写行话和隐式过滤条件。他直言：“我们需要一个系统，能把一个查询拆解成多个部分，并为不同部分用上合适的技术。”这不是单一向量搜索能解决的问题。

真正拖慢团队的，不是模型，而是你怎么证明它是对的

在很多RAG讨论中，话题往往集中在embedding、重排序或Agent架构上，但Harvey的经验恰恰相反。Calvin明确说了一句很“反直觉”的话：“我们花最多时间的地方，不是算法，而是验证系统是否真的好。”

原因很现实：法律是一个工程师天然不熟悉的领域，系统是否正确，不能靠直觉。Harvey采用的是典型的“评估驱动开发”（eval-driven development）。他们没有押注某一个“银弹式评估指标”，而是构建了一整套分层评估体系。

在最高保真度一侧，是律师和领域专家直接审查模型输出、撰写评估报告，成本极高但质量最好；中间层是专家标注的评估标准，通过半自动或合成方式运行；最低成本的一层，则是检索层面的定量指标，比如召回的是否是正确文件夹、是否命中正确章节和关键词。正如他总结的：“好的评估，决定了你能迭代多快。”

当数据规模到达千万级，基础设施才是真正的产品

如果说查询复杂度考验的是RAG策略，那么数据规模考验的就是基础设施。Calvin给出了一个直观数字：单一法律语料库就可能达到“tens of millions of documents”，而且每一份文档都不小。这直接带来了在线查询延迟、离线重建索引、实验成本等一系列问题。

他们对基础设施的要求也异常具体：既要支持精确匹配、语义检索、过滤条件的组合，又要满足严格的数据隔离、保留周期和合规要求。“有些文档我们只能存储特定时间，这是法律要求。”他说。

这也解释了为什么Harvey选择与 LanceDB 合作。Chang She 在现场介绍，LanceDB并不把自己定义为“另一个向量数据库”，而是一个“AI-native 多模态 lakehouse”。核心理念是：搜索、分析、训练和预处理，应该建立在同一份数据之上，而不是分散在多个系统里靠人工同步。

LanceDB的赌注：把向量、文本和原始数据放在一张表里

Chang She 给出了一个非常工程化的视角：传统lakehouse擅长离线分析，却不擅长在线服务；而很多向量数据库只解决了检索，却无法承载完整的数据生命周期。LanceDB选择了一条更“重”的路。

他们基于自研的 Lance 格式，允许在同一张表中同时存储文本、embedding、图片、音频甚至视频，并直接在对象存储之上运行。这种计算与存储分离的架构，使其既能做离线分析，也能支撑在线检索。

他给出了一个具体能力边界：在GPU索引支持下，单表可以处理“30到40亿级别的向量”，索引时间在“2到3小时”。更重要的是，API设计刻意做成类似 pandas 或 Polars 的 DataFrame 风格，降低数据团队的心智负担。Chang She用一句话概括这套设计的野心：“你只需要一个地方，作为所有AI数据的单一事实源。”

三条来自一线的RAG落地经验

在演讲结尾，Calvin总结了三条极其“实战向”的经验。第一，领域型RAG必须深度理解数据本身，包括显式和隐式的查询模式，这件事无法跳过，也无法完全自动化，必须和领域专家并肩工作。

第二，要为变化而设计。模型、上下文窗口、工具都在快速演进，如果系统无法快速试错和回滚，早晚会被拖垮。而评估体系，正是支撑这种灵活性的地基。

第三，数据基础设施必须正视一个事实：未来的AI数据一定是多模态、向量密集、规模持续膨胀的。正如他所说：“我们正在进入一个全新的世界，规模只会越来越大。”这不是某一个模型的问题，而是整个系统设计的问题。

总结

这场分享最有价值的地方，不在于某个具体算法，而在于它揭示了企业级RAG真正的难点：复杂领域知识、可验证的正确性，以及能支撑长期演进的数据基础设施。对任何想把RAG带入严肃行业的团队来说，Harvey的经验都在提醒一件事——先把评估和数据底座想清楚，模型反而是最不难的部分。

关键词： 检索增强生成， 法律AI， 向量数据库， 评估驱动开发， 多模态数据

事实核查备注： 演讲者：Calvin Qi（Harvey）、Chang She（LanceDB）；Harvey处理的数据规模：单语料库达数千万文档；LanceDB支持GPU索引，单表可处理约30-40亿向量，索引时间约2-3小时；核心概念：RAG、eval-driven development、多模态 lakehouse、Lance 格式