专访 LanceDB 创始人：多模态 AI 需要下一代数据基建

01 AI-native data infra

AI的这轮爆发，给数据基础设施带来的，不只是简单的量变，而是彻底的质变。随着大语言模型和多模态模型的崛起，非结构化数据开始指数级增长。这让传统的存储、检索和分析手段，一下子就显得力不从心了。

回想云计算时代，Snowflake 和 Databricks 抓住了机遇，成为增长最快的数据产品。那么在 AI 时代，也必然会诞生新一代的数据基础设施，来承接全新的需求。准确地说，这个新时代需要解决两大核心问题。

首先是规模化带来的可扩展性挑战：

• AI合成的数据，让非结构化数据的规模持续膨胀。基础设施必须能像搭积木一样灵活横向扩展，以应对不可预测的增长。
• 不同模态的数据，脾气秉性完全不同。文本需要全文索引，图像需要向量索引，而且为AI设计的索引和传统的搜索索引，底层逻辑也不一样。
• AI应用对实时性的要求是前所未见的。无论是实时语音交互，还是毫秒级的图像检索，都在倒逼数据库的读取和查询性能。

其次是技术栈和工作流的不确定性。目前，RAG 作为主流方案，仍然处于一个快速演进的阶段：

• RAG 的链条非常长，涉及数据预处理、向量化、索引、检索和生成等多个环节，每个环节都有好几种技术方案可以选择。
• 理想情况下，RAG 中的 embedding 模型、retriever、reranker 都需要用行业数据做微调才能达到最佳效果。这使得整个工作流变得高度复杂，且极度模块化。
• 标准化和可复现性低，是 RAG 难以端到端产品化的症结所在。

下一代数据产品的使命，就是解决这些难题。而 LanceDB，正是这条赛道上的一个重要玩家。

02 About LanceDB

LanceDB 是一个专门为多模态数据设计的数据库，它的客户名单中，就有 MidJourney、Character AI 和 Airtable 这样响当当的名字。其核心创新，在于他们设计并开源了一种名为 Lance 的数据格式，专门用来解决传统数据格式（比如 Parquet）在面对多模态数据时的各种水土不服。基于 Lance 格式构建的 LanceDB，可以更低成本、更快地索引数十亿向量和 PB 级别的文本、图像、视频数据。

LanceDB 的联合创始人 Chang She，是数据科学领域无人不知的 Pandas 库的核心作者。另一位联合创始人 Lei Xu，则来自自动驾驶公司 Cruise，拥有丰富的多模态数据基础设施建设经验。两位都是在这个交叉领域浸淫多年的高手。

在最近的 Databricks Summit 上，Chang She 提出了一个 AI 数据库时代的“CAP 定理”，或者说，是传统数据库面对 AI 任务时的“不可能三角”：

• 随机读取：
  比如训练模型时的 data shuffling，需要能快速定位和访问任意一条数据。

• 大块数据：
  高效地存储和检索大规模的非结构化数据，像是图像、视频文件。

• 快速扫描：
  高效地对整个表或大范围数据进行扫描和过滤。

LanceDB 的目标，就是打破这个“不可能三角”，让 AI 应用能同时享受到这三种能力。

03 访谈正文

多模态下的数据库机会

LanceDB 是为多模态 AI 设计的新一代数据库。在AI时代，企业面对的是海量的非结构化数据，比如向量嵌入、图像、视频。相应的任务，比如向量搜索、分布式训练、模型推理，与传统的键值对查询完全是两码事。传统的数据基础设施，已经管不好这些新的数据和任务了。LanceDB 的核心理念，就是为这个 AI 时代打造全新的基础数据设施。

我们和 Databricks 这类传统数据湖最大的区别，就在于底层的数据格式。传统数据湖大多基于 Parquet 格式或者原始图像文件。但对于需要处理多模态数据的 AI 任务来说，这并非理想方案，因为需要维护多个数据副本，还会遇到各种性能瓶颈，导致可扩展性差、成本高、使用复杂。所以，我们从头设计了新的数据格式和系统，来满足 AI，特别是多模态场景下的需求。

简单来说，如果你的团队日常工作中有大量搜索和检索的需求，或者因为模型训练而需要处理海量数据，那就非常适合用 LanceDB。我们在高性能和数据处理规模两方面都处于行业领先。更重要的是，我们是市面上唯一能在同一套数据上，运行从检索到模型训练等各种关键 AI 任务的产品，并且简单易用，和技术生态有最广泛的集成。无论是搭建 AI 应用，还是训练新模型，LanceDB 都能让项目的可扩展性提升 10 倍，同时成本降低一个数量级。

