链载Ai

标题: RAG应用如何进行有效的文本切分 [打印本页]
作者: 链载Ai    时间: 昨天 21:52
标题: RAG应用如何进行有效的文本切分

在RAG（检索增强生成，Retrieval-Augmented Generation）应用中，文本分块（Text Chunking）是连接“知识存储”与“检索-生成”的核心预处理步骤，其重要性体现在对检索效率、相关性、生成质量及系统灵活性的多维度影响。

首先松哥和大家讨论第一个问题，就是为什么我们要重视文本切分。

一 为什么文本切分很重要

1.1 提升检索相关性：精准匹配用户需求

RAG 的核心是“先检索、后生成”，而检索的本质是从知识库中找到与用户查询语义最相关的信息。文本分块直接影响检索的精准度：

1.2 优化检索效率：降低计算成本与延迟

RAG 依赖向量数据库存储文本的向量表示（通过嵌入模型生成），检索时需计算“用户查询向量”与“文本块向量”的相似度。分块对效率的影响体现在：

1.3 保障生成质量：为LLM提供精准上下文

LLM（大语言模型）生成回答时，依赖检索到的文本块作为“事实依据”。分块质量直接影响输入 LLM 的上下文有效性：

一般我们通过嵌入模型来生成嵌入向量，而嵌入向量往往也有上下文窗口大小的限制。以常见的 bge-m3 为例，我们可以在介绍文档中看到最大 token 数的限制。

当然，我们也可以直接在模型的配置文件中找到 token 上限：

上图是在 tokenizer_config.json 文件中找到的配置，有的是在 config.json 配置文件中。

1.4 适配长文档处理：突破“上下文窗口限制”

现实中，RAG 的知识库常包含长文档（如论文、手册、法律条文等），其长度远超 LLM 的上下文窗口（例如，一本 300 页的技术手册）。文本分块是处理这类文档的核心手段：

1.5 平衡“完整性”与“聚焦性”：避免信息割裂

分块的核心挑战是“如何划分边界”，而合理分块能在“信息完整”与“聚焦性”间找到平衡：

针对这里第一小点，松哥举个例子。

假设原文是一段关于"气候变化对农业影响"的论证：

①. 全球平均气温上升会导致极端天气事件增加。
②. 干旱和洪涝频率上升会直接破坏农作物生长周期。
③. 这将导致主要粮食产区的产量下降。
④. 最终可能引发全球粮食供应紧张和价格波动。

这四句话构成一个完整的因果链论证：气温上升→极端天气→作物受损→粮食危机。

如果按单句分块存储，当用户查询"气候变化为何会导致粮食价格上涨"时：

这种情况下，过度细碎的分块割裂了语义关联，使检索到的信息失去了上下文支撑，LLM自然无法生成逻辑完整的回答。

因此，优质分块策略（如按语义、段落、标点符号分块）需确保每个块既能独立表达完整信息，又不包含无关内容，这是 RAG 系统性能的关键前提。

二 文本该如何切分

那么文本该如何切？

虽然文本切分策略很多，但是 Java 在这块现有框架目前支持的比较少，Spring AI 中仅有一个 TokenTextSplitter，而在 Spring AI Alibaba 中则多支持了一个 SentenceSplitter。

我们来简单看看这两种切分策略。

2.1 TokenTextSplitter

在 Spring AI 中，TokenTextSplitter 是一个用于文本分割的工具类，主要功能是将长文本按照令牌（Token）数量进行拆分，适用于处理超出大语言模型（LLM）上下文窗口限制的文本内容。它是实现文本分块（Text Chunking）的重要组件，通常在构建检索增强生成（RAG）等应用时使用。

TokenTextSplitter 通常使用与 LLM 一致的令牌化逻辑（通常基于 OpenAI 的 tiktoken 库），确保分割结果与模型的令牌计数一致；并且 TokenTextSplitter 会尽量在自然边界（如句子结束处）进行分割，避免将完整语义拆分到不同文本块中。

我们来看一段简单的示例代码：

