Indexify 揭秘 - Diptanu Gon Choudhury | 向量空间讲座

“我们有像 Qdrant 这样的工具，它非常适合进行向量搜索。因此，我们现在理解了存储系统的形态。”
— Diptanu Gon Choudhury

Diptanu Gon Choudhury 是 Tensorlake 的创始人。他们正在构建 Indexify - 一个开源的可扩展的非结构化数据结构化提取引擎，用于构建近实时知识库，以支持 AI/智能体驱动的工作流程和查询引擎。在构建 Indexify 之前，Diptanu 在 Hashicorp 创建了 Nomad 集群调度器，在 Netflix 发明了 Titan/Titus 集群调度器，领导了 FBLearner 机器学习平台，并在 Facebook 构建了实时语音推理引擎。

收听本集节目： Spotify、Apple Podcast、Podcast addicts、Castbox。您也可以在以下平台观看本集节目：YouTube。

主要收获

探索 Diptanu 如何深入讲解 Indexify，了解其重新构想的数据基础设施如何彻底改变 AI 智能体工作流程，将原始数据转化为实时知识库。他还分享了关于优化基于 RAG 的应用的专家见解，所有这些都发生在 Spark 不断演变的背景下。

您将发现的内容

1. 创新数据基础设施：Diptanu 深入探讨了 Indexify 如何通过今年更加聚焦数据基础设施和为生成式 AI 提供更精致的抽象来革新企业界。
2. 呼叫中心的 AI 副驾驶：了解 Indexify 如何利用实时知识库简化客户服务，改变座席人员互动和解决问题的方式。
3. 扩展实时索引：了解系统强大的能力，能够实时索引内容，并支持多个提取器同时运行。关键在于选择合适的模型和具备足够的计算能力来实现内容的即时生成。
4. 改进开发者体验：一窥未来，Diptanu 与 Demetrios 探讨了如何重新构想 Spark 以适应当今的技术能力，这与仅仅两年前的情况大不相同！
5. AI 智能体工作流程洞察：理解 AI 智能体驱动工作流程的核心，即模型动态地对数据做出反应，并在实时环境中协调决策。

趣闻：Diptanu 开发 Indexify 的灵感源于大型语言模型在应用中的日益普及，以及随之而来的支持这些技术所需的更完善的数据基础设施。

节目笔记

00:00 AI 对模型生产和工作流程的影响。
05:15 构建智能体需要持续更新的索引。
09:27 早期的 RAG 和 LLMs 采用者忽视了数据基础设施。
12:32 设计合作伙伴正在为呼叫中心创建副驾驶。
17:00 使用可扩展模型进行高效索引和生成。
20:47 Spark 功能多样，适用于多种用例。
24:45 最近关于 RAG 的综述论文涵盖了技巧。
26:57 数据生成的各个方面的评估。
28:45 在事实准确性方面平衡信任和成本。

Diptanu 的更多引言

“2017年，当我开始做机器学习时，将一个好的模型投入生产需要六个月。而今天，到了2024年1月，每周都有新模型问世，并且人们正在将它们投入生产。”
– Diptanu Gon Choudhury

“随着时间的推移，你会希望从现有数据中提取新的信息，因为模型正在不断进步。”
– Diptanu Gon Choudhury

“我们正处于演示的黄金时代。LLMs 演示的黄金时代。几乎任何人，只要具备一些编程知识，我认为都可以使用 OpenAI API 或嵌入模型等来编写演示。”
– Diptanu Gon Choudhury

文字记录

Demetrios：我们直播了，宝贝。就是这样。欢迎回到又一期向量空间讲座。我和我的朋友 Diptanu 在这里。他是 Tensorlake 的创始人兼创建者。他们正在构建 Indexify，一个开源的、可扩展的非结构化数据结构化提取引擎，用于构建近实时知识库，以支持 AI 智能体驱动的工作流程和查询引擎。如果听起来我把所有时髦词都塞进了这句话里，你可以说“中了”，我们就来了，接下来的30分钟，我们就要剖析这一切到底是什么意思。所以，首先我得让所有在场的人知道，您可是一位重量级人物。

