第 12 章 AI InfraGPU分布式训练

第 12 章 RAG 与向量检索

第12章 RAG 与向量检索

本章围绕检索增强生成（RAG）的检索管线展开，按分块、嵌入、检索引擎、混合检索、重排序与评估的顺序介绍核心组件与工程方法，再扩展到高级 RAG 模式与生产化架构。章节覆盖从文档处理到最终回答的完整链路，不涉及具体 LLM 的微调与训练细节。

12.1 RAG 范式与架构总览

检索增强生成（Retrieval-Augmented Generation, RAG）是大模型时代最核心的应用范式之一。其本质是将参数化知识（Parametric Knowledge，模型权重中隐含的语料统计规律）与非参数化知识（Non-parametric Knowledge，外部文档库、数据库、知识图谱）结合，在推理时动态检索相关信息注入 prompt，从而扩展模型的知识边界。

12.1.1 RAG 的三重动机

RAG 之所以成为大模型应用的标准组件，源于 LLM 的三个固有局限： •幻觉缓解：LLM 本质上是一个条件概率生成器。当 prompt 触发的知识超出训练数据覆盖范围，模型倾向于“自信地编造”。工程实践中，RAG 可将生成内容中不被检索上下文支撑的比例从无检索时的 15-27% 降至 2-5%。Faithfulness 衡量的是答案与检索上下文的忠实度，不等同于客观事实准确性，检索上下文本身若包含错误，该指标无法反映。 •知识截止日：GPT-4 的训练数据截止于 2023 年 4 月（GPT-4 Turbo 扩展至 2023 年 12 月）。在金融、法律、医疗等知识密集型领域，半年的知识滞后意味着大量信息缺失。RAG 通过接入实时更新的知识库，将知识新鲜度从“训练时的快照”变为“检索时的实时视图”。 •领域适配成本：微调一个 70B 模型需要数百 GB 领域数据与数十万 GPU 小时。RAG 只需将领域文档向量化存入向量数据库，成本低 3-4 个数量级，且支持增量更新，新文档加入后立即生效，无需重新训练。

12.1.2 RAG 与长上下文微调

在工程实践中，三者不是互斥而是互补。场景与推荐策略的决策框架如表12-1所示。表12-1 RAG 选型决策框架场景推荐策略原因静态专业知识，规模大（>100K tokens） RAG 按需检索，避免上下文膨胀小规模上下文（<10K tokens），高频查询长上下文延迟更低，无检索 pipeline 改变模型行为/风格微调检索不能改变 reasoning pattern 实时信息、时效性要求高 RAG 知识库可实时更新隐私数据，不能离开用户环境 RAG（本地向量库）数据不进入训练/推理实践中最常见的组合模式是 RAG + 微调：微调优化模型的指令遵循和领域风格，RAG 提供事实知识。例如金融合规问答系统常使用领域微调 + 实时法规检索的组合架构。 RAG 与长上下文在成本、延迟与准确性上的权衡可进一步量化，对比如表12-2所示。表12-2 RAG 与长上下文对比维度 RAG 长上下文推理成本每查询仅检索 top-K 片段，token 消耗低全量上下文按 token 计费，成本随窗口线性增长首 token 延迟额外增加检索与重排延迟 10-100 ms 长 prompt 预填充时间随长度线性增长维度 RAG 长上下文知识更新即时生效，新文档入库即可检索依赖模型记忆，需微调才能更新上下文规模不受窗口限制，可覆盖百万级文档受窗口上限约束，超长需截断或摘要幻觉风险依赖检索质量，可提供引用溯源依赖模型记忆，无引用锚点可解释性高，可展示检索来源低，黑盒生成长程准确性命中率与重排质量决定效果注意力稀释，中间位置信息易丢失以 128K 上下文窗口、每查询 4K token 检索结果为例：RAG 的推理 token 消耗约为长上下文方案的 1/30，首 token 延迟约低 100-300 ms；但长上下文省去了检索质量的不确定性，对需要全局一致性的任务（如整篇代码库理解）更优。工程上倾向于按任务粒度混合：需全局把握选长上下文，需时效与溯源选 RAG。

12.1.3 RAG 的三代演进

Naive RAG（2020-2022）用户查询 → 嵌入 → 向量检索 top-K → 拼接上下文 → LLM 生成。简单但问题显著：检索结果可能无关、分块碎片化导致上下文断裂、重复信息浪费 token 预算。
Advanced RAG（2022-2023）在 Naive RAG 基础上引入前检索优化（查询重写、HyDE 假设文档嵌入、多路召回）和后检索优化（重排序、上下文压缩）。这一代的标志性工作是 LlamaIndex 和 LangChain 的 RAG 框架成熟，使 RAG pipeline 成为一个标准化的工程概念。
Modular RAG（2023-至今）不再将 RAG 视为固定流水线，而是可编排的能力模块。核心创新包括自适应检索（模型自主决定是否需要检索）、迭代检索（多步推理与往返检索）、以及将 RAG 与 Agent 框架融合（模型决定何时检索、检索什么、如何利用检索结果）。三代演进的递进关系如图12-1所示。 Naive RAG Pre/post-retrieval optimiza Advanced RAG Modular RAG Agentic RAG 2020-2022 tion 2022-2023 Modular + Agent 2023-present Adaptive · Multi-step · T ools 图12-1 RAG 范式的三代演进

12.2 文档处理与分块策略

分块（Chunking）是 RAG 系统中影响最大的预处理环节，却也是最容易被低估的。分块策略直接决定了检索的召回率、上下文连贯性以及 token 消耗效率。

12.2.1 分块的工程本质

