Retrieval on Khari Z's LogBook

从 Prompt 到可审计系统：结构化 LLM 决策的工程笔记

Fri, 24 Jul 2026 00:00:00 +0000

最近一个月，我一直在整理一类结构化 LLM 决策系统。它接收自然语言和结构化字段，在有限标签中做选择；证据不足时，系统要能转人工或者明确放弃自动判断。

这篇只保留能公开讨论的方法，不涉及具体行业、业务字段、数据规模和实测数字。真正让我花时间的也不是某一句 Prompt，而是几个更基础的问题：候选从哪里来，怎样限制模型输出，第二次调用为什么可能和第一次不同，服务变快以后质量会不会发生变化。

一、先把“生成答案”改成“受限决策”

开放式生成很灵活，直接放进业务流程却容易出问题：模型可能编出不存在的标签，也可能忽略方向、阶段之类的约束。即使返回了合法 JSON，字段值仍然可能选错。

我更习惯把流程拆成下面这样：

1
2
3
4
5
6
7


原始输入
 -> 清洗和确定性规则
 -> 检索候选
 -> LLM 提取受控事实
 -> 在候选 ID 中选择
 -> 程序检查 + 必要时语义复核
 -> 自动通过 / 人工复核 / 放弃自动判断

这类结构可以用在文档分类、工单路由、内容审核或其他高风险分类任务中。模型只负责一个边界清楚的局部判断：

1

decision = model(facts, candidates, policy)

facts 是当前样本中可验证的事实，candidates 是允许选择的集合，policy 描述决策边界。三者最好分开组织。全塞进一段自然语言里，后面很难知道模型到底忽略了哪一部分。

JSON 合法，只解决了第一层问题

结构化输出有两种常见做法。一种是在 Prompt 里要求返回 JSON，解析失败后重试；另一种是在解码阶段按照 JSON Schema 屏蔽非法 token，也就是 constrained decoding。

OpenAI 对 Structured Outputs 的说明提到，约束解码可以保证输出符合 schema，却不能保证对象里的值正确。一个答案可以格式完美，同时语义完全错误。

所以校验至少要分成两层：

1
2


结构校验：字段是否齐全、类型是否正确、枚举是否合法
领域校验：候选是否存在、事实是否冲突、决策是否越过业务边界

模型最好返回候选里的稳定 ID，不要重新生成标签名称。解释可以是一小段文本，真正参与程序路由的状态尽量使用枚举、布尔值和受控数组。

还有一个常被漏掉的分支：模型拒绝回答，或者因为长度限制没有生成完整对象。结构化输出接口通常会单独暴露 refusal 和 finish reason，程序必须处理，不能把缺失字段补成一个看似正常的结果。

二、检索的价值，是把问题变小

在分类系统里，检索的任务不只是补充知识。它还负责缩小模型的选择空间。

环节	目标	常用观察指标
确定性规则	接住边界清楚的输入	覆盖率、冲突率
候选召回	让正确标签进入 top-k	Recall@K
候选排序	把更相关的候选排在前面	MRR、NDCG
LLM 决策	结合事实做最终选择	自动决策精度、放弃率

召回决定了系统的理论上限。正确答案没有进入候选池，后面的 LLM 再强也选不到。反过来，Recall@K 很高也不代表最终结果一定更好。候选太多会增加 token，相近标签之间也会互相干扰。

候选数量还会影响上下文利用率。Lost in the Middle 发现，相关信息位于长上下文中部时，模型表现可能明显下降。“窗口装得下”和“模型用得好”并不是一回事。

因此 top-k 应该被当作需要评测的超参数：

1
2
3


k 太小：正确答案可能没有被召回
k 太大：上下文变长，候选彼此干扰
合适的 k：兼顾 Recall@K 和最终决策质量

BM25、Embedding 和 Reranker 适合解决不同的问题。BM25 对关键词、编号和专有名词敏感；Embedding 能处理同义表达；Reranker 在较小的候选集上做更细的 query-document 交互。常见做法是先用便宜的检索器召回，再把少量候选交给 Reranker 或 LLM。

候选来源也值得保留。某个候选来自规则、稀疏检索还是向量检索，应该跟着结果进入 trace。误判发生时，这能帮助判断该调整召回还是决策节点。

三、中间状态也是接口

多节点流程里，一个事实分析节点可能先把原文压缩成摘要，后续节点再根据摘要做判断。这样很方便，也很容易积累漂移。

