Reranker 可以理解成 RAG 里的“二次筛选官”。

它不负责生成答案，也不负责给全库建索引。它的作用是：在第一轮检索已经找出一批候选 chunk 之后，再逐个判断“这个 chunk 到底和当前问题有多相关”，然后重新排序。

典型流程是：

用户问题
  ↓
Embedding / 关键词检索
  ↓
先召回 Top 50 或 Top 100 个候选 chunk
  ↓
Reranker 逐个打分
  ↓
保留最相关的 Top 5~10 个 chunk
  ↓
交给 Chat Model，例如 Kimi / GLM / Claude Code 本地模型
  ↓
生成最终回答

1. Reranker 的基本原理

最常见的 reranker 是 cross-encoder。

它的输入不是单独一句话，而是：

[用户问题, 候选文档片段]

然后它输出一个相关性分数，例如：

query:
"How to limit top routing layer in Innovus?"

chunk A:
"setNanoRouteMode -routeTopRoutingLayer specifies the top routing layer..."
score = 0.92

chunk B:
"Top-level floorplan includes power ring and macro placement..."
score = 0.31

chunk C:
"Routing layer stack information for technology files..."
score = 0.57

最后 RAG 系统按照 reranker score 重新排序。

Sentence Transformers 官方文档对 retrieve-and-rerank 的描述就是：第一阶段先用 lexical search 或 dense retrieval 召回一批候选结果；第二阶段用 CrossEncoder reranker 给每个候选和 query 的相关性打分，再输出排序后的结果。它也说明 CrossEncoder 会把 query 和 document 同时送进 transformer，并输出一个相关性分数。(sbert.net)

关键点是：reranker 会同时看 query 和 chunk。

这和 embedding model 不一样。

2. 为什么有了 reranker 效果会更好？

因为第一轮检索追求的是 快和召回率，不是绝对精准。

第一轮检索可能会做：

关键词检索：BM25 / full-text search
向量检索：embedding cosine similarity
混合检索：keyword + vector

这些方法很快，可以从几万、几十万、几百万个 chunk 里快速找出候选结果。但它们都有局限。

Embedding 检索通常是 bi-encoder 结构：

query 单独编码成向量
chunk 单独编码成向量
然后比较两个向量距离

也就是：

query -> [0.12, -0.44, ...]
chunk -> [0.09, -0.39, ...]
similarity = cosine(query_vector, chunk_vector)

这种方法快，因为文档 chunk 的向量可以提前算好、提前存进向量库。Sentence Transformers 文档也说明 bi-encoder 会分别为 paragraphs 和 query 生成 embeddings，然后用相似度检索。(sbert.net)

但它有一个问题：query 和 chunk 没有在模型内部充分交互。

它只是比较两个压缩后的向量。
对于普通语义搜索，这通常够用；但对你的 EDA / PDK 文档，很多问题不是普通语义相似，而是精确条件匹配。

比如你问：

M1 minimum spacing rule when line-end condition applies

第一轮检索可能召回：

A. M1 spacing general table
B. M1 line-end spacing exception
C. M2 spacing line-end rule
D. VIA1 enclosure rule
E. M1 density rule

embedding 可能觉得 A、B、C 都很像，因为它们都包含：

M1 / M2
spacing
line-end
rule

但真正有用的可能是 B，因为它同时满足：

layer = M1
rule type = spacing
condition = line-end

reranker 会把 query 和 chunk 放在一起判断，更容易识别这种细粒度匹配。CrossEncoder 的优势就在于它能在 query 和 document 之间做 attention，但代价是速度慢，所以通常只用于重排第一轮召回出来的 Top-K 候选，而不是直接扫全库。(sbert.net)

3. 它和 Embedding Model 的本质区别

可以用一句话区分：

Embedding model：把文本变成向量，用于大规模快速召回。
Reranker model：把 query-chunk 对变成相关性分数，用于小规模精排。
Chat model：基于上下文生成自然语言答案。

更具体一点：

模型	输入	输出	主要用途	能否离线预计算	速度	是否生成答案
Embedding model	单段文本	向量	建索引、向量检索	文档可以提前算好	快	否
Reranker	query + chunk	相关性分数	候选 chunk 重排序	不能完全预计算，因为 query 是实时的	中慢	否
Chat model	prompt + context	自然语言 / 代码 / 解释	推理和生成最终回答	否	慢	是

Embedding model 像“粗搜索引”

它适合从大库里快速找候选：

从 100 万个 chunk 中找出最可能相关的 100 个

它的优点是快。
它的缺点是判断不够细。

Reranker 像“人工复核排序”

它适合在候选集中做精细判断：

从 100 个候选 chunk 中挑出最相关的 8 个

它的优点是准。
它的缺点是慢。

Chat model 像“读材料后回答问题的人”

它负责最后回答：

根据这 8 个 chunk，告诉我 Innovus 应该用哪个命令、哪些 option、出处在哪一页。

它的优点是能组织答案、推理、解释。
它的缺点是如果前面检索给错了材料，它也可能答错。

所以 RAG 质量通常不是只靠 chat model 决定，而是：

文档解析质量
+ chunk 切分质量
+ embedding 召回质量
+ keyword 精确命中
+ reranker 精排质量
+ chat model 基于证据回答的能力

4. 一个 EDA 场景例子

假设你问 Claude Code：

Innovus 中如何限制 routing top layer？

第一轮 hybrid search 可能召回这些 chunk：