Demetrios：您身上有很多了不起的成就。可以说在您创建 Tensorlake 之前，让大家知道您曾在 Hashicorp 创建了 Nomad 集群调度器，在 Netflix 发明了 Titan/Titus 集群调度器，领导了 FBLearner 机器学习平台，并在 Facebook 构建了实时语音推理引擎。您可能是我们请来的嘉宾中最功勋卓著的一位，也是我有幸交谈过的人之一，这已经说明了很多。我这辈子和很多人聊过，所以我想深入探讨。我给您的第一个问题，是个大问题。您说的 AI 智能体驱动工作流程到底是什么意思？您是指自主智能体？还是指语音智能体？那是什么？

Diptanu Gon Choudhury：是的，我想说过去几年对 AI 来说真是太棒了。我的意思是，在语境中，学习某种程度上改变了人们创建模型、访问模型以及在生产中使用模型的方式，就像在 Facebook 一样。2017年，当我开始做机器学习时，将一个好的模型投入生产需要六个月。而今天，到了2024年1月，每周都有新模型问世，并且人们正在将它们投入生产。这有点像 YOLO（你只活一次）的心态，我感觉人们已经不再衡量模型的表现如何，而是直接将其投入生产，但我们就是这样。但我认为这一切的基础是这样一个想法：模型在一定程度上能够对数据和非参数知识进行推理。我们现在看到的是，工作流程不再完全由启发式驱动，或者像人们说的，由软件 10 驱动。人们将模型引入其中，让模型对工作流程看到的数据做出反应，然后利用模型在数据上的行为，让模型决定工作流程应该做什么。我认为对我来说，智能体差不多就是这样，智能体对世界信息和外部信息做出响应，并对这些信息做出反应，然后协调某种业务流程、某种工作流程或工作流程中的某种决策。

Diptanu Gon Choudhury：这就是我所说的智能体。它们可以是自主的。它们可以是编写电子邮件或聊天消息之类的东西。这里的范围很广。

Demetrios：好的。下一个问题，合乎逻辑的问题是，我也赞同您说的。比如我们去年看到的进展，哇。时代在变化，我们正在尝试在生产中进行评估。我喜欢您说的“yoloed it”（放手一搏），或者像现在的年轻人说的（我是听说的，我不是他们中的一员），我们只是为了剧情发展才这么做。所以我们把这些模型推向市场，看看它们是否有效。我想您肯定看过雪佛兰聊天机器人的一些有趣引言，那个聊天机器人是雪佛兰支持页面上的，有人问它特斯拉是否比雪佛兰更好。它说，是的，特斯拉比雪佛兰更好。

Demetrios：所以是的，我们现在就是这么做的。这是2024年，宝贝。我们就是把它放出去，然后测试和试用。总之，回到正题，我们来谈谈 Indexify，因为我刚才用了太多行话来描述您的工作，请给我一个直截了当的答案。就像我是个五岁小孩一样给我讲讲。好的。

Diptanu Gon Choudhury：所以，如果您今天正在构建一个依赖于增强生成（比如检索增强生成）的智能体，并且考虑到这是 Qdrant 的节目，我假设大家都非常熟悉 RAG 和增强生成。所以，如果人们正在构建的应用中的数据是外部的或非参数的，并且模型需要持续查看更新的信息，比如应用用于其知识库的底层文档正在变化，或者有人正在构建一个聊天应用，新的聊天消息不断涌入，并且智能体或模型需要了解正在发生的事情，那么您就需要一个或一组持续更新的索引。此外，随着时间的推移，您会希望从现有数据中提取新的信息，因为模型正在不断进步。还有一点是，直到现在，或者直到几年前，AI 都非常注重领域或任务，模型背后的关键是模态。现在我们正在进入一个世界，信息以任何形式编码（文档、视频或其他）对于人们正在构建的这些工作流程或智能体都非常重要。因此，您需要具备能力来摄取任何类型的数据，然后从中构建索引。在我看来，索引不仅仅是嵌入索引，它们也可以是半结构化数据的索引。比如您有一张发票。

