想象一个很小的需求：用户只记得一段文案“像雨后被晒热的柏油路”，却想找回商品详情页里那句类似的话。关键词检索会为难，因为页面里未必有“雨后”“柏油路”。这时，系统往往先把文本转成一串数字，再去找数字空间里距离相近的内容。向量数据库处理的，就是这类“按相似度找东西”的问题。
它存的不是原文，而是可比较的坐标
嵌入模型把文本、图片或音频压成向量后，原文仍然要放在别处，数据库里留下的是向量、标识信息和必要的过滤字段。可以把它想成给内容建立一套坐标：语义接近的内容，坐标也靠近。查询时，系统把问题同样转成向量，再去索引中找邻近点。索引结构决定了查找路径，也决定了内存、构建时间和召回之间的取舍。这里没有神秘理解，只有表示方式和距离计算。
相似，不等于可以少做工程
真正落地时，麻烦常从“过滤”开始。用户既要语义相近，又要限定品类、时间或权限，向量检索与结构化条件如何配合，会直接影响结果稳定性。更新也是问题：内容频繁变动，索引需要重建或增量维护，延迟与成本随之变化。若把向量数据库当成万能检索层，容易忽略原文存储、权限校验和结果解释这些旧工作。它更像检索链路中的一段，而不是整条链路。
还有一个常被低估的边界：相似度分数不是业务正确率。它只说明两个向量在某个模型下的接近程度，未必等于用户真正想要的结果。模型换了，距离分布会变；切片方式变了，召回也会变。因此，向量检索需要和抽样评估、人工反馈、兜底关键词一起工作。把它放在合适的位置，本身就是工程判断。
先问清楚：你要找的是“相同”还是“相近”
如果业务只需精确匹配编号、订单号或标签，传统数据库的索引已经够用；引入向量检索反而增加模型调用、向量同步和运维负担。反过来，当查询本身模糊、内容形态多样，或者需要跨语言、跨模态找相似项，向量数据库才有明确位置。判断标准并不复杂：先看问题是否依赖语义相似，再看团队是否能接受近似结果和持续调参。
所以，别急着把“相似”塞进所有检索框。先确认用户是在找唯一答案，还是在找一类感觉；再确认系统能否承担模型更新、索引维护和结果校验。向量数据库不是语义搜索的开关，它只是把“相近”变成可查询的一层基础设施。想清楚这一层要解决什么，再决定是否引入，通常比追新更稳妥。