Embedding 模型与文本切块
向量检索系统的效果上限，其实在进数据库之前就决定了：embedding 模型选得对不对、文档切得好不好。这一篇整理模型选型与切块策略——同样是"书上看的 + 梳理"，等我实际调过再补体感。
Embedding 模型在干什么
一句话：把任意长度的文本压成一个定长向量，语义近的向量距离近。
- 模型结构大多是 Transformer 编码器（双塔/bi-encoder 思路）：输入文本 → 输出 768 / 1024 / 1536 维向量
- 训练目标就是"拉近相似文本对、推远无关文本对"，所以出来的向量天然带语义
- query 和文档必须用同一个模型转向量——不同模型的向量空间互不相通，混用等于拿北京的坐标在上海找路（这是我理解的向量系统第一条铁律）
中文模型怎么选（2025 前后的书里信息）
| 模型 | 维度 | 特点 |
|---|---|---|
| bge 系列（BAAI 智源） | 1024 | 开源中文标杆，bge-large-zh-v1.5 起步即用；bge-m3 多语言 + 长文本（8K） |
| gte / text2vec 等开源系 | 768~1024 | 备选，差距不大，跟 MTEB 子榜走 |
| OpenAI text-embedding-3 | 1536 / 3072 | 商用 API，效果稳，数据出境要注意 |
| 国产 API（通义/智谱等） | 1024 量级 | 生态配套方便，合规省心 |
看榜单的方法（书上学到的）：看 MTEB / C-MTEB 的 Retrieval（检索）子榜，别只看总分——总分高不代表检索强。
💡 bge 有个容易漏的细节：检索时 query 要加指令前缀（"为这个句子生成表示以用于检索相关文章："），文档不加——不加前缀召回会掉，这是教程里反复强调的。
文本切块：被低估的效果杀手
向量检索查的是"块"（chunk）不是整篇文档，切块质量直接决定召回质量。书里的经验结论：
- 块太大：一个块里混多个主题，向量语义被"平均"稀释，检索命中率降；塞进 prompt 也费 token
- 块太小：上下文断了，"它支持这个参数"这种指代块成了孤儿，查出来也不知道在说什么
- 常见起点：中文 200~500 字符一块，相邻块重叠 10%~20%（overlap 保上下文）
比"固定长度切"更好的做法（按优先级）：
- 按结构切：Markdown 标题、段落自然边界——语义天然完整
- 带锚点切块：每块前面拼上"所属标题路径"（如
数据库 > MySQL > 索引），孤立小块也有上下文 - 父子块：用小块做检索（精准），命中后返回它的大父块（完整）——两边都要
💡 我的记忆钩子：RAG 效果差先怀疑切块，十次里有六七次的根因在数据预处理，不在向量库参数——这是书里出现频率最高的忠告。
Rerank：便宜又有效的第二级
双塔模型（上面所有 embedding 模型）为了能离线建索引，query 和文档各自独立编码，精度有天花板。Rerank 用交叉编码器（cross-encoder）：把 query 和候选文档拼在一起过模型，精度高一个档次——代价是每一对都要现场算，没法预建索引。
所以标准姿势是两级流水线：
向量检索粗筛 top 50（快，靠 ANN 索引）
↓
rerank 精排取 top 5（准，交叉编码器逐对打分）
↓
塞进 LLM prompt
常用模型：bge-reranker-large 等开源重排器。粗筛放宽到 50~100、精排只留 3~5，是书里常见的配比。
⬅️ 01-相似度与向量索引 🏠 00-数据库 ➡️ 03-RAG 检索增强生成
💬 评论