召回率上不去，搜索和 RAG 就废一半：一文讲透如何提高召回率

一、先说结论：什么是召回率？

召回率，说白了就是：

用户真正想要的内容，你有没有尽可能多地找出来。

举个例子。

用户搜索：

“怎么提高 RAG 检索效果？”

系统里其实有 10 篇相关文档，但你只召回了 4 篇。

那么召回率就偏低。

很多系统效果差，不是大模型不会回答，而是前面检索阶段就把正确资料漏掉了。尤其在搜索系统、推荐系统、知识库问答、RAG、智能客服、企业文档问答里，召回率非常关键。

二、为什么召回率这么重要？

2.1 召回率决定“有没有机会答对”

排序、重排、大模型生成都属于后续环节。

但如果第一步召回阶段没有把正确内容找出来，后面再强也没用。

这就像你让厨师做菜，但食材一开始就没买对。

2.2 低召回常见表现

用户会感觉：

明明知识库里有答案，但系统说不知道。
搜索关键词稍微换个说法，就搜不到。
用户输入口语化问题，系统匹配不到正式文档。
同义词、缩写、别名、错别字搜不到。
RAG 回答看起来很流畅，但内容不对。

所以提高召回率，本质上就是：

让系统尽可能别漏掉用户真正需要的内容。

三、提高召回率的核心思路

3.1 不要只靠一种检索方式

传统关键词检索擅长“字面匹配”，比如 BM25、倒排索引。

向量检索擅长“语义理解”，比如用户说“怎么提升检索命中率”，系统能找到“召回率优化方案”。

现在主流做法是 混合检索 Hybrid Search：把关键词检索和向量检索结合起来。Weaviate 官方文档也明确提到，混合检索会结合 BM25 关键词搜索和向量搜索的优势，既保留关键词精确匹配能力，又增强语义理解能力。

一句话：

想提高召回率，不要单腿走路，要多路召回。

四、方法一：关键词检索优化

4.1 做好分词

中文搜索里，分词非常重要。

比如：

“苹果手机维修”

如果分词错了，可能变成：

“苹果 / 手机维修”

也可能变成：

“苹果手机 / 维修”

不同分词结果，召回内容完全不同。

常见优化方式：

使用更适合业务的中文分词器。
加入业务词典。
加入品牌词、产品词、行业词。
对专有名词做保护。
对人名、地名、公司名做特殊处理。

例如在企业知识库里，可以把这些词加入词典：

混合检索
向量数据库
LangChain
Milvus
Elasticsearch
RAG
Agent
前缀缓存
KV Cache

否则系统可能会乱切词，导致召回失败。

4.2 做同义词扩展

用户表达是非常多样的。

比如用户搜索：

“提高召回率”

4.3 做别名和缩写处理

很多业务系统里，用户喜欢用简称。

比如：

中国工商银行 => 工行
中华人民共和国 => 中国
检索增强生成 => RAG
大语言模型 => LLM
向量数据库 => Vector DB

如果没有别名映射，用户搜“RAG”，文档里写“检索增强生成”，可能就搜不到。

所以建议维护三类词表：

4.3.1 中文别名表

阿里云 => 阿里云计算、Alibaba Cloud
腾讯云 => Tencent Cloud
飞书 => Lark

4.3.2 英文缩写表

LLM => Large Language Model
RAG => Retrieval-Augmented Generation
NLP => Natural Language Processing

4.3.3 业务内部黑话表

企业内部最容易出现这种问题。

比如：

智能客服项目 => 小智
搜索中台 => Search Hub
知识库系统 => KB

这些词对外人没意义，但对企业内部检索非常关键。

4.4 做拼写纠错和错别字处理

用户输入经常不标准。

比如：

Elasticsearch => ElasticSearch、ES、elsticsearch
向量数据库 => 向量数据哭
召回率 => 招回率

如果系统不做纠错，召回会明显下降。

可以做：

拼音纠错。
编辑距离纠错。
热词纠错。
用户搜索日志纠错。
大模型改写纠错。

例如用户输入：

“怎么题高招回率”

系统可以改写成：

“怎么提高召回率”

这一步对搜索体验提升很明显。

五、方法二：向量检索优化

5.1 什么是向量检索？

关键词检索看的是“词有没有出现”。

向量检索看的是“意思像不像”。

比如用户问：

“怎么让知识库问答更准？”

文档标题是：

“RAG 检索召回优化实战”

这两个句子字面不完全一样，但意思相关。

向量检索就有机会把它召回。