自然语言摘要是一种有损压缩。它可能省略否定和范围，也可能把推断写成事实。后续模型并不知道这句话来自原始输入还是上一个模型的猜测，只会把它当作新的上下文继续推理。

更稳的中间协议可以写成：

1
2
3
4
5
6
7
8


{
 "direction": "outbound",
 "entity_type": "organization",
 "stage": "execution",
 "has_supporting_document": true,
 "evidence": ["原文片段 A", "输入字段 B"],
 "uncertain_fields": []
}

这里最重要的不是字段叫什么，而是把“输入事实”“模型推断”和“不确定项”分开。自由文本仍然可以留在 reason 中供人阅读，但不要让它悄悄控制程序分支。

从工程角度看，LLM 节点和普通服务没有区别：输入、输出、版本和失败行为都需要契约。模型生成的文字很顺，所以接口漂移有时比普通类型错误更难发现。

四、Critic 能用，但要先告诉它查什么

多轮反思看起来很自然：先生成答案，再让模型审查，发现问题后重新生成。研究对这种方法给出了不同结果。

Self-Refine 在多种任务上观察到自反馈和迭代改写带来的提升；Large Language Models Cannot Self-Correct Reasoning Yet 则发现，没有外部反馈时，模型可能找不到自己的推理错误，修改后表现甚至会下降。

这两个结论并不冲突。润色文本、补充遗漏，和定位一个未知的逻辑错误不是同一道题。Critic 如果只收到一句“请严格审查”，很可能重复第一次判断，也可能为了表现得更严格而修改原本正确的答案。

我更认可有边界的审查：

程序先检查 ID、枚举、互斥条件等硬约束。
规则无法判断时，再调用一次语义 Critic。
Critic 只检查预先定义的错误类型。
高风险状态变化需要独立证据或短确认。
达到调用上限后转人工，不允许无限反思。

Critic 真正需要的是外部锚点。程序规则、候选约束、错误位置和独立检索证据都算锚点。什么都不给，只让模型“再想想”，效果很难预测。

还可以把“发现错误”和“修正错误”拆成两个节点。已有研究表明，模型可能具备修正已定位错误的能力，却不擅长自己找到错误位置。拆开后，每个节点的评测也更清楚。

五、评测不能只留一个 accuracy

高风险分类中，不同错误的代价差很多。自动给出错误结果和把正确样本转给人工，不能算成同一种失败。

一组更实用的指标包括：

总体准确率；
自动决策精度和错误自动放行数；
人工复核率与错误放弃数；
最终状态分布；
各节点调用数、P50/P95 延迟、输入与输出 token；
schema retry、服务 retry、超时和错误类型。

如果业务更重视避免错误自动决策，就应该给自动决策精度设置独立门槛，而不是让总体 accuracy 把它平均掉。可以把目标写成简单的成本函数：

1
2
3
4
5


total_cost
 = false_accept * 高风险成本
 + false_abstain * 机会成本
 + manual_review * 人工成本
 + latency * 服务成本

这些权重来自业务风险，不应由模型指标替代。

全链路评测和冻结回放回答不同问题

全链路评测回答“这个版本能不能用”。冻结回放回答“变化从哪里产生”。

冻结回放会保存某个节点的完整输入，固定 Prompt、候选和依赖，只替换模型或推理参数。如果冻结输入仍然漂移，问题更可能在模型或运行时；如果冻结后稳定、全链路却不稳定，就应检查上游状态。

同一实验也需要重复运行。除了均值，还应观察最差轮次、方差和变化样本交集。一直失败的样本容易定位；偶尔正确、偶尔自信做错的样本更值得警惕。

六、推理优化要分清 prefill 和 decode

一个 LLM 请求大致有两个阶段：

1
2


prefill：处理整段输入，建立 KV cache 或模型状态
decode：逐 token 生成输出，过程更串行

上下文、候选和示例过长，主要增加 prefill；输出理由太长、反复 repair，主要增加 decode 和调用次数。优化前先拆开这些指标，不然很容易在错误的阶段花时间。

Prefix cache 只节省共享前缀的 prefill

vLLM 的 Automatic Prefix Caching 文档明确说明，APC 会复用相同前缀的 KV cache，从而跳过共享部分的 prefill，但不会减少新 token 的 decode 时间。

它更适合长公共前缀、多轮对话，或者对同一文档的重复查询。如果瓶颈是长输出或重复调用，prefix cache 的帮助有限。

