做知识库或者搜索功能时，常卡在一个地方：到底上向量检索，还是先做全文检索，或者两个都用。选错了要么答不准，要么白烧钱和算力。这篇不堆概念，先把两种检索的原理差异摆清楚，再给一套按数据形态、查询习惯、验收标准来判断的流程，让你在自己的场景里能直接落地选型。
做知识库或者站内搜索时，团队常常卡在同一个岔路口：是先上向量检索，还是先把全文检索做扎实，或者干脆两套一起上。选错的代价很直接，要么答非所问、用户搜不到，要么白烧算力和存储，维护成本还翻倍。这篇不堆术语，先把两种检索在原理上到底比的是什么摆清楚，再给一套按数据形态、查询习惯、验收标准来判断的流程，让你在自己的项目里能照着走完选型。
需要先说清一个前提：这两种检索不是谁替代谁的关系，它们匹配的信号根本不同。你把原理差异想明白了，后面很多纠结会自动消失，比如「为什么加了向量还是搜不到订单号」这类问题，本质不是调参没调好。
两种检索，底层到底在比什么
全文检索的底层是倒排索引：先对文档做分词，记录每个词出现在哪些文档里、出现几次、在什么位置，查询时把用户的词拿去做同样的处理，然后去表里查命中了哪些文档。它比的单位是「词」，所以对精确词、编号、专有名词特别友好，因为只要字符串对得上就能命中。
向量检索的底层是数值距离：把一段文本通过嵌入模型压成一个固定长度的向量，语义相近的文本在向量空间里挨得近，查询时把问题也压成向量，去算它和库里每个向量之间的距离，取最近的若干个。它比的单位是「意思」，所以换个说法、打错字、口语化提问，仍然有机会命中。
- 倒排索引
- 以词为键、文档列表为值的索引结构，查词即查文档
- 分词
- 把句子切成一个个可检索的词元，中文尤其影响效果
- 嵌入向量
- 把文本压成的一串数字，用来衡量语义接近程度
- 向量距离
- 两段文本在向量空间里的远近，越近通常越相似
- 全文检索擅长精确匹配，向量检索擅长模糊语义
- 两者都是匹配信号，不存在谁更先进的问题
- 很多真实场景需要两种信号一起用
- 先想清楚查询长什么样，再决定用哪种
各自会在哪些情况下掉链子
| 检索方式 | 容易掉链子的情况 | 典型表现 |
|---|---|---|
| 全文检索 | 用户换说法、写错字、问法很口语 | 正确文档在库里但搜不出来 |
| 全文检索 | 同义词、缩写没有维护进词表 | 只能靠人工不停补词表 |
| 向量检索 | 精确查找编号、型号、条款号 | 召回一堆意思相近但编号不对的 |
| 向量检索 | 结果不好解释为什么被召回 | 排查问题只能靠猜 |
| 两者共有 | 文档切分太碎或太长、语料重复杂乱 | 换方案也救不回来 |
全文检索最典型的短板是「词对不上就搜不到」。用户问「怎么退钱」，文档里写的是「退款流程」，如果没有同义词扩展，这次查询就是零结果。这类问题靠人工维护词表能缓解，但词表会越滚越大，维护成本不低。
向量检索最典型的短板是精确项。订单号、型号、规章条款号这类字符串，语义上没什么可「像」的，模型很容易把编号相近但内容无关的召回上来。而且结果往往不好解释，用户问「为什么给我这条」，你很难给一个直观理由。
还有一个共同的坑容易被忽略：如果文档本身切分得太碎或者太长、语料重复杂乱，那不管换哪种检索都答不准。这种情况下先回去查语料和切分策略，比换检索方案更有效。另外要提醒一句：数据量很小、查询关键词又很固定时，引入向量检索带来的复杂度和算力开销可能根本回不了本，这种情况不适用，老老实实用全文检索就行。
按场景选：四步判断流程
- 第一步：写清查询长什么样把用户真实的查询列举出十条左右，区分是「打关键词」还是「整句提问」。如果八成以上是关键词，全文检索的性价比通常更高；如果是整句自然语言提问，向量的价值才明显。
- 第二步：标出必须命中的硬项把编号、条款、人名、型号这类必须准的字段单独列出来。只要这类硬项在业务里不可错，就得先给全文检索留位置，不能只靠向量。
- 第三步：按数据形态选文档多、表述杂、需要跨说法找内容，倾向向量；字段规整、以精确匹配为主，倾向全文检索。两边都占的，考虑混合。
- 第四步：定验收再拍板拉一批真实问题，人工标出正确答案，两种方案各跑一遍比召回情况，用数据说话。凭感觉选型，后面返工概率很高。
这四步里最容易偷懒的是第一步和第四步。很多人直接凭「我们要做 AI 搜索」就上了向量，结果发现用户压根是拿它当关键词搜索用。验收环节也别省，标注一批问题虽然费时间，但能省掉后面反复换方案的折腾。想横向看看同行的做法，可以到工具目录页面按「检索」「向量数据库」这类标签翻一翻，对照自己的场景。
混着用：什么时候该把两种合起来
混合检索的典型做法是两路各召回一批结果，再合并排序。这样既能保住精确词的命中，又能补上语义。代价是要同时维护两套索引，写入和更新都得双份，排错时也要判断是哪一路出了问题。
重排是第二步优化：先做粗召回，比如两路各取一批，再用一个精排模型对候选重新排序。效果通常比单靠向量好，但会额外增加延迟和成本，得看你的响应时间预算撑不撑得住。
- 先跑通一路检索，确认它单独能用，再叠另一路
- 两路召回数量别一次调太大，先小批量对比效果
- 把每一路的召回结果分别打日志，方便定位是谁召回的
- 合并排序的规则要写清楚，避免以后没人说得清结果怎么来的
- 响应时间有硬要求时，先量一下精排带来的延迟再做决定
工程上最忌讳一上来就搭混合架构，链路一长，出问题时根本不知道是哪一环的锅。稳妥的顺序是：先单路可用，再叠第二路，最后才考虑精排。至于嵌入模型和向量维度怎么挑，各家口径不一样，别只看单一指标，可以到嵌入模型页面核对当时的说明和维度信息。
下一步想按预算和可信度筛一轮候选方案，先去站内的中转站导航页看当前可选项，再拿本文的四步流程对着自己的数据跑一遍验证。→常见问题
小项目数据量不大，直接上向量检索是不是更省事？
不一定。数据量小、查询又偏关键词时，全文检索几行配置就能跑，维护成本更低。向量检索要管模型、维度和索引更新，省不下来多少效果。先用你真实的查询样例各跑一遍，谁召回准用谁，别按「先进程度」挑。
向量检索搜不到精确的编号和型号，怎么补？
把这部分交给全文检索兜底，或者在建索引时把编号、型号当成独立字段一起存，查询时先做精确匹配再走语义。纯靠向量去记一长串编号和型号，通常不靠谱，混合方案更稳。具体做法取决于你的数据结构，先列清哪些字段必须精确命中。
两种检索都要，是不是成本和延迟一定翻倍？
不一定，取决于召回规模和排序方式。两路可以各召回少量结果再合并，开销可控。真正的成本大头常在重排模型和索引更新频率上，而不是多查一路。上线前用 接口测速 量一遍自己的延迟基线，再决定合并几条。
