1. 先从一次搜索需求说起大概在半年前我接到一个内部需求现有系统里存了几十万条短文本数据用户想按“语义相似”而不是“关键词匹配”来检索。比如输入“怎么给猫洗澡”系统要能召回“猫咪沐浴的正确姿势”“宠物清洁护理要点”这类内容而不是只匹配包含“洗澡”两个字的条目。当时团队里有人提议直接上专门的向量数据库有人建议用开源的本地向量检索方案最后我们选了Elasticsearch。原因不复杂现有业务数据已经在ES里跑了好几年与其多维护一套存储引擎不如让ES自己把向量检索这块能力接住。如果你也面临类似的选择这篇文章应该能帮你少走不少弯路。我会从向量检索的基本逻辑讲起到ES里怎么建索引、怎么写查询再讲到生产环境里常见的坑。整套内容是基于真实项目实操总结出来的不是照着文档念一遍。2. 为什么需要在ES里做向量搜索2.1 关键词匹配的先天局限传统ES搜索依赖倒排索引本质上是字面匹配文档里有这个词query里有这个词就能命中。它理解不了“同义”“近义”“上下文语义”。举个很典型的例子搜索“手机屏幕碎了怎么办”如果文档里写的是“液晶面板破裂维修指南”关键词搜索大概率召回不了。因为“屏幕”和“液晶面板”之间没有字面上的交集。这不是分词器调一调就能解决的分词只能解决“词形”问题解决不了“语义”问题。向量搜索的出发点完全不同。它先把文本、图片、音频等内容通过模型映射成一个高维向量比如256维、768维、1024维然后在这个向量空间里计算两个向量的距离。语义相近的内容向量距离就小语义无关的内容向量距离就大。这样“手机屏幕碎了”和“液晶面板破裂”就可能落在相近的区域检索自然就召回了。2.2 专门向量数据库的优劣势市面上的专用向量数据库比如Milvus、Qdrant、Weaviate确实做得很优秀尤其在几千万上亿级别的向量规模下性能和成本控制都很好。但引入一个新数据库意味着额外维护一套集群监控、告警、备份都要重做业务系统多一个依赖数据同步要做双写或者订阅变更团队需要掌握一个新的查询语法学习成本不是零如果业务场景里向量检索只是其中一个功能而不是核心存储底座那这件事的ROI需要认真掂量。尤其是中小团队人力紧张运维成本敏感能复用现有的ES集群是最省心的一条路。2.3 ES做向量搜索的底气来源ES从7.x版本开始逐步引入向量能力到8.x已经非常成熟支持dense_vector字段类型存储浮点型向量内置多种相似度度量cosine、dot_product、l1、l2提供kNN搜索API支持HNSW算法支持在向量检索的同时叠加传统filter条件关键词、范围、布尔条件等可以跟BM25进行混合检索这意味着什么意味着你不需要在“语义搜索”和“关键词搜索”之间二选一可以两套机制共存互相补充。比如先做一次向量召回再用传统条件过滤业务字段这是一个相当实用的组合姿势。3. 向量相似性搜索的核心概念拆解3.1 什么是向量空间模型向量空间模型Vector Space Model这个说法看起来很学术其实本质不复杂。你可以把一篇文档想象成高维空间里的一个点维度由模型决定。假设模型输出768维向量那这个点就处在768维空间里。所有文档的点共同构成一个“空间”点在空间里的相对位置关系就是语义关系的几何表达。距离可以使用不同的度量方式。最常用的几个欧氏距离l2两点之间的直线距离数值越小越相似曼哈顿距离l1各维度差值绝对值之和对异常值更敏感余弦相似度cosine两个向量的夹角余弦值值越大越相似。它忽略向量的绝对长度只关注方向内积dot_product向量各维度乘积之和。在向量归一化后它和余弦相似度等价实际使用中文本场景最推荐余弦相似度因为文本向量的绝对长度往往和词频之类因素相关方向更能反映语义内容。商品推荐、图像场景则要根据embedding模型的具体处理方式来判断。3.2 Embedding模型的选择逻辑ES只负责存储和计算不负责把内容变成向量。向量从哪里来需要外部embedding模型。这一步的选择非常关键因为向量质量直接决定检索效果索引算法再优化也弥补不了embedding的缺陷。常见方案通用文本向量模型比如各类开源Embedding模型适合短文本匹配、语义检索领域微调模型如果业务词汇比较专业比如法律、医疗、金融通用模型效果可能不理想需要用领域语料微调多模态模型如果内容包含图片、图文混合需要选择支持图文对齐的模型选型时注意几点向量维度不是越高越好维度高代表信息丰富但内存占用线性增长检索性能也会下降。768维和1024维在普通业务规模下差别不大但在千万级数据量下内存差距就是几十G级别同一模型产出的向量之间才有比较意义不要混用不同模型的向量中文场景特别要注意模型的中文能力。3.3 递归地看为什么HNSW算法适合ESES内置的kNN搜索基于HNSWHierarchical Navigable Small World算法。这个算法属于近似最近邻ANN搜索不是精确搜索但能在可接受精度损失下大幅提升检索效率。HNSW的核心思想可以理解为一种多层图结构底层包含所有向量越往上层的点越稀疏。搜索时从顶层开始每次在当前层贪心地找最近的点然后下到下一层继续层层逼近真正的最近邻。这个过程的复杂度大约是对数级别的。这里有个重要权衡HNSW的搜索精度和召回率不是百分百但配合合适的参数ef_search、ef_construction、M值可以把召回率做到95%以上而性能比暴力线性扫描快几个数量级。对这种“近似”特性要心里有数不要在要求严格精确的场景里依赖它。注意如果你的数据量很小比如几千条精确的暴力扫描script_score 余弦相似度可能比kNN更快且更准。HNSW的优势在数据量大的时候才明显。4. 实操在ES里构建向量检索全流程4.1 环境准备与索引设计ES版本至少需要8.0以上我实际使用的是8.11版本。7.x的dense_vector功能不那么完整一些参数不支持建议直接上8.x。先创建索引指定dense_vector字段。这里用一个简化但真实的例子内容摘要搜索场景文档包含标题、正文、标签和摘要向量。PUT /content_index { mappings: { properties: { title: { type: text, analyzer: ik_max_word }, body: { type: text, analyzer: ik_max_word }, tags: { type: keyword }, summary_vector: { type: dense_vector, dims: 768, index: true, similarity: cosine, index_options: { type: hnsw, m: 16, ef_construction: 100 } } } } }几个字段参数说明dims向量维度必须和embedding模型输出的维度完全一致这个值一旦创建不可修改similarity相似度度量我这边用的cosine。注意ES的cosine定义是返回值越大代表越相似取值为[-1, 1]区间index_options.m每个节点在HNSW图中的最大连接数。值越大图越稠密召回率越高但内存占用越大。经验值16-32之间index_options.ef_construction建索引时的动态候选集大小影响索引质量和构建速度。100是个常用起点值越大质量越好但构建越慢4.2 向量数据的写入写入数据时向量字段直接作为普通JSON数组传入。这里的关键是向量必须由embedding模型提前算好。from elasticsearch import Elasticsearch from sentence_transformers import SentenceTransformer model SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) es Elasticsearch([{host: localhost, port: 9200}]) # 假设content是待索引的文本 summary 猫咪日常清洁护理的完整指南包括洗澡频率、水温控制与吹干技巧 vector model.encode(summary).tolist() doc { title: 猫咪洗澡指南, body: summary, tags: [宠物, 清洁], summary_vector: vector } es.index(indexcontent_index, documentdoc)写入时的几个注意事项建议用批量接口bulk写入单条逐条写入在大数据量下吞吐太低。我在项目里是每500条一批实测吞吐比单条写入快大概10倍向量字段与其他普通字段在同一个doc里ES会一起索引不需要额外维护关系如果数据源是数据库可以用Logstash或者自建同步任务向量化环节放在ETL过程中做4.3 向量搜索的两种主流写法方式一kNN搜索API这是ES 8.x推荐的标准方式语法清晰性能好POST /content_index/_search { knn: { field: summary_vector, query_vector: [0.012, 0.033, ...], k: 10, num_candidates: 100 } }k返回最相似的10条结果num_candidates每一分片候选集大小。这个值越大结果越接近真实最优但性能开销越高。经验值是k的5~10倍方式二script_score查询这种方式适合需要精确计算相似度或做复杂评分融合的场景POST /content_index/_search { query: { script_score: { query: { match_all: {} }, script: { source: cosineSimilarity(params.queryVector, summary_vector) 1.0, params: { queryVector: [0.012, 0.033, ...] } } } } }注意script_score里cosineSimilarity返回范围是[-1, 1]ES要求分数非负所以需要1.0偏移。这个写法灵活但性能比kNN差因为它是线性扫描所有doc没有利用HNSW索引。4.4 混合检索向量 传统过滤实际业务很少只需要“纯向量搜索”通常要带各种业务限制。比如只想搜“宠物”标签下的内容或者排除某些状态的数据。ES的kNN API支持在搜索时叠加过滤条件POST /content_index/_search { knn: { field: summary_vector, query_vector: [0.012, 0.033, ...], k: 10, num_candidates: 100, filter: { term: { tags: 宠物 } } } }更高级的玩法是向量搜索和BM25关键词搜索并行结果用RRFReciprocal Rank Fusion做融合排序。ES 8.8之后的版本原生支持RRF可以直接在search里同时写knn和query两个部分这个方案的实用价值在于向量搜索擅长处理同义词和语义泛化BM25擅长精确匹配专有名词。两者融合后既不会漏掉“显示屏”和“屏幕”这种语义等价词也不会漏掉“iPhone 15 Pro Max”这种需要精确匹配的型号词。我在实际项目中用了这个方案后检索的NDCG指标比纯向量高了不少。5. 向量化处理环节的工程细节5.1 Embedding效率优化从业务文本到向量的转换环节往往是整个链路中最耗时的部分。如果调用外部API来embedding比如某些云服务单条几十毫秒甚至上百毫秒几百万数据量就是几十小时级别。做法上有两类优化批量请求多数embedding服务支持批量输入一次传几十条文本进去减少网络往返。实测批量32条的吞吐量是逐条的20倍左右瓶颈往往在网络IO。本地模型如果团队有GPU或者高性能CPU可以部署本地embedding模型用sentence-transformers这类库加载模型直接在离线的ETL任务里跑。我试过用一个小型模型在8核CPU的机器上处理200万条短文本大约用了不到5小时速度完全可以接受。5.2 向量维度一致性的坑这是入门最容易踩的坑embedding模型换了一个或者模型输入配置修改导致输出维度变化而索引已经建立在旧的维度上。dense_vector的dims参数在索引创建后就锁定了没法改。这种情况下只能创建新索引重新写入全部数据。数据库迁移的最佳实践是在索引命名里带上版本号或者模型标识比如content_index_v3_768dim。如果哪一天换模型了直接建新索引数据双跑切换查询时用别名。ES的别名机制在这里很关键。5.3 增量数据如何处理索引不是一次建完就完事的业务每天都在产出新内容。增量处理的逻辑是新文档写入数据库 - 触发embedding计算 - 写入ES。这步要保证幂等性防止重复写入导致向量重复。我这边用了简单的方案在内部消息队列中发一个“内容更新”事件消费者收到事件后读取最新内容计算向量然后upsert到ES。用文档的id字段做唯一标识重复消费时也能保证最终一致。6. 常见问题与排查技巧实录6.1 查询结果不理想召回了一堆不相关内容排查思路先看向量本身有没有问题。把query文本和几条召回文档文本拿出来分别算一下向量再手动计算余弦相似度。如果手动算出来的相似度很高但肉眼看内容明显不相关问题大概率出在embedding模型上——模型没有理解这类内容。另一个常见原因是query和生产内容的文本分布不一致。比如生产内容全是宠物医疗领域的用户query却是日常口语化的闲聊。这种情况可以考虑对领域数据微调embedding模型或者增加一个BM25关键词通道作为兜底。6.2 性能差查询响应时间几百毫秒检查几个地方确认查询走了knn API而不是script_scorescript_score是线性扫描数据量过万就会明显变慢确认dense_vector字段的index设为true如果false等于没有建HNSW索引只能暴力扫描num_candidates设置过大导致每个分片排序开销高建议从k值的3倍开始调核对每个分片的容量分片过大或者数据倾斜会让单分片检索开销偏高6.3 内存占用居高不下HNSW结构会常驻内存你不用它索引时它不加载一旦有查询触发索引就载入JVM堆外内存。如果你的向量数据量很大比如1000万条768维向量大概需要的内存是1000万 * 768 * 4字节 ≈ 30GB。再加上原始索引、keyword字段、倒排索引一台机器很容易吃紧。缓解策略降低向量维度768降到384内存直接少一半只对必要的文档做向量化比如只embedding标题不embedding全文加大分片数让向量索引均匀分布到更多节点极端情况可以把向量字段的index设为false退化为纯存储模式只用来返回结果而不参与检索但这就失去了向量搜索的意义一般不建议6.4 精确度和召回率之间的权衡HNSW的召回率不是100%这在前面已经提到过。如果业务方对召回质量要求严格需要量化验证。我当时的做法是拿出一批人工标注的相似对来测试分别用kNN和暴力计算script_score跑一遍对比top10的命中率。如果kNN的命中率和暴力计算的差距超过5%就调大m、ef_construction、num_candidates这些参数。一个经验值参考m16、ef_construction100、num_candidates100时在100万级数据上是能跑到95%以上召回率的。再加到m32、ef_construction200召回率能到98%但内存会上升不少。到底怎么权衡取决于业务容忍度。6.5 线上索引数据一致性维护ES里的索引数据与业务库存在同步延迟或者中途崩溃导致部分数据没写进去。建议做法给每条doc写入一个timestamp字段定期做对账任务扫描业务库里最近N分钟更新的数据重新计算向量并upsert到ES对账频率不用太高增量数据量很小的话每分钟跑一次没压力7. 我自己沉淀下来的几条实操经验7.1 先小规模验证再大规模铺开第一版不要急着把几百万数据全量灌进去。抽一万条有代表性的数据建一个小索引把检索路径整个走通包括embedding、索引、kNN查询、过滤条件、结果返回。这个环节能发现很多问题——维度不一致、模型效果差、字段类型配错、查询语法写错——而且改了也不痛。等到小规模验证的检索效果让业务方满意了再上全量心里才有底。7.2 加一个“可视化的调试工具”非常有必要命令行和curl只能告诉你返回了什么分数但你不知道这个分数意味着什么。我在项目里写了一个极简的调试页面输入query文本后台调用embedding模型生成向量然后去ES里走kNN返回top20结果把文本、分数、标签都展示出来。手动标注几十条典型query就能感觉出检索效果行不行。这个工具花不了多少时间但绝对值得。7.3 关注向量字段的“不可解释性”做技术选型时要清楚地知道向量搜索的结果不能直接解释。用户问“为什么会返回这条结果”你只能说“语义相似度最高”。这和关键词搜索完全不一样关键词可以定位到命中的词向量不行。提前跟业务方打好预防针否则将来扯皮会有很多。7.4 混合检索的融合权重需要调参向量和BM25的融合不是简单的五五开。如果业务数据里专有名词很多比如产品型号、人名那BM25的权重应该大些如果内容偏泛语义比如知识问答、文章推荐向量权重应该大些。建议用离线评测集做参数搜索尝试不同的RRF权重或加权求和系数选效果最好的上线。8. 后续可以往哪些方向扩展如果你已经把基础的向量搜索跑通了接下来有几个自然的演进方向图片和文本的跨模态检索标题和图片通过多模态模型映射到同一向量空间用户输入文字就能搜图片基于向量聚类做内容去重文本向量聚类后同一簇内的高相似文档可以识别为近似重复内容做推荐场景的内容清洗流式更新和大模型结合把ES作为长期语义记忆与大模型应用结合做带历史上下文的生成式搜索ES的向量能力还在持续迭代比如近似kNN的更多算法实现、更细粒度的索引参数控制、与生成式AI的融合。如果你现在还在纠结要不要上向量搜索只要业务里有“语义匹配”的需求就值得动手试。先从一个小场景切入把链路打通再逐步扩展这条路我走下来感觉是顺畅的。