我最早在对冲基金做量化分析师，经常要承担很多数据工程的工作。当时最痛苦的是，没有趁手的工具。我们得先写 Ja va 代码读 CSV 文件，再用 VB 脚本做数据分析。我的一位同事 Wes 也遇到了同样的问题，于是他就写了一个闭源库，也就是后来的 Pandas。我用过后非常喜欢，就推广给了整个团队，很快就火了起来。Pandas 开源后也是在金融领域最先流行起来的，因为它对时间序列、统计的分析支持特别好。

2012年前后，随着学术研究和互联网数据的激增，数据科学家成了热门职位。突然间，对数据分析的需求猛增了100倍，Pandas 也因此人气飙升。与此同时，Wes 和我也开始思考那些不会写 Python 的数据分析师怎么办，于是我们创办了 DataPad 做数据分析可视化，后来被 Cloudera 收购了。之后我进入机器学习领域，加入了 Tubi。在机器学习领域，表格数据和非结构化数据之间存在一个巨大的鸿沟。表格数据有 Python、Spark、Pandas 这样高质量的工具，但处理视频和图像这类数据，就非常不顺手了。所以，2022年我们决定创办 LanceDB，为非结构化数据打造新的存储层。

回顾一下历史上的技术趋势会更清楚。90年代，企业数字化，Oracle 这样的数据库公司兴起。2000年代，互联网时代到来，MongoDB 随着 JSON 数据的普及而崛起。随后进入云计算时代，Snowflake 和云数据仓库出现。差不多同时，机器学习开始流行，Databricks 成为了连接不同工作负载（从 SQL 查询到深度学习训练）的重要基础设施。

而眼下，我认为 LLM 代表了一个新时代，尤其是多模态 AI。这个时代的特点是数据类型不同、数据规模更大、工作流程也大不相同。另外需要强调的是，现在还没有 killer app。AI 领域还没出现类似 LAMP stack 这种标准架构。回顾历史，每一代技术对应的 killer app 是先出现的，然后人们才去构建相应的基础设施。互联网普及之后，才有了 LAMP stack。现在的 AI 同理，还处于早期，人们还在寻找 AI 时代的 killer app，现在去定义 AI 的 LAMP stack 为时过早。

但是，我们可以锚定一些不变量。比如，模型和数据都是必不可少的。如果能让数据的存储和操作变得高效和可扩展，这件事是不会过时的。而越往中间层，middleware 的不确定性就越大。所以，通过紧贴模型和数据这两个不变量，可以构建一些经得起未来考验的东西。

在 ChatGPT 发布之前，我们就已经看到多模态数据很难管理了。特别是对于自动驾驶厂商或处理大规模 CV 数据的公司，他们往往会有数据的很多副本：一份用于训练，一份用于推理，还有一份用于数据探索。我的联合创始人来自 Cruise，他搭建过一个大规模的机器学习平台。在 Cruise，工程师要完成一个迭代周期，需要学习四种编程语言、七种不同的系统，并管理三份不同的数据副本。而且他们必须“相信”整个 pipeline 没出错。解决这个数据管理问题，是我们最初的出发点。

后来，因为项目是开源的，我们从社区发现 RAG 和向量检索的需求越来越多。很多用户发现用 Lance 搭建的系统在 RAG 用例中非常方便。到了今年，我们更明确了，RAG 在生产环境中对产出质量的要求很高。这意味着除了向量搜索，用户还需要全文搜索、SQL 过滤、借鉴推荐系统的 reranking 技术。此外，通过用户反馈来微调 embedding 模型和 reranking 模型，可以用少量数据获得更准确的检索结果。这一系列操作非常复杂。

我们的早期用户发现，要实现一个好用的检索系统，需要用到多个系统：一个做全文检索，一个向量数据库，一个存实际数据，加上一些自定义代码做 reranking，可能还需要数据副本做微调。LanceDB 就是想解决这个问题，把这些需求从五个系统简化成一个系统，从而降低管理成本。Lance 格式因此成为我们的独特优势——它支持在一张表中存储原始数据、元数据、向量和用户反馈，自动版本控制确保了可复制性，并提供各种检索方法。用户在一个地方就能运行 SQL 查询、全文搜索、向量搜索以及 reranking。

