RAG 索引构建完全指南：数据清洗、分块策略、文档解析与 Embedding 选型 – pd的后端笔记

为什么很多 RAG 系统不是“检索不到”，而是“索引阶段就埋雷了”？

很多团队做 RAG，容易把注意力全放在在线问答阶段：

• 用户怎么提问
• Retriever 怎么召回
• Rerank 怎么排
• LLM 怎么回答

但真正上线后你会发现，很多“检索不准”“答非所问”“幻觉偏多”的问题，根源其实并不在在线链路，而是在更前面的 索引构建阶段：

• 文档解析不完整，表格、标题、代码块全丢了
• 清洗过度，把关键字段、版本号、枚举值一起清掉了
• 分块太粗，模型吃不下；分块太碎，语义断裂
• Embedding 模型选得不合适，中文、长文、术语检索效果都不稳定

所以如果你想真正提升 RAG 检索精度，必须把下面这条链路做扎实：

文档解析 -> 数据清洗与预处理 -> 分块 -> Embedding -> 索引入库

这篇文章就围绕几个高频问题展开：

1. 在 RAG 应用中，为了优化检索精度，数据清洗和预处理怎么做？
2. 什么是 RAG 中的分块？为什么需要分块？
3. 常见的分块策略有哪些？分别有什么区别？
4. 索引流程中的文档解析一般怎么做？
5. 什么是 Embedding 嵌入？
6. 常见的 Embedding 模型有哪些？
7. 选择 Embedding 模型时需要考虑什么？

---

🎯 一、RAG 索引阶段到底在解决什么问题？

先讲一句总纲：

索引阶段的目标，不是把文档“存进去”，而是把文档变成“可被准确召回的知识单元”。

这句话很重要，因为很多人一开始会把索引理解成“做个向量化 + 丢到向量库”。

其实真正难的地方是：

• 文档原始格式很脏
• 知识粒度不统一
• 文本、表格、代码、图片混在一起
• 不同问题需要的上下文粒度不同
• 模型对不同语言、长度、术语风格的适配也不同

如果这些问题在索引时没处理好，后面在线阶段再怎么补救，效果都有限。

可以把它理解成一条知识加工流水线：

你后面检索质量的上限，往往在这里就已经决定了。

---

🚀 二、在 RAG 应用中，为了优化检索精度，数据清洗和预处理怎么做？

1. 为什么清洗和预处理这么重要？

因为原始文档并不是天然适合检索的。

现实里的知识源通常长这样：

• PDF 带页眉页脚、页码、水印
• 网页抓取结果里混着导航栏、广告、按钮文本
• Word 文档格式复杂，标题和正文层级混乱
• 代码文档里混着日志、堆栈、注释、重复示例
• 多版本制度文档里同一内容有多个历史版本

如果这些脏数据直接进入索引，就会带来非常典型的问题：

• query 命中的是页脚而不是正文
• 标题层级丢失，检索不到章节语义
• 重复内容被反复召回，污染上下文
• 旧版本规则和新版本规则一起进 Prompt，造成冲突
• 噪声 token 挤掉了真正有价值的信息

所以，数据清洗和预处理本质上解决的是：

让进入索引的内容更像“知识”，而不是“原始文件残片”。

2. 数据清洗通常清什么？

可以分成 4 类来看。

第一类：格式噪声清洗

主要处理：

• 页眉、页脚
• 页码
• 水印
• 重复导航栏
• HTML 标签噪声
• OCR 误识别残片
• 乱码与非法字符

例如一个 PDF 每页底部都有：

Confidential - Internal Use Only - Page 12

如果不清掉，向量里就会大量重复这些无意义文本，干扰检索。

第二类：内容重复清洗

主要处理：

• 同文档跨页重复段落
• 多文档重复发布内容
• 模板化文本反复出现
• FAQ 中高度重复问法
• 版本归档中的旧副本

这一步对 RAG 很重要，因为重复内容不仅浪费索引空间，还会导致：

