做了一年 RAG 项目，总结的几条避坑经验

Fri, 10 Apr 2026 00:00:00 +0000

写在前面

过去一年深度参与了三个生产级 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。

2026 年中文 Embedding 模型选型指南

Thu, 12 Mar 2026 00:00:00 +0000

为什么 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。

向量检索 on AI 拾遗笔记