有人在站内搜索框里敲下“出差回来怎么报账”，返回的却是采购管理办法和一份年会通知。文档都在库里，字面上也能对上几个词，可就是没找到那份流程图。这类失败通常会把人引向同一个方案：上向量数据库。
这个判断未必错，但把问题直接归给它，后面的工作往往会变得含糊。
它在做的其实是一件范围很窄的事
文本、图片、音频先经过嵌入模型，变成一串浮点数。语义接近的内容，在这串数字构成的空间里距离也接近。向量数据库负责把这些数字存下来、建索引，让“找出最近的若干个”在可接受的时间内完成。它并不理解“报账”是什么意思，那一层理解发生在模型里；它擅长的是在高维空间里快速做近似近邻检索。
把职责分开之后，排查就有了方向：结果不对味，先看嵌入模型是否适配你的语料，再看切片是不是把一份完整流程切成了互不相干的碎片。
三类反复出现的失望
- 模型不适配。通用模型对行业术语的处理常常含糊，两个意思相反的表述可能在向量空间里挨得很近。
- 切片粗暴。按固定字数硬切，会把条件和结论分到两段，召回的片段读起来像半句话。
- 过滤叠加。带时间、部门等条件筛选时，候选集被压缩，召回质量可能明显下滑，调参也未必拉得回来。
被低估的是更新与一致性
原文改了，向量得重算；文档删了，索引里的条目也要跟着消失。这些动作在演示阶段几乎不出现，上线后却每天都在发生。真正麻烦的是嵌入模型换版本：旧向量和新向量不在同一个空间里，混着用会得到难以解释的结果，通常只能整体重建。重建期间查询怎么服务、要不要留一份旧索引兜底，这些都需要提前想清楚，而不是等出事再补。
还有一个容易被忽略的细节：向量只承载语义，权限、时效、版本这些约束仍然要靠外部的元数据来管。检索层做得再顺，如果过滤条件没有在召回阶段就生效，返回的内容依然可能是不该出现的那一份。
什么时候可以先缓一缓
语料规模不大、查询以编号、人名、专有名词为主的场景，传统检索引擎加上同义词表和少量规则，往往已经够用，而且行为可解释、出错好定位。确实需要语义召回时，把关键词检索与向量检索并用，让两路结果互相补位，通常比单靠一路稳当。
回到开头那个搜索框。问题可能出在嵌入模型，可能出在切片，也可能出在从来没人认真整理过那份文档。向量数据库只是链条上的一环，它能扩大召回，但扩大的部分里同样有噪声。先想清楚要解决的是“找不到”还是“找不准”，再决定要不要引入它，比先上一套系统、回头再找理由要省事得多。