1. 从一次检索需求说起为什么普通数据库突然不够用了前阵子帮一个做知识管理工具的朋友看架构问题。他们的产品早期用传统关系型数据库存文档元数据搜索靠LIKE %关键词%硬扫数据量小的时候一切正常。等到文档量爬到几十万条、用户开始用自然语言提问帮我找去年关于预算调整的会议记录时整个检索链路直接崩了——响应时间从几百毫秒飙到十几秒而且搜出来的东西驴唇不对马嘴。这个场景其实特别典型。向量数据库和普通数据库的选型问题本质上不是哪个更好的问题而是你的检索需求到底属于哪一类的问题。普通数据库擅长的是精确匹配和结构化条件过滤比如找出所有状态为已发布、创建时间在某个区间、作者是某人的记录这类查询它闭着眼睛都能跑得飞快。但一旦你的需求变成找出语义上和这句话最接近的十条内容普通数据库就彻底抓瞎了。我写这篇东西是想把这两类数据库的边界、各自的底层逻辑、以及实际选型时那些文档里不会写的坑一次性讲清楚。不管你是刚接触向量检索的新手还是已经在做架构决策的工程师应该都能从中找到能直接用的判断依据。核心关键词就三个向量数据库、普通数据库、选型全文围绕它们展开。先说结论性的判断框架后面再逐层拆解如果你的查询条件是精确的、可枚举的、结构化的普通数据库是更优解如果你的查询条件是模糊的、语义的、相似度排序的向量数据库才是对的工具。而现实中大量场景其实是两者混合这时候怎么组合才是真正考验功力的地方。2. 两类数据库的底层逻辑差异一个存值一个存方向2.1 普通数据库的索引本质把值排好序快速定位普通数据库这里主要指关系型和文档型的核心能力是精确检索。它之所以快是因为建立了 B 树、哈希索引、倒排索引这类结构把数据按照某种确定的顺序组织起来。你查id 12345它通过 B 树几层就能定位到你查name LIKE 张%它能利用索引的前缀特性快速缩小范围。关键在于这类索引的前提是值本身可以被比较和排序。数字能比大小字符串能按字典序排时间能按先后排。所以普通数据库处理的是这个值等于/大于/小于/包含某个确定值这类问题。但语义相似度这个东西它没法排序。你没法说苹果和水果哪个更大也没法说预算调整和财务规划哪个排在前面。语义关系是一个高维空间里的距离问题普通数据库的索引结构根本表达不了。2.2 向量数据库的核心把语义变成高维空间里的坐标向量数据库做的事情是先把文本、图片、音频这类非结构化内容通过嵌入模型转换成一串浮点数也就是向量。比如一段文本可能被转成 768 维或 1536 维的向量。这个向量可以理解为这段内容在语义空间里的坐标。一旦内容变成了坐标语义相似度就变成了向量之间的距离。两个向量夹角越小余弦相似度越高说明它们语义越接近。向量数据库的核心工作就是在这个高维空间里快速找到离查询向量最近的若干个点也就是ANN近似最近邻搜索。这里有个很多人忽略的点向量数据库并不理解语义它只是高效地做高维空间的距离计算。真正赋予它语义能力的是那个嵌入模型。模型选得好不好直接决定了检索质量的上限。数据库本身只负责算得快。2.3 一张表看清两者的能力边界维度普通数据库向量数据库核心索引结构B树、哈希、倒排HNSW、IVF、PQ 等擅长查询精确匹配、范围过滤、聚合相似度检索、Top-K 排序数据类型结构化、半结构化高维浮点向量语义理解无依赖嵌入模型典型延迟毫秒级有索引毫秒到几十毫秒取决于规模事务支持强普遍较弱更新代价低较高索引重建这张表不是让你二选一而是让你明白它们解决的是完全不同的问题。把向量检索硬塞进普通数据库或者指望向量数据库做复杂事务都是在用错误的工具干错误的活。3. 选型的第一道分水岭你的查询到底长什么样3.1 精确条件查询普通数据库的主场别犹豫先看几个典型的查询语句判断它们属于哪一类查询订单号 20240115001 的物流状态统计上个月华东区销售额超过 10 万的客户找出所有标签包含紧急且未处理的工单这些查询的共同点是条件明确、结果确定、可以精确描述。这类需求用普通数据库配合合适的索引性能几乎没有对手。你要是拿向量数据库来做这些不仅没必要还会因为向量检索的近似特性导致结果不精确——ANN 搜索返回的是近似最近邻它可能漏掉真正精确匹配的那一条。我见过有团队为了技术先进把所有查询都往向量数据库上搬结果连按 ID 查用户都要走一遍向量检索延迟反而更高还引入了结果不确定性。这是典型的过度设计。3.2 语义相似查询向量数据库不可替代再看另一类查询帮我找和这段产品描述相似的其他商品根据这段故障描述检索历史上处理过的类似问题用户上传了一张图找出图库里风格相近的图片这类查询的特点是你没法用精确条件描述只能给出一个参照物然后要求找相似的。这正是向量数据库的用武之地。这里要强调一个实操经验相似度阈值的选择比数据库选型更影响体验。余弦相似度 0.8 以上通常算高度相关0.6 到 0.8 是弱相关0.6 以下基本可以认为是噪声。但这个阈值不是固定的它跟你的嵌入模型、数据分布强相关。我一般建议先用一批标注好的查询-结果对跑一遍看看相似度分布再定阈值而不是拍脑袋设个 0.7。3.3 混合查询现实中最常见的形态真实业务里纯语义查询和纯精确查询都少见混合查询才是主流。比如电商搜索找出价格在 100 到 500 元之间、且和轻便透气跑鞋语义相近的商品按相似度排序。这个查询里价格 100 到 500是精确过滤语义相近是向量检索。怎么处理有两种主流方案方案一先过滤后检索。先用普通数据库的条件筛出候选集再对候选集做向量检索。优点是精确条件能大幅缩小检索范围缺点是如果候选集太大向量检索依然慢。方案二向量数据库内置过滤。现在主流向量数据库都支持在检索时附带元数据过滤条件比如price BETWEEN 100 AND 500它在遍历向量索引的同时应用过滤。这种方式实现简单但要注意过滤字段的索引效率否则可能退化成全量扫描。我的经验是过滤后候选集小于总量 10% 时方案一更稳候选集占比高时方案二更合适。这个比例不是绝对的得结合你的数据规模和硬件实测。4. 向量数据库内部也不是铁板一块索引类型决定性能天花板4.1 HNSW召回率高但内存吃得凶HNSW分层可导航小世界图是目前最主流的向量索引。它的思路是构建一个多层图结构上层稀疏用于快速跳转下层密集用于精细搜索。查询时从顶层开始逐层下降像坐电梯一样快速接近目标区域。它的优点是召回率高、查询延迟低在百万级数据上通常能做到毫秒级响应。缺点是内存占用大因为整个图结构要常驻内存。我实测过一个 100 万条 768 维向量的数据集HNSW 索引大概要吃掉 3 到 4 GB 内存。数据量再往上走内存成本会非常可观。调参上M每个节点的连接数和efConstruction构建时的搜索宽度是两个关键参数。M越大召回率越高但内存越大一般设 16 到 64efConstruction越大构建越慢但索引质量越好一般设 100 到 500。查询时的efSearch则直接权衡延迟和召回率。4.2 IVF 系列用聚类换内存适合超大规模IVF倒排文件的思路是先对向量做聚类分成若干个簇查询时只搜索距离查询向量最近的几个簇。这样就不用扫描全部数据大幅降低计算量。它的优点是内存占用比 HNSW 小适合千万级甚至亿级数据。缺点是召回率受聚类质量影响大如果查询向量落在簇的边界上可能漏掉相邻簇里的真正近邻。通常配合 PQ乘积量化进一步压缩向量牺牲一点精度换大幅内存节省。选 IVF 还是 HNSW核心看你的数据规模和内存预算。百万级以内、内存充足HNSW 是首选千万级以上、内存紧张IVFPQ 更现实。4.3 索引不是建完就完事更新与重建的代价这是文档里很少强调、但实际踩坑最多的地方向量索引的更新代价远高于普通数据库索引。普通数据库插入一条记录B 树调整一下就好代价很低。但向量索引尤其是 HNSW插入新向量时需要更新图结构频繁插入会导致索引质量下降。很多向量数据库的做法是批量重建索引这就意味着新数据不能立即被检索到存在延迟。如果你的业务是数据频繁增删改 要求实时可检索这一点必须提前评估。有些场景下用普通数据库存原始数据、定期批量同步到向量索引反而是更稳的架构。我见过有团队没考虑这点上线后才发现新上传的文档要等索引重建才能被搜到用户体验直接崩了。5. 那些选型时最容易踩的坑5.1 坑一以为向量数据库能替代全文检索这是新手最常见的误解。向量检索擅长语义相似但它在精确关键词匹配上反而不如传统全文检索。比如用户搜一个特定的产品型号XYZ-2000向量检索可能返回一堆语义相近但型号不同的产品而全文检索能精确命中。正确做法是混合检索向量检索负责语义召回全文检索负责关键词召回最后用 RRF倒数排名融合之类的算法合并结果。这样既有语义的广度又有关键词的精度。很多成熟的检索系统都是这么做的单靠一路召回很难覆盖所有查询意图。5.2 坑二忽略嵌入模型的成本与一致性向量数据库本身不产生向量向量来自嵌入模型。这里有两个隐藏成本一是调用成本。每次查询都要把查询文本转成向量这需要调用嵌入模型。如果模型是远程 API每次查询都多一次网络往返延迟和费用都要算进去。数据入库时更是要对全量数据做一次嵌入这个批量成本不小。二是模型一致性。入库用的嵌入模型和查询用的嵌入模型必须是同一个否则向量空间对不上检索结果完全错乱。我见过有团队中途换了嵌入模型但没重新嵌入历史数据导致新旧数据检索结果割裂。换模型一定要全量重嵌这是铁律。5.3 坑三把向量数据库当主库用向量数据库的事务能力、数据一致性保障普遍弱于成熟的关系型数据库。把它当唯一数据源风险很高。稳妥的架构是普通数据库做主库存全量原始数据和元数据向量数据库做检索索引存向量和必要的过滤字段。两者通过 ID 关联向量库挂了可以从主库重建。这个架构还有个好处向量库的索引可以随时重建、换模型、调参数不影响主数据。灵活性高很多。5.4 坑四没做召回率评估就上线向量检索是近似的它不保证返回的一定是真正的最近邻。上线前必须做召回率评估拿一批查询用暴力搜索精确计算所有距离得到真实 Top-K再和向量索引返回的结果对比看重合度。如果召回率低于 90%要么调索引参数增大efSearch、M要么换索引类型。这个评估不做你根本不知道系统漏掉了多少本该返回的结果。我一般建议召回率目标定在 95% 以上低于这个数就得优化。6. 一套可落地的选型决策流程6.1 第一步把查询需求分类打标拿一张纸把你系统里所有的查询需求列出来逐条打标是精确条件查询还是语义相似查询还是混合查询。统计各类占比。如果语义类查询占比低于 10%老实说可能暂时不需要向量数据库先用普通数据库扛着等需求明确了再上。如果语义类占比超过 30%向量数据库基本是刚需。6.2 第二步评估数据规模与增长预期数据规模直接决定索引选型和硬件预算。这里给个粗略的参考数据规模推荐方案内存预估768维10 万以内普通数据库 内存暴力检索几百 MB10 万 - 100 万HNSW3 - 8 GB100 万 - 1000 万HNSW 或 IVF8 - 50 GB1000 万以上IVF PQ视压缩率而定注意这个表是单机粗估分布式部署要另算。而且维度越高内存越大1536 维差不多是 768 维的两倍。6.3 第三步确定架构组合方式基于前两步基本能定下架构纯精确查询为主普通数据库别折腾。纯语义查询为主、数据量中等向量数据库单扛但原始数据仍建议落普通库。混合查询为主普通数据库 向量数据库组合或者用支持混合检索的向量数据库。超大规模 成本敏感IVFPQ 压缩配合普通数据库做元数据过滤。6.4 第四步小规模验证再全量别一上来就全量导入。先拿 1 万到 10 万条数据做验证跑通检索链路评估召回率和延迟确认嵌入模型效果。这一步能提前暴露大部分问题成本却低得多。验证通过再逐步扩量边扩边观察性能曲线。7. 混合架构下的实操细节7.1 ID 映射与数据同步普通库和向量库之间靠唯一 ID 关联。写入流程一般是先写普通库拿到 ID再用这个 ID 和内容去生成向量、写入向量库。这里要注意写入顺序和失败处理如果普通库写成功、向量库写失败就会出现数据不一致。常见做法是加一个补偿队列失败的重试或者定期做全量对账。同步延迟也要评估。如果是异步同步新数据可能几秒后才可检索。对实时性要求高的场景得用同步写入或者更快的同步机制。7.2 过滤字段的设计向量数据库里除了向量通常还要存一些用于过滤的元数据字段比如分类、时间、状态。这些字段的设计直接影响混合查询效率。原则是把最常用于过滤、选择性最高的字段放进向量库其他字段留在普通库。比如电商场景category和price是高频过滤字段放向量库而详细的商品描述、库存明细留在普通库。这样混合查询时向量库能独立完成过滤 相似度排序不用回普通库二次查询。7.3 结果融合与重排混合检索返回多路结果后需要融合。最简单的是加权求和但权重难调。更稳的是 RRF对每路结果按排名给分排名越靠前分越高最后合并总分排序。RRF 的好处是不依赖各路分值的绝对大小鲁棒性强。如果对精度要求极高还可以加一层重排模型Rerank用交叉编码器对候选结果重新打分。这一步精度提升明显但计算成本高一般只对 Top 50 到 100 的候选做重排。8. 我个人的几条经验之谈折腾了这么多项目有几个体会是反复被验证的。第一别为了用向量数据库而用。它是解决特定问题的工具不是架构升级的标配。我见过太多项目引入向量库后实际语义查询占比不到 5%纯属资源浪费。第二嵌入模型的选择比数据库选型更影响最终效果。同一个向量数据库换个更好的嵌入模型检索质量可能天翻地覆。预算有限时优先把钱花在模型上而不是堆数据库配置。第三召回率评估要常态化。数据分布会变模型会更新索引会老化。定期跑召回率评估才能及时发现检索质量下滑。我一般建议至少每季度做一次。第四架构上永远留一条退路。向量库再方便也要保证能从普通库全量重建。这样无论换模型、换数据库、还是索引损坏都能快速恢复。这条退路关键时刻能救命。选型这件事没有标准答案只有适不适合。把查询需求摸清楚把数据规模算明白把成本评估到位答案自然会浮现出来。