向量数据库和普通数据库的区别

你手上有一堆文本、图片或日志，团队有人说塞进关系库加个字段就行，有人说必须上向量库，两边都说得有理。这篇不站队，只把两类库在存储结构、检索方式和运维代价上的差异拆开讲，再给一份选型排查顺序，帮你在评审会上把「为什么选它」说清楚。

你手上有一堆文本、图片或者日志，团队里有人说塞进关系库加个字段就行，有人说必须上向量库，两边听起来都挺有理。这篇不站队，只把两类库在「存什么」「怎么查」「出错代价」这三件事上的差异拆开讲，最后给一份可以直接照着问的选型排查顺序。

先说结论方向：它们不是一代替换一代的关系，更像是两种不同工种。关系库擅长把事实摆得整整齐齐、算得明明白白；向量库擅长从一堆说不清语义的东西里，找出「感觉最像」的那几条。选型工程师真正要回答的问题，不是哪个更先进，而是你的这次检索到底要的是「对」还是「像」。

先看存进去的东西长得一样不一样

关系库存的是结构化字段，一行一条记录，字段类型在建模阶段就定死了，整数就是整数，字符串长度超了直接报错。向量库存的核心是一串高维浮点数组，这串数字本身没有任何可读语义，你看一眼不知道它代表什么，只能靠距离计算去和别的数组比。旁边通常还会挂一份原始载荷，比如主键、来源、时间戳这类元数据。

那串数字是怎么来的？文本或图片先过一遍嵌入模型，模型输出一串定长的浮点值，这串值就是检索时唯一拿来比对的依据。所以「同一个词换一种说法，向量可能很接近」是它的优势，但「向量接近不等于业务含义相同」也是它天生的坑。

结构化字段

类型、长度、取值范围在写入前就确定，越界会直接拒绝，好处是后续计算和统计都很确定。

嵌入向量

由模型把原始内容转成的一串浮点数字，本身不可读，只在和其他向量比距离时才有意义。

原始载荷

挂在向量旁边的附加信息，一般放主键、来源、标签、权限标识，方便检索完再回源取完整内容。

两者最常见的分工是：向量库只存向量和主键，真正的内容正文、权限字段、业务状态还留在原来的关系库里。这样换嵌入模型时，受影响的范围清楚可控，不会把业务数据也一起搅进去。

查的方式：精确匹配和近似最近邻是两种活

关系库靠条件筛选、多表关联和索引做精确匹配，答案要么命中要么不命中，同一份数据、同一条语句，今天跑和明天跑结果一致。向量库靠距离度量找「最接近的若干条」，本质是近似检索，哪怕数据和查询都没变，调整召回数量或者距离阈值，出来的结果就可能不一样。

正因为没有「唯一正确答案」这一说，向量检索必须配一套评测。做法很简单：先把真实业务里的一批问题整理成小测试集，标好每条期望命中的内容，然后每次调整参数或换模型都跑一遍，看命中情况有没有退化。没有这套东西，你根本判断不了这次改动是变好了还是碰巧。

具体某个向量库支持哪些距离度量、哪些参数可调，不同产品差别不小，这个别凭印象记，去站内的向量库资料目录按当时的版本说明核对一遍更可靠。

事务、约束、一致性这三件事的落差

关系库有事务、外键、唯一约束，能保证一批写入要么全成要么全败，也能挡住明显不合规的数据。多数向量库在这块能力偏弱，通常要靠应用层自己补偿：先写事实库，成功了再往向量库推，失败了记一条待重试任务。

更值得注意的是写入可见性。向量库的索引往往在后台构建，刚写进去的数据不一定立刻能被检索到，这个延迟窗口在不同实现里长短不一。如果你的产品逻辑是「提交完立刻能搜到」，那就要先确认这个窗口是否满足要求，别等上线后才发现。

• 需要扣减库存、扣减余额这类原子操作：放关系库，并把向量检索放在之后的展示环节。
• 需要唯一性约束（比如同一用户不能重复提交）：关系库的唯一索引更简单可靠。
• 需要跨表统计和对账：留在关系库，向量库不擅长做聚合。
• 需要软删除和权限过滤：优先在应用层或关系库做，别全指望向量库的元数据过滤。

什么情况下不该上向量库

第一种：数据量不大、关键词能直接命中、结果还要求完全可复现的检索。这种情况用普通库的模糊匹配或全文索引就够了，多引入一个向量库只是多一个运维面、多一份索引重建的活。