List<Document> documents = myTikaDocumentReader.loadText();
TokenTextSplitter splitter =newTokenTextSplitter(30,10,3,2000,true);
List<Document> chunks = splitter.apply(documents);
for(Document chunk : chunks) {
  System.out.println("内容块: "+ chunk.getText());
  System.out.println("元数据: "+ chunk.getMetadata());// 继承原始文档元数据
}

在构建 TokenTextSplitter 的时候，有五个参数，含义分别如下：

参数名
默认值
功能描述
defaultChunkSize
30
目标块大小（令牌数）
minChunkSizeChars
10
最小块字符数（低于此值不分割）
minChunkLengthToEmbed
3
有效块最小长度（字符数，短于此值丢弃）
maxNumChunks
2000
单文本最大分块数（防长文本爆炸）
keepSeparator
true
是否保留分隔符（如换行符）

TokenTextSplitter 处理流程如下：

  1. 编码阶段：使用 CL100K_BASE 编码将输入文本转换为令牌序列。
  2. 分块切割：按 defaultChunkSize 将令牌序列切割为块。
  3. 断点优化：对每个块尝试在 minChunkSizeChars 后寻找自然断点（句号、问号、感叹号或换行符）。找到断点则截断，否则保留原始切割点。
  4. 格式处理：修剪空白字符，按 keepSeparator 决定是否保留换行符。仅保留长度 ≥minChunkLengthToEmbed 的块。
  5. 循环处理：重复切割直至处理完所有令牌或达到 maxNumChunks 限制。

以上代码最终切块后的结果如下：

2.2 SentenceSplitter

Spring AI Alibaba 的 SentenceSplitter 是一个专为文本分块设计的组件，主要用于优化 RAG（检索增强生成） 流程中的文档预处理阶段。它通过智能拆分长文本为语义连贯的句子组，确保后续向量化处理能保留上下文完整性，从而提升大模型在问答、知识检索等任务中的准确性。

SentenceSplitter 的工作流程分为两步：

代码案例如下：

List<Document> documents = myTikaDocumentReader.loadText();
SentenceSplitter splitter =newSentenceSplitter(128);
List<Document> chunks = splitter.apply(documents);
for(Document chunk : chunks) {
  System.out.println("内容块: "+ chunk.getText());
  System.out.println("元数据: "+ chunk.getMetadata());// 继承原始文档元数据
}

这是目前我们在 Java 相关框架中支持的分块方案。

还有其他一些分块思路，这里也和大家聊聊，大家可以结合自己的项目需求，自行实现。

2.3 固定长度分块（Fixed-Length Chunking）

思路

将文本按照预设的固定长度（如字符数、token 数）进行均匀拆分，不考虑文本的语义、结构或标点等信息，当剩余文本长度不足固定长度时，作为最后一个块保留。

原理

适用场景

优缺点

2.4 递归分块（Recursive Chunking）

思路

以“先大后小”的层级逻辑分块，优先按大粒度分隔符（如段落、章节）切分，若分块后仍超过预设长度，则递归使用更小粒度的分隔符（如句子、逗号）继续切割，直到所有块的长度符合要求。

原理

适用场景

优缺点

2.5 按结构分块（Structural Chunking）

思路

根据文本的固有结构特征（如格式标记、逻辑层级）进行分块，将具有相同结构属性的内容划分为一个块。

原理

适用场景

优缺点

2.6 按标点分块（Punctuation-Based Chunking）

思路

以标点符号作为分块的主要依据，将标点符号（如句号、问号、感叹号、分号）分隔的内容划分为独立块，通常优先使用表示语义停顿较强的标点。

原理

适用场景

优缺点

总结

分块策略
核心依据
核心目标
典型应用场景
固定长度分块
量化长度（字符/token）
快速、均匀切割
日志、简单无结构文本
递归分块
分隔符优先级+长度控制
平衡长度与语义完整性
文章、书籍等长文档
按结构分块
文本格式/逻辑结构
保留结构化单元
网页、Markdown、PDF报告
按标点分块
标点符号（语义停顿）
保留完整句子/分句
散文、论文、对话文本

实际应用中，常结合多种策略（如递归分块中融入标点和结构信息），以适应复杂文本的分块需求。





欢迎光临 链载Ai (https://www.lianzai.com/) Powered by Discuz! X3.5