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

大模型的应用场景越来越具体，问题也越来越一致：模型本身很强，但它不知道你的业务数据。于是很多团队开始往提示词里塞背景资料，塞到最后提示词超长，或者干脆尝试微调。两种做法都有用，但都不是数据接入的最佳方式。真正让大模型与业务数据形成稳定连接的关键组件，是向量数据库。

“向量数据库”这个名字听起来像是一个新的技术品类，但它的本质并不难理解。大模型在计算语义时，会把文本转换成一个固定维度的向量，语义相近的内容在向量空间里的距离也更近。用户问“我要退货”，知识库里写着“退换货流程”，在字面上并不完全匹配，但在向量空间中可以很近。向量数据库要做的事情，就是高效地保存这些向量，并且在收到一个新向量时快速找到最接近的那一批。

这个需求之所以在近两年被放大，是因为大模型应用普遍采用检索增强生成（RAG）的模式。模型的上下文窗口再大，也不可能容纳整个企业知识库。与其把所有内容交给模型，不如先通过检索把候选范围缩小到几十条，再把这几条作为参考上下文送入模型。于是，检索这个环节的质量，就成了大模型回答质量的重要前置条件。

为什么传统数据库做不了这件事

传统关系型数据库擅长的是精确匹配和范围查询，比如“查订单号为1001的记录”或者“筛选出价格区间在100到200的商品”。这些查询建立在字段之间的确定性关系上，可以依靠B+树索引快速定位。但“语义相似”是一个高维空间里的距离概念，没有办法预先定义一个确定性排序。

用SQL的LIKE做模糊匹配，只能处理字面重叠；用全文检索，可以匹配同根词和分词，但依然停留在关键词层面。当用户换成“这个东西坏了想退”，知识库里写的是“支持7天无理由退换货”，全文检索很难把它们关联起来。向量表示的优点正在于此：不需要字面一致，只要语义相近。

真正的问题是，向量检索的执行计划与关系型索引完全不同。传统数据库如果只增加一个向量类型和一个距离运算符，却不在存储层和查询层做专门优化，查询时很容易退化成线性扫描。pgvector这类的扩展已经试图通过近似索引解决这个问题，但它在接近千万级向量、高并发查询的压力下，仍然可能遇到CPU和内存瓶颈。这也是专用向量数据库存在的理由：从数据分布、索引构建到查询调度，它都为“高维向量快查找”做了更纯粹的设计。

向量数据库的搜索逻辑：从向量到索引

一个最小可用的向量检索流程分三步。第一步，用嵌入模型把非结构化数据转成向量；第二步，用索引结构组织好这些向量；第三步，把查询文本也转成向量，通过近邻搜索返回结果。

嵌入模型的选择直接影响召回效果。通用模型对日常语言表现良好，但如果是医疗、法律、代码这些垂直领域，直接用通用向量可能会把很多专业术语混在一起。比较好的做法是构造一批领域内的相似样本，对比几个候选Embedding模型的效果，而不只是看模型榜单上的分数。

索引部分决定的是查询速度和召回率之间的平衡。目前使用最广泛的算法有两类：一类是基于图的HNSW，一类是基于倒排的IVF。HNSW把向量组织成多层图，搜索时在高层粗跳，在底层细找；IVF则先把向量聚类，再只在最相关的几个簇内搜索。两者都牺牲一定的精确性来换取时间，所以它们也被称为近似最近邻（ANN）索引。

以HNSW为例，在pgvector中创建索引和使用索引查询的SQL如下：

CREATE TABLE docs (
    id BIGSERIAL PRIMARY KEY,
    content TEXT NOT NULL,
    embedding vector(768)
);

CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);

SELECT id, content, 1 - (embedding <=> query_embedding) AS similarity
FROM docs
ORDER BY embedding <=> query_embedding
LIMIT 5;

vector_cosine_ops表示按余弦相似度建索引。这里使用的距离运算符是<=>，它返回余弦距离，数值越小越相似。实际业务中，还可以根据场景选择内积（<#>）或欧氏距离（<->）。内积适合商品推荐这类带有模长信息的场景，余弦更适合文本相似度，欧氏距离有时用于图片等密集向量。选择不当，可能导致排序结果和业务期望不一致。

这里有一个容易被忽略的细节：HNSW索引的质量高度依赖参数。m值控制每个节点的连接数，ef_construction控制构建时搜索范围，ef_search控制查询时搜索范围。调大这些参数能提升准确率，但内存占用和延迟也会相应上升。很多团队在生产环境遇到慢查询，最后发现不是数据库性能问题，而是索引没有命中，或者查询时用了普通遍历。