• 检索结果被重复 chunk 占满
• Rerank 选择空间变差
• LLM 看到很多相似上下文，误以为它们是“多条独立证据”

第三类：结构标准化

主要处理：

• 标题层级统一
• 列表项还原
• 表格结构恢复
• 代码块边界保留
• 段落合并 / 换行规范化
• 中英文标点、空格、大小写统一

这一步很关键，因为 RAG 检索不只是找“词”，还要保住“结构语义”。

比如：

• H2 标题 -> 正文 -> 子标题
• 函数名 -> 参数说明 -> 示例
• 规则条款 -> 适用范围 -> 特例

如果结构被打平，后面分块就很容易切坏语义。

第四类：检索友好预处理

主要包括：

• 特殊符号保留策略
• 枚举值保留
• 缩写补全
• 同义词映射
• 多语言字段对齐
• 时间、版本、部门等元数据抽取

这里最容易出问题的点是：别过度清洗。

例如这些信息在很多业务问答中都很关键：

• 错误码：ERR_4012
• 接口名：create_payment_intent
• 枚举值：SETTLED、PENDING
• 版本号：v2.3.1
• 配置项：max_connections

如果你把它们当“噪声符号”清掉，检索精度会直接掉一截。

3. 一套比较实用的预处理流程

如果是生产落地，我通常建议按下面顺序处理：

原始文档
  -> 格式解析
  -> 噪声清洗
  -> 段落/标题/表格/代码结构恢复
  -> 重复检测与去重
  -> 元数据提取
  -> 检索友好标准化
  -> 分块

4. 数据清洗里最常见的几个坑

坑点	典型后果
清洗过猛	关键术语、版本号、代码符号被删掉
只清正文，不清元数据	检索时无法做时间/部门/版本过滤
去重太粗暴	合法相似段被误删
结构被打平	分块后语义断裂
OCR 文档不校验	错别字和乱码直接入索引

所以数据清洗不是“越干净越好”，而是：

越有利于检索和回答越好。

---

🧩 三、什么是 RAG 中的分块？为什么需要分块？

1. 什么是分块？

分块（Chunking）就是把一份长文档切分成多个较小的文本单元，每个单元再去做 Embedding 和索引。

例如，一份 50 页的 PDF，不会整体做成一个向量，而是会切成很多 chunk：

• 一段定义
• 一个小节说明
• 一张表格描述
• 一个代码示例
• 一个 FAQ 问答对

也就是说：

分块的目标，是把文档切成既保留语义、又适合检索的最小知识单元。

2. 为什么必须分块？

因为大多数知识源天然都太长，而检索和生成都不适合直接操作整篇原文。

如果不分块，会有几个问题：

• 整篇文档做一个向量，语义太混杂
• 用户只问某个局部问题，但向量表示是全文平均后的结果
• 召回回来的是超长上下文，LLM 不好消费
• 成本高，延迟高，上下文利用率还低

举个例子：

用户只问：

“退款超时时间是多久？”

如果你的文档是一整篇《支付系统设计说明书》，里面同时讲：

• 下单流程
• 支付回调
• 清结算
• 退款
• 对账
• 风控

那么全文向量很可能无法把“退款超时”这个局部语义表达得足够突出。

3. 分块解决了什么核心问题？

分块主要解决 3 件事：

1. 提升召回粒度：让系统召回“段落级知识”，而不是“整本手册”
2. 提升语义纯度：每个向量表达更聚焦
3. 降低 Prompt 污染：只把相关片段送进模型，而不是整篇长文

所以分块其实是连接“原始文档”和“高质量检索”的中间桥梁。

---

📦 四、在 RAG 中，常见的分块策略有哪些？分别有什么区别？

1. 固定长度分块（Fixed-size Chunking）

这是最简单的一类。

比如按：

• 256 tokens
• 512 tokens
• 1024 tokens

来切。

优点

• 实现简单
• 性能稳定
• 容易批处理

缺点

• 容易把完整语义切断
• 可能把标题和正文拆开
• 代码块、表格等结构容易被破坏

适合场景

