RAG技术分享会：Embedding · Rerank · Eval 全链路初探
最近在公司内部做了一次RAG的技术分享会，从 Embedding 向量表征、Rerank 精排到 Eval 评估体系串了一遍。 同时，会上也有两个非常有意思的问题，我觉得还挺值得说道说道。（见正文2.2和3.1）
分享结束后，我觉得把这套内容整理成文字会更有价值——既能帮助自己沉淀，也方便后续回顾。这篇文章就是我基于那次分享的 PPT，重新梳理出来的一份“从理论到落地”的 RAG 全链路指南。
如果你也在做 AI 问答、知识库检索或者企业级 RAG 系统，甚至单纯对AI感兴趣，希望这篇文章能帮你把整条链路串清楚。
一、RAG 技术全景：从检索到生成的完整链路
RAG（Retrieval-Augmented Generation，检索增强生成）的核心思路很简单：大模型不是全知全能的，它也会“胡说八道”。我们给它外挂一个知识库，让它在回答之前先查资料，再基于查到的内容生成答案。
可以把 RAG 理解成一场开卷考试：学生（大模型）本身有知识储备，但面对专业问题时，先去图书馆（知识库）查资料，然后结合资料作答，这样答案更准确、更可溯源。
一条完整的 RAG 链路通常包括以下 8 个环节：
- 知识输入：接入文档、网页、知识库等多样化数据源，构建原始语料池。
- 文本切分：把长文本按语义或固定长度切成 Chunk（片段），保证内容完整且独立。
- 向量化表征：用 Embedding 模型把文本片段变成高维向量，让机器“读懂”语义。
- 向量存储：把向量写入向量数据库（如 Milvus、PGVector），建立索引供后续检索。
- 检索召回：用户提问也先向量化，然后在向量库中找最相似的 Top-N 片段。
- 排序精排：用 Rerank 模型对召回结果重新打分排序，过滤低相关文档。
- 模型推理：把用户 Query 和精排后的上下文拼接，送入大模型生成回答。
- 答案输出：大模型基于上下文生成准确、可溯源的答案。
这 8 步看似线性，但每一步都直接影响最终效果。接下来我会重点拆解 Embedding、Rerank 和 Eval 这三个关键环节。
二、Embedding 深度解析：文本向量化的核心概念
2.1 什么是 Embedding？
Embedding 的本质是把离散的文本符号映射成连续的高维实数向量。用人话说，就是给每段文本发一张“语义身份证”——在这张身份证上，意思相近的文本会被放到一起，意思无关的文本会被拉开距离。
比如：
- “苹果手机” 和 “iPhone” → 语义极近，向量距离很近
- “苹果手机” 和 “水果苹果” → 语义差异大，向量距离很远
Embedding 让计算机不再只是“看到文字”，而是能在高维空间中“感知语义”。这是现代语义检索、文本聚类、推荐系统的基础。
2.2 语义距离度量：余弦相似度
有了向量之后，怎么判断两段文本有多像？最常用的指标是余弦相似度。
余弦相似度的几何本质是衡量两个向量方向的夹角，而不是它们的长度：
- 夹角越小，余弦值越接近 1，语义越相似
- 夹角为 90°，余弦值为 0，语义无关
- 夹角为 180°，余弦值为 -1，语义相反
公式也很简单：
cosθ = (A · B) / (||A|| × ||B||)
其中 A · B 是点积，||A|| 和 ||B|| 是向量模长。归一化之后，结果严格落在 [-1, 1] 区间。
余弦相似度有几个明显的优势：
- 尺度不变性：不关心文本长短，只关心主题方向。
- 高维有效：在词向量、句向量等高维空间中依然稳定。
- 计算高效：核心是一次点积，复杂度为 O(n)，适合大规模实时检索。
如果说 Embedding 是给文本发了身份证，那余弦相似度就是比对两张身份证上的“相似度分数”。
分享现场有同事追了一个问题，我觉得特别值得展开：既然都是衡量向量夹角，为什么偏偏选余弦（cos）而不是正弦（sin）？ 这问题乍看像钻牛角尖，但顺着它想下去，反而能讲清楚余弦相似度为什么是这套体系里最自然的选择。
第一层是单调性。向量之间的夹角范围是 [0, π]，在这个区间里 y = cos x 是单调递减的，而且斜率足够陡峭——夹角从 0 拉开到 π 的过程中，cos 值会一路从 1 掉到 -1，绝不回头。这就保证了夹角和相似度之间是一一对应的关系：夹角越小越相似，越靠近 1；夹角越大越相反，越靠近 -1。值域 [-1, 1] 也正好契合直觉——正向相关为 1，毫不相干为 0，反向对立为 -1。
换成 y = sin x 就完全是另一回事了。它在 [0, π/2] 先升到峰值 1，再在 [π/2, π] 往下掉回 0，整个区间不单调。也就是说，同一个 sin 值会对应两个不同的夹角，而这两个夹角背后的语义关系可能截然相反。放到 RAG 里就是灾难：同一个 Query 去算相似度，可能同时拿到“高度相关”和“几乎相反”两个互相矛盾的分数，根本排不出一个确定的顺序。再加上 sin 的值域只有 [0, 1]，全是非负数，连“相反语义”这个维度都表达不出来，也和我们心里对“相似度”的直觉对不上。
我顺嘴讲了个段子：假设某个平行世界的程序员不走寻常路，搞出一套叫 ARAG（Alternative RAG） 的系统，非要拿正弦当语义相似度的标准，那场面会相当滑稽——医院诊断机器人对着同一组症状，先算出“很可能是感冒”，紧接着又算出“绝对不是感冒”，两个结论并排输出，自己打自己的脸；搜索引擎分不清“想要”和“不想要”，把意思对立的内容一起顶上来；更糟的是，因为方向信息丢了，系统只能堆一堆额外规则去兜底消歧，检索链路越拉越长，查询速度也跟着慢下来。听起来像笑话，但它恰恰点破了一件事：度量标准不是随便挑的，它直接决定了整个系统讲不讲得通道理。
所以余弦相似度能成为 RAG 的标准度量，靠的不是“看起来高级”，而是几何意义、单调性、值域和计算效率这几条，恰好都对得上语义检索的需要。
2.3 bge-m3：当前最强大的开源嵌入模型之一
在实际选型中，我们用得比较多的是 bge-m3，由北京智源人工智能研究院（BAAI）开源。它的特点是“三多”：多语言、多功能、多粒度。
多语言（Multi-Linguality）
支持 100+ 种语言，训练数据覆盖 194 种语言。中文提问检索英文文档、日文文档找韩文答案，这些跨语言场景都能覆盖。
多功能（Multi-Functionality）
一个模型同时支持三种检索模式：
- Dense 稠密检索：语义级匹配，适合理解查询意图。
- Sparse 稀疏检索：关键词级权重匹配，适合精确命中术语。
- Multi-vector 多向量检索：Token 级细粒度匹配，适合复杂语义对齐。
相当于一个模型干三个模型的活，工程上非常省心。
多粒度（Multi-Granularity）
支持从短句到长文档的全尺度输入，最大上下文长度可达 8192 Tokens，远超传统 512 Tokens 的限制，长文档检索也能吃得消。
为什么选 bge-m3？
| 优势 | 说明 |
|---|---|
| 检索精度高 | 在 MTEB、BEIR 等权威基准上多项指标领先，混合检索模式召回率可提升 10-15% |
| 部署成本低 | 一个模型替代稠密、稀疏、重排三套系统，架构更简单 |
| 中文优化好 | 针对中文语料专项优化，分词边界、语义歧义、专业术语理解更准 |
| 开源生态成熟 | 完全开源可商用，原生支持 Transformers、FlagEmbedding 等框架 |
三、Rerank 精排：检索质量的最后一公里
Embedding 检索快，但它更像“粗筛”——先把可能相关的文档快速捞回来。真正决定答案质量的，是Rerank（重排序） 这一步。
可以把 Rerank 理解为机场安检后的“最后一道复核”：前面已经快速筛查了一遍，现在要把真正可疑的、真正重要的再仔细检查一次，确保进入候机厅（大模型上下文）的人都是高质量的。
在讲 Rerank 之前，同事抛了个很直接的问题：既然 Embedding 已经能算出相似度，那查询时直接取语义相似度最大的 Top-K 拼进 Prompt 不就行了，为什么还要再套一层 Rerank？ 这个问题问到点子上了，因为它正好戳中了“相似度大就等于答案对”这个常见误区。
理论上 Query 和文档的语义相似度越大，确实越有可能藏着答案。但问题在于，用户的问题往往是有侧重的，而 Embedding 比出来的向量相似度，反映的只是“这两段话长得像”，未必是用户真正想要的东西。比如用户问“2026 年 RAG 的最新进展”，重点在时效；可在单纯的 Embedding 排序里，如果其他信息都差不多，排上来的 Top-K 可能全是 2023、2024 年的旧文。对用户来说，这些内容词再像也是无效的——他要的是新，不是像。
而且随着知识库导入的体量越来越大，这类“长得像但答非所问”的噪声会越来越多，光靠 Embedding 这一层越来越扛不住。这就是 Rerank 必须存在的理由：它基于交叉注意力机制，对召回质量做一次精细复核。
这里有个关键区别值得拎出来讲。Transformer 里的自注意力是 Q、K、V 来自同一条序列，本质是“自己看自己”，去捕捉序列内部的依赖关系；而 Rerank 用的交叉注意力，Q 和 K、V 来自不同的序列——Q 来自用户的 Query，K、V 来自候选文档。等于让模型把用户的问题和每篇候选文档逐对地交叉比对，去算它们之间真正的语义契合度，而不只是看谁和谁“长得像”。正是这种跨序列的交叉，让 Rerank 能筛出更符合用户侧重点、更贴合真实意图的答案，而不是被表面相似度带跑。
也正因为它算得这么细、这么深，交叉编码器的成本远高于双塔式的 Embedding 检索，没法对全库跑，只能对初召回的小批量候选做精排——这又正好接回了前面那套两阶段流程。
3.1 Rerank 解决了什么问题？
- 提升精度：用更强的语义理解模型（如 Cross-Encoder）对候选文档精细打分，让最相关的文档排在最前面。
- 过滤噪声：剔除初召回阶段混进来的低相关、语义偏差文档，净化输入给大模型的知识库。
- 平衡效率与效果：初召回保证“快且全”，精排保证“准且优”，两阶段配合避免算力浪费。
3.2 两阶段检索流程
实际生产中，RAG 检索通常是两阶段：
用户 Query
↓
Step 1: 向量初召回（Embedding 检索 Top-100）
↓
Step 2: Rerank 精排（Cross-Encoder 打分，筛选 Top-10）
↓
Step 3: 送入 LLM 生成最终答案
交叉编码器（Cross-Encoder）会把 Query 和候选文档一起输入模型，计算它们之间的深度交互语义匹配度。它的计算成本远高于双塔式的 Embedding 检索，所以无法对全库使用，只能对初召回的小批量候选做精排。
这就是 RAG 检索的经典范式：Embedding 负责“召回”，Rerank 负责“精排”。
四、评估体系：如何量化 RAG 系统效果
没有评估就没有优化。RAG 系统的效果不能只看“感觉不错”，必须建立科学的量化指标体系。
4.1 检索质量评估
| 指标 | 含义 |
|---|---|
| Recall@K | 召回相关文档数 / 总相关文档数，衡量查全率，K 常取 5/10/20 |
| NDCG@K | 归一化折损累计增益，考虑排名位置，越靠前的相关文档权重越高，取值 [0, 1] |
| MRR | 平均倒数排名，关注第一个相关结果的位置 |
| Precision | 召回结果中真正相关文档的占比，衡量查准率 |
Recall@K 是粗召回阶段的核心指标，确保不漏掉关键信息；NDCG@K 是综合评估排序质量的首选指标。
4.2 生成质量评估
- Faithfulness（忠实度）：生成答案中能被检索证据支持的比例，常用 LLM-as-Judge 方法打分。这是衡量大模型是否“胡说八道”的关键指标。
- 相关性：回答是否准确解决了用户的核心问题。
- 完整性：是否覆盖了关键信息点，避免片面或缺失。
- 流畅度：语言表达是否自然通顺，符合人类阅读习惯。
4.3 系统性能评估
- 响应延迟与吞吐：端到端响应时间、系统 QPS。
- 资源占用：内存、GPU 显存消耗。
- 成本控制：单次查询的 Token 消耗与计算成本。
4.4 自动评估 vs 人工评估
- 自动评估：用 Recall、NDCG 等指标或 GPT-5 等大模型自动打分。速度快、可重复、边际成本低；但可能与人类主观感受存在偏差。
- 人工评估：由领域专家打分标注。结果最准确，能真实反映业务需求；但耗时久、成本高，难以大规模常态化执行。
好的评估体系 = 检索质量 + 生成质量 + 系统性能，三者缺一不可。
五、项目演示：全栈 RAG 系统实战
分享的最后，我展示了一个基于 Next.js + AI SDK + pgvector + DeepSeek 的全栈 RAG 演示系统。它集成了知识导入、异步向量化处理、检索增强生成，同时提供完整的可视化流程展示，能直观看到 AI 问答背后的技术实现。(稍后GitHub开源)
主页
RAG演示
5.1 系统主要功能
- 多模态知识导入：支持本地文件上传与文本直接粘贴，自动解析格式。
- 模型动态切换：可在 DeepSeek Flash 与 Pro 版本之间切换，实时对比响应速度与回答质量。
- 全链路技术可视化：从知识录入、文本切分、Embedding 向量化到向量入库，每个节点状态实时可见。
- 检索生成过程还原：直观展示“相似度检索 → 上下文拼接 → LLM 回答生成”的完整闭环。
- 双语交互支持：支持中英文语境切换。
- 异步导入与反馈：大文件处理采用异步机制，实时显示进度条，避免页面阻塞。
- 双格式内容输出：支持 Markdown 富文本与纯文本两种模式。
5.2 技术选型与工程亮点
| 层级 | 选型 | 说明 |
|---|---|---|
| 前端 | Next.js 14 + React 18 + TypeScript + Tailwind CSS + shadcn/ui | 强类型、高性能、组件美观 |
| AI 层 | AI SDK 5 + DeepSeek + BAAI/bge-m3 | 统一接口，语义理解与生成能力强 |
| 数据层 | PostgreSQL + pgvector + Drizzle ORM | 结构化数据与向量检索一体化，类型安全 |
| 文本解析 | unified + remark-parse + remark-gfm | 精准处理 Markdown 等复杂文本结构 |
几个值得关注的工程细节：
- AI SDK 统一接入层：无需手写 HTTP 协议，统一封装模型调用、流式响应与聊天状态管理，模型供应商可无感替换。
- OpenAI 兼容标准化：通过
@ai-sdk/openai-compatible封装 DeepSeek，底层模型灵活可变，上层架构保持稳定。 - 数据库一体化存储：PostgreSQL 同时承担结构化数据与向量检索，不引入外部向量库，降低运维门槛。
- 异步知识导入任务化：大文本导入后台异步执行，前端轮询反馈进度，符合真实业务中长耗时任务的处理逻辑。
- Markdown 结构化切分：基于 AST 语法树，按标题、代码块、列表等语义单元切分，而不是简单按空行分割，显著提升召回相关性。
- 批量 Embedding 优化：使用
embedMany()替代串行处理，配合动态批大小与并发控制，最大化利用计算资源。
六、总结
6.1 一句话总结
RAG 技术的价值不在于单一模型的强大，而在于整个链路的协同优化。从 Embedding 的精准表征，到 Rerank 的精细筛选，再到 Eval 的科学闭环，每个环节的微提升都会汇聚成最终效果的质变，实现工程与智能的完美融合。
6.2 未来展望
- 多模态融合：实现文本、图像、表格、音频的统一检索与理解，打破数据壁垒。
- 端到端优化：检索与生成模型联合训练，不再割裂，提升整体问答的流畅性与准确性。
- 自适应与轻量化：动态选择策略，探索端侧部署方案，兼顾隐私保护与实时响应效率。
RAG = 检索 + 生成 + 工程，三者缺一不可，共同构筑智能问答的完整闭环。
希望这篇文章能帮你把 RAG 的全链路串起来。如果有理解不到位的地方，欢迎在评论区交流。