不同方案之间的取舍

那么，是不是所有场景都必须上专用的向量数据库？答案取决于你的数据量、并发、一致性要求，以及团队能承担的运维复杂度。下面这张表是常见选型路径的对比。

实际上，很多系统最终会采用混合结构。交易类数据继续放在关系型数据库，向量数据单独存入专用数据库，通过CDC或者其他同步机制把需要检索的文本片段推送过去。这个数据管道本身也需要监控和重放机制，如果断流，用户很快会发现找不到新增内容。

从工程角度看，一个比较合理的升级路径是这样：先用pgvector或者单机Milvus跑通第一版，把注意力放在嵌入模型和检索质量上；当向量规模增长到单机内存吃紧，或者在线检索并发明显上升，再考虑迁移到分布式专用数据库。提前设计好索引和事务边界，迁移成本并不会特别高。

工程落地中的三个误区

第一个常见误区，是把向量数据库当作“语义搜索引擎”。向量数据库只负责根据距离找邻居，并不理解语义。真正决定检索结果相关度的，是嵌入模型本身，以及数据切分的方式。切分太短，每段信息不完整；切分太长，一段里混杂多个主题，向量被平均后失去辨识度。这些都需要针对数据具体调优，而不是换了数据库就能解决。

第二个误区，是认为做了向量检索就能彻底解决大模型幻觉。检索增强的可靠性依赖两个前提：一是检索结果确实包含答案，二是大模型能严格根据给定上下文回答。如果top3结果里只有一条相关，模型依然可能被无关信息带偏。因此，检索质量评测不能只看“检索命中率”，还要看“下游答案是否可信”。

第三个误区，是忽略元数据过滤与向量检索的结合方式。生产环境里很少只是“凭一句话检索全库”，往往还要求限制来源、时间、权限等条件。不同数据库对过滤下推的支持差异很大，有的先向量扫描再过滤，有的先过滤再扫描，有的支持倒排索引后做融合排序。如果业务对过滤严格，选型时就要专门测这类场景，否则上线后会发现权限控制或准确率成了瓶颈。

从原型到生产：可以这样逐渐演进

如果你所在的团队正打算引入向量数据库，我建议从一个足够简单的闭环开始。比如选择客服问答或文档检索这类目标单一的场景，收集几百条真实文本，切分后用一款Embedding模型生成向量，再用pgvector或轻量级向量库做检索，最后人工评判top5结果是否合理。这个阶段不需要关注性能，只验证“语义检索是否真的比关键词更好”。

验证有效后，再逐步补充下面几项工程能力：

• 建立评测集：准备一批有标准答案的查询和对应文档，用于对比不同模型和索引参数的召回效果。
• 设计数据同步链路：明确新文档从写入存储到向量化、再到索引生效的延迟要求。
• 做好监控：除了延迟和吞吐，还要记录检索结果的分布，比如长时间没有返回结果、只有单一来源命中等等。
• 规划备份与恢复：向量索引重建代价高，必须有一套可执行的备份策略。

这里要特别提醒一下，数据更新频繁的场景比只读检索要复杂得多。对HNSW索引来说，频繁插入和删除会导致图结构退化，需要定期重建。关系型数据库用事务可以保证强一致，但分布式向量数据库的一致性和隔离级别往往做不到那么严格。对一致性要求很高的业务，需要在上游先做数据版本管理。

一个典型的成长场景是内部知识库系统。第一版数据量只有几万段，用一台PostgreSQL实例加pgvector就足够。随着团队把更多项目文档接入，段落数增长到几百万，查询量和并发也上升，DBA开始发现备份和索引维护时间越来越长。这时再评估引入Milvus或Qdrant这类专用服务，并且逐步把知识库的检索流量切过去，原有SQL部分仍然保留。这样的演进方式比一开始就追求“大而全”要平滑得多。

总结与判断

向量数据库能成为大模型时代数据基础设施的新成员，核心原因是它把“按语义查内容”这个以前很难工程化的需求，变成了可以被索引、分片、监控的标准数据服务。它并不替代关系型数据库，也不是对大模型能力的重复实现，而是在两者之间补上了检索这一块拼图。

选型时应该回到业务约束：数据规模多大、并发多高、更新多频繁、团队有多少运维余力。先验证检索质量，再设计索引和同步链路，最后考虑分布式扩展。理解边界，比盲目跟风更重要。