RAG技术架构核心：从文档解析到答案生成

RAG流程全景解析

检索增强生成（Retrieval-Augmented Generation, RAG）通过将外部知识检索与大语言模型生成相结合，解决了LLM知识过时和幻觉问题。现代RAG系统已形成标准化的三阶段架构：文档处理（Processing）、索引构建（Indexing）、查询执行（Querying）。

flowchart LR
    subgraph 文档处理
        A[原始文档] --> B[解析]
        B --> C[分块]
        C --> D[清洗]
    end
    
    subgraph 索引构建
        D --> E[Embedding编码]
        E --> F[向量存储]
        F --> G[索引优化]
    end
    
    subgraph 查询执行
        H[用户查询] --> I[查询理解]
        I --> J[向量检索]
        J --> K[重排序]
        K --> L[上下文组装]
        L --> M[LLM生成]
    end
    
    G -.-> J
    
    style A fill:#e5e7eb
    style H fill:#e5e7eb
    style M fill:#10b981,color:#fff

文档处理阶段负责将异构数据转化为适合检索的文本单元。这一阶段的质量直接影响后续检索效果。根据LangChain社区2024年的调研，约40%的RAG项目失败可以归因于文档解析或分块策略不当。处理流程包括：格式转换（PDF→文本、HTML→Markdown）、内容提取（表格、图片的OCR）、文本清洗（去除页眉页脚、修复断句）。

索引构建阶段将处理后的文本转换为向量表示并建立高效索引。Embedding模型将语义信息压缩为固定维度的向量（常见384-4096维），向量数据库负责存储和近似最近邻（ANN）检索。索引优化的关键技术包括：量化压缩（降低存储和计算成本）、分区策略（提升大规模数据集性能）、混合索引（向量+关键词的联合检索）。

查询执行阶段响应用户请求，完成从问题理解到答案生成的闭环。标准流程包括：查询重写（扩展同义词、消除歧义）、向量检索（召回Top-K候选）、重排序（使用更强大的模型精排）、上下文组装（将检索结果格式化为Prompt）、LLM生成（合成最终答案）。

根据生产环境的性能数据，完整的RAG链路平均耗时分布为：向量检索10-50ms、重排序50-100ms、LLM生成500-2000ms。其中LLM推理占据总时间的70-80%，是主要的优化目标。

文档解析与分块策略

文档分块（Chunking）是RAG中最关键但最容易被忽视的环节。分块策略决定了检索的粒度——块太小会丢失上下文，块太大会引入噪声。实践中不存在”银弹”策略，需要根据文档类型和查询模式动态选择。

固定长度分块是最简单的策略，按字符数或Token数均分文档。例如，设置块大小为512 Token、重叠128 Token。这种策略实现简单，但会粗暴切断语义单元。测试表明，固定长度分块在问答任务上的准确率为65-75%，适合快速原型验证，但不建议用于生产环境。

语义分块基于文档的内在结构进行分割。对于Markdown，按标题层级分块；对于代码，按函数/类边界分块；对于学术论文，按章节（Introduction/Methods/Results）分块。这种策略保留了语义完整性，但需要针对不同文档类型定制解析器。使用Unstructured等框架可以实现半自动化的语义分块，准确率可提升至75-85%。

递归分块是更精细的方案，采用多级粒度：先按大边界（章节）分块，对大块再细分为小段落。这种层次结构允许检索时动态选择粒度——先匹配大段确定范围，再在大段内精确定位。递归分块在需要跨段落推理的场景表现优异，但实现复杂度和存储成本都更高（需要维护层级索引）。

Agentic分块代表了前沿方向，使用LLM主动决定分块边界。模型分析文档内容，识别主题转换点，生成分块建议。这种方法理论上最优，但成本高昂（处理10万字文档可能需要$1-5的API费用），且存在延迟问题。目前主要用于高价值文档（如法律合同、医学文献）的处理。

分块大小（Chunk Size）的选择同样关键。较小的块（128-256 Token）检索精度高，但可能丢失上下文；较大的块（1024-2048 Token）保留了更多背景，但会稀释关键信息。研究表明，最优块大小与查询长度呈正相关：对于短查询（<50 Token），256-512 Token的块表现最佳；对于长查询（200+ Token），需要1024+ Token的块来提供足够上下文。

