RAG 推理链路优化：把检索、重排与生成串成低延迟流水线

RAG 端到端延迟分解：
① 检索（Retrieval）
   □ query 向量化        ~20-100ms
   □ 向量检索（Top-100） ~10-200ms（取决于索引与规模）
   □ 关键词检索（可选）   ~10-50ms（混合检索）
② 重排（Rerank）
   □ 交叉编码器打分       ~200ms-2s（取决于候选数）
③ 上下文构造（Context Assembly）
   □ 去重、截断、模板拼装  ~5-50ms
④ 生成（Generation）
   □ Prefill（长上下文）  ~200ms-2s
   □ Decode（逐 token）   每 token 10-50ms

→ 用户体感 = TTFT ≈ ①+②+③+prefill

关键认知：
用户感知的是 TTFT（首 token 时间），而 TTFT = 检索 + 重排 + 构造 + prefill
→ 优化 TTFT 必须四段一起看，只优化 decode 对 TTFT 没用
→ 重排常是「隐形大头」：候选 100 个，交叉编码器逐个打分，几百 ms 起

向量索引选型（影响检索延迟）：
□ HNSW：高召回、低延迟，内存占用大 → 在线首选
□ IVF：内存小，需 nprobe 调优 → 大规模
□ PQ/SQ：量化压缩，省内存、略降精度 → 超大规模

检索方式：
□ 纯向量：语义相似
□ 纯关键词（BM25）：精确匹配
□ 混合检索（Hybrid）：向量 + BM25 融合 → 召回更好
  → 融合用 RRF（倒数排名融合）或加权

# 混合检索 + RRF 融合（概念示意）
def hybrid_search(query, top_k=100):
    vec_hits = vector_index.search(embed(query), k=top_k)
    kw_hits  = bm25.search(query, k=top_k)
    # RRF：1/(k + rank)，合并两个排序
    scores = {}
    for rank, doc in enumerate(vec_hits):
        scores[doc.id] = scores.get(doc.id, 0) + 1/(60 + rank)
    for rank, doc in enumerate(kw_hits):
        scores[doc.id] = scores.get(doc.id, 0) + 1/(60 + rank)
    return sorted(scores, key=scores.get, reverse=True)[:top_k]

检索缓存分层：
□ query 向量缓存：相同 query 直接复用（精确哈希）
□ 检索结果缓存：相同 query → 相同 Top-K（TTL 短）
□ 语义缓存：相似 query 命中（embedding 相似度 > 阈值）
  → 见前缀缓存与语义缓存篇的完整设计

命中率来源：
□ 重复查询（FAQ、热门问题）
□ 语义相近的改写（语义缓存）
□ 多轮对话中的指代（同一会话）

重排优化手段：
□ 候选裁剪：粗排召回 100 → 精排只处理 20-50
  （用更便宜的轻量 reranker 先过一遍）
□ 批处理：候选成批送入，长度分桶
□ 蒸馏：大 reranker 蒸馏小模型，延迟减半
□ 量化：FP16/INT8
□ 异步/并行：与后续无关步骤重叠

候选数 vs 质量权衡：
候选少 → 快，但可能漏掉相关文档（召回损失）
候选多 → 准，但延迟线性增长
→ 通常 50 是甜点（召回与延迟平衡）

上下文构造的优化点：
□ 去重：不同 chunk 可能内容重叠 → 去掉冗余
□ 截断：按相关性排序后截断到预算 token 数
□ 压缩：长 chunk 抽取关键句（上下文压缩）
□ 排序：最相关的放开头或结尾（「lost in the middle」效应）
□ 模板：稳定前缀（system + 指令）→ 利于前缀缓存复用

「Lost in the Middle」效应：
LLM 对上下文「开头和结尾」的信息利用最好，
「中间」的信息容易被忽略。
→ 把最相关的文档放首尾，次要的放中间
→ 或按相关性降序排列，让最相关的排最前

前缀缓存的两种收益：
① 相同 system prompt + 指令 → 稳定前缀，跨请求复用
② 相同检索文档被不同 query 引用 → 文档段落的 KV 复用