Pinecone 关于 RAG 的资料中提到，检索阶段会把用户问题转换成向量，再去向量数据库中搜索相似内容；混合检索还会结合稀疏检索与稠密向量检索，并在结果合并后进行重排。

5.2 选择合适的 Embedding 模型

向量检索效果很大程度取决于 Embedding 模型。

如果模型不适合中文，召回率会很差。

选择模型时要看：

是否支持中文。
是否支持中英混合。
是否适合问答场景。
是否适合长文本。
是否适合代码、法律、医疗、金融等垂直领域。
是否支持多语言。
是否有较好的语义相似度表现。

如果是中文知识库，尽量选择中文表现好的 Embedding 模型。

如果是企业内部技术文档，可以考虑：

通用中文 Embedding。
中英双语 Embedding。
代码 Embedding。
领域微调 Embedding。

5.3 文档切分要合理

RAG 里召回率低，很多时候不是模型问题，而是文档切分问题。

5.3.1 切得太大

如果一个 chunk 太大，里面混了太多主题。

用户问一个具体问题时，这个 chunk 的语义会被稀释，向量相似度下降。

比如一个 chunk 里同时包含：

用户登录
权限校验
订单支付
优惠券
日志监控

用户问“权限校验怎么做”，这个 chunk 可能不够聚焦。

5.3.2 切得太小

如果切得太小，上下文不完整。

比如只切出一句：

“具体流程如下。”

这种 chunk 没有意义，也很难被召回。

5.3.3 推荐做法

比较稳妥的做法是：

按标题层级切分。
按段落切分。
保留上下文。
设置 chunk overlap，也就是上下文重叠。
对表格、代码、列表单独处理。
给 chunk 加元数据，比如标题、章节、来源、时间、标签。

5.4 给 chunk 加标题和上下文

很多文档正文里没有明确关键词，但标题里有。

比如：

标题：三、如何提高召回率
正文：可以通过多路召回、Query 改写、混合检索、重排序等方式优化。

如果只把正文拿去向量化，可能少了“召回率”这个核心词。

更好的做法是：

标题 + 小标题 + 正文 一起向量化

例如：

文档标题：RAG 检索优化方案
章节标题：如何提高召回率
正文：可以通过多路召回、Query 改写、混合检索、重排序等方式优化。

这样召回效果通常会更好。

六、方法三：混合检索提高召回率

6.1 什么是混合检索？

混合检索就是：

关键词检索 + 向量检索 + 结果融合。

关键词检索适合找精确词。

向量检索适合理解语义。

两者结合后，召回率通常会明显提升。

Elasticsearch 对混合检索的解释是，将词法搜索和语义搜索融合成一个排序列表，词法搜索擅长匹配精确词和短语，语义搜索擅长理解查询背后的含义。

6.2 为什么混合检索能提高召回？

因为用户问题有两种典型类型。

6.2.1 第一种：关键词强相关

比如用户搜：

“Milvus HNSW 参数”

这种问题里，“Milvus”“HNSW”是强关键词。

如果只用向量检索，可能会召回一些“向量数据库优化”的泛化内容，但不一定精确。

关键词检索更适合。

6.2.2 第二种：语义强相关

比如用户问：

“为什么知识库明明有答案，大模型还是答不上来？”

这句话没有直接说“召回率低”，但本质就是召回问题。

向量检索更适合。

所以混合检索的价值就是：

精确词靠关键词检索，模糊意图靠向量检索。

6.3 常见混合检索架构

一个典型流程是：

用户问题
  ↓
Query 预处理
  ↓
关键词检索 BM25
  ↓
向量检索 Embedding Search
  ↓
结果合并去重
  ↓
重排序 Rerank
  ↓
返回 TopK 文档
  ↓
交给大模型生成答案

Weaviate 文档中也提到，Hybrid Search 会把向量搜索和关键词搜索结果融合，并且融合方式和相对权重可以配置。

6.4 结果融合怎么做？

不用讲复杂公式，可以理解成：

系统从两个渠道各找一批候选内容。

比如：

关键词检索召回：A、B、C、D
向量检索召回：C、D、E、F

合并后：

A、B、C、D、E、F

其中 C、D 同时被两个渠道召回，通常说明它们更重要。

常见融合方式：

分数加权融合。
排名融合。
RRF 融合。
规则融合。
先粗召回，再统一重排。

Elastic 的资料中提到，混合搜索可以通过 BM25 和向量检索结合，并使用 RRF 这类方式融合结果；向量可以提升召回，而关键词检索能保留精确匹配能力。