向量编码与索引原理

Embedding模型是RAG的”语义引擎”，将文本映射到高维向量空间，使得语义相似的文本在向量空间中距离相近。现代Embedding模型基于Transformer架构，通过对比学习（Contrastive Learning）在大规模语料上训练得到。

编码架构演进：早期模型（如Word2Vec、GloVe）基于静态词向量，无法处理一词多义。现代模型（如BERT、Sentence-BERT）采用上下文相关编码，同一个词在不同语境下有不同的向量表示。最新的E5-mistral、GTE-Qwen2等模型使用更大规模的预训练（数十亿参数），在MTEB基准上持续刷新记录。

向量相似度度量：检索时计算查询向量与文档向量的相似度，常用三种度量方式：

• 余弦相似度（Cosine Similarity）：最常用的度量，计算向量夹角的余弦值，范围[-1, 1]。对向量长度不敏感，适合语义匹配。
• 欧氏距离（Euclidean Distance）：计算向量空间中的直线距离。对向量长度敏感，适合需要考虑词频的场景。
• 点积（Dot Product）：计算简单，在归一化后与余弦相似度等价。常被用于量化加速场景。

近似最近邻（ANN）算法：当向量数量达到百万甚至十亿级别时，精确计算所有相似度不可行。ANN算法通过牺牲少量精度换取数量级的速度提升：

• HNSW（Hierarchical Navigable Small World）：基于图结构的索引，构建多层导航图。查询时从顶层开始，逐层向下逼近。在Milvus、Faiss等库中广泛使用，召回率可达95%+，查询延迟<10ms（百万级向量）。
• IVF（Inverted File Index）：将向量空间划分为K个聚类（Voronoi Cell），查询时只需搜索最近的几个聚类。适合内存受限场景，但召回率略低于HNSW。
• PQ（Product Quantization）：将高维向量分割为子向量，每个子向量用码本中的码字近似。可将存储压缩4-32倍，适合十亿级向量存储。

flowchart TD
    A[原始向量<br/>768维] --> B[Product Quantization]
    B --> C[子向量1<br/>96维 x 8]
    B --> D[子向量2<br/>96维 x 8]
    B --> E[...]
    
    C --> F[码本查找<br/>256个码字]
    D --> G[码本查找]
    E --> H[码本查找]
    
    F --> I[压缩表示<br/>8字节]
    G --> I
    H --> I
    
    I --> J[存储节省<br/>768x4B=3KB → 8B<br/>压缩比384x]
    
    style B fill:#4f46e5,color:#fff
    style I fill:#10b981,color:#fff

混合检索策略：纯向量检索擅长语义匹配，但对精确关键词（如产品型号、人名）可能失效。混合检索结合向量相似度和关键词匹配（BM25），通过加权或Reranker融合结果。测试显示，在包含专有名词的查询中，混合检索比纯向量检索的准确率提升15-25%。

检索-重排-生成机制

完整的RAG查询链路包含三个核心步骤，每个步骤都有明确的技术选型和优化空间。

**第一阶段：向量检索（Retrieval）负责从海量文档中快速召回候选集。这一阶段追求召回率（Recall）**而非精确率，目标是”不漏掉相关文档”。通常召回Top-20到Top-100候选，为后续精排提供素材。检索阶段的优化重点包括：

• 查询重写（Query Rewriting）：用户原始查询可能表述模糊，使用LLM扩展同义词、消除歧义。例如，“Apple”可以扩展为”苹果公司 OR Apple Inc OR AAPL”。
• HyDE（Hypothetical Document Embeddings）：生成一个假设的理想答案，用该答案的向量而非原始查询向量进行检索。在查询较短或抽象时效果显著，可提升召回率10-20%。
• 多向量检索（Multi-Vector Retrieval）：使用多个查询向量并行检索，融合结果。适用于需要跨段落推理的复杂查询。

