RAG重排模型拖慢推理速度交叉编码器在线计算成延迟瓶颈

AI大模型-阿水

交叉编码器无法提前离线预计算且全注意力开销随候选量倍增，工程落地须通过严格压缩初筛漏斗与自适应路由平衡精度与时延。

AI-assisted summary of 让 AI 答得更准的 Rerank，到底慢在哪？ — original source. Check the original for full context.

Source published: 2026-11-02

Key ideas

Rerank 能让 RAG 问答更准但变慢的本质原因，在于它将双塔模型（Bi-Encoder）的离线单向量粗筛换成了交叉编码器（Cross-Encoder）在线拼接 Query 与 Doc 进行 Token 级全注意力交互。 (0:00)
交叉编码器计算复杂度随 Token 长度呈平方级增长并乘以候选文档数，使得初筛几十毫秒的延迟在精排阶段迅速增加数百毫秒。 (2:30)
业界压降延迟的四类主流解法包括晚期交互（如 ColBERT）、动态自适应路由、100M-300M 级别轻量化模型蒸馏，以及通过 BM25 混合检索压缩送入重排的候选集规模。 (2:30)
双向 Cross-Encoder 中提问表示会受到后接文档内容影响，无法直接复用自回归语言模型常见的前缀缓存（Prefix Caching）技术。 (2:30)

Detailed notes

## Background 本视频由 UP 主“AI大模型-阿水”于 2026 年 11 月 2 日发布在 Bilibili 平台。视频简介提供了包括 Agent 学习资料、大模型学习路线、实战案例集与电子书等配套资源的获取链接。

## TL;DR 视频深入剖析了检索增强生成（RAG）中重排（Rerank）机制“既让回答变准又导致系统变慢”的根本原因。传统的双塔向量召回（Bi-Encoder）虽然能依靠离线预计算实现毫秒级粗筛，但缺乏细粒度语义交互；而交叉编码器（Cross-Encoder）通过在线拼接并触发 Transformer 逐词自注意力交互大幅提升了相关性，却带来了平方级增长的在线延迟。针对这一工程瓶颈，阿水提出了四条主流优化路径：采用以 ColBERT 为代表的晚期交互折中方案、基于置信度的自适应动态路由、模型蒸馏与推理加速，以及通过混合检索压低送入精排的候选集规模。

## Atmosphere & style 视频风格务实透彻、极具工程直觉，善于用“对比两本书的摘要”与“带着问题精读原文”等生动比方化解硬核的模型结构差异。主讲人阿水语调沉稳且不盲从权威，在梳理优化方案时频频提醒开发者警惕“延迟翻倍”的绝对化思维和缓存错用的认知陷阱，处处透露出在业务指标与延迟预算之间寻求务实平衡的资深工程师视角。

## Bulletin - [00:00](https://www.bilibili.com/video/BV1iPxC6SEWu?t=0s) Rerank 能让 RAG 问答更准但变慢的本质原因，在于它将双塔模型（Bi-Encoder）的离线单向量粗筛换成了交叉编码器（Cross-Encoder）在线拼接 Query 与 Doc 进行 Token 级全注意力交互。 - [02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) 交叉编码器计算复杂度随 Token 长度呈平方级增长并乘以候选文档数，使得初筛几十毫秒的延迟在精排阶段迅速增加数百毫秒。 - [02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) 业界压降延迟的四类主流解法包括晚期交互（如 ColBERT）、动态自适应路由、100M-300M 级别轻量化模型蒸馏，以及通过 BM25 混合检索压缩送入重排的候选集规模。 - [02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) 双向 Cross-Encoder 中提问表示会受到后接文档内容影响，无法直接复用自回归语言模型常见的前缀缓存（Prefix Caching）技术。