七、方法四：多路召回

7.1 什么是多路召回？

多路召回就是：

不只用一种策略找内容，而是多个召回通道一起找。

比如：

多路召回的核心目标是：

宁可多召回一些候选内容，也不要一开始就漏掉正确答案。

7.2 搜索系统里的多路召回

比如用户搜索：

“Java 面试问 RAG 项目怎么讲”

可以走多个通道：

7.2.1 标题召回

找标题里包含：

Java 面试
RAG 项目
大模型项目
简历项目

7.2.2 正文召回

找正文中出现：

混合检索
向量数据库
知识库问答
Agent
Embedding

7.2.3 向量召回

找语义相关内容：

AI 工程师面试
大模型项目包装
RAG 项目落地
简历优化

7.2.4 标签召回

根据标签找：

Java
AI 转型
RAG
大模型
面试

7.2.5 热门召回

如果很多用户都点击某类文章，也可以适当提高召回概率。

7.3 RAG 里的多路召回

RAG 场景中可以这样设计：

用户问题
  ↓
原始问题向量召回
  ↓
改写问题向量召回
  ↓
关键词 BM25 召回
  ↓
标题字段召回
  ↓
摘要字段召回
  ↓
元数据过滤召回
  ↓
合并去重
  ↓
重排序

比如用户问：

“项目里怎么体现混合检索？”

可以改写成多个查询：

然后分别召回，再合并。

这类方法对提高召回率非常有效。

八、方法五：Query 改写

8.1 为什么要 Query 改写？

用户的问题经常很口语化。

比如用户问：

“这个搜不到咋办？”

系统很难直接理解。

但可以改写成：

“搜索系统召回率低的原因和优化方法”

再去检索，效果会好很多。

Query 改写就是把用户原始问题变成更适合检索的问题。

8.2 常见 Query 改写方式

8.2.1 同义词改写

提高召回率
↓
提升检索命中率
减少漏召回
提高搜索覆盖率

8.2.2 问句改写成关键词

为什么我的知识库问答总是找不到答案？
↓
RAG 召回率低 知识库 检索不到答案

8.2.3 口语化改写成专业表达

搜出来的东西不全
↓
搜索系统召回率不足

8.2.4 多查询改写

一个问题生成多个查询：

原问题：怎么提高 RAG 检索效果？
 
改写：
1. RAG 如何提高召回率
2. 知识库问答检索优化方法
3. 混合检索在 RAG 中怎么用
4. 向量检索召回率低怎么解决
5. BM25 和向量检索如何结合

8.3 大模型改写 Query

现在很多 RAG 系统会用 LLM 做 Query Rewrite。

流程是：

用户原始问题
  ↓
大模型理解意图
  ↓
生成多个检索查询
  ↓
多路召回
  ↓
合并结果

例如用户问：

“我简历里那个 AI 文案项目怎么讲得高级点？”

大模型可以改写为：

AI 文案生成项目 架构设计
RAG 在内容生成系统中的应用
大模型项目 简历包装
AI 文案系统 技术亮点
提示词工程 内容生成 质量评估

这样能召回更多相关内容。

九、方法六：扩大 TopK

9.1 什么是 TopK？

TopK 就是检索时返回前多少条结果。

比如：

TopK = 5

表示只返回最相关的 5 条。

如果 TopK 太小，可能漏掉正确答案。

9.2 提高召回率可以适当扩大 TopK

比如：

关键词检索 TopK = 50
向量检索 TopK = 50
合并后 100 条
重排后取前 10 条

这样做的好处是：

第一阶段尽量多找，第二阶段再筛。

也就是：

粗召回：多找一些
精排序：再挑最好的

9.3 注意 TopK 不是越大越好

TopK 太大会带来几个问题：

检索变慢。
成本上升。
噪声变多。
大模型上下文塞不下。
后续重排压力变大。

所以更合理的做法是：

召回阶段 TopK 稍大
重排阶段压缩
生成阶段只放最相关内容

例如：

召回 100 条
重排 20 条
最终给大模型 5 条

十、方法七：重排序 Rerank

10.1 Rerank 不是直接提高召回，但能释放召回价值

召回阶段为了不漏，通常会多召回一些内容。

但多召回也会带来噪声。

这时候就需要 Rerank。

Rerank 的作用是：

把召回来的候选内容重新排一遍，把真正相关的内容排到前面。

Pinecone 文档中也提到，混合检索架构里可以在多个层级使用 rerank，包括对每个索引结果和合并结果做重排。