Diptanu Gon Choudhury：您可能希望将该发票转换为半结构化数据，例如发票的来源、项目明细等等。所以简而言之，您需要良好的数据基础设施来存储和提供这些索引。此外，您还需要一个可扩展的计算引擎，以便在有新数据进来时，能够对其进行适当的索引并持续更新索引等。您还需要进行实验的能力，将新的提取器添加到您的平台，将新的模型添加到您的平台等等。Indexify 可以帮助您完成所有这些，对吗？所以，想象 Indexify 是一个带有 API 的在线服务，开发者可以上传任何形式的非结构化数据，然后集群上会并行运行一组提取器，从这些非结构化数据中提取信息，然后持续更新 Qdrant 或 postgres 等系统上的半结构化数据索引。

Demetrios：好的？

Diptanu Gon Choudhury：基本上，您可以通过一个应用程序（一个在集群上分布的单一二进制文件）获得这一切。除了存储系统之外，您基本上没有任何外部依赖，就可以拥有一个非常可扩展的数据基础设施，用于您的 RAG 应用或您的 LLM 智能体。

Demetrios：太棒了。那么，请告诉我创建这个的灵感来源是什么。您看到了什么，让您觉得“我知道了，市场需要一种能够处理这个问题的东西”？好的。

Diptanu Gon Choudhury：今年早些时候，我在这里与一家生成式 AI 初创公司的创始人合作。我在观察他们在做什么，我在帮助他们，然后我看到了。然后我环顾四周，看看正在发生什么。不是今年早些时候，而是在2023年初的某个时候，我在观察开发者如何使用 LLMs 构建应用，我们正处于演示的黄金时代。LLMs 演示的黄金时代。我认为几乎任何具备一些编程知识的人都可以使用 OpenAI API 或嵌入模型等来编写演示。我主要看到的是，那些演示或应用的底层数据基础设施非常基础，人们会进行一次性数据转换，构建索引，然后做一些事情，并在其上构建应用。

Diptanu Gon Choudhury：然后我开始与企业中 RAG 和 LLMs 的早期采用者交流，我开始和他们谈论他们如何构建用于 LLMs 的数据管道和数据基础设施。我感觉人们主要对应用层感到兴奋，对数据基础设施的思考非常少，几乎就像是用胶带拼凑起来的管道，比如 RabbitMQ 等管道和工作流程，非常定制化的管道，擅长一次性转换数据。所以您将一些文档放入队列，然后这些文档不知怎么就被嵌入并放入 Qdrant 之类的东西中。但没有人考虑过如何重新索引？如何在管道中添加新功能？或者如何保持整个系统在线，对吧？在重新索引时保持索引在线等等。所以从经典的分布式系统工程师角度来看，他们会说，你知道，这是一个 MapReduce 问题，对吧？所以有像 Spark 这样的工具，有像 Anyscale Ray 这样的工具，它们通常会解决这些问题，对吧？如果您去 Facebook，我们使用 Spark 来处理类似的问题，或者 Presto，或者我们有大量的大数据基础设施来处理这些事情。我认为在2023年，我们需要一个更好的抽象来做这样的事情。世界正朝着无服务器方向发展，对吧？开发者理解函数。开发者将计算机视为函数，这些函数分布在集群上，并且可以将内容转换为 LLMs 可以消化的东西。

Diptanu Gon Choudhury：这就是我的灵感来源，我在想，如果我们为2023年的生成式 AI 重做 Spark 或 Ray，会是什么样子？我们如何使其如此简单，以便开发者可以编写函数来从任何形式的非结构化数据中提取内容，对吧？您无需考虑文本、音频、视频或其他任何内容。您编写一个可以处理特定数据类型并从中提取内容的函数。现在，我们如何扩展它？我们如何以非常透明的方式赋予开发者管理索引并在生产中提供索引的所有能力？这就是它的灵感来源。我想为生成式 AI 重新构想 MapReduce。

Demetrios：哇。我喜欢您给我发来的关于不同用例的一些想法，我们可以一一探讨，我很想深入了解并将其转化为您在实践中看到的具体事物。以及您如何将其应用到这些不同的用例中。我想我想看的第一个是为呼叫中心座席构建一个副驾驶，以及它在实践中到底是什么样子。好的。

