设想一个客服知识库：用户输入“买错了想退”，后台明明存着“退款申请入口”，搜索结果却是空的。原因不复杂，倒排索引按字词匹配，用户的说法和文档的措辞没有重合，链路就断了。这类问题在内部文档检索、工单归类、商品描述搜索里反复出现，也正因如此，向量数据库这几年被频繁提起。
思路是把文本交给模型编码成一串数字，也就是向量。语义相近的句子，向量在空间里的距离也近。检索时先把查询也编码，再在已有的向量集合里找距离最近的若干条。听起来简单，真正麻烦的是“找”这一步：向量维度动辄几百上千，逐条比对在数据量上来之后延迟会很难看。
折中发生在“找”这一步
于是工程上普遍接受一个折中：不追求精确的最近邻，改用近似算法，用少量召回损失换回可接受的响应时间。常见做法包括构建可导航的图结构、对向量做量化压缩，或者先把向量分桶再在桶内细找。这些结构在数据写入时维护，查询时沿索引走，避免全量扫描。向量数据库要处理的，正是索引构建、增量写入、持久化和查询调度这一整套事情，而不只是“存向量”三个字。
但把它当成默认选项，容易踩坑。数据规模不大的时候，内存里做一次暴力比对往往够用，额外引入一套系统反而增加运维负担。更现实的问题是更新：索引结构对频繁写入并不总是友好，删除和修改常常要靠标记加合并来消化，实时性要求高的场景要提前想清楚。还有一个隐性成本容易被忽略——编码模型一旦更换，历史向量与新查询就不在同一个语义空间里，通常需要重建索引，这不是改个配置能解决的。
精确匹配并没有退场
另一个常被演示视频掩盖的事实是，精确匹配仍然有它的位置。订单号、型号、人名这类查询，倒排索引的准确和可解释难以替代。实践中更常见的形态是混合检索：先各自召回，再融合排序。它在这里承担的是语义那一路，而不是全部。
所以评估时，与其看演示里那几张相似度热力图，不如先翻自己的查询日志：用户到底在用什么词找东西，错配发生在哪一类查询上。如果问题集中在同义表达和口语化描述，语义检索值得投入；如果主要是拼写错误和专有名词，先补同义词表和纠错可能更划算。向量数据库不是把旧检索推翻重来，它更像在原有链路上加了一层，能不能发挥作用，取决于这一层是否对准了真实的查询分布。