第二种：字段过滤条件特别复杂、需要多表关联做统计分析。向量库的强项是相似度，不是关系代数，硬做会非常别扭。第三种最容易被忽略：团队没有人力维护索引重建、模型换版本后的全量重嵌入。一旦没人管，向量库很快会变成谁都不敢动的黑盒，检索质量慢慢烂掉还没人发现。

还有一个判断标准是容错成本。如果检索结果错了只是体验差一点，向量库完全可以上；如果错一条就会影响结算、合规或者对外承诺，那向量方案必须加人工确认或二次校验环节，不能直接拿近似结果当最终答案。

更常见的答案：两个一起用

实际项目里最稳的分工是：向量库当检索层，负责快速缩小范围；关系库当事实层，负责给出完整、准确、可对账的内容。检索拿到主键之后，回关系库取正文和权限字段，这样业务数据的准确性不受向量质量波动影响。

另一个被反复验证有效的做法是混合召回：关键词召回一批，向量召回一批，两批合并后再排序。关键词能兜住那些「字面必须匹配」的查询，向量能兜住「换个说法也得搜到」的查询，两边互补。具体有哪些向量库、各自定位怎么分，去站内 /stacks/vector-dbs 的目录看当时的清单，再按自己的场景筛。

权限过滤、软删除、审计这类业务规则尽量前置：要么在应用层拼好过滤条件再发起检索，要么由关系库先算出一批允许访问的主键，再把主键作为过滤条件传给向量库。指望向量库的元数据过滤兜住所有权限逻辑，通常会在数据量涨上来之后出问题。

选型清单：把问题问成可比较的项

选型讨论最容易变成观点对轰，解决办法是把问题改写成可比较的项。先定四个业务参数，再对齐运维能力，最后做一次小规模对照实验，三步走完基本就能形成结论。

1. 第一步：定数据规模量级和写入频率先估算总量是几千条、几万条还是更多，以及每天新增多少、是否需要实时写入。量级决定你有没有必要上专门的向量库，写入频率决定索引重建窗口能不能排进日常。
2. 第二步：明确能不能接受近似结果和产品、业务方确认：漏掉一条或者排错一条，后果是什么。能接受就在向量路线上继续，不能接受就要设计二次校验或者干脆退回精确匹配。
3. 第三步：确认要不要强一致把流程里涉及扣减、状态流转的动作单独拎出来，这部分明确交给关系库。剩下的检索和展示环节，才交给向量方案。
4. 第四步：对齐运维项逐项确认：能不能本地部署、有没有备份恢复手段、索引重建要多久、换嵌入模型后历史数据怎么全量重跑。这些问题的答案直接决定长期成本。
5. 第五步：做小规模对照实验同一批真实问题，分别在两种方案下跑，记录召回质量和响应延迟。测试前先用站内 /tools/speed-test 把网络和延迟基线量出来，否则你分不清慢在库还是慢在链路。

做完这五步，你在评审会上就不需要说「我觉得向量库更先进」，而是可以说「我们这批数据是什么量级、能接受近似、强一致部分单独放关系库、重建窗口是多久，所以选它」。这才是选型工程师该有的表达方式。

接入阶段最容易踩的几个坑

第一个坑是嵌入模型换了但没重嵌入历史数据。新旧两批向量混在同一个集合里，距离尺度不一致，检索结果会明显发飘，而且很难一眼看出原因。换模型必须伴随一次全量重跑，这件事要在计划里就留出时间。

• 模型换版本后只对新数据生效，历史向量没重跑：结果是新旧混杂，检索质量断崖式下降。
• 把大批量写入放在请求链路上同步做：接口超时和写入堆积会同时出现，应该走离线任务或队列。
• 过滤条件写在检索之后而不是之前：先召回一大堆再筛，性能和最终准确率都会受影响。
• 没有评测集就开始调参：改完不知道变好还是变坏，调参变成碰运气。
• 权限校验只做在展示层：检索阶段已经把不该看的内容召回了，存在信息泄露风险。

排查顺序建议按这个来：先看写入是否完整、有没有堆积；再看检索参数有没有被人改过；然后确认嵌入模型版本是否一致；最后才怀疑数据本身。多数「搜不准」的问题，根子在前三步而不是向量库本身不行。