→ RAG 是前缀缓存的理想场景
→ 命中后 prefill 算力大幅下降，TTFT 显著降低

与 KV cache 的关系：
□ 前缀缓存复用「已算好的 KV」→ 省 prefill
□ PagedAttention 让复用粒度到「块」级别
□ RadixAttention（前缀树）自动发现共享前缀
→ 详见前缀缓存与语义缓存篇

长 prefill 的问题：
□ 一次性 prefill 长上下文 → TTFT 高（用户干等）
□ 且会阻塞同批的 decode 请求（长 prefill 抢占）

解法：
□ Chunked prefill：把长 prefill 切成小块，与 decode 交错
  → 改善 TTFT 与整体吞吐（见 PD 分离篇）
□ 前缀缓存命中 → 直接跳过已缓存的 prefill
□ 上下文压缩 → 减少送入的 token 数

上下文长度 vs TTFT 的权衡：
文档越多 → 召回越好，但 prefill 越慢、KV cache 越占显存
→ 用「相关性截断」在预算内保留最相关文档
→ 目标：在质量可接受下，把上下文压到最短

可并行/重叠的机会：
□ 向量检索与关键词检索 → 并行（两个独立查询）
□ 检索与「query 预处理」→ 部分重叠
□ 重排与「上下文模板准备」→ 重叠
□ 生成 prefill 与「后续文档加载」→ 重叠

流水线示意：
t0 ─┬─ 向量检索 ─┐
    └─ BM25 检索 ─┴─ RRF 融合 ─ 重排 ─ 构造 ─ prefill ─ decode
       （并行）                    ↑
                              与「模板准备」重叠

# 并行检索 + 并行打分（异步）
import asyncio

async def rag_pipeline(query):
    # 并行：向量检索与关键词检索同时发起
    vec_task = asyncio.create_task(vector_search(query))
    kw_task  = asyncio.create_task(bm25_search(query))
    vec_hits, kw_hits = await asyncio.gather(vec_task, kw_task)

    candidates = rrf_fuse(vec_hits, kw_hits)[:50]
    # 重排（批处理，一次打分）
    scores = await rerank_batch(query, candidates)
    top = sorted(zip(candidates, scores), key=lambda x: -x[1])[:10]

    context = build_context(top)      # 去重 + 截断 + 排序
    return await generate(query, context)

并行化的边界：
□ 有数据依赖的步骤不能并行（检索完才能重排）
□ 能并行的是「独立子步骤」（多路检索、独立打分）
□ 端到端优化 = 缩短关键路径 + 让非关键路径重叠

RAG 的多层缓存（从快到慢）：
Layer 1  结果缓存：完整问答对（相同 query 直接返回）
  → 最快，命中即 0 延迟；TTL 短，需失效策略
Layer 2  语义缓存：相似 query 复用答案
  → 命中率高，但需相似度阈值与一致性校验
Layer 3  检索缓存：query → Top-K 文档
  → 跳过检索，仍需重排与生成
Layer 4  前缀缓存：文档 KV 复用
  → 跳过 prefill，仍需 decode

→ 越靠前命中，省的越多
→ 分层设计：先查快层，未命中再往深走

缓存失效：
□ 文档更新 → 检索缓存与结果缓存都要失效
□ 用版本号/时间戳标记文档库状态
□ 语义缓存要防「近似但不等价」的 query 误命中

RAG 端到端指标：
延迟：
□ TTFT（首 token）← 优化重点
□ 各段耗时分解（检索/重排/构造/prefill）
□ P95/P99（长尾）
质量：
□ 检索：Recall@K、MRR
□ 生成：忠实度（faithfulness）、答案正确率
□ 端到端：人工/自动评测集通过率

成本：
□ 每请求 token 消耗（含上下文）
□ 缓存命中率带来的节省

优化验证纪律：
□ 每项优化前后跑同一评测集（延迟 + 质量）
□ 关注「质量是否下降」，而非只看「延迟是否下降」
□ 端到端 SLO：如「P95 TTFT < 2s 且 忠实度 > 0.9」