Embedding 模型将文本映射为固定维度的向量，但模型存在输入长度限制（通常 512-8192 tokens）。更重要的是，向量相似度搜索在“精确匹配”和“语义理解”之间存在根本性的粒度权衡：分块太大，单块包含过多主题导致检索精度下降；分块太小，丢失上下文导致语义碎片化。优秀的分块策略追求两个目标： •语义完整性：每个 chunk 应是对一个独立概念的自包含描述 •检索效率：chunk 数量过大增加索引大小和检索延迟

12.2.2 主流分块范式

固定大小分块最朴素的方法：按 token 数或字符数等距切分。 Raw text (800 tokens) ▶ [chunk_1: 256 tokens, chunk_2: 256 tokens, ...] 优点：简单、可预测、计算成本低。缺点：可能在句子中间切断，破坏语义完整性。实际效果高度依赖 chunk_overlap 的选取。典型配置：chunk_size=512 tokens, chunk_overlap=50 tokens（约 10%）。
递归字符分块基于分隔符优先级进行递归切分：先尝试段落分隔（\n\n），再尝试句子分隔（\n），最后退化为字符级切分。这是 LangChain 和 LlamaIndex 的默认策略，命中率远高于固定大小分块。 Priority: \n\n ▶ \n ▶ . ▶ ? ▶ ! ▶ space ▶ character
语义分块利用 embedding 模型自身计算相邻句子的语义相似度，在相似度骤降处切分（语义断层）。当相邻两句的余弦相似度低于阈值（通常 0.5-0.7），标记为分割点。核心算法： •将文档按句子分割 •逐句计算相邻句对的 embedding 余弦相似度 •在相似度低谷处设置 chunk 边界 •可选：对异常短的 chunk 进行合并语义分块在技术文档和教科书类内容上表现优异（语义边界清晰），但在小说、对话等连续叙述文体上效果有限。
Agent 分块最前沿的方案：用 LLM 自身来决定最优切分点。LLM 分析文档结构，识别标题、列表、表格、代码块等语义单元，生成带层级标签的 chunk 树。 Agent analysis ▶ [Section 2.3: "KV Cache Management"] (parent=Section 2, tokens=350) ▶ [Section 2.3.1: "PagedAttention Algorithm"] (parent=Section 2.3, tokens=280) 优点：chunk 语义完整性最佳，元数据丰富（层级、标题、段落类型）。缺点：计算成本高（需遍历整个文档），不适合超大规模文档库。
延迟分块 2024 年 Jina AI 提出的延迟分块（Late Chunking）颠覆了“先切分再嵌入”的传统顺序。传统分块在嵌入前就把文档切成独立片段，每个 chunk 编码时“看不到”前后文，导致代词指代、跨段实体等上下文信息在向量中丢失。 Late Chunking 的做法相反：先用支持长上下文的嵌入模型（如 jina-embeddings-v3、BGE-M3，8192 tokens）对整篇文档做一次前向传播，得到全部 token 的上下文化嵌入，再按 chunk 边界对相应 token 区间做均值池化（mean pooling）生成每个 chunk 的最终向量。由于每个 token 嵌入已通过自注意力吸收了全文上下文，所生成的 chunk 向量天然携带跨块语义，无需依赖 chunk_overlap 来补偿边界信息丢失。 Jina 官方基准显示，在 BeIR 检索任务上 Late Chunking 相比朴素分块的 nDCG 有稳定提升（部分数据集提升 3-10%），且文档越长、指代越密集，收益越明显。工程代价是：文档长度受嵌入模型上下文窗口限制（超过 8K token 需先做“宏观分块”再在每块内部做 Late Chunking），且需要模型返回 token 级隐藏态而非仅最终句向量，因此更适合自托管开源模型而非只返回单向量的商用 API。
Contextual Retrieval Contextual Retrieval（Anthropic, 2024）的核心思想：在嵌入每个 chunk 之前，先用 LLM 为该 chunk 生成一段上下文前缀描述其在整篇文档中的位置和角色，然后将前缀与 chunk 原文拼接后再送嵌入模型。例如原始 chunk「调整 timeout 为 30s」语义模糊；生成前缀后变为「本文档是 K8s Pod 配置参考；本段位于 securityContext 配置节，描述容器启动超时参数：调整 timeout 为 30s」。 Anthropic 实验表明 Contextual Retrieval 将检索失败率从传统分块的 5-8% 降至 1-2%，且与重排序叠加时效果进一步提升。与语义分块不同，它不改变分块边界而是增强每个 chunk 的语义密度，可与任何分块策略叠加。工程代价是一次性写入成本（百万文档约 $15-30 LLM 调用费用），适合文档更新频率低但查询量大的场景。

12.2.3 关键工程参数

Chunk Overlap 相邻 chunk 之间的共享内容比例。过小导致边界处信息丢失，过大导致冗余。经验值：10-20% 的 chunk_size。对于法律、合同等需精确引用的文本，提高到 20-30%。
Metadata Enrichment 每个 chunk 应附加元数据，在检索时用于过滤和排序： chunk_metadata = { "source": "k8s-networking-guide-v3.pdf", "section": "4.3 CNI Plugin Architecture", "page": 87, "chunk_type": "technical_explanation", "last_updated": "2025-03-15", "parent_section_id": "sec-4" }
多粒度索引实践中建议维护两套索引： •小块索引（256-512 tokens）：用于精确检索，回答具体问题 •大块索引（1024-2048 tokens）：用于上下文扩展，检索到小块后拉取父级大块这种 small-to-big 策略在 LangChain 和 LlamaIndex 中都有原生支持，召回率和上下文质量均有 10-15% 的提升。
RAPTOR RAPTOR（斯坦福, 2024）解决的是长文档中“全局问题”的检索困境：当用户问「这篇论文的核心贡献是什么」时，任何单个 chunk 都无法覆盖答案所需的全局视角。RAPTOR 构建文档的层次化摘要树：底层是常规 chunk，中层是相邻 chunk 聚类的 LLM 摘要，顶层是更大范围的主题摘要。检索时同时查询各层，使系统既能回答细节问题也能回答概括性问题。核心技术包括 UMAP 降维与 Gaussian Mixture Model 软聚类，以及折叠树策略去重。在 NarrativeQA 和 QASPER 基准上，RAPTOR + GPT-4 的组合在需要跨段综合推理的问题上提升显著（QASPER answer F1 提升 8-12 个百分点）。工程代价：索引构建需要 O(N log N) 次 LLM 摘要调用，适合内容型 RAG。

