01.

AI-native data infra

02.

About  LanceDB

03.

访谈正文

如果某个团队的日常工作中存在大量的搜索和检索的需求，或者因为模型训练（包括 LLM、VLM 等在内）要处理规模庞大的数据，这些任务场景就都很适合 LanceDB，因为 LanceDB 在高性能和数据处理规模这两方面都处于行业领先位置。此外，我们也是市面上唯一能同一组数据上运行从检索到模型训练的各种关键 AI workload 的产品，而且它简单易用，和技术生态系统有最广泛的集成。

总之，不管是搭建 AI 应用，还是训练新的多模态模型，都可以借助 LanceDB 来把项目的可拓展性提升 10 倍，同时成本降低一个数量级，在这个过程中，LanceDB 会帮助开发者实现更高的生产力、更快的迭代速度。

海外独角兽：你一直在数据行业探索，除了创立 LanceDB， 也是数据行业中大家都很熟悉的 Python Pandas 库的核心作者。你对 data Infra 的兴趣来自于哪里？

Chang She：我一直都对数据行业很感兴趣。我最早在对冲基金工作，作为量化分析师要承担很多数据工程的工作，当时我就意识到这个工作过程中没有好的工具可以使用，所以我们都会先写 Java 代码来读取 CSV 文件，再用 VB 脚本来做数据分析和处理。

当时我的一位同事 Wes 也遇到了和我一样的问题，于是他就写了一个闭源库，也就是今天的 Pandas。我用过 Pandas 之后相当喜欢这个项目，于是就把它推广到了整个团队，后来 Pandas 在我们整个公司都很受欢迎。Pandas 开源后也是在金融领域最先流行起来的，因为它对时间序列、统计等的支持特别好。

2012 年前后，随着相关学术研究和 互联网（web-scale）数据激增，数据科学家成为了新兴的热门职位。突然之间，对数据分析的需求猛增了 100 倍，Pandas 也因此获得了更多人的关注、可以说是人气飙升。

与此同时，Wes 和我也开始思考新的问题，比如那些不会写 Python 的数据分析师要怎么办？于是我们创办了 DataPad 做数据分析可视化，DataPad 后来被 Cloudera 收购了。

再之后我进入到机器学习领域、并加入了 Tubi。在机器学习领域，表格数据（tabular data）和非结构化数据之间存在一个相当明显的鸿沟。对于表格数据，有诸如 Python、 Spark 和 Pandas 这样很高质量的工具可以使用，但对于视频和图像这类数据处理工作就不太理想了。

因此， 2022年，我和我们的 co-founder 们决定创办 LanceDB，为非结构化数据打造新的存储层。这就是我从量化分析师到 LanceDB 以来的整个过程。

海外独角兽：你之前的经历中很多是在为结构化表格数据（tabular data）打造工具，但在非结构化数据我们还没有见到很多好的工具。这背后是不是源于结构化数据分析、机器学习、LLM，对数据的需求是三阶段演进的过程？

Chang She：我们可以先回顾一下历史上的重大技术趋势。90 年代，企业开始数字化、大规模使用数据，这让 Oracle 这样的数据库公司作为 infra 层兴起。

进入 2000 年代，互联网时代到来，先前的技术变得不够用了。随着 web-scale 数据的出现，从表格数据到 JSON 数据的转变使 MongoDB 兴起。

后来就进入到了云计算时代，出现了 Snowflake 和云数据仓库。差不多同一时期，机器学习也开始流行，所以不再只是单一的数据仓库，我们需要一种能够存储和连接不同工作负载的 infra，这就包括从简单的运行 SQL 查询，到深度学习训练、模型工作等复杂的数据管道，这也让 Databricks 成为了这个时代重要的 infra 公司。

而眼下，我认为 LLM 代表了一个新时代，尤其是多模态 AI 的出现。LLM 时代的特点是数据类型不同、数据规模远远更大、工作流程也大不相同。

