在构建基于大语言模型的AI应用时,使用特定数据“锚定”生成的文本响应至关重要。
本文深入探讨了检索增强生成(RAG)中的分块技术,分析了从基础到高级的分块策略及其权衡,为开发者选择正确方法提供指导。
分块是将大型文档分解为更小、更易于管理的片段,以适应LLM的有限上下文窗口。
文章详细解释了分块对RAG的重要性,包括优化检索准确性和为生成保留上下文。
此外,还介绍了预分块与后分块、各种分块策略(如固定大小、递归分块、基于文档的分块等)以及如何选择最佳分块策略。
最后,文章还讨论了分块工具和库的使用,以及如何在生产环境中优化RAG的分块大小。
/>
如果你正在构建基于大语言模型(LLMs)的
应用,那么用你的特定数据来“锚定”生成的文本响应,是获得准确答案的关键。
检索增强生成(RAG)将大语言模型与外部知识源(如向量数据库)连接起来。
这使得模型在生成回复之前能够找到相关的事实依据。
检索过程的质量是影响应用程序性能的最大因素之一。
许多开发者专注于挑选合适的向量数据库或嵌入模型(Embedding
Model),但最重要的一步往往是你如何准备数据本身。
这就是分块(Chunking)发挥作用的地方。
/>
接下来,我们将回顾一些基本的分块策略,从基础到高级技术,分析它们的权衡取舍,并提供为你的
RAG
应用选择正确方法的建议。
什么是分块?
简单来说,分块是将大型文档分解为更小、更易于管理的片段(称为“块”或
chunks)的过程。
这是准备数据以供大语言模型使用时的关键第一步。
主要原因是
LLM
具有有限的上下文窗口(context
window),这意味着它们一次只能处理一定量的文本。
如果上下文窗口中的文本过多,重要的细节就会丢失,从而导致答案不完整或不准确。
分块通过创建更小、更聚焦的内容片段来解决这个问题,使
LLM
能够利用这些片段回答用户的查询,而不会迷失在无关的信息中。
每个块的大小、内容和语义边界都会影响检索性能,因此决定使用哪种技术会对
RAG
性能中最重要的因素。
你如何拆分文档会直接影响系统找到相关信息并给出准确答案的能力。
当一个
RAG
系统表现不佳时,问题往往不在于检索器,而在于块。
如果是在准备得很糟糕的数据上进行搜索,即使是完美的检索系统也会失败。
这就产生了一个根本性的挑战:你的分块既要便于向量搜索找到,又要给
LLM
提供足够的上下文来生成有用的答案。
1.
优化检索准确性
第一步是确保你的系统能够在向量数据库中找到正确的信息。
向量搜索通过比较用户查询与分块的嵌入向量来实现这一点。
分块过大的问题在于:它们通常混合了多种观点,子主题可能会丢失或变得模糊。
这就好比试图通过平均所有章节的内容来描述一本书。
这会产生一个嘈杂的、“平均化”的嵌入向量,无法清晰地代表任何单一主题,从而使向量检索步骤难以找到所有相关的上下文。
分块小而聚焦则能捕捉到一个清晰的观点。
这会产生一个精确的嵌入向量,能够编码内容的细微差别。
这使得系统更容易找到正确的信息。
2.
为生成保留上下文
当系统找到最佳的分块后,它们会被传递给
LLM。
这就是上下文质量决定输出响应质量的地方。
这有一个简单的测试方法:如果一个分块单独阅读时对你来说有意义,那么它对
LLM
来说也会有意义。
分块过小无法通过这个测试。
想象一下从一篇研究论文的中间读一个单独的句子——如果没有更多的上下文,即使是人类也很难理解发生了什么。
分块过大则会产生另一个问题。
由于注意力稀释(attention
dilution)和“迷失在中间(lost
***
的性能会随着上下文输入的变长而下降。
也就是说,模型很难访问埋藏在长上下文中间的信息,尽管它能较好地处理开头和结尾的信息。
随着上下文长度的增加,模型的注意力在所有输入上变得过于分散,使其在寻找相关信息时变得不那么准确,导致推理错误增多,并增加了产生幻觉(hallucinating)的可能性。
分块的最佳平衡点(The
Spot)
你希望在保留作者的**“思路(train
thought)”的同时,创建足够小的分块以进行精确检索,但又足够完整以给
LLM
提供全部上下文。
这是上下文工程(context
engineering)**的一部分:以一种
LLM
能够理解并据此生成准确响应的方式准备输入。
当你找准了这个平衡点,几件事会得到改善:
- 提高检索质量:通过创建聚焦的、语义完整的分块,你使检索系统能够精确定位查询最相关的上下文。
- 管理
LLM
的上下文窗口:
有效的分块确保只有相关数据被传递给LLM,有助于避免过长的上下文长度混淆模型。
- 减少幻觉:通过向模型提供小的、高度相关的分块,你将模型的回答锚定在事实数据中,最大限度地降低了它编造信息的风险。
- 提高效率并降低成本:处理较小的分块速度更快,计算效率更高,这能带来更快的响应时间和更低的
LLM
(Post-Chunking)
既然我们已经涵盖了分块的基本困境,我们可以探讨在
RAG
管道中何时执行分块步骤。
这个决定导致了两种主要策略:标准的预分块和一种更先进的替代方案,后分块。
预分块是最常见的方法。
它异步处理文档,在嵌入和存储到向量数据库之前将它们分解成更小的部分。
这种方法需要预先决定分块的大小和边界,但由于所有分块都是预先计算和建立索引的,因此能够在查询时实现快速检索。
/>
后分块采取了不同的方法,它首先嵌入整个文档,然后仅在实际检索到文档后,才在查询时进行分块。
分块结果可以被缓存,因此随着频繁访问的文档积累起缓存的块,系统会随着时间的推移变得更快。
这种方法避免了对可能永远不会被查询的文档进行分块,同时允许根据具体查询采用更动态、上下文感知的分块策略。
然而,它在首次访问时会引入延迟,并需要额外的基础设施决策。
/>
分块策略
最好的分块策略取决于你正在处理的文档类型以及你的
RAG
应用的需求。
以下方法主要针对基于文本的文档。
对于其他格式(如
PDF),需要额外的步骤将其转换为干净的文本。
关于处理
PDF在对
是一种视觉格式,因此提取文本可能很棘手。
分栏、表格、页眉或扫描页面会使文本提取变得不可靠。
对于扫描文档,需要光学字符识别
(OCR)来获取文本。
专家建议:最可靠的方法是首先将
PDF
Markdown。
这个预处理步骤确保你在应用以下任何分块策略之前,拥有干净、逻辑有序的文本。
简单分块技术
固定大小分块
(Fixed-Size
Chunking)
固定大小分块是最简单、最直接的方法。
它将文本分割成预定大小的块,通常以
Token(模型处理文本的单位)或字符来衡量。
这种方法易于实现,但不尊重文本的语义结构。
因此,它可能会在句子甚至单词的中间切断,导致尴尬的断裂。
一个常见的解决方案是**分块重叠
(Chunk
会在下一个分块的开头重复出现。
这保留了原本可能在分块边界处丢失的上下文。
关键考虑因素:
- 分块大小
(Chunk
Size):
一个常见的起点是与嵌入模型的上下文窗口对齐的大小。较小的分块可能更适合捕捉细粒度的细节,而较大的分块可能更适合理解更广泛的主题。
- 分块重叠
(Chunk
Overlap):
典型的重叠比例是分块大小的10%
20%。
适用场景:快速原型设计以及获取
RAG
系统性能的基准线。
这是最简单的起点,特别是当你处理结构不一致的文档或尚不确定正在处理什么内容时。
只要确保使用适当的重叠(10-20%),这样你就不会因信息被分割到不同块中而丢失重要上下文。
代码示例:
fromtyping
get_chunks_fixed_size_with_overlap(text:
str,
Chunking)
递归分块是一种更细致的方法。
它使用优先级的常用分隔符列表来分割文本,例如双换行符(用于段落)或单换行符(用于句子)。
它首先尝试用优先级最高的分隔符(段落)来分割文本。
如果产生的任何分块仍然太大,算法会对该特定分块递归地应用下一个分隔符(句子)。
这种方法适应文档的结构,尽可能保持结构相关的单元在一起。
它避免了固定大小分块的突然切断,并确保分块保留其原始格式的结构。
推荐用于:非结构化文本文档,如文章、博客文章和研究论文。
这通常是一个可靠的默认选择,因为它尊重文本的自然组织,而不是随机分割。
代码示例:
fromtyping
chunks.append(current_chunk.strip())
current_chunk
chunks.append(current_chunk.strip())
Recursively
final_chunks.extend(recursive_chunking(chunk,
max_chunk_size))
max_chunk_size)]
基于文档的分块
(Document-Based
Chunking)
基于文档的分块利用文档的内在结构。
它不是依赖通用的分隔符,而是根据文档特定格式的元素来解析文档。
例如:
- Markdown:按标题(#,
##)分割以捕获章节或子章节。
- HTML:按标签(
<p>,<div>)分割以保留逻辑内容块。 - PDF:预处理后(如
OCR
Markdown),按页眉、段落、表格或其他结构元素分割。
- 程序代码:按函数或类(例如
Python
中的
def)分割以保持代码的逻辑单元。
使用这种方法,分块保持与文档逻辑组织的对齐,这种组织通常也与语义含义相关联。
LangChain
LlamaIndex
JSON)提供了专门的分割器。
适用场景:高度结构化的文档,其格式可以轻松定义逻辑分隔。
非常适合
Markdown、HTML、源代码或任何具有清晰结构标记的文档。
代码示例:
fromtyping
markdown_document_chunking(text:
str)
r'^#{1,6}\s+.+$'
lines
'\n'.join(current_chunk).strip()
chunk_text:
'\n'.join(current_chunk).strip()
chunk_text:
chunks
高级分块技术
语义分块
(Semantic
Chunking)
语义分块从传统的基于规则的分割转变为基于意义的分割。
这种更高级的技术不是依赖字符数或文档结构,而是根据语义相似性来划分文本。
该过程包括:
- 句子分割:将文本分解为单独的句子。
- 嵌入生成:将每个句子转换为向量嵌入。
- 相似度分析:比较嵌入向量以检测语义断点(主题发生变化的地方)。
- 分块形成:在这些断点之间创建新的分块。
结果是一组高度连贯的语义块,每个块包含一个独立的想法或主题。
这种方法非常适合密集的非结构化文本,在这些文本中你希望保留论点或叙述的逻辑流。
推荐用于:密集的非结构化文本,以保留一个想法的完整语义上下文。
这种方法非常适合学术论文、法律文件或长篇故事。
这些文本并不总是使用清晰的分隔符(如段落)来显示主题变化。
当你处理复杂的内容,且语义边界与文档结构不完全一致时,这种方法非常棒。
基于
LLM
不是依赖固定规则或基于向量的相似度分数,而是处理文档并生成语义连贯的分块,通常还会添加额外的上下文、摘要或其他信息。
这可以通过以下方式完成:
- 识别命题
(Identifying
propositions):
将文本分解为清晰、逻辑的陈述。 - 部分摘要
(Summarizing
sections):
归纳成更小的、保留原意的分块。 - 突出关键点
(Highlighting
points):
确保捕获最相关的信息。
结果是一组比传统方法更准确地保留语义意义的分块。
这使得基于
LLM
最强大的策略之一。
适用场景:检索质量至关重要且预算不是主要顾虑的高价值、复杂文档。
非常适合法律合同、研究论文、合规文件或企业知识库。
这种方法可以生成概括或突出关键思想的分块,但也伴随着权衡。
与其他分块技术相比,它是计算成本最高且速度最慢的方法。
/>
代理式分块
代理不是应用单一方法,而是动态决定如何分割你的文档。
它会查看整个文档,包括其结构、密度和内容。
然后,它决定使用最佳的分块策略或策略组合。
例如,代理可能会看到一个文档是
Markdown
文件,然后按标题分割文件。
它也可能发现一个更密集的文档需要命题式的方法。
它甚至可以用元数据标签丰富分块,以实现更高级的检索。
这些“LLM
驱动的方法”可以创建非常清晰且内容丰富的分块。
然而,它们需要大量的计算能力,成本更高。
通常每个文档需要多次调用强大的模型。
适用场景:高风险的
RAG
系统,你需要尽可能最好的分块,且成本不是决定性因素。
当你需要针对每个文档的独特特征量身定制自定义分块策略时,这是完美的选择。
/>
后期分块
Chunking)
后期分块是一种略有不同的技术,旨在解决其他分块策略中的一个常见问题:上下文丢失。
在其他分块技术中,当你先分割文档然后创建嵌入时,每个分块都会变得孤立。
这可能导致分块内的上下文模棱两可或丢失,而这些上下文是在文档前面的部分解释或引用的。
后期分块反其道而行之。
你不是先分割,而是首先将整个文档输入到一个长上下文嵌入模型中。
这创建了详细的、Token
级别的嵌入,能够理解全貌。
只有在那之后,你才将文档分割成块。
当你为每个分块创建嵌入时,你使用的是已经包含完整上下文的
Token
嵌入。
这意味着每个分块都保留了关于整个文档的上下文。
适用场景:在检索质量依赖于理解分块与整个文档之间关系的
RAG
法律文本非常有用。
这些文档的章节经常引用其他地方提到的想法、方法或定义。
这有助于捕捉常规分块方法会错过的文档不同部分之间的联系。
/>
分层分块
Chunking)
分层分块对于非常大和复杂的文档来说可能是一个游戏规则改变者。
这个想法非常直接:你在不同的细节层级上创建多层分块。
- 在顶层,你创建大的分块,总结广泛的章节或主题,如标题和摘要。
- 在下一层,你将这些章节分割成逐渐变小的分块,以捕捉更精细的细节,如论点、例子或定义。
这让你的
RAG
系统可以从高层概览开始,然后在用户需要更多细节时深入到具体内容。
LlamaIndex
的
HierarchicalNodeParser使这种方法的实现变得容易。适用场景:非常大和复杂的文档,如教科书、法律合同或广泛的技术手册。
当你需要回答高层总结性问题和高度具体、细节性查询时,此策略非常理想。
它为你提供了广阔上下文和细粒度访问之间的良好中间地带,虽然比基本分割方法更复杂,但没有完全的代理式分块那么复杂。
/>
自适应分块
Chunking)
自适应分块技术根据文档的内容动态调整关键参数(如分块大小和重叠)。
这种方法不是对整个文档应用单一、固定的规则,而是将文本视为变化的景观。
它可能会使用机器学习模型来分析不同部分的语义密度和结构。
例如,它可以自动为复杂、信息丰富的段落创建更小、更细粒度的分块以捕捉细节,同时为更一般的介绍性部分使用更大的分块。
目标是创建大小和边界针对其包含的具体内容量身定制的分块,从而实现更精确和上下文感知的检索。
这与代理式分块不同,后者由代理决定使用哪种分块策略,而不仅仅是调整一种策略的参数。
适用场景:具有变化和不一致内部结构的文档。
想象一份长报告,其中包含密集的技术段落和稀疏的叙述部分。
自适应策略在这里表现出色,因为它避免了“一刀切”的问题。
它可以在同一文档中为复杂部分创建细小的颗粒状分块以捕捉每个细节,并为较简单的文本创建较大的分块以保留上下文。
如何选择最佳分块策略?
没有单一的“最佳”分块方法;最优策略始终取决于你的具体用例。
但在深入研究不同技术之前,要问的最重要的问题是:
“我的数据真的需要分块吗?”
分块旨在分解长的、非结构化的文档。
如果你的数据源已经包含小的、完整的信息片段,如常见问题解答(FAQ)、产品描述或社交媒体帖子,通常不需要对它们进行分块。
分块甚至可能引起问题。
目标是创建有意义的语义单元,如果你的数据已经是这种格式,你就已经准备好进入嵌入阶段了。
一旦你确认文档足够长,可以从分块中受益,你可以使用以下问题来指导你选择策略:
- 我的文档性质是什么?它们是高度结构化的(如代码或
JSON),还是非结构化的叙述性文本?
- 我的
RAG
系统需要什么级别的细节?
它需要检索具体的、细粒度的事实,还是总结更广泛的概念? - 我使用的是哪种嵌入模型?输出向量的大小是多少(维度越多,存储更细粒度信息的能力越强)?
- 用户查询会有多复杂?它们是需要小的、目标明确的分块的简单问题,还是需要更多上下文的复杂问题?
分块策略 工作原理 复杂度 最佳适用场景 示例 固定大小 (Fixed-Size)
按 Token
或字符计数分割。
低 小型或简单文档,或当速度最重要时。 会议记录、短博文、邮件、简单 FAQ
递归 (Recursive)
重复分割文本直到符合所需大小,通常保留一些结构。 中 需要保持一定结构但速度仍然重要的文档。 研究文章、产品指南、简短报告 基于文档 (Document-Based)
将每个文档视为一个分块,或仅在文档边界分割。 低 短小、独立的文档集合。 新闻文章、客户支持工单、短合同 语义 (Semantic)
在自然意义边界(主题、想法)处分割文本。 中-高 技术、学术或叙述性文档。 科学论文、教科书、小说、白皮书 基于 LLM
(LLM-Based)
使用语言模型根据上下文、意义或任务需求决定边界。 高 意义感知分块能改善下游任务(如摘要或问答)的复杂文本。 长报告、法律意见书、医疗记录 代理式 代理根据意义和结构决定如何分割。
非常高 需要自定义策略的复杂、微妙文档。 监管文件、多章节合同、公司政策 后期 (Late)
先嵌入整个文档,然后从中推导分块嵌入。 高 分块需要感知完整文档上下文的用例。 案例研究、综合手册、长篇分析报告 分层 (Hierarchical)
将文本分解为多个层级(章节 句子)。
保持结构完整。
中 大型、结构化文档,如手册、报告或合同。 员工手册、政府法规、软件文档 自适应 或启发式方法动态调整分块大小和重叠。
高 结构和长度各异的混合数据集。 来自多源的数据:博客、PDF、邮件、技术文档 代码 (Code)
按逻辑代码块(函数、类、模块)分割,同时保留语法。 中 源代码、脚本或编程文档。 Python 模块、JavaScript
文档
分块工具和库
在为
RAG
应用程序设置数据摄取管道时,你经常面临分块的经典权衡:你可以依赖专用库以获得速度和易用性,或者自己构建逻辑以获得完全控制。
使用库
幸运的是,你不必从头开始。
LLM
社区经常使用两个强大的开源库:LangChain和LlamaIndex,每一个都有不同的分块方法:
- LangChain:一个用于构建
LLM
应用程序的广泛框架。
其灵活的
TextSplitters使其易于将分块集成为更大系统(如多步代理)的一部分。
- 最适合:模块化工作流,其中分块只是拼图的一块。
- LlamaIndex:专为
RAG
管道设计。
其复杂的
NodeParsers生成针对摄取和检索进行优化的“节点(Nodes)”。 - 最适合:高性能、以数据为中心的检索系统。
- chonkie:一个轻量级、专用的分块库,专注于分割文本。
它提供各种分块策略,如
SemanticChunker,并且易于与其他RAG
库集成。
- 最适合:那些你想要简单、专注的解决方案,而不需要大型框架开销的项目。
手动实现
使用库的替代方案是自己实现分块逻辑。
像固定大小或递归分块这样的策略在
Python
中很容易编写代码,这让你对数据处理方式拥有完全的权威,并避免在项目中添加外部依赖。
- 最适合:那些希望避免添加大型库、需要实现高度自定义分块策略或需要数据管道完全透明的项目。
如何在生产环境中优化
RAG
的分块大小
在生产环境中优化分块大小需要大量的测试和审查。
以下是你可以采取的一些步骤:
- 从通用的基准策略开始,例如固定大小分块。
一个好的起点是
512
的重叠。
这为你提供了一个稳固的基准,易于复现并与其他分块策略进行比较。
- 尝试不同的分块方法,通过调整分块大小和重叠等参数,找到最适合你数据的方法。
- 测试检索效果,通过运行典型的查询并检查命中率
(hit
(recall)
等指标,看看哪种策略效果最好。 - 引入人工审查,检查检索到的分块和
LLM
生成的回复——他们的反馈会捕捉到指标可能遗漏的问题。
- 持续监控生产环境中
RAG
系统的性能,并准备好根据需要迭代你的分块策略。
最后
我在一线科技企业深耕十二载,见证过太多因技术更迭而跃迁的案例。
那些率先拥抱
的同事,早已在效率与薪资上形成代际优势,我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。
我整理出这套
大模型突围资料包:
- ✅AI大模型学习路线图
- ✅Agent行业报告
- ✅100集大模型视频教程
- ✅大模型书籍PDF
- ✅DeepSeek教程
- ✅AI产品经理入门资料
完整的大模型学习和面试资料已经上传带到CSDN的官方了,有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇
/>
/>
为什么说现在普通人就业/升职加薪的首选是AI大模型?
人工智能技术的爆发式增长,正以不可逆转之势重塑就业市场版图。
从DeepSeek等国产大模型引发的科技圈热议,到全国两会关于AI产业发展的政策聚焦,再到招聘会上排起的长队,AI的热度已从技术领域渗透到就业市场的每一个角落。
/>
/>智联招聘的最新数据给出了最直观的印证:2025年2月,AI领域求职人数同比增幅突破200%,远超其他行业平均水平;整个人工智能行业的求职增速达到33.4%,位居各行业榜首,其中人工智能工程师岗位的求职热度更是飙升69.6%。
AI产业的快速扩张,也让人才供需矛盾愈发突出。
麦肯锡报告明确预测,到2030年中国AI专业人才需求将达600万人,人才缺口可能高达400万人,这一缺口不仅存在于核心技术领域,更蔓延至产业应用的各个环节。
/>
/>
资料包有什么?
①从入门到精通的全套视频教程⑤⑥
包含提示词工程、RAG、Agent等技术点
/>
AI大模型学习路线图(还有视频解说)
全过程AI大模型学习路线
/>
③学习电子书籍和技术文档
市面上的大模型书籍确实太多了,这些是我精选出来的
/>
④各大厂大模型面试题目详解
/>
⑤
这些资料真的有用吗?
这份资料由我和鲁为民博士共同整理,鲁为民博士先后获得了北京清华大学学士和美国加州理工学院博士学位,在包括IEEE
Transactions等学术期刊和诸多国际会议上发表了超过50篇学术论文、取得了多项美国和中国发明专利,同时还斩获了吴文俊人工智能科学技术奖。
目前我正在和鲁博士共同进行人工智能的研究。
所有的视频教程由智泊AI老师录制,且资料与智泊AI共享,相互补充。
这份学习大礼包应该算是现在最全面的大模型学习资料了。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目,无论你是小白还是有些技术基础的,这份资料都绝对能帮助你提升薪资待遇,转行大模型岗位。
/>
/>
智泊AI始终秉持着“让每个人平等享受到优质教育资源”的育人理念,通过动态追踪大模型开发、数据标注伦理等前沿技术趋势,构建起"前沿课程+智能实训+精准就业"的高效培养体系。
课堂上不光教理论,还带着学员做了十多个真实项目。
学员要亲自上手搞数据清洗、模型调优这些硬核操作,把课本知识变成真本事!
/>
/>
如果说你是以下人群中的其中一类,都可以来智泊AI学习人工智能,找到高薪工作,一次小小的“投资”换来的是终身受益!
应届毕业生:无工作经验但想要系统学习AI大模型技术,期待通过实战项目掌握核心技术。
零基础转型:非技术背景但关注AI应用场景,计划通过低代码工具实现“AI+行业”跨界。
业务赋能
突破瓶颈:传统开发者(Java/前端等)学习Transformer架构与LangChain框架,向AI全栈工程师转型。
👉获取方式:
😝有需要的小伙伴,可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓**
/>