10.2 Rerank 常见做法

10.2.1 规则重排

根据标题匹配、关键词命中、时间、热度等规则加分。

比如：

标题命中关键词 +10
正文命中关键词 +5
最近更新 +3
用户点击率高 +2

10.2.2 模型重排

使用专门的 rerank 模型判断：

用户问题和文档片段到底有多相关？

模型重排比普通向量相似度更精细。

10.2.3 大模型重排

把候选内容交给大模型，让它判断哪些最相关。

适合小规模、高价值场景，但成本较高。

十一、方法八：优化索引字段

11.1 不要只索引正文

很多系统召回率低，是因为只索引了正文。

更好的方式是多字段索引：

标题
小标题
正文
摘要
标签
作者
分类
更新时间
来源
关键词
FAQ 问法

用户搜索时，不同字段权重不同。

通常：

标题权重 > 小标题权重 > 标签权重 > 正文权重

因为标题命中往往更能说明相关性。

11.2 给文档生成摘要字段

有些正文很长，直接检索效果不好。

可以先用大模型给文档生成摘要：

原文：几千字技术文档
摘要：本文主要介绍 RAG 系统中如何通过混合检索、Query 改写、向量召回、BM25、Rerank 提高召回率。

然后对摘要也建索引。

这样用户搜索时，更容易命中核心信息。

11.3 给文档生成关键词字段

可以给每篇文档提取关键词：

召回率
混合检索
BM25
向量检索
RAG
Rerank
Query 改写
Embedding

这些关键词可以单独建索引，提高召回概率。

十二、方法九：元数据过滤不要太死

12.1 过滤条件过严会降低召回率

很多系统会加过滤条件，比如：

只查某个部门
只查某个时间范围
只查某个分类
只查某个标签

这些过滤有必要，但如果太严格，会把正确结果过滤掉。

比如用户问：

“权限设计方案”

系统只在“后端开发”分类里查。

但真正答案可能在“架构设计”分类里。

结果就漏了。

12.2 推荐做软过滤

硬过滤是：

必须满足这个条件，否则不要

软过滤是：

满足这个条件可以加分，但不满足也可以参与排序

比如：

同部门文档 +5 分
最近一年文档 +3 分
标题命中 +10 分

这样既能保证相关性，又不至于召回过窄。

十三、方法十：建立用户行为反馈闭环

13.1 用户行为是最真实的优化数据

用户搜索后会有很多行为：

点击了哪个结果。
停留多久。
是否复制。
是否点赞。
是否继续追问。
是否换关键词重新搜索。
是否标记“没帮助”。

这些都是优化召回率的重要信号。

13.2 如何用行为数据提高召回率？

13.2.1 分析无结果搜索词

重点看：

用户搜了什么，但系统没有结果？

这些词通常说明：

同义词没覆盖。
文档没入库。
分词有问题。
业务词典缺失。
用户表达和文档表达不一致。

13.2.2 分析低点击搜索词

有结果但没人点，说明召回结果不准。

13.2.3 分析二次搜索词

用户第一次没搜到，换了一个词又搜。

比如：

第一次：知识库答不上来
第二次：RAG 召回率低

这说明这两个词应该建立关联。

十四、方法十一：离线评测召回率

14.1 没有评测，就不知道优化有没有用

很多团队优化召回率靠感觉。

今天调一下 TopK，明天换个模型，后天改个分词。

但到底有没有提升？不知道。

正确做法是建立测试集。

14.2 测试集怎么做？

准备一批问题和标准答案文档。

例如：

问题：怎么提高 RAG 召回率？
标准相关文档：
1. RAG 检索优化方案
2. 混合检索实践
3. Query 改写策略

然后每次检索，检查这些标准文档有没有被召回。

14.3 常见评估指标

不用复杂公式，理解这几个就够了：

14.3.1 Recall@K

意思是：

前 K 条结果里，有没有召回正确文档。

比如 Recall@10，就是看前 10 条里有没有相关文档。

14.3.2 Hit Rate

意思是：

只要命中一个正确答案，就算成功。

适合 RAG 问答。

14.3.3 MRR

意思是：

正确答案排得越靠前越好。

不只是看有没有召回，还看排第几。

十五、方法十二：针对长文档做特殊处理

15.1 长文档直接向量化效果通常不好

比如一篇 2 万字文档，如果直接整体向量化，会丢失很多细节。

用户问一个小问题时，整篇文章的向量不一定能准确匹配。

所以长文档必须切分。

