这是数学白话系列第十九篇。前面十八篇我们从模型内部一路聊到微调方法Attention 怎么算、位置编码怎么加、Scaling Laws 怎么预测、数据怎么洗、怎么对齐、怎么用 LoRA 微调。这一篇我们走向外部知识注入RAG检索增强生成——让大模型不再依赖记忆而是学会查资料。简单 RAG 的现实 用户问公司2025年Q3营收多少 → 向量检索 Top-5 文档 → 喂给 LLM → 答案根据文档Q3营收为... 听起来很美但现实中你遇到的可能是 ❌ 检索不到关键词不匹配 ❌ 检索到了但不相关语义相似≠语义相关 ❌ 检索到了相关内容但被淹没在噪音里 ❌ 用户问题太模糊系统不知道该查哪类数据 → 简单 RAG 在真实场景的召回率≈30-50% → 加上优化后可提升到 70-85%这篇我们把 RAG 的四层优化拆开Chunk 策略、Embedding 选型、Query 路由、重排序——每一层都能让检索质量上一个台阶。开场RAG 的本质是三问RAG 不是简单的检索生成它是一个系统工程。理解 RAG先理解三个核心问题问题1怎么把大文档切成小片段Chunk 策略 → 切太碎语义被切断 → 切太大噪音太多检索不精准问题2怎么把文字变成向量Embedding 模型 → 向量质量决定检索质量 → 不同模型在不同任务上表现差异巨大问题3用户的查询是原始态怎么翻译成检索语言Query 优化 → 用户那个东西多少钱模糊 → 系统需要查哪个品类、哪个时间范围、哪个地区 → 需要查询路由、查询改写、多角度检索问题4检索回来的几十个文档怎么挑出真正有用的重排序 → 向量检索是粗排快但不准 → 重排序是精排准但慢 → 两阶段缺一不可这四个问题正好对应 RAG 的四层优化。我们逐层深入。第一章Chunk 策略——怎么切才不把语义切断了1.1 Chunk 的本质有损压缩先建立一个根本认知Chunking分块不是简单的切分文本而是 将非结构化长文本 → 压缩成语义可索引单元 → 这是一个有损压缩过程 → 压缩的好坏直接决定检索的上限 类比 把一本500页的教科书拆成5000张知识卡片 → 每张卡片必须是独立的、完整的、可检索的 → 一张卡片说一半用户查到也用不了1.2 Chunk 策略的五级演进从简单到高级Chunk 策略分五个 levelLevel 1固定大小分块Fixed-Size Chunking → 最简单按字符数/Token数切比如每512个Token一块 → 缺点可能把一句话切成两半语义被破坏 → 适用场景快速原型、对质量要求不高 工具LangChain 的 CharacterTextSplitter 参数chunk_size512, chunk_overlap50Level 2递归字符分块Recursive Character Chunking → 当前最常用LangChain 默认 → 按分隔符分层切先按\n\n段落再按\n句子再按字符 → 优点尽量保持语义完整性 → 适用场景通用场景质量与速度平衡 工具RecursiveCharacterTextSplitter 分隔符[\n\n, \n, , ]Level 3基于文档结构的分块Document-Based Chunking → 按 Markdown 标题、HTML 标签、代码函数边界切 → 优点尊重文档的天然结构 → 适用场景有明确结构的文档技术文档、法律条文 工具MarkdownTextSplitter, PythonCodeTextSplitterLevel 4语义分块Semantic Chunking → 不按字符数按语义相似度切 → 算法计算相邻句子的 embedding 相似度低于阈值就切开 → 优点每个块都是语义完整单元 → 缺点需要额外计算 embedding成本高 实现先按句子拆分 → 计算每句 embedding → 相邻句子相似度低于阈值如0.6就切Level 5智能分块LLM-Based / Agentic Chunking → 用 LLM 理解文档动态决定分块边界 → 最智能但也最贵 → 适用场景高价值文档医疗、法律1.3 重叠Overlap一把双刃剑重叠的作用 相邻块之间保留一部分重复内容 → 防止边界信息被切成两半 示例 chunk_size512, chunk_overlap50 → 第1块字符 0-512 → 第2块字符 462-974与第1块重叠50字符重叠的隐性成本常被忽略 → 索引膨胀重叠越多总 chunk 数越多存储× → Embedding 成本每个 chunk 都要算一遍 embedding费用× → 检索延迟候选文档多了去重和重排负担× → 噪音增加同一段话在多个 chunk 里重复LLM 被喂了冗余信息经验法则 chunk_overlap ≈ chunk_size 的 10-20% → 512 sizeoverlap 50-100 是常见配置 → 重叠不是越多越好要在完整性和去重间权衡1.4 进阶Late Chunking 与分层索引Late Chunking后期分块 传统先分块 → 再算 embedding Late Chunking先算整个文档的 embedding → 再分块 → 让每个块继承完整文档的上下文 → 解决分块后语义断裂问题分层索引Hierarchical Indexing 大块parent一个段落/一节 小块child段落里的句子 → 检索时用小块匹配精准 → 返回时把整个大块给 LLM完整上下文 → 两全其美第二章Embedding 模型选型——向量的质量决定检索的上限2.1 Embedding 的作用从文字到数学Embedding 做的事 文本 公司的Q3营收为500万 → 向量 [0.12, -0.34, 0.56, ...] → 一个 768 维或 3072 维的浮点数向量 → 这个向量捕捉了文本的语义 → 相似的文本向量距离近不相似的向量距离远 关键洞察 Embedding 是 RAG 的眼睛 → 眼睛不好再好的检索策略也看不清 → 选对 Embedding 模型是 RAG 的第一要务2.2 怎么选MTEB 榜单与实测MTEBMassive Text Embedding Benchmark → 文本嵌入模型的奥林匹克 → 8 个任务检索/分类/聚类/重排/... → 58 个数据集112 种语言 → 榜单地址huggingface.co/spaces/mteb/leaderboard选型逻辑 1. 看 MTEB 榜单排名 2. 看你关心的是哪个任务RAG 主要看 Retrieval 任务 3. 看模型的语言支持中文英文多语言 4. 看模型的维度维度越高越准但存储和计算成本也越高 5. 看模型的最大输入长度8K32K2.3 主流 Embedding 模型对比┌──────────────────────────┬────────┬────────┬────────┬──────────┬────────────┐│ 模型 │ 维度 │ 输入 │ 语言 │ 成本 │ 适用场景 │├──────────────────────────┼────────┼────────┼────────┼──────────┼────────────┤│ OpenAI text-embedding-3 │ 3072 │ 8191 │ 多语言 │ $0.13/M │ 通用首选 ││ -large │ │ │ │ token │ 英文为主 │├──────────────────────────┼────────┼────────┼────────┼──────────┼────────────┤│ OpenAI text-embedding-3 │ 1536 │ 8191 │ 多语言 │ $0.02/M │ 成本敏感 ││ -small │ │ │ │ token │ 大规模索引 │├──────────────────────────┼────────┼────────┼────────┼──────────┼────────────┤│ BGE-M3BAAI │ 1024 │ 8192 │ 100 │ 开源免费 │ 中文首选 ││ │ │ │ 语言 │ 本地部署 │ 多语言 │├──────────────────────────┼────────┼────────┼────────┼──────────┼────────────┤│ BGE-small-zh-v1.5 │ 512 │ 512 │ 中文 │ 开源免费 │ 中文轻量 ││ │ │ │ │ 本地部署 │ 资源受限 │├──────────────────────────┼────────┼────────┼────────┼──────────┼────────────┤│ Gemini Embedding 2 │ 3072 │ 2048 │ 5模态 │ API │ 多模态 ││ │ │ │ 100语 │ │ 文本/图像 │├──────────────────────────┼────────┼────────┼────────┼──────────┼────────────┤│ Jina Embeddings v4 │ 1024 │ 8192 │ 多语言 │ API/开源 │ 检索优化 ││ │ │ │ │ │ 长文本 │└──────────────────────────┴────────┴────────┴────────┴──────────┴────────────┘2.4 BGE-M3中文场景的王牌BGE-M3BAAI 2024清华中科院 三大M M1Multi-Linguality多语言→ 支持 100 语言 M2Multi-Functionality多功能→ 稠密检索 稀疏检索 多向量检索 M3Multi-Granularity多粒度→ 句子/段落/篇章都能处理 关键特性 → 输入长度8192 token是很多模型的 2-4 倍 → 训练数据1.2 亿文本对194 种语言 → 混合检索Dense稠密 Sparse稀疏 Multi-Vector多向量 → 三种检索方式融合效果显著优于单一方式 为什么是中文首选 → 在中文检索任务C-MTEB上表现优异 → 开源免费可本地部署 → 支持长文本8K 输入2.5 维度可裁剪Matryoshka EmbeddingsOpenAI text-embedding-3 系列的黑科技 你可以指定输出的维度 → text-embedding-3-large 默认 3072 维 → 但你可以裁剪到 256 维、512 维、1024 维... 为什么能裁剪 → 训练时用了俄罗斯套娃损失函数Matryoshka → 前面的维度保留了最核心的语义 → 后面的维度是补充细节 裁剪的好处 → 存储3072 维 → 256 维存储降 12 倍 → 检索速度向量越短计算越快 → 效果损失从 3072 降到 256性能仅降 5-10% 适用场景 → 存储敏感、检索量大、对精度要求不极致第三章Query 路由与改写——用户的模糊提问怎么变成精准检索3.1 Query 的三大痛点痛点1用户问题太短、太模糊 用户那个东西多少钱 → 系统哪个东西哪个品类哪个地区哪个时间痛点2用户问题与文档的语言风格不匹配 用户怎么让模型跑得更快口语化 文档模型推理优化技术综述专业术语 → 语义相似但字面不匹配向量检索可能miss痛点3用户问题需要查多个数据源 用户对比一下Q3和Q4的营收趋势 → 需要查 Q3 数据、Q4 数据、趋势分析三个方向 → 单次检索无法覆盖3.2 Multi-Query一个变五个召回率翻倍Multi-Query多查询检索 让 LLM 把用户的原始问题生成 5 个不同角度的改写版本 原始问题公司的Q3营收情况 生成变体 1. 2025年第三季度公司财务收入数据 2. Q3季度营收同比增长率 3. 第三季度主营业务收入明细 4. 2025年9月财务报表营收部分 5. 公司Q3收入构成分析 流程 原始问题 → LLM 生成 5 个变体 → 对 6 个问题分别检索 → 合并结果 → 去重 → 重排序 效果 → 召回率提升 20-40% → 覆盖了不同的表达方式、不同的关键词 代价 → 检索次数 × 6 → 延迟增加 → 需要合并和去重3.3 HyDE先想象答案再检索HyDEHypothetical Document Embeddings 核心思想用户的问题与文档的答案在语义空间里有鸿沟 → 问题的 embedding ≠ 答案的 embedding → 但假设的答案与真实答案在语义空间里很接近 流程 1. 用户问题公司的Q3营收增长原因是什么 2. LLM 生成一个假设答案可能包含错误但语义结构是对的 公司Q3营收增长主要得益于1新产品线发布销售额增长30%2海外市场拓展... 3. 把假设答案向量化 4. 用假设答案的向量去检索真实文档 为什么有效 → 假设答案的语言风格与真实文档一致都是陈述句 → 假设答案包含了关键实体Q3、营收、增长 → 弥合了问题-文档的语义鸿沟 适用场景 → 用户问题太短、太模糊 → 问题与文档的表达风格差异大 → 长尾问题冷门问题 风险 → 如果假设答案完全跑偏可能引入噪音 → 需要额外的 LLM 调用成本3.4 Query Decomposition复杂问题拆解Query Decomposition查询分解 把复杂问题拆成多个子问题分别检索再综合回答 原始问题对比一下公司和竞品在2024年的市场表现 拆解 子问题1公司2024年市场份额 子问题2竞品A 2024年市场份额 子问题3竞品B 2024年市场份额 子问题42024年市场增长率 流程 原始问题 → LLM 拆解 → 对每个子问题检索 → 合并结果 → 综合回答 适用场景 → 对比类问题 → 多条件查询 → 需要综合多个信息源的问题3.5 Semantic Router智能路由不同问题走不同路Semantic Router语义路由器 不是所有问题都走同一条检索路径 示例 用户问题公司最新的股价是多少 → 路由到实时数据 API不是向量库 用户问题公司的核心价值观是什么 → 路由到企业文档向量库 用户问题帮我写一段营销文案 → 路由到直接让 LLM 生成不需要检索 实现方式 1. LLM-based Router让 LLM 看着问题选择最合适的工具 2. Semantic Router定义多个路由模板用 embedding 相似度匹配 Semantic Router 的优势 → 不需要 LLM用向量匹配代替 LLM 决策 → 快毫秒级路由决策 → 可扩展新增路由只需加模板不用改逻辑第四章重排序——粗排之后再来一次精排4.1 为什么需要 Rerank向量检索的局限向量检索Bi-Encoder的本质 → 把 Query 和 Document 分别编码成向量 → 计算 Query 向量与 Document 向量的余弦相似度 → 返回 Top-K 问题 → 编码是独立的Query 和 Document 没有交互 → 只能捕捉粗粒度语义相似性 → 无法捕捉细粒度相关性 例子 Query公司的Q3营收增长率 Document1Q3营收为500万相关但没有增长率 Document2Q2营收增长率15%有增长率但不是Q3 Document3Q3营收同比增长20%最相关 → 向量检索可能把 Document1 排第一语义最接近 → 需要 Rerank 把 Document3 提上来4.2 Rerank 的原理Cross-EncoderCross-Encoder交叉编码器 与 Bi-Encoder 的区别 Bi-Encoder Query → 编码器 → 向量Q Doc → 编码器 → 向量D 相似度 cos(Q, D) Cross-Encoder [CLS] Query [SEP] Document [SEP] → 编码器 → 相似度分数 → Query 和 Document 拼成一个序列一起输入模型 → 模型内部有交互Self-Attention 让 Query 和 Doc 的词互相影响 → 输出一个相关性分数不是向量 为什么更准 → Query 和 Document 的每个词都可以交互 → 模型可以捕捉细粒度匹配 → 比如 Query 里的Q3和 Document 里的Q3可以精确匹配 为什么不用 Cross-Encoder 直接检索 → 太慢需要对每个文档都跑一遍 Cross-Encoder → 如果库里有 100 万文档每个查询要跑 100 万次模型 → 只适合对候选集Top-50~100做精排4.3 主流 Rerank 模型对比┌──────────────────────┬────────────┬────────┬────────┬──────────┐│ 模型 │ 提供方 │ 语言 │ 部署 │ 特点 │├──────────────────────┼────────────┼────────┼────────┼──────────┤│ BGE-Reranker-v2-M3 │ BAAI │ 多语言 │ 本地 │ 中文首选 ││ │ │ │ │ 开源免费 │├──────────────────────┼────────────┼────────┼────────┼──────────┤│ Cohere Rerank │ Cohere │ 多语言 │ API │ 商用首选 ││ │ │ │ │ 效果稳定 │├──────────────────────┼────────────┼────────┼────────┼──────────┤│ bge-reranker-large │ BAAI │ 中文 │ 本地 │ 中文优化 ││ │ │ │ │ 性能强 │├──────────────────────┼────────────┼────────┼────────┼──────────┤│ ColBERTv2 │ Stanford │ 英文 │ 本地 │ 高效 ││ │ │ │ │ 可扩展 │└──────────────────────┴────────────┴────────┴────────┴──────────┘4.4 Rerank 在 RAG 流程里的位置完整 RAG 流程 用户提问 ↓ Query 改写/路由可选 ↓ 向量检索Bi-Encoder召回 Top-50~100← 粗排快 ↓ RerankCross-Encoder精排 Top-5~10 ← 精排准 ↓ 把 Top-5 文档喂给 LLM ↓ LLM 生成答案 两阶段检索的本质 → 粗排从海量数据里快速筛选可能相关的 → 精排从候选集里挑出真正相关的 → 粗排精排 召回率 精确率4.5 RAG-Fusion多路检索 RRF 融合RAG-FusionRAG 融合 把 Multi-Query 和 Rerank 结合再加一个融合算法 流程 1. 原始问题 → LLM 生成 5 个变体 2. 对 6 个问题分别向量检索各返回 Top-10 3. 用 RRFReciprocal Rank Fusion合并多个结果列表 4. 对合并后的 Top-20 做 Rerank 5. 返回 Top-5 RRF倒数排名融合 对每个文档计算其在多个列表里的排名倒数之和 score(doc) Σ 1/(k rank_i) → k 通常取 60 → 排名越靠前分数越高 → 在多个列表里都出现的文档会被加权 效果 → 比单次检索召回率提升 30-50% → 比单纯的 Multi-Query 效果更好因为有融合和重排序尾声RAG 不是魔法是系统工程回到开场的三个问题收个尾问题1怎么切文档 → 从固定大小到语义分块到智能分块 → 选型通用场景用 Recursive专业文档用 Document-Based问题2怎么选 Embedding → 看 MTEB 榜单看任务类型看语言支持 → 中文首选 BGE-M3英文/通用选 OpenAI text-embedding-3问题3怎么优化查询 → Multi-Query 扩召回HyDE 弥合语义鸿沟Decomposition 拆复杂问题 → Semantic Router 智能分路问题4怎么精排结果 → 向量检索 Cross-Encoder Rerank → BGE-Reranker 或 Cohere RerankRAG 的本质 不是检索生成这么简单而是一个多层优化的系统工程 每一层都能提升 10-30% → 四层叠加就是质的飞跃 但每一层也都有成本 → 更复杂的分块、更好的 Embedding、更多的 LLM 调用、更慢的重排序 → 需要在效果和成本间找平衡 这就是 RAG 系统设计的艺术。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 RAG系统设计：超越简单检索，四层优化的技术全景
这是数学白话系列第十九篇。前面十八篇我们从模型内部一路聊到微调方法Attention 怎么算、位置编码怎么加、Scaling Laws 怎么预测、数据怎么洗、怎么对齐、怎么用 LoRA 微调。这一篇我们走向外部知识注入RAG检索增强生成——让大模型不再依赖记忆而是学会查资料。简单 RAG 的现实 用户问公司2025年Q3营收多少 → 向量检索 Top-5 文档 → 喂给 LLM → 答案根据文档Q3营收为... 听起来很美但现实中你遇到的可能是 ❌ 检索不到关键词不匹配 ❌ 检索到了但不相关语义相似≠语义相关 ❌ 检索到了相关内容但被淹没在噪音里 ❌ 用户问题太模糊系统不知道该查哪类数据 → 简单 RAG 在真实场景的召回率≈30-50% → 加上优化后可提升到 70-85%这篇我们把 RAG 的四层优化拆开Chunk 策略、Embedding 选型、Query 路由、重排序——每一层都能让检索质量上一个台阶。开场RAG 的本质是三问RAG 不是简单的检索生成它是一个系统工程。理解 RAG先理解三个核心问题问题1怎么把大文档切成小片段Chunk 策略 → 切太碎语义被切断 → 切太大噪音太多检索不精准问题2怎么把文字变成向量Embedding 模型 → 向量质量决定检索质量 → 不同模型在不同任务上表现差异巨大问题3用户的查询是原始态怎么翻译成检索语言Query 优化 → 用户那个东西多少钱模糊 → 系统需要查哪个品类、哪个时间范围、哪个地区 → 需要查询路由、查询改写、多角度检索问题4检索回来的几十个文档怎么挑出真正有用的重排序 → 向量检索是粗排快但不准 → 重排序是精排准但慢 → 两阶段缺一不可这四个问题正好对应 RAG 的四层优化。我们逐层深入。第一章Chunk 策略——怎么切才不把语义切断了1.1 Chunk 的本质有损压缩先建立一个根本认知Chunking分块不是简单的切分文本而是 将非结构化长文本 → 压缩成语义可索引单元 → 这是一个有损压缩过程 → 压缩的好坏直接决定检索的上限 类比 把一本500页的教科书拆成5000张知识卡片 → 每张卡片必须是独立的、完整的、可检索的 → 一张卡片说一半用户查到也用不了1.2 Chunk 策略的五级演进从简单到高级Chunk 策略分五个 levelLevel 1固定大小分块Fixed-Size Chunking → 最简单按字符数/Token数切比如每512个Token一块 → 缺点可能把一句话切成两半语义被破坏 → 适用场景快速原型、对质量要求不高 工具LangChain 的 CharacterTextSplitter 参数chunk_size512, chunk_overlap50Level 2递归字符分块Recursive Character Chunking → 当前最常用LangChain 默认 → 按分隔符分层切先按\n\n段落再按\n句子再按字符 → 优点尽量保持语义完整性 → 适用场景通用场景质量与速度平衡 工具RecursiveCharacterTextSplitter 分隔符[\n\n, \n, , ]Level 3基于文档结构的分块Document-Based Chunking → 按 Markdown 标题、HTML 标签、代码函数边界切 → 优点尊重文档的天然结构 → 适用场景有明确结构的文档技术文档、法律条文 工具MarkdownTextSplitter, PythonCodeTextSplitterLevel 4语义分块Semantic Chunking → 不按字符数按语义相似度切 → 算法计算相邻句子的 embedding 相似度低于阈值就切开 → 优点每个块都是语义完整单元 → 缺点需要额外计算 embedding成本高 实现先按句子拆分 → 计算每句 embedding → 相邻句子相似度低于阈值如0.6就切Level 5智能分块LLM-Based / Agentic Chunking → 用 LLM 理解文档动态决定分块边界 → 最智能但也最贵 → 适用场景高价值文档医疗、法律1.3 重叠Overlap一把双刃剑重叠的作用 相邻块之间保留一部分重复内容 → 防止边界信息被切成两半 示例 chunk_size512, chunk_overlap50 → 第1块字符 0-512 → 第2块字符 462-974与第1块重叠50字符重叠的隐性成本常被忽略 → 索引膨胀重叠越多总 chunk 数越多存储× → Embedding 成本每个 chunk 都要算一遍 embedding费用× → 检索延迟候选文档多了去重和重排负担× → 噪音增加同一段话在多个 chunk 里重复LLM 被喂了冗余信息经验法则 chunk_overlap ≈ chunk_size 的 10-20% → 512 sizeoverlap 50-100 是常见配置 → 重叠不是越多越好要在完整性和去重间权衡1.4 进阶Late Chunking 与分层索引Late Chunking后期分块 传统先分块 → 再算 embedding Late Chunking先算整个文档的 embedding → 再分块 → 让每个块继承完整文档的上下文 → 解决分块后语义断裂问题分层索引Hierarchical Indexing 大块parent一个段落/一节 小块child段落里的句子 → 检索时用小块匹配精准 → 返回时把整个大块给 LLM完整上下文 → 两全其美第二章Embedding 模型选型——向量的质量决定检索的上限2.1 Embedding 的作用从文字到数学Embedding 做的事 文本 公司的Q3营收为500万 → 向量 [0.12, -0.34, 0.56, ...] → 一个 768 维或 3072 维的浮点数向量 → 这个向量捕捉了文本的语义 → 相似的文本向量距离近不相似的向量距离远 关键洞察 Embedding 是 RAG 的眼睛 → 眼睛不好再好的检索策略也看不清 → 选对 Embedding 模型是 RAG 的第一要务2.2 怎么选MTEB 榜单与实测MTEBMassive Text Embedding Benchmark → 文本嵌入模型的奥林匹克 → 8 个任务检索/分类/聚类/重排/... → 58 个数据集112 种语言 → 榜单地址huggingface.co/spaces/mteb/leaderboard选型逻辑 1. 看 MTEB 榜单排名 2. 看你关心的是哪个任务RAG 主要看 Retrieval 任务 3. 看模型的语言支持中文英文多语言 4. 看模型的维度维度越高越准但存储和计算成本也越高 5. 看模型的最大输入长度8K32K2.3 主流 Embedding 模型对比┌──────────────────────────┬────────┬────────┬────────┬──────────┬────────────┐│ 模型 │ 维度 │ 输入 │ 语言 │ 成本 │ 适用场景 │├──────────────────────────┼────────┼────────┼────────┼──────────┼────────────┤│ OpenAI text-embedding-3 │ 3072 │ 8191 │ 多语言 │ $0.13/M │ 通用首选 ││ -large │ │ │ │ token │ 英文为主 │├──────────────────────────┼────────┼────────┼────────┼──────────┼────────────┤│ OpenAI text-embedding-3 │ 1536 │ 8191 │ 多语言 │ $0.02/M │ 成本敏感 ││ -small │ │ │ │ token │ 大规模索引 │├──────────────────────────┼────────┼────────┼────────┼──────────┼────────────┤│ BGE-M3BAAI │ 1024 │ 8192 │ 100 │ 开源免费 │ 中文首选 ││ │ │ │ 语言 │ 本地部署 │ 多语言 │├──────────────────────────┼────────┼────────┼────────┼──────────┼────────────┤│ BGE-small-zh-v1.5 │ 512 │ 512 │ 中文 │ 开源免费 │ 中文轻量 ││ │ │ │ │ 本地部署 │ 资源受限 │├──────────────────────────┼────────┼────────┼────────┼──────────┼────────────┤│ Gemini Embedding 2 │ 3072 │ 2048 │ 5模态 │ API │ 多模态 ││ │ │ │ 100语 │ │ 文本/图像 │├──────────────────────────┼────────┼────────┼────────┼──────────┼────────────┤│ Jina Embeddings v4 │ 1024 │ 8192 │ 多语言 │ API/开源 │ 检索优化 ││ │ │ │ │ │ 长文本 │└──────────────────────────┴────────┴────────┴────────┴──────────┴────────────┘2.4 BGE-M3中文场景的王牌BGE-M3BAAI 2024清华中科院 三大M M1Multi-Linguality多语言→ 支持 100 语言 M2Multi-Functionality多功能→ 稠密检索 稀疏检索 多向量检索 M3Multi-Granularity多粒度→ 句子/段落/篇章都能处理 关键特性 → 输入长度8192 token是很多模型的 2-4 倍 → 训练数据1.2 亿文本对194 种语言 → 混合检索Dense稠密 Sparse稀疏 Multi-Vector多向量 → 三种检索方式融合效果显著优于单一方式 为什么是中文首选 → 在中文检索任务C-MTEB上表现优异 → 开源免费可本地部署 → 支持长文本8K 输入2.5 维度可裁剪Matryoshka EmbeddingsOpenAI text-embedding-3 系列的黑科技 你可以指定输出的维度 → text-embedding-3-large 默认 3072 维 → 但你可以裁剪到 256 维、512 维、1024 维... 为什么能裁剪 → 训练时用了俄罗斯套娃损失函数Matryoshka → 前面的维度保留了最核心的语义 → 后面的维度是补充细节 裁剪的好处 → 存储3072 维 → 256 维存储降 12 倍 → 检索速度向量越短计算越快 → 效果损失从 3072 降到 256性能仅降 5-10% 适用场景 → 存储敏感、检索量大、对精度要求不极致第三章Query 路由与改写——用户的模糊提问怎么变成精准检索3.1 Query 的三大痛点痛点1用户问题太短、太模糊 用户那个东西多少钱 → 系统哪个东西哪个品类哪个地区哪个时间痛点2用户问题与文档的语言风格不匹配 用户怎么让模型跑得更快口语化 文档模型推理优化技术综述专业术语 → 语义相似但字面不匹配向量检索可能miss痛点3用户问题需要查多个数据源 用户对比一下Q3和Q4的营收趋势 → 需要查 Q3 数据、Q4 数据、趋势分析三个方向 → 单次检索无法覆盖3.2 Multi-Query一个变五个召回率翻倍Multi-Query多查询检索 让 LLM 把用户的原始问题生成 5 个不同角度的改写版本 原始问题公司的Q3营收情况 生成变体 1. 2025年第三季度公司财务收入数据 2. Q3季度营收同比增长率 3. 第三季度主营业务收入明细 4. 2025年9月财务报表营收部分 5. 公司Q3收入构成分析 流程 原始问题 → LLM 生成 5 个变体 → 对 6 个问题分别检索 → 合并结果 → 去重 → 重排序 效果 → 召回率提升 20-40% → 覆盖了不同的表达方式、不同的关键词 代价 → 检索次数 × 6 → 延迟增加 → 需要合并和去重3.3 HyDE先想象答案再检索HyDEHypothetical Document Embeddings 核心思想用户的问题与文档的答案在语义空间里有鸿沟 → 问题的 embedding ≠ 答案的 embedding → 但假设的答案与真实答案在语义空间里很接近 流程 1. 用户问题公司的Q3营收增长原因是什么 2. LLM 生成一个假设答案可能包含错误但语义结构是对的 公司Q3营收增长主要得益于1新产品线发布销售额增长30%2海外市场拓展... 3. 把假设答案向量化 4. 用假设答案的向量去检索真实文档 为什么有效 → 假设答案的语言风格与真实文档一致都是陈述句 → 假设答案包含了关键实体Q3、营收、增长 → 弥合了问题-文档的语义鸿沟 适用场景 → 用户问题太短、太模糊 → 问题与文档的表达风格差异大 → 长尾问题冷门问题 风险 → 如果假设答案完全跑偏可能引入噪音 → 需要额外的 LLM 调用成本3.4 Query Decomposition复杂问题拆解Query Decomposition查询分解 把复杂问题拆成多个子问题分别检索再综合回答 原始问题对比一下公司和竞品在2024年的市场表现 拆解 子问题1公司2024年市场份额 子问题2竞品A 2024年市场份额 子问题3竞品B 2024年市场份额 子问题42024年市场增长率 流程 原始问题 → LLM 拆解 → 对每个子问题检索 → 合并结果 → 综合回答 适用场景 → 对比类问题 → 多条件查询 → 需要综合多个信息源的问题3.5 Semantic Router智能路由不同问题走不同路Semantic Router语义路由器 不是所有问题都走同一条检索路径 示例 用户问题公司最新的股价是多少 → 路由到实时数据 API不是向量库 用户问题公司的核心价值观是什么 → 路由到企业文档向量库 用户问题帮我写一段营销文案 → 路由到直接让 LLM 生成不需要检索 实现方式 1. LLM-based Router让 LLM 看着问题选择最合适的工具 2. Semantic Router定义多个路由模板用 embedding 相似度匹配 Semantic Router 的优势 → 不需要 LLM用向量匹配代替 LLM 决策 → 快毫秒级路由决策 → 可扩展新增路由只需加模板不用改逻辑第四章重排序——粗排之后再来一次精排4.1 为什么需要 Rerank向量检索的局限向量检索Bi-Encoder的本质 → 把 Query 和 Document 分别编码成向量 → 计算 Query 向量与 Document 向量的余弦相似度 → 返回 Top-K 问题 → 编码是独立的Query 和 Document 没有交互 → 只能捕捉粗粒度语义相似性 → 无法捕捉细粒度相关性 例子 Query公司的Q3营收增长率 Document1Q3营收为500万相关但没有增长率 Document2Q2营收增长率15%有增长率但不是Q3 Document3Q3营收同比增长20%最相关 → 向量检索可能把 Document1 排第一语义最接近 → 需要 Rerank 把 Document3 提上来4.2 Rerank 的原理Cross-EncoderCross-Encoder交叉编码器 与 Bi-Encoder 的区别 Bi-Encoder Query → 编码器 → 向量Q Doc → 编码器 → 向量D 相似度 cos(Q, D) Cross-Encoder [CLS] Query [SEP] Document [SEP] → 编码器 → 相似度分数 → Query 和 Document 拼成一个序列一起输入模型 → 模型内部有交互Self-Attention 让 Query 和 Doc 的词互相影响 → 输出一个相关性分数不是向量 为什么更准 → Query 和 Document 的每个词都可以交互 → 模型可以捕捉细粒度匹配 → 比如 Query 里的Q3和 Document 里的Q3可以精确匹配 为什么不用 Cross-Encoder 直接检索 → 太慢需要对每个文档都跑一遍 Cross-Encoder → 如果库里有 100 万文档每个查询要跑 100 万次模型 → 只适合对候选集Top-50~100做精排4.3 主流 Rerank 模型对比┌──────────────────────┬────────────┬────────┬────────┬──────────┐│ 模型 │ 提供方 │ 语言 │ 部署 │ 特点 │├──────────────────────┼────────────┼────────┼────────┼──────────┤│ BGE-Reranker-v2-M3 │ BAAI │ 多语言 │ 本地 │ 中文首选 ││ │ │ │ │ 开源免费 │├──────────────────────┼────────────┼────────┼────────┼──────────┤│ Cohere Rerank │ Cohere │ 多语言 │ API │ 商用首选 ││ │ │ │ │ 效果稳定 │├──────────────────────┼────────────┼────────┼────────┼──────────┤│ bge-reranker-large │ BAAI │ 中文 │ 本地 │ 中文优化 ││ │ │ │ │ 性能强 │├──────────────────────┼────────────┼────────┼────────┼──────────┤│ ColBERTv2 │ Stanford │ 英文 │ 本地 │ 高效 ││ │ │ │ │ 可扩展 │└──────────────────────┴────────────┴────────┴────────┴──────────┘4.4 Rerank 在 RAG 流程里的位置完整 RAG 流程 用户提问 ↓ Query 改写/路由可选 ↓ 向量检索Bi-Encoder召回 Top-50~100← 粗排快 ↓ RerankCross-Encoder精排 Top-5~10 ← 精排准 ↓ 把 Top-5 文档喂给 LLM ↓ LLM 生成答案 两阶段检索的本质 → 粗排从海量数据里快速筛选可能相关的 → 精排从候选集里挑出真正相关的 → 粗排精排 召回率 精确率4.5 RAG-Fusion多路检索 RRF 融合RAG-FusionRAG 融合 把 Multi-Query 和 Rerank 结合再加一个融合算法 流程 1. 原始问题 → LLM 生成 5 个变体 2. 对 6 个问题分别向量检索各返回 Top-10 3. 用 RRFReciprocal Rank Fusion合并多个结果列表 4. 对合并后的 Top-20 做 Rerank 5. 返回 Top-5 RRF倒数排名融合 对每个文档计算其在多个列表里的排名倒数之和 score(doc) Σ 1/(k rank_i) → k 通常取 60 → 排名越靠前分数越高 → 在多个列表里都出现的文档会被加权 效果 → 比单次检索召回率提升 30-50% → 比单纯的 Multi-Query 效果更好因为有融合和重排序尾声RAG 不是魔法是系统工程回到开场的三个问题收个尾问题1怎么切文档 → 从固定大小到语义分块到智能分块 → 选型通用场景用 Recursive专业文档用 Document-Based问题2怎么选 Embedding → 看 MTEB 榜单看任务类型看语言支持 → 中文首选 BGE-M3英文/通用选 OpenAI text-embedding-3问题3怎么优化查询 → Multi-Query 扩召回HyDE 弥合语义鸿沟Decomposition 拆复杂问题 → Semantic Router 智能分路问题4怎么精排结果 → 向量检索 Cross-Encoder Rerank → BGE-Reranker 或 Cohere RerankRAG 的本质 不是检索生成这么简单而是一个多层优化的系统工程 每一层都能提升 10-30% → 四层叠加就是质的飞跃 但每一层也都有成本 → 更复杂的分块、更好的 Embedding、更多的 LLM 调用、更慢的重排序 → 需要在效果和成本间找平衡 这就是 RAG 系统设计的艺术。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】