深夜调一个语义搜索，输入“报销流程为什么慢”，返回的却是“差旅标准”和“发票粘贴示例”。字面上都沾边，点开却解决不了问题。于是有人问：向量数据库是不是不够聪明？
这个疑问把责任放错了地方。向量数据库并不理解“为什么慢”，它做的是把查询向量和库里已有向量做近似最近邻计算。查询被编码成什么，取决于嵌入模型；返回的邻居是否可用，还取决于分块方式、过滤条件和评估口径。数据库只是链路中的一段。
它擅长找“像”，不负责解释“为什么”
向量检索的起点是嵌入。文本被切成块，转成稠密向量，语义相近的块在空间里靠得近。问题在于，“相近”不等于“有用”。一段流程说明和一句吐槽可能共享“报销”“慢”这些词，却不在回答同一个问题。若分块切得太碎，上下文丢失；切得太长，主题被稀释。检索结果看似相关，实则是嵌入空间里的邻居，不是业务上的答案。
所以调优时先别急着换库。把误召回的例子摊开，看是查询表达不清、分块不合理，还是嵌入模型没有覆盖业务词汇。向量数据库不会替你做这一步判断。
过滤、更新和评估，才是日常
真实系统很少只做纯向量检索。权限、时间、品类、状态这些条件，通常要以元数据过滤的形式参与。过滤放在检索前还是检索后，会影响延迟和结果覆盖；工程上常要在索引结构和过滤选择之间做取舍。这里的取舍没有统一答案，只有和查询模式是否匹配。
更新也不轻松。嵌入模型一换，旧向量和新向量就不在同一语义空间，混用会让结果漂移。删除、重建、版本切换需要流程，不能只靠一次全量导入。评估同样不能只看几个演示查询。需要准备一组贴近业务的查询，记录有用结果是否出现、近似重复是否挤占位置、过滤后是否还有足够候选。这些指标不华丽，却决定检索是否可维护。
把它放回系统里
稳妥的做法，是把向量数据库当成语义层的索引，而不是业务数据的单一来源。权限、事务、审计、精确匹配，仍由原有系统承担；向量层负责把“说得不一样但意思相近”的查询接住。它和关键词检索、规则过滤常常需要配合，而不是互相替代。
下一次遇到似曾相识的搜索结果，先别问它聪不聪明，先看嵌入、分块、过滤、更新和评估这五件事。这项技术的耐心，藏在这些不显眼的工程细节里。