4. 分块核心概念

在金融RAG系统中，分块策略是决定召回质量的第一道闸门。金融文档具有高度结构化、术语密集、数字与条款交织的特点，分块不当会直接导致检索时“找得到但读不懂”或“读得懂但找不全”。本节将系统梳理四种主流分块策略的核心原理、优缺点与适用边界，帮助你在不同金融场景中做出合理选择。

一、核心原理：四种分块策略的本质差异

分块的本质是在“语义完整性”与“检索粒度”之间寻找平衡点。固定长度分块以字符数或数为唯一标尺，实现简单但容易切断语义；语义分块通过嵌入相似度或模型判断句子边界，保语义但计算成本高；递归分块采用层级分隔符逐级降级切分，兼顾结构与效率；滑动窗口通过重叠区域保留上下文，缓解边界信息丢失。

二、方法流程：从文档到分块的决策路径

在实际工程中，分块策略的选择应遵循“文档结构分析→策略匹配→参数调优→效果验证”的闭环流程。首先分析金融文档的层级结构：年报通常有章节、小节、段落三级；合同有条款、子条款；研报有标题、摘要、正文。然后根据结构复杂度选择策略：结构清晰用递归分块，语义密集用语义分块，结构松散用固定长度加滑动窗口。

参数调优阶段需重点关注三个指标：块大小（chunk_size）、重叠长度（overlap）和最小块阈值。金融文本建议块大小控制在256-512 ，重叠64-128 ，最小块不低于50 。验证阶段通过召回率、精确率和答案完整性三个维度评估，若召回率低则增大重叠，若精确率低则减小块大小。

# 递归分块参数配置示例（LangChain风格）
from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=400,          # 金融文本建议256-512
    chunk_overlap=80,        # 重叠比例约20%
    separators=["\n\n", "\n", "。", "；", "，", " "],
    length_function=len,
    keep_separator=True
)

# 滑动窗口配置
from langchain.text_splitter import TokenTextSplitter
sliding = TokenTextSplitter(
    chunk_size=300,
    chunk_overlap=100,       # 重叠约33%
    encoding_name="cl100k_base"
)

三、案例场景：不同金融文档的分块实践

以某券商研报RAG系统为例，原始文档包含标题、摘要、正文、图表说明和风险提示。采用递归分块后，标题与摘要合并为一个块，正文按段落切分，图表说明单独成块，风险提示独立成块。召回测试显示，关于“净利润增长率”的查询能准确召回摘要中的关键数据，而“风险因素”查询则精准命中风险提示块。

另一个案例是银行合同审查场景。合同条款具有强语义关联性，采用语义分块后，每个条款块包含完整的权利义务描述。但语义分块计算成本高，该团队最终采用“递归分块+语义后处理”的混合方案：先用递归分块快速切分，再用嵌入模型对相邻块进行语义合并，兼顾效率与质量。

四、误区与复盘：分块策略的常见陷阱

误区一：认为“块越小召回越准”。实际上，过小的块会丢失上下文，导致检索到的片段无法回答完整问题。金融条款往往需要前后文才能理解，块太小反而降低答案质量。

误区二：忽视重叠参数。许多团队将overlap设为0，导致边界处的关键信息被切断。建议至少设置10%-20%的重叠，对于语义密集的合同文本可提高到30%。

误区三：一套参数打天下。不同金融文档类型差异巨大，财报、研报、合同、监管文件应分别配置分块参数。建议建立分块策略矩阵，按文档类型动态选择。

综合来看，金融RAG的分块策略没有“银弹”。生产环境推荐以递归分块为基线，针对语义密集文档引入语义分块，对短文本问答采用滑动窗口，并在所有策略中保留适当重叠。最终选择应基于文档结构、查询类型和资源约束三者的平衡，通过持续评估迭代优化。