在一个内部知识库的搜索框里输入“合同到期后客户还想续，但价格没谈拢，之前怎么处理的”，只靠关键词，系统可能被“合同”“价格”这类词带走，返回一堆看似相关、实际答非所问的文档。人的提问往往带着场景、指代和隐含条件，字面匹配很难接住。向量数据库被频繁提起，正是因为它试图处理这类“意思相近”的检索问题。
把“像不像”变成可计算的距离
文本、图片或音频经过嵌入模型处理后，会变成一组向量。语义接近的内容，在向量空间里通常靠得较近。检索时，系统把查询也转成向量，再去找距离较近的记录。这个过程听起来只是算相似度，落到工程里却不只是算一算：数据要存、索引要建、过滤条件要带上、删除和更新要能被处理。向量数据库承担的，正是把这些环节组织成可用的检索服务。
如果只把向量当成一个附加字段塞进传统数据库，小规模验证也许能跑通；一旦数据变多、查询变复杂，索引结构、内存占用和结果合并就会开始暴露问题。这里没有神奇开关，只有取舍：索引用于加速查询，也会带来构建成本和召回偏差；过滤能缩小范围，却可能让原本的索引策略失灵；批量导入方便，实时更新又是另一套节奏。
它难的地方，不在“存向量”
很多人第一次接触向量数据库，会以为它的核心是存下高维数组。实际使用中，麻烦常出现在周边：元数据怎么设计，权限怎么隔离，混合检索怎么把关键词条件和语义条件放在一起，版本变化后旧向量要不要重建。一个知识库如果今天改了文档切分方式，明天换了嵌入模型，历史数据和新数据就可能不在同一语义尺度上。检索结果不稳定，未必是数据库本身的问题，也可能是数据流水线没有对齐。
另一个容易被低估的边界是评估。语义检索没有绝对正确的唯一答案，只有“对当前任务是否有帮助”。如果没有一批贴近真实提问的测试集，团队可能被演示效果迷惑：几个例子看起来不错，上线后却发现长尾问题不断。我的判断是，向量数据库不是把搜索变聪明的按钮，它更像一套围绕向量展开的检索基础设施。基础设施的价值，取决于数据治理、模型选择和产品约束是否配合。
什么时候需要它，什么时候可以先等等
当业务里的查询开始大量出现同义表达、跨语言描述、图片相似匹配，或者需要在海量非结构化内容中做语义召回，向量数据库就有讨论价值。反过来，如果需求主要是精确编号查询、固定标签筛选、强事务一致性，传统数据库仍然合适。两者并非替代关系，很多系统会各取所长，把结构化条件交给熟悉的关系型存储，把语义召回交给专门的检索层。
还要留意成本和运维。向量维度、索引类型、副本策略、冷热数据分布，都会影响资源开销。团队在选型时，与其盯着功能清单，不如先回答几个朴素问题：数据多久更新一次，查询延迟能接受到什么程度，召回不准时谁来定位，权限边界在哪里。把这些写清楚，再决定是否引入向量数据库，通常能减少后续反复。