Prompt 的排列也会影响缓存命中。稳定的系统指令、schema 和公共规则可以放在前面，动态事实与候选放在后面。不过这个建议仍需在具体运行时上验证。Prefix cache、推测解码、模型架构和并发调度可能互相影响，任何组合都不能只凭单项基准上线。

MTP 和推测解码

普通自回归解码一次只确定一个 token。推测解码先草拟多个 token，再由目标模型一次验证。经典的 Speculative Decoding 使用接受/拒绝采样保持目标模型的输出分布，因此草拟模型不会直接替代目标模型。

MTP 使用模型自带的 multi-token prediction head 预测后续 token。vLLM 的 MTP 文档也把它归在 speculative decoding 中。

评估 MTP 时至少要记录：

1
2
3
4
5
6


draft acceptance rate
mean accepted length
inter-token latency
request throughput
P50 / P95 latency
端到端质量指标

接受率高不等于服务一定更快。草拟和验证本身也有计算成本；高并发下，普通 decode 已经能组成较大的 batch，MTP 的相对收益可能缩小。

并发不是越大越好

vLLM 使用 PagedAttention 和连续批处理提高显存利用率与吞吐。PagedAttention 论文讨论了如何减少动态 KV cache 的碎片和重复保存，从而容纳更有效的 batch。

但 batch 增大后，每一步 decode 会有更多序列竞争计算和内存带宽。max-num-seqs、客户端并发和吞吐之间通常不是单调关系，需要逐档压测。

排查服务瓶颈时，可以先做这样的判断：

1
2
3
4


队列高：检查调度容量、限流或服务副本
prefill 高：检查上下文、候选数量和前缀复用
decode 高：检查输出长度、MTP 和重复调用
GPU 不忙但流程慢：检查网络、串行节点和任务编排

GPU 利用率本身说明不了请求是否高效。它需要和队列、延迟、吞吐、KV cache 使用量一起看。

七、一次结果需要保存哪些版本

模型版本只是复现条件的一部分。结果还会受到检索索引、标签集合、参考数据、策略配置、Prompt、采样参数和运行时版本影响。

对外部依赖，可以先规范化 JSON，再计算内容哈希；一次任务只引用不可变的快照 ID 和哈希，不在执行中途重新获取可能变化的数据。

我现在会把一次 LLM 实验看成下面这个元组：

1
2
3
4
5
6
7
8
9


run = (
 code_commit,
 model_and_runtime,
 prompt_version,
 decoding_config,
 dependency_snapshot,
 evaluation_dataset,
 random_and_request_metadata
)

少了其中一项，复现失败时都可能说不清原因。即使温度设为 0，也不要假设系统绝对确定。并行归约、批处理顺序、服务版本和上游自然语言状态仍可能产生差异。

运行配置可以进入版本控制，密钥不可以。可复现实验和 secret 管理是两件事。

八、通用 Prompt 不应该保存本地政策

领域示例经常不只是在教模型怎样推理，还可能暗中携带业务政策。直接删掉示例，模型失去的也许不是语言能力，而是决策边界。

更清楚的拆法是：

1
2
3


通用推理层：怎样阅读事实、比较候选、处理冲突
领域知识层：常见概念、关系和表达方式
本地政策层：允许的边界、例外规则和风险阈值

推理方法可以复用，政策应显式配置和版本化。所谓泛化，也需要在新的标签集合、独立标注和不同输入分布上验证。把特定词汇从 Prompt 里删掉，只能说明文本变得更抽象，不能说明系统更通用。

以后再做类似系统，我会先检查这些

正确答案不在候选里时，系统是否会明确停止？
模型返回的是稳定 ID，还是重新生成标签名称？
schema 合法后，是否还有领域校验？
中间节点传递的是受控状态，还是会漂移的摘要？
Critic 是否知道具体要检查哪类错误？
自动做错和转人工是否使用不同门槛？
能否冻结任意节点输入，单独回放模型与运行时？
性能数据是否拆开 queue、prefill、decode 和调用次数？
每次实验能否还原代码、模型、Prompt、依赖和评测集？
通用方案是否在新的数据分布上验证过？

一个月前，我更关注模型能不能给出正确答案。现在我更在意，当模型给出答案时，系统有没有足够证据决定自动接受、转给人工，或者承认信息不足。这个问题没什么神秘的，却决定了 LLM 能不能进入真实流程。

多路召回学习笔记：BM25、Embedding、SPLADE 和 Reranker 各在解决什么

Fri, 15 May 2026 00:00:00 +0000