## Key takeaways - [00:00](https://www.bilibili.com/video/BV1iPxC6SEWu?t=0s) RAG 检索本质上是两阶段漏斗机制：第一步召回（Recall）负责轻量粗筛扩大覆盖面，第二步重排（Rerank）在线增加一轮计算换取更精确的相关性排序。 - [00:00](https://www.bilibili.com/video/BV1iPxC6SEWu?t=0s) 双塔模型（Bi-Encoder）将问题与文档独立转化为固定维度向量，仅计算余弦相似度，因两者编码时互不见面，容易在否定词、实体命名和复杂逻辑处丢失细粒度语义。 - [00:00](https://www.bilibili.com/video/BV1iPxC6SEWu?t=0s) 交叉编码器（Cross-Encoder）将用户提问与候选文档直接拼接输入 Transformer，在自注意力机制中实现 Token 级交互，从而大幅提升对复杂条件的精细理解。 - [02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) 双塔与交叉编码器的核心性能差异在于计算时机：双塔将绝大部分向量计算放到了离线阶段，而交叉编码器必须在用户提问后全部实时在线推理。 - [02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) 晚期交互（Late Interaction / ColBERT）通过在离线端保留 Token 级多向量、在线端快速汇总对齐，在计算开销与精细度间折中，但会显著增加向量存储与检索成本。 - [02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) 自适应重排（动态路由）能根据问题难度或初筛置信度跳过重排以降低平均响应成本，但这不会加速复杂请求本身的计算，且需注意业务中短问题不等于简单问题的陷阱。 - [02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) 模型工程上应优先采用知识蒸馏的 100M-300M 参数轻量级 Reranker，避免盲目使用数十亿参数大模型带来无法接受的推理延迟。 - [02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) 双向 Cross-Encoder 无法像自回归因果模型那样简单利用前缀缓存共享 Query 的 KV Cache，因为双向自注意力机制会导致提问的表示随文档内容改变。 - [02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) 业务层结合 BM25 与向量的混合召回能有效压缩重排候选集数量，但候选集缩减 80% 并不等同于端到端延迟下降 80%，且过度压缩存在筛掉黄金上下文的风险。 - [02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) RAG 系统落地不应盲目追求纸面效果最强的重排模型，而应在自身具体业务数据与延迟预算之间寻找平衡适用的检索漏斗架构。

## Detailed walkthrough ### [00:00](https://www.bilibili.com/video/BV1iPxC6SEWu?t=0s) Rerank 的两阶段漏斗与为什么变准：从双塔到交叉编码器

在检索增强生成（RAG）系统中，许多开发者会发现一个普遍现象：知识库加上 Rerank（重排）之后，模型的回答变得更聪明、更精准了，但系统的整体响应速度却明显变迟钝了。要理解这个“变准又变慢”的权衡，必须先看知识库从海量文档中检索答案的真实流程。从百万级甚至千万级文档中找答案，从来都不是一次检索就能完成的，而是一个层层筛选的漏斗机制。第一步是“召回”（Recall），利用轻量算法快速捞出比如 100 篇候选文档；第二步才是 Rerank（重排），对这 100 篇候选文档逐一进行精细打分，挑出最相关的 5 篇作为优质上下文交给大语言模型。阿水指出：“这里的 100 和 5 只是方便理解的例子，不是固定配置。为什么要分两步？因为第一步负责尽量找全，第二步负责把真正相关的内容排到前面。所以加上 Rerank 本质上是在漏斗末端增加一轮计算，用更多的在线推理换取更准确的相关性判断。”

传统的初筛召回通常采用“双塔模型”（Bi-Encoder），例如 BGE 或 OpenAI 的 Embedding 嵌入模型。在这种架构下，用户的问题和文档分别由模型独立编码，各自转化为固定维度的向量（如 1024 维），线上检索时再通过计算向量之间的余弦相似度（Cosine Similarity）来评估相关性。双塔的核心在于，问题和文档在编码时彼此“看不到”对方，“这就像分别读两本书的摘要，再判断它们是不是在讨论同一件事”。双塔非常擅长在大规模库中极速粗筛，但固定维度的稠密向量无法完整保留所有细粒度语义，遇到否定词、特定实体命名以及复杂的条件逻辑时容易出现偏差。例如，用户搜索“苹果手机的功能”，双塔可能因为“苹果公司”的主题相似度很高而把公司介绍召回，但真正能回答手机操作细节的段落却排不到最前列。