Diptanu Gon Choudhury：所以我举了这个例子，因为这对我来说非常亲近，我们有一个正在做这个的设计合作伙伴。您会看到，在呼叫中心，进入呼叫中心的信息，或者呼叫中心的人类座席人员处理的信息非常丰富。在呼叫中心，您有来电、聊天消息、正在进行的电子邮件，还有作为人类回答问题或做决定的知识库文档。对。所以他们处理大量数据，并且总是在拉取大量信息。我们的一个设计合作伙伴基本上正在为呼叫中心构建一个副驾驶。他们正在做的是，他们希望呼叫中心的人类座席人员能够基于与用户的对话或通话的语境轻松回答问题，或者调出公司政策等的最新信息。所以他们使用 indexify 的方式是，他们将所有内容，比如传入的原始内容，视频——不，实际上是音频、电子邮件、聊天消息，都摄取到 indexify 中。

Diptanu Gon Choudhury：然后他们有一组提取器，可以处理不同类型的模态，对吗？有些提取器从电子邮件中提取信息。比如他们会做电子邮件分类，他们会对电子邮件进行嵌入，他们会从电子邮件中提取实体等。所以他们从电子邮件中创建了许多不同类型的索引。语音也是如此。对吗？比如通过通话传来的数据。他们会先使用 ASR 提取器对其进行转录，然后将语音进行嵌入，并将整个文本处理流程应用进去，然后语音就可以被搜索了。如果有人想找出发生过什么对话，他们就可以查找。还有一个摘要提取器，可以查看电话通话，然后总结客户来电的目的等等。

Diptanu Gon Choudhury：所以他们基本上正在构建一个近实时的知识库，一方面了解客户正在发生什么。另一方面，他们也在从他们的文档中提取信息。所以这就像一个典型的用例。现在他们唯一的依赖基本上是像 blob 存储系统和用于索引的服务基础设施，比如在本例中是 Qdrant 和 postgres。他们有一组他们自己编写的提取器，以及一些我们编写的提取器，他们正在直接使用这些提取器，并且他们可以根据需要扩展系统。这相当于给了他们一个构建索引并在 LLMs 中使用的高级抽象。

Demetrios：所以我非常喜欢您提出的这种非结构化数据和半结构化数据如何几乎可以协同工作、相互配合的想法。我认为非常清楚的一点是，您有转录文本，您正在做嵌入，但您也有非常结构化的文档，也许是上次通话记录，存储在某种数据库中。我想我们可以说，比如 Salesforce，它就在 Salesforce 里，您拥有所有数据。所以这些数据有一定的结构。现在您想要能够接入所有这些数据，并且能够做到，特别是在这个用例中，呼叫中心座席，人类座席需要做出决定，而且他们需要快速做出决定。对。所以实时性在这其中扮演了非常重要的角色。

Diptanu Gon Choudhury：没错。

Demetrios：您不能让它需要30秒才能回复您，或者也许30秒还可以接受，但实际上时间越短越好。因此，传统上当我考虑使用 LLMs 时，我基本上不会考虑实时性。您在使其更实时方面有什么心得吗？好的。

Diptanu Gon Choudhury：这有两个方面。您的索引能多快更新？截至昨晚，我们可以在 AWS 上在五分钟内索引整个维基百科。我们可以使用 indexify 并发并行运行多达 5000 个提取器。我觉得我们在索引方面已经做得不错了。当然，除非您使用的模型是通过 API 调用，我们无法控制。但假设您正在使用某种嵌入模型或某种提取器模型，比如您控制的命名实体提取器或语音转文本模型，并且您了解其 I Ops，我们可以将其扩展，我们的系统可以处理快速索引的规模。现在在生成端，这就有点微妙了，对吗？生成取决于生成模型的大小。如果您使用 GPT-4，那么显然您将受制于 OpenAI 提供的延迟预算。

Diptanu Gon Choudhury：如果您使用的是其他形式的模型，比如 Mixture of Experts (MoE) 或其他经过高度优化且您已致力于优化模型的模型，那么显然您可以缩短延迟。所以这取决于端到端的堆栈。它不像一个单独的软件。它不是一个单体软件。所以它取决于很多不同的因素。但我可以自信地说，只要人们使用的模型是合理的并且他们的集群中有足够的计算资源，我们就已经解决了实时性方面的索引问题。