是的，当时没做完整的 RAG，但已经在做检索。自动驾驶行业发展了十年，容易解决的问题都解决了，剩下的都是长尾问题。每天有大量数据进来，但目标长尾问题的可能只有 0.01%。挑战是怎么把这 0.01% 的 corner case 找出来。为此我们增加了许多不同的 retrieval 和 indexing 能力，而 retrieval 加上向量 indexing，本质上就是一个向量搜索系统了。LanceDB 的第一批客户也都是和自动驾驶相关的团队。

越来越多的公司开始对更高质量的搜索能力提出需求。尤其是去年，推荐系统、电商和其他机器学习密集型行业的需求爆发式增长。今年则更多关于多模态，这已经成为共识，人们开始想办法输入图像和视频。多模态让数据规模的增长比传统 AI 快得多。四年前，可能只有 Google 或 Meta 这种公司的数据规模在 PB 量级。但现在，我们的一个视频领域的初创公司客户，数据规模就超过了 10PB。传统数据 infra 的成本结构、效率和性能都无法应对这种新规模。

现在每个行业都在尝试用好 AI，而且大多都需要 RAG 或语义搜索能力，这意味着我们的用户和客户群体大大拓宽了。同时，AI-native 公司需要预训练自己的大模型，他们现在必须管理比以往更多的数据，甚至比之前自动驾驶的工作负载还要多。这些场景非常适合 LanceDB 的优势。

这个问题很有意思。现在多模态 RAG 也在成为一种趋势。传统方法中，每种模态最终都会被映射到语言，但目前很多研究在绕过这种映射，通过创建不同模态之间更原生的连接来实现更低的延迟和更复杂的用例。我认为 RAG 在多模态的语境下也会发生变化。总的来说，就像人有五感一样，AI 也在朝着这个方向发展。对于 RAG 来说，prompt 和检索的上下文也会是多模态的。如何指令模型返回文本、音频、视频的混合内容，会变得更加复杂，这意味着应用层会更厚，这些数据的管理也将成为一个大挑战。

Lance

任何想成为行业标准的技术，都必须是开源的，且需要能够很好地与生态系统中的其他工具集成。具体有两种方法：一种是公司在生态系统中有足够的影响力和资源，可以自己定义标准。但对于 Lance 来说，我们的 use case 还没那么清晰，所以我们采取了另一种方式——想以对各类 use case 都非常有价值的方式来做这件事，希望通过为社区提供巨大的价值，让它成为事实上的行业标准。开源数据格式的用户增长曲线会非常不同，这很大程度上得益于 Apache Arrow 的流行。Arrow 出现之前，创建新数据格式需要与 Pandas、Spark 等工具一一集成。而 Arrow 作为内存格式标准，意味着所有这些系统都已经与它实现了集成。Lance 作为一种非磁盘格式，正是使用 Arrow 的标准类型系统和内存格式，Arrow 是我们的主接口。对用户来说，甚至不需要考虑磁盘格式，就能低成本、快速地实现性能和可扩展性的提升。比如从 Parquet 转换到 Lance，只需两行代码。

这件事上有不同观点。有些人认为可以修改 Parquet v3 来满足新用例。而我的观点是，如果所有东西都将与 Arrow 集成，是否存在一个单一的数据格式标准就无关紧要了。不同的用例可能会有不同的标准。三五年后，一个数据湖中可能部分 Parquet、部分 Lance，也许还有 CSV。但这对最终用户并不重要，你只需为具体用例选择最优的存储格式。

我更倾向于从差异化角度来思考。今天 AI 领域对数据有三个要求：快速扫描、随机访问（搜索和检索需要）、以及处理多模态数据下的高效大块数据传输。这里存在一个 AI 数据的“CAP 定理”，其他系统或许擅长其中一点或两点，但还没有一个能三者兼顾。Lance 的目标就是解决这三个问题。我们一开始也尝试过在 Parquet 上构建，但考虑到 Arrow 和生态系统的变化，从头设计一个新格式可能更有价值。即便你在 Parquet 旁边添加偏移量或索引来快速定位行，但由于 Parquet 固有的局限性，获取特定一行的记录仍然很慢，因为你需要读取整个块或行组。这是 Parquet 难以克服的根本问题。快速随机访问之所以重要，是因为只有实现这一点，索引才能真正发挥价值。Lance 不仅提供数据格式，还内置了索引格式，从而为各种用例（不仅仅是向量搜索）提供更优的查询性能。

在 LanceDB 的一个行中，我们可以同时存储图像、文本、音频、视频，以及与原始数据不同部分对应的任意数量的向量，在此基础上可以实现任意模态的跨数据检索，并使用任意模态的方法处理检索到的数据，这是 Parquet 无法高效实现的。大多数向量数据库也不允许每行超过一个向量，因为它们是为提供 API 服务而设计的，而不是作为表格。