• 原始文本结构很弱
• 先做 MVP / Demo
• 需要快速验证管线

2. 滑动窗口分块（Sliding Window Chunking）

这是固定长度分块的增强版。

比如：

• chunk size = 500
• overlap = 100

这样相邻 chunk 会保留一部分重叠内容。

优点

• 缓解边界截断问题
• 上下文连续性更好

缺点

• 重复内容更多
• 索引体积更大
• 检索后更需要去重

适合场景

• 文本连续性要求高
• 法务、制度、长说明文档
• 问题容易跨段依赖上下文

3. 按结构分块（Structure-aware Chunking）

按文档天然结构切分，比如：

• 标题
• 段落
• 小节
• 列表
• 表格
• 代码块
• FAQ 对

这是目前生产里非常常见的一类策略。

优点

• 语义边界更自然
• 检索质量通常更高
• 更适合做引用和回溯

缺点

• 依赖文档解析质量
• 对 PDF/OCR 场景要求更高

适合场景

• Markdown、HTML、结构化文档
• 技术文档、知识库、制度文档

4. 语义分块（Semantic Chunking）

让模型或算法根据语义变化点来切，而不是死按字符数或标题。

例如：

• 同一语义主题合在一起
• 主题切换处再断开

优点

• 语义完整性更强
• 对非标准结构文本很有帮助

缺点

• 计算更贵
• 实现复杂度更高
• 稳定性依赖模型与参数

适合场景

• 长篇自然语言文本
• 原始文档结构差但语义流明显

5. Parent-Child 分块

这类策略会保留两层结构：

• 子块（child chunk）负责检索
• 父块（parent chunk）负责回答时回填更完整上下文

也就是说：

• 检索时用更细粒度提高命中率
• 生成时回到更大粒度保证语义完整

优点

• 检索粒度和生成上下文兼顾
• 对长文档效果通常很好

缺点

• 索引设计更复杂
• 需要维护 chunk 之间的父子关系

适合场景

• 长篇技术文档
• 政策文档
• 多章节手册

6. 多模态/类型感知分块

针对不同内容类型使用不同切法，例如：

• 正文按段落切
• 表格按表级别切
• 代码按函数/类切
• FAQ 按问答对切
• 幻灯片按页切

优点

• 最贴近真实内容结构
• 对复杂企业知识库很有价值

缺点

• 工程实现复杂
• 对解析器能力要求高

7. 一张表看懂这些分块策略

策略	核心思想	优点	缺点	适合场景
固定长度	按 token/字符切	简单稳定	容易切断语义	MVP、弱结构文本
滑动窗口	固定长度 + 重叠	连续性更好	重复更多	长文本说明类文档
按结构分块	按标题/段落/表格切	语义自然	依赖解析质量	Markdown、HTML、知识库
语义分块	按语义变化点切	语义完整	成本高	非结构化长文本
Parent-Child	检索细粒度，回答大粒度	兼顾召回和上下文	设计复杂	长文档生产系统
类型感知分块	不同内容不同切法	效果最好	实现复杂	企业复杂知识库

8. 分块没有银弹，关键是匹配文档与问题形态

如果让我给一句经验判断：

结构化文档优先按结构切，长文档优先 Parent-Child，MVP 先用滑窗，复杂企业知识库做类型感知分块。

---

📄 五、在 RAG 中，索引流程中的文档解析你们怎么做的？

1. 什么是文档解析？

文档解析（Document Parsing）就是把各种原始文件，转换成后续可清洗、可分块、可嵌入的中间表示。

输入可能是：

• PDF
• Word
• Markdown
• HTML
• PPT
• Excel
• 图片 / 扫描件
• 代码仓库文件

输出不应该只是“一大坨纯文本”，而应该尽量保留结构信息，例如：

• 标题层级
• 段落边界
• 表格
• 列表
• 代码块
• 图片说明
• 页面号
• 来源路径
• 文档元数据

2. 为什么文档解析不能只做“提取纯文本”？

因为纯文本会丢掉大量对检索很关键的信息。

举几个典型例子：

