设想一个内部知识库：员工输入“出差发票丢了怎么报销”，关键词检索却把“发票”和“报销”拆开匹配，返回一堆制度目录。问题不在于内容少，而在于系统只认字面，不认意思。这时，向量数据库常被拿来讨论。
它处理的是“相似”，不是“相同”
文本、图片或音频经过嵌入模型变成一串数字，也就是向量。语义相近的内容，在向量空间里的距离通常更近。向量数据库负责保存这些向量，维护索引，并在查询时做近似最近邻搜索，同时带上一些元数据用于过滤。它并不替代传统关系型数据库，也不负责业务事务；它更像一层面向相似度检索的基础设施。真正决定效果的，往往不是“把数据灌进去”这个动作，而是前面的切分、嵌入模型选择和后面的结果重排。
有了向量数据库，搜索就会变聪明吗
不一定。若原始文档标题混乱、权限标签缺失、切分颗粒度过大，向量检索只会把模糊的问题放大。一个常见误解是以为相似度可以包办一切。实际系统里，精确匹配、结构化过滤、权限校验仍然要做。更稳妥的思路是混合检索：关键词负责召回明确词，向量负责补充语义相近的表达，再根据业务规则合并结果。对于合同编号、订单号这类精确查询，向量相似度未必合适；对于“意思相近但说法不同”的问题，它才有发挥空间。
讨论选型前，先问几个朴素问题
- 数据更新和删除是否频繁？索引维护会不会成为负担？
- 查询是否需要复杂的元数据过滤，比如部门、时间、权限？
- 是否准备做混合检索和结果重排，还是只想要一个相似度接口？
- 团队能否观察召回质量、延迟和资源消耗，并持续调整切分与嵌入？
这些问题没有统一答案。小范围验证通常比一次性铺开更可控：挑一类问题明确的文档，先看召回结果是否真的解决了提问，再决定是否扩大范围。向量数据库的价值不在“新”，而在它把语义相似度变成了可查询的能力。至于这项能力是否值得引入，取决于数据治理是否跟得上，以及团队是否愿意把检索当成一个持续调优的产品问题，而不是装完就结束的技术动作。