有人问过一个很朴素的问题：为什么在搜索框里输入“红色连衣裙”，系统能给出结果；换成“有点复古感的那条”，就什么也搜不到。前者可以被拆成几个标签，后者不能。它描述的是一种感觉，而传统数据库只认精确匹配、范围比较和倒排索引里的词。
问题就出在这里：现实里大量的查询需求，本来就是“差不多就行”。
相似度不是一个值，而是一段距离
要让机器处理“差不多”，通常的做法是先把内容交给一个嵌入模型，把一段文字、一张图片压成一串几百到几千维的浮点数。语义接近的东西，在这串数字构成的空间里距离也接近。于是“找相似”被翻译成“在高维空间里找距离最近的若干个点”。
向量数据库承接的正是这一步。它不负责理解语义，语义是模型给的；它负责在这些点被写进去之后，用可接受的时间把它们找回来。这个分工经常被含糊掉，导致选型时把模型效果和检索效果混在一起谈。
难的不是找最近，是找得又快又允许一点错
如果只有几千条向量，逐个算距离就够了。到了百万、千万级，逐个比对在延迟上撑不住。工程上的办法是牺牲一点准确性换取速度：建图索引、做聚类分桶、对向量做量化压缩，先把候选集缩小，再在小范围内精算。这类做法统称近似最近邻检索。
代价是召回率。调高召回，延迟和内存跟着上去；压缩得狠一些，响应快了，但真正相关的结果可能被漏在候选集之外。这个取舍没有普适答案，只能按业务能容忍的漏检程度来定。很多团队在这一步才第一次意识到，检索质量不是一个开关，而是一条可以左右滑动的曲线。
更麻烦的是过滤条件。用户往往既要“语义相似”，又要“发布时间在最近一周”“属于某个类目”。先按条件过滤再检索，候选集可能小到索引失效；先检索再过滤，返回的条数可能不够。不同的执行顺序会得到不同的结果，这一点在压测里不容易暴露，在真实流量里却会反复出现。
数据会变，而索引不太喜欢变
内容平台的数据是流动的：新文章每天进来，旧内容下架，描述被编辑。图索引这类结构对插入相对友好，对删除和大幅更新就没那么从容，常见的做法是标记删除、定期重建。重建意味着额外的计算和一段时间里的资源占用，也意味着运维上要留出余量。这一点在演示环境里几乎感觉不到，上线三个月后才会变成一件必须排期的事。
它承接的只是一类查询
把向量数据库当成万能存储是个常见的误会。按 ID 精确查、按时间范围扫、做聚合统计，这些用成熟的关系型或文档型系统更直接。真实系统里更常见的形态是混合检索：关键词召回一路，向量召回一路，再合并排序。向量检索只是整体检索策略里的一条路径，它擅长处理那些说不清、但举得出例子的需求。
如果一定要给一个判断：选型时容易犯的错，是先挑一个库，再回头想“相似”到底由哪个模型定义。模型一换，向量空间就变了，历史数据基本要重算一遍。真正需要提前想清楚的耦合点在模型这一侧，不在存储那一侧。
回到开头那个搜索框。“有点复古感的那条”能不能被搜到，取决于模型有没有把这种描述和对应的图片放进相近的位置；至于找得快不快，才是后面的问题。这两件事经常被放在一起讨论，但它们其实分属两个工种。