15.2 长文档推荐处理方式

15.2.1 按目录结构切分

一级标题
二级标题
三级标题
正文段落

15.2.2 保留父级标题

例如：

文档标题：RAG 系统设计方案
一级标题：检索模块
二级标题：提高召回率的方法
正文：可以通过混合检索、Query 改写、多路召回等方式优化。

这样比只存正文更容易召回。

15.2.3 建立文档级索引和片段级索引

可以同时建两套索引：

文档级索引：判断哪篇文档相关
片段级索引：找到具体答案位置

先找文档，再找片段，效果通常更稳。

十六、方法十三：处理表格、代码、图片和 PDF

16.1 表格不能简单按普通文本处理

很多知识在表格里。

比如：

参数名 | 说明 | 默认值
TopK | 召回数量 | 10
Score Threshold | 相似度阈值 | 0.75

如果直接抽取文本，可能结构丢失。

建议：

表格转 Markdown。
表格每一行单独索引。
表头和单元格一起保存。
给表格生成摘要。
保留原始位置信息。

16.2 代码文档要保留代码块

比如用户搜索：

“Elasticsearch 混合检索 DSL 怎么写？”

如果代码块没有被索引，就召回不到。

代码类文档建议：

代码块单独切分。
代码说明和代码一起存。
函数名、类名、参数名单独索引。
支持代码 Embedding。

16.3 PDF 要注意解析质量

PDF 里常见问题：

页眉页脚干扰。
换行错乱。
表格错位。
图片文字无法提取。
标题层级丢失。

如果 PDF 解析质量差，后面检索再怎么调也没用。

十七、方法十四：召回阶段不要过早设置高阈值

17.1 相似度阈值太高会漏召回

很多向量检索系统会设置：

score > 0.8

低于这个分数就不要。

但问题是，有些正确内容分数可能只有 0.72。

如果阈值太高，直接被过滤掉。

17.2 推荐做法

召回阶段：

阈值低一点，TopK 大一点

排序阶段：

再通过 Rerank 和规则过滤

生成阶段：

只保留最相关内容

也就是：

前面宽一点，后面严一点。

十八、方法十五：领域数据微调

18.1 通用模型不一定懂你的业务

如果你的系统是金融、医疗、法律、政务、工业、代码、企业内部知识库，通用 Embedding 模型可能不够好。

因为业务里有大量专有词：

授信
风控
放款
核保
保全
工单流转
主数据
账务中心
资损
链路追踪

通用模型未必能准确理解。

18.2 可以做领域微调

用企业内部数据构造训练样本：

用户问题
相关文档
不相关文档

让模型学会：

什么样的问题应该匹配什么样的文档。

微调成本更高，但在垂直场景中效果明显。

十九、方法十六：利用 FAQ 问法增强召回

19.1 给每个知识点生成多个问法

很多知识库文档写得很正式，但用户问得很口语。

比如文档写：

“系统支持基于 RBAC 的权限控制。”

用户可能问：

权限怎么做？
怎么控制不同角色能看什么？
管理员和普通用户怎么区分？
菜单权限怎么实现？
接口权限怎么校验？

所以可以给每个知识点生成多个 FAQ 问法。

19.2 FAQ 增强示例

原文：

系统采用 RBAC 权限模型，通过用户、角色、权限三层结构实现访问控制。

生成问法：

把这些问法也加入索引，可以显著提高召回率。

二十、方法十七：冷热数据分层召回

20.1 新内容容易召回不到

很多系统会偏向老内容，因为老内容点击多、权重高。

但新内容也可能很重要。

比如技术文档刚更新，用户马上搜索，如果系统没有及时索引，就搜不到。

20.2 解决方法

建立实时索引。
新文档加新鲜度权重。
冷热数据分层召回。
对近期更新内容单独召回一路。
定期重建索引。

例如：

一路召回历史高质量文档
一路召回最近 30 天更新文档
一路召回用户所在部门文档

这样既保留经典内容，也不漏新内容。

二十一、方法十八：知识库治理

21.1 召回率低不一定是检索问题

有时候是知识库本身质量差。

常见问题：

文档标题不清晰。
内容重复。
文档过期。
文档缺少关键词。
文档没有分类。
文档没有摘要。
文档格式混乱。
同一问题多个版本答案冲突。

这些都会影响召回。

21.2 知识库治理建议

21.2.1 标题规范

不要写：

问题记录
方案
总结
测试

要写：

RAG 系统召回率优化方案
Elasticsearch 混合检索落地实践
企业知识库权限设计说明

