演示环境里，几千条文本的语义搜索几乎瞬间返回；等语料涨到几十万条，同样的查询要等上好几秒，内存也开始吃紧。这时候，「要不要上一个向量数据库」常被提上议程。问题在于，这个决定没那么直白。
它解决的其实是一个「找近似」的问题
向量数据库的核心工作，是把高维向量按某种索引组织起来，让「最相似的若干条」能在可接受的时间内被找出来。精确的暴力比对当然准确，代价是每次查询都要遍历全部数据。近似最近邻索引换掉一部分准确率，换回速度与内存的平衡。HNSW 靠分层图跳转，IVF 先聚类再在若干簇里找，量化方法则压缩向量本身。它们各自都有需要调的参数，也都有各自付出的代价。
慢，未必是数据库的错
查询变慢的原因常常不止一处。embedding 模型本身的推理开销、一次请求要跑多轮检索、过滤条件与向量检索的先后顺序、索引是否常驻内存——这些环节里任何一处出问题，表现都像「存储层不行」。在换组件之前先弄清楚瓶颈在哪，通常比直接引入新系统省事。尤其当过滤条件很严格时，先过滤再检索和先检索再过滤，结果与耗时可能差得很远。
边界：什么时候不必上
- 数据规模有限、查询并发不高时，一个进程内的索引库加上持久化文件，往往够用；
- 已有的关系型数据库若提供向量扩展，能省掉一套运维；
- 检索质量的上限更多由 embedding 决定，换存储换不来语义理解。
反过来说，当数据持续增长、需要多副本与在线更新、需要把向量检索和元数据过滤混在一起处理时，专门的向量数据库才有它的位置。
被忽略的成本
索引重建、内存占用、删除与更新的一致性，这些在演示阶段都看不见。向量索引对频繁写入并不总是友好，批量导入和增量写入常常需要不同策略。还有评估：召回率怎么测，相似度阈值怎么定，换掉模型之后要不要重跑一遍。缺一套离线评估，线上调参基本靠猜。
混合检索的现实
纯向量检索在关键词精确匹配上会露怯，产品名、编号、专有名词尤其明显。多数实用系统最后走的是向量加关键词的混合路线，再用重排模型收尾。这也意味着，引入向量能力之后，检索链路的复杂度是上升的，而不是下降的。
所以向量数据库值得被认真看待，但它既不是语义搜索的起点，也不是终点。先把数据规模、更新频率、过滤复杂度、评估手段这几件事说清楚，再决定要不要为它增加一套组件。这个顺序，比选哪个名字更影响最终体验。