RAG 检索召回率怎么提升

为什么把整份文档塞给大模型行不通

直接把整份资料丢给大模型回答问题，会遇到三个工程上的硬约束：一是上下文窗口有限，几十页的合同或一整本教材根本放不进去；二是塞进去的无关内容越多，模型越容易被干扰、答非所问，准确率反而下降；三是用户的提问往往很口语、很模糊，和原文里的措辞对不上，直接拿原话去匹配经常漏掉真正相关的段落。RAG（检索增强生成）就是为了解决这一类问题：先检索出少量真正相关的片段，再让模型基于这些片段作答。

这个技能把 RAG 流程做成了什么

它把"建库"和"检索"两个阶段串成一条完整流程。建库阶段，它解析图片、PDF、Word、Markdown、TXT、PPT 等多种格式（图片走 OCR 后入库），把内容切分并写入 sqlite-vec 向量数据库；这里用的是 smart 模式，会跳过已索引过的重复文件、只追加新文档，或在需要时定向重建索引，避免每次都从头跑一遍。检索阶段，它不会拿用户原话直接去查，而是先把口语化、模糊的问题改写成精准的查询词和子查询，再并行执行向量检索、BM25 关键词检索、LLM 分词，用 RRF 把多路结果融合，最后做一次 LLM 重排序，返回排在最前的相关片段。

这套混合检索加重排序的设计，目的是同时兼顾"语义相近"和"关键词命中"两种召回，比单一向量检索更不容易漏；问题改写则解决了"用户说得太口语、和原文对不上"的老问题。

怎么用它

用法是用自然语言把"要建库的资料"或"要回答的问题"交给它，建库与检索的细节由它按流程处理，无需手动跑脚本或调参数。例如可以这样对它说：

它适合这些场景：用户上传教材、合同、论文或资料包，需要先建立统一的本地知识索引库；围绕已索引资料做问答，且要求答案只引用检索片段而非整份原文；新增或更新文件后，要避免重复索引、保留已有数据库内容；提问较模糊，需要先改写成结构化查询词以提升召回质量。适合做本地资料问答、课程辅助、文档研究和企业知识库检索，尤其是多格式文档混在一起的场景。

大家常问

RAG 检索里说的「混合检索」是什么意思？

混合检索不是某种单一算法，而是把两路检索的结果融合起来：一路用 BM25 等稀疏检索做关键词字面匹配，一路用向量做稠密语义匹配，再用 RRF 等方式按排名融合去重。目的是同时兼顾"精确命中"和"语义相近"，比只用一路更不容易漏掉相关片段。

向量检索和关键词检索（BM25）有什么区别？

BM25 是稀疏检索，靠词频与倒排索引做字面匹配，词对不上就漏，但对专有名词、型号、代码很精确且可解释。向量检索是稠密检索，把文本编码成向量比语义相似度，能识别同义改写，但对罕见实体和精确匹配偏弱。一个管字面命中，一个管语义关联，互补大于竞争。

为什么混合检索之后还要再做一次重排序（rerank）？

混合检索为了保召回会"广撒网"，两路打分都是轻量近似——BM25 只看词频、向量是有损压缩，正确答案大概率在候选里却不一定排最前，还混着噪声。重排序用交叉编码器让查询和每个候选做细粒度交互精排，把真正相关的提到前面。它只在几十到几百条候选上跑，负责"收网"。

检索评测里的召回率和精确率有什么区别？

召回率回答"该找的有没有漏"，是命中的相关文档数除以全部相关文档数；精确率回答"找回来的有没有用"，是命中的相关文档数除以返回的总条数。两者通常矛盾：多返回结果召回率升、精确率降。工程上常用大候选集保召回，再靠重排序和元数据过滤把精确率提上去。