知识块 · 版本 1块链接查看来源查看知识状态待读取
01

正文

大多数 RAG 效果差,不是管道搭错了,是正确的那一段根本没进候选集。它没进来的头号原因是:向量模型度量的是"像不像",不是"答没答"——这两件事在数学上就不是一回事,而且有可证明的上界。在一个刻意构造、语义上极其简单的检索任务 LIMIT 上,六个不同厂商不同规模的单向量模型 recall@100 全部落在 3.3%–18.9%,而一个 1994 年前后就定型的 BM25 拿到 85.7%。

如果你正在给自己的 agent 平台选检索方案,这篇文章想让你带走的不是一张组件清单,而是一个排查顺序:先量什么,量出来该动哪一层,以及在哪条线以下你根本不该建检索。

知识块 · 版本 1块链接查看来源查看知识状态待读取
02

一、向量模型分不清"像"和"答了"

先认症状。下面这几条如果你熟悉,就说明你撞的是这堵墙,不是管道 bug:

  • 问"A 和 B 有什么区别",召回一堆同时提到 A 和 B 的段落,全在讲它们的相似之处;
  • 问"退货超过 30 天怎么办",召回的全是标准退货流程;
  • 问"哪个函数调用了 foo",召回的是 foo 的定义和文档;
  • 问"不需要审批的情况有哪些",召回的全是需要审批的条款——否定词在向量里几乎没有权重。

共同点是:top-10 主题都对,但没有一条真正回答了问题。这不是"模型不够强",是三层叠起来的结构性原因,一层比一层硬。

第一层,训练目标错配。 多数 embedding 模型的对比学习目标是"语义接近",不是"能回答"。问题和答案在语义上往往并不接近——问句里根本不会出现答案里的关键实体。

第二层,池化抹平结构。 mean pooling 把否定、限定、方向性(谁调用谁)压成一个平均值。"A 调用 B"和"B 调用 A"的向量几乎重合。

第三层,维度决定容量,这一条是可证明的。 Weller 等(arXiv:2508.21038)证明:能被某个查询返回的 top-k 文档子集数量,受 embedding 维度限制。他们据此构造了 LIMIT 数据集——任务本身极简单——结果是一张让人不太舒服的表:

检索器recall@100
BM2585.7%
GTE-ModernColBERT(多向量)54.8%
Promptriever Llama3 8B18.9%
GritLM 7B12.9%
Gemini Embed10.0%
E5-Mistral 7B8.3%
Qwen3 Embed4.8%
Snowflake Arctic L3.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 能捞到而向量捞不到的那批查询——基本都是精确标识符、否定词、数量限定这三类。

知识块 · 版本 1块链接查看来源查看知识状态待读取
03

二、先把 BM25 的 recall 量到底,再谈要不要上向量

关键词检索不是历史包袱。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 ]
  • k1 管词频饱和。tf 同时出现在分子和分母,使分数随词频增长但收敛到上界 IDF·(k1+1)。一篇文档里"检索"出现 20 次,并不比出现 5 次相关 4 倍。k1=0 退化成二值模型,k1→∞ 趋近线性加权。
  • b 管长度归一化。b=1 完全按长度归一,长文档被强力压制;b=0 完全不归一,长文档因为词多而系统性占优。

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 模型,去追一个十行代码就能到的水位。

知识块 · 版本 1块链接查看来源查看知识状态待读取
04

三、20 万 token 以下不该建检索,装得下的中间地带不该一刀切

在讨论怎么把检索做好之前,先确认你是否真的需要它。Anthropic 在 contextual retrieval 那篇里给了一条很硬的负向边界:知识库小于 20 万 token(约 500 页)时不要建检索,直接把整库塞进 prompt。这条常被引用者跳过,但它决定了后面所有工程是不是纯属自找麻烦。

拐点比大多数人想象的低,而中间地带同样有结论。Li 等(EMNLP 2024 Industry Track)在 LongBench 的 7 个 + ∞Bench 的 2 个数据集上,用 300 词/块、top-k=5 的配置做了完整对照:

RAG 均分长上下文直塞均分
Gemini-1.5-Pro37.3349.70
GPT-4o32.6048.67