1. setNanoRouteMode -routeTopRoutingLayer
2. setNanoRouteMode -routeBottomRoutingLayer
3. routeDesign command overview
4. floorplan top-level design setup
5. metal layer technology file description
6. global route congestion report

如果没有 reranker，系统可能按 embedding / keyword 的混合分数直接把前 8 个 chunk 塞给 chat model。

问题是，其中有些 chunk 只是“看起来相关”，比如：

top-level design
metal layer
routing
technology file

但不一定回答你的问题。

reranker 会逐个判断：

query = "如何限制 routing top layer"
chunk = "setNanoRouteMode -routeTopRoutingLayer ..."

它会发现这个 chunk 和问题高度匹配，于是排到前面。

再比如 PDK/design rule 查询：

查询 VIA0 enclosure by M1 under minimum width condition

第一轮可能召回：

VIA0 enclosure by M1
VIA0 enclosure by M2
VIA1 enclosure by M1
M1 minimum width
M1 minimum spacing

reranker 的价值是把同时满足 VIA0 + enclosure + M1 + minimum width condition 的 chunk 排到前面，而不是只因为某个 chunk 里出现了很多相似词就排高。

5. RAGFlow 里 reranker 是怎么接入的？

在 RAGFlow 里，默认检索会混合：

keyword similarity
+ vector cosine similarity

如果你配置了 rerank model，RAGFlow 会改成混合：

keyword similarity
+ reranking score

RAGFlow 官方 retrieval component 文档明确说明：默认使用加权关键词相似度和向量余弦相似度；如果选择 rerank model，则使用加权关键词相似度和 reranking score，并且 rerank 会显著增加响应时间。(RAGFlow)

RAGFlow 的 retrieval test 文档也说明了同样的逻辑：没有 reranker 时组合 keyword similarity 和 vector cosine similarity；有 reranker 时组合 keyword similarity 和 vector reranking score。(RAGFlow)

所以在你的场景里，RAGFlow 的链路大致是：

第一步：hybrid search 召回候选 chunk
  - keyword match
  - vector similarity

第二步：reranker 对候选 chunk 重新打分

第三步：取 Top N chunk 给 Claude Code / 本地大模型

6. 为什么它特别适合你的 Innovus / PDK / Design Rule 文档？

你的文档不是普通百科问答，而是工程规则查询。它的难点是：

命令名很像
option 名很像
rule ID 很像
layer name 很像
同一个 rule 有不同 condition
同一个 node / revision 不能混用
表格脚注可能比主表更关键

例如：

M1.S.1
M1.S.1.a
M1.S.2
M2.S.1
VIA0.EN.1
VIA1.EN.1

embedding model 有时会觉得这些都很接近。
chat model 如果拿到错误 chunk，可能会很自信地答错。
reranker 的作用就是在进入 chat model 之前，尽量把最贴近问题条件的 chunk 排到最前面。

但要注意：reranker 不是真理判断器。

它不能保证：

这个 design rule 数值一定正确
这个 revision 一定是你想要的
两个冲突 chunk 哪个才是最新

它只判断：

这个 chunk 和当前 query 的相关性有多高

所以你仍然要做这些约束：

1. 每个 PDK revision 单独建 dataset
2. 查询时指定 dataset，不要跨版本搜
3. 回答必须引用 page / section / table / rule ID
4. 对 design rule 数值，不允许模型凭记忆补全

7. 有没有必要一开始就上 reranker？

我的建议是：

Innovus user guide：可以先不上 reranker，先看 hybrid search 效果。

因为 user guide 里很多问题是自然语言 how-to，embedding + keyword 通常已经能召回不错的内容。

PDK / design rule：建议尽早上 reranker。

因为 rule 查询对排序精度要求更高，错误 chunk 的代价更大。尤其是你要查：

spacing
enclosure
density
antenna
line-end
cut class
coloring
double patterning
exception
footnote

这些场景里，reranker 通常很有价值。

8. 推荐配置方式

你的本地系统可以这样配：

Chat model:
  Kimi 2.5 / GLM5 / 你本地 Claude Code 正在调用的大模型

Embedding model:
  BGE-M3 或 Qwen3-Embedding

Reranker:
  bge-reranker-v2-m3
  或 Qwen3-Reranker

RAGFlow 参数可以从这个起点开始：

Similarity threshold: 0.25 ~ 0.35

Vector similarity weight:
  Innovus user guide: 0.3 ~ 0.5
  PDK/design rule: 0.2 ~ 0.35

Top N:
  8 ~ 12

Reranker:
  Innovus: 可选
  PDK/design rule: 推荐开启

对 PDK/design rule，我会更偏向：

keyword 权重大一些
reranker 开启
Top N 不要太大
回答强制引用出处

因为你要的是 准确规则查找，不是宽泛语义问答。

9. 最核心的一句话

Embedding model 负责“从全库里快点捞一批可能相关的材料”；Reranker 负责“在这批材料里更认真地挑最相关的”；Chat model 负责“读这些材料后组织答案”。

对你的红区 EDA/PDK RAG 来说，比较稳的链路是：

RAGFlow 解析文档
  ↓
BGE-M3 / Qwen3-Embedding 建索引
  ↓
keyword + vector hybrid search 召回 Top 50
  ↓
bge-reranker / Qwen3-Reranker 重排
  ↓
取 Top 8~12 chunk
  ↓
Claude Code 本地 Kimi / GLM 基于证据回答

这样比“只用 embedding + chat model”更稳，尤其适合 Innovus 命令参数、PDK rule ID、design rule 表格和脚注这种精确检索场景。