Demetrios：好的。现在我们再谈谈用这个重新思考开发者体验的想法，以及几乎是重新构想如果 Spark 今天创建会是什么样子。

Diptanu Gon Choudhury：没错。

Demetrios：您认为您构建的东西中，有哪些体现了只有在今天而非两年前才能实现的事物？

Diptanu Gon Choudhury：是的。所以我想，举个例子，拿 Spark 来说，对吧？Spark 诞生于大数据时代，比如2011年、2012年的大数据时代。事实上，我曾是 Apache Mesos 的提交者之一，Spark 在很长一段时间里使用了这个集群调度器。然后我在 Hashicorp 的时候，我们尝试为 Spark 贡献 Nomad 的支持。我想说的是，Spark 最终是一个任务调度器，它使用底层调度器。所以今天管理 Spark 或任何其他类似工具的团队，他们有十几到十五个人，或者他们使用托管解决方案，这管理起来超级复杂。对。一个 Spark 集群不容易管理。

Diptanu Gon Choudhury：我并不是说这是件坏事或者怎么样。在任何特定时间编写的软件都反映了它诞生的那个世界。所以很明显，它是那个时代的系统工程等等的产物。从那时起，系统工程已经取得了很大的进步。我觉得我们已经学会了如何构建可扩展但更容易理解和操作的软件等等。而在 Spark 或 Anyscale Ray 中，我觉得缺失的另一件大事是，它们没有原生集成到数据堆栈中。对。它们对数据堆栈是什么没有自己的看法。

Diptanu Gon Choudhury：它们就像出色的 MapReduce 系统，然后数据部分再在其上构建。这在一定程度上使它们能够推广到如此多不同的用例。人们使用 Spark 处理各种事情。在 Facebook，我曾使用 Spark 进行语音到文本的批量转码，用于各种用例，底层有很多问题。对吧？所以它们与大数据存储基础设施紧密相连。因此，当我重新构想 Spark 时，我几乎可以采取这样的立场：我们将使用 blob 存储来摄取和写入原始数据，并且我们将拥有低延迟的服务基础设施，比如 postgres 或 clickhouse 或其他什么，用于服务结构化或半结构化数据。然后我们有像 Qdrant 这样的工具，它非常适合进行向量搜索等等。因此，我们现在理解了存储系统的形态。

Diptanu Gon Choudhury：我们知道开发者希望与它们集成。所以现在我们可以控制计算层，使其优化计算并生成数据，以便数据可以写入那些数据存储中，对吗？所以我们了解 I Ops，对吗？那个 I/O，那叫什么？底层存储系统的 I/O 特性我们非常清楚。而且我们知道用例是人们希望在 LLMs 中消费这些数据，对吧？所以我们可以做出设计决策，比如如何写入那些存储系统，如何专门为 LLMs 提供服务，这些决策如果开发者使用其他工具的话，我觉得他们需要自己来做。

Demetrios：是的，感觉就像是针对这一点进行优化，并认识到 Spark 几乎就像一把瑞士军刀。正如您提到的，它能做一百万件事，但有时候您不想做一百万件事。您只想做一件事，并且希望能够非常轻松地完成那件事。我有个朋友曾在某家企业工作，他提到 Spark 工程师拥有世界上所有的工作保障，原因有二：a，就像您说的，您需要很多人；b，从事这项工作并且深入了解其内部运作和细节非常困难。所以我在这一点上能理解您的意思。

Diptanu Gon Choudhury：是的，我的意思是，我们基本上将计算引擎与存储集成在一起，这样开发者就不必考虑它了。插入任何您想要的存储。显然，我们支持所有的 blob 存储，我们现在支持 Qdrant 和 postgres，Indexify 未来甚至可以支持其他存储引擎。现在，应用程序开发者所需要做的就是将其部署在 AWS 或 GCP 或其他任何地方，对吧？拥有足够的计算资源，将其指向存储系统，然后就可以构建您的应用程序了。您无需做出任何困难的决定，也无需通过将五种不同的工具组合起来花费五个月时间构建数据层，只需专注于应用程序，构建您的智能体即可。

