过去两年,向量数据库几乎是大模型落地最受关注的底层组件。企业做检索增强生成(RAG)时,第一反应往往是把文档切片、调用嵌入模型、写入向量库。但当应用从演示走向生产,仅靠余弦相似度排序开始暴露短板:专有名词、型号、订单号等关键词常被"淹没"在语义近邻中,命中率不稳定;为了提升召回盲目扩大 top-k,又会让上下文变长、推理成本攀升。
混合检索成为默认选项
行业正在形成共识:纯向量检索不是终点,混合检索才是。所谓混合,通常是三件事的组合——稠密向量负责语义泛化,稀疏向量(如 BM25、SPLADE 等学习式稀疏表示)负责关键词精确匹配,两路结果再经倒数排序融合(RRF)或交叉编码器重排,得到最终候选集。
- 召回端:稠密与稀疏双路并行,兼顾语义与字面匹配;
- 排序端:轻量重排模型做精排,把真正相关的片段顶上来;
- 评估端:用固定评测集衡量召回率与端到端准确率,而非只看延迟。
一个值得注意的变化是,关键词检索并未被淘汰,反而在工具调用、代码检索、法律与医疗等专业场景中重新被重视。不少团队发现,先用关键词收窄候选范围,再用向量做语义精排,综合效果优于任何单一方案。
内核之争:内存、磁盘与 GPU
混合检索对内核提出新要求。传统向量索引(HNSW、IVF 等)主要面向内存设计,当数据规模从百万级涨到十亿级,内存成本变得难以承受,磁盘索引方案因此获得更多关注,借助图结构与 SSD 的配合,在可接受延迟下承载更大规模数据。
候选集扩大也推高了计算压力,量化压缩与 GPU 加速逐渐成为标配:前者把向量从浮点压缩为更小的表示,降低内存与带宽占用;后者用于批量重排与批量嵌入,缩短端到端响应。多租户隔离、冷热分层、增量更新这些数据库基本功也被重新审视——企业不希望为向量检索再搭一套缺乏事务与权限的孤岛系统。
检索与存储正在合流
更值得关注的是形态变化。一方面,向量能力正被塞进通用数据库:PostgreSQL 的 pgvector 扩展、搜索引擎内置的向量字段,让许多团队不必引入新的独立组件。另一方面,面向 AI 的数据湖格式开始在湖仓中直接承载向量与多模态数据,配合对象存储降低成本,让"数据在哪、检索就在哪"成为可能。
这种合流意味着,向量检索不再是孤立赛道,而是数据库与数据平台能力的一部分。企业选型的关注点随之转移:不再只看每秒查询数这类单点指标,而是看能否与既有元数据、权限、血缘和可观测体系对齐。
落地的三点建议
- 先定评测基线:用真实业务问题集代替通用榜单,明确召回率、端到端准确率与成本三条线;
- 混合优先、增量演进:从关键词加向量的双路召回起步,再逐步引入重排与微调;
- 把治理纳入设计:向量与原始数据同样需要权限、版本、血缘与删除机制。
总的来看,向量数据库正从"专用黑盒"走向"混合检索加平台能力"的组合,竞争焦点已从能不能存向量,转向能否在成本、准确率与治理之间取得平衡。对大模型应用而言,这或许是比模型参数更影响体验的一环。