Rerank 的优势正是在这里体现。常见的神经重排模型采用的是“交叉编码器”（Cross-Encoder），如 BGE-Reranker。它打破了双塔模型的隔离，将用户提问与候选文档直接拼接为一条输入序列，中间插入特殊分隔符，整体送入 Transformer 模型。提问中的每个 Token 与文档中的 Token 在自注意力机制（Self-Attention）中可以直接发生注意力交互。“前面像是在对比摘要，现在更像带着问题精读原文。”模型不仅在看整体主题像不像，还能精细推断具体句子是否满足提问的先决条件。阿水强调，更准确的说法是“理解更细”，而不是完全无损，文档阶段、模型能力和业务领域依然会影响结果，而且这里的交互发生在拼接序列的自注意力中，不必将其理解为独立的交叉注意力模块。

```mermaid flowchart TD accTitle: RAG 两阶段检索漏斗机制 accDescr: 展示从百万文档库经过双塔粗排召回到 Cross-Encoder 精排重排的筛选流程

subgraph Phase1["第一阶段：初筛召回 (双塔 Bi-Encoder)"] A["海量知识库 (百万级文档)"] --> B["离线向量化与 ANN 索引"] Q1["用户提问 Query"] --> C["在线生成单向量"] B & C --> D["余弦相似度快速粗筛"] D --> E["候选文档集 (约 100 篇)"] end

subgraph Phase2["第二阶段：精细重排 (交叉编码 Cross-Encoder)"] E & Q2["用户提问 Query"] --> F["Query + Document 拼接输入"] F --> G["Transformer Token 级自注意力全交互"] G --> H["精细相关性打分与重排序"] H --> I["Top-K 优质上下文 (约 5 篇)"] end

I --> J["大语言模型生成最终回答"] ```

[02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) 延迟根源剖析与四种主流优化思路

理解了交叉编码器为什么准，就能明白它为什么会带来极高的在线延迟。双塔模型与交叉编码器最本质的差异在于“计算发生的时间点”。在双塔向量召回阶段，知识库中百万文档的向量化计算早在离线阶段就已经预先处理完毕并存入数据库，用户在线提问时，系统仅需将提问转为向量，然后通过近似最近邻搜索（ANN）极速匹配候选，虽然不能说整条查询是常数复杂度，但大头计算早被消化了。而交叉编码器截然不同，它必须将用户实时提出的问题与每篇候选文档在线拼在一起推理，无法提前预计算。如果召回 50 篇，就有 50 组提问和文档对需要打分。对标准的全注意力机制而言，计算量大致随着输入 Token 数量的平方级增长，再乘以候选文档数量。召回阶段的延时可能仅有几十毫秒，而重排阶段直接增加几百毫秒。阿水提醒大家客观看待性能指标：“所谓延迟翻倍，是某套系统里的结果，不是加上 Rerank 就一定翻倍。”

为了在保留细粒度匹配的同时压降在线延迟，业界形成了四种主要的优化路径：