12.2.4 内容类型分块建议

分块策略的选择与文档类型强相关，不同类型的分块建议如表12-3所示。表12-3 不同文档类型的分块建议文档类型推荐分块策略 chunk_size chunk_overlap 额外处理技术文档语义分块 512 50 保留标题层级法律合同 Agent 分块 768 100 条款级索引 API 文档递归字符 256 30 端点级索引学术论文递归字符 + 语义 1024 128 摘要独立 chunk 对话/客服固定大小 256 64 保留对话轮次多语言混合语义分块 512 80 语言检测标签

12.3 嵌入模型选型

Embedding 模型是 RAG 系统的质量天花板，检索精度的上限由 embedding 质量决定，后续重排序只能逼近但不能超越这个上限。

12.3.1 嵌入模型分类

稀疏嵌入传统信息检索方法，将文本表示为高维稀疏向量（词频或 BM25 权重）。稀疏检索在精确关键词匹配上强于密集检索，但无法捕获语义相似性（“AI Infra”和“GPU 集群管理”在稀疏空间中可能不相关，但在语义空间中紧密关联）。 •BM25：经典概率检索模型，对文档长度和词频分布做了工程修正 •SPLADE：学习型稀疏嵌入，在稀疏向量基础上引入神经排序，弥补了 BM25 的语义盲区
密集嵌入用 Transformer 编码器将文本映射到连续向量空间（256-4096 维），语义相似的文本在向量空间中距离相近。主流密集嵌入模型对比如表12-4所示。表12-4 主流密集嵌入模型对比模型维度最大 tokens MTEB 平均分 API/开源推荐场景 OpenAI text-embedding-3-large 3072 8191 64.6 API 通用，多语言 OpenAI text-embedding-3-small 1536 8191 62.3 API 性价比优先 Cohere embed-english-v3.0 1024 512 64.0 API RAG 专用，有压缩模式 BGE-M3 (BAAI) 1024 8192 63.4 开源中英双语，支持稀疏+密集 E5-mistral-7b-instruct 4096 32768 66.6 开源通用，长上下文 Jina-embeddings-v3 1024 8192 65.3 开源多语言，task-specific LoRA gte-Qwen2-7B-instruct 3584 32768 67.2 开源中文领先
ColBERT 风格 ColBERT 风格模型不将文档压缩为单一向量，而是保留每个 token 的嵌入（token-level embedding），在检索时进行细粒度的 token 级交互。在精度上接近 Cross-Encoder，但可预先计算文档 token 嵌入，延迟远低于 Cross-Encoder。

12.3.2 维度质量成本权衡

嵌入维度直接影响存储开销、检索延迟与召回质量： High dimension (3072+, e.g. text-embedding-3-large) ├─ Pro: Strong semantic representation, high MTEB score ├─ Con: Index memory 4x vs 768-dim, ANN query latency 2-3x higher └─ Use case: Recall requirement >95% (legal, medical) Medium dimension (1024-1536, e.g. Cohere, BGE-M3) ├─ Pro: Best overall cost-performance └─ Use case: Most RAG production systems Low dimension (256-768, e.g. text-embedding-3-small reduced) ├─ Pro: Low latency, low cost (deployable even in browser) ├─ Con: Recall loss 3-8% └─ Use case: High throughput, <50ms latency real-time systems

Matryoshka 嵌入 OpenAI 的 Matryoshka 嵌入（text-embedding-3 系列）：同一个 3072 维嵌入，可截取前 N 维使用（N ∈ {256, 512, 1024, 1536, 2048, 3072}），短向量损失可控（256 维时 MTEB 仅降 3%），实现了一次嵌入、多级使用。
SOTA 与基准演进嵌入模型迭代极快，选型时务必参考最新榜单而非固定数值。2024 年底至 2025 年，MTEB 榜首梯队已被指令微调的 LLM-based 嵌入模型占据：NVIDIA NV-Embed-v2（Mistral-7B 底座，4096 维）、阿里 Qwen3-Embedding 系列（0.6B/4B/8B 三档，8B 版在多语言 MMTEB 上登顶，支持 32K 上下文与用户自定义指令）、gte-Qwen2-7B-instruct 等。评测基准本身也在升级：原始 MTEB（56 个英文任务）已扩展为覆盖 250+ 任务、100+ 语言的 MMTEB（Massive Multilingual Text Embedding Benchmark），单一“MTEB 平均分”不再能代表跨语言能力，跨语言检索需专门看 MMTEB 的多语言检索子集。选型上有两条实践经验：其一，7B 级嵌入模型精度虽高，但推理成本与延迟远高于 BGE-M3/1024 维这类轻量模型，多数生产 RAG 仍在“1024 维 + 重排序”组合上取得最佳性价比；其二，务必区分对称检索（句-句相似）与非对称检索（短查询-长文档），后者应选择带 query/passage 指令前缀训练的模型（E5、GTE、Qwen3-Embedding 均需在查询前拼接 instruction 才能发挥最佳效果）。

12.3.3 嵌入流水线工程

