客服后台有一条差评：「东西到了，但盒子是瘪的，心情也跟着瘪了。」运营想知道，历史上还有多少用户抱怨过类似的事。用关键词搜「盒子」，会捞出一堆问包装尺寸的；搜「瘪」，又漏掉说「压扁」「变形」「凹进去」的人。这类活儿，正是向量数据库被拉进来的场景。
先把「相似」变成距离
做法不复杂：用一个嵌入模型把每段文本压成一串数字，也就是向量。语义接近的句子，向量在高维空间里的位置也接近。于是「找意思相近的话」变成了「找距离最近的点」——一个几何问题。
麻烦在于点太多。逐条比对在数据量小的时候还行，规模上去之后，每次查询都要算一遍全部距离，代价难以接受。向量数据库要处理的就是这一层：用近似索引把大部分明显不相干的点先排除掉，只在一小片候选里做精确计算。
近似两个字，藏着取舍
「近似」意味着它可能漏。索引参数调得松，查询快、召回低；调得紧，结果全、延迟和内存都上去。这不是实现缺陷，而是这类系统的固有交换。真正落地时，团队往往要拿一批真实查询反复试，才能找到自己业务能接受的那个点。
另一处容易踩空的是过滤。业务查询很少是纯语义的，往往还要「只看最近三个月」「只看某个品类」。带条件的近邻搜索，处理不好会出现候选被条件筛空，或者为了满足条件而放弃索引的情况。这类混合查询的能力，比向量维度、索引类型这些参数更值得在选型时追问。
它不负责的事情
- 不负责判断对错。向量只表达「像不像」，不表达「是不是」。
- 不负责一致性。嵌入模型一换，整个库的向量就得重算；新旧向量混在一起，距离不再可比。
- 不负责原始数据的权威性。文本、图片、权限这些，仍然要留在原来的系统里。
所以更常见的架构是：业务数据留在关系库或对象存储里，向量库存向量和指向原文的标识，检索拿到候选之后，再回源补齐。向量数据库是这条链路上的一环，不是新的中心。
先问自己三个问题
在把一套系统接进来之前，与其比较参数，不如先回答：我的嵌入模型会不会频繁更换？我的查询里有多少带硬性过滤条件？我能接受多大比例的漏召回？这三个答案，基本决定了这套东西在你这里是刚需，还是可有可无的装饰。
回到那条差评。它需要的不是被归进一个标签，而是被放进一群说同类话的人中间，让人看见这不是孤例。向量数据库做的，就是把「意思」变成可以检索的东西——仅此而已，但已经够用。