1. **算法层优化：晚期交互（Late Interaction）** 以 ColBERT 为代表架构。它不把整篇文档压缩成单一全局向量，而是保留文档的多个 Token 级向量。文档侧仍然可以在离线阶段提前编码建库，查询时在 Token 级别做快速的对齐与相似度汇总。它在双塔模型的“离线预计算”与交叉编码器的“Token 级交互”之间找到了折中点，在部分任务上能以较低的在线算力换取接近交叉编码器的效果。但阿水特别指出：“这不是免费的提升，多个向量会增加存储和检索成本，效果与延迟也需要实测，不能直接认定它已经是所有系统的标配。” 2. **架构层优化：动态路由（自适应重排）** 不是所有的请求都配得上昂贵的精排处理。如果是简单的通用闲聊，甚至连召回都不需要；若初筛向量召回的首选结果置信度极高且语义明确，便可以直接跳过 Rerank。只有当问题属于复杂的专业查询、包含多重限制条件，或者召回的候选文档得分胶着、难以区分时，才通过轻量级路由将其分流至 Rerank。阿水提醒这种方案“减少的是所有请求的平均成本，不代表复杂请求本身就变快了”，并且“简单问题不一定容易检索，是否跳过重排要通过业务数据验证，不能只看问题短不短”。 3. **系统层优化：模型轻量化与推理加速** 系统工程上首先可以做知识蒸馏，用大模型指导训练 1 到 3 亿（100M-300M）参数量级的轻量 Rerank 模型，避免盲目使用几十亿参数的大模型；其次是采用 TensorRT-LLM、vLLM 等推理框架优化 Batch 处理与硬件吞吐。关于注意力机制中的 KV Cache（键值缓存），阿水作了关键辨析：若使用支持前缀缓存（Prefix Caching）的自回归因果语言模型做重排，重复的 Query 前缀可以复用缓存；但“常见的双向 Cross-Encoder，提问表示会受到后面文档内容的影响，不能直接照搬这种缓存共享方式，不是输入里有相同提问就一定能缓存”。 4. **业务层控制漏斗：混合检索与候选集压测** 在业务工程端，采用 BM25 关键词检索与向量检索进行混合召回（Hybrid Search），通过多路召回融合先剔除低质量内容，严格把控送入 Rerank 的候选集规模。例如将送入 Rerank 的候选文档从 100 篇压缩到 20 篇，需要打分的文档量直接缩减 80%。但端到端延迟不会同等减少 80%，因为网络开销、提问编码与后续 LLM 生成的固定时间仍然存在。同时候选数量也不能盲目缩减，如果召回阶段就把黄金上下文漏掉了，后续精排再强也无力回天。

阿水总结道，在实际架构落地中，“我们要找的不是最强的重排模型，而是在自己的数据和延迟预算下，最合适的那套检索漏斗”。

- **双塔 (Bi-Encoder) 与交叉编码器 (Cross-Encoder) 核心差异：** - **交互时机：** 双塔是离线独立编码（Query 与 Doc 互不见面），交叉编码器是在线拼接联合编码（Query 与 Doc 在 Transformer 内部深度交互）。 - **算力开销：** 双塔在线仅算一次 Query 向量和 ANN 向量距离（毫秒级）；交叉编码器复杂度随 Token 数呈平方级增长并乘以候选文档数 $N$（百毫秒级）。 - **优化路径落地要点：** - **晚期交互 (Late Interaction / ColBERT)：** 换取细粒度交互但显著膨胀向量索引体积。 - **自适应重排 (Dynamic Routing)：** 优化宏观 QPS 和平均延迟，需防范“短问题难检索”的业务陷阱。 - **轻量模型与蒸馏：** 优先评估 100M-300M 级别小模型在业务域的数据表现。 - **混合召回限流：** BM25 + Dense 向量互补，卡紧 Top-N 漏斗入口，兼顾召回覆盖率与响应时延。

## Notable quotes > [02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) 我们要找的不是最强的重排模型，而是在自己的数据和延迟预算下，最合适的那套检索漏斗 — 阿水

