使用 Qdrant 构建高性能实体匹配解决方案 - Rishabh Bhardwaj | 向量空间讲座

“在构建该解决方案的概念验证时，我们最初从 Postgres 开始。但在经过一些实验后，我们意识到它在召回率和速度方面表现不佳……然后我们了解到，与当时存在的其他解决方案相比，Qdrant 的表现要好得多。”
– Rishabh Bhardwaj

HNSW（分层可导航小世界）算法如何使 Rishabh 构建的解决方案受益？

HRS 集团的数据工程师 Rishabh 擅长设计、开发和维护对数据驱动决策过程至关重要的数据管道和基础设施。凭借丰富的经验，Rishabh 对数据工程原则和最佳实践有着深刻的理解。Rishabh 精通 SQL、Python、Airflow、ETL 工具以及 AWS 和 Azure 等云平台，在交付符合业务需求的高质量数据解决方案方面拥有良好的记录。Rishabh 与 HRS 集团的数据分析师、科学家和利益相关者密切合作，确保提供有价值的数据和见解，以支持明智的决策。

在 Spotify、Apple Podcast、Podcast addicts、Castbox 上收听此集。您也可以在 YouTube 上观看此集。

主要收获

数据不一致、重复和实时处理难题？HRS 集团的数据工程师 Rishabh Bhardwaj 有解决方案！

在本集中，Rishabh 深入探讨了如何使用 Qdrant 创建高性能酒店匹配解决方案的细节，涵盖了从数据不一致挑战到通过 HNSW 算法实现的速度和准确性提升的一切。

从本集学习的 5 个关键点

1. 了解数据一致性的重要性以及在处理多个来源和语言时带来的挑战。
2. 了解 Qdrant（一个开源向量数据库）如何超越其他解决方案，并为高速匹配提供高效解决方案。
3. 探索 Qdrant 中 HNSW 算法的独特修改以及它如何优化了解决方案的性能。
4. 深入探讨地理过滤的关键作用以及它如何确保基于酒店位置的准确匹配。
5. 深入了解 GDPR 合规性和酒店数据安全处理方面的考虑。

趣闻：您知道 Rishabh 和他的团队尝试了多种 Transformer 模型，以找到最适合他们的实体解析用例的模型吗？最终，他们发现 Mini LM 模型在速度和准确性之间取得了完美的平衡。这真是一个成功的组合！

笔记

02:24 来自不同来源的数据不一致且复杂。
05:03 使用 Postgres 进行概念验证，后改用 Qdrant 获得更好结果
09:16 地理过滤对于验证我们的匹配至关重要。
11:46 性能指标和基准测试的洞察。
16:22 我们尝试了不同的值并找到了所需的数字。
19:54 我们尝试了不同的模型并找到了最好的模型。
21:01 API 网关连接多个客户端进行实体解析。
24:31 支持多种语言，使用转录 API 提高准确性。

Rishabh 的更多语录

“主要挑战之一是数据不一致。”
– Rishabh Bhardwaj

“因此，唯一知道哪个模型适合我们的方法是，再次在我们自己的数据集上对模型进行实验。但在进行这些实验后，我们意识到这是在速度和嵌入准确性之间提供最佳平衡的最佳模型。”
– Rishabh Bhardwaj

“Qdrant 基本上对计算资源进行了大量优化，这也帮助我们以真正高效的方式扩展了整个基础设施。”
– Rishabh Bhardwaj

文字记录

Demetrios：向量空间中的各位同行，敢称你们为宇航员吗？今天我们与 Rishabh 进行了一场精彩的对话，我很高兴大家加入了我们。Rishabh，很高兴你来到这里，伙计。你怎么样？

Rishabh Bhardwaj：谢谢你邀请我，Demetrios。我很好。

Demetrios：太棒了。我喜欢听到这个。我知道你在印度。那里有点晚了，所以我很感谢你今天抽出时间来参加我们的向量空间讲座。你有很多要讲的内容。对于不认识你的人，你是 HRS 集团的数据工程师，你负责设计、开发和维护支持公司的数据管道和基础设施。我很高兴，因为今天我们将讨论如何使用 Qdrant 构建高性能酒店匹配解决方案。当然，这里有一个小秘密。

