企业官网建设流程全解析

1. 为什么召回之后还需要一道“精排”工序

很多人第一次搭问答系统时，都会经历这样一个阶段：向量库接好了，embedding 模型也选了，top-k 一调，感觉效果还行，于是就直接把召回结果丢给大模型去生成答案。结果上线之后发现，用户问一个稍微具体点的问题，返回的答案就开始“串味”——明明问的是 A 产品的退款政策，模型却把 B 产品的售后条款混进来一起答了。

这个问题的根源，往往不在生成模型，而在召回阶段本身。向量检索本质上是在做“粗筛”，它用的是双塔结构（Bi-Encoder），query 和文档分别编码成向量，然后算余弦相似度。这种做法的好处是快，可以提前把文档向量全部算好存进索引，查询时只算 query 一次，然后做近似最近邻搜索。但代价是：query 和文档在编码阶段完全没有交互，模型不知道这两个东西放在一起会是什么语义。

这就是为什么我们需要 Reranker。Reranker 用的是 Cross-Encoder 结构，把 query 和文档拼在一起送进模型，让它们在注意力层里充分交互，最后输出一个相关性分数。这个分数比向量余弦相似度准得多，但代价是慢——你没法预计算，每来一个 query，都得把候选文档逐个跟它拼起来跑一遍模型。

所以工业界的标准做法是两段式：召回阶段用 Bi-Encoder 快速从百万级文档里捞出几十上百个候选，精排阶段用 Cross-Encoder 对这几十个候选重新打分排序。这一步做完，相关性通常会有肉眼可见的提升。

但精排之后还有第二个问题：冗余。top-k 里经常出现好几条内容高度相似的文档，它们可能来自同一篇长文的不同段落，或者是对同一个问题的重复表述。如果直接把这些都塞进上下文，不仅浪费 token，还会让生成模型被重复信息带偏。这时候就需要 MMR（Maximal Marginal Relevance）来做去冗余，在“相关性”和“多样性”之间找一个平衡。

这一章要解决的，就是这两个问题：怎么用 Reranker 把相关性做准，怎么用 MMR 把冗余去掉。我会从原理讲到实操，包括模型选型、llama.cpp GGUF 的部署方式、超时不等式的推导，以及我在实际项目里踩过的坑。

2. Reranker 的本质：Cross-Encoder 到底比 Bi-Encoder 强在哪

2.1 双塔结构的先天局限

先把这个事情说透。Bi-Encoder 的工作方式是：

query_vec = model.encode(query) doc_vec = model.encode(doc) score = cosine(query_vec, doc_vec)

注意这里的关键：model.encode(query)和model.encode(doc)是两次完全独立的调用。query 编码的时候，模型根本不知道它要跟哪篇文档比；doc 编码的时候，也不知道会来什么 query。两边各自把语义压缩成一个固定维度的向量，然后靠向量空间里的距离来衡量相关性。

这个压缩过程是有损的。一篇 500 字的文档，被压成一个 768 维的向量，里面必然丢失了大量细节。更关键的是，有些相关性是“条件性”的——比如 query 问“支持哪些支付方式”，文档里写“我们接受微信、支付宝、银行卡”，这两者在双塔里可能因为用词差异而距离较远，但实际上高度相关。Cross-Encoder 因为能看到 query 和 doc 的完整文本，就能捕捉到这种细粒度的匹配。

2.2 Cross-Encoder 的交互机制

Cross-Encoder 的输入形式是：

[CLS] query [SEP] doc [SEP]

整个序列送进 Transformer，每一层注意力里，query 的 token 和 doc 的 token 都在互相看。最后取[CLS]位置的输出，接一个线性层，得到一个标量分数。这个分数直接就是“这两段文本有多相关”的预测。

我实测下来，同一个数据集上，Bi-Encoder 的 top-1 准确率大概在 60% 出头，换成 Cross-Encoder 精排之后能到 80% 以上。这个差距在问答场景里是决定性的——因为生成模型是“给什么料做什么饭”，你喂进去的上下文不对，它再怎么强也答不对。

但 Cross-Encoder 的代价也很明显。假设你有 100 个候选文档，每个文档平均 200 token，query 50 token，那么每篇文档都要跑一次 250 token 的 forward pass。100 篇就是 100 次。如果用的是 7B 级别的模型，这个延迟在 CPU 上基本不可接受，在 GPU 上也要几百毫秒到一秒。

