从“搜关键词”到“搜意思”
在内容平台里输入一句模糊描述，系统返回的却不是包含这些词的文章，而是语义相近的段落。这个变化背后，查询不再只依赖字面匹配，而是先把文本、图片或音频转成向量，再在向量空间里找距离较近的对象。这时，向量数据库进入视野。
它的角色并不神秘：存向量、建索引、在大量候选里快速找出相似项。难点在于“相似”不是精确相等。传统数据库擅长“等于”“大于”“落在区间内”，而向量检索要回答的是“哪些对象离这条查询向量更近”。一旦数据规模上来，逐条比较代价太高，索引结构就变得关键。
索引解决速度，过滤解决业务
向量索引常见的思路，是用近似计算换取可接受的响应时间。它不一定保证每次返回全局最近的结果，但要在召回与延迟之间找平衡。工程上还要把元数据过滤一起考虑：比如只查某个时间范围、某个栏目、某种状态下的内容。若先做向量检索再过滤，可能召回不足；若先过滤再检索，又可能让索引利用率下降。这里的取舍，常常直接决定体验。
- 嵌入模型决定“意思”被如何表示，模型变化会直接影响检索效果。
- 索引参数影响查询速度与召回表现，需要结合数据分布调。
- 元数据过滤、更新频率、删除策略，决定了它能否长期稳定运行。
所以，向量数据库不是把数据丢进去就能用。它更像一套需要与嵌入模型、检索策略、业务过滤共同调校的基础设施。把它当成万能搜索按钮，通常会失望。
边界问题常被忽略
如果查询主要是精确条件、事务处理或强一致读写，传统数据库通常仍是自然选择。向量数据库擅长的场景，往往是非结构化数据的相似性查找：语义搜索、推荐召回、问答系统的上下文检索、以图搜图等。它也有代价：索引构建与重建需要资源，嵌入模型升级会带来迁移问题，召回质量难以用单一指标说清。
我的判断是，先问清楚“相似”要解决什么业务问题，再决定是否引入向量数据库。若只是少量数据、低并发查询，简单计算甚至也能撑住；当数据量、查询频率和语义需求同时上来，专门的系统才有意义。技术选型不该被热词推着走，而应从检索失败的真实场景倒推。
回到开头那个模糊搜索，用户感知到的是“它懂我”。系统内部发生的，是一次向量化、一次索引查询、一次结果重排。检索链路只是其中一环，却也是让语义检索从概念走向可运营服务的一环。