RAG 系统架构设计深度解析

概述

Retrieval-Augmented Generation (RAG) 已成为大语言模型应用的核心架构范式。 它通过将外部知识检索与 LLM 生成能力相结合，有效解决了纯 LLM 的知识时效性、 hallucination 以及缺乏垂直领域知识等问题。本文将从资深架构师视角， 系统性地解析 RAG 系统从数据处理到最终输出的完整技术链条。

系统架构总览

一个完整的 RAG Pipeline 包含两个核心阶段：

Indexing Pipeline（索引阶段）

负责将原始文档转化为可检索的知识库。这一阶段的质量直接决定了 后续检索阶段的上限。关键步骤包括：文档解析、文本分块 (Chunking)、 向量化 (Embedding) 以及向量存储。

Query Pipeline（查询阶段）

负责将用户问题转化为精准的答案。这一阶段涉及：Query 理解、 向量检索、Hybrid Search（混合检索）、Reranking（重排序）以及 最终的 LLM 生成。

Chunk 策略

Chunk 策略是 RAG 系统设计中最基础也最关键的决策之一。 它直接影响：检索精度（Chunk 太小导致语义不完整）、上下文利用率 （Chunk 太大导致关键信息被淹没）以及检索延迟与存储成本。

主流分块方法

chunk_size = 512
chunk_overlap = 50

Chunk Size 选择

Chunk Size 的选择需要综合考虑以下因素：

• Embedding 模型上下文窗口：现代 Embedding 模型（如 Cohere embed-v3、text-embedding-3-large）支持 8K-16K tokens 的上下文， 但实际检索精度随长度增加而下降
• 平均 query 长度：用户 query 通常较短（50-200 tokens）， Chunk 需要足够长以提供完整语义
• 文档结构特征：技术文档适合 300-500 tokens 块， 而长篇小说可能需要 1000+ tokens 才能保留情节完整性
• LLM 上下文窗口：最终送入 LLM 的上下文总量 需在模型限制内（通常 4K-128K tokens）

高级分块策略

父子块分块 (Parent Document Retrieval)

采用两层分块结构：子块（Small Chunk）用于精确检索，父块（Large Chunk） 用于最终上下文注入。检索时先找到相关子块，再召回其所属的父块。

Small Chunk → 精确匹配 → Parent Chunk → 上下文注入

语义分块 (Semantic Chunking)

通过计算相邻句子之间的语义相似度，动态决定断点。当相似度低于阈值时， 触发新的 Chunk。这种方法产生的块大小不均匀，但语义更加连贯。

结构感知分块

利用文档结构信息（Markdown 标题层级、XML 标签、PDF 目录等）指导分块：

• 同一标题下的内容尽可能保持在同一 Chunk
• 代码块、表格作为独立 Chunk 整体保留
• 标题元信息作为 Chunk 的 metadata 存储

Embedding 模型

Embedding 模型是 RAG 系统的核心组件，负责将文本转化为稠密向量。 它的选择直接影响检索质量和最终回答的准确性。

主流 Embedding 模型对比

维度选择与 MATRYOSHKA 表示

传统观点认为更高的Embedding维度能保留更多信息，但对于实际检索任务， 1024 维度通常已足够。Cohere 提出的 MATRYOSHKA 表示法 允许在不同维度下进行检索（如 1024 → 768 → 512 → 256）， 大幅降低存储和计算成本，同时保持可接受的精度。

# 使用 MATRYOSHKA 表示降维示例
original_dim = 1024
target_dim = 256  # 75% 存储节省

# 截断前 256 维即可，无需重新计算
embedding = full_embedding[:target_dim]

Embedding 优化策略

批次处理与向量化加速

批量调用 Embedding API 可大幅提升吞吐量。生产环境中， 建议批次大小设置为 100-500，并发请求数根据 API 限流配置。

Query 预处理

• 去除噪音：移除特殊字符、HTML 标签等
• Query 扩展：对短 query 进行同义词扩展或 HyDE（假设性文档嵌入）
• Query 改写：通过小模型将用户口语化表达转化为检索友好型表述