> [00:00](https://www.bilibili.com/video/BV1iPxC6SEWu?t=0s) 加上 Rerank 本质上是在漏斗末端增加一轮计算，用更多的在线推理换取更准确的相关性判断。 — 阿水

> [02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) 简单问题不一定容易检索，是否跳过重排要通过业务数据验证，不能只看问题短不短 — 阿水

> [02:30](https://www.bilibili.com/video/BV1iPxC6SEWu?t=150s) 所谓延迟翻倍，是某套系统里的结果，不是加上 Rerank 就一定翻倍。 — 阿水

## Mentioned 阿水, RAG, Rerank, Bi-Encoder, Cross-Encoder, BGE, OpenAI, BGE-Reranker, ColBERT, TensorRT-LLM, vLLM, BM25

## Video description 视频Agent学习籽料、大模型学习路线、、实战案例集、电子书+问题解答👉https://www.bilibili.com/read/cv52978347/?spm_id_from=333.1387.0.0&jump_opus=1自取哦

[Source](https://www.bilibili.com/video/BV1iPxC6SEWu)

中文简报

RAG重排模型拖慢推理速度交叉编码器在线计算成延迟瓶颈交叉编码器无法提前离线预计算且全注意力开销随候选量倍增，工程落地须通过严格压缩初筛漏斗与自适应路由平衡精度与时延。视频深入剖析了检索增强生成（RAG）中重排（Rerank）机制“既让回答变准又导致系统变慢”的根本原因。传统的双塔向量召回（Bi-Encoder）虽然能依靠离线预计算实现毫秒级粗筛，但缺乏细粒度语义交互；而交叉编码器（Cross-Encoder）通过在线拼接并触发 Transformer 逐词自注意力交互大幅提升了相关性，却带来了平方级增长的在线延迟。针对这一工程瓶颈，阿水提出了四条主流优化路径：采用以 ColBERT 为代表的晚期交互折中方案、基于置信度的自适应动态路由、模型蒸馏与推理加速，以及通过混合检索压低送入精排的候选集规模。 Rerank 能让 RAG 问答更准但变慢的本质原因，在于它将双塔模型（Bi-Encoder）的离线单向量粗筛换成了交叉编码器（Cross-Encoder）在线拼接 Query 与 Doc 进行 Token 级全注意力交互。 (0:00) 交叉编码器计算复杂度随 Token 长度呈平方级增长并乘以候选文档数，使得初筛几十毫秒的延迟在精排阶段迅速增加数百毫秒。 (2:30) 业界压降延迟的四类主流解法包括晚期交互（如 ColBERT）、动态自适应路由、100M-300M 级别轻量化模型蒸馏，以及通过 BM25 混合检索压缩送入重排的候选集规模。 (2:30) 双向 Cross-Encoder 中提问表示会受到后接文档内容影响，无法直接复用自回归语言模型常见的前缀缓存（Prefix Caching）技术。 (2:30)

Reading summary

检索增强生成（RAG）通过引入重排（Rerank）提升回答精准度，但在线延迟会显著攀升。阿水指出，双塔召回负责快速筛选，交叉编码器负责深度交互精排，二者计算时机与机制的差异是造成时延瓶颈的主因，优化需结合多层策略在精度与延迟预算间取得平衡。双塔与交叉编码器的检索漏斗差异 (0:00) 知识库检索通常采用两阶段漏斗机制。第一阶段由双塔模型（Bi-Encoder）执行初筛召回，将问题与文档分别独立编码为固定维度向量，依赖离线预计算与余弦相似度快速筛选候选。但因两端在编码时彼此隔离，双塔模型遇到否定词、特定实体与复杂条件逻辑时容易出现偏差。第二阶段引入的交叉编码器（Cross-Encoder）则打破隔离，将提问与候选文档拼接后输入 Transformer 模型，在自注意力机制中让 Token 之间直接交互。这种精读式的 Token 级推断能更精准地判断句子是否满足提问条件，显著提高送入大语言模型的上下文质量。在线计算与平方级增长导致延迟 (2:30) 重排变慢的根本原因在于计算发生的时间点不同。双塔召回阶段的百万级文档向量计算早在离线建库时完成，在线匹配仅需毫秒级耗时；而交叉编码器必须将用户实时提问与每篇候选文档在线组合推理，无法离线预处理。在标准自注意力机制下，计算复杂度大致随输入 Token 数量呈平方级增长，并随候选文档数量翻倍，常使在线响应时间增加数百毫秒。阿水提醒，延迟翻倍是特定系统测试下的表现，评估重排性能时应客观结合实际系统环境，而非视为绝对规律。平衡精度与时延的四种优化路径 (2:30) 业界针对重排延迟形成了四条主要优化路径。算法层采用 ColBERT 等晚期交互架构，离线保留 Token 级多向量并在查询时快速对齐，但会伴随存储与检索成本上升；架构层引入动态路由，对简单闲聊或高置信度召回跳过重排，阿水强调这降低的是全局平均耗时，且复杂查询的界定必须依赖业务数据验证；系统工程层推荐蒸馏 100M 至 300M 参数的轻量模型并优化批处理，同时提示双向 Cross-Encoder 的提问表示会受文档影响，无法直接套用因果模型的前缀 KV 缓存；业务层则利用 BM25 与向量的混合召回剔除杂质，合理压缩进入精排的候选集规模。实际系统落地的关键不在于盲目部署单体能力最强的重排模型，而在于结合具体业务数据特性与端到端延迟预算，调优出兼顾召回覆盖率与计算成本的检索漏斗架构。

Source quotes

[2:30] 阿水: 我们要找的不是最强的重排模型，而是在自己的数据和延迟预算下，最合适的那套检索漏斗 [0:00] 阿水: 加上 Rerank 本质上是在漏斗末端增加一轮计算，用更多的在线推理换取更准确的相关性判断。 [2:30] 阿水: 简单问题不一定容易检索，是否跳过重排要通过业务数据验证，不能只看问题短不短 [2:30] 阿水: 所谓延迟翻倍，是某套系统里的结果，不是加上 Rerank 就一定翻倍。

Original transcript

[0:00] 为什么你的AI知识库加上Rerunk后脑子变聪明了反应却变迟钝了今天我们就来聊聊Rug,也就是检索增强生成系统,为什么加上Rerunc会更准也更慢,以及怎么把速度找回来。我整理了一份大模型和A型的系统学习路线,可以在主页置顶群里先从它找答案的流程说起。从百万件文档里找答案通常不是一次解锁就结束而是一个层层筛选的漏斗第一步叫造回先快速捞出100篇后选文档第二步才是原Runk 也就是重排把候选文档再精细打分调出最相关的5篇作为上向文交给大模型这里的100和5只是方便理解的例子不是固定配置为什么要分两步因为第一步负责尽量找权第二步负责把真正相关的内容排到前面所以加上Rerank本质上是在漏斗末端增加一轮计算用更多的在线推理划举更准确的相关性判断先说效果为什么会长下来造回通常用双躺模型也叫BI-encode的比如BGE或OpenAI的嵌入模型用户提问和文导分辨编码各自变成一个固定维度的向量比如一千零二十四位再通过与一线相似度判断是否相关双塔不一定是两套不同的模型关键是提问和文档在编码时互相看不到对方这就像分别读两本书的摘要在判断他们是不是在讨论同一件事这种方式很适合快速检索但一个固定维度的向量可能完整保留所有细节否定时特定实体以及复杂的条件关系都可能影响匹配结果比如苹果手机和苹果公司主题接近但如果你问的是手机功能公司介绍就不一定能回答问题向来召回能找到相关主题却不一定能把最能回答问题的那段内容排在第一位VeRank的优势就出现在这里,常见的神经虫排模型采用close encoder,也就是交叉编码器比如BGE, 以Ranker就属于这一类他把提问和文档拼接成一条输入中间通过特殊标记、风格在一起送进Transformer跟Santa不同模型处理这点输入时提问你的token可以直接和文档里的token发生注意力交互Token可以理解成模型处理文本的基本单位不一定等于一个汉字这样模型判断的不只是主题像不像还包括这段内容有没有满足问题里的具体条件前面式的对比摘要现在更像带着问题精度原文不过准确的说法是理解更细不是完全无损也不是保证不会判断错文本阶段模型能力和业务领域仍然会影响结果另外这里的交互发生在凭借序列的自注意力中不必把它理解成一个独立的交叉注意力模块那为什么更细的理解会换来明显的延迟因为两种架构把计算放在了不同的时间向来照回你文道限量可以离线提前算好用户发来问题之后,在线只需要生成提问项量再通过AIA,也就是近似最近年所演,快速寻找相近的文档它不是把整个数据库出条算一遍也不能简单说整条查询都是常数复杂度但大量文档编码工作确实已经提前完成了Cross-Incoder不一样它要把当前提问和每篇候选文档一起处理文档测的完整交互结果无法提前算好召唤五十篇就有五十组提问语文大学要打分可以批量处理但总计算量依然存在对标准的全注意力模型来说注意力计算量大致随输入token数量的平方增加再乘上候选数量注意是平方增长不是指数增长而且这还不是整个模型的全部开销所以后选越多,文本越多,在线推理通常就越次算力召回可能是几十毫秒,重排可能增加几百毫秒但具体素质取决于模型、硬件、批处理和服务负载所谓延迟翻倍,是某套系统里的结果不是加上relunk就一定翻倍理解的成本接下来就能讨论能不能保留细腻度匹配又少做一些在线计算第一种思路是算法层的laten interaction也叫晚期交互代表架构是Cobot它不把整篇文档只压成一个项量而是保留多个TOK箱量文档测依然可以离线编码查询时再进行token级匹配并把匹配结果汇总成相关性分数它相当于在双塔和交叉编码器之间寻找一个折中保留预计算优势同时增加细利度交互在一些任务上,它能以较低的在线计算成本获得接近脚查编码器的效果但这不是免费的提升多个项量会增加存储和减速成本效果与延迟也需要实测不能直接认定它已经是所有系统的标配第二种思路是架构成的动态路由也叫自信重排不是每个请求都值得走同样昂贵的流程比如闲聊本来就可能不需要检索一些简单明确的知识查询如果技术召回以及能提供可靠上下文也可以考虑跳过重牌而复杂的专业问题涉及多个条件或者候选文档难以区分就更值得投入这能计算可以通过轻量级路由决定哪些请求进入Rerunk这样减少的是所有请求的平均成本不代表复杂请求本身就变快了还有一个容易忽略的风险简单问题不一定容易检索是否跳过重牌要通过业务数据验证不能只看问题短不短第三种思路是系统成优化主要看模型大小和推你方式先说知识之流就是让较小的模型学习较大模型的判断能力可以尝试以1到3亿参数级别的轻量重拍模型而不是一开始就用几十亿参数的模型小模型可能更快,但精度会不会下降,下降多少必须在自己的数据上评估再说推理框架,根据模型架构,可以选择适配的Tensor RT-VILM或其他推理方案,优化P处理和硬件利用率这里要特别区分KVCash,也就是注意力计算中的禁止缓存如果使用支持前缀缓存的英国语言模型做重排相同的提问前缀可能复用缓存节省一部分计算但常见的双向close encoder [5:00] 提问表示会受到后面文档内容的影响不能直接照搬这种缓冲共享方式不是输入里有相同提问就一定能缓存最后一种思路是业务层控制漏斗用BM25也就是基于关键词的检索方式加上项量检索作混合造回再融合结果请你低资料候选控制进入relank的数量比如把候选从100篇压到20篇需要打分的文档就少了80%但端到端颜值不一定也减少80%因为还包括查询编码、检索、网络、排队和模型生成等开销而且候选不能只求少真正相关的文档如果在召回阶段就被丢掉重拍再强也找不回来所以最终要一起看召回是否找权排序是否更准回答质量有没有提升以及延迟能不能满足业务要求总结一下,Rank更准,是因为他让提问和文档进行更细的交互更慢是因为这些交互要在线完成优化的方向也就很清楚了算法上减少交互成本架构上按需触发系统上优化模型与推理业务上控制候选规模我们要找的不是最强的重拍模型而是在自己的数据和延迟预算下最合适的那套前所漏斗

RAG重排模型拖慢推理速度 交叉编码器在线计算成延迟瓶颈