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

“在我们构建这个解决方案的概念验证时，最初我们从 Postgres 开始。但在进行了一些实验后，我们发现它在召回率和速度方面的表现基本上不太好……然后我们了解到，与当时存在的其他解决方案相比，Qdrant 的性能要好得多。”
– Rishabh Bhardwaj

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

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

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

要点总结

数据不一致、重复以及实时处理方面的挑战？HRS Group 数据工程师 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 Group 的数据工程师，负责设计、开发和维护支持公司的数据管道和基础设施。我很兴奋，因为今天我们要讨论的是如何使用 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 内的私有 EC2 实例。然后我们运行一些批处理作业，这些作业主要负责创建嵌入。源数据首先进入 S3 桶，形成一个数据湖。我们进行一些预处理和数据清洗，然后通过批处理过程使用 Mini LM 模型，即 Mini LM L6 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。所以是的，那也是一个限制，因为它在 EC2 实例中使用的计算容量比 Qdrant 多得多。Qdrant 在计算资源利用方面进行了大量优化，这也帮助我们以非常高效的方式扩展了整个基础设施。

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

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

Demetrios：很酷。非常酷。聊天中有很多很棒的问题。你们是否支持多种语言的酒店名称？如果是，在进行这类映射时是否遇到过问题？

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

Demetrios：太棒了。评估时还考虑了哪些其他的 Transformer 模型？

Rishabh Bhardwaj：我能立刻想起来的有 Mpnet，然后有一个中文模型叫做 Text to VEC，还有 Shiba 什么的，以及 Bert uncased，如果我没记错的话。是的，这些是一些模型。

Demetrios：你们考虑了这些模型，是没有哪个表现特别突出，还是说你们都需要在所有模型上做出权衡？

Rishabh Bhardwaj：所以就准确度而言，Mpnet 比 Mini LM 稍好一些，但它比 Mini LM 模型慢很多。它比 Mini LM 模型大约慢五倍，所以这不是一个划算的取舍。因此我们决定采用 Mini LM。

Demetrios：太棒了。伙计，这真的让人受益匪浅。非常感谢你来到这里做这个。如果还有人对你有任何问题，我们会把你的联系方式留在聊天中。Rishabh，非常感谢你。这太酷了。感谢你来到这里。各位听众，如果你们想参加向量空间对话，请随时联系我，我会安排的。

Demetrios：看到大家所做的不同工作，以及你们是如何推动这个领域的进步，这真的很酷，伙计们。我非常感谢。

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