另外还需要强调的是，目前还没有 killer app 出现。因为 AI 领域暂时还没出现类似 LAMP stack 这种标准架构作为基础设施，所以我也看到有很多 data  infra 公司正尝试定义 AI 时代的 LAMP stack ，但如果回顾之前的几次技术浪潮，就会发现每一代技术对应的 killer app 是先出现的，在这之后人们才去构建相应的 infra。比如，互联网普及之后才有了 LAMP stack 。

对于现在的 AI 同理，我们仍处于这个技术时代的早期，人们还在寻找 AI 时代的 killer app 是什么。所以我认为现在下结论说 AI 的 LAMP stack 会是什么样子会为时过早。

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

海外独角兽：2022 年你创办 LanceDB 时  ChatGPT 还没有推出，当时你看到的行业机会是什么？整个 data stack 中除了 RAG 还有很多方向，为什么最终选择了现在的方向?

Chang She：在 ChatGPT 发布之前，我们就已经看到多模态数据很难管理了。尤其是对于自动驾驶厂商或者其他需要处理大规模 CV 数据的公司来说，他们可能会有数据的很多副本，一份用于训练，一份用于推理，还有一份用于数据发现和探索。

我的联合创始人来自 Cruise，他在 Cruise 参与搭建过一个大规模的机器学习平台。对于 Cruise 的工程师来说，要完成一个迭代周期，他们需要学习四种不同的编程语言、七种不同的系统，并管理大约三份不同的数据副本。而且他们必须“相信”整个 pipeline 没有出错，因此数据管理问题是我们一开始想要解决的问题。

到后来，因为我们是开源的，我们通过社区发现 RAG 和向量检索的需求很多，很多用户发现用 Lance 搭建的系统在 RAG 相关用例中很方便。

到了今年我们更明确的是，RAG 在生产环境中对产出质量的要求是很高的。这意味着除了向量搜索，用户还需要其他检索方法，比如全文搜索、SQL 过滤、借鉴推荐系统中的 reranking 技术，这需要更高的复杂度。此外，通过用户反馈，用户可以对 embedding 模型和 reranking 模型进行微调，从而用少量数据和成本获得更准确的检索结果，而不是预训练一个新的大型 embedding 模型。这一系列实现都比较复杂。

我们的早期用户们发现，要实现一个好用的检索需要用到很多个系统：一个用于全文检索，一个向量数据库，一个用于存储实际数据的系统，一些自定义代码进行 reranking，并且可能还需要数据的其他数据副本用于 fine-tuning，以及自定义工作流等等。

LanceDB 就是想解决这个问题，这些都是人们绝对需要做的事情，但让我们将其从五个系统简化成一个系统，从而降低管理成本。

也因此，LanceDB 的 Lance 数据格式会是我们的独特优势之一，Lance 格式支持在一张表中存储原始数据、元数据、向量和用于 fine-tune 的用户反馈。它的自动版本控制确保了可复制性，并提供各种检索方法。用户可以在一个地方运行 SQL 查询、全文搜索、向量搜索以及 reranking 和混合搜索功能。这大大简化了生产所需的复杂度。

海外独角兽：所以当市场还没有讨论 RAG 的时候，你们实际上已经在提供相关需求的解决方案了？

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

LanceDB 的第一批客户也都是和自动驾驶相关的团队，当时还有一些车厂以及制造飞机的公司都在尝试做自动驾驶。另外还有一些规模比较小的公司，这些公司有大量的图片或 PDF 文件进行信息提取和实体提取的需求。

海外独角兽：今天 LLM 已经完全兴起了，这件事对于你们之前看到的机会带来了哪些变化？

Chang She：越来越多的公司开始对更高质量的搜索能力提出需求。尤其是去年，推荐系统、电子商务和其他机器学习密集型行业的需求就出现了爆发式增长，人们认识到需要 embedding、向量搜索和数据管理，至少是对于文本数据而言。

