ToB企服应用市场:ToB评测及商务社交产业平台
标题:
Elasticsearch vs 向量数据库:寻找最佳混合检索方案
[打印本页]
作者:
徐锦洪
时间:
2024-12-11 16:01
标题:
Elasticsearch vs 向量数据库:寻找最佳混合检索方案
图片来自Shutterstock上的Bakhtiar Zein
多年来，以Elasticsearch为代表的基于全文检索的搜索方案，一直是搜索和保举引擎等信息检索体系的默认选择。但传统的全文搜索只能提供基于关键字匹配的准确效果，例如找到包含特别名词“Python3.9”的文档，或是找到带“花”字，“雨”字，“雪”字的古诗词。
但在实际需求中，我们有时间需要的，不但是古诗词中带“雪”字，还要找到表示雪很大如许意向的古诗词。好比，初高中语文课里学到的“忽如一夜春风来，千树万树梨花开”这句诗，虽然没有雪字，却精准表达了雪很大如许的意向。
再以照片检索为例，我们不仅需要1:1精准搜索出图像对应的原图，每每也需要对图像的特征、关键信息提取后，去检索具备雷同特征的图像，完成以图搜图或者内容保举等使命。
怎样通过检索得到以上效果？
基于稠密向量打造的语义搜索就发挥了作用。通常来说，语义检索，通过将我们输入的词汇、图片、语音等原始数据转化为向量，进而捕获差异数据之间的语义关系（例如知道“老师”和“西席”实在是一个意思），可以更精准的明白用户的搜索意图，从而提供更准确、更相干的搜索效果。
但怎样实现语义检索？Embedding模型和向量数据库在此中的作用至关重要。前者主要完成原始信息的向量化，后者则提供对向量化信息的存储、检索等服务。现在，检索加强生成（RAG）与多模态搜索，是语义检索的焦点应用场景之一。
但通常来说，在实践中，全文检索与语义检索不黑白此即彼的关系。我们需要同时分身语义明白和准确的关键字匹配。好比学术论文的写作中，用户不仅盼望在搜索效果看到与搜索查询相干的概念，同时也盼望保留查询中利用的原始信息返回搜索效果，好比基于一些特别术语和名称。
因此，许多搜索应用正在接纳混合搜索方法，团结两种方法的上风，以平衡灵活的语义相干性和可预测的准确关键字匹配。
01.
混合搜索挑战
实现混合搜索的常见方法如下：
先利用像开源Milvus如许的专用向量数据库，进行高效和可扩展的语义搜索；
然后利用像Elasticsearch或OpenSearch如许的传统搜索引擎进行全文搜索。
两两搭配虽然效果不错，但也引入了新的复杂性：起首，搭配两套差异的搜索体系，也就意味着我们要同时管理差异的基础设施、设置和维护使命。这会造成更重的运营负担并增加潜在的集成题目。
在此基础上，混合检索统一解决方案横空出世。
混合搜索的统一解决方案将提供许多利益：
减少基础设施维护：
管理一个体系而不是两个体系大大低落了操作复杂性，节省了时间和资源。这也意味着更少的上下文切换和掌握两组差异API的算力开销。
归并数据管理：
统一的表结构答应用户将麋集（基于向量）和稀疏（基于关键字）数据与共享元数据标签一起存储。利用两个单独的体系，则需要将元数据标签存储两次，以便两边可以或许进行元数据过滤。
简化查询
：单个请求可以实行语义和全文搜索使命，无需对单独的体系进行两次API调用。
加强的安全性和权限改造
：统一的方法可以实现更直接和更强大的安全管理，因为全部访问控制都可以在向量数据库中集中管理，从而提高安全性合规性和一致性。
02.
怎样利用统一的向量方法简化混合搜索
在语义搜索中，呆板学习模型会根据文本的寄义将文本“嵌入”为高维空间中的点（称为麋集向量） 。具有相似语义的文本在此空间中，彼此的距离会更靠近。例如，“苹果”和“水果”就比“苹果”和“汽车”更靠近。这使得我们可以或许通过利用近似最近邻 (ANN)算法盘算每个点之间的距离来快速找到语义相干的文本。
这种方法也可以通过将文档和查询编码为稀疏向量，进而应用于全文搜索。
在稀疏向量中，每个维度代表一个术语，值表示每个术语在文档中的重要性。
文档中不存在的术语的值为零。由于任何给定的文档通常只利用词汇表中全部可能术语的一小部门，因此，大多数术语不会出如今文档中。这也就意味着生成的向量是稀疏的——因为它们的大多数值为零。例如，在通常用于评估信息检索使命的MS-MARCO数据集中，虽然约莫有 900 万个文档，100 万个词，但大多数文档只覆盖不足几百个词，生成的向量中绝大多数维度值为零。
这种极端稀疏性对于我们高效存储和处理这些向量具有重要意义。好比，我们可以将其用于优化搜索性能，同时保持准确性
。
最初为麋集向量设计的向量数据库，实在也可以高效处理这些稀疏向量。例如，开源向量数据库Milvus刚刚发布了利用Sparse-BM25的原生全文搜索功能。
Sparse-BM25 由 Milvus提出，其原理雷同 Elasticsearch 和其他全文搜索体系中常用的BM25算法，但针对稀疏向量设计，可以实现相同效果的全文搜索功能：
具有数据剪枝功能的高效检索算法：
通过剪枝来抛弃搜索查询中的低值稀疏向量，向量数据库可以明显减小索引大小并以最小的质量丧失达成最优的性能。
带来进一步的性能优化：
将词频表示为稀疏向量而不是倒排索引，可以实现其他基于向量的优化。好比：用图索引替代暴力扫描，实现更有用的搜索；乘积量化（PQ）/标量量化（SQ），进一步减少内存占用。
除了这些优化之外，Sparse-BM25还继承了高性能向量数据库Milvus的几个体系级上风：
高效的底层实现和内存管理：
Milvus 的焦点向量索引引擎接纳 C++ 实现，可以提供比基于Java的体系（如Elasticsearch）更高效的内存管理。与基于JVM的方法相比，仅此一项就节省了数 GB 的内存占用。
对MMap的支持：
与Elasticsearch在内存和磁盘中利用page-cache进行索引存储雷同，Milvus支持内存映射（MMap）以在索引凌驾可用内存时扩展内存容量。
03.
为什么传统搜索引擎在向量搜索方面有天赋不足
Elasticsearch是为传统的倒排索引构建的，在不根本改变架构的环境下，支持向量索引具有非常大的挑战。这导致其相比于专用向量数据库有非常大的性能差异：纵然只有100万个向量，Elasticsearch也需要200毫秒（在全托管的 Elastic Cloud 上测试）才能返回搜索效果，而在Milvus上（在全托管的Zilliz Cloud上测试）需要6毫秒——性能差异凌驾30倍。
每秒查询率（QPS）测量的吞吐量也有3倍的差异，Zilliz Cloud上性能最高的实例运行在6,000QPS，而Elastic Cloud最多为1,900QPS。此外，Zilliz Cloud在加载向量数据和构建索引方面比Elastic Cloud快15倍。
此外，Elasticsearch的Java/JVM实现导致其性能的可扩展性也弱于基于 C++/Go 实现的向量数据库。而且，Elasticsearch缺乏高级的向量搜索功能，如基于磁盘的索引（DiskANN、MMap）、优化的元数据过滤和range search。
04.
结论
Milvus 作为性能领先的向量数据库，通过无缝团结语义搜索和全文搜索，将稠密向量搜索与优化的稀疏向量技术相团结，提供了卓越的性能、可扩展性和效率，并简化了基础设施的摆设难度，低落成本的同时还加强了搜索本领。
预测未来，我们信赖基于向量数据库的新型基础设施，将有望逾越Elasticsearch成为混合搜索的尺度解决方案。
作者介绍
陈将
Zilliz 生态和 AI 平台负责人
保举阅读
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)
Powered by Discuz! X3.4