所以这里有一个工程上的核心矛盾：精度和延迟的权衡。我的经验是，召回阶段可以放宽到 top-50 甚至 top-100，但精排阶段一定要控制候选数量，通常 top-20 到 top-30 是比较舒服的区间。再多了，延迟上去了，收益却递减。

2.3 Reranker 模型的选型思路

选 Reranker 模型，我一般看三个维度：语言支持、模型大小、部署方式。

语言支持不用多说，中文场景必须选中文或多语言训练过的模型。早期很多人直接拿英文的 ms-marco 模型来跑中文，效果惨不忍睹，因为 tokenizer 和语义空间都不匹配。

模型大小方面，Reranker 不需要像生成模型那么大。因为它的任务很简单——二分类式的相关性打分，不需要生成能力。0.1B 到 1B 参数的模型通常就够用了。我试过 bge-reranker-base（约 0.1B）、bge-reranker-large（约 0.3B），以及一些 0.5B 级别的模型，在中文问答场景下，base 版本已经能带来大部分收益，large 版本边际提升有限但延迟翻倍。

部署方式上，如果你的系统已经在用 llama.cpp 跑生成模型，那么用 GGUF 格式的 Reranker 是最省事的——同一套推理框架，不用额外维护 Python 服务。这也是为什么这一章我会重点讲 llama.cpp GGUF 的部署方式。

3. 用 llama.cpp 部署 GGUF 版 Reranker 的完整流程

3.1 为什么选 GGUF 而不是 PyTorch 服务

先说选型理由。用 PyTorch 起一个 Reranker 服务，你需要装 transformers、torch，模型加载要占显存，推理时还要处理 batch 和 padding。如果团队里已经有 llama.cpp 的推理链路，再单独维护一个 PyTorch 服务，运维成本是翻倍的。

GGUF 的好处是：单文件、量化后体积小、CPU 也能跑、和 llama.cpp 生态无缝衔接。一个 0.3B 的 Reranker 量化到 Q4_K_M，文件大概 200MB 左右，加载快，内存占用低。在 CPU 上跑 20 个候选的精排，延迟可以控制在 200-500ms，对于大多数企业问答场景完全够用。

当然，GGUF 也有局限。它的量化会带来轻微精度损失，而且 llama.cpp 对某些模型架构的支持可能滞后。但对于 Reranker 这种打分任务，Q4 量化的精度损失基本可以忽略——我做过对比，Q4_K_M 和 FP16 的排序结果一致性在 98% 以上。

3.2 模型转换与量化

假设你手上有一个 HuggingFace 格式的 Reranker 模型，转 GGUF 的流程大致是：

# 1. 克隆 llama.cpp（假设你已经有了） cd llama.cpp # 2. 安装 Python 依赖 pip install -r requirements.txt # 3. 转换模型为 GGUF（FP16） python convert_hf_to_gguf.py /path/to/reranker-model \ --outfile reranker-fp16.gguf \ --outtype f16 # 4. 量化为 Q4_K_M ./llama-quantize reranker-fp16.gguf reranker-q4km.gguf Q4_K_M

这里有个细节要注意：不是所有 Reranker 模型都能顺利转换。llama.cpp 对模型架构有要求，必须是它支持的架构（比如 BERT、RoBERTa、XLM-R 等）。如果你拿的是一个自定义架构的模型，转换脚本可能会报错。我建议优先选那些社区已经验证过能转 GGUF 的模型，比如 bge-reranker 系列。

转换完成之后，验证一下模型能不能正常加载：

./llama-cli -m reranker-q4km.gguf -p "query: 退款政策 [SEP] doc: 我们支持7天无理由退款" --reranking

注意--reranking这个参数，它告诉 llama.cpp 这是一个 Reranker 模型，输出的是相关性分数而不是生成的 token。

3.3 服务化封装

实际项目里，你不会每次都调命令行。通常是用 llama-cpp-python 封装成一个服务：

from llama_cpp import Llama class Reranker: def __init__(self, model_path, n_ctx=512, n_threads=4): self.llm = Llama( model_path=model_path, n_ctx=n_ctx, n_threads=n_threads, embedding=False, reranking=True, ) def score(self, query, docs): scores = [] for doc in docs: result = self.llm.create_rerank( query=query, documents=[doc], ) scores.append(result['results'][0]['relevance_score']) return scores