场景 A：标题层级丢失

原文：

• 4.2 退款规则
  • 4.2.1 普通退款
  • 4.2.2 超时退款

如果被打平成纯文本，后面检索很难知道这些段落属于哪一章节。

场景 B：表格丢失

很多制度、参数说明、字段字典都是表格表达。

如果表格只被拉平成断裂文本，字段和值的对应关系会被破坏。

场景 C：代码块丢失

技术文档里函数名、参数名、配置项、路径，往往都在代码块里。

如果解析时不保留代码边界，后续 chunk 和 embedding 都容易出问题。

3. 一套常见的解析思路

我更推荐把文档解析分成 3 层：

第一层：格式适配层

针对不同文件类型选择不同解析器：

• PDF：文本层 PDF 与扫描版 PDF 分开处理
• Word：优先保留标题、段落、表格
• HTML/Markdown：直接利用 DOM/AST 结构
• Excel：按 sheet + 表结构解析
• PPT：按页 + 标题 + 要点解析
• 图片：OCR + 版面分析

第二层：结构恢复层

统一抽象成中间结构，例如：

{
  "title": "退款规则",
  "section_path": ["支付系统", "退款模块", "超时退款"],
  "content_type": "paragraph",
  "text": "订单支付成功后...",
  "page": 12,
  "source": "payment_spec_v3.pdf"
}

这一步的关键不是“抽出文字”，而是 恢复文档结构语义。

第三层：内容类型细分层

根据内容类型打标签：

• paragraph
• heading
• table
• code
• list
• faq
• caption
• image_ocr_text

后面分块、检索、压缩都可以针对不同类型做差异化策略。

4. 生产里文档解析通常怎么做？

一个实用方案通常是：

上传文档
   ↓
文件类型识别
   ↓
按类型选择解析器
   ↓
输出统一中间结构 JSON
   ↓
结构校验 / OCR 置信度校验
   ↓
清洗与标准化
   ↓
分块与索引

5. 文档解析阶段最容易踩的坑

• 扫描版 PDF 没做 OCR 质量校验
• 表格被硬转纯文本
• 标题层级丢失
• 代码块边界丢失
• 多列排版 PDF 顺序错乱
• 图片里的关键信息完全忽略

所以真正高质量的 RAG 索引系统，往往不是向量库决定的，而是：

你的文档解析是不是把知识原貌尽可能保住了。

---

🧠 六、在 RAG 中的 Embedding 嵌入是什么？

Embedding（嵌入）本质上是：

把文本转换成一组高维数值向量，让机器能够用“距离”来衡量语义相似度。

比如两句话：

• “退款什么时候到账？”
• “退款到账时间是多久？”

虽然字面不完全一样，但语义很接近。Embedding 模型会把它们映射到向量空间中较近的位置。

为什么 RAG 需要 Embedding？

因为用户提问和知识库表达经常不是逐字匹配的。

只靠关键词检索，容易漏掉：

• 同义表达
• 近义表达
• 口语与规范术语映射
• 跨语言表达
• 长尾问法

Embedding 的作用就是：

让检索从“字面匹配”升级成“语义匹配”。

Embedding 在索引流程里的位置

Embedding 不是“压缩摘要”

这一点要特别说明：

• Embedding 不是给人看的
• 它不是摘要
• 它也不是关键词列表

它是模型学习出来的一种 语义表示，后续用来做近邻搜索、聚类、分类、推荐等任务。

---

🔎 七、在 RAG 中，你知道有哪些 Embedding Model 嵌入模型？

这里不追求列全，而是按实际使用最常见的几类来讲。

1. 闭源 API 类代表模型

OpenAI

官方文档里，text-embedding-3-large 被描述为其“most capable embedding model”，适合英文和非英文任务；同时还有成本更低的 text-embedding-3-small。开发者还可以在一定范围内调整向量维度，这对存储成本和召回精度之间的权衡很有帮助。

Voyage AI

Voyage 官方 Embeddings 文档给出了比较完整的产品线，例如：