看起来长上下文完胜,差距 12 分左右。但同一篇论文里还有一个几乎所有引用都会漏掉的数字:63% 的查询上两者预测完全相同,70% 的查询上分差小于 10 分。也就是说,大多数时候你为长上下文多付的钱买不到任何东西——差距集中在少数难查询上。

由此产生的第三条路是 Self-Route:先让 RAG 跑,同时允许模型自我反思"给的材料够不够答",答不了才回退到长上下文。实测代价:

  • Gemini-1.5-Pro:只用长上下文 38.39% 的 token,成本降 65%,均分 46.41 vs 49.70;
  • GPT-4o:用 61.40% 的 token,成本降 39%,均分 48.89,反而略高于直塞的 48.67;
  • GPT-3.5-Turbo:用 38.85% 的 token,均分 35.32,高于直塞的 32.07。

GPT-4o 那一行是这套方法真正的说服力所在:更便宜且不更差。

两条线合起来是四个规模档位,对应四种范式,不存在一套通吃的架构:

  1. 语料 < 20 万 token → 直塞,连索引都不要建;
  2. 装得下窗口但很贵 → Self-Route 式路由,别一刀切;
  3. 语料远超窗口 → 必须 RAG,没得选;
  4. 问题本身是全局 sensemaking(答案不在任何单块里)→ 检索结构上就做不到,得在索引期把答案物化出来。

顺带提醒一句:长上下文并不豁免检索质量问题。Liu 等的 lost in the middle 数据里,正确文档放在中段时 GPT-3.5-Turbo 准确率 53.8%,低于什么都不给的 closed-book 基线 56.1%,而更大的窗口不解决这一点。"塞进去"不等于"被读到"。

知识块 · 版本 1块链接查看来源查看知识状态待读取
05

四、增益顺序和直觉正好相反:改文本 > 加通道 > 改排序 > 改模型

Anthropic 的 contextual retrieval 实验是目前公开材料里唯一一组同一语料、同一指标、逐级叠加的阶梯,值得逐行读:

配置top-20 检索失败率相对下降
基线(embedding + BM25)5.7%—
+ 上下文检索(仅向量索引)3.7%35%
+ 同样文本喂给 BM252.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 是救不了的,因为它压根没进候选。

三个数字必须分开记,合起来读会得出错误结论:

  • 单靠改写向量索引只有 35%;
  • 把改写后的文本同时喂给 BM25 才凑到 49%——增量的一大半来自词法通道拿到了新出现的专名。这也是为什么混合检索不是可选项;
  • 最后 18 个百分点来自重排,是查询期算力换来的,不能和索引期的收益混算。

再看绝对增益: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 重灌,增量维护成本比朴素切块高一个量级,该走查询期。

知识块 · 版本 1块链接查看来源查看知识状态待读取
06

五、late chunking 值不值得做,基本只由文档长度决定

late chunking 把"先切块再编码"倒过来:先让长上下文 embedding 模型对整篇文档跑一次 transformer,拿到全篇条件化的 token 表示,再按 chunk 边界分段 mean pooling。切块位置一点没变,变的只是 pooling 发生在注意力之后而不是之前——所以第 7 块里"该公司"这个 token 的隐状态已经吸收了第 1 块的公司名。它零额外 LLM 调用,这是相对上下文检索最大的成本优势。

但它的收益极不均匀。Jina 在 BeIR 上用同一个 jina-embeddings-v2-base-en 的 nDCG@10 对照:

数据集朴素切块late chunking不切块
SciFact64.20%66.10%63.89%
NFCorpus23.46%29.98%30.40%
FiQA201833.25%33.84%33.43%
TRECCOVID63.36%64.70%65.18%
Quora87.19%87.19%87.19%

三条能直接指导决策的读法:

  1. NFCorpus 上 +6.5 个百分点是全表最大增益,而 NFCorpus 是长医学文档;Quora 三列完全相同,因为 Quora 的"文档"就是一句话,压根没有跨块语境可补。收益随文档长度增长,短文档语料上这个技术的期望收益是零。
  2. 它在 SciFact、FiQA 上超过了"不切块",说明它不是简单退化成整篇编码——切块本身仍有定位价值,late chunking 是把两者的优点都拿到。
  3. 在 TRECCOVID、NFCorpus 上"不切块"仍略优,说明对某些语料,切块本身就是净损失,该先问"要不要切"。

