在搜索框里输入“附近能修伞的店”，传统关键词检索可能会卡住：页面写的是“雨具维修”，两个词没有字面重合。语义检索想解决的，就是这种“说法不同、意思接近”的匹配。向量数据库在这里承担的是其中一段工作：把文本、图片或音频转成向量，存好，并在查询时快速找出距离较近的那一批记录。
它不负责“理解”，但负责把理解结果放好
向量通常由嵌入模型生成。一段话变成一串数字，语义相近的内容在向量空间里靠得近。向量数据库做的事更偏工程：建立索引、管理元数据、处理增删改、在查询时返回候选结果。它不直接生成答案，也不保证语义一定正确。答案质量往往取决于上游模型、切分方式、查询构造和下游排序。
把它想成一个专门存放“语义坐标”的仓库更准确。仓库的价值不只在能存，还在查询时能带着过滤条件取货。例如只检索某个租户、某个时间范围、某类文档。没有这些约束，语义相近但业务上无关的内容也会被捞出来。
真正麻烦的是数据会变
演示阶段，几万条文本跑出相近结果，容易让人产生“已经完成”的错觉。进入日常使用后，问题会变成另一组：文档更新了，旧向量要不要重算？嵌入模型换版本，历史向量还能不能混用？用户删除了资料，索引里是否同步消失？这些不是靠一个查询接口就能自动解决的。
- 模型变化会改变向量空间，混用不同模型生成的向量，距离含义可能不再一致。
- 文档切分过粗，检索结果会带着大量无关内容；切得过细，上下文又容易断裂。
- 权限过滤如果只在应用层做，检索结果仍可能把不该出现的内容带进候选集。
- 频繁更新会带来重建索引的成本，离线任务和在线查询需要分开考虑。
所以，向量数据库并不是“接上就懂”的组件。它更像一个需要与数据治理配套的基础设施：记录向量由哪个模型生成，保留版本信息，设计更新流程，并把权限条件纳入检索路径。否则，语义相似度越高，越可能把不合适的旧资料翻出来。
什么时候需要它
如果只是按编号查记录，或关键词匹配已经足够稳定，引入向量检索会增加一条维护链路。它适合那些查询表达模糊、内容形态多样、需要按语义找候选的场景，比如资料问答、相似内容查找、图片或音频的近似检索。是否使用，先看检索失败到底发生在哪一步：是字面不匹配，还是结果排序不对，还是数据本身缺失。不同问题对应不同改法。
回到“修伞”的例子，用户能不能找到店，不只取决于向量数据库。还要看店名、服务描述、地理位置、营业状态有没有被正确写入，查询时有没有把“附近”转成可过滤的条件。语义检索补上了一段匹配能力，但一段能力无法独自承担整个搜索体验。