如果只存储向量，那就没有任何“引力”，因为表只是一个索引。当你重新 embed 并创建新索引时，旧索引就会被丢弃。数据迁移成本来自于源数据，源数据并不会被改变。Lance 一个有趣的优势是对模式演化的支持。在创建新的 embedding 时，你不需要复制源数据。你可以删除旧的 embedding 列并添加一个新的，这在 Parquet 中做不到。此外，Lance 支持时间回溯，可以回溯到之前的 embedding 状态，有助于调试。我们有一个元数据层，不同的列和模式部分可以存在于不同的数据文件中。不同版本会写出指示该版本相关文件、模式及 blob 的元数据。通过这种方式，就可以在不重写数据的情况下进行模式演化。

我认为它们更可能长期共存。有些数据集和用例中，关键词搜索效果更好，而另一些则更适合向量搜索。有效结合这两者也是一个有趣的领域。即使在 RAG 之外，AI 也正在引发巨大的搜索革命。上一代 Web 应用都有响应关键词搜索的搜索框。现在，有了更好的搜索能力和 RAG，人们看到那种陈旧的关键词搜索框，会觉得很糟糕。所以很快就会进入一个新时代，如果你的应用不支持语义搜索，用户体验就会变差。这种转变可能没有受到太多关注，但它对行业来说影响很大。

它们并没有表模式的概念。一切更像是一个集合，集合有一个 record ID，可以有多个向量或者只有一个向量，外加元数据形成类似 JSON 的数据块。所以不存在所谓的模式演化和版本控制，在这种情况下，你只能显式地进行数据快照，但这时必须复制数据。

对于分布式训练，你需要进行过滤、分发和随机化等预处理。现有格式在随机化和数据混洗方面效果非常糟糕。此外，你还需要一个大规模的引擎来处理过滤和其他任务。直接从对象存储流式传输数据会使 ETL 变得复杂，并可能严重影响 GPU 利用率。由于 GPU 是最宝贵的资源，最大化它们的效率至关重要。这就是 LanceDB 的独特价值所在，它可以确保高效的数据处理，让 GPU 得到充分利用，并在分布式训练中表现出色。

我们希望为多模态数据培养一个蓬勃的开源生态系统。与任意计算引擎实现好的集成对我们来说很重要。我们已经发布了对 Ray 的集成，与 Spark 和 Trino/Presto 的集成也在推进。这回到了数据湖的概念：客户将数据以 Lance 格式存储在对象存储中，并应能使用任何处理系统进行处理。我们会是他们的合作伙伴。例如，通过 Apache Arrow，使 Snowflake 能够读写 Lance 数据。设想一下，如果 Snowflake 加入一个 pushdown，他们就可以允许客户连接到 LanceDB，并使用 Snowflake SQL 进行向量搜索。

文本确实与其他模态不太一样，但每个模态都有自己的特殊需求。对于文本来说，问题可能不在于原始数据本身更难操作，而在于数据的规模。一家专注文本的模型公司可能需要爬取整个互联网，而全网视频数据的规模则要大得多。规模问题也是现有数据 infra 面临的大挑战。

是，也不是。因为多模态数据的规模更大，所以我们的优势更加明显。从这个意义上说，我们确实希望抓住多模态数据处理这个定位。但如果你看现在的向量数据库，它们也无法处理大规模的文本数据，因为它们无法有效存储长文本。大多数向量数据库是专门为语义搜索设计的，由向量 ID、元数据的 blob 构成，而不是用于长文本的有效存储、检索和管理。对于短文本差别不大，但如果检索的是整个文档的长度，就会很快遇到规模问题。

从长远来看，向量搜索更可能成为一个更完整、独立的产品的一部分，而不是简单地作为现有系统的功能扩展。对于那些正在添加向量搜索功能的现有数据库，由于架构已定，它们只是添加了一种新索引能力。但这种索引与 B-tree 或 bitmap 索引有很大不同。对于 PostgreSQL 来说，这在工作负载特征等方面会产生很大影响。我们听到很多用户反映，他们最初使用 PostgreSQL，但数据一旦超过 1000 万或 2000 万行，延迟就会变得非常糟糕。一个更完整产品的未来发展路径，将是为 AI 和管理 AI 数据而设计的，而不仅仅是增量式地添加向量索引。

是的，我们目前正在与各个模态领域的领先公司合作，比如与 MidJourney 处理图像，与 Character AI 处理文本，也正在与一家大型视频公司合作。在所有模态中，共同的特点是庞大的数据规模、复杂的检索与数据管理需求，以及需要与分布式训练无缝集成。