最近在补 RAG 和检索系统的基础。刚开始看资料时，最容易混在一起的几个词就是：BM25、Embedding、SPLADE、Reranker，再加一个听起来很工程的词：多路召回。

单独看定义不难，难点在于把它们放进同一条检索链路里。复习时重点回答这些问题：

哪些方法负责“先找一批候选”？
哪些方法负责“把候选重新排好”？
BM25 和 Embedding 明明都能搜，为什么还要一起用？
Reranker 听起来更准，为什么不直接全库跑？
SPLADE 到底是关键词检索，还是语义检索？

这篇笔记不铺满公式，重点讲清每种方法在检索系统里的位置、优势和边界。

速读版

先给一个压缩版结论：

方法	系统位置	主要解决	优点	短板
BM25	关键词搜索	字面精确命中	快、可解释、对术语敏感	不懂同义表达
Embedding	语义近邻搜索	意思接近但字面不同	泛化强，适合自然语言问题	细粒度容易混
SPLADE	神经稀疏搜索	语义扩展后的关键词匹配	兼顾稀疏结构和语义扩展	模型和索引更复杂
Reranker	精排裁判	少量候选谁最相关	判断细，通常更准	慢，不适合全库扫描

一条典型链路大概是：

1
2
3
4
5


用户 query
 -> BM25 / Embedding / SPLADE 多路召回
 -> 候选合并、去重、分数融合
 -> Reranker 精排
 -> 返回 top-k 或交给下游生成模型

多路召回要解决的是：不要让单一检索方法承担所有召回责任，而是让不同方法互相补盲区。

一、先分清召回和精排

搜索系统一般不会一开始就让最复杂的模型扫描整个文档库。文档量一大，成本会很高。

所以它会分成两步：

1
2
3
4
5


Recall 召回
 从大量文档里快速捞出一批“可能相关”的候选。

Ranking / Reranking 排序或精排
 在候选集合变小之后，再认真比较谁更相关。

召回阶段的目标是“尽量别漏掉相关候选”；精排阶段的目标是“在候选里排得更准”。

BM25、Embedding、SPLADE 通常更适合放在召回阶段；Reranker 通常更适合放在精排阶段。

二、BM25：最经典的关键词检索

BM25 是传统搜索里很经典的方法。它不理解深层语义，也不做推理，主要看一个问题：

query 里的词，在文档里有没有出现？出现的词有没有区分度？

比如用户搜：

1

酒店住宿报销

如果一篇文档里出现了“酒店”“住宿”“报销”，它就应该比完全没出现这些词的文档更相关。

BM25 可以先记成：

1

BM25 分数 ≈ 词频 TF × 逆文档频率 IDF × 文档长度修正

复习时先理解这三个部分，再回到完整公式。

2.1 词频：命中 query 词，说明可能相关

如果 query 里有“住宿”，文档 A 出现了“住宿”，文档 B 没出现，那文档 A 大概率更相关。

但 BM25 不会让词频无限加分。一个词重复出现很多次，并不代表相关性可以无限升高。所以 BM25 会对词频做饱和处理。

2.2 IDF：越少见的词，越有区分度

有些词太常见：

1

申请、说明、费用、管理、流程

它们出现了当然有一点信息，但区分度不强。

有些词更具体：

1

住宿、发票、差旅、押金、手续费

这些词更能帮助判断文档主题。

这就是 IDF 的直觉：一个词在全库里越少见，它越能区分文档。

2.3 文档长度修正：长文档不能天然占便宜

长文档词多，命中 query 词的概率天然更高。如果不修正，长文档会占便宜。

BM25 会考虑文档长度，让“短但精准命中”的文档也有机会排在前面。

2.4 BM25 的位置

BM25 特别适合这些场景：

搜索专有名词
搜索编号、代码、实体名
搜索业务词或固定术语
需要可解释的检索结果

比如：

1

增值税专用发票

如果文档里明确出现这个词，BM25 的表现通常很稳。

它的短板也很明显：不太懂同义词。

1
2
3


住酒店
住宿费
差旅住宿支出

这些表达意思接近，但字面不完全一样。如果没有共同词，BM25 可能就会漏。

复习锚点：BM25 适合作为基础召回，尤其适合术语、编号、实体名；短板是同义表达和口语化改写。

三、Embedding：把文本放进语义空间

Embedding 的思路和 BM25 不同。BM25 看词有没有命中；Embedding 把文本编码成向量。

语义相近的文本，在向量空间里应该更接近。

比如：

1
2
3


