在一次内部知识库演示里，有人输入“上次说的蓝色包装方案”，传统关键词检索返回了一堆含“蓝色”“包装”但不相干的文档。换成基于语义的检索后，系统命中了那份讨论记录。现场很容易把功劳归给“向量数据库”，但真正发生的事情更朴素：文本先被嵌入模型压成向量，数据库负责在大量向量中找出距离相近的几条，再把原文交还给应用。
这个链条里，数据库并不是理解语言的那一方。它不理解“蓝色包装”是什么意思，只处理数字。理解来自嵌入模型，排序来自距离度量，业务判断仍然要由应用层完成。把这点说清楚，很多期待就会回到合理位置。
它擅长的是相似，不是正确
向量检索的强项是“找相近”。相近可以来自同义表达、上下文相似，甚至跨语言的语义接近。但它不保证结果一定正确，也不天然知道权限、时效和版本。一个旧版本的方案和最新讨论可能在向量空间里挨得很近，数据库不会自动判断哪份该优先展示。所以实际系统里，元数据过滤、权限校验、更新时间排序、原文重排往往要一起工作。向量数据库只是其中一层，负责把候选范围收窄。
这也解释了为什么有些团队接入得很快，效果却不稳定。问题未必出在数据库本身，而在于嵌入模型是否适合语料、切片是否保留了上下文、查询是否需要改写、过滤条件是否设计得足够细。把这些环节省略，只比较某次检索结果，很容易得出偏差结论。
工程上的麻烦常藏在细节里
当数据量不大时，用内存索引或现成库也能跑起来；一旦进入持续写入、频繁更新、多租户隔离的场景，问题会变得更具体。索引构建需要时间，删除和更新要处理残留，过滤条件会改变候选集，召回结果还要和业务规则对齐。向量数据库要面对的不是一次演示，而是长期运行中的数据一致性和可维护性。
- 嵌入模型换了，旧向量是否需要重建，版本如何共存；
- 文档切片过粗会丢上下文，过细又可能把一句话拆散；
- 过滤字段设计得太少，权限和时效就只能留给应用层兜底；
- 召回结果不能直接当答案，仍需重排、引用和人工校验。
这些问题没有统一答案，它们取决于语料形态和业务约束。把向量数据库当成“装进向量就能搜”的盒子，往往会低估后面的维护成本；反过来，把它只当成普通索引，也可能忽略它在语义召回上的独特位置。
我的判断是：向量数据库适合承担语义候选生成这一层，不适合被包装成端到端的理解系统。它让检索从字面匹配往前走了一步，但这一步之后，模型选择、数据治理和结果校验仍然要有人负责。评价一个系统时，与其看演示里那一次命中，不如看它在数据更新、权限变化和错误结果出现时，能不能解释清楚自己做了什么。