这里有个性能陷阱：逐条打分效率很低。llama.cpp 的 rerank 接口其实支持一次传多个 documents，内部会做 batch 处理。我建议这样写：

def score_batch(self, query, docs): result = self.llm.create_rerank( query=query, documents=docs, ) return [r['relevance_score'] for r in result['results']]

实测下来，batch 模式比逐条模式快 3-5 倍，因为省去了重复的模型调用开销。

4. 超时不等式：精排延迟的数学边界

4.1 这个不等式解决什么问题

在企业级系统里，延迟是有硬性预算的。假设你的问答接口 SLA 是 2 秒，那么这 2 秒要分配给：召回（向量检索）、精排（Reranker）、生成（LLM）、网络传输。如果精排吃掉了 1.5 秒，生成就没时间了。

所谓“超时不等式”，就是用来判断：在当前候选数量下，精排会不会超时。它的形式很简单：

T_rerank = N × t_per_doc + t_overhead ≤ T_budget

其中：

• N是候选文档数量
• t_per_doc是单篇文档的打分耗时
• t_overhead是模型调用、tokenization 等固定开销
• T_budget是分配给精排的时间预算

这个不等式看起来简单，但实际用起来有几个坑。

4.2 t_per_doc 不是常数

很多人以为t_per_doc是固定的，其实它跟文档长度强相关。Cross-Encoder 的输入是 query + doc 拼接，doc 越长，序列越长，注意力计算量是 O(n²) 增长的。

我实测过一组数据，用 Q4_K_M 的 0.3B Reranker，在 4 核 CPU 上：

可以看到，从 200 token 到 800 token，长度翻了 4 倍，耗时翻了 6 倍。所以如果你不控制文档长度，t_per_doc会失控。

我的做法是：在精排之前，对候选文档做截断。通常截到 256 或 512 token。因为 Reranker 只需要判断相关性，不需要看完整文档。截断虽然会损失一点信息，但换来的是延迟的可预测性。

4.3 反推候选数量上限

有了t_per_doc的实测数据，就可以反推N的上限。假设T_budget = 500ms，t_overhead = 50ms，文档平均 200 token（t_per_doc = 35ms），那么：

N ≤ (500 - 50) / 35 ≈ 12.8

也就是说，最多只能精排 12 篇。这个数字可能比很多人想象的要小。如果你召回 top-50，然后全部精排，延迟直接爆掉。

所以工程上的做法是：召回 top-50，先用一个轻量级策略粗筛到 top-20，再精排到 top-5。粗筛可以用向量分数阈值，或者用一个更小的 Reranker。这样既保证了精度，又控制了延迟。

提示：这个不等式里的数字都是示例，实际项目里一定要自己实测。不同硬件、不同模型、不同文档长度，结果差异很大。我建议在系统上线前，专门跑一组压测，把t_per_doc和文档长度的关系曲线画出来，作为容量规划的输入。

5. MMR 去冗余：在相关性和多样性之间走钢丝

5.1 冗余是怎么产生的

精排之后，你拿到一个按相关性排序的列表。但如果你仔细看，会发现 top-5 里经常有 2-3 条讲的是同一件事。

这种情况在长文档场景里特别常见。比如一篇 5000 字的产品手册，被切成 20 个 chunk，用户问“保修期多久”，可能 chunk 3、chunk 7、chunk 12 都提到了保修期，只是表述略有不同。精排模型给这三条都打了高分，因为它们确实都相关。但如果把三条都塞进上下文，生成模型会看到三遍几乎一样的信息，不仅浪费 token，还可能因为细微差异而产生混淆。

另一种冗余来自多来源。同一个问题，知识库里有官方文档、有客服话术、有用户手册，三者内容重叠度高。精排只看相关性，不看来源，所以会把它们都排上来。

5.2 MMR 的核心公式

MMR 的思路很直观：在选择下一条文档时，不仅看它和 query 的相关性，还要看它和已选文档的相似度。公式是：

MMR = argmax [ λ × Sim(doc, query) - (1-λ) × max Sim(doc, selected_docs) ]

其中λ是一个 0 到 1 之间的权重：

• λ = 1时，退化成纯相关性排序，不做去冗余
• λ = 0时，完全追求多样性，可能选出不相关的文档
• 实际项目里，λ通常在 0.5 到 0.8 之间

这个公式的直觉是：一条文档如果跟 query 很相关（第一项大），但跟已选文档也很相似（第二项大），那么它的 MMR 分数会被第二项拉低，从而让位给那些同样相关但内容不同的文档。

