RAG 系统链路构建:文档切割与转换技术详解
上一篇我们详细拆解了 RAG 系统的文档加载环节,用 PyPDFLoader、WebBaseLoader 等工具搞定了 PDF、网页、Word 等多源数据的加载。但加载后的原始文档往往存在「长度超标」「格式混乱」「信息零散」等问题——500 页的法律合同直接喂给模型会超 token 限制,网页文本混着广告导航栏,产品手册的关键参数散在不同页面……这时候就需要 RAG 链路中的核心环节:文档切割转换来'提纯'数据。
今天这篇就带大家吃透 LangChain 中的文档转换器(Document Transformers),从「为什么要做」到「核心参数怎么调」,再到「不同场景实战」,手把手教你做好 RAG 的数据预处理第一步~
一、先搞懂:为啥 RAG 必须做文档切割转换?
上一篇加载后的文档只是'原始素材',直接用于向量化和检索会踩 3 个大坑,这也是文档切割转换的核心价值所在:
| 核心痛点 | 具体影响 | 解决思路 |
|---|---|---|
| 模型输入 token 限制 | GPT-4 最大 32k tokens、Claude 3 最高 200k,长文档(如 500 页合同)直接输入会 API 报错,或被截断导致信息丢失 | 按模型上下文窗口合理分块,确保每个文本块长度合规 |
| 信息密度不均 & 语义断裂 | 关键信息(如合同条款、产品参数)分散在长文本中,粗暴分割会把完整语义(如一个句子、一个功能模块)拆碎 | 按自然语义边界(段落、句子)分割,保留上下文连贯性 |
| 格式混乱 & 噪音干扰 | 网页文本含广告/导航栏、代码文档混着 Markdown 格式、PDF 有乱码特殊字符,会降低向量检索精度 | 文本清洗去噪 + 格式标准化,提取纯净有效内容 |
简单说:文档切割转换的本质是「数据提纯 + 结构化」——把杂乱的原始文档变成「长度合规、语义完整、无噪音、带上下文元数据」的标准化文本块,为后续向量化和检索筑牢基础。
二、LangChain 文档转换器:核心逻辑与核心任务
LangChain 中的 Document Transformers 是处理文档流水线的'数据加工厂',核心围绕 3 件事展开,缺一不可:
1. 三大核心任务(直接决定后续检索效果)
| 核心任务 | 具体操作 | 最终效果 |
|---|---|---|
| 文本分块 | 按「固定长度 + 语义边界」分割文本(优先用段落、句子分隔符) | 避免截断完整语义,适配模型 token 限制 |
| 去噪处理 | 移除特殊字符、乱码、HTML 标签、广告内容、多余空格 | 提升文本信息密度,减少噪音对向量化的干扰 |
| 元数据增强 | 为每个文本块注入来源(如'XX 合同第 3 章')、页码、时间戳、加载器类型等上下文 | 检索时可追溯信息源头,提高答案可信度 |
2. 核心组件:TextSplitter 抽象类
所有文档切割逻辑都基于 langchain_text_splitters.TextSplitter 抽象类实现——它定义了分块的核心接口,但不直接实现分割逻辑,需通过子类(如 RecursiveCharacterTextSplitter、CharacterTextSplitter)按具体策略执行。
先看核心源码结构(关键参数带场景解读):
from langchain_text_splitters import TextSplitter
from abc import ABC, abstractmethod
typing , ,
(BaseDocumentTransformer, ABC):
() -> :
...
() -> []:
...


