很多人第一次接触向量数据库，是在给大模型“加记忆”的时候。把文档切片、转成向量、写进库里，再让提问去召回相似片段，流程看起来干净利落。可一旦进入真实业务，问题往往从另一头冒出来：旧答案还在，新答案进不来；员工调岗后，权限没有跟着变；一份被撤回的文件，仍可能被检索到。检索快不快当然重要，但这类“记忆卫生”更早决定系统能不能用。
它解决的不是“存”，而是“找得近似”
向量数据库的核心工作，是把文本、图片等对象的语义特征变成向量，并在高维空间里寻找相近结果。它并不理解内容本身，也不负责判断答案对不对。开发者常把它和关键词检索放在一起看：前者擅长处理说法不同但意思接近的查询，后者对精确词、编号、专有名词更稳。实际系统里，两者混合使用并不少见。若把向量库当成万能搜索层，容易忽略它的边界。
真正麻烦的是更新与清理
内容一旦变成向量，维护就成了一套持续动作。文档改了，旧向量要不要立刻失效？切片粒度变了，历史索引是否还兼容？用户删除数据后，近似索引里的残留何时清除？这些问题没有一次配置就完事的答案。很多团队在演示阶段只关注召回效果，上线后才补上版本号、时间戳、来源标记和删除流程。向量数据库在这里更像一个需要运营的数据设施，而不是插上就灵的插件。
- 权限过滤要尽量贴近检索发生的位置，否则先召回再筛掉，既浪费算力，也可能留下信息暴露的缝隙。
- 来源与版本信息应随向量一起保存，方便回答时回溯，也方便内容变更后做定向清理。
- 对新鲜度要求高的场景，可考虑增量写入与定期重建并存的策略，但成本要提前算清。
另一个容易被低估的点是评估。向量检索的“看起来相关”很难直接等同于业务可用。需要准备一批真实问法，观察召回片段是否覆盖答案、是否夹带过期内容、是否在权限边界上出错。仅看相似度分数，往往不够。
把它放回系统里看
向量数据库不是大模型的外挂大脑，它只是检索链路中的一段。嵌入模型换了，向量分布会变；切片策略改了，召回结果也会变；业务规则更新，过滤条件同样要跟着调整。把这些变化纳入日常维护，比在选型阶段反复纠结参数更实际。对多数团队来说，先明确要解决的是语义召回、精确查找，还是二者混合，再决定要不要引入专门的向量数据库，可能更稳妥。它值得用，但前提是有人愿意处理那些不显眼的脏活。