批量处理单次 API 调用可处理 2048 个文档（OpenAI 限制）。对于百万级文档库，应设计分段批量、失败重试与进度检查点的流水线： [Document store] ▶ Chunk(2048 docs/batch) ▶ [Embedding API] ▶ Fail? ▶ Retry(exponential backoff) ▼ Success [Vector DB batch write]
嵌入缓存对高频查询（如 FAQ 类问题），缓存查询嵌入可节省 20-40% 的 API 调用量。缓存 key = query 文本的 hash，value = embedding 向量。配合语义去重（相同意图的不同表述 → 同一缓存条目），缓存命中率可进一步提高。
增量更新文档库更新时，只需对新文档或修改过的文档重新嵌入，不需要全量重建。向量数据库应支持按文档 ID 的 upsert 和 delete 操作，实现嵌入的增量同步。
多模型并行在复杂 RAG 系统中，可同时使用多个 embedding 模型：对短查询用轻量模型（降低延迟），对长文档用重量级模型（保证精度）。路由层根据输入长度和类型动态选择模型。部分系统采用 ColBERT 做文档端嵌入、密集模型做查询端嵌入的不对称方案。

12.4 向量检索引擎深度解析

向量检索引擎是 RAG 系统的核心存储与查询层。本节以系统工程的视角深度剖析六大检索引擎的架构特征、性能极限和适用边界。

12.4.1 检索引擎分类体系

从部署形态与承载方式看，向量检索引擎可分为专用向量数据库、传统数据库扩展、托管服务与 GPU 加速四类： Standalone Distributed ──────── ────────── Dedicated Vector DB Qdrant Milvus (Rust, HNSW) (Go, billion-scale) Traditional DB Ext. pgvector Elasticsearch (PostgreSQL extension) (Lucene + vector) Managed Services Pinecone Zilliz Cloud (Serverless, auto-tuning) (Milvus fully managed) GPU Acceleration cuVS / RAFT (NVIDIA, pure GPU ANN)

12.4.2 专用向量数据库

Milvus 架构分层：Access Layer（Proxy 无状态）→ Coordinator（元数据与索引调度）→ Worker Nodes（Query Node / Data Node / Index Node）。 ┌─ Proxy ─┐ Client ──▶ LB ──────┤ ├────▶ Root Coordinator (etcd metadata) └─ Proxy ─┘ │ ┌────────────┼────────────┐ Query Node Data Node Index Node (in-memory search) (persistent storage) (GPU-accelerated building) 核心数据通路： •写入：Proxy → Data Node（WAL + 分段存储）→ 异步触发 Index Node 构建 •查询：Proxy → Query Node（内存 ANN 搜索）→ 返回结果 •分段（Segment）是 Milvus 的最小调度单元（默认 512 MB），支持热分段（内存）和冷分段（对象存储）的分层存储性能特征（约 1000 万向量, 768d, HNSW, 16 vCPU + 64 GB 单节点）： •写入：100K vectors/s •查询延迟：p99 < 20 ms（top-10） •召回率：>95%（ef=128，HNSW 搜索参数）注：HNSW 需将原始向量常驻内存（1000 万 × 768 × 4B ≈ 30 GB，加图结构约 40-50 GB），故单节点 64 GB 约支撑千万级 768d float32 向量。10 亿级需分布式多 Query Node 分片，或配合 PQ 压缩 / DiskANN 磁盘索引，全内存存 10 亿 768d 向量需 3 TB 以上。
Qdrant 纯 Rust 实现，单机部署。核心优势在于 Payload Filtering，在向量搜索的同时高效过滤结构化字段，是同类产品中过滤性能最佳的。 Vector search + Payload filtering execution flow:

HNSW traverses graph nodes
For each candidate node, immediately check Payload conditions (in-memory check, < 1us)
Nodes not meeting conditions are skipped, not included in top-K comparison
Result: filtering + search completed in one pass, latency barely increases Qdrant 的向量量化支持： •Scalar Quantization（INT8）：将 float32 向量压缩为 int8，4× 内存节省 •Product Quantization：16× 内存节省，召回率损失 < 3% •Binary Quantization：32× 内存节省，但召回率损失大（仅适用粗筛阶段）

12.4.3 传统数据库的向量扩展

pgvector 在已有 PG 实例上添加向量搜索能力。pgvector 同时支持 IVFFlat 与 HNSW 两种索引（HNSW 自 0.5.0 引入，为当前推荐默认，speed-recall 权衡优于 IVFFlat），查询语法融入 SQL：

Requires PostgreSQL with pgvector 0.5.0+

SELECT id, content, 1 - (embedding <=> $1) AS similarity FROM documents WHERE metadata->>'category' = 'technical' ORDER BY embedding <=> $1 LIMIT 10; 核心局限：IVFFlat 索引在千万级以上向量时性能急剧退化（list 数受限于 shared_buffers 大小），且构建时间随数据量增长是非线性的，改用 HNSW 索引可显著缓解，但受单机内存与写入吞吐限制。适用场景：中小规模向量库，追求运维简单、与现有 PG 集成。 2) Elasticsearch 基于 Lucene 的 HNSW 实现。独特优势是同一次查询中实现 BM25 文本搜索、KNN 向量搜索与结构化过滤的三合一，是混合检索场景的自然选择。 ES hybrid retrieval pipeline: User query ▶ [BM25 text search] ───┐ ▶ [KNN vector search] ──┤▶ [RRF fusion ranking] ▶ Top-K results ▶ [structured filter] ──┘

12.4.4 GPU 加速索引

NVIDIA RAFT 将 ANN 搜索全流程（索引构建 + 查询）迁移到 GPU。在十亿级数据集上，RAFT 的 HNSW 查询延迟比 CPU 实现低 5- 10×。核心创新： •GPU 上的并行图遍历：同时处理多个查询向量，利用 SM 的大规模并行度 •IVF-PQ 的 GPU 优化：聚类分配和距离计算全在 GPU 上完成 •CAGRA（CUDA-Accelerated Graph Index for ANN）：NVIDIA 自研的 GPU 图索引，查询速度比 HNSW 快 2-3×
cuVS 2024 年 NVIDIA 将 RAFT 的向量搜索核心独立为 cuVS 库，提供 C++/Python API。Milvus 已集成 cuVS 作为 GPU 加速后端。