5.3 相似度用什么算

MMR 里的Sim可以用不同的度量。常见的有：

• 余弦相似度：用 embedding 向量算，快，但需要额外维护一个 embedding 模型
• Jaccard 相似度：基于词集合，简单，但对同义改写不敏感
• BM25 或 TF-IDF：基于词频，适合关键词重叠的场景

我的经验是：如果系统里已经有 embedding 模型（召回阶段肯定有），直接用余弦相似度最方便。因为文档向量在召回阶段可能已经算过了，可以直接复用，不用额外计算。

但这里有个细节：召回用的 embedding 和 MMR 用的 embedding 可以是同一个，但要注意归一化。余弦相似度要求向量是归一化的，否则点积不等于余弦。

import numpy as np def mmr(query_vec, doc_vecs, doc_scores, lambda_param=0.7, top_k=5): """ query_vec: query 的 embedding，shape (d,) doc_vecs: 候选文档的 embedding，shape (n, d) doc_scores: 候选文档的相关性分数（来自 Reranker），shape (n,) """ # 归一化 query_vec = query_vec / np.linalg.norm(query_vec) doc_vecs = doc_vecs / np.linalg.norm(doc_vecs, axis=1, keepdims=True) # query 和每个文档的相似度 query_sim = doc_vecs @ query_vec selected = [] candidates = list(range(len(doc_vecs))) for _ in range(top_k): best_idx = None best_score = -np.inf for idx in candidates: # 相关性项 relevance = lambda_param * query_sim[idx] # 冗余项：跟已选文档的最大相似度 if selected: redundancy = (1 - lambda_param) * max( doc_vecs[idx] @ doc_vecs[s] for s in selected ) else: redundancy = 0 mmr_score = relevance - redundancy if mmr_score > best_score: best_score = mmr_score best_idx = idx selected.append(best_idx) candidates.remove(best_idx) return selected

这段代码里，doc_scores其实没用到，因为 MMR 用的是 embedding 相似度而不是 Reranker 分数。如果你想让 Reranker 分数参与进来，可以把query_sim替换成归一化后的 Reranker 分数。两种做法各有道理：用 embedding 相似度更一致，用 Reranker 分数更准。我一般倾向于用 Reranker 分数做相关性项，用 embedding 相似度做冗余项，这样各取所长。

5.4 λ 怎么调

λ的取值直接决定了最终上下文的质量。我的调参方法是：

1. 先固定λ = 0.7，跑一批测试 query，看 top-5 里有没有明显重复的内容
2. 如果还有重复，降到 0.6 或 0.5
3. 如果发现选出来的文档开始跑题（相关性下降），说明 λ 太低了，往上调

这个过程没有捷径，必须用真实数据调。我见过一些团队直接抄网上的λ = 0.5，结果在他们的场景里效果很差，因为他们的文档冗余度本来就不高，强行去冗余反而把相关文档挤掉了。

注意：MMR 是在精排之后做的，所以它只能从已经排好序的候选里选。如果精排本身就没把相关文档排上来，MMR 也救不了。所以顺序一定是：召回 → 精排 → MMR。

6. 把 Reranker 和 MMR 串进完整链路

6.1 完整流程拆解

现在把前面几块拼起来。一个完整的问答检索链路是这样的：

用户 query ↓ [1] 向量召回（Bi-Encoder）→ top-50 ↓ [2] 文档截断（256 token） ↓ [3] Reranker 精排（Cross-Encoder）→ top-20 ↓ [4] MMR 去冗余 → top-5 ↓ [5] 拼上下文 → 生成模型

每一步都有它的作用，缺一不可。我见过有人跳过第 3 步直接做 MMR，结果 MMR 在低质量的候选集上做选择，选出来的东西相关性很差。也见过有人跳过第 4 步，结果上下文里全是重复内容。

6.2 各阶段的参数配置

把关键参数整理成一张表，方便对照：

这些数字不是金科玉律，但可以作为起点。实际项目里，我会先按这套配置跑通，然后根据效果和延迟做微调。

6.3 一个容易忽略的细节：query 改写

在召回之前，其实还有一个可选步骤：query 改写。用户的问题往往口语化、有指代、有省略。比如“它支持退款吗”里的“它”指什么，如果直接拿去做向量检索，效果会很差。

