一个常见的场景是：团队把文档切块、生成向量，接上模型，演示时提问几乎都能命中。过一阵子，文档更新了，权限变细了，用户开始问“为什么昨天能搜到，今天搜不到”。这时问题往往不在模型，而在检索链路里那块被忽略的基础设施。
向量数据库常被描述成“给 AI 用的新数据库”。这个说法不算错，但容易让人误以为只要把文本变成向量存进去，语义检索就完成了。实际工作里，它更像是把“相似度计算”这件事产品化：负责存向量、建索引、在可接受的时间内找出相近条目，并尽量配合元数据过滤和增量更新。它不负责理解业务，也不自动解决切块、权限和召回质量。
它补的是“相似”，不是“正确”
向量检索的核心，是把一段内容映射成高维空间里的点，再找距离近的点。好处是能绕过字面匹配，处理同义表达和模糊描述；代价是“近”不等于“对”。如果切块把上下文切碎，或者嵌入模型对领域词不敏感，向量数据库只能忠实地返回一堆看起来相近、实际无用的结果。于是上线后常见的动作不是换数据库，而是回头调整切块粒度、补充元数据、重做嵌入。数据库在这里是执行者，不是裁判。
真正考验人的，是更新和过滤
演示阶段数据少，全量重建索引也能接受。上线后，文档会增删改，权限会变化，用户还会带着筛选条件来查。此时要关注的是索引更新是否及时、删除是否彻底、过滤条件会不会让召回变窄、查询延迟是否稳定。向量数据库提供能力，但策略仍要由业务定义：哪些字段必须前置过滤，哪些内容允许延迟可见，旧向量何时清理。把这些当成数据库的“自动功能”，很容易在真实流量里露出裂缝。
- 数据量不大、更新不频繁时，先用现有存储加简单相似度计算也能撑住，不必为了概念提前上系统。
- 当语义检索成为主路径，且需要持续写入、过滤和多人维护时，专门的向量数据库才有比较清晰的用武之地。
- 无论选哪种方案，切块、嵌入、召回评估和权限控制都无法外包给数据库本身。
所以，面对“要不要上向量数据库”这个问题，更实际的问法是：检索是否会长期存在、数据是否会持续变化、团队是否愿意维护一条可观测的检索链路。如果答案是否定的，轻量方案也许就够用；如果答案是肯定的，那就别只盯着查询速度，也要看更新、过滤、删除和故障恢复。向量数据库不是让 AI 变聪明的开关，它只是把语义检索从演示推向日常的一层基础设施。