12.5 多路召回与混合检索

单一检索方式存在固有的召回盲区。生产级 RAG 系统通常同时运行多路检索，再将结果融合。本节讨论工程中可落地的混合检索策略。

12.5.1 密稀检索的互补性

密集检索（Dense Retrieval）和稀疏检索（Sparse Retrieval）在互补的维度上各擅胜场，对比如表12-5所示。表12-5 密集检索与稀疏检索对比维度密集检索稀疏检索语义理解强：理解同义词、转述弱：依赖精确关键词精确匹配弱：可能错过专有名词强：精确匹配 ID、代码、缩写多语言强：跨语言语义对齐弱：语言间词汇不共享生僻术语弱：训练数据未覆盖强：只要文档包含即可命中索引大小大（每向量 0.1-4 KB）小（倒排索引，<0.01 KB/文档）典型盲区案例：查询“K8s GPU device plugin 的 NUMA 对齐策略”。密集检索可能返回 GPU 调度相关的广泛内容但漏掉具体的 device plugin 实现细节（“device plugin”在语义空间中模糊），而稀疏检索通过精确匹配“device_plugin”和“NUMA”可直接命中代码注释。两者融合后，召回率可从单路 70% 提高到 90%+。

12.5.2 融合策略

倒数排名融合 RRF（Reciprocal Rank Fusion）是最简洁、无需训练的融合方法，对多路结果按排名取倒数加权： RRF_score(d) = Σ 1 / (k + rank_i(d)) where k = 60 (standard smoothing constant), rank_i(d) is the rank of document d in the i-th retrieval RRF 的优势是不依赖分数的绝对值（各路的分数分布可能完全不同），天然适应各路检索的评分尺度差异。在 TREC 深度学习评测中，RRF 融合比单路最优的 NDCG@10 提高 5-8%。
加权求和当各路输出的分数可比较时，直接加权求和： final_score(d) = α × dense_score(d) + (1-α) × sparse_score(d) α 通常设为 0.7-0.8（密集检索权重偏高），但最优值随查询类型动态变化。可通过一个小型标注集（200-500 条查询-相关文档对）使用贝叶斯优化或网格搜索确定。
学习式融合用一个小型分类模型（如 LightGBM 或 3 层 MLP）将各路检索特征（排名、分数、文档长度、查询-文档 TF-IDF 重叠等）映射为最终排序。训练数据可通过人工标注或利用用户点击反馈构建（点击 = 正例，曝光未点击 = 负例）。
查询路由并非所有查询都需要混合检索。工程上可在检索前加入路由层，按查询特征决定策略：专有名词、产品名、代码标识符等词汇型查询适合稀疏检索（精确词项匹配）；语义模糊、口语化查询适合稠密检索；实体与语义并存的混合查询才走完整融合流程。路由信号可来自分类模型（Few-shot 分类器或小型 LM）、查询长度与词频统计等。典型收益是稀疏查询的命中率不变，而平均检索延迟下降 30-50%。

12.5.3 多模态检索

当 RAG 系统需要检索图像、图表或音视频时，需要额外的模态处理链路。

文本-图像跨模态检索 [User text query] ▶ Text Embedding (text-embedding-3-large) [Image library] ▶ Image Embedding (CLIP ViT-L/14) ▼ Multimodal vector store (unified vector space) ▼ Top-K cross-modal retrieval results

CLIP（Contrastive Language-Image Pre-training）将文本和图像映射到同一向量空间。在多模态 RAG 中，用户可以用自然语言搜索技术架构图、产品图片、截图等视觉内容。 2) 多模态生成增强检索到的图像、图表可以： •直接嵌入回答（Markdown ） •由多模态 LLM（GPT-4V, Gemini）解析为文本描述后再融入生成 •作为数据源传递给代码解释器进行图表数据分析和洞察生成跨模态检索的工程复杂度主要在于两个方面：embedding 模型的模态对齐质量（不同模型在同一向量空间中的文本/图像映射不一致），以及不同模态结果的融合排序（图像相关性和文本相关性的分数不直接可比）。 3) ColPali 传统 RAG 的 PDF 处理需要 OCR → 布局解析 → 分块 → 嵌入，在含复杂表格和图表时错误率极高。ColPali（2024, École Polytechnique / IP Paris）直接用视觉语言模型 PaliGemma-3B 将 PDF 页面渲染为图像，生成类似 ColBERT 的多向量嵌入，检索时无需文本提取。在 ViDoRe 基准上，ColPali 的 nDCG@5 比传统 text-only pipeline 高 15-25 个百分点，视觉嵌入天然保留了表格结构、空间布局和排版层级信息。单页存储约 0.5 MB（float32），百万页约 500 GB。检索延迟约为传统单向量检索的 3-5 倍。适合学术论文、财报等排版质量要求高的场景，不适合纯文本文档。

12.6 重排序与精排

RAG 系统的核心瓶颈不在检索而在精排（Reranking）。向量检索返回的 top-20 chunks 中有 30-50% 可能是不相关的，而一个精确的重排序模型可以将这个比例降低到 5-10%。重排序的本质是用延迟换精度，对粗筛结果进行更细粒度的相关性判断。

12.6.1 Cross vs Bi-Encoder