今年则更多关于多模态。现在多模态已经是一个共识趋势了，并且他们正在想办法输入图像和视频。多模态的发展让数据规模的增长将比传统 AI 快得多。可能在四年前，只有 Google 或者 Meta 这样的公司的数据规模是在 PB 量级，但现在，我们客户中的一个视频领域的初创公司的数据规模就超过了 10PB 。

传统数据 infra 的成本结构、效率和性能都无法应对这种新的规模，对于训练或大量定制模型的公司而言存在很大的痛点，急需一种更有效的解决方案来管理如此大量的数据。

海外独角兽：LLM 时代中最流行的使用场景和 workload 是什么？

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

海外独角兽：多模态对 RAG 带来了哪些影响？

Chang She：这个问题很有意思。现在多模态 RAG 也在成为一种趋势，多模态的模型层和应用层也在发生很大变化。传统方法中每种模态最终都会被映射到语言，但目前有很多研究绕过这种映射，通过创建不同模态之间更加原生的连接来实现更低的延迟和更复杂的用例。所以我认为 RAG 在多模态的语境下也会发生变化。

但总的来说，就像人有五感一样，AI 也在朝着这个方向发展，在不久的将来，我们将拥有通用的输入和输出能力。对于 RAG 来说，prompt 和检索的上下文也会是多模态的。在如何指令模型返回文本、音频、视频以及这几种模态的混合方面，会变得更加复杂，这意味着应用层会变得更厚，同时这些数据的管理也将成为一个相当有挑战的问题。

Lance

具体有两种方法：一种是，如果一个公司在生态系统中有足够的影响力和资源，就有机会和能力来自己定义一套标准，并且随着时间的推移，这个标准可能会被广泛接受。

但对于 Lance 来说，目前我们的 use case 其实还没有特别清晰，所以我们采取了另外一种方式，我们想以一种对各类 use case 都非常有价值的方式来做这件事，希望通过为社区提供巨大的价值，让它成为行业应用标准（de facto）。

开源数据格式的用户增长曲线会非常不同，一部分原因是 Apache Arrow 的流行。

Apache Arrow  出现之前，如果有人创建了一种新的数据格式，首先必须与市面上的工具进行一对一的集成，比如 Pandas、Polars、Spark 和 Snowflake。而 Arrow 作为内存格式标准，意味着所有这些系统都已经与 Arrow 实现了集成。

而 Lance 作为一种非磁盘格式，正是使用 Arrow 的标准类型系统和内存格式，Arrow 是我们的主接口。

因此，对我们用户来说，他们甚至不需要考虑目前正在使用的是什么磁盘格式，就可以很低成本、快速实现性能和可拓展性的提升。比如，如果他们之前是用 Parquet 格式来存储数据，那么只需两行代码就可以转换为 Lance 格式。如果用的是 Polars 或 Spark，也不需要做太多代码更改。

海外独角兽：在今天要让一个新的数据格式成为行业标准，会比之前更容易还是更难？

Chang She：这件事上有不同的观点。有一些在数据行业经验很丰富的人会认为：我们可以通过修改 Parquet v3 这一格式来满足新的用例。

而我的观点是，如果所有东西都将与 Arrow 这一标准集成，是否存在一个单一的数据格式标准就无关紧要了。不同的用例可能会有不同的标准。也许三到五年后，一个数据湖中会部分是 Parquet，部分是 Lance，也许还有部分是像 CSV 这样的其他格式。但这对最终用户来说并不重要，你只需为具体用例选择最优的存储格式。

海外独角兽：和 Parquet 相比，Lance 在快速随机访问上有很强的优势，这是如何实现的？可以通过修改 Parquet 来实现这一点吗？

Chang She：我倾向于这样思考 Lance 的差异化。今天 AI 领域对数据有三个要求。首先，人们仍然需要快速扫描（fast scans）用于分析、查询、过滤等；其实是随机访问（random access），即搜索和检索需要快速随机查找；第三点是需要能够处理多模态数据，并高效处理大块数据（large blobs）。