Demetrios：我们想了解你是如何做到这一点的，以及你是如何利用 Qdrant 的。来谈谈吧，伙计。我们开始吧。我想了解一下，请给我们一个关于这到底是什么的快速概述。我给出了标题，但我认为你可以告诉我们更多关于构建这个高性能酒店匹配解决方案的信息。

Rishabh Bhardwaj：当然。首先，简要介绍一下这个项目。我们在内部数据库中拥有一些数据，并且我们定期从不同来源摄取大量数据。HRS 基本上是一家专注于商务旅行的全球科技公司，我们拥有欧洲使用最广泛的酒店预订门户之一。因此，对客户满意度很重要的主要事情之一是我们门户上提供的内容。对。因此，我们面临的问题或主要挑战基本上是我们从不同来源摄取的数据本身。主要挑战之一是数据不一致。

Rishabh Bhardwaj：因此，不同的来源提供不同格式的数据，不仅是不同格式。它也以多种语言出现。几乎欧洲和世界其他地区使用的所有语言。因此，数据主要来自 20 种不同的语言，这使得整合和分析这些数据变得非常困难。而且数据中的这种不一致性经常导致数据解释和决策中出现许多错误。此外，还存在数据重复的挑战，因此相同的信息可能在不同来源中以不同方式表示，这又可能导致数据冗余。识别和解决这些重复又是一个重大挑战。然后我能想到的最后一个挑战是，这个数据处理是实时发生的。

Rishabh Bhardwaj：因此，我们不断地从多个来源接收数据流，实时处理和更新这些信息是一项非常艰巨的任务。是的。

Demetrios：当您谈论数据重复时，您是指相同的信息用法语和德语表示吗？还是指相同的列，只是在表格中以不同的方式表示？

Rishabh Bhardwaj：实际上，两种情况都有，所以相同的实体可以以多种语言出现。然后，第二件事也是，哇。

Demetrios：好的，酷。这为我们设定了场景。现在，我感觉你带来了一些幻灯片。随时分享你想要的幻灯片。我将提出第一个问题，并询问这个问题。我将直接进入 Qdrant 问题，并请你详细说明 Qdrant 对 HNSW 算法的独特修改如何使你的解决方案受益。那么，你在那里做了什么？你是如何利用它的？以及如何再增加一个层面到这个问题，这个我开始陷入的荒谬冗长的问题，你是如何处理基于经纬度的地理过滤的？所以，总结我冗长的问题，我们先从 HNSW 算法开始。它如何使你的解决方案受益？

Rishabh Bhardwaj：好的。首先，我先讲一些背景故事。当我们为这个解决方案构建概念验证时，我们最初从 Postgres 开始，因为我们在开发环境中有一些 Postgres 数据库，我们只是想尝试构建一个概念验证。所以我们安装了一个名为 Pgvector 的扩展。当时，它使用 IVF Flat 索引方法。但是经过一些实验后，我们意识到它在召回率和速度方面表现不佳。基本上，如果我们想提高速度，那么我们将在召回率方面遭受很大损失。然后我们开始寻找市场上的原生向量数据库，然后我们看到了一些基准测试，我们了解到 Qdrant 与当时存在的其他解决方案相比，性能要好得多。

Rishabh Bhardwaj：而且，它是开源的，而且非常容易托管和使用。我们只需要在 EC2 实例中部署一个 docker 镜像，我们就可以真正开始使用它。

Demetrios：你们也做了自己的基准测试吗？还是说，你们只是看了看，然后就说，好吧，让我们试试这个？

Rishabh Bhardwaj：所以在最初决定时，我们只查看了公开可用的基准测试，但后来，当我们开始使用 Qdrant 时，我们在内部进行了自己的基准测试。不错。

Demetrios：好的。

Rishabh Bhardwaj：我们只是在其中一个 EC2 实例中部署了一个 Qdrant 的 Docker 镜像，然后开始进行实验。很快我们就意识到它用于构建向量索引的 HNSW 索引算法非常高效。我们注意到，与 PG Vector IVF Flat 方法相比，它快了大约 16 倍。这并不意味着它不准确。实际上，它比之前的结果准确 5%。等等。

Demetrios：快 16 倍，准确 5%。为了让所有听众都知道，我们没有付钱让你说这些，对吧？

Rishabh Bhardwaj：不，一点也没有。

Demetrios：好的，继续说。我喜欢。