两种编码器架构代表了检索系统中精度与效率的根本权衡，对比如表12-6所示。表12-6 Bi-Encoder 与 Cross-Encoder 对比架构工作方式单次比较延迟适用阶段精度 Bi-Encoder 查询和文档独立编码，余弦相似度比较 < 0.1 ms 粗筛（百万→千） MTEB 约64 Cross-Encoder 查询和文档联合输入 Transformer，输出相关性分数 10-50 ms 精排（千→十） TREC DL 约85 Bi-Encoder 将打分量化为向量内积（O(1) 每次），可以在毫秒内扫描百万文档。但它的代价是编码时查询和文档从未 “见过彼此”，无法进行细粒度的 token 级交互，而这正是 Cross-Encoder 的强项。 Cross-Encoder 将 [CLS] query [SEP] document [SEP] 输入完整 Transformer，通过自注意力机制进行全 token 交互，输出一个 0-1 的相关性分数。精度远超 Bi-Encoder，但每对 (query, doc) 都需要完整的前向传播，延迟限制了其只能用于精排阶段。

12.6.2 主流重排序方案对比

主流重排序方案的对比如表12-7所示。表12-7 主流重排序方案对比方案类型最大长度延迟 (单条) API/开源 NDCG@10 (BEIR) Cohere Rerank v3 Cross-Encoder 4096 tokens 约100ms API 60.1 BGE-Reranker-v2-m3 Cross-Encoder 8192 tokens 约50ms 开源 60.5 ColBERT v2 Late Interaction 不限约30ms 开源 49.7 Jina Reranker v2 Cross-Encoder 8192 tokens 约80ms API 59.8 mxbai-rerank-base Cross-Encoder 512 tokens 约30ms 开源 57.2 Cohere Rerank v3 在商业 RAG 系统中采用率最高，其优势在于 API 设计简洁（直接输入 query 与 documents 列表，返回 reranked 结果），且对多语言和多领域内容的泛化能力强。 BGE-Reranker-v2-m3 是开源社区的首选。支持 8192 token 长文档（多数 Cross-Encoder 仅支持 512），且中英双语效果均衡。部署建议：vLLM 或 TGI 推理，1× A10 GPU 可达到 200 queries/s。 ColBERT v2 的独特价值在于 late interaction，文档端 token 嵌入可预计算和索引，查询时只计算查询 token 嵌入然后进行 MaxSim 操作。这使得它在某些场景（文档库更新不频繁但查询量大）中延迟优于 Cross-Encoder。

12.6.3 级联检索架构

生产级 RAG 通常采用三阶段级联，如图12-2所示。 User Query Stage 1: Coarse Filter Top 100 Stage 2: Rerank Top 20 Stage 3: LLM Aware Final Context LLM Generation Bi-Encoder ANN Cross-Encoder 图12-2 三阶段级联检索架构各阶段的延迟预算如表12-8所示。表12-8 三阶段级联的延迟预算阶段候选集延迟预算累计延迟 Bi-Encoder (ANN) 百万 → 100 < 10 ms < 10 ms Cross-Encoder 100 → 20 < 500 ms < 510 ms LLM Context Assembly 20 → 最终 prompt < 50 ms < 560 ms LLM Generation 生成回答 < 2000 ms < 2560 ms 总端到端 RAG 延迟通常在 0.8-3 秒之间，其中 LLM 生成占 50-70%，Embedding 与检索占 15-25%，重排序占 10- 20%。 LLM 感知重排最新趋势是用 LLM 自身（如 GPT-4o-mini）进行精排。对每个 candidate chunk，LLM 输出一个 YES/NO 判断（chunk 是否有助于回答查询），而非连续分数。这种二值判断方法（如 RankGPT）在精度上接近 Cross-Encoder，但延迟高 5- 10×。适用场景：对精度要求极高且延迟不敏感的企业级系统。

12.7 RAG 评估体系

RAG 系统的质量评估是一个多维度问题。与传统的生成质量评估不同，RAG 评估必须同时覆盖检索质量（retrieval）和生成质量（generation）两个层面，以及两者之间的交互。

12.7.1 检索质量指标

检索阶段的核心问题是“返回的文档是否包含回答所需的信息”。检索质量指标的定义与目标如表12-9所示。表12-9 检索质量指标定义与目标指标定义典型目标适用场景 Recall@K Top-K 结果中包含至少一个相关文档的查询 > 95% 基准评估比例 (K=10) MRR (Mean Reciprocal Rank) 第一个相关文档排名的倒数均值 > 0.8 问答系统 NDCG@K (Normalized Discounted Cumulative 考虑排名位置的相关性加权 > 0.7 (K=10) 多级相关 Gain) 度 Hit Rate 相关文档是否在 Top-K 中（二值） > 95% 简单评估 (K=20) Recall@K 的选择：K 值取决于下游 LLM 的上下文窗口和预算。对于 GPT-4 Turbo（128K 上下文），K=20-30 是常见选择（检索更多，让 LLM 自己筛选）。对于小上下文模型，K=3-5 更合适。

12.7.2 生成质量指标

生成阶段的核心问题是“基于检索到的上下文，LLM 是否正确、忠实地回答了问题”。

忠实度忠实度（Faithfulness）衡量生成的回答是否完全基于检索到的上下文，没有编造信息。计算方法：将长回答分解为原子声明（atomic claims），逐个检查每个声明是否能在检索上下文中找到支撑。 faithfulness = |{supported claims}| / |{total claims}| Target: > 0.90
答案相关性答案相关性（Answer Relevance）衡量回答是否直接回应了用户的问题（不是答非所问）。计算方法：用 LLM 生成回答的逆问题（reverse questions），计算逆问题与原问题的语义相似度均值。
上下文相关性上下文相关性（Context Relevance）衡量检索到的上下文是否紧凑地包含了回答所需的信息，没有冗余。计算方法：从上下文中提取对回答有贡献的句子比例。 context_relevance = |{relevant sentences}| / |{total context sentences}| Target: > 0.70 (too low means poor retrieval precision, too high may indicate missing information)
上下文召回率上下文召回率（Context Recall）衡量检索到的上下文是否完整覆盖了 ground truth 回答中的关键信息。计算方法：将 ground truth 分解为原子声明，检查每个声明是否能在检索上下文或其推断中找到覆盖。

