点击知识块看内容，点击连线看依据。没有关系的块也保留。
大多数 RAG 效果差,不是管道搭错了,是正确的那一段根本没进候选集。它没进来的头号原因是:向量模型度量的是"像不像",不是"答没答"——这两件事在数学上就不是一回事,而且有可证明的上界。在一个刻意构造、语义上极其简单的检索任务 LIMIT 上,六个不同厂商不同规模的单向量模型 recall@100 全部落在 3.3%–18.9%,而一个 1994 年前后就定型的 BM25 拿到 85.7%。
如果你正在给自己的 agent 平台选检索方案,这篇文章想让你带走的不是一张组件清单,而是一个排查顺序:先量什么,量出来该动哪一层,以及在哪条线以下你根本不该建检索。
先认症状。下面这几条如果你熟悉,就说明你撞的是这堵墙,不是管道 bug:
foo",召回的是 foo 的定义和文档;共同点是:top-10 主题都对,但没有一条真正回答了问题。这不是"模型不够强",是三层叠起来的结构性原因,一层比一层硬。
第一层,训练目标错配。 多数 embedding 模型的对比学习目标是"语义接近",不是"能回答"。问题和答案在语义上往往并不接近——问句里根本不会出现答案里的关键实体。
第二层,池化抹平结构。 mean pooling 把否定、限定、方向性(谁调用谁)压成一个平均值。"A 调用 B"和"B 调用 A"的向量几乎重合。
第三层,维度决定容量,这一条是可证明的。 Weller 等(arXiv:2508.21038)证明:能被某个查询返回的 top-k 文档子集数量,受 embedding 维度限制。他们据此构造了 LIMIT 数据集——任务本身极简单——结果是一张让人不太舒服的表:
| 检索器 | recall@100 |
|---|---|
| BM25 | 85.7% |
| GTE-ModernColBERT(多向量) | 54.8% |
| Promptriever Llama3 8B | 18.9% |
| GritLM 7B | 12.9% |
| Gemini Embed | 10.0% |
| E5-Mistral 7B | 8.3% |
| Qwen3 Embed | 4.8% |
| Snowflake Arctic L | 3.3% |
同一篇论文里还有一个对照:把全部 46 篇文档一次性交给 Gemini 2.5-Pro 做全注意力判断,1000 条查询全部正确,一次前向搞定。论文给出的临界规模与维度拟合是 d=10 约 36 篇文档、d=20 约 120 篇、d=30 约 261 篇、d=45 约 626 篇——容量随维度增长,但增长曲线远慢于语料规模。
这张表最该被记住的读法不是"BM25 好厉害",而是:跨越六个厂商、从 4.8% 到 18.9%,换 embedding 模型这个动作不在解空间里。它是范式约束,不是选型问题。而"换个更好的 embedding"恰恰是绝大多数团队遇到检索差时的第一反应,也是回报最低的一个动作。
想确诊只要三步,都不难做:人工看 top-10 的相关率;加一层 cross-encoder 重排,只看正确块的位置变化(从第 37 位跳到第 2 位就确诊,说明双塔的独立编码丢掉了 query-doc 交互);再和 BM25 对拍,看 BM25 能捞到而向量捞不到的那批查询——基本都是精确标识符、否定词、数量限定这三类。
关键词检索不是历史包袱。BEIR(arXiv:2104.08663)在 18 个异构数据集上评了 10 个检索系统,零样本结论是 BM25 极其稳健,ANCE、TAS-B 这类 dense retriever 在部分数据集上强,在很多数据集上显著劣于 BM25。没有域内微调时,只上 dense 是在赌数据分布。
BM25 只有两个真正需要理解的旋钮,都在这条公式里:
score(d, t) = IDF(t) · [ (k1 + 1) · tf_td ] / [ k1 · ( (1 - b) + b · (L_d / L_ave) ) + tf_td ]IDF·(k1+1)。一篇文档里"检索"出现 20 次,并不比出现 5 次相关 4 倍。k1=0 退化成二值模型,k1→∞ 趋近线性加权。IR 教科书给的经验区间是 k1 取 1.2–2、b=0.75,并明确说"不做开发集调优也够用";Elasticsearch 的默认值正是 k1=1.2、b=0.75。也就是说,这条基线的冷启动成本接近零:建个倒排索引,不选模型、不跑全量 embedding、不占显存。
两个通道值得同时存在的全部理由是:它们的失败集合几乎不重叠。BM25 死在同义改写、跨语言、口语提问上,一个词都对不上就是 0 分,也理解不了词序和指代;dense 死在精确标识符和维度上界上。反方向的证据同样硬——Anthropic 的实验里,把语境前缀只加到向量索引,top-20 失败率从 5.7% 降到 3.7%(相对 -35%),这 35% 是纯向量通道贡献的,只有 BM25 同样拿不到。
融合要用 RRF(混合检索的标准做法),不要归一化分数后加权:
RRFscore(d) = Σ_i 1 / (k + rank_i(d)) k 默认 60理由很具体:BM25 分数是无上界的对数-TF 累加(典型 5–30,随查询词数漂移),余弦相似度落在 [-1,1],两者既不同尺度也不同分布;做 min-max 归一化,会让"本批候选恰好全都很差"的查询被拉伸出假信心。RRF 只用名次,零模型调用、零额外延迟,绕开了这个问题。
k=60 是 Cormack 等 2009 年原论文的取值,已成事实标准,但它不是不能动的常数:rank 1 贡献 1/61≈0.0164,rank 100 贡献 1/160≈0.00625,只差 2.6 倍——k 越大越"民主",两个通道都排中游的文档能压过只被一个通道排第一的文档。精确 ID 查询该调小 k,模糊概念查询该调大。还有一个常被忽略的陷阱:两路 top-k 取太小时 RRF 无从发挥,如果 BM25 只召回 10 条,它对最终榜单的影响就被截断在前 10 名之内。
一条选型顺序建议:先量 BM25 的 recall@50,再决定要不要向量。 很多团队跳过这一步直接上向量库,然后花几个月调 embedding 模型,去追一个十行代码就能到的水位。
在讨论怎么把检索做好之前,先确认你是否真的需要它。Anthropic 在 contextual retrieval 那篇里给了一条很硬的负向边界:知识库小于 20 万 token(约 500 页)时不要建检索,直接把整库塞进 prompt。这条常被引用者跳过,但它决定了后面所有工程是不是纯属自找麻烦。
拐点比大多数人想象的低,而中间地带同样有结论。Li 等(EMNLP 2024 Industry Track)在 LongBench 的 7 个 + ∞Bench 的 2 个数据集上,用 300 词/块、top-k=5 的配置做了完整对照:
| RAG 均分 | 长上下文直塞均分 | |
|---|---|---|
| Gemini-1.5-Pro | 37.33 | 49.70 |
| GPT-4o | 32.60 | 48.67 |
看起来长上下文完胜,差距 12 分左右。但同一篇论文里还有一个几乎所有引用都会漏掉的数字:63% 的查询上两者预测完全相同,70% 的查询上分差小于 10 分。也就是说,大多数时候你为长上下文多付的钱买不到任何东西——差距集中在少数难查询上。
由此产生的第三条路是 Self-Route:先让 RAG 跑,同时允许模型自我反思"给的材料够不够答",答不了才回退到长上下文。实测代价:
GPT-4o 那一行是这套方法真正的说服力所在:更便宜且不更差。
两条线合起来是四个规模档位,对应四种范式,不存在一套通吃的架构:
顺带提醒一句:长上下文并不豁免检索质量问题。Liu 等的 lost in the middle 数据里,正确文档放在中段时 GPT-3.5-Turbo 准确率 53.8%,低于什么都不给的 closed-book 基线 56.1%,而更大的窗口不解决这一点。"塞进去"不等于"被读到"。
Anthropic 的 contextual retrieval 实验是目前公开材料里唯一一组同一语料、同一指标、逐级叠加的阶梯,值得逐行读:
| 配置 | top-20 检索失败率 | 相对下降 |
|---|---|---|
| 基线(embedding + BM25) | 5.7% | — |
| + 上下文检索(仅向量索引) | 3.7% | 35% |
| + 同样文本喂给 BM25 | 2.9% | 49% |
| + 重排 | 1.9% | 67% |
上下文检索(contextual retrieval)做的事本身很朴素:索引前用一个廉价 LLM(Anthropic 用 Claude 3 Haiku)为每个 chunk 生成 50–100 token 的"这段在整篇文档里是什么位置、指代谁"的前缀,拼进 chunk 再索引。它修的不是检索算法,是被索引的文本本身。教科书例子是一个块写着"该公司营收较上季度增长了 3%",索引里既没有公司名也没有季度——查询 "ACME Corp 2023 Q2 revenue growth" 与它的词法重合度接近零,语义重合度也很低,这个块在索引里等于不存在。这类切块语境丢失,rerank 是救不了的,因为它压根没进候选。
三个数字必须分开记,合起来读会得出错误结论:
再看绝对增益:2.0 → 0.8 → 1.0 个百分点,递减。而 LIMIT 那张表说明,"换 embedding 模型"这一维度上六个模型全在 3.3%–18.9% 区间。把这两组数并排,就得到本文标题想说的那件事:最贵、最常被首先尝试的动作(换模型),回报最低;最土、最少人做的动作(改被索引的文本),回报最高。
成本上,靠 prompt caching 把整篇文档缓存复用,Anthropic 给的口径是 $1.02 / 百万文档 token 的一次性索引成本(800-token chunk、8k-token 文档、50-token 指令),索引期一次付清,查询期零额外延迟。
同一条"语境鸿沟",还有一个查询期的对偶填法:HyDE——让 LLM 先写一篇"如果答案存在,大概长这样"的假文档,只对假文档编码去检索,把 query-doc 的跨分布问题换成 doc-doc 的同分布问题。原论文(arXiv:2212.10496)同一个 Contriever 编码器下,TREC-COVID 的 nDCG@10 从 27.3 升到 59.3,TREC DL19 从 44.5 到 61.3;但 FiQA 只从 24.5 到 27.3。规律是查询与语料的术语鸿沟越大,HyDE 收益越高;查询本身就用语料词汇写成时,收益接近噪声。它还有两条硬边界:每次查询都要付 N 次生成的延迟;查询是精确标识符(错误码、SKU、函数名)时假文档会把精确 token 稀释进散文里,反而不如直接走 BM25。
索引期改写和查询期改写的选择判据不是"哪个效果好",是语料变动频率与查询频率之比。 语料稳定、查询频繁 → 索引期,一次付清;语料每天大改 → 索引期改写要重新调 LLM 重灌,增量维护成本比朴素切块高一个量级,该走查询期。
late chunking 把"先切块再编码"倒过来:先让长上下文 embedding 模型对整篇文档跑一次 transformer,拿到全篇条件化的 token 表示,再按 chunk 边界分段 mean pooling。切块位置一点没变,变的只是 pooling 发生在注意力之后而不是之前——所以第 7 块里"该公司"这个 token 的隐状态已经吸收了第 1 块的公司名。它零额外 LLM 调用,这是相对上下文检索最大的成本优势。
但它的收益极不均匀。Jina 在 BeIR 上用同一个 jina-embeddings-v2-base-en 的 nDCG@10 对照:
| 数据集 | 朴素切块 | late chunking | 不切块 |
|---|---|---|---|
| SciFact | 64.20% | 66.10% | 63.89% |
| NFCorpus | 23.46% | 29.98% | 30.40% |
| FiQA2018 | 33.25% | 33.84% | 33.43% |
| TRECCOVID | 63.36% | 64.70% | 65.18% |
| Quora | 87.19% | 87.19% | 87.19% |
三条能直接指导决策的读法:
它和上下文检索常被并列成同类替代品,真正的分工是:late chunking 便宜但只惠及向量通道(没有新文本产生,BM25 索引里什么都没变);上下文检索贵,但产出真实自然语言,能同时修好 BM25。语料以自然语言长文为主、预算紧,选前者;语料里有大量专名/编号、能承担索引期成本,选后者。两者可以叠加,不互斥。两条工程约束:必须用长上下文 embedding 模型(jina-embeddings-v2-base-en 支持 8192 token),以及它增加的是索引期显存而非查询期延迟,批量重建索引时容易 OOM。
顺带把切块策略这件事收个尾:它不是超参数调优,是一次不可兼得的三方分配——小块提升定位精度和向量表达纯度,大块保留语境和推理链,而块越大,一个具体事实在 mean pooling 出的合成向量里权重越低;同时 top-k 固定时块越大,进模型的 token 越多,越早撞上 lost in the middle。Bhat 等(arXiv:2505.21700)横扫多数据集多模型的结论是不存在通用最优 chunk size:64–128 token 在"答案是短事实"的数据集上最优,512–1024 token 在需要广域语境的数据集上最优;而且对模型敏感——Stella 受益于大块,Snowflake 在小块上更好。换 embedding 模型就要重扫一遍。
真正被低估的一招是父子块:小块进索引负责命中,命中后返回父块给 LLM。它把"检索粒度"和"生成粒度"解耦,直接绕开了整个三方分配。对 markdown、代码、法规这类强结构文本,还有一招更便宜:递归按标题/段落/函数边界切,并把"文档标题 > 章 > 节"路径拼进每块——连 LLM 调用都不用。
cross-encoder 重排(rerank)是把 (query, candidate) 拼成一条序列送进 transformer 做全注意力打分。它和双塔的差别不是精度调优,是架构性的:双塔无法让 query token 看到 document token,cross-encoder 可以——这让它能判断"这段话是否回答了问题",而不只是"是否谈论同一话题",正是第一节那道坎唯一在结构上能表达的层。代价是它不产生可索引的向量,因此永远只能当第二级。
延迟的量级要有直观感受。sentence-transformers 官方给的对照:对 10,000 条句子做聚类,cross-encoder 需要算约 5000 万对,约 65 小时;bi-encoder 只需为每条句子算一次 embedding,约 5 秒。四个数量级的差距,解释了为什么它只能用在几十到几百条候选上。
计费形态同样值得摆到桌面:Cohere 把"一个 query + 最多 100 篇文档"定义为一个 search unit。也就是说候选数从 100 涨到 200,你付两倍钱——召回深度是钱和延迟的直接乘数,不是免费旋钮。
由此得到本节最实用的一条:真正影响成败的是召回深度,不是 reranker 型号。rerank 只能重排它拿到的候选,第 200 名的正确答案,给多强的 reranker 也救不回来。深度不够时先修召回,不要先换 reranker;先量 recall@150,再谈重排。
两个容易混的邻居:
这一节是全文的落地部分。检索质量的故障有三段,处置手段完全不同,混着治必然无效:
评估三元组正是用来把这三段拆开的:context relevance 量 query→context 这条边,groundedness / faithfulness 量 context→response,answer relevance 量 query→response。
| 指标 | 度量的边 | 低分意味着 | 该动哪里 |
|---|---|---|---|
| context relevance | query → context | 召回/排序坏了 | 切块、混合检索、重排 |
| groundedness | context → response | 模型在编 | prompt 约束、引用强制、换模型 |
| answer relevance | query → response | 答非所问 | 指令、问题改写、拒答策略 |
关键是读组合而不是读单值:context 低 + groundedness 高 = 模型忠实地复述了错误材料,这是最危险的一种,输出看起来有据可依,错的是根;context 高 + groundedness 低 = 材料对了但模型跑偏,典型就是中段证据被忽略;三项都高但 answer relevance 低 = 答了一个相关但不同的问题,通常是查询歧义或指令冲突。
落地口径可以直接抄 RAGAS 的可执行定义:faithfulness = 回答中被检索上下文支持的 claim 数 / claim 总数,执行分两步(拆句 + 逐句判断能否从 context 推出);context precision 对每个 rank k 算 Precision@k 再对相关块取均值,它是排序敏感的——同一批块,正确的排前面分高;context recall 和它互补,precision 问"排得好不好",recall 问"该有的都捞到了没有",两者不能只报一个。从零起步最实用的一条是 LLMContextPrecisionWithoutReference:没有标准答案时,用生成结果反过来判断块相关性,不需要先攒标注集。
排查顺序,按这个来:
几条量测本身的陷阱,踩了会让你优化出一个"分高但更差"的系统:
一条纪律收尾:没有这三个数,任何"我们上了 rerank,感觉好多了"都不可采信。先建评测,再调参。
本文的整条论证链有一个前提:检索是一次性的、由固定管线在模型看到问题之前完成的。下面这些场景里,这个前提本身就不成立。
语料有天然导航结构、任务是多跳研究时,该走 agentic 检索。 让模型在推理循环里自己决定查什么、查几轮、什么时候停,用 glob/grep/read 逐步逼近,而不是预取 top-k。Anthropic 在 BrowseComp 上的回归显示三个因素解释了 95% 的性能方差,其中仅 token 用量一项就解释 80%——这直接说明它的收益机制是"允许消耗更多 token 去搜",不是某个巧妙算法。代价同样明确:多智能体系统的 token 用量约为普通对话的 15×;收益是他们的多智能体研究系统在内部评测上比单个 Claude Opus 4 高 90.2%。这条线摆在那里:只在"任务价值 > 15 倍 token 成本"时成立。
但它有反面边界:grep 在代码库上好用,是因为代码有路径、有命名约定、有精确标识符;换成一千万篇没有目录结构的新闻,agent 无从下手,还是要 ANN 索引兜底。而且每一轮工具返回的原始结果都进上下文,轮数一多必然撞上位置退化,必须配套上下文隔离或压缩。顺带说一句,Anthropic 自己的表述是"用 just-in-time 策略增强既有检索系统",把它读成"RAG 已死"是误读。
其余几条边界:
最后一个诚实的开放问题:三元组的 judge 漂移目前没有被广泛接受的锚定方案,这让"我的检索质量是不是在提升"这个最基本的问题,长期无法跨期比较。你能做的只有锁版本、留原始样本、每次改动重跑基线。
如果只带走一句话:检索质量的排查顺序是"先量规模,再量 BM25,再量召回,再量排序,最后量位置",而增益顺序是"改文本 > 加通道 > 改排序 > 改模型"。 两条顺序都和大多数团队的实际做法正好相反——他们从换 embedding 模型开始,而那是回报最低的一格。