内部知识库里，用户输入“退款多久到账”，关键词检索可能先命中“退款政策总览”，而真正有用的段落藏在“到账时间说明”里。语义检索想解决的，就是字面不重合时的召回问题。向量数据库常被放在这条链路的前台，但它并不是让搜索变聪明的按钮，更像一段需要被认真设计的基础设施。
它存的是向量，不是“理解”
文本先被嵌入模型压成向量，向量数据库负责保存、索引并做相似度搜索。用户问题也走同一套嵌入流程，系统再找距离接近的片段。这里的关键词是“接近”，不是“正确”。如果切块把一句完整规则拆散，或者嵌入模型对业务词不敏感，再顺滑的索引也补不回来。把这些环节拆开看，向量数据库解决的是存取与索引问题，不是语义理解本身。
过滤条件一多，事情就变复杂
真实查询很少只有语义相似。用户还会带时间、权限、产品线、文档状态等条件。先过滤再搜向量，可能把候选集切得太碎；先搜向量再过滤，又可能在结果末尾才遇到符合条件的内容。不同系统在这件事上的策略不同，效果也会随数据分布变化。团队在测试时不能只看几条漂亮查询，还要看带过滤、带否定词、带长尾表达时是否稳定。
- 元数据设计是否足够支撑权限与时效过滤；
- 更新和删除后，索引能否及时反映最新状态；
- 召回结果是否需要重排模型再处理一遍；
- 日志里能否看到召回、过滤、重排各环节的损耗。
什么时候值得单独引入
小规模知识库用现有数据库的向量扩展也能跑起来，未必需要新组件。当数据量、并发查询、复杂过滤和多租户隔离一起上来，向量数据库才更像一个需要认真对待的基础设施。选型时，比起看宣传页上的单点指标，更值得问的是：写入后多久可查，删除是否彻底，过滤性能是否稳定，故障恢复要多久，团队是否愿意长期维护一套新系统。
另一个容易被低估的点是混合检索。语义相似擅长处理换一种说法，但对编号、专有名词、精确条件并不总是可靠。把关键词检索、向量检索和重排放在同一条链路里，通常比单独依赖某一种方式更接近实际需求。代价是复杂度上升，排查问题也更依赖可观测性。
所以，面对“要不要上向量数据库”这个问题，先别急着比较参数。把查询拆开，看哪些靠语义，哪些靠过滤，哪些必须精确匹配；再看现有存储能否支撑更新与并发。向量数据库可以成为语义检索的一部分，但它不是检索质量的全部来源。真正决定体验的，往往是数据切分、嵌入模型、过滤策略和重排环节是否被认真对待。