向量数据库 + 大数据平台：别再各玩各的了，这才是相似性搜索的“王炸组合”
向量数据库 大数据平台别再各玩各的了这才是相似性搜索的“王炸组合”作者Echo_Wish这两年向量数据库火得一塌糊涂。什么“语义检索”“相似度召回”“多模态搜索”——听着都高级。但我发现一个很有意思的现象很多团队在做向量搜索时是“孤岛式”的。离线在大数据平台上算 embedding在线在向量数据库里做相似性搜索两边之间几乎没有数据治理、指标联动、特征统一结果是什么 离线一套逻辑线上一套逻辑 大数据平台负责“算”向量库负责“查”但彼此不知道对方在干啥 召回效果不稳定数据更新延迟成本还居高不下今天我就跟大家聊聊一个更实战的方向如何把向量数据库和大数据平台真正融合起来做一套可扩展、可治理、可进化的相似性搜索与召回系统这篇文章不空谈我们直接聊架构、代码、工程问题。一、问题本质相似性搜索不是一个“数据库问题”很多人以为“我选个好用的向量数据库不就行了”比如MilvusWeaviatePineconeFaiss但我想说一句扎心的话相似性搜索从来不是数据库问题而是“数据工程问题”。因为一个完整的相似性召回系统至少包括原始数据采集清洗与特征工程Embedding 生成向量索引构建在线搜索与召回排序与重排监控与效果评估这7个环节向量数据库只负责第4和第5。剩下的全是大数据平台的事。二、正确姿势向量数据库嵌入大数据体系我自己更推崇一种架构ODS → Spark/Flink → 特征处理 → Embedding生成 ↓ 向量索引构建任务 ↓ 向量数据库在线 ↓ API召回服务也就是说大数据平台负责 embedding 生命周期管理向量数据库负责高性能 ANN 检索两者通过流式或批式任务打通三、一个真实工程示例我们假设场景做一个商品语义搜索系统。1️⃣ 离线计算 embeddingSparkfrompyspark.sqlimportSparkSessionfromsentence_transformersimportSentenceTransformer sparkSparkSession.builder.appName(embedding-job).getOrCreate()modelSentenceTransformer(all-MiniLM-L6-v2)dfspark.read.parquet(hdfs://product_data)defencode(text):returnmodel.encode(text).tolist()frompyspark.sql.functionsimportudffrompyspark.sql.typesimportArrayType,FloatType encode_udfudf(encode,ArrayType(FloatType()))dfdf.withColumn(embedding,encode_udf(df[description]))df.write.mode(overwrite).parquet(hdfs://product_embedding)这里大数据平台负责分布式并行算 embedding存储历史版本可回溯这一步非常关键。2️⃣ 构建向量索引Milvus示例frompymilvusimportconnections,Collection connections.connect(default,hostlocalhost,port19530)collectionCollection(product_embedding)# 插入数据collection.insert([ids_list,embedding_list])# 构建索引index_params{metric_type:L2,index_type:IVF_FLAT,params:{nlist:128}}collection.create_index(embedding,index_params)注意向量库不是主数据源它只是 serving 层数据权威在大数据平台这一点很多团队没搞清楚。四、进阶流式更新怎么搞如果你只做离线批量更新那系统很快就过时。这时候用 Flink 消费消息队列实时生成 embedding实时写入向量库示例伪代码defprocess_stream(event):embeddingmodel.encode(event[text])milvus.insert([event[id],embedding])这样大数据平台负责流处理向量数据库负责近实时更新两者结合召回效果才有生命力。五、很多人忽略的三个坑坑1Embedding版本不统一模型升级了怎么办如果你没做版本控制老向量 新向量混在一起相似度空间彻底乱掉正确做法每个 embedding 带 version 字段不同版本分开索引灰度切换坑2只做向量召回不做特征过滤实际业务中必须类别过滤时间过滤权重控制向量数据库支持 hybrid search但复杂过滤逻辑仍然建议在大数据层预处理。坑3效果评估缺失很多团队上线向量搜索后不监控召回率不做 A/B不对 embedding 质量做分析结果就是以为很高级其实效果一般。大数据平台的优势就在于可以做离线评估可以做样本回放可以跑全量统计六、我的观点向量数据库不是终点而是加速器我越来越觉得向量数据库只是“加速器”不是“大脑”。真正的大脑在于数据治理能力特征工程能力模型迭代能力大规模分布式计算能力这也是为什么做推荐、搜索、RAG系统的团队最后都会回到大数据平台做基础建设。七、一个更高级的玩法向量 特征融合召回很多人做的是向量召回 → 直接排序但更高级的是向量召回 规则召回 统计特征召回 → 合并 → 排序模型而这些融合逻辑用 Spark 训练用大数据平台计算特征用在线服务做融合向量数据库只负责“快速找候选”。八、最后一点感受这几年我接触过很多做向量搜索的团队。真正做得好的团队有一个共同点他们从来没有把向量数据库当成救世主。而是把它嵌入到大数据体系里。说句实在话如果你没有数据治理能力光买个向量数据库是救不了召回效果的。真正的壁垒在数据规模数据质量特征工程深度计算架构设计向量数据库只是让这一切跑得更快。如果你正在做RAG系统语义搜索推荐召回多模态检索建议你回头看看自己的大数据体系 embedding 生命周期是否可控 模型版本是否可回溯 在线与离线是否一致