它和上下文检索常被并列成同类替代品,真正的分工是: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 调用都不用。

知识块 · 版本 1块链接查看来源查看知识状态待读取
07

六、重排是最后一级,它的天花板是召回集

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,再谈重排。

两个容易混的邻居:

  • RRF ≠ rerank。RRF 是零模型的名次代数,零额外延迟;rerank 是逐对模型推理,延迟以百毫秒计。RRF 是廉价粗排合并,没有任何语义判断能力,替代不了 rerank。
  • cross-encoder ≠ LLM-as-judge 排序。把 100 条候选一并塞进大模型让它排序,会把 lost in the middle 原样带进排序阶段(排在中间的候选被系统性低估);cross-encoder 是逐对打分,结构上不存在位置偏置。你以为在治病,其实在传染。
知识块 · 版本 1块链接查看来源查看知识状态待读取
08

七、三段故障要用三个数分别定位:先量哪个,按什么顺序排

这一节是全文的落地部分。检索质量的故障有三段,处置手段完全不同,混着治必然无效:

  1. 没召回——正确块压根没进候选集。成因是切块语境丢失、通道缺失、召回深度不够。rerank 对此完全无效。
  2. 召回了没排上——在候选里但排在 150 名开外。这是排序层问题,是重排和 RRF 的战场。
  3. 排上了没被读——进了上下文却被忽略。lost in the middle:正确文档在中段时 53.8%,低于什么都不给的 56.1%。recall 达标的系统仍可能净贡献为负。

评估三元组正是用来把这三段拆开的:context relevance 量 query→context 这条边,groundedness / faithfulness 量 context→response,answer relevance 量 query→response。

指标度量的边低分意味着该动哪里
context relevancequery → context召回/排序坏了切块、混合检索、重排
groundednesscontext → response模型在编prompt 约束、引用强制、换模型
answer relevancequery → response答非所问指令、问题改写、拒答策略

关键是读组合而不是读单值:context 低 + groundedness 高 = 模型忠实地复述了错误材料,这是最危险的一种,输出看起来有据可依,错的是根;context 高 + groundedness 低 = 材料对了但模型跑偏,典型就是中段证据被忽略;三项都高但 answer relevance 低 = 答了一个相关但不同的问题,通常是查询歧义或指令冲突。

落地口径可以直接抄 RAGAS 的可执行定义:faithfulness = 回答中被检索上下文支持的 claim 数 / claim 总数,执行分两步(拆句 + 逐句判断能否从 context 推出);context precision 对每个 rank k 算 Precision@k 再对相关块取均值,它是排序敏感的——同一批块,正确的排前面分高;context recall 和它互补,precision 问"排得好不好",recall 问"该有的都捞到了没有",两者不能只报一个。从零起步最实用的一条是 LLMContextPrecisionWithoutReference:没有标准答案时,用生成结果反过来判断块相关性,不需要先攒标注集。

排查顺序,按这个来:

  1. 先量语料规模。 < 20 万 token,停,别建检索。
  2. 量 BM25 单通道的 recall@50 作为基线。 零成本,而且它是你判断"向量到底带来了什么"的唯一参照。
  3. 量最终召回集的 recall@k(k 用你实际的召回深度)。 低 → 问题在第一段。随机抽 20 个 chunk 单独读,数有多少个含无法解析的指代("它/该公司/上述/如前所述"),超过三成基本确诊切块语境丢失,走第四节的索引期改写;若不是,查通道缺失(用文档级实体名查不到、用块内关键词能查到,就是缺语境;精确标识符查不到就是缺 BM25)。
  4. recall 达标但 context precision 低 → 问题在第二段。加 cross-encoder 看正确块位置变化,跳得越多越确诊。
  5. context relevance 高而 groundedness 低 → 问题在第三段。做位置扫描:固定问题和材料,只把正确文档从头移到尾重跑,画准确率对位置的曲线,U 形就是确诊。处置是压 k 不是加 k、rerank 后把最高分的几条折叠到首尾。
  6. 三项都高但 answer relevance 低 → 不是检索问题,回到指令和查询改写。

