前阵子帮一个团队看他们的语义搜索模块。演示很顺：输入一句口语化的问题，系统能从几千条帮助文档里挑出几条意思相近的答案。真上线之后，反馈却变得零碎——用户说“搜出来的东西看着像，但不是我要的”。这句话几乎概括了这类检索最常见的误解：相似是一种数学关系，有用是另一种。
它擅长的是“意思接近”，不是“答案正确”
文本经过嵌入模型压缩成一组浮点数，语义相近的内容在这个空间里距离更近。向量数据库做的事情，是把这些向量存起来，并在给定查询向量时快速找出邻近的那些。倒排索引匹配字面，它匹配方向。这带来一个直接后果：同义改写、跨语言、口语与书面语之间的缝隙被抹平了，但抹平本身也意味着细节被牺牲。否定词、限定条件、时间范围，恰恰容易被语义相似吞掉。
真正难的部分在检索之外
很多人以为选个引擎、建个索引就结束了。实际做下来，麻烦集中在几处：
- 带条件的近邻检索。用户往往既要语义相近，又要限定某个分类或时间段。过滤和近邻谁先谁后，会直接影响召回质量与延迟。
- 数据更新。文档会改、会删，向量也要跟着变。增量写入与索引重建的节奏，需要提前想清楚。
- 切分策略。一段话切成多大、重叠多少，决定了召回的粒度。这一步没有通用答案，只能拿自己的语料反复试。
这些工作不显眼，却决定了最终体验。把向量数据库当成一个黑盒插进系统，通常会在这里卡住。
有些问题它本来就不该接
精确匹配、编号查询、按字段聚合统计，这些交给传统索引更稳妥。反过来，凡是需要“理解意图”的入口，纯关键词方案又常常漏召回。更常见的做法是混合检索：关键词先保住精确命中的结果，语义检索补充意思相近的结果，再交给排序环节。向量数据库在这条链路里只是其中一段，把它当成全部，预期就会跑偏。
怎么判断值不值得引入
我的建议是先问三个问题：语料里同义表达多不多？用户的查询是短关键词还是完整句子？系统能否接受“先召回一批再筛选”的交互？如果答案偏向后者，收益会比较明显；如果业务主要是精确查找，投入产出比可能并不划算。
评估方式也要换。别盯着相似度分数看，那只是模型内部的度量。看用户点没点、改没改写查询、有没有在结果里真的找到答案。这些信号虽然粗糙，但比余弦距离诚实得多。
最后一点体会：这类工具的说明文档往往写得比实际用起来轻松。它不神秘，也不万能，更像一块需要仔细打磨的零件。真正花时间的，是把业务里的“相关”翻译成可计算的东西——这件事，任何引擎都替不了。