这里其实存在一个 AI 数据的 CAP theorem，即其他系统或许擅长上面一点或者两点要求，但还没有一个能三者兼顾。Lance 的目标就是解决这三个问题。现阶段除了 Lance 之外，还没有其他系统能够同时很好地满足这三个方面需求。

我们一开始也尝试在 Parquet 上面来构建，也考虑过修改 Parquet，但考虑到 Arrow 和生态系统的变化，从头设计一个新的数据格式可能更有价值。

如果你现在依然采用 Parquet，并在旁边想添加偏移量或索引（这是很多人的做法），索引可以快速定位到正确的行。但是由于 Parquet 固有的局限性，获取特定一行记录会很慢，因为你需要读取整个块或整个行组才能获得所需的一行数据。这是 Parquet 难以克服的根本问题。

快速随机访问之所以重要，是因为只有实现这一点，index 才能发挥真正价值。Lance 不仅提供了一种数据格式，还内置了索引格式，从而为各种用例（不仅限于向量搜索）提供更优的查询性能。

海外独角兽：在 RAG 上， Lance 数据格式有什么优势？和 Parquet 比有什么不同？

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

海外独角兽：传统数据库的数据迁移成本很高。向量数据库的数据迁移成本是什么样的？举个例子，因为 embedding model 的切换会让之前存储的 embedding 数据失效，所以如果我们 embed 了workspace 的 Notion 页面并频繁更新它，我们就需要反复重新 embed 更新数据。新一代向量数据库如何面对这个差异？

Chang She：如果只存储向量，那就没有任何 gravity，因为表只是一个索引，当你重新 embed 并创建新索引时，旧索引就会被丢弃。数据迁移成本来自于源数据，源数据并不会被改变，确实在实践中可以改变 embedding 模型，但存储待 embed 的原始数据（文本、图像等）的那个系统是难以迁移的。

关于 Lance，我们没有讨论到的一个有趣方面是它对模式演化（schema evolution）的支持。在创建新的 embedding 时，你不需要复制源数据。而有了 Lance，你可以在不复制源数据的情况下，删除旧的 embedding 列并添加一个新的，这在 Parquet 中是做不到的。此外，Lance 支持时间回溯，让你可以回溯到之前的 embedding 状态，这也有助于调试。

Lance 有一个元数据（metadata）层，不同的列和模式部分可以存在于不同的数据文件中。然后不同的版本会写出指示该版本相关文件、模式及 blob 的元数据。通过这种方式，就可以在不重写数据的情况下进行模式演化。

海外独角兽：现在行业中也有很多关于混合搜索的讨论，即把关键词搜索和语义向量搜索结合。长期来看，向量搜索会完全取代关键词搜索吗？还是二者持续共存？

Chang She：我认为它们更可能长期共存。有些数据集和用例中，关键词搜索效果更好，而另一些则更适合向量搜索。有效结合这两者也是一个有趣的领域，比如说见证式搜索（testimonial search）等。我认为在未来，各种应用都将拥有语义搜索能力，而且更可能是这两种搜索方式的结合。

即使在 RAG 之外，AI 也正在引发巨大的搜索革命。上一代 Web 应用都有响应关键词搜索的搜索框，人们不得不接受它的搜索质量，因为那是我们当时所能获得的最佳选择。现在，有了更好的搜索能力和 RAG，人们看到那种陈旧的关键词搜索框将会觉得效果很糟糕。所以我认为很快就会进入一个新时代，如果你的应用不支持语义搜索功能，用户体验就会变得糟糕。因为自然语言搜索、对话式交互模式由于 ChatGPT 的兴起变得更加核心，搜索本身也已成为用户体验的更核心部分。这种转变可能没有受到太多关注，因为听起来并不那么 sexy，但它对行业来说也是有很大影响的。