Chunkr：用 Rust 打造的文本分块库，速度快 20 倍

在构建 RAG（检索增强生成）系统时，文本分块（chunking）往往是容易被忽视却又实打实影响性能的一环。随着文档规模扩大，Python 生态里的主流分块工具开始暴露出速度瓶颈。一位开发者为了解决自己系统中的这个问题，用 Rust 从头写了一个分块库 Chunkr，并给出了一组相当亮眼的基准测试数据。

为什么要重写一个分块库

作者的出发点很直接：他需要一个更快的分块库，但又不想牺牲整体的分块准确性，而现有方案里并没有太多能同时满足这两点的选择。于是他基于 Rust 实现了 Chunkr，覆盖了目前主流的多种分块策略，包括字符分块（Character）、递归分块（Recursive）、Markdown 标题分块、延迟分块（Late chunking）、层级分块（Hierarchical chunking）等。

除了分块策略，Chunkr 还内置了原生的 PDF 加载器，并支持其他多种文件类型。这意味着它不只是一个纯粹的字符串切分工具，而是把"文档读取 + 分块"这条链路整合在了一起——这恰恰是 RAG 预处理流程中最耗时的部分。

延迟分块（Late Chunking） 是一种相对新颖的策略，与传统"先分块再嵌入"的流程相反，它先对整段文档做完整的上下文嵌入，再在嵌入空间中执行分割。这样每个块的向量表示都携带了全局上下文信息，能有效缓解传统分块导致的语义截断问题，尤其适合处理跨段落存在指代关系的长文本。层级分块（Hierarchical Chunking） 则将文档拆分为粗粒度的"父块"与细粒度的"子块"两个层级：检索时用子块提高精度，返回时附带父块提供上下文，是当前 RAG 系统中应对"精确匹配"与"语义完整性"两难问题的常用架构。这两种策略的实现比字符切分复杂得多，能将其与高吞吐量结合是 Chunkr 相对于简单字符串切分工具的主要差异点。

分块速度：对比主流 Python 工具

作者在 MacBook（M4 芯片、16GB 内存）上，将 Chunkr 与 LangChain、LlamaIndex、Chonkie、semchunk、text-splitter 等常见库做了横向对比。在参数对齐（如 1000/200 的块大小与重叠）的前提下，差距非常明显：

• 递归分块（1MB，1000/200）：Chunkr 达到 2,264 MB/s，而 LangChain 为 769 MB/s，LlamaIndex 仅 10 MB/s，Chonkie 225 MB/s。
• 固定字符分块（1MB）：Chunkr 为 750 MB/s，LangChain 只有 1.7 MB/s，差距高达数百倍。
• Python 代码分块（200KB，1500/200）：Chunkr 冲到 3,232 MB/s，text-splitter 仅 5.7 MB/s。
• 100 份文档 × 50KB 的并行批处理：Chunkr 保持在 3,224 MB/s，展示了其并行处理能力。

需要留意的一个例外是 BPE 分词（cl100k_base，512/50） 场景：Chunkr 为 38 MB/s，Chonkie 反而以 151 MB/s 领先。这说明在涉及真实 tokenizer 的场景下，性能格局会发生变化，Chunkr 并非在所有维度都是最快的。

BPE（Byte Pair Encoding）分词是 GPT 系列模型所使用的子词分词算法，cl100k_base 是 GPT-4 和 text-embedding-ada-002 等模型采用的具体词表。基于 BPE 的分块策略会先将文本转换为 token 序列，再按 token 数量切分，从而保证每个块的 token 数严格可控——这对于需要精确匹配模型上下文窗口限制的场景至关重要。与字符级分块不同，BPE 分词涉及调用真实的 tokenizer 模型（通常由 tiktoken 等库提供），这一步骤本身有固定的计算开销，会掩盖底层字符串处理的速度差异。这也解释了为何 Chonkie 在此场景下反超 Chunkr——Chonkie 专门针对 tiktoken 集成做了优化，而 Chunkr 在 tokenizer 调用层的适配目前尚未达到同等水平。

PDF 解析与端到端流水线

分块之外，PDF 解析本身也是常见瓶颈。作者将 Chunkr 的 PDFLoader 与 PyMuPDF（fitz）、pypdf（纯 Python）做了对比，并以 pypdf 作为基准（1.0x）：

• Chunkr PDFLoader（全文）：747.9 ms，2,762 页/秒，相比 pypdf 快 15.9 倍。
• Chunkr PDFLoader（按页文档）：721.0 ms，2,865 页/秒，快 16.5 倍。
• PyMuPDF（fitz）：2,616.8 ms，789.5 页/秒，快 4.5 倍。
• pypdf（纯 Python）：11,900.5 ms，173.6 页/秒，基准线。

更贴近实际使用的是端到端测试。Chunkr 的"PDF + 递归分块"完整流程耗时 798.1 ms（2,589 页/秒），相比 pypdf + LangChain RecursiveTextSplitter 的 12,054.5 ms（171.4 页/秒），实现了约 14.9 倍 的整体加速。即便对比 PyMuPDF + LangChain 的组合（2,659.3 ms），Chunkr 也有明显优势。

这组数据的价值在于它衡量的是"读文件到切完块"的完整链路，而非单一环节，更能反映在真实数据管道中的收益。

PyMuPDF（fitz） 是对 MuPDF 渲染引擎的 Python 绑定，底层同样是 C/C++ 实现，因此在纯 Python 库中性能表现突出（约 4.5 倍于 pypdf）。然而即便如此，Chunkr 的 Rust 原生 PDF 加载器仍以约 3.5 倍的优势超过 PyMuPDF，说明 Rust 在内存管理和零拷贝字符串处理上的优势在 PDF 文本提取这类 IO 与解析混合的任务中依然显著。端到端流水线的测试方式更具实际参考价值：现实的 RAG 预处理不会单独测量 PDF 解析或分块，而是两者串行执行，任何一环的瓶颈都会拖累整体。Chunkr 将两步合并为单一 Rust 调用，减少了 Python 层的数据转换与内存拷贝开销，这也是其端到端倍数（14.9×）接近 PDF 解析单项倍数（15.9×）而非两者相乘的原因。

如何看待这些数据

从结果看，Rust 在这类 CPU 密集型、字符串与 IO 混合的任务上发挥出了语言层面的性能优势，尤其在固定字符分块、代码分块这类纯计算场景下，与纯 Python 实现拉开了量级差距。对于需要批量处理海量文档的检索系统来说，这种吞吐量的提升可以直接转化为更短的索引构建时间和更低的预处理成本。

不过也有几点值得冷静看待。其一，所有数据均来自作者单机（M4）的自测，缺少第三方复现；其二，吞吐量（MB/s）不等于分块质量，作者强调"不影响准确性"，但基准测试中并未给出准确性或召回率的对比指标；其三，BPE tokenizer 场景下 Chunkr 落后于 Chonkie，提示在选型时仍需结合具体的分块策略和下游 embedding 方案来评估。

对于正在搭建 RAG 流水线、且文档解析与分块已成为瓶颈的团队，Chunkr 值得放进候选清单里做一次实测。作者也在 GitHub 上公开了项目并征集反馈，感兴趣的开发者可以直接上手验证这些数字。