RAG 核心：Embedding、向量检索与 Rerank
什么是 RAG？
RAG（Retrieval-Augmented Generation，检索增强生成）是大模型应用的核心架构。它通过"检索+生成"的两阶段模式，让 AI 能够利用私有知识库回答问题，而不是仅依赖模型内部的训练数据。
典型的 RAG 流程如下：
用户查询 → 向量检索（召回）→ Rerank（重排）→ LLM 生成 → 最终回答本文将深入解析这个流程中的三个核心技术：Embedding 向量编码、向量检索召回和 Rerank 重排。
一、Embedding 向量编码
1.1 什么是 Embedding？
Embedding 是将文本转换为稠密向量（dense vector）的技术。在向量空间中，语义相似的文本距离更近。
例如：
- “苹果手机” 和 “iPhone” → 向量距离很近
- “苹果手机” 和 “苹果股票” → 向量距离较远
1.2 主流 Embedding 模型
| 模型 | 特点 | 适用场景 |
|---|---|---|
| BGE系列 | 开源效果好，中文优化 | 通用场景 |
| OpenAI text-embedding-3 | 商用最强，支持长文本 | 高精度需求 |
| Perplexity e5-mistral | 内存占用低，效果接近大厂 | 资源受限场景 |
| Jina AI Jina-embeddings | 开源支持 8K 上下文 | 长文档 |
1.3 MTEB 基准测试
评估 Embedding 模型的主要指标是 MTEB（Massive Text Embedding Benchmark），覆盖分类、聚类、检索等任务。2024 年的趋势是：开源模型快速追赶商用模型，如 BGE-M3 已达到接近商用水平。
1.4 实战建议
- 中文场景：优先选择 BGE 系列（如 bge-large-zh-v1.5）
- 长文本：选择支持 8K+ 上下文的模型
- 资源受限：考虑量化版本（如 INT8）或小型模型（如 bge-small）
二、向量检索（召回）
2.1 核心流程
向量检索的目标是：从海量文档中找到与查询最相关的 Top K 条结果。
步骤：
- 离线：将文档切分 → 每个 chunk 生成向量 → 存入向量数据库
- 在线：将用户查询转为向量 → 在向量空间中做相似度搜索 → 返回 Top K
2.2 相似度度量
| 方法 | 特点 |
|---|---|
| Cosine 余弦相似度 | 最常用，衡量方向差异 |
| 欧氏距离 | 衡量绝对距离 |
| 点积 | 计算快，但对向量长度敏感 |
2.3 向量数据库
| 数据库 | 特点 |
|---|---|
| Milvus | 开源最成熟，支持多种索引 |
| Qdrant | Rust 实现，性能高，支持过滤 |
| Pinecone | 云服务，托管简单 |
| Weaviate | 支持混合检索 |
| Chroma | 轻量，适合原型 |
2.4 索引优化
向量检索的性能关键在于索引算法：
| 索引 | 特点 | 适用场景 |
|---|---|---|
| HNSW | 精度高，内存占用大 | 小规模高精度 |
| IVF | 精度略低，速度快 | 大规模 |
| PQ | 向量压缩，极省内存 | 超大规模 |
| SCANN | 谷歌开源，平衡好 | 中大规模 |
2.5 混合检索
单一向量检索有时召回不全，业界常用混合检索：
向量检索（语义） + 关键词检索（BM25） → 结果融合- BM25：传统关键词匹配，解决"语义相似但词不匹配"问题
- RRF（Reciprocal Rank Fusion）：对多路检索结果加权融合
研究表明，混合检索能显著提升召回率，尤其对短查询和歧义查询效果明显。
三、Chunk 分块策略
3.1 为什么需要分块？
大模型的上下文窗口有限，且直接 Embedding 长文档会丢失细节。因此需要将文档切成小块（chunk），独立编码后再检索。
3.2 分块策略
| 策略 | 说明 | 优点 | 缺点 |
|---|---|---|---|
| 固定长度 | 按 token/字符数切分 | 简单 | 可能切断语义 |
| 递归分块 | 按段落、句子层级切 | 语义完整 | 实现复杂 |
| 语义分块 | 用模型判断切分点 | 最精准 | 成本高 |
| 父子文档 | 大 chunk 检索，小 chunk 召回 | 兼顾上下文 | 实现复杂 |
3.3 关键参数
- Chunk Size：常见 256-1024 tokens，代码场景常用 512
- Chunk Overlap：重叠 10-20%，避免边界信息丢失
3.4 Contextual Retrieval
Anthropic 2024 年提出的技巧：在 Embedding 前，给每个 chunk 加上上下文摘要，如"This chunk is from Section 3 of the API documentation, describing authentication methods." 能显著提升召回效果。
四、Rerank 重排
4.1 为什么需要 Rerank？
向量检索的局限性：
- 语义近似 ≠ 相关：搜"苹果手机"，“苹果股票"也可能召回
- Embedding 能力有限：无法覆盖所有语义场景
- Top K 精度不够：召回 100 条，top 10 可能混入不相关结果
Rerank 相当于"二次筛选”，用更强的模型重新打分排序。
4.2 两阶段检索架构
向量检索（召回 Top 100）→ Rerank（重排 Top 5-10）→ LLM 生成为什么这样做？成本。向量检索 1 次几毫秒，LLM 一次几百毫秒，Rerank 成本远低于直接用 LLM 检索。
4.3 Rerank 模型
| 模型 | 特点 | 场景 |
|---|---|---|
| BGE-reranker-base | 开源免费，效果好 | 通用 |
| Cohere rerank | 商用最强 | 精度优先 |
| MonoT5 | T5 base 做排序 | 长文档 |
| LLM Rerank | 用 LLM 直接评分 | 复杂查询 |
4.4 Rerank 方案
方案一：直接评分
prompt = f"""
查询：{query}
文档：{doc}
请判断文档对查询的帮助程度，返回 0-10 分。
"""缺点：贵、慢
方案二：Pairwise 排序 让 LLM 对候选文档做二选一，汇总所有结果排序。
方案三：Listwise（最新趋势） 直接给 LLM 整个候选列表，让它输出排序结果。
4.5 实战效果
根据业界经验，Rerank 能带来显著提升：
- Top 5 准确率：从 65% 提升到 85%+
- Top 1 精确度：尤其对语义模糊查询提升明显
五、工程优化实践
5.1 典型 RAG 架构
用户 → 网关 → 预处理（Query rewriting）
→ 向量检索（Milvus + BGE）
→ Rerank（BGE-reranker）
→ LLM 生成（GPT-4 / Claude）
→ 后处理（格式校验）→ 返回5.2 性能优化
- 量化：INT8 量化推理，基本不增加延迟
- 缓存：高频查询结果缓存
- Batch：批量处理提升吞吐
- 异步：检索和生成并行
5.3 效果评估
| 指标 | 说明 |
|---|---|
| 召回率 @K | Top K 中相关文档的比例 |
| 精确率 @K | Top K 中真正相关的比例 |
| MRR | 首个相关结果的排名倒数 |
| NDCG | 综合考虑排名和相关性 |
5.4 Bad Case 优化
建立 bad case 库，按周迭代：
- 收集：用户反馈 + 自动化检测
- 分类：幻觉、格式、知识错误、拒答
- 根因：prompt 问题？知识库问题？模型能力？
- 优化：改 prompt / 调 chunk / 换模型 / 加规则兜底
总结
RAG 系统的核心是检索精度和生成质量的平衡：
- Embedding：选择合适的模型，评估 MTEB 基准
- 向量检索：用混合检索提升召回，注意 chunk 策略
- Rerank：用轻量模型做精排，提升 top 结果相关性
- 迭代优化：建立 bad case 闭环，持续打磨效果
随着大模型能力不断增强，RAG 已成为企业知识管理、智能客服、代码助手等场景的标配技术。掌握这套核心技术栈，能让你在 AI 应用开发中更具竞争力。