先设想一个不太愉快的场景：知识库上线了，同事输入一句口语化的问题，系统返回了几段语气相近、内容却绕开的文字。大家第一反应是“向量数据库不行”。这个判断来得太快。检索结果不理想，问题可能出在切分、嵌入模型、查询改写、过滤条件，也可能出在索引参数。向量库只是链路中的一段。
它擅长“像”，不等于擅长“准”
向量数据库的基本工作，是把文本、图片等对象转成向量，再按距离找相近项。它解决的是语义相似，不是事实校验。用户问“合同里付款节点怎么约定”，系统可能召回一段讨论付款风险的段落，语义很近，却没有答案。这不是库的错，而是“相似”与“正确”之间本来就有缝。要补上这条缝，通常得让关键词检索、结构化过滤和重排一起参与，而不是把全部期待压给一个索引。
更新与过滤，常被低估的麻烦
很多演示停留在一次性导入数据。真实业务里，文档会改，权限会变，用户会删。向量索引的刷新往往不是瞬时的，删除也可能先标记再合并。若检索层没有处理好版本与可见性，就会出现“旧答案还在、无权限内容被召回”的尴尬。过滤同样如此：先向量召回再按条件筛，可能把结果筛空；先按条件缩小范围再召回，又考验索引组织。这里没有一招通吃，只有对数据分布和查询模式的持续观察。
成本不是一个单价，而是一串取舍
把向量数据库放进架构图很容易，让它稳定服务却要算几笔账：嵌入模型调用、索引内存、副本、备份、重排服务，以及为召回率留出的余量。向量维度高、数据量大时，内存压力会先显现；查询并发上来后，延迟又会被放大。更现实的做法，是先从明确的业务问题出发，限定数据范围，保留可回退的关键词检索，再逐步观察语义召回带来的增量。不要为了“看起来智能”而把简单查询复杂化。
边界清楚，才好用
我倾向于把向量数据库看作一种检索组件，而不是知识管理方案。它能缩小“找得到”的范围，却不能替代内容治理、权限设计和答案评估。上线前不妨问四个问题：召回失败时能否解释？数据更新后多久可见？过滤条件是否会破坏召回？成本随规模如何变化？这些问题没有漂亮的标准答案，但会逼着团队把链路拆开看。检索体验的改善，往往来自对边界的老实承认，而不是换一个更响亮的组件名称。