向量数据库为什么成为大模型时代数据基础设施的新成员

大模型应用需要什么样的数据访问

如果你最近搭过大模型相关应用，大概会注意到一个现象：无论做知识库问答、语义搜索，还是给 Agent 加长期记忆，最后都会出现一个叫向量数据库的组件。它从过去的”选装件”逐渐变成了不少系统架构中的常驻模块。

但”常驻”不意味着它是万能的。向量数据库之所以被重视，是因为大模型时代的数据访问方式发生了一个根本变化：应用不再只依赖精确匹配，而需要处理大量”语义层面的相似性”。

从精确匹配到语义匹配

传统应用中，用户要查订单，输入订单号，数据库执行一条 where id = 123 就结束了。搜索场景也类似，倒排索引拆词、去停用词、算 BM25 分数，本质上还是词法匹配。这套模式很成熟，但它的隐含假设是用户能明确说出要搜的东西。

大模型应用打破了这个假设。用户会直接问”发票报销流程是怎么样的”，而知识库里对应的文档标题可能是”报销发票如何走审批”。关键词没有重合，语义却接近。靠老办法需要维护同义词表、做文本相似度计算，成本高且效果不稳定。

embedding 模型的出现改变了这件事。文本会被映射成一个固定维度的向量，模型训练目标就是让语义相近的文本在向量空间中距离更近。于是检索问题被转化为向量相似性搜索，这也成了大模型应用最关注的基础能力之一。

为什么是数据库，而不是一个索引库

很多团队会问：向量相似性搜索用 FAISS 这样的库就能做，为什么非要引入一个”向量数据库”？

单纯从算法角度看，FAISS 完全可以完成近似最近邻检索。但一个完整的数据组件还要解决持久化、并发读写、元数据过滤、权限控制、故障恢复和水平扩展，这些不是算法库的职责。早期不少团队用 FAISS 加自研存储层拼装检索系统，初期勉强能用，数据量一上来，索引重建、节点扩容、数据一致性每一项都会变成技术债。

真实的业务检索也很少是纯粹的按向量距离排序。你通常需要过滤掉没有权限的文档，只在某个时间范围内检索，或者组合多种业务条件。如果只用 FAISS，向量数据和标量元数据往往分落在两套系统，要保持一致成本很高。向量数据库做的事情，是把高维索引、标量过滤和数据管理放在一起重新设计，而不是简单地在传统数据库上追加一个插件。

这里也值得了解一下常见的索引机制。HNSW 把向量组织成多层图，检索时从顶层快速下探，速度和精度通常不错，但内存占用更高。IVF 则先对向量做聚类，把数据分成多个桶，查询时只检查最近的几个桶，构建成本更低，但召回率可能略受损失。选择哪种往往取决于你的内存预算和查询延迟要求。

大模型时代为什么特别需要它

如果只说向量检索，推荐系统里做相似物品召回已经用了很多年，不算新鲜。但大模型让这个需求变得异常普遍，核心推动力是 RAG（检索增强生成）。

大模型本身没有增量记忆，训练数据里的知识和私有业务知识之间存在一道鸿沟。RAG 的思路是：在模型回答之前，先从外部知识库中检索相关资料，再作为上下文塞给模型。一个最常见的流程是：用户问题先被 embedding 模型转成向量，在向量数据库中召回 top5 相关文档，然后拼成一个包含指令、上下文和问题的 prompt，最后调用大模型生成回答。在这个流程里，向量数据库的召回质量决定了 prompt 里有没有正确答案。

于是，向量检索从”偶尔用一用”变成了大模型应用的主链路组件。很多团队搭建知识库问答时，第一个实践就是嵌入一个向量数据库，把文档切片后写入索引，再让问题发起语义搜索。这个路径能跑通，关键就在于向量数据库让语义检索变得像传统数据库一样有索引、有查询接口、有过滤条件，而不是自己从头搭一套需要持续维护的系统。

常见误区：向量数据库不是用来替代一切的

看到这里，你可能会觉得向量数据库是更高级的搜索方案，应该全面替代现有存储。这其实是个很大的坑。

第一个误区是”向量检索能替代全文搜索”。实际场景里，商品编号、身份证号、错误码这类精确值，全文搜索的命中效果比向量检索更稳。实践中更合理的做法是混合检索：先用关键词或全文引擎锁死精确条件，再用向量召回语义相近的候选，最后做融合排序。纯粹依赖任何一种都容易出问题。

第二个误区是”语义相似度等于业务相关性”。向量空间中的相近只说明文本表达方式接近，不代表逻辑上就适用于当前问题。比如”订单被取消”和”取消订单”语义很接近，但用户需要了解的可能是取消后的退款路径，不是取消操作本身。如果只按相似度截断返回，不做下游业务校验，会出现看似合理、实则无用的答案。

还有一个容易忽略的问题：把业务数据全量同步进向量库，会导致一致性成本激增。向量库通常不是事务系统的替代品，它更适合作为检索层与现有业务系统并行存在。你需要设计同步链路，容忍部分延迟，而不是让向量库承担所有读写。

最危险的不是选错向量数据库，而是把向量检索当成唯一答案，忽略业务上下文。检索质量是系统工程，数据库只负责其中一环。

选型对比：独立向量数据库、pgvector、还是 ANN 库

“向量数据库”这个词下其实有多种实现路径。目前代表性的选择大致有三类：独立向量数据库（如 Milvus、Qdrant、Weaviate）、传统数据库的向量扩展（如 pgvector）、以及面向算法的 ANN 索引库（如 FAISS）。它们之间的工程边界差异很大。

方案	语义检索	扩展性	运维成本	适合场景
关系库全文检索	弱	中等	无额外组件	简单关键词搜索
PostgreSQL + pgvector	较好	中等	较低	已有 Postgres，数据量千万以下
独立向量数据库	强	高	需要独立运维	亿级向量、高并发、复杂过滤
ANN 索引库（FAISS）	强	依赖自研	高	研究原型、完全可控

以 pgvector 为例，接入向量检索比想象中简单。先建一张文档表，加一个向量列，再创建一个用于近似检索的索引：

CREATE TABLE documents (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(768)
);

CREATE INDEX ON documents
  USING ivfflat (embedding vector_cosine_ops);

-- 查询：按语义相似度返回 top5
SELECT content FROM documents
ORDER BY embedding <=> $1
LIMIT 5;

这里的 ivfflat 是 pgvector 提供的近似索引，也可以换成 HNSW。核心变化是：查询不再是精确匹配某个词，而是把输入问题转换成向量后寻找最相近的文档。这个能力放在 SQL 里非常自然，业务代码不需要维护一个新的存储系统。

需要注意的是，向量检索的召回率和延迟之间存在直接权衡。HNSW 的 ef_search、IVF 的 nprobe，调大通常能提高召回率，但也会增加响应时间。线上系统需要压测找到平衡点，而不是直接使用默认配置。