• voyage-3
• voyage-3-lite
• voyage-multilingual-2
• voyage-code-3
• voyage-law-2
• voyage-finance-2

它们的特点是区分得比较细：

• 通用检索
• 多语言检索
• 代码检索
• 法律领域
• 金融领域
• 不同延迟 / 成本档位

Cohere

Cohere 官方文档中常见的 Embedding 模型包括：

• embed-v4.0
• embed-english-v3.0
• embed-english-light-v3.0
• embed-multilingual-v3.0
• embed-multilingual-light-v3.0

其中 embed-v4.0 还支持文本、图像、混合内容（例如 PDF 截图等）的 embedding，适合文档形态比较复杂的场景。

Jina AI

Jina 的官方 Embedding 文档中，jina-embeddings-v3 是一个很常见的多语言长上下文 embedding 模型，支持 8192 token 长度，并主打多语言检索表现。

2. 开源通用类代表模型

BGE 系列（BAAI）

例如：

• bge-large-en-v1.5
• bge-m3

其中 bge-m3 比较特别，官方模型卡里强调它支持：

• dense retrieval
• sparse retrieval
• multi-vector retrieval
• 100+ 语言
• 最长 8192 token

所以它很适合做混合检索或多语言场景下的实验与生产。

E5 系列

例如：

• multilingual-e5-large
• multilingual-e5-large-instruct

E5 系列在多语言和 instruction-style embedding 上比较常见，尤其适合 query/document 区分比较明确的检索任务。

GTE 系列

现在也有很多团队会使用 GTE（General Text Embedding）系模型，尤其是面向通用文本、多语言、较强开源可用性的场景。

Nomic 系列

如 nomic-embed-text-v1，在开源长文本 embedding 讨论中也经常出现，适合一些需要本地部署、可控性更高的项目。

3. 垂直领域模型

除了通用 embedding 模型，实际项目里还经常会遇到：

• code embedding
• legal embedding
• finance embedding
• biomedical embedding
• multilingual domain embedding

如果你的知识库术语极强、专业性极高，垂直领域 embedding 往往比纯通用模型更稳。

4. 一张表看懂 Embedding 模型类型

类型	代表模型	特点	适合场景
闭源通用	OpenAI / Voyage / Cohere	开箱即用、效果稳、运维省心	业务快速落地
闭源垂直	Voyage Code/Law/Finance 等	领域适配更强	代码、法律、金融
开源通用	BGE、E5、GTE、Nomic	可本地部署、可控性高	私有化、成本敏感场景
开源多功能	BGE-M3	Dense/Sparse/Multi-vector 一体	混合检索、多语言
开源垂直	各类领域微调 Embedding	术语适应更好	行业知识库

这里要特别提醒：

不要执着于“哪个模型最强”，先看它是否匹配你的文档形态、语言分布、部署约束和检索目标。

---

⚙️ 八、在 RAG 中，你如何选择 Embedding Model，需要考虑哪些因素？

这是最重要的问题，因为 Embedding 选型很容易掉进“盲目看榜单”的坑。

1. 先看语言

这是第一优先级。

如果你的知识库是：

• 纯英文
• 中文为主
• 中英混合
• 100+ 语言混合

那适合的模型完全不同。

例如：

• 纯英文可以优先英文优化模型
• 中文 / 多语言场景要优先多语言 embedding
• 跨语言检索更要看 multilingual 能力是否稳定

2. 再看文档长度

不同模型支持的上下文长度差异很大。

如果你的 chunk 常常比较长，或者你希望保留较大段落语义，那么要关注：

• 最大 token 长度
• 超长输入截断方式
• 长文检索效果是否稳定

例如官方资料里：

• OpenAI text-embedding-3-large 常见默认高维输出
• Voyage 有多款 32k context 的 embedding 模型
• Cohere embed-v4.0 支持到 128k 级别上下文
• Jina / BGE-M3 也强调长上下文能力

这对长文档知识库非常关键。

3. 看检索任务类型

不同模型擅长的任务也不同。