Rishabh Bhardwaj：是的。因此，在实验初期，我们从 Qdrant 提供的 HNSW 算法的默认值开始。我刚才告诉你的这些基准测试就是基于这些参数的。但随着我们用例的演变，我们还对 Qdrant 允许我们在索引算法中指定的 M 和 EF construct 的多个值进行了实验。

Demetrios：对。

Rishabh Bhardwaj：另外一件事是，Qdrant 还提供了在进行搜索时指定这些参数的功能。因此，这并不意味着如果我们最初构建了索引，我们就只能使用这些规范。我们也可以在搜索过程中再次指定它们。

Demetrios：好的。

Rishabh Bhardwaj：是的。所以我们的一些用例需要 100% 的准确性。这意味着在这些用例中我们根本不需要担心速度。但是有些用例中速度非常重要，当我们需要匹配像百万级别的数据集时。在这些用例中，速度非常重要，我们可以在准确性方面进行一些调整。所以，是的，Qdrant 为索引提供的这种配置确实对我们的方法有所帮助。

Demetrios：好的，然后融入所有关于如何处理地理过滤的乐趣。

Rishabh Bhardwaj：所以地理过滤也是我们解决方案中一个非常重要的功能，因为我们数据中处理的实体主要由酒店实体组成。对。酒店实体通常带有地理坐标。因此，即使我们使用其中一个嵌入模型进行匹配，我们也需要确保模型与某个余弦相似度匹配的结果也是真实的。为了验证这一点，我们使用地理过滤，它也与 Qdrant 堆叠在一起。所以我们从内部数据库提供地理坐标数据，然后我们将其与从多个来源获取的数据进行匹配。它还有一个半径参数，我们可以提供该参数进行调整。我们希望在多大半径内进行过滤？

Demetrios：是的。有道理。我想象酒店位置信息可能是您为人们提供的拼图中非常重要的一部分。那么，在您做这件事的时候，有哪些事情变得非常重要？我知道您提到了与欧洲合作。有很多 GDPR 方面的担忧。您是否必须解决隐私方面的考虑？在处理酒店数据时，是否存在安全方面的考虑？向量、嵌入，您是如何管理所有这些的？

Rishabh Bhardwaj：所以 GDP 合规性？是的。它在这个整体解决方案中扮演着非常重要的角色。

Demetrios：那本来是要竖起大拇指的。我不知道发生了什么。继续说。抱歉，我打断了。

Rishabh Bhardwaj：没关系。是的。所以 GDPR 合规性也是我们在构建此解决方案时考虑的关键因素之一，以确保没有任何东西超出合规范围。我们基本上将 Qdrant 部署在一个私有 EC2 实例中，它也受到 API 密钥的保护。此外，我们还使用 Microsoft Azure SSO 构建了自定义身份验证工作流。

Demetrios：我明白了。所以还有一些我想问的事情，但我想开放讨论。有听众和观众在直播。如果有人想在聊天中提出任何问题，请随时提出，我会回答。同时，当人们输入他们想和你讨论的内容时，你能告诉我们任何关于性能指标的见解吗？以及你进行的这些基准测试，你看到了什么，我想你说的是快 16 倍，然后准确率高 5%。那是什么样子？你做了哪些基准测试？你是如何进行基准测试的？所有这些有趣的事情。以及如果其他人想进行基准测试，有哪些事情需要记住？我想你只是在与 Pgvector 进行基准测试，对吧？

Rishabh Bhardwaj：是的，我们做了。

Demetrios：好的，酷。

Rishabh Bhardwaj：因此，为了进行基准测试，我们有一些已经与某些实体匹配的数据集。这是部分由人工完成，部分由我们过去用于匹配的其他算法完成。它已经是整合的数据集，我们再次将其用于基准测试目的。然后我指定的基准测试仅针对 PG vector，我们没有进一步进行基准测试，因为 Qdrant 提供的速度和准确性，我认为它已经涵盖了我们的用例，而且它比我们想象的解决方案要快得多。所以目前我们没有针对任何其他向量数据库或任何其他解决方案进行基准测试。

Demetrios：有道理，只是为了在我的脑海中形成一个概念，我有点跳来跳去，所以请原谅。酒店的语义组成部分是文本描述还是图像，或者两者兼而有之？所有这些？

Rishabh Bhardwaj：是的。语义仅来自酒店的描述，目前不包括图像。但在未来的用例中，我们也在考虑使用图像来计算两个实体之间的语义相似性。

