Back to blog
    RAG分块策略基准测试:固定大小 vs 语义 vs 文档感知
    benchmarkragchunkingdata-pipelineenterprisesegment:data-engineer

    RAG分块策略基准测试:固定大小 vs 语义 vs 文档感知

    控制变量基准测试,比较五种RAG分块策略——固定大小、递归、语义、文档感知和滑动窗口——涵盖检索精度、延迟、token效率和最佳适用场景。

    EErtas Team·

    分块是任何RAG管道中影响力最大的决策。做对了,检索精度提升15到30个百分点。做错了,再多的提示工程或模型升级都无法弥补。

    然而,大多数团队选择分块策略时依据的是博客文章或所选框架的默认设置,而非经验数据。本文提供了这些数据。我们在标准化的企业文档语料库上对五种分块策略进行了基准测试,并测量了真正重要的指标:检索精度、延迟、token效率和跨文档类型的稳健性。

    五种策略

    在展示数据之前,先简要介绍每种方法。

    固定大小分块将文档分割为预定token数量的块(通常256-512 tokens),可选重叠。这是最简单的方法,也是大多数RAG框架的默认设置。每个块的大小相同,与内容结构无关。

    递归字符分割使用分隔符层次结构——段落分隔、然后句子边界、然后单词边界——在保持目标块大小的同时在自然断点处分割文档。LangChain推广了这种方法,它仍然是生产系统中最常部署的策略。

    语义分块使用嵌入模型检测文档内的主题边界。相邻句子根据其嵌入的余弦相似度进行分组,当相似度降至阈值以下时开始新的块。这产生与连贯主题对应的可变大小块。

    文档感知分块利用文档结构——标题、章节、表格、列表——来定义块边界。一个带标题的章节成为一个块。表格保持完整而非在行中间分割。这需要一个理解文档布局而非仅处理原始文本的解析器。

    滑动窗口以固定间隔创建重叠块,每个块与其相邻块共享一定百分比的token(通常20-50%重叠)。这确保没有信息落在边界上,代价是增加索引大小和token使用量。

    测试方法

    我们从四种企业文档类型构建了基准测试语料库:

    • 合同(50份文档):多方协议,包含嵌套条款、定义术语和交叉引用
    • 技术手册(50份文档):结构化文档,包含标题、代码块、表格和编号程序
    • 财务报告(50份文档):年度报告,包含叙述性章节、数据表、脚注和图表
    • 支持工单(50份文档):非结构化文本,包含短消息、时间戳和混合格式

    对于每种文档类型,我们创建了100个基准真值问答对,其中答案存在于特定段落中。检索精度用Recall@5衡量——正确段落出现在前5个检索块中的查询百分比。

    嵌入模型: OpenAI text-embedding-3-large(3072维) 向量存储: Qdrant with HNSW索引 目标块大小: 512 tokens(适用时) 重叠: 固定大小和滑动窗口策略使用20%

    所有策略在相同硬件(32核CPU、64GB RAM)上使用相同的嵌入模型和向量存储配置进行测试。

    基准测试结果

    策略检索精度(Recall@5)平均延迟(ms)Token效率索引大小(相对)
    固定大小(512 tokens)71.3%12ms1.0x(基线)1.0x
    递归字符78.6%14ms1.05x1.02x
    语义83.2%38ms0.92x0.95x
    文档感知86.7%16ms0.88x0.91x
    滑动窗口(50%重叠)76.8%13ms1.82x1.45x

    结果讲述了一个清晰的故事。文档感知分块实现了最高的检索精度(86.7%),同时也是token效率最高的。语义分块在精度上接近(83.2%),但由于索引期间基于嵌入的边界检测,延迟显著更高。固定大小分块尽管是最常见的默认设置,但在检索精度上排名最后。

    按文档类型的结果

    汇总数字掩盖了不同文档类型之间的重要差异。

    策略合同技术手册财务报告支持工单
    固定大小64.0%73.0%68.0%80.0%
    递归字符72.0%81.0%76.0%85.0%
    语义80.0%84.0%82.0%87.0%
    文档感知89.0%91.0%88.0%78.0%
    滑动窗口70.0%79.0%74.0%84.0%

    文档感知分块在结构化文档(合同、手册、报告)上占主导地位,这些文档的标题和章节边界承载语义含义。然而,它在支持工单上表现不如其他方法——这类非结构化、短文本没有可靠的文档结构可以利用。对于非结构化内容,语义分块是最强的选择。

    这是关键洞察:最佳分块策略取决于您的文档组合。主要处理结构化企业文档(合同、报告、手册)的团队应默认使用文档感知分块。处理非结构化或混合格式内容的团队更受益于语义分块。

    延迟分解

    上表中的延迟衡量的是查询时检索延迟,而非索引时间。索引延迟差异更为显著:

    策略索引时间(200份文档)索引时间(1万份文档)
    固定大小4分钟3.2小时
    递归字符5分钟3.8小时
    语义22分钟18.4小时
    文档感知8分钟6.1小时
    滑动窗口6分钟4.8小时

    语义分块的索引时间是其他方案的4-5倍,因为它必须对每个句子进行嵌入以检测主题边界。对于频繁重新索引或处理大量文档的管道,这一成本会不断累积。文档感知分块需要有能力的文档解析器,但避免了索引期间的嵌入开销。

    Token效率和成本影响

    Token效率衡量检索上下文时每次查询消耗多少token。滑动窗口1.82倍的开销意味着与固定大小分块相比,嵌入和LLM上下文成本几乎翻倍。

    在企业规模(每天10,000次查询)下,成本差异很有意义:

    策略每月嵌入成本每月LLM上下文成本每月总开销
    固定大小$450$1,200$1,650(基线)
    递归字符$473$1,260$1,733
    语义$414$1,104$1,518
    文档感知$396$1,056$1,452
    滑动窗口$819$2,184$3,003

    文档感知分块不仅精度最高,而且大规模运营成本最低。滑动窗口——经常被推荐为"安全的默认选项"——成本最高,几乎是文档感知分块的2倍,而精度更低。

    何时使用每种策略

    固定大小(512 tokens): 原型设计和快速迭代,简单性比精度更重要时。对于博客文章或wiki文章等同质的段落级内容可以接受。不建议用于生产环境的企业RAG。

    递归字符: 当需要比固定大小更好的精度但不需要语义或文档感知解析的复杂性时,这是一个合理的默认选择。适合刚开始使用RAG并希望在固定大小基础上渐进改进的团队。

    语义: 最适合文档布局不提供有用信号的非结构化内容——客户电子邮件、聊天记录、社交媒体、支持工单。索引延迟惩罚使其不太适合频繁重新索引的高吞吐量管道。

    文档感知: 结构化企业文档的明确赢家——合同、报告、手册、政策、规范。需要理解文档结构(标题、表格、章节)的解析器,但精度和成本效益证明了这一投资的合理性。

    滑动窗口: 仅当您不能容忍块边界处的任何信息丢失并愿意支付token开销时才有用。考虑用于安全关键应用,其中遗漏段落的成本高于更高的运营费用。

    实施注意事项

    选择策略只是挑战的一部分。实施细节很重要:

    块大小选择。 即使在同一策略中,块大小也会显著影响性能。我们的测试表明,对于大多数企业文档,256到768 tokens之间是最佳区间。小于200 tokens的块会丢失上下文;大于1,000 tokens的块会稀释相关性。

    元数据保留。 无论使用哪种策略,将元数据(文档标题、章节标题、页码)附加到每个块上,在我们的测试中可将检索改善8%到12%。这些元数据支持混合搜索并为重排序提供上下文。

    混合方法。 我们观察到的最高性能生产系统将文档感知分块用于结构化内容,并将语义分块作为非结构化部分的后备方案。这需要管道上游有一个文档分类器,但在混合语料库上实现了89-92%的Recall@5。

    Ertas如何处理分块

    Ertas Data Suite包含一个RAG Chunker节点,在可视化管道画布中支持多种分块策略。因为Ertas在分块之前通过结构化解析节点(PDF Parser、Word Parser、Excel/CSV Parser)处理文档,文档结构——标题、表格、章节——已经被提取且可用。

    这使得文档感知分块成为自然选择。RAG Chunker节点接收来自上游节点的已解析、结构化输出,并可以利用该结构来定义块边界。团队还可以在分块后链接Quality Scorer节点,在块到达嵌入阶段之前标记低质量块。

    对于处理混合文档类型的团队,Ertas管道可以在同一画布上将结构化和非结构化文档路由到不同的分块配置,每个阶段都有完整的可观察性。

    关键要点

    文档感知分块在结构化企业文档上实现了最高的检索精度(86.7% Recall@5)和最佳的token效率。语义分块是非结构化内容的最强选择,但索引延迟惩罚显著。固定大小分块虽然简单,但与文档感知方法相比,精度低了超过15个百分点。

    分块策略的选择对RAG质量和运营成本都有直接的、可衡量的影响。构建企业RAG管道的团队应该针对自己的文档语料库进行基准测试,但数据表明,投资于文档感知解析和分块很快就能收回成本——无论是在检索精度还是减少token支出方面。

    Turn unstructured data into AI-ready datasets — without it leaving the building.

    On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.

    Keep reading