领域微调

通用 Embedding 在垂直领域（如医疗、法律、工程）表现可能不佳。 通过对比学习微调领域语料，可以显著提升检索精度。 典型微调数据格式：

{
  "query": "糖尿病的诊断标准是什么？",
  "positive": "根据 WHO 标准，空腹血糖≥7.0mmol/L...",
  "negative": "高血糖的饮食注意事项包括..."
}

向量检索

向量检索是 RAG 系统的核心引擎，负责在高维向量空间中快速找到与 Query 最相似的 Top-K 文档。向量数据库的选择需要综合考虑精度、性能、成本和运维复杂度。

向量数据库选型

索引算法深度解析

HNSW (Hierarchical Navigable Small World)

目前最流行的向量索引算法，采用多层图结构实现近似最近邻搜索：

• 构建阶段：自底向上构建多层结构，上层稀疏下层稠密
• 搜索阶段：从最上层开始贪心搜索，逐层细化
• 复杂度：构建 O(n log n)，搜索 O(log n)
• 关键参数：ef_construction（精度/构建速度）、 m（内存/精度权衡）

# HNSW 参数配置示例
{
  "ef_construction": 200,  # 范围: 100-400, 越大越精确越慢
  "M": 16,                  # 范围: 4-64, 边数，影响内存和精度
  "ef_search": 100          # 搜索时动态参数，可调
}

IVF (Inverted File Index)

基于聚类的索引方法，将向量空间划分为 K 个聚类中心，搜索时只扫描 最相关的几个聚类。适合内存受限场景。

DISKANN

微软提出的全内存替代方案，基于图索引设计但优化了磁盘访问模式， 适合 billion 级别向量的单机部署。

向量检索质量指标

• Recall@K：召回率，Top-K 结果中包含真实最近邻的比例
• Latency：P99 延迟，通常需要 < 50ms 以保证用户体验
• Throughput：QPS，取决于硬件和索引配置
• Memory Footprint：索引内存占用，影响部署成本

Top-K 与召回率的平衡

实际生产中，通常设置 top_k 为 50-100，然后在重排阶段 缩减至 5-20 条最终上下文。早期召回更多候选项能显著提升最终精度。

Hybrid Search

纯向量检索在某些场景下存在明显局限：难以处理精确关键词匹配（如人名、 型号代码）、数值范围查询、以及结构化查询条件。Hybrid Search（混合检索） 通过融合向量检索与关键词检索，实现优势互补。

混合检索架构

User Query
    │
    ├──→ Sparse Retrieval (BM25) ──→ Score₁ (0.0-1.0)
    │
    └──→ Dense Retrieval (Vector) ──→ Score₂ (0.0-1.0)
            │
            ↓
    ┌───────────────────────┐
    │  Score Fusion (RRF)   │  ← Reciprocal Rank Fusion
    └───────────────────────┘
            │
            ↓
    Unified Ranking

稀疏检索：BM25 详解

BM25 (Best Matching 25) 是经典的信息检索算法，基于词频和逆文档频率：

BM25 Score = Σ IDF(t) · (tf(t,d) · (k₁ + 1)) / (tf(t,d) + k₁ · (1 - b + b · |d|/avgdl))

参数：
- k₁: 词频饱和参数 (通常 1.2-2.0)
- b: 文档长度归一化 (通常 0.75)
- IDF: 逆文档频率
- tf: 词频
- |d|: 文档长度
- avgdl: 平均文档长度

分数融合策略

RRF (Reciprocal Rank Fusion)

最常用的融合方法，对不同检索来源的结果按排名进行加权：

RRF(d) = Σ 1 / (k + rank_i(d))

其中 k 通常为 60，rank_i(d) 为文档 d 在第 i 个检索结果中的排名

Score-based 融合

当两个检索来源的分数分布差异较大时，需要先做归一化再融合：

Final Score = α · normalize(BM25_score) + (1-α) · normalize(Vector_score)

α 通常设置为 0.3-0.5，可通过离线评估优化

BM25 与向量的平衡

实现方案

主流向量数据库均已支持 Hybrid Search：