Demetrios：不错。好的，酷。很好。我是一个视觉型的人。你也有幻灯片给我们，对吧？如果我没记错的话？你想分享它们，还是想让我继续提问？我们收到了 Brad 在聊天中的一个问题，也许在你分享任何幻灯片之前，应用程序 UI 中是否有地图可视化？你能谈谈你使用了什么吗？

Rishabh Bhardwaj：如果可以的话，现在还没有，但这确实是一个很棒的想法，我们会尽快尝试实现它。

Demetrios：是的，有道理。你可以拖动，然后看到在这个区域内有多少家酒店，它们长什么样，等等。

Rishabh Bhardwaj：是的，当然。

Demetrios：太棒了。好的，所以，是的，随时分享你的幻灯片，否则我可以在这段时间里再问你一个问题，那就是我想知道你在 Qdrant 中用于 HNSW 索引的配置是什么，每个节点的边缘数量和在索引构建过程中要考虑的邻居数量是多少。所有这些细节。

Rishabh Bhardwaj：我应该先讲幻灯片还是先回答你的问题？

Demetrios：可能先回答问题，这样我们就不会跑题太远，然后我们可以再看你的幻灯片。我敢肯定，幻灯片会引发我和观众的许多其他问题。

Rishabh Bhardwaj：所以，对于 HNSW 配置，我们将 M 的值（我想它基本上是层）指定为 64，EF construct 的值为 256。

Demetrios：你是怎么做到的？

Rishabh Bhardwaj：所以我们又做了一些基准测试，基于我们选择的单一模型，即 Mini LM L6 V2。我稍后也会谈到它。但我们基本上尝试了 M 和 EF construct 的不同值，最终得出了我们希望采用的这个数字。此外，当我说在某些情况下根本不需要索引，根本不需要速度时，我们希望确保我们匹配的所有内容都是 100% 准确的。在这种情况下，Qdrant 的 Python 客户端还提供了一个名为 `exact` 的参数，如果我们将它指定为 true，那么它基本上不使用索引，而是对整个向量集合进行完整搜索。

Demetrios：好的，所以有些东西对我来说非常有趣，这些不同的用例。在不同的用例中还有什么不同？因为你对速度或准确性有特定的需求。看起来这些是你主要权衡的因素。你设置事物的方式有什么不同？

Rishabh Bhardwaj：所以在某些情况下，有些内部数据库需要以非常复杂的方式存储酒店实体。这意味着它不应该包含哪怕一个重复的实体。在这些情况下，准确性是我们最看重的东西，而在某些情况下，为了数据分析和整合目的，我们更看重速度，但准确性的价值不应那么高。

Demetrios：那在实践中是怎样的呢？因为你提到了，好的，当我们在追求准确性时，我们会确保它通过所有不同的记录。对。在实践中，你还做了其他不同的事情吗？

Rishabh Bhardwaj：不，真的没有。现在想不出什么。

Demetrios：好的，如果有什么，我会提醒你，但是，伙计，给我们看幻灯片吧。你为视觉学习者准备了什么？

Rishabh Bhardwaj：好的。我有一张解决方案架构图，它现在的样子。所以，这是我们目前在生产中的架构。正如我所提到的，我们将 Qdrant 向量数据库部署在 EC2 私有实例中，托管在 VPC 内部。然后我们有一些批处理作业在运行，它们基本上创建嵌入。源数据首先进入 S3 存储桶，进入数据湖。我们进行一些预处理数据清理，然后通过批处理过程使用 Mini LM 模型，Mini LML6 V2 生成嵌入。这个模型基本上托管在 SageMaker 无服务器推理端点中，这使我们无需担心服务器，并且我们可以根据需要进行扩展。

Rishabh Bhardwaj：它确实帮助我们以非常快的方式构建嵌入。

Demetrios：你为什么选择那个模型？你尝试了不同的模型，还是说这个模型效果足够好，你就用了它？

Rishabh Bhardwaj：不，实际上这是我们尝试的第三个或第四个模型。所以现在发生的情况是，如果我们要执行句子相似度等任务，然后我们去网上寻找一个模型，很难知道哪个模型在我们的用例中表现最好。所以，唯一知道哪个模型适合我们的方法是，再次在我们自己的数据集上对模型进行实验。所以我们做了很多实验。我想我们使用了 Mpnet 模型和许多多语言模型。但在进行这些实验后，我们意识到这是在速度和嵌入准确性之间提供最佳平衡的最佳模型。所以我们将其部署在 SageMaker 的无服务器推理端点中。一旦我们在 Glue 作业中生成了嵌入，我们就会将它们存储到向量数据库 Qdrant 中。

