🔗 RAG 完整链路：从分块到回答
文档分块 → 向量化 → 检索 → 重排 → 注入 → 生成，每个环节都有优化点。
RAG 在解决什么问题
🎯 大模型的知识短板
大模型知识有截止日期，也不知道你公司的私有文档。它只能靠训练时见过的数据回答，容易编造（幻觉）。
RAG（Retrieval-Augmented Generation，检索增强生成）的解法：先从知识库里检索相关文档，再让模型基于这些文档回答。
🧠 和 Fine-tuning 的区别
Fine-tuning 是改变模型权重（贵、慢、要重新训练）；RAG 是不改模型，只往提示词里注入检索到的上下文。
RAG 快、可解释、好更新——知识一变，重建索引即可，不用重新训练模型。
完整链路：7 步
每环节的关键优化点
📄 ① 分块策略
固定大小滑动窗口、语义分块、递归分块。
切太细语义断，切太粗召回噪。
生产常用 parent-child：小 chunk 检索、大 chunk 生成。
🧮 ② Embedding 模型
考虑维度、成本、语言支持、领域适配。
中文场景选中文专用模型（如 bge-large-zh）。
维度短→chunk 别太大；维度长→chunk 可放宽。
🗄️ ③ 向量数据库
Milvus、Pinecone、Weaviate、Chroma、FAISS。
选型看数据量、并发、是否需要 filter、部署方式（云端/自建）。
🔍 ④ 检索优化六手段
分块策略优化、多路检索（向量+BM25）、Rerank 重排、上下文压缩、查询改写、反馈循环。
层层叠加提升召回和相关性。
| 环节 | 关键优化点 |
|---|---|
| 分块 | 滑动窗口/语义分块/递归分块/parent-child |
| Embedding | 维度·成本·语言支持·领域适配 |
| 向量库 | Milvus/Pinecone/Weaviate/Chroma/FAISS 按需选 |
| 检索 | 多路检索 + Rerank + 上下文压缩 + 查询改写 + 反馈循环 |
常见翻车原因
召回不足
该召的文档没召到——分块太粗、Embedding 选型差、Query 口语化导致相似度低。从分块和检索入口排查。
相关性低
召回来一堆但和问题关系不大——Top-K 太大、没做 Rerank、噪声 chunk 混入。用重排模型精排。
上下文干扰判断
无关 chunk 塞太多，模型被误导、答非所问。上下文压缩 + 控制注入数量。
LLM 幻觉
即使有上下文，模型仍可能编造。用 RAGAs 的 Faithfulness 指标监控。
RAG 完整链路 = 文档分块 → 向量化存入向量库 → 用户问题嵌入 → 检索 Top-K → Rerank 重排 → 注入 Prompt 上下文 → LLM 生成。每环节都有优化点：分块策略、Embedding 选型、向量库选型、检索六手段（多路+Rerank+查询改写等）。常见翻车：召回不足、相关性低、上下文干扰判断、幻觉。
我分离线准备和在线检索两部分说。离线先把文档切成 chunk，每个 chunk 用 Embedding 模型转成向量，存进向量数据库。在线用户提问时，先把问题用同一个 Embedding 模型转成向量，然后去向量库做 ANN 检索，找出最相似的 Top-K 个 chunk，再用 Rerank 模型精排去掉噪声，最后把精排后的内容注入 Prompt，让模型基于这些上下文生成回答。
分块策略是基础，常用滑动窗口、语义分块、递归分块，生产里我比较推荐 parent-child，就是小 chunk 检索、大 chunk 生成，兼顾召回和上下文完整性；Embedding 选型要看维度、成本、语言支持和领域，中文场景要用中文专用模型；向量数据库在 Milvus、Pinecone、FAISS 这些里按数据量和部署方式选；检索这块可以做多路检索，就是向量加 BM25 各召一批再用 RRF 融合，再加 Rerank、查询改写、上下文压缩这些手段层层提升。
我总结四个：一是召回不足，该召的文档没召到，一般是分块太粗、Embedding 选型差、或者 Query 太口语化导致相似度低；二是相关性低，召回来一堆但和问题关系不大，一般是 Top-K 太大或者没做 Rerank；三是上下文干扰，无关 chunk 塞太多，模型被误导答非所问，需要上下文压缩和控制注入数量；四是模型幻觉，即使有上下文还是可能编造，要用 Faithfulness 指标监控。