在 LanceDB 的一个行中，你可以存储图像、文本、音频、视频，以及与原始数据不同部分对应的任意数量的向量，这允许你能够使用任意模态跨数据检索，并使用任意模态的方法处理检索到的数据，这是 Parquet 无法有效实现的。大多数向量数据库也不允许每行超过一个向量，因为它们是为提供 API 服务而设计的，而不是作为表格。

我们在开源社区看到很多用户用 LanceDB 处理各种 RAG 任务，比如代码生成工具、SQL 语句生成、自动化数据分析、常规 chatbot 以及 chat with doc。将不同语言包项目计算在内，我们每月的包下载量总计已经超过 100 万次。我们也和咨询公司交流过，他们会将 LanceDB 用在财务报告分析上。通常，他们发现在向量与被提取的原始数据旁边存储更多数据，更容易对原始数据进行扩展以用于提取，并将其提供给模型进行总结，从而获得更准确、更丰富的 RAG 结果。大型企业也用 LanceDB 存储和管理他们所有的训练数据，用于分布式模型训练。

LanceDB 是这些应用场景下的基础设施。在我看来，围绕不同垂直领域和高价值数据源的通用数据进行数据提取和分析，会出现很多解决方案。我们不太认为某一家公司能同时处理法律、医疗保健和政府合同等不同领域的需求，更可能是由不同的公司来做。我们的目标是为这些应用公司提供基础设施，创建易于使用的工具和可组合的构建块。与其让这些公司编写复杂的管道，不如只需编写一个 SQL 查询，就能从 PDF 中提取并使用信息，在计算集群中自动分配作业。

我不认为这些是彼此割裂的部分。有效存储大规模多模态数据是我们的核心，但存储本身没有价值，必须针对特定用例进行优化。对于大规模且复杂的需求，我们通常是唯一的解决方案。关于离线和在线用例，其他数据格式和过去的数据基础设施通常只适用于其中一种。LanceDB 是唯一能在两方面都表现出色的，我认为它对训练和检索同等重要。

产品路线图

我们的开源社区已经拥有相当大的规模，一些重要的科技公司和领先的生成式 AI 公司也都在与我们合作，所以这是一种面向开发者社区和大客户的双峰策略。最终，更多大型的非技术企业可能会在采用多模态 AI 并将其进入生产阶段时，稍晚一些加入我们的客户群体。

LanceDB 的商业化不是对数据格式本身进行商业化，而是关于构建数据管理层、工作流层和向量数据库层。这是针对真正拥有大规模数据的大型企业，无论是在推理服务还是模型构建中。我们的企业产品旨在提高生产力，减少维护负担。

要创建一个真正适合 AI 的数据库系统，需要对数据库和机器学习有深入的专业知识。我们团队在这个交叉领域积累了大量经验。我们处理的数据是多模态的，在非结构化和结构化数据上都经验丰富；查询和 workload 也是多模态的，涵盖 OLAP、检索和训练；上下文也可以是多模态的，涵盖离线数据集和在线服务。我们是 Pandas、HDFS、Apache Arrow、Delta 和 Polars 等重要项目的核心贡献者，这些过往经历让我们站在独特的位置上。

我们的目标是成为处理多模态数据的行业标准。未来一到三年内，我们将看到建立在 LanceDB 之上的更完整的多模态 AI 数据湖产品。如今，构建 AI 的公司需要雇佣专家，经历大量试错，才能拥有生产级系统。我们未来的目标是，让客户无需雇佣一支 OpenAI 级别的团队，就能在企业内运行一个完整而精密的 AI 应用栈。希望达到这样一个状态：一个数据基础设施可以支持企业内的多种不同应用，只需很少的维护和运营工作。

这个问题很有意思。我用雕刻来类比。LanceDB 中的数据就像是一团原始材料，如何从中选择合适的数据，“雕刻”成一个鼻子，也就是得到能创造出最优模型的成品，这里面有非常专业的 know-how。我们提供一个方便的工具，但更高层次的工具还不是当前产品的一部分。未来模型会 commoditize，对于采用机器学习的企业来说，差异化的因素是他们如何融入自己的专有数据。企业如何用自己的数据进行微调或预训练，如何用自己的专有数据定制化应用，这些问题会变得更加重要。

我们正在寻找各个领域的专家，尤其是那些以前曾在数据库领域工作或构建过数据库的人。我们远程工作，正在打造真正全新的事物，希望找到高度自驱、好奇，对新挑战感到兴奋的人才。