RAG

写在前面 过去一年深度参与了三个生产级 RAG 系统的搭建，从最初的 demo 到稳定服务百万级查询，踩过的坑足够写本书。这里挑几条最有共鸣的经验。 1. 文档切分策略远比你想的重要 很多人直接 RecursiveCharacterTextSplitter 切 500 字一段就完事了，效果当然不好。 真正有效的切分原则： 按语义边界切：标题、段落、列表项是天然分割点。Markdown 文档优先按标题层级切（H1/H2/H3），保留上下文层级 保留元数据：每个 chunk 至少要带：文档来源、章节标题路径、原始位置。检索时这些都是重要信号 重叠策略：chunk 之间保留 10-20% 重叠，避免把关键信息切在边界 chunk 大小自适应：FAQ 类用 200-400 token，技术文档用 500-800 token，叙述性文档用 1000+ token 实测：从"无脑切 500"换到"按 Markdown 标题切 + 携带 H1>H2>H3 路径"，准确率提升约 15%。 2. 单纯向量检索不够，混合检索才是基线 Embedding 擅长语义相似，但对精确匹配（产品代号、人名、专有术语）非常弱。生产环境基本都是混合检索： 最终得分 = α × 向量相似度 + (1-α) × BM25 得分 进阶玩法： 多路召回 + RRF 合并：BM25、向量、ColBERT、关键词扩展各召回一批，用 Reciprocal Rank Fusion 合并 Query 重写：用小模型把用户口语化提问改写成检索友好的形式 HyDE：让 LLM 先针对问题"幻觉"出一个假设答案，用这个假设答案的 embedding 去检索（适合长尾问题） 3. Rerank 是性价比最高的优化点 向量检索召回 50-100 条，再用 Cross-Encoder 模型对这些候选打分排序，只把 Top 5 喂给 LLM。 ...

为什么 Embedding 选型很重要 RAG 系统的天花板在很大程度上由 Embedding 模型决定。Embedding 不准，后面的 Rerank 和生成再厉害也救不回来。 中文场景比英文复杂：词的边界模糊、同义词多、行业术语差异大，对模型的理解力要求更高。 下面整理目前（2026 年初）值得选用的中文 Embedding 模型，按使用场景分类。 通用首选：BGE 系列 智源（BAAI）出品，目前中文 Embedding 的事实标准。 主力型号： bge-large-zh-v1.5：1024 维，1.3GB，通用场景最佳 bge-base-zh-v1.5：768 维，400MB，性能/速度平衡 bge-small-zh-v1.5：512 维，100MB，资源受限场景 特点： C-MTEB 中文榜单长期前列 训练数据覆盖广，开箱即用 HuggingFace、ModelScope 都有，部署友好 典型用法： from sentence_transformers import SentenceTransformer model = SentenceTransformer('BAAI/bge-large-zh-v1.5') embeddings = model.encode(texts, normalize_embeddings=True) 注意：BGE 在做相似度查询时，建议给 query 加前缀 "为这个句子生成表示以用于检索相关文章："，能提升 1-2 个点。 多语言场景：BGE-M3 如果业务有跨语言需求（中英混合查询、跨语言检索），BGE-M3 是最强选择。 核心特点： 同时支持稠密向量、稀疏向量、ColBERT-style 多向量 100+ 语言原生支持 单模型出三种检索信号，下游融合方便 适合场景： 跨境电商、出海业务 中英文混合的技术文档检索 需要多路召回的高级 RAG 系统 高性能选择：GTE 系列 阿里通义出品，性能在某些 benchmark 上反超 BGE。 ...