员工出差住酒店
差旅住宿费用
酒店房费报销

这些句子字面不同，但语义接近。好的 Embedding 模型会尽量把它们编码到相近的位置。

检索时通常是这样：

1
2
3
4


文档库里的文档 -> 提前编码成向量
用户 query -> 编码成向量
计算 query 向量和文档向量的相似度
返回最相似的 top-k 文档

最常见的相似度是余弦相似度：

1

cosine similarity = 两个向量方向的接近程度

它关心的是方向，而不是文本长度。两个文本语义越接近，向量夹角通常越小，相似度越高。

3.1 Embedding 解决了 BM25 的一部分盲区

用户的问题往往很口语化：

1

出差住酒店怎么报销

文档标题可能是：

1

差旅住宿费用管理办法

BM25 如果没有命中关键分词，可能不够稳；Embedding 更可能从整体意思上判断它们相关。

Embedding 适合：

同义表达
口语化 query
标题和问题表达方式不一致
需要整体语义理解的场景

3.2 Embedding 也会犯“语义太近”的错

Embedding 的问题是，它有时会太模糊。

比如：

1
2
3
4


技术服务费
咨询服务费
软件服务费
会议服务费

从语义上看都和“服务”有关，向量空间里可能靠得很近。但在实际业务里，它们可能需要被分到不同类别。

复习锚点：Embedding 擅长找“语义相近”的内容，但在术语边界、细分类别、编号实体上可能不够精确。因此它常和 BM25 搭配使用。

四、为什么需要多路召回

BM25 和 Embedding 的优缺点互补。BM25 负责词面命中，Embedding 负责语义相近；SPLADE 可以补充神经稀疏召回。多路召回就是同时跑多种召回方法，再合并候选：

1
2
3
4
5
6


BM25 召回一批
Embedding 召回一批
SPLADE 也可以召回一批
 -> 合并候选
 -> 去重
 -> 融合或重排

举个简单例子。

1

query: 出差住酒店怎么报销

BM25 可能找到：

1
2


酒店发票填写要求
住宿费报销单填写说明

Embedding 可能找到：

1
2


差旅费用管理办法
员工出差报销流程

两路结果合起来，比单独用一路更稳。

4.1 分数不能直接相加

多路召回带来一个麻烦：不同方法的分数不是一个尺度。

BM25 可能返回：

1

12.7, 8.3, 3.1

Embedding 的余弦相似度可能是：

1

0.82, 0.77, 0.65

这些分数不能直接相加。

常见处理方法有两类。

第一类是分数归一化，例如 min-max normalization，把不同来源的分数压到相近区间，再加权融合：

1

final_score = 0.5 * norm(BM25) + 0.5 * norm(Embedding)

第二类是只看排名，比如 Reciprocal Rank Fusion。它不太关心原始分数，而是看一个文档在每一路里排第几：

1

RRF(d) = sum(1 / (k + rank_i(d)))

如果一个文档在多路召回里都排得靠前，它的融合分数就会更高。

RRF 的复习锚点：多路召回都排得靠前的文档，融合后应该获得更高优先级。

五、Reranker：候选少了以后，再认真判断

如果 BM25、Embedding、SPLADE 负责先找候选，Reranker 负责在候选变少后做细粒度比较。

Embedding 通常是 bi-encoder：

1
2
3


query 单独编码
doc 单独编码
然后算向量相似度

这种方式快，因为文档向量可以提前算好。

Reranker 通常接近 cross-encoder 思路：

1
2


把 query 和 doc 放在一起
让模型直接判断相关性

例如：

1
2
3


query: 出差住酒店怎么报销
doc: 差旅住宿费用管理办法
score: 0.93

模型可以同时看到 query 和 doc，细粒度判断它们是否匹配。

5.1 为什么 Reranker 不直接全库跑

Reranker 通常更准，但也更慢。

如果文档库有 100 万篇，让 Reranker 对每篇都判断一次：

1
2
3
4


query-doc1
query-doc2
...
query-doc1000000

成本太高。

所以它一般放在召回之后：

1
2


先用 BM25 / Embedding / SPLADE 召回 top50
再用 Reranker 对这 50 个候选重新排序

复习锚点：召回阶段追求快和覆盖，Reranker 阶段追求细粒度相关性判断。

5.2 Reranker 适合处理候选之间的细微差别

比如 query 是：

1

酒店发票抬头填错了怎么办

召回阶段可能找出：

1
2
3


酒店发票填写要求
发票作废与重开流程
差旅住宿费报销规则

