简介这份 PDF 讲稿围绕 RAG检索增强生成系统的关键技术展开面向大模型应用开发者、算法工程师与信息检索学习者回应大模型幻觉、知识更新滞后、私域数据接入与上下文长度受限等痛点。内容从 Embedding 向量模型讲到 Reranker 重排模型Jina-embeddings-v2 8K 融合约 750Gb 语料训练借助 ALiBi 相对位置偏置实现「Train Short, Test Long」的长度外推向量侧涉及 Bi-Encoder 双塔架构、Mean Pooling以及弱监督数据清洗与强监督三元组构造MSMarco、Natural Questions 等含 Hard Negative Mining并附 MTEB 与长文本召回、聚类评测。资源包共 1 个 PDF 文件约 3.27MB主讲人王峰博士任 Jina AI 研发总监长期负责向量 Embedding 与 Reranker 训练。已有 258 人学习下载适合希望理解 RAG 检索链路底层训练方法与工程取舍的读者。1. RAG 的效果上限通常卡在 Embedding 和 Reranker 这两段很多团队搭 RAG 知识库的顺序是反的先把 LangChain 或某个开源框架跑通接上向量库塞几百篇文档进 pgvector 或 Milvus然后发现回答质量忽好忽坏。调 prompt、换大模型、加 few-shot收益都不明显。真正的问题往往在检索链路的前半段——召回时向量模型没把语义压对召回后几十条候选又原封不动丢给大模型噪声把上下文淹了。RAG 检索增强生成的链路可以粗分成四段分块、Embedding 向量化、向量召回、重排序Rerank。分块决定信息单元的边界Embedding 决定“能不能被召回”Reranker 决定“召回的排不排前面”。这三段任一环节掉链子后面的大模型再强也补不回来。这篇从 Embedding 模型选型和向量化实现讲起走到 Reranker 的部署与融合排序中间给可直接复现的 Python 代码和参数表适合正在做企业知识库、智能客服、Agentic RAG 的工程师对照排查。2. Embedding 模型选型与向量化落地2.1 从 rag 分块到 embedding 的输入构造Embedding 不是“把整篇文档丢进去”就完事。向量模型有最大输入长度常见 512 token长上下文模型能到 8k超长截断会直接丢信息。所以第一步是 rag分块把文档切成 200500 token 的片段块间保留 10%20% 重叠避免语义被切断。分块粒度要和 embedding 模型的能力匹配。语义模型对短文本区分度高块太大反而让向量被主题稀释。我一般按标题层级切Markdown 按##、###切PDF 先按页再按段落切表格单独成块。from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size400, # 目标块大小按 token 近似 chunk_overlap60, # 重叠量约为块大小的 15% separators[\n## , \n### , \n\n, \n, 。], length_functionlen, # 中文可用 len 近似严格应按 tokenizer 计 ) chunks splitter.split_text(raw_markdown)逻辑说明分隔符按优先级从上到下尝试先按二级标题切切不动再降级到段落、句号保证语义块完整。参数说明chunk_size太小会让单块缺上下文太大则让 embedding 向量指向模糊400 是中文技术文档的经验起点chunk_overlap用于保住跨块句子设 0 会丢边界语义。注意length_functionlen对中文是字符数不等于 token 数。用 BGE、GTE 这类模型时按字符估会低估 token建议留 30% 余量。2.2 embedding模型选型开源本地与 API 的取舍选型先问三个问题数据能不能出内网、语种是不是中文为主、检索规模多大。rag必须用api吗不是。数据敏感就走本地开源模型用 Ollama 或 sentence-transformers 直接跑对延迟和运维成本敏感、数据可外发的用云端 embedding API。模型类型代表维度适用场景注意点中文开源BGE 系列、GTE 系列768/1024企业知识库、内网需 GPU 或 CPU 量化版多语开源multilingual-e5 类768中英混合语料需加 query/passage 前缀云端 API各厂商 text-embedding1024~3072快速验证、无运维按量计费、有网络依赖微调定制LoRA 微调 embedding模型继承底座垂直领域术语多需构造正负样本对如果是医疗、法律、电力这类术语密集的领域通用 embedding模型 对专有名词区分度差这时 lora微调embedding模型就值得做用「问题-正确段落」构成正样本同批其他段落做负样本在底座模型上加 LoRA 适配层训练成本远低于全参微调。2.3 用 Python 跑通向量化与 pgvector 入库验证阶段我习惯用 sentence-transformers 本地加载避免 API 费用干扰判断。from sentence_transformers import SentenceTransformer import psycopg2, json # 1. 加载本地 embedding 模型 model SentenceTransformer(BAAI/bge-base-zh-v1.5) # 2. 批量编码normalize 后可用内积/余弦 vectors model.encode( chunks, batch_size32, normalize_embeddingsTrue, # 归一化余弦相似度等价内积 show_progress_barTrue, ) # 3. 写入 pgvector conn psycopg2.connect(dsnpostgresql://user:pwdlocalhost:5432/ragdb) cur conn.cursor() cur.execute(CREATE EXTENSION IF NOT EXISTS vector;) cur.execute( CREATE TABLE IF NOT EXISTS kb_chunk ( id BIGSERIAL PRIMARY KEY, content TEXT NOT NULL, embedding vector(768) ); ) for text, vec in zip(chunks, vectors): cur.execute( INSERT INTO kb_chunk (content, embedding) VALUES (%s, %s), (text, json.dumps(vec.tolist())), ) conn.commit()逻辑说明先统一归一化向量后续检索统一用余弦距离避免维度量纲差异。参数说明batch_size32是显存与吞吐的折中显存小降到 8vector(768)必须与模型输出维度一致bge-base-zh 是 768bge-large-zh 是 1024写错维度插入直接报错。检索时用ORDER BY embedding %s::vector LIMIT 20是 pgvector 的余弦距离算子配合归一化向量即可。3. 向量召回与多路检索的融合3.1 把 Top-K 召回从单路扩成多路只做向量召回有个硬伤用户问的是精确编号、产品型号、人名时语义向量反而不如关键词命中准。rag实战里稳定的做法是多路召回——向量路负责语义泛化BM25 或全文索引路负责精确匹配两路结果再合并去重。-- pgvector 语义路 SELECT id, content, 1 - (embedding %s::vector) AS score FROM kb_chunk ORDER BY embedding %s::vector LIMIT 20; -- 全文检索路中文需先配置分词或退化为 ILIKE SELECT id, content, ts_rank(to_tsvector(simple, content), query) AS score FROM kb_chunk, plainto_tsquery(simple, %s) query WHERE to_tsvector(simple, content) query ORDER BY score DESC LIMIT 20;逻辑说明语义路返回 20 条按余弦相似度排序的候选关键词路返回 20 条按词频排序的候选两路在应用层按id合并同一文档被两路都命中的提高权重。参数说明语义路 Top-K 建议 2050太小会漏召回关键词路simple配置对中文效果一般生产环境通常接 jieba 分词后写入tsvector列再建 GIN 索引。注意多路召回的合并如果只做简单拼接语义路的高分候选会被关键词路的噪声稀释最好用加权分数或 RRF倒数排名融合再排一次。3.2 RRF 融合排序的代码实现倒数排名融合不依赖两路分数可比性只吃排名适合向量分和 BM25 分不同量纲的场景。def rrf_fuse(semantic_hits, keyword_hits, k60): 两路召回结果做倒数排名融合 scores {} for rank, doc_id in enumerate(semantic_hits, start1): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank) for rank, doc_id in enumerate(keyword_hits, start1): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank) return sorted(scores.items(), keylambda x: x[1], reverseTrue) fused rrf_fuse([d.id for d in semantic_results], [d.id for d in keyword_results]) top20 [doc_id for doc_id, _ in fused[:20]]逻辑说明每个文档的得分是它在各路中排名的倒数之和排名越靠前贡献越大两路都靠前则得分叠加。参数说明k60是 RRF 论文里的经验平滑值调小会让头部排名差异放大调大会让各路影响趋于平均一般 4080 之间调。融合出 20 条只是候选集还不到给大模型的时候。真正决定最终上下文质量的是下一步 Reranker。4. Reranker 部署与重排序实战4.1 为什么召回了还要 RerankerEmbedding 是双塔结构query 和文档各自编码两者在编码阶段不交互速度快但精度有限所以它适合从百万级里粗筛 Top-K。Reranker 是交叉编码器cross-encoder把 query 和候选文档拼在一起送进模型逐对打分能捕捉细粒度语义交互代价是算得慢。所以标准分工是Embedding 负责召回快、粗Reranker 负责精排慢、准只对 Top-50 候选做重排性能可接受。如果直接把 Reranker 用在全库上响应时间会爆。4.2 开源 Cross-Encoder Reranker 的加载与调用from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-base, max_length512) # pairs 是 (query, 候选文档内容) 的列表 pairs [(query, doc.content) for doc in candidates] scores reranker.predict(pairs, batch_size16) # 按重排分降序取 Top-5 进 prompt ranked sorted(zip(candidates, scores), keylambda x: x[1], reverseTrue) final_docs [doc for doc, _ in ranked[:5]]逻辑说明predict返回每条 pair 的相关性分数分数绝对值不必归一只用于同一 query 内排序。参数说明max_length512要与分块大小匹配块超过 512 token 会被截断batch_size16控制显存占用GPU 上可调到 3264。如果用的是 Dify 这类平台dify rerank text embedding 安装的路径通常在模型供应商配置里本质也是接同一个 cross-encoder 服务或云端 rerank API。4.3 Reranker 的 3 个必调参数参数作用经验取值调错后果召回候选数送入 Reranker 的池子大小3050太小漏掉正确文档太大延迟上升最终 Top-N进 prompt 的文档数38太多引入噪声太少丢上下文分数阈值过滤明显不相关候选按模型分数分布定过高召回空过低噪声回流阈值不能照抄要看自己模型输出的分数分布先用一批标注 query 跑一遍看正确文档的分数落在哪个区间再定线。一般 cross-encoder 分数在 01 之间低于 0.2 的基本可丢。5. 用召回率与 MRR 验证 Reranker 到底有没有用上线前别凭感觉判断。构造一个小的评测集50100 条 query每条人工标注 13 个正确 chunk然后对比加 Reranker 前后的指标。def hit_rate_at_k(retrieved_ids, gold_ids, k): Top-K 中有没有命中正确文档 topk set(retrieved_ids[:k]) return 1.0 if topk set(gold_ids) else 0.0 def mrr(retrieved_ids, gold_ids): 正确文档在返回列表中的倒数排名 for rank, doc_id in enumerate(retrieved_ids, start1): if doc_id in gold_ids: return 1.0 / rank return 0.0 # 分别对「仅向量召回」和「向量RRFReranker」跑一遍 for name, ids in [(embedding_only, emb_ids), (with_rerank, rerank_ids)]: hr sum(hit_rate_at_k(i, g, 5) for i, g in zip(ids, golds)) / len(golds) m sum(mrr(i, g) for i, g in zip(ids, golds)) / len(golds) print(f{name}: HitRate5{hr:.3f}, MRR{m:.3f})逻辑说明HitRate5看正确文档有没有进前五衡量召回覆盖MRR看正确文档排得多靠前衡量排序质量。Reranker 的主要收益通常体现在 MRR 上——正确文档从第 8 位提到第 1 位HitRate 可能变化不大但大模型拿到的上下文质量明显提升。参数说明gold 集要覆盖三类难例用术语精确匹配的、语义改写提问的、需要跨块推理的只测简单问句会高估效果。如果加 Reranker 后 MRR 反而降了先查是不是候选池太小正确文档压根没被召回Reranker 无从发力再查是不是重排模型和 embedding 模型语种不匹配。这套验证流程跑通之后Embedding 选型、多路召回、Reranker 精排三段的收益就能各自量化后面再上 Ontology RAG、Graph RAG 或 Agentic 路由也能分清是哪一段带来的提升。本文还有配套的精品资源点击获取
