RAG 检索不再靠玄学BGE 文本嵌入实战指南【免费下载链接】FlagEmbeddingRetrieval and Retrieval-augmented LLMs项目地址: https://gitcode.com/GitHub_Trending/fl/FlagEmbedding向量库建好了查出来的却全是废话——问题多半出在检索这一环。BGE 把文本嵌入、重排、微调、评测打包成一套工具专治 RAG 里搜不准。读完你能跑通第一条可用的检索链路。RAG 向量检索链路文档先切块编码成向量查询走同一条编码路径相似度召回后交给 LLM 生成。50 页 PDF 塞进向量库为什么搜不到重点你搭了个 demoPDF 切开、塞进向量库、提问回一段看着相关、其实没用的段落。原因常见两条嵌入模型有效上下文只有 512 token长段落被截断关键信息根本没进向量又只用了密集检索——向量擅长语义、不擅长专名和报错码语义相近但事实错误的段落容易压过正确答案。BGE 就是针对检索这一环的工具集推理、微调、评测各一套入口分别在 examples/inference/、examples/finetune/、examples/evaluation/。模型分三族bge-*-v1.5 基础系列small/base/large384/768/1024 维中英文分开、多语言多功能的 BGE-M3、cross-encoder 重排系列。BGE 工具集全景嵌入与重排的推理、微调、评测都在同一套框架里各研究方向挂在 research 目录下。8192 token 上下文到底意味着什么长文档要不要切先定长文本切不切。v1.5 系列固定 512 token长文必须自己切块切点一刀下去如表 3 所述这类跨段指代两半都不完整。BGE-M3 支持最长 8192 token 输入、输出 1024 维整篇技术文档、长问答记录可以原样进模型没有边界问题。代价是长输入推理更慢、显存更吃。语料是百万级短问答时全走 M3 长上下文纯属浪费。实操口径文档普遍几千字、语义跨段 → M3 不切或粗切文档短、吞吐优先 → bge-small/base-*-v1.5。M3 在长文档检索MLDR等场景下的表现覆盖 13 种语言、从短句到长文档的不同粒度。密集、稀疏、混合你的数据该走哪条路一句话区分密集检索把文本变成向量比语义改写换说法也搜得到但对专名、编号、报错码是弱项稀疏检索接近 BM25按词权重打分精确匹配强纯释义反而搜不到。两者互补。M3 的特点是密集、稀疏、多向量ColBERT三种模式同一个模型出encode 一次顺带得到 token 权重等于免费拿了 BM25 式稀疏特征这就是官方 RAG 推荐混合检索 重排的原因——先用 densesparse 把召回做宽再用 cross-encoder 精排 top-k。怎么选按数据特征挑路线数据特征推荐路线专名、编号、报错码多法律/医疗/代码M3 混合检索densesparse 重排纯语义匹配、短问答、吞吐优先单一 densev1.5 即可多语言或跨语言语料BGE-M3基本必选多语言混排检索为什么总翻车v1.5 严格分 zh 和 en 两个模型跨语言检索中文 query 查英文文档没有保障。语料涉及 100 种语言、或至少要中英互查选 BGE-M3它面向 MIRACL、MKQA 这类跨语言基准训练中文 query 查英文文档在设计范围内。代价是 M3 是 large 规模的大模型要上边缘设备或压延迟只能退回单语言的 v1.5 small/base。M3 在多语言检索基准 MIRACL 上与其他模型的对比体现其多语言场景的检索精度。BGE 安装与上手从克隆到第一条向量路径很短克隆安装git clone https://gitcode.com/GitHub_Trending/fl/FlagEmbedding cd FlagEmbedding pip install -e .纯推理装上面就行要微调就加[finetune]extra带 deepspeed 和 flash-attn。首次运行会下载模型权重到 HF 缓存HF_HUB_CACHE控制目录看着像卡住其实只是下载。然后直接跑 examples/inference/embedder/encoder_only/base_single_device.py加载 bge-small-en-v1.5编码两条 query、两条 passage输出一个 2x2 余弦相似度矩阵左上角约 0.79法国首都对Paris is the capital of France.。看到数字对检索的手感就有了。没有 GPU 就把devices改成cpu。一条 RAG 检索链路的数据流嵌入 → 召回 → 重排数据流分三步。建索引切块走encode_corpus向量写进 Faiss 或向量库M3 用户同时拿到稀疏权重可建混合索引。召回query 走encode_queries注意 v1.5 会自动给 query 加指令英文 Represent this sentence for searching relevant passages: 、中文为这个句子生成表示以用于检索相关文章passage 侧不加M3 则完全不需要指令。重排召回 top 20–50交给 bge-reranker-v2-m3 这类 cross-encoder 逐对打分取前 3–5 喂给 LLM。cross-encoder 精度明显高于 bi-encoder但计算量随文档数线性涨只能压在 top-k 上这就是两段式的由来。接自己的数据时重点盯三个参数query_instruction_for_retrievalv1.5 别漏、pooling_method默认 cls别乱改、重排 top-k不是越大越好LLM 上下文也有限。BGE 使用避坑数据格式、难负例与版本兼容训练数据是 jsonl每行一个 dictquery、pos正例列表、neg难负例列表。pos/neg 必须是列表塞单个字符串是最常见的报错来源样例在 examples/finetune/embedder/example_data/retrieval、sts、分类几类都有格式照抄就行。难负例不是摆设。对比学习靠分得开相似但错误的文档负例太简单效果打折。仓库自带 scripts/hn_mine.py默认从检索结果 top 10–210 里挖、每条 query 取 15 个负例微调前先跑一遍。版本上 setup.py 锁了 transformers 4.44.2,6.0.0自行升级容易翻车embedder 与 reranker 的接口也分开前者单文本出向量后者给 (query, passage) 对打分别混用。想深入微调脚本在 examples/finetune/embedder再用 examples/evaluation 里 msmarco、beir 的现成命令验证效果到底涨没涨。先拿你手头那份文档跑一次 baseline把 top-10 准确率记下来再决定要不要微调。入口examples/inference/【免费下载链接】FlagEmbeddingRetrieval and Retrieval-augmented LLMs项目地址: https://gitcode.com/GitHub_Trending/fl/FlagEmbedding创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考