• Pinecone：内置 Hybrid Search 支持，alpha 参数控制权重
• Weaviate：BM25 + HNSW 原生融合
• Milvus：通过 Hybrid Search 插件实现
• Qdrant：支持 PRECISE 操作符配合向量检索

# Weaviate Hybrid Search 示例
{
  "query": "RAG system architecture",
  "vectorizer": "text2vec-transformers",
  "hybrid": {
    "alpha": 0.5,  # 0=纯关键词, 1=纯向量, 0.5=平衡
    "fusionType": "relativeScoreFusion"
  }
}

重排 (Reranking)

Reranking 是 RAG Pipeline 中提升最终效果的关键步骤。 在向量检索（或混合检索）得到候选文档列表后，Reranker 通过更复杂的 交互式语义模型对候选文档与 Query 的相关性进行更精准的排序。

为什么需要 Reranking？

• 向量检索的局限性：双塔模型（Bi-Encoder）预先计算文档向量， 无法捕捉 Query-Document 的交互特征
• Top-K 精度需求：向量检索召回 Top-50 后，Reranker 精筛至 Top-5
• 跨编码器能力：Cross-Encoder 能直接计算 Query 与 Document 的联合语义相似度

Reranker 模型

Cross-Encoder vs Bi-Encoder

典型 Reranking Pipeline

Query ──┬──→ Vector Search (Top-100) ──┐
        │                                  │
        └──→ BM25 Search (Top-100) ────────┼──→ RRF Fusion (Top-50) ──→ Cross-Encoder Rerank ──→ Top-10 ──→ LLM
                                           │                        (精排)
                                           └──→ Vector Search (不同 index) ──┘

Reranking 优化技巧

上下文窗口选择

Reranker 输入通常限制在 512 tokens。若 Chunk 超过此长度， 需要策略性截取：

• 头部截取：取 Chunk 开头部分（通常信息密度最高）
• 尾部截取：取 Chunk 结尾部分（结论性内容）
• 滑动窗口：分段 Rerank 后聚合分数

DocBERT 风格交互

将 Query 作为 Document 的特殊段落插入，利用 BERT 的 [CLS] token 输出做排序分数：

[CLS] + Query + [SEP] + Document + [SEP]
              ↓
         BERT Forward
              ↓
    [CLS] Token Output → Sigmoid → Relevance Score

多样性重排 (MMR-style)

除相关性外，还需考虑结果多样性。通过 Max Marginal Relevance 在相关性与多样性间取得平衡：

MMR Score = α · Relevance(Q, D) - (1-α) · max_{D'∈Selected} Similarity(D, D')

RAG 评估

RAG 系统的评估是迭代优化的基础。与传统 ML 不同，RAG 评估需要 同时考量 检索质量 与 生成质量 两个维度。

检索评估指标

生成评估指标

RAGAS 框架

RAGAS (Retrieval-Augmented Generation Assessment) 是当前最流行的 RAG 评估框架，从三个维度评估生成质量：

• Faithfulness（忠实度）：生成答案与检索上下文的一致程度， 衡量 hallucination 风险
• Answer Relevance（答案相关性）：生成答案与原始问题的相关程度
• Context Precision（上下文精确度）：检索上下文与问题的相关程度

# RAGAS 评估指标计算
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision

result = evaluate(
    dataset=test_dataset,
    metrics=[faithfulness, answer_relevancy, context_precision]
)

LLM-as-Judge

使用强 LLM（如 GPT-4、Claude-3）对回答质量进行评分。 相比人工评估，成本更低、速度更快，适合迭代测试。

评估 Prompt 示例：
"请评估以下问答对中，AI 助手的回答质量。
考虑因素：
1. 回答是否准确回答了问题
2. 回答是否基于提供的上下文
3. 回答是否完整、无遗漏

评分范围：1-5 分，5 分为最优。

问题：{question}
上下文：{context}
回答：{answer}
评分理由："

其他生成指标

• BLEU / ROUGE：与参考答案的 n-gram 重叠度， 但不适合开放式生成评估
• BERTScore：基于语义嵌入的评估，更灵活
• Task-Specific Metrics：如问答准确率、摘要质量评分等