我通常会用一个小模型做 query 改写，把“它支持退款吗”改写成“XX产品支持退款吗”。这一步对召回质量的提升很明显，而且成本很低。改写后的 query 同时用于召回、精排和 MMR，保证三个阶段看到的是同一个 query。

7. 实测中的坑与调优经验

7.1 Reranker 分数不可比

第一个坑：不同 query 的 Reranker 分数不可比。Cross-Encoder 输出的是一个 logit，它的绝对值没有意义，只有相对排序有意义。你不能说“分数大于 0.5 就是相关”，因为有的 query 整体分数都高，有的整体都低。

所以不要用固定阈值来过滤 Reranker 结果。正确的做法是：永远取 top-n，而不是取分数大于某个值的结果。如果非要过滤，也要用相对阈值，比如“取分数最高的 20%”。

7.2 MMR 的 O(n²) 复杂度

第二个坑：MMR 的朴素实现是 O(n²) 的。每选一条文档，都要跟已选文档算相似度。如果候选有 100 条，选 5 条，计算量是 100×5 次相似度计算，还好。但如果候选有 1000 条，就会明显变慢。

优化方法是：预计算文档之间的相似度矩阵。虽然矩阵本身是 O(n²) 的，但可以用矩阵乘法一次性算完，比 Python 循环快得多。如果 n 特别大，还可以先用向量检索把候选降到 100 以内再做 MMR。

7.3 截断位置的选择

第三个坑：截断文档时，截头还是截尾。很多文档的关键信息在开头（比如标题、摘要），截尾比较安全。但有些文档是“总-分”结构，关键结论在最后，截尾就把结论截掉了。

我的做法是：优先保留开头和结尾，中间截断。具体来说，如果文档超过 256 token，就取前 128 token 和后 128 token 拼起来。这样既能保留标题和开头信息，又能保留结尾的结论。实测下来，这比单纯截尾效果好。

7.4 缓存 Reranker 结果

第四个坑：重复 query 的重复计算。企业问答场景里，很多 query 是重复的或者高度相似的。如果每次都重新跑 Reranker，浪费很大。

我通常会在 Reranker 前面加一层缓存，key 是 query 的哈希，value 是精排后的结果。缓存命中率在真实场景里往往能到 30% 以上，对降低平均延迟很有帮助。缓存可以用 Redis，设置一个合理的过期时间（比如 1 小时），因为知识库更新不频繁。

7.5 监控精排的“边际收益”

最后一个经验：要监控精排的边际收益。什么意思？就是对比“精排前 top-5”和“精排后 top-5”的重合度。如果重合度很高（比如 80% 以上），说明召回质量已经很好，精排带来的提升有限，可以考虑降低精排的候选数量来省延迟。如果重合度很低，说明精排很关键，不能省。

这个指标我一般会做成一个 dashboard，持续观察。它比单纯看“精排后准确率”更有指导意义，因为它直接告诉你精排这一步值不值得。

8. 关于这套方案的一些个人体会

写到这里，Reranker 和 MMR 的核心内容基本讲完了。最后分享几点我在实际项目里的体会。

第一，不要一上来就上最复杂的方案。我见过一些团队，召回还没调好，就急着上 Reranker，结果精排在一个低质量的候选集上做选择，效果提升有限。正确的顺序是：先把召回做好，确保相关文档能进 top-50，再上精排。召回是地基，精排是装修。

第二，延迟预算要提前算。很多项目是上线之后才发现延迟超标，然后回头砍候选数量，效果就下来了。我的做法是在设计阶段就把超时不等式列出来，反推每个阶段的预算，这样后面调优有据可依。

第三，MMR 的 λ 一定要用真实数据调。网上的默认值只能作为起点，不同场景差异很大。我一般会准备一批标注好的 query-doc 对，然后网格搜索 λ，看哪个值在“相关性”和“多样性”两个指标上综合最好。

第四，GGUF 部署虽然方便，但要验证精度。量化会带来精度损失，虽然通常很小，但在某些边界 case 上可能会放大。我建议在切换量化版本之前，跑一组回归测试，对比排序结果的一致性。如果一致性低于 95%，就要考虑用更高的量化精度。

这套方案我在几个企业问答项目里都用过，从客服机器人到内部知识库，效果都比较稳定。核心思路就是：召回负责“不漏”，精排负责“准”，MMR 负责“不重复”。三者各司其职，配合起来才能把上下文质量做上去。