Demetrios：还有一些其他事情。在我们结束之前，我想问您最后一件事，如果大家有任何问题，请随时在聊天中提出。我也正在监控聊天。但我想知道您对于正在构建基于 RAG 应用的人有什么建议吗？因为我感觉您可能在实践中见过不少这样的应用。那么，您见过哪些效果非常好的优化或巧妙的方法？好的。

Diptanu Gon Choudhury：所以我想，首先，有一篇最近的论文，一篇关于 RAG 的综述论文。我非常喜欢它。如果可以的话，您可以在节目笔记中附上链接。有一篇最近的综述论文，我非常喜欢，它涵盖了很多人们在使用 RAG 时可以使用的技巧。但本质上，RAG 是一种信息处理。RAG 本质上是一个两步过程。一个是文档选择过程，一个是文档阅读过程。文档选择是如何从可能存在的数百万份文档中检索出最重要的信息，然后阅读过程是如何将这些信息塞入模型的语境中，以便模型可以根据语境进行生成。

Diptanu Gon Choudhury：所以我认为这里最棘手的部分，也是技巧最多的部分，就是文档选择部分。这就像一个经典的信息检索问题。所以我建议大家在排序算法、查询不同类型的索引以及合并不同索引的结果以优化结果等方面进行大量实验。对我来说，一种始终奏效的方法是以非常系统的方式缩小我选择文档的搜索空间。比如使用某种混合搜索，先进行嵌入查找，然后进行关键词查找，反之亦然，或者并行进行查找然后合并结果。这些缩小搜索空间的方法对我来说总是有效的。

Demetrios：所以我认为 Qdrant 的一位团队成员很想知道，因为我经常和他们谈论这个问题，也就是检索的评估。您在这方面，以及评估检索到的内容的质量方面有什么技巧或建议吗？

Diptanu Gon Choudhury：我还没有找到一个适用于所有用例的“灵丹妙药”式的评估解决方案。评估确实很难。有一些开源项目，比如 ragas，正在尝试解决这个问题，每个人都在尝试解决评估 RAG 的各个方面。有些人尝试评估结果的准确性，有些人尝试评估答案的多样性等等。我认为我们的设计合作伙伴最关心的是事实准确性。一个非常有效的流程是使用一个评审模型。让生成模型生成一些数据，然后让评审模型去查找引用并检查数据的准确性、生成的准确性，然后将这些信息反馈给系统。另一点，回到之前的话题，有什么技巧可以让人很好地使用 RAG 呢？我觉得人们对嵌入模型进行微调得不多。

Diptanu Gon Choudhury：我认为如果人们使用现成的嵌入模型，比如 Sentence Transformer 或其他任何现成模型，他们应该考虑在他们要嵌入的数据集上对嵌入模型进行微调。我认为微调嵌入模型并进行一些事实准确性检查的组合，对于让 RAG 很好地工作大有帮助。

Demetrios：是的，这很有趣。关于那个基本上检查事实准确性的额外模型，我可能就讲到这里。您总是在权衡这些取舍，对吧？其中一个权衡可能是，您可能需要进行另一次 LLM 调用，这可能会更昂贵，但您会获得信任或信心，相信它输出的内容确实如它所说。而且正如您所说，它在事实层面上是正确的。所以这就像，信任的价值有多大？我们回到了我在雪佛兰网站上看到的那个事情，他们说特斯拉更好。希望随着人们部署这些东西，并且认识到人类在玩弄聊天机器人时是多么狡猾，这种情况不再发生。所以这太引人入胜了。感谢您来到这里和我聊天。

Demetrios：我鼓励大家可以通过 LinkedIn 联系您，我知道您在上面，我们也会在聊天中留下您的 LinkedIn 链接。如果不行，可以看看 Tensorlake，看看 indexify，我们会保持联系。这次谈话太棒了。

Diptanu Gon Choudhury：是的，同感。很高兴与您聊这些， Demetrios，感谢您今天的邀请。

Demetrios：干杯。回头再聊。