这些都相关，但最该排前面的可能是“发票作废与重开流程”。Reranker 就是在这种时候发挥价值。

六、SPLADE：神经网络版的关键词检索

SPLADE 是这几个方法里最容易混淆的一块，可以先这样理解：

SPLADE 试图把 BM25 的稀疏可解释性，和神经模型的语义扩展能力接起来。

BM25 在词项空间工作。文档里有哪些词，就在哪些词上有统计权重。

Embedding 在稠密向量空间工作。每个维度不一定有明确含义，但整体能表达语义。

SPLADE 也在词表空间里工作。假设模型词表有 30,000 个 token，那么一段文本会被表示成一个 30,000 维向量。

不同的是，这个向量很稀疏：

1
2


大部分维度是 0
少数相关 token 维度有正权重

比如用户输入：

1

住酒店

SPLADE 可能不只激活“酒店”，还会激活：

1

住宿、旅馆、房费、差旅

这相当于模型自动帮 query 做语义扩展，但结果仍然落在稀疏词项空间里。

6.1 SPLADE 的激活直觉

很多 SPLADE 实现会对模型输出做类似这样的变换：

1

log(1 + ReLU(x))

拆开看：

ReLU(x)：负数清零，只保留正向激活。
log(1 + x)：压缩过大的权重，让数值更稳定。

这样得到的是非负稀疏权重。

检索时可以直接做点积：

1

score(query, doc) = sparse_query_vector · sparse_doc_vector

如果 query 和 doc 在相同或相关 token 上都有权重，分数就会变高。

6.2 SPLADE 放在哪个位置

可以把它放在 BM25 和 Embedding 中间理解：

1
2
3


BM25 ：词面匹配，稀疏，可解释
Embedding ：语义匹配，稠密，不太可解释
SPLADE ：神经稀疏匹配，有语义扩展，也保留词项空间

SPLADE 吸引人的地方在于，它不像普通 Embedding 那样完全进入黑盒稠密空间，也不像 BM25 那样只依赖原始词面。它可以学习到一些扩展关系。

它的成本也更高：需要专门模型，向量维度很高，索引和部署比 BM25 更复杂。

七、一个完整检索链路可以怎么想

假设用户问：

1

差旅住宿发票丢了还能报销吗

一条比较完整的检索链路可以这样组织：

1
2
3
4
5
6
7


1. BM25 找到包含“差旅”“住宿”“发票”“报销”的文档
2. Embedding 找到语义上接近“发票遗失”“报销材料补充”的文档
3. SPLADE 如果可用，再补一批神经稀疏召回结果
4. 合并候选，去掉重复文档
5. 用归一化加权或 RRF 做候选融合
6. 用 Reranker 对候选重新排序
7. 把 top 文档交给下游问答模型或直接返回

每一步对应一个具体问题：

BM25：有没有明确命中关键词？
Embedding：语义上像不像？
SPLADE：能不能做更聪明的词项扩展？
Reranker：候选里谁最贴合用户问题？

八、选型建议

如果只是做一个小型知识库，最简单的起点通常是：

1

Embedding 召回 + Reranker 精排

如果业务词很强，比如法规条款、财务科目、商品型号、错误代码，可以加上 BM25：

1

BM25 + Embedding 多路召回 + Reranker 精排

如果发现 BM25 词面太死、Embedding 又容易把细分类别混在一起，再考虑 SPLADE：

1

BM25 + Embedding + SPLADE 多路召回 + Reranker 精排

不要一开始就把所有东西都加上。检索系统越堆越复杂，调试成本也越高。更稳的做法是先跑通 baseline，再根据错误样本决定补哪一路。

小结

多路召回不是一个单独算法，而是一种系统设计思路：让不同检索方法从不同角度找候选，再用排序模型做最终筛选。

BM25 解决精确词面匹配，Embedding 解决语义泛化，SPLADE 尝试在稀疏词项空间里加入神经语义扩展，Reranker 负责最后的细粒度判断。

以后复习或设计检索链路时，优先问这些问题：

1
2
3
4
5
6


它用了哪些召回路？
每一路分别解决什么盲区？
候选是取并集，还是只在某一路结果里重打分？
不同分数怎么融合？
Reranker 放在多少候选之后？
最终阈值有没有单独校准？

这些问题比单独背概念更有用。检索效果通常不是由某个单点算法决定的，而是由整条链路的召回覆盖、候选融合、精排质量和阈值校准共同决定的。