在手机相册里翻照片，有时会遇到一种尴尬：记得画面偏青、光线很软，却想不起文件名，也想不起拍摄地点。用关键词搜“青”或“柔光”，结果往往不沾边。人脑对“相似”的容忍度很高，检索系统却长期习惯精确匹配。相似性检索被更多讨论之后，向量数据库这个说法开始频繁出现。
相似不是相等
传统检索里，条件通常是“字段等于某值”或“包含某词”。相似性检索问的是另一类问题：在大量高维向量中，找与目标向量距离较近的那些。图片、音频、文本片段经过模型转换成向量后，语义或感知上的接近，可能表现为空间里的邻近。问题也随之变化：候选数量大、维度高、还要在可接受延迟内返回结果。仅靠逐条比对，成本会迅速上升。
索引结构因此变得关键。近似近邻搜索用一定的召回损失换取速度，具体策略因实现而异。查询里若还带时间、类别、权限等过滤条件，过滤与近邻搜索如何结合，也会影响结果和延迟。插入、删除、更新同样不是附属功能：数据频繁变动时，索引维护开销需要计入日常成本。
它不负责“懂语义”
容易混淆的一点是，向量数据库并不生成向量，也不负责让模型“理解”内容。它更像一个面向向量查询的存储与检索组件：接收向量和元数据，建立索引，执行近邻查询，返回标识或附带字段。向量从哪来、用什么模型生成、模型更新后旧向量是否还有效，这些属于上游问题。模型一变，向量空间可能偏移，重建索引往往难以避免。把相似性检索的成败全压在一个存储组件上，并不现实。
另一个边界在过滤。带条件的近邻查询并不总能优雅地同时满足：过滤性很强时，先过滤再搜索可能让候选集过小；先搜索再过滤又可能返回不足。不同系统对这类混合查询的支持程度不同，实际表现需要用自己的数据验证。这里没有放之四海而皆准的配置。
什么时候可以先不上
如果数据规模有限，查询频率不高，内存里的近邻索引或现有数据库的向量扩展可能已经够用。引入独立组件意味着多一份运维、备份、监控和权限管理。判断起点不是“别人都在用”，而是查询里有多少是“相似”而不是“相等”，数据增长是否会让逐条比对变得吃力，更新频率是否会让索引维护成为负担。这些问题回答清楚，再决定要不要把向量检索单独拆出来。
所以，向量数据库更像一种针对特定查询形态的组件，而不是所有检索问题的通用答案。它适合处理高维向量的近邻查询，但需要和向量生成、过滤策略、更新流程一起设计。先看查询模式，再看数据规模，答案通常就会清楚一些。