12.7.3 评估框架对比

主流评估框架的对比如表12-10所示。表12-10 主流 RAG 评估框架对比框架指标覆盖是否需要 Ground LLM 依赖开生产监控 Truth 源 RAGAS Faithfulness, Answer Relevance, Context Precision/Recall, 共 7 个部分需要 GPT-4 或等是价基本支持 TruLens Answer Relevance, Context Relevance, Groundedness 不需要 GPT-4 或等是价支持 Dashboard DeepEva 14+ 指标，含 Hallucination Score 可选任意 LLM 是 CI/CD 集成 l LangSmi 自定义 + RAGAS 集成可选任意 LLM 闭源完整 th Dashboard RAGAS 是目前最广泛采用的 RAG 评估框架。其指标设计源自学术研究，每个指标都有明确的数学定义。TruLens 在生产监控方面更优（实时 Dashboard，漂移检测）。DeepEval 最强在 CI/CD 集成，可作为 pytest 插件直接嵌入开发流程。

12.7.4 合成评估数据生成

手动标注 RAG 评估数据（查询 + ground truth 答案）成本极高。实际工程中常用 LLM 合成评估数据： Synthesis flow:

Sample representative documents from the document store
LLM generates 3-5 QA pairs of varying difficulty for each document
Annotate key information points required for each answer (for subsequent Faithfulness evaluation)
Manual spot-check 10-20% to ensure quality
Use as evaluation dataset for RAGAS/TruLens 关键质量控制： •难度分层：简单（单文档单句）、中等（跨段组合）、困难（多文档推理） •问题多样性：事实型、推理性、比较型、总结型 •对抗样本：故意构造易产生幻觉的问题（如要求引用不存在的数据）

12.8 高级 RAG 模式

Naive RAG 假设检索到的文档就是回答所需的所有信息，在复杂查询中这一假设常常不成立。以下四种高级模式通过引入反思、迭代和图结构来应对这一挑战。

12.8.1 Self-RAG

Self-RAG（Asai et al., ICLR 2024）让 LLM 在生成过程中自主决定是否检索、评估检索结果质量、并据此调整生成策略。核心是在生成序列中插入特殊的反思 token：

  ▶ Trigger retrieval
      ▶ Whether current chunk is relevant (YES/NO)
      ▶ Whether generated content is supported by retrieval (FULLY/PARTIALLY/NO)
      ▶ Whether generated content is useful (usefulness score 1-5)

Self-RAG 的训练方式：在指令数据中插入上述反思 token，微调 7B/13B 模型。推理时，当模型生成时，系统拦截 token，触发向量检索，将结果插入上下文后继续生成。 RAFT RAFT（Retrieval-Augmented Fine-Tuning, Zhang et al., 2024）解决了一个关键问题：通用 RAG 在领域文档上的表现远不如领域微调模型。RAFT 证明可以将「检索 + 阅读 + 推理」的能力在微调阶段直接注入模型。其训练方法：构造训练样本时对每个问题混入正相关文档和干扰文档，并以 20% 概率不提供 oracle 文档，迫使模型学会在噪声上下文中区分相关信息。RAFT 微调后的 Llama-2 7B 在 PubMed、HotpotQA 等专业领域基准上，超过了未微调但使用同等检索 pipeline 的 GPT-3.5。RAFT 学到的不是特定知识，而是「如何在噪声上下文中提取可靠信息」的元能力，与 Self-RAG 的推理时反思机制可组合使用。

12.8.2 Corrective RAG

CRAG（Corrective RAG）专治“检索到错误内容”的问题。当检索结果的相关性置信度低于阈值时，CRAG 触发以下修正流程： [User query] ▼ [Vector retrieval] ▶ Relevance score (per chunk 0-1) ▼ ├─ High confidence (>0.7) ▶ Use retrieval results directly ├─ Medium confidence (0.4-0.7) ▶ Use retrieval + Web Search supplement └─ Low confidence (<0.4) ▶ Discard retrieval, pure Web Search ▼ [Knowledge refinement] ▶ Extract key facts from multi-source info, remove redundancy ▼ [Final generation] CRAG 的核心组件是一个轻量级检索评估器（T5-large 级别，约 3GB），对检索到的每个 chunk 输出 0-1 的相关性分数。评估器通过构造正负例（相关 chunk 标记为 1，随机 chunk 标记为 0）进行微调。

12.8.3 Graph RAG

Graph RAG 将知识图谱（Knowledge Graph）融入 RAG 流程。与向量检索的“相似度驱动”不同，图检索是“关系驱动”的，从查询中提取实体和关系，在图谱中遍历邻域，获取结构化知识。 Microsoft GraphRAG 的两阶段流程： Phase 1: Index construction [Document] ▶ LLM extracts entities + relations ▶ [Build knowledge graph] ▶ [Community detection (Leiden)] ▶ [Community summary generation] Phase 2: Query [User query] ▶ [Local retrieval] or [Global retrieval] Local: vector search + graph traversal of neighbor entities Global: match community summaries (high-level topic answers) ▶ [Map-Reduce generation] 局部检索回答特定实体问题（如“Kubernetes 的 etcd 是什么”），全局检索回答概括性问题（如“K8s 架构中各组件的职责总结”）。 Graph RAG 的优势是结构化精度，对于需要追踪实体间关系的问题，图结构比向量相似度更精确。代价是索引构建成本高（LLM 调用量是 Naive RAG 的 10-50×），适用于文档库规模中等（<10 万篇）但复杂度高的场景。

12.8.4 Agentic RAG

