在一个内部知识库的搜索框里输入“年假怎么请”，出来的却是“调休申请入口”。字面没有完全对上，意思却接近。传统关键词检索遇到这种场景，常常显得笨拙：它擅长匹配词，不擅长理解意图。语义搜索想解决的，正是这层错位。
做法并不神秘。文本先被嵌入模型压成一段向量，语义相近的内容在向量空间里彼此靠近。查询时，把问题也转成向量，再去候选集中找邻近项。问题随之出现：这些向量放在哪里，带条件时怎么找，数据更新后索引怎么维护。向量数据库就是围绕这些问题出现的一类系统。
它不只是“存向量”
如果只把向量当成一列数据，普通数据库也能存。麻烦在于检索方式不同：不是等值匹配，也不是范围扫描，而是找“离我最近的那一批”。当数据量不大，内存里的近似最近邻索引就能应付；当数据持续增长、需要按部门或时间过滤、还要兼顾删除和重建时，专门的向量数据库才有讨论价值。
这里的工程细节不太上镜，却决定体验。过滤和向量检索谁先谁后，会影响结果是否稳定；索引参数调得太紧，召回可能下降，调得太松，延迟和资源开销又会上来；批量导入和增量更新也不是一句“实时”能带过。向量数据库的价值，往往不在“存向量”这一步，而在这些琐碎但绕不开的维护工作。
检索到底要多“像”
语义相似并不等于任务正确。用户搜“调休”，可能想找流程，也可能想找规则，还可能只是打错了字。向量召回会把一批“看起来相关”的内容拉进来，但排序、截断、重排仍然影响最终体验。把这类检索接进系统，只是把候选集换了一种生成方式，并没有自动解决“什么才算相关”。
另一个容易被忽略的点是评估。没有一组贴近真实问题的查询集，很难判断换模型、改切分、调索引之后是变好还是只是变了。团队若只盯着单次演示里的几条结果，很容易把偶然当成能力。我的判断是，语义检索项目里，数据切分和评估集建设是容易被低估的耐心活。
边界常被忽略
不是所有应用都需要独立的向量数据库。数据规模有限、查询模式单一、团队没有额外运维精力时，现有数据库的向量扩展或内存索引可能已经够用。反过来，如果检索是核心链路，过滤条件复杂，数据生命周期长，专门系统提供的索引管理、快照恢复、权限隔离就值得纳入考虑。这里没有统一答案，只有约束条件下的取舍。
还要留意混合检索。很多真实查询既有字面约束，也有语义意图，比如型号、编号、时间范围。只靠向量容易漏掉精确项，只靠关键词又接不住同义表达。把两者结合，再配合重排和兜底策略，是一种务实做法。它在这类架构里只是一个组件，不是整套方案。