21.2.2 标签规范

每篇文档至少有：

业务标签
技术标签
系统标签
场景标签

21.2.3 摘要规范

每篇文档生成 100 到 300 字摘要，说明它解决什么问题。

21.2.4 定期清理

删除或降权：

过期文档。
重复文档。
低质量文档。
无人访问文档。

二十二、方法十九：针对不同问题走不同召回策略

22.1 不同问题不能用同一套检索策略

比如：

22.1.1 精确查询

“订单表字段 order_status 是什么意思？”

适合关键词检索、字段检索。

22.1.2 语义查询

“为什么用户支付成功但订单没更新？”

适合向量检索、故障案例召回。

22.1.3 操作型查询

“怎么配置混合检索？”

适合文档召回、FAQ 召回。

22.1.4 对比型查询

“BM25 和向量检索有什么区别？”

适合多文档召回。

22.2 可以先做意图识别

用户问题进来后，先判断类型：

精确查找
故障排查
概念解释
操作步骤
代码问题
业务规则
历史记录

然后选择不同召回策略。

例如：

精确查找 => BM25 权重大
概念解释 => 向量检索权重大
故障排查 => 案例库召回 + 向量检索
操作步骤 => FAQ + 文档标题召回

这样比所有问题都用一套 TopK 更有效。

二十三、方法二十：线上灰度和 A/B 测试

23.1 召回优化不能只看离线指标

离线测试提升了，不代表线上用户一定满意。

所以要做 A/B 测试。

比如：

A 组：只用 BM25
B 组：BM25 + 向量检索
C 组：BM25 + 向量检索 + Rerank

观察：

点击率是否提升。
用户是否减少二次搜索。
问答满意度是否提升。
无结果率是否下降。
平均响应时间是否可接受。

23.2 线上指标重点看什么？

23.2.1 无结果率

用户搜了，但没有结果。

无结果率越低，召回越好。

23.2.2 点击率

召回结果有没有被用户点。

23.2.3 首条点击率

第一条结果是不是用户想要的。

23.2.4 二次搜索率

用户搜完又改关键词，说明第一次没满足。

23.2.5 RAG 答案满意度

用户是否点赞、继续追问、复制答案。

二十四、完整落地方案：如何设计一个高召回检索系统？

24.1 第一层：数据处理

文档清洗
标题提取
正文提取
表格处理
代码块处理
PDF 解析
去重
摘要生成
关键词生成
标签生成

24.2 第二层：索引建设

标题索引
正文索引
摘要索引
标签索引
关键词索引
向量索引
FAQ 问法索引
元数据索引

24.3 第三层：Query 处理

分词
纠错
同义词扩展
别名扩展
Query 改写
多 Query 生成
意图识别

24.4 第四层：多路召回

BM25 召回
向量召回
标题召回
标签召回
FAQ 召回
热门召回
最近更新召回
规则召回

24.5 第五层：融合去重

合并多路结果
去重
按来源加权
按字段加权
按时间加权
按业务规则加权

24.6 第六层：重排序

规则重排
Rerank 模型重排
大模型重排
业务权重调整

24.7 第七层：效果评估

Recall@K
Hit Rate
MRR
点击率
无结果率
二次搜索率
用户满意度

二十五、面试中怎么讲“提高召回率”？

如果面试官问：

你们项目里怎么提高召回率？

可以这样回答：

我们主要从数据、Query、召回策略和排序四个层面优化。
数据层面会做文档清洗、合理切分、标题增强、摘要和关键词生成；
Query 层面会做分词、纠错、同义词扩展、Query 改写和多 Query 生成；
召回层面采用 BM25 + 向量检索的混合检索，同时加入标题、标签、FAQ 等多路召回；
排序层面会先扩大 TopK，保证候选集覆盖，再通过 Rerank 模型和业务规则进行重排。
最后通过 Recall@K、Hit Rate、无结果率、点击率、用户反馈等指标持续评估。

这段回答非常适合写进简历或者面试表达。

二十六、总结

提高召回率，不是简单调一个参数，而是一整套系统工程。

核心可以总结成一句话：

让系统用更多角度理解用户问题，用更多通道寻找候选内容，再用更好的排序方法筛出真正相关结果。

真正有效的方法包括：

最后记住一句话：

召回阶段的目标不是一开始就找得最精准，而是尽量别漏；排序阶段的目标才是从一堆候选里挑出最好的。

所以优秀的检索系统，一定是：

召回要宽，排序要准，生成要稳。