**第二阶段：重排序（Reranking）**使用更强大的模型对候选文档精排。与检索阶段的轻量级模型（如384维的all-MiniLM）不同，Reranker通常使用更大的交叉编码器（Cross-Encoder）模型，直接计算查询与文档的交互特征。

Reranker模型的优势在于：

• 更高的准确性：在MS MARCO等基准上，好的Reranker比双编码器（Bi-Encoder）提升10-15%的nDCG@10。
• 动态交互：交叉编码器可以看到查询和文档的完整交互，而双编码器是独立编码后计算相似度。
• 细粒度匹配：可以捕捉token-level的匹配信号，对关键词对齐更敏感。

代价是计算成本高：重排序100个候选的成本可能是向量检索的10-50倍。因此实践中通常召回Top-20后只重排序Top-K（如5-10个）。

flowchart LR
    A[用户查询] --> B[Embedding编码]
    B --> C[向量检索<br/>召回Top-20]
    
    C --> D[重排序模型]
    D --> E[精排Top-5]
    
    E --> F[上下文组装]
    F --> G[Prompt构建]
    G --> H[LLM生成]
    
    H --> I[最终答案]
    
    style C fill:#f59e0b,color:#fff
    style D fill:#4f46e5,color:#fff
    style H fill:#10b981,color:#fff

第三阶段：上下文组装与生成将筛选后的文档组织为Prompt，调用LLM生成答案。这一阶段的关键决策包括：

• 上下文长度分配：LLM的上下文窗口有限（如GPT-4o为128K Token），需要在”更多文档”和”每个文档更完整”之间权衡。研究表明，对于问答任务，提供3-5个高质量文档比提供20个文档效果更优。
• 提示词工程：系统提示（System Prompt）需要明确指导模型如何使用检索到的上下文，包括引用格式、不确定时的处理策略（承认不知道 vs 推测）。
• 引用溯源：先进的RAG系统会要求模型在答案中标注引用来源（如[1][2]），并对应到具体文档片段，增强答案的可信度和可验证性。

架构演进：从Naive RAG到Advanced RAG

RAG架构经历了从简单到复杂的演进，形成了Naive RAG、Advanced RAG、Modular RAG三个阶段。

Naive RAG是最基础的实现：文档直接分块、使用通用Embedding模型编码、向量检索后拼接上下文调用LLM。这种方案30分钟即可搭建原型，但在生产环境中面临诸多问题：检索不准确（约60-70%的问答正确率）、上下文冗长导致生成质量下降、无法处理复杂推理。

Advanced RAG引入了多项优化技术，是目前生产环境的主流方案：

• 预检索优化：查询重写、HyDE、多跳检索规划。
• 后检索优化：重排序、上下文压缩、信息去重。
• 索引优化：混合索引（向量+关键词）、元数据过滤、多级索引结构。

实践表明，从Naive RAG升级到Advanced RAG可以将问答准确率从65%提升至80-85%，同时将延迟控制在可接受范围（<2秒）。

Modular RAG代表了更灵活的架构范式，将RAG流程拆解为独立的模块，支持动态组合。LangChain、LlamaIndex等框架提供了丰富的组件库，开发者可以根据需求选择检索器、重排序器、生成器。更激进的方案使用Agent架构，让LLM自主决定检索策略（检索几次、是否切换关键词、是否查询外部API）。

flowchart TD
    A[Naive RAG] --> B[Advanced RAG]
    B --> C[Modular RAG]
    
    A --> A1[直接分块]
    A --> A2[通用模型]
    A --> A3[单次检索]
    
    B --> B1[语义分块]
    B --> B2[领域模型]
    B --> B3[多路召回]
    B --> B4[重排序]
    
    C --> C1[模块化组件]
    C --> C2[动态路由]
    C --> C3[Agent规划]
    C --> C4[多模态融合]
    
    style A fill:#ef4444,color:#fff
    style B fill:#f59e0b,color:#fff
    style C fill:#10b981,color:#fff

从成本效益角度，建议大多数团队从Advanced RAG起步，在验证业务价值后再考虑Modular RAG的复杂架构。过早引入Agent等复杂机制会增加调试难度，且收益不一定与投入成正比。