Rishabh Bhardwaj：然后这部分就是实时场景中发生的事情。所以，我们有多个客户端，基本上是多个应用程序会连接到一个 API 网关。我们以这样一种方式公开了这个 API 网关，即多个客户端可以连接到它，并且他们可以根据自己的用例使用这个实体解析服务。我们接受不同的参数。有些是强制性的，有些不是强制性的，然后他们可以根据自己的用例使用它。API 网关连接到一个 Lambda 函数，该函数基本上使用可以从我们托管在无服务器推理端点中的相同模型生成的相同嵌入对 Qdrant 向量数据库执行搜索。所以，是的，这就是目前的图表。它在一段时间前并不是这样，但我们已经对其进行了演进、开发，现在我们已经达到了这样一个地步，即它真正可扩展，因为我们在这里使用的大部分基础设施都是无服务器的，并且可以扩展到您想要的任何请求数量。

Demetrios：你之前是什么样的 MVP？

Rishabh Bhardwaj：因此，我们之前有一个实时推理端点，它基本上将我们的请求数量限制为我们在部署模型时预设的一些数量。这是瓶颈之一，然后 Lambda 函数一直都在，我想这个，而且我想在 Qdrant 向量数据库的位置，正如我提到的，我们有 Postgres。所以，是的，那也是一个限制，因为它与 Qdrant 相比，在 EC2 实例内使用了大量的计算能力。Qdrant 基本上对计算资源进行了大量优化，这也帮助我们以真正高效的方式扩展了整个基础设施。

Demetrios：太棒了。酷。这太引人入胜了。从我的角度来看，我喜欢看到你所做的工作以及你是如何迭代架构的，从已有的东西开始，然后对其进行优化。所以这个项目已经进行了多久了？从零到一的第一个 MVP，现在感觉你正在从一到无限进行优化。时间框架是多久？

Rishabh Bhardwaj：我想我们是今年五月开始的。现在已经五六个月了。我们构建的第一个工作解决方案大约花了一个半月，然后从那时起，我们一直努力迭代，使其变得越来越好。

Demetrios：酷。非常酷。聊天中出现了一些很棒的问题。您是否支持多种语言的酒店名称？如果是，您在这些映射中遇到过任何问题吗？

Rishabh Bhardwaj：是的，我们确实支持多种语言，我们目前不使用多语言模型来实现，因为我们意识到多语言模型是基于普通句子构建的，而不是基于实体（如名称、酒店名称和旅客名称等）进行训练的。因此，当我们使用多语言模型进行实验时，它没有提供令人满意的结果。所以我们使用了 Google 的转录 API，它能够基本上翻译我们数据中的许多语言，并且在实体解析方面确实提供了令人满意的结果。

Demetrios：太棒了。在评估中还考虑了哪些其他 Transformer？

Rishabh Bhardwaj：我记忆中主要的有 Mpnet，还有一个叫 Text to VEC 的中文模型，Shiba something 和 Bert uncased，如果我没记错的话。是的，这些是其中一些模型。

Demetrios：我们考虑过，但没有任何一个表现特别好，还是说你必须在所有模型上进行权衡？

Rishabh Bhardwaj：所以，在准确性方面，Mpnet 比 Mini LM 稍微好一点，但它比 Mini LM 模型慢很多。它比 Mini LM 模型慢了大约五倍，所以放弃它并不是一个很大的权衡。所以我们决定继续使用 Mini LM。

Demetrios：太棒了。伙计，这真是令人大开眼界。我非常感谢你来到这里做这个。如果其他人对你有什么问题，我们会在聊天中留下你的所有联系方式。Rishabh，非常感谢你。这太酷了。感谢你来到这里。任何正在听的人，如果你想参加向量空间讲座，请随时与我联系，我会安排。 

Demetrios：看到大家所做的不同工作以及你们如何推动游戏发展，这真的很酷。我非常感谢这一点。

Rishabh Bhardwaj：谢谢你，Demetrios。谢谢你的邀请，祝你有个美好的一天。