Agentic RAG 将 RAG 嵌入 Agent 框架，模型不是被动接收检索结果，而是主动制定检索策略： [User query] ▶ Agent analysis ▶ Decompose into sub-problems ├─ Sub-problem 1 ▶ Retrieve ▶ Analyze ▶ Sufficient? │ ├─ Yes ▶ Continue │ └─ No ▶ Rewrite query ▶ Re-retrieve ├─ Sub-problem 2 ▶ Need code execution? ▶ Python REPL compute ▶ Result └─ Sub-problem 3 ▶ Need SQL? ▶ DB query ▶ Result ▼ [Sub-result aggregation] ▶ Agent synthesis ▶ Final answer Agentic RAG 的关键工程能力： •查询分解：将复杂问题拆分为原子子问题（每个子问题可被单次检索覆盖） •工具调用：检索只是工具之一；Agent 还可调用 SQL 数据库、API、代码解释器 •迭代检索：基于已检索的信息，Agent 判断是否需要额外信息，动态调整检索方向 •信息综合：将多轮、多源检索结果整合为连贯回答 LangChain 的 create_retrieval_chain 、LlamaIndex 的 RetrieverQueryEngine 和 DSPy 的 ChainOfThought 都是 Agentic RAG 的框架级实现。在实际部署中，建议从简单的单步检索起步，仅在明确需要多步推理时才引入 Agent 模式，每次额外的 LLM 调用带来 0.5-2 秒的延迟增加。

12.9 生产级 RAG 系统架构

将 RAG 从原型推向生产，涉及的不仅是模型选型和参数调优，更是一整套围绕延迟、吞吐、可靠性和可观测性的系统工程。

12.9.1 端到端延迟优化

生产环境的端到端延迟由检索、重排与生成多个环节叠加而成，各环节的优化空间如表12-11所示。表12-11 端到端延迟优化策略策略延迟减少实现方式本地部署 Embedding 60-80 ms → 5-10 ms BGE 模型 + ONNX Runtime 预计算文档 Embedding 消除每次查询的文档嵌入写入时嵌入，查询时只嵌入 query 并行多路检索减半（并行化） async 同时调用多个检索引擎流式 LLM 生成首 token 延迟不变，体感延迟降低 SSE streaming 缓存常用查询命中时 3s → 0s Redis 缓存 query→answer

12.9.2 多租户架构

企业级 RAG 平台通常需要服务多个团队，每个团队有独立的文档库和权限。多租户架构的核心设计问题是数据隔离与速率控制。

数据隔离数据隔离方案对比如表12-12所示。表12-12 数据隔离方案对比方案隔离级别优点缺点独立 Collection 物理隔离最强安全性，性能无干扰资源浪费，小租户成本高 Partition Key 逻辑隔离资源利用率高可能误查（bug 风险） Metadata 过滤应用层隔离最简单查询时过滤开销，核心风险推荐方案：大租户（>100 万文档）使用独立 Collection，中小租户使用 Partition Key 与 Metadata 过滤组合。Milvus 和 Qdrant 都原生支持 Partition Key 的物理分区，查询被路由到对应分区，无跨分区扫描开销。
速率限制与 QoS 按租户配置 QPS 上限和优先级。高优先级租户的数据在热分段（内存），低优先级在温分段（SSD）。对突发流量使用令牌桶算法限流。

12.9.3 向量索引的增量运维

生产环境的文档库是持续变化的，每天有新增、修改和删除。向量索引必须支持高效的增量操作。

Upsert 现代向量数据库支持按文档 ID 的 upsert，新 ID 插入，已存在 ID 覆盖旧向量和元数据。Qdrant 和 Milvus 的 upsert 延迟在 1-5 ms（单文档）。
Delete 标记删除（tombstone）加后台 GC。在 HNSW 索引中，删除节点不会立即从图中移除（代价高），而是标记为“已删除” 并在查询时过滤。
索引重建策略 •增量更新：插入新节点到 HNSW 图，时间复杂度 O(log N )。但大量插入（>10% 总节点数）后图质量下降，召回率损失 2-5% •周期性全量重建：每周/每月重建索引，恢复最优召回率。对于十亿级索引，全量重建耗时数小时至数天，需安排在低峰窗口
滚动更新与 A/B 测试维护两个索引版本（A/B），新文档写入 B 索引。当 B 索引就绪后，通过配置中心切换流量。这种模式支持： •新 embedding 模型的零停机上线 •新分块策略的灰度验证 •快速回滚（切换回 A 索引）

12.9.4 对接推理服务架构

RAG 系统与推理服务之间的接口设计直接影响端到端延迟和可靠性，典型架构如下： ┌─── RAG Service ───┐ [Client] ──▶ [API Gateway] ──┤ ├──▶ [Vector DB] └──┬─────────────────┘ │ ▼ [Inference Platform] (vLLM / TGI / Triton)

耦合度 •紧耦合：RAG 组件嵌入推理服务内部（如 vLLM 的自定义插件）。延迟最优但灵活性差 •松耦合：RAG 作为独立微服务，通过 HTTP/gRPC 与推理服务通信。推荐用于多模型、多租户平台
超时与降级 •向量检索超时 > 500 ms → 返回空结果，通知 LLM 无检索结果、直接回答 •重排序超时 > 1000 ms → 跳过重排，直接使用粗筛结果 •LLM 生成超时 > 5s → 返回部分生成结果（streaming 已发送的 tokens）
监控指标体系监控指标体系如表12-13所示。表12-13 生产 RAG 监控指标体系指标类别关键指标告警阈值延迟 p50/p95/p99 端到端延迟 p99 > 5s 吞吐检索 QPS, LLM tokens/s QPS 周环比下降 >20% 质量 Faithfulness, Answer Relevance Faithfulness < 0.85 可靠性检索错误率, LLM API 错误率错误率 > 1% 成本每查询 Embedding + LLM token 成本成本周环比上升 >30%