几条量测本身的陷阱,踩了会让你优化出一个"分高但更差"的系统:

  • context relevance 与 chunk 大小强耦合。 把 chunk 切大,相关内容更容易落进块里,分数虚高而实际信噪比更差。改切块策略时必须同时看 groundedness 和最终 token 数。
  • 别把向量索引的 recall 当检索质量。 用 recall@k 对暴力检索结果做评测,量的是"ANN 逼近精确检索的程度",不是"检索到正确答案的程度"。前者 0.99 的索引在后者上可能一塌糊涂,两个指标必须分开报。
  • HNSW 的旋钮要认清职责。 线上召回不够,先调 ef——它是唯一能在索引建好之后改的运行时召回-延迟拨盘(硬约束 ef > k,实践中要大好几倍);调 ef 上不去,说明是 M 或 ef_construction 太小,那必须重建索引,靠 ef 无解。反过来,P99 变差时去调 M 是无效动作,因为 M 是建图期参数。hnswlib 给的合理范围是 M 2–100、多数场景 12–48,图开销约 M×8–10 字节/元素且常驻内存——这条决定了你的规模天花板。
  • judge 要锁版本。 三元组三项都是 LLM-as-judge,judge 自身有偏且随模型版本漂移,基线必须用同一 judge 版本重跑,否则跨期数字不可比。
  • groundedness ≠ 正确性。 TruLens 对三元组的结论有一句常被砍掉的限定语:三项达标时系统 "hallucination free up to the limit of its knowledge base"——它保证不了知识库本身是对的。回答忠实于一份过期文档,groundedness 满分,事实全错。

一条纪律收尾:没有这三个数,任何"我们上了 rerank,感觉好多了"都不可采信。先建评测,再调参。

知识块 · 版本 1块链接查看来源查看知识状态待读取
09

八、什么时候本文的建议不成立

本文的整条论证链有一个前提:检索是一次性的、由固定管线在模型看到问题之前完成的。下面这些场景里,这个前提本身就不成立。

语料有天然导航结构、任务是多跳研究时,该走 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 已死"是误读。

其余几条边界:

  • 高 QPS、低延迟的线上问答:agentic 检索的墙钟时间是秒到分钟级,HyDE 是百毫秒到秒级,cross-encoder 一次调用百毫秒级——预算在几十毫秒的场景(交互式补全)这三样都用不了。
  • 纯跨语言检索:BM25 通道几乎不贡献,除非先做查询翻译,这时混合检索的性价比大幅下降。
  • 文档天然很短(FAQ、商品描述、单条日志、Quora 式问答):切块策略、late chunking 全部无效,Quora 那三个 87.19% 就是证据。
  • chunk 本身已经自足(API reference、结构化日志、独立 FAQ 条目):没有跨块指代,上下文检索的改写只是在烧钱。
  • 查询与文档同源、用户会用精确术语(内部代码检索、日志检索):纯 BM25 往往已经够,加 dense 只是加运维成本。
  • 有充足域内标注数据时:先微调编码器。HyDE 与有监督基线在 DL20 的 MAP/nDCG@10 上仍差约 10%,它是替代品不是叠加品。

最后一个诚实的开放问题:三元组的 judge 漂移目前没有被广泛接受的锚定方案,这让"我的检索质量是不是在提升"这个最基本的问题,长期无法跨期比较。你能做的只有锁版本、留原始样本、每次改动重跑基线。

如果只带走一句话:检索质量的排查顺序是"先量规模,再量 BM25,再量召回,再量排序,最后量位置",而增益顺序是"改文本 > 加通道 > 改排序 > 改模型"。 两条顺序都和大多数团队的实际做法正好相反——他们从换 embedding 模型开始,而那是回报最低的一格。

知识块 · 版本 1块链接查看来源查看知识状态待读取
10

出处

来源与依据