端到端评估数据集

评估最佳实践

生产级实践

企业级 RAG 架构

┌─────────────────────────────────────────────────────────┐
│                    RAG System Architecture                 │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  ┌──────────┐   ┌──────────┐   ┌──────────────────────┐ │
│  │  Ingest  │──▶│  Chunk   │──▶│  Embedding Service   │ │
│  │  Service │   │  Service │   │  (Batch/Stream)      │ │
│  └──────────┘   └──────────┘   └──────────┬───────────┘ │
│                                            │              │
│                                            ▼              │
│                                    ┌──────────────┐       │
│                                    │  Vector DB   │       │
│                                    │  + Metadata  │       │
│                                    └──────┬───────┘       │
│                                           │              │
│  ┌────────────────────────────────────────┼────────────┐ │
│  │              Query Pipeline             │            │ │
│  │  ┌─────────┐   ┌──────────┐   ┌────────▼───────┐    │ │
│  │  │  Query  │──▶│  Router  │──▶│ Hybrid Search   │    │ │
│  │  │Parsing  │   │(Intent)  │   │ BM25 + Vector   │    │ │
│  │  └─────────┘   └──────────┘   └────────┬────────┘    │ │
│  │                                       │              │ │
│  │                              ┌────────▼────────┐     │ │
│  │                              │   Reranker      │     │ │
│  │                              │(Cross-Encoder)  │     │ │
│  │                              └────────┬────────┘     │ │
│  │                                       │              │ │
│  │                              ┌────────▼────────┐     │ │
│  │                              │  Context       │     │ │
│  │                              │  Assembly      │     │ │
│  │                              └────────┬────────┘     │ │
│  └───────────────────────────────────────┼───────────────┘ │
│                                          │                │
│                               ┌──────────▼──────────┐     │
│                               │     LLM Gateway     │     │
│                               │  (Cache/Rate Limit) │     │
│                               └──────────┬──────────┘     │
│                                          │                │
│                                          ▼                │
│                                  ┌──────────────┐        │
│                                  │  Response    │        │
│                                  │  Streaming   │        │
│                                  └──────────────┘        │
└─────────────────────────────────────────────────────────┘

关键工程实践

缓存策略

• Query 缓存：相同/相似 Query 直接返回历史结果
• Embedding 缓存：热门文档的向量预计算并持久化
• LLM 响应缓存：基于 Prompt Hash 的精确缓存

延迟优化

RAG 系统的端到端延迟通常由以下因素决定：

• 向量检索：5-30ms（索引优化、EF 参数调优）
• Reranking：50-200ms（候选集大小、模型选择）
• LLM 生成：500ms-5s（模型、流式输出）

容错与降级

• 向量检索超时 → 回退至纯 BM25 检索
• Reranking 服务不可用 → 直接使用向量检索 Top-K
• LLM 服务不可用 → 返回预设回复或「当前服务繁忙」

监控与告警

生产环境必须监控的指标：

• 检索召回率（离线评估，定期跑）
• 端到端 P50/P95/P99 延迟
• LLM Token 消耗与成本
• 向量数据库存储增长趋势
• Reranking 质量评分（LLM-as-Judge）

多模态 RAG 扩展

当文档包含图片、表格、PDF 扫描件时，需要额外的处理流程：

• 文档解析：OCR + 布局识别（如 Surya、DocParser）
• 表格处理：表格检测 + 结构化解析（如 TableFormer）
• 图片描述：多模态 LLM 生成图片摘要（如 GPT-4V、Claude）
• 跨模态检索：CLIP 实现图片-文本统一向量空间

总结

RAG 系统架构设计的核心在于对每个环节的深入理解和系统性优化：

RAG 不是一个静态的系统，而是一个需要持续优化的数据 Pipeline。 从 Chunk 策略到最终的用户体验，每个环节都有大量的调优空间。 建议从最小可用系统开始，通过数据驱动的方式逐步迭代，最终构建 满足业务需求的 RAG 系统。