本文将介绍 Elasticsearch 9.1 中面向稠密向量检索的两项最新改进:适用于带过滤条件的向量检索的新算法 ACORN 量化方法 BBQ 的新实验证据——它不仅能降低成本,甚至还能提升排序质量 ACORN:更聪明的向量过滤检索路径真实场景中的搜索很少是简单的“找类似的东西”。 因此,带过滤条件的向量检索极为常见。如何在不过度牺牲准确度的前提下加速这类检索,一直是技术难题。HNSW 算法本质上是一种图搜索,索引阶段构建图,查询阶段遍历节点。 BBQ 实际上是一个“两阶段检索流程”:广泛扫描(Broad scan)先用极小的压缩向量快速扫描语料,得到一批候选文档(数量通常 > 用户请求的 k,称为 oversampling)。 实验设置:10 个公开数据集,来自 BEIR 三种检索方式 传统 BM25 e5-small 模型生成的 float32 向量 同一模型配合 BBQ 之所以选择 e5-small,是因为我们已知
1 背景上一篇文章《向量检索研究系列:本地向量检索(上)》介绍了如何加快向量相似度计算,但是一般的向量检索流程还包括对计算结果进行排序,以及有必要的话,在计算相似度之前可以对向量库中的向量进行过滤筛选( 图片2.1 向量过滤把广告通过模型转成向量后,向量应该关联广告的一些基本信息,广告检索条件是基于这些广告属性的,检索的时候可以根据检索条件在向量关联的广告信息中进行向量的筛选过滤。 检索时把检索条件在第一个Map中查询到满足检索条件的广告ID列表,再根据ID列表从第二个Map中取出对应向量列表。大致结构可以参考2.2中向量存储方案图。 (2)优化后本地向量检索P99时延降低50倍,平均时延降低180倍。(3)优化后本地向量检索时延分布,99.2的检索时延都在1ms以内。 本地向量检索方案可以为100万以下数据量的业务提供快速、高性能且稳定的向量检索方案。SIMD自定义编程可以在应用到其它偏数学计算的业务,加速计算。
1 背景当广告推荐业务峰值QPS已经达到10万以上,向量检索QPS峰值就会就会达到30万以上,召回服务的向量检索P99时延和平均时延已经超出了能接受的正常范围,导致召回服务整体时延达到上限,很多请求超时以至于没有广告返回给上游服务 在数据量不大但检索QPS非常高的场景下,使用第三方的向量检索产品可能并不一定是最佳选择,像开源的Faiss、HNSWliib和ScaNN这些优秀的向量检索库比较适用于上亿数量级,而且第三方服务毕竟存在网络请求开销和不稳定性因素 但是在业务服务本身做向量检索会消耗比较多的CPU资源和内存资源,CPU资源是比较稀缺的,而且普通的向量检索效率比较低,时延比较长,如何减少资源消耗和加快向量检索效率成为了优化目标。 2.1 Gonum计算向量检索的过程是两个向量按照一定的相似度计算公式进行运算,比如做内积、余弦或欧式距离计算。 但实际上向量检索的流程还有前置的向量过滤(可选流程)和后置的检索结果排序,这两个方面也有进一步优化的空间,以及整体优化后的效果将在下一篇文章《向量检索研究系列:本地向量检索(下)》中进行详细介绍。
基于二进制量化的向量搜索:Elasticsearch使用BBQ技术比OpenSearch搭配FAISS快5倍。 在Elasticsearch 8.18和9.0中,我们重写了量化向量的核心算法。因此,虽然8.16中的BBQ表现良好,但最新版本更为出色。您可以在这里和这里阅读相关内容。 简而言之,每个向量通过优化的标量分位数单独量化。结果是,用户在不影响性能的情况下,享受更高的向量搜索准确性,使Elasticsearch的向量检索更加强大。 这些结果突出了Elasticsearch BBQ在高维向量搜索场景中的效率和性能优势。 在Elastic,我们不断创新,以改进Apache Lucene和Elasticsearch,为搜索和检索用例(包括RAG,检索增强生成)提供最佳的向量数据库。
全文检索 全文搜索是指将部分或全部文本查询与数据库中存储的文档进行匹配。与传统的数据库查询相比,全文搜索即使在部分匹配的情况下也能提供结果。 大语言模型可以处理数据库记录并生成向量嵌入——文档语义的数字表示。然后将这些嵌入存储在向量数据库中。顾名思义,矢量搜索的工作原理是比较相似的矢量。 通过执行向量比较,向量搜索有效地实现了语义搜索。 Elastic Search Elastic Search 引入了带有倒数排名融合 (RRF) 的混合搜索,以结合向量、关键字和语义技术以获得更好的结果。 此版本还提高了向量搜索和摄取的性能,响应时间加快了 30% 以上。 Elasticsearch 用户越来越多地使用不同类型信息的搜索检索 — BM25 用于文本,向量搜索用于密集向量。 混合搜索技术通常会提供更好的结果:对多个 BIER 数据集进行基准测试显示,结合 BM25 和基于 ELSER 的排名时,相关性有所提高,现在用户甚至可以更轻松地组合所有这些检索方法。
1、引言 《Elasticsearch 向量搜索的工程化实战》文章一经发出,收到很多留言。读者对向量检索和普通检索的区别充满了好奇,所以就有了今天的文章。 2、普通搜索 VS 向量搜索 向量搜索已经在黑暗中成长了有些年头了,但是随着近几年机器学习和深度学习的蓬勃发展,“特别是万物皆可 embedding“的观点越来越流行之后,向量搜索才逐渐从小众的技术走入人们的视野之中 以广泛被使用的 Lucene、Elasticsearch、Solr,以及最近出来的一些类似 MeiliSearch、Redisearch 等为代表,基于词元和倒排索引所构建的普通搜索,是建立在准确的搜索内容和检索语句上的 ,他们往往通过各种方式对文档进行分词(analyze),通过诸如BKD tree等数据结构,将拆解出来的词元(token)进行倒排索引,在检索时也会对检索语句进行同样的分词处理,通过相同词元的匹配进行召回 ,通过预先配置的参数对向量进行 KNN 聚类的方式进行索引 召回时会通过寻找较近的核向量的方式来找到 topK 的向量进行 主要包含的一些方式: 2.2.2.3 升级和调优 其他一些可用的开源库 [NGT
结果汇总 向量数据库名称 是否开源(Github Star,数据统计于 2025年3月) 是否有 云版本 支持暴力检索 支持的索引 可视化界面 标量过滤 特点 Annoy 是(13.5k) 无 否 Annoy 功能:将文档生成向量,存储向量及其元数据,检索向量。即将推出:多种数据类型,包括图像、音频、视频等。 = np.random.rand(num_embeddings, 256) project = atlas.map_embeddings(embeddings=embeddings) # 检索向量 neighbors 功能:将文档生成向量,存储向量及其元数据,检索向量。即将推出:多种数据类型,包括图像、音频、视频等。 然后将查询图像转换为向量,并检索出相似的图像。 产品推荐:基于代表用户的向量,为电子商务生成产品推荐。
展示 如何 在 WIndows 系统中 实现 RAG ; 一、关键字检索 和 向量检索 " 关键字检索 " 和 " 向量检索 " 是 信息检索 和 数据检索 领域 中的 检索方法 , 二者各有优劣 , 分别适用于不同的 场景 和 需求 ; 关键字检索 : 适用于对 检索速度 和 精确匹配 要求较高的场景 , 但对语义理解能力有限 , 基本不能理解语义 ; 向量检索 : 适用于需要 语义理解 和 高灵活性 文档中必须有要检索的关键字 , 如果是 关键字 的 同义词 则无法进行检索 ; 应用场景 : 百度搜索引擎 , 图书馆的文献检索系统 ; 2、向量检索 向量检索 基于 向量空间模型 进行检索 , 文档 和 查询词 都被表示为向量 , 检索系统通过 计算 向量之间 的 相似度 来找到相关文档 ; 向量检索特点 : 向量空间模型 : 文档 和 查询词 被 映射 到 高维向量空间 中 , 通常使用 Word2Vec 和 长尾查询 ; 应用场景 : 新一代搜索引擎 、推荐系统 、聊天机器人 、语义搜索 ; 二、向量检索 分析 1、向量 简介 向量 是一个 数学 和 计算机科学 中的基本概念 , 用于 表示具有大小和方向的量
关键词:混合检索|向量数据库|SQLite FTS5|ONNX 嵌入|相似度归一化|候选重排序 在上一篇中,我们了解了 OpenClaw 记忆系统的配置体系。 为此,OpenClaw 构建了一套轻量但强大的混合检索引擎(Hybrid Search Engine),巧妙结合向量语义搜索与全文关键词匹配,在资源受限的边缘设备(如个人服务器)上也能提供接近商业 RAG 一、为什么需要混合检索? 单一策略的局限 混合检索的价值 高召回率(Recall):关键词确保关键信息不丢失 高相关性(Relevance):向量确保语义匹配 鲁棒性:任一子系统失效,另一仍可兜底 OpenClaw 默认采用 结语:混合检索是平衡的艺术 OpenClaw 的混合检索引擎,没有追求最前沿的 ANN 算法或最大规模的向量库,而是在实用性、性能与准确性之间找到最优解。
产品概况1.1 产品对比向量检索领域有着非常多优秀产品,不同的产品有着各自的特性,适用于不同的场景,接下来将对已了解的8款优秀向量检索产品进行简单的介绍。 glove-100-angular (k = 10)数据集的向量检索内积距离top 10测试结果fashion-mnist-784-euclidean (k = 10)数据集的向量检索欧式距离top 10 ScaNN使用了各向异性矢量量化技术提高了向量检索的精度。 2.8 ProximaProxima 是阿里内部达摩院开发的一个通用向量检索引擎框架,类似于Facebook开源的Faiss,支持多种索引类型。架构图优点支持多种向量检索算法。 后续还将进一步分享向量检索的技术详细介绍、测试、应用和思考。4.
向量检索介绍1.1 概念介绍随着互联网的不断发展,产生了各种各样的海量数据,比如图片、文本、视频和语音等非结构化数据,这些数据可以通过人工智能技术提取出特征向量,然后通过对这些特征向量的计算和检索来实现对非结构化数据的分析和检索 ,如何对非结构化的向量数据进行高效检索即为向量检索技术的核心问题。 距离计算向量检索的过程是计算向量之间的相似度,最后返回相似度较高的TopK向量返回,而向量相似度计算有多种方式,不同的计算方式也适用于不同的检索场景。对于浮点型向量和二值型向量有着不同的距离计算方式。 基础算法了解了向量检索的计算相似度方式,如何加快检索速度是研究的重点。 基于图的向量检索算法在向量检索的评测中性能都是比较优异的。如果比较在乎检索算法的效率,而且可以容忍一定的空间成本,多数场景下比较推荐基于图的检索算法。
向量搜索热度不减,所以我们非常有必要将向量搜索和普通搜索结合方式给大家讲清楚。 换句话说,向量搜索和普通搜索的组合检索才是 Elasticsearch 作为向量数据库有别于其他新兴向量数据库的发力点所在。 更多向量检索的先验知识,推荐大家阅读: 干货 | 详述 Elasticsearch 向量检索发展史 高维向量搜索:在 Elasticsearch 8.X 中利用 dense_vector 的实战探索 Elasticsearch:普通检索和向量检索的异同? 2.3.4 官方答案一:Filtered kNN search 如下实现语法的核心:knn 向量检索的里面加了 filter 过滤。
完整流程为:用户输入问题后,直接执行语义相似度检索,通过向量相似度打分筛选出匹配度最高的文档块;随后将检索获取的上下文片段传入 LCEL 执行链,与提示词进行拼接,完成向量检索推理,最终交由大模型生成回答 对话模型输出自然语言文本(供人阅读),向量模型输出浮点型向量数组(供机器计算相似度),是实现RAG检索生成的核心组件。 检索结果2:RAG技术核心流程分为文档加载、文本切片、向量嵌入存储、相似度检索、大模型生成回答五个核心步骤。 同时引入向量距离分数可视化,分数越小语义相似度越高,可直观调试检索质量。 它的工作流程包括文档加载、文本切分、向量化、存入向量数据库、检索、组装Prompt和输出答案。RAG的主要工作流程 包括文档加载、文本切分、向量化、存入向量数据库、检索、组装Prompt和输出答案。
作者 | Maple小七 整理 | NewBeeNLP 稠密向量检索巨大的内存占用一直是限制其落地的一大瓶颈。 虽然DPR能够提供更准确的检索结果,但DPR所生成的向量索引的内存占用是很大的。 Hybrid Search 大量研究已表明结合稀疏向量检索(BM25)和稠密向量检索能够提升性能,其中最简单有效的方法是对分数做线性加权求和: 这里我们简单地设定 ,即稠密检索和稀疏检索等权。 加入混合检索可以进一步提升性能,下图展示了不同压缩方法的检索准确率和索引大小的关系,其中每条曲线从左到右依次为PQ1、PQ2和w/o PQ,图中的黑色虚线为帕累托边界,原始的768维DPR向量并没有落在帕累托边界上 Discussion 限制稠密向量检索模型落地的一大瓶颈就是推理时延和内存消耗的问题,这篇论文通过实验证明了简单的主成分分析加上乘积量化,在辅以稀疏向量检索,就能在保证准确度的前提下大幅减少内存占用,提升检索速度
环境依赖安装 本项目基于LangChain生态、Chroma向量库、ModelScope模型社区开发,依赖文档解析、文本分割、向量检索、重排序模型等核心库。 ,必须使用专门的嵌入模型;本示例使用Qwen3‑Embedding作为向量模型,用于Chroma向量库的文档向量化检索。" [文档2|来源:embedding_note.md] Embedding向量不能直接使用对话型大模型,必须使用专门的嵌入模型;本示例使用Qwen3‑Embedding作为向量模型,用于Chroma向量库的文档向量化检索 ,必须使用专门的嵌入模型;本示例使用Qwen3‑Embedding作为向量模型,用于Chroma向量库的文档向量化检索。" ,必须使用专门的嵌入模型;本示例使用Qwen3‑Embedding作为向量模型,用于Chroma向量库的文档向量化检索。"
本章将通过多个案例实现私有数据集检索功能,虽然 LangChain 也可以实现向量检索,但在企业级项目中,通常会选用 LlamaIndex 这类专门面向检索场景的框架。 向量数据库用来存储文本对应的向量嵌入 4. 向量检索通过计算向量相似度找到相似内容 5. 文本嵌入模型可以把句子转为多维向量 6. 语义检索不依赖关键词匹配,理解句子含义 7. 分块策略会影响知识库检索的效果 使用向量检索代码,先自定义对接本地 embedding 服务LocalLlamaServerEmbedding实现文本向量化,配置OpenAILike接入本地大模型作为LLM 向量数据库用来存储文本对应的向量嵌入。 4. 向量检索通过计算向量相似度找到相似内容。 5. 文本嵌入模型可以把句子转为多维向量。 6. 语义检索不依赖关键词匹配,理解句子含义。 7. 向量数据库用来存储文本对应的向量嵌入;4. 向量检索通过计算向量相似度 找到相似内容;5. 文本嵌入模型可以把句子转为多维向量;6. 语义检索不依赖关键词匹配,理解句子含义;7.
通过压缩存储向量数据,BBQ 提升了效率(高达32倍),并保持高排名质量。详细探讨了 SIMD 指令在 BBQ 中的应用,特别是 x64 上的 AVX 和 ARM 上的 NEON 指令。 BBQ 是一个巨大的进步,通过压缩存储的向量数据,提高了效率(高达32倍),同时保持了高排名质量,并提供了极速的性能。 由于高层次性能已经在 BBQ 博客中详细介绍,这里我们将深入探讨 BBQ 如何实现如此出色的性能。特别是,我们将关注如何通过硬件加速 SIMD(单指令多数据)指令优化向量比较。 BBQ 采用非对称量化;查询向量被量化为 int4,而存储的向量则被进一步压缩到仅一个比特值。由于点积是组件值乘积的总和,我们可以立即看到,只有存储向量为 1 的查询组件值才能对结果产生积极贡献。 在这篇博客中,我们探讨了如何通过硬件加速 SIMD 指令在 BBQ 中优化向量距离比较。你可以在 BBQ 博客 中阅读更多关于索引和搜索性能、准确性和召回率的内容。
什么是AI知识库 传统知识库是关键词匹配 + 人工分类 + 被动查询 + 手动维护;AI 知识库是语义向量检索 + RAG、自动向量化与多模态组织、自然语言问答直接给答案、实时同步自动学习。 答案可以归为七个原因:一套引擎两种检索(dense_vector + BM25,免维护两套系统)、原生向量能力(HNSW/BBQ,无需外挂向量库)、原生混合检索(RRF Retriever 开箱即用)、 向量召回上,dense_vector 字段配合 BBQ 量化有两种选型:bbq_hnsw(量化 + HNSW 图,内存优先、低延迟)与 bbq_disk(量化落盘,规模优先、支撑更大向量)。 横向多集群多索引路由 + 纵向 alias rollover 挑战二:向量内存与存储压力 → bbq_disk 是最优解。 数据无限增长、成本有限——基于磁盘的 bbq_disk 在这个场景下是性能与成本的最优解。 配合 _source excludes 向量字段(检索不依赖原向量),还能省下约一半的冗余存储与 IO。
技术服务 产品标签:#Elasticsearch企业版 #GPU加速索引构建(cuVS) #BBQ #DiskBBQ #SimdVec #TSDB++ #ES|QL #PromQL兼容 #向量数据库 # 时序数据库 #搜索增强引擎 #向量检索 #时序存储 #计算引擎 第四章:方法论说明 研究方法:定量分析(跨公共云实例性能基准对比,如ES BBQ与Milvus IVF RabitQ/HNSW FP32对比 AI 搜索平台整体架构 为各种场景专门优化引擎 02 向量数据库优化 向量算法演进:BBQ → DiskBBQ 全面拥抱硬件加速 GPU 加速索引构建与合并 (NVIDIA cuVS) SimdVec : 自研原生向量计算C++引擎 天下武功唯“快”不破,以BBQ算法为例 03 指标数据库/纯列式数据库优化 TSDB++ 重新构建一个纯列式引擎 替代 Prometheus 与原生支持 PromQL 04 第二章:报告背景和目标 企业搜索正从传统关键词向Agentic AI与多模态混合检索演进,但大规模向量与时序指标场景面临内存瓶颈与查询延迟痛点。
我们用完全相同的 向量 构建了一个原始的 float32 索引和一个 bbq_hnsw 索引,然后测量了两者的内存、磁盘使用情况和检索质量。结果显示,两个索引的磁盘使用情况几乎相同。 这使得最终的检索质量接近于全精度搜索。 BBQ 通过以下三种机制保持了高检索质量:非对称精度(Asymmetric precision):存储的向量每个维度使用 1 比特。 最终,向量体积缩小了约 32 倍,同时检索质量接近于全精度。在文章的下一节中,我们将在一个真实的语料库上测量内存节省和召回率。 BBQ 量化结果总结相同的向量,两种存储格式,一次实验:磁盘占用:大致相同(12.80 MB 对比 13.25 MB)。BBQ 保留了原始的 float 向量以供重新评分和合并使用。