你要先问清楚自己在做哪种任务：

• query -> document 检索
• document -> document 相似查找
• FAQ 召回
• 代码检索
• 多语言检索
• 聚类 / 分类

比如 Voyage 文档里就明确区分：

• 通用 retrieval
• multilingual retrieval
• code retrieval
• law / finance retrieval

如果任务本身高度专业化，选专用 embedding 模型通常更合适。

4. 看部署方式与成本

这是工程上绕不开的问题。

选闭源 API 的优点

• 接入快
• 效果通常稳
• 不需要自己维护推理服务
• 容易快速验证业务效果

选开源本地部署的优点

• 数据可控
• 长期成本可控
• 便于私有化与定制化
• 更容易做垂直微调

如果你是：

• 企业私有知识库
• 强合规场景
• 高 QPS 场景
• 大规模离线索引场景

那本地部署和推理成本通常必须进入决策。

5. 看向量维度与存储成本

向量维度不是越高越好。

维度越高通常意味着：

• 单条向量占用更大
• 索引体积更大
• 相似度检索成本更高
• 内存与磁盘压力更大

所以你要平衡：

• 精度
• 延迟
• 存储成本
• 查询吞吐

如果是亿级 chunk 规模，维度选择会直接影响你的基础设施成本。

6. 看 query/document 是否区分编码

有些模型对 query 和 document 使用不同提示模板或不同编码模式，效果会更好。

例如：

• Voyage 官方就建议在检索场景中标明 input_type=query/document
• E5 instruct 类模型也常要求 query 带指令格式

如果你忽略这一点，检索效果可能会白白损失一截。

7. 看评测集是否匹配你的业务

不要只看公开排行榜。

因为很多榜单不一定覆盖你的真实场景：

• 中文 FAQ
• 企业制度问答
• 代码仓库检索
• 带表格参数说明的技术文档
• 长文 / 长 chunk 检索

最靠谱的方式永远是：

用自己的数据做离线评测。

例如评测这些指标：

• Recall@K
• MRR
• NDCG
• 命中率
• 人工相关性打分
• 最终答案质量提升幅度

8. 一套实用的选型思路

如果让我给一个很实用的落地建议，我会这样选：

场景 A：先快速验证业务

优先：

• 闭源稳定 API 模型
• 少量候选模型 AB 测
• 先看召回质量，再考虑成本优化

场景 B：中文 / 多语言知识库

优先：

• 多语言 embedding 模型
• 长上下文支持较好的模型
• 明确看 query/document 检索优化能力

场景 C：私有化、合规、成本敏感

优先：

• 开源 embedding
• 本地可部署模型
• 结合自己的业务数据做评测

场景 D：代码、法律、金融等领域知识库

优先：

• 垂直领域 embedding
• 通用模型 + 领域微调方案

9. 一个选型对比表

维度	要问的问题
语言	主要是中文、英文还是多语言？
文档长度	chunk 是否经常超过 512/1024 token？
任务类型	通用检索还是代码/法律/金融等垂直检索？
部署约束	能否调用外部 API？是否必须私有化？
成本	能接受多高的向量化与检索成本？
吞吐	索引规模和 QPS 多大？
维度	向量维度是否会压垮存储和检索成本？
编码方式	是否支持 query/document 区分？
评测	是否用自己的数据验证过？

一句话总结：

Embedding 模型选型，本质上不是选“最强模型”，而是选“最适合你知识库和检索任务的模型”。

---

🏗️ 九、如果让我设计一条更稳的 RAG 索引流程，我会怎么做？

下面给一条比较实用、生产友好的思路：

1. 按文件类型做解析器路由
   • PDF、Word、Markdown、HTML、Excel、PPT 分开处理
2. 保留结构化中间表示
   • 标题、段落、表格、代码、页码、来源、章节路径都保留
3. 做检索友好清洗
   • 去页眉页脚、去重、标准化，但保留术语、版本号、错误码
4. 按文档类型选分块策略
   • Markdown/HTML 用结构分块
   • 长 PDF 用滑窗或 Parent-Child
   • 复杂知识库做类型感知分块
