搜索框里输入“报销流程太慢怎么办”，传统关键词检索可能返回一堆包含“报销”的文档，却漏掉写着“费用审批周期长”的那一页。语义检索想解决的正是这种字面不重合的问题：把文本转成向量，在坐标空间里找相近内容。于是很多人自然想到，上一套向量数据库。
这个想法不算错，但容易把一件事简化成一次采购。它确实承担向量存储和相似度查询，可它并不负责“理解”业务。查询和文档怎么切、embedding 模型是否贴合语料、召回结果如何重排，这些环节决定了实际体验。库只是链路中的一段。
它解决的是“找得到”，不是“答得对”
把向量检索接进问答系统后，常见误区是拿几条演示问题验证效果，就认为可以上线。真实查询往往偏短、偏含糊，还带权限、时间、状态等条件。此时单靠向量相似度不够，需要 metadata 过滤，甚至关键词召回兜底。向量数据库的过滤能力、更新方式和查询延迟，会在这里暴露出来。
比如权限过滤：如果先取近邻再筛权限，可能把大量无权结果算进候选；如果先过滤再检索，又可能影响索引效率。不同实现有不同取舍，选型时不能只看“支持向量”这个标签。
索引不是免费的
向量检索通常依赖近似最近邻算法，用少量召回损失换查询速度。参数调得激进，延迟好看，但该出现的片段没出现；调得保守，查询变慢，成本上升。索引构建、增量写入、删除更新也会带来维护工作。数据量不大时，这些成本容易被忽略；数据持续增长后，它们会变成日常问题。
- 召回率与延迟需要一起看，不能只压测平均耗时。
- 过滤字段的分布会影响查询计划，权限和时间条件要提前设计。
- 删除与更新是否即时可见，要和业务一致性要求对齐。
- 监控要能定位是 embedding、索引还是重排环节出了问题。
它不必替代关键词检索
很多场景里，混合检索是常见的折中：关键词负责精确命中编号、术语和专有名词，向量负责语义扩展，再用重排模型收敛结果。向量数据库可以作为其中一路召回，也可以只存语义向量；是否独立部署，取决于团队已有的存储、查询规模和运维能力。小规模场景用现有数据库的向量扩展也能跑通，不必为了“架构完整”增加一个组件。
我的判断是，先把查询日志和评估集建起来，再决定要不要引入向量数据库。用几十条真实问题看召回缺口，功能清单放在后面。它更像检索链路里的一个可替换部件，而不是一接就灵的答案。清楚它不做什么，和急着用它一样重要。