5. 做元数据增强
   • 时间、部门、版本、知识域、语言、权限标签
6. Embedding 前做抽样评测
   • 不同模型先小样本对比 Recall@K
7. 入库前做质量校验
   • chunk 长度分布、重复率、空块率、OCR 置信度、元数据完整率
8. 上线后持续回流评测
   • 看检索点击、答案引用命中、人工反馈、幻觉率

这条链路看似麻烦，但它会直接决定你的 RAG 系统是不是“稳定可用”。

---

⚠️ 十、最容易踩的几个坑

误区 1：分块越小越好

太小会导致语义断裂，召回看起来很精确，实际上拼不出答案。

误区 2：清洗越狠越好

把术语、代码符号、枚举值、版本号一起清掉，检索会直接失真。

误区 3：只看 Embedding 排行榜

公开 benchmark 不一定代表你的业务效果。

误区 4：文档解析只要抽出纯文本就够了

标题层级、表格、代码块、章节路径，很多时候比纯文本更重要。

误区 5：Embedding 模型只影响召回，不影响回答

错。

召回的本质证据就是由 embedding 决定的，证据错了，后面回答自然更容易幻觉。

---

✅ 十一、面试回答模板

如果面试官问到这几个问题，你可以这样回答：

在 RAG 应用里，索引阶段的核心是把原始文档加工成可被准确召回的知识单元。数据清洗和预处理主要做噪声移除、结构标准化、重复清洗和检索友好增强，比如保留标题层级、表格、代码块、版本号、错误码和元数据。分块则是把长文档切成适合检索的 chunk，常见策略包括固定长度、滑动窗口、按结构切、语义分块、Parent-Child 分块和类型感知分块，不同策略在实现复杂度、语义完整性和检索粒度上各有取舍。文档解析上，生产里通常会先按文件类型选择解析器，再统一输出带结构标签的中间表示。Embedding 本质上是把文本映射成向量，用来做语义检索；模型选择要综合语言、上下文长度、任务类型、部署约束、成本、维度和业务评测结果，而不是只看公开榜单。

这段回答的优点是：

• 把索引链路讲完整了
• 不只讲概念，还讲了工程取舍
• 体现了“检索精度来自索引质量”的视角

---

📌 十二、总结：一句话记住这几个点

1. 数据清洗和预处理在干什么？

把原始文档变成更适合检索的知识材料，而不是简单“清文本”。

2. 什么是分块？

把长文档切成适合 embedding 和检索的语义单元。

3. 为什么需要分块？

因为整篇文档太长、语义太混，既不利于召回，也不利于模型消费。

4. 常见分块策略有哪些？

固定长度、滑动窗口、按结构切、语义分块、Parent-Child、类型感知分块。

5. 文档解析的核心是什么？

不是只抽文字，而是尽量保住结构语义：标题、表格、代码、页码、元数据。

6. Embedding 是什么？

把文本映射成向量，用距离表示语义相似度。

7. 怎么选 Embedding 模型？

先看语言、长度、任务、部署和成本，再用自己的业务数据做评测。

如果你只记一句话，可以记这个：

RAG 检索做得准不准，很多时候不取决于在线 Prompt 写得多漂亮，而取决于你在索引阶段是否把“文档解析、清洗、分块、Embedding 选型”这条链路打磨到位。

---

🔗 参考资料

1. OpenAI text-embedding-3-large 官方模型页
   https://developers.openai.com/api/docs/models/text-embedding-3-large

2. Voyage AI Embeddings 官方文档
   https://docs.voyageai.com/docs/embeddings

3. Cohere Embed Models 官方文档
   https://docs.cohere.com/docs/cohere-embed

4. Jina AI Embeddings 官方文档
   https://jina.ai/embeddings/

5. BAAI bge-m3 官方模型卡
   https://huggingface.co/BAAI/bge-m3

6. multilingual-e5-large-instruct 官方模型卡
   https://huggingface.co/intfloat/multilingual-e5-large-instruct