Pathway RAG 中 TokenCountSplitter 和 RecursiveSplitter 分块策略怎么选？

Pathway RAG 中 TokenCountSplitter 和 RecursiveSplitter 分块策略怎么选【免费下载链接】pathwayPython ETL framework for stream processing, real-time analytics, LLM pipelines, and RAG.项目地址: https://gitcode.com/GitHub_Trending/pa/pathway在 Pathway Live Data Framework 里搭建 RAG 时DocumentStore会把文档依次做解析、分块chunking和建索引。整个文档被压缩成单个向量往往检索效果差——模型被迫把全部信息塞进一个表示里细节和上下文容易丢失。分块是这一步里直接影响检索质量的选择而 Pathway LLM xpack 提供的主要选项就是TokenCountSplitter和RecursiveSplitter。这篇文章基于项目文档Chunking 说明、Document Indexing 说明和源码给出两者的行为差异、选型依据以及一套可以用retrieve_query验证的分块配置方法。准备条件按文档要求安装 LLM xpackllm-app 文档 中的安装命令pip install pathway[xpack-llm] python-dotenv两个 splitter 都用 tiktoken 统计 token 数所以 token 长度上限是以“编码后的 token 数”为准而不是字符数。两个 Splitter 的行为差异两者的差异在 Chunking 文档 和 splitters.py 源码 中有明确说明TokenCountSplitter先按encoding_name指定的 tiktoken 编码把全文 tokenize再切成 token 数落在min_tokens到max_tokens之间的块并尝试在标点. ? !和换行处断开。它不关心句子或段落结构产出的是大小相对均匀的块。构造参数为min_tokens、max_tokens、encoding_name。RecursiveSplitter同样按 token 数衡量块长但切分点由一组有序的separators决定——从最细的分隔符开始尝试块仍超过chunk_size时回退到下一个更粗的分隔符直到所有块都小于chunk_size。例如可以先按\n\n切必要时再回退到句号.。它额外支持chunk_overlap让相邻块重叠以保留跨块上下文。文档同时提醒开启 overlap 会增加检索时的总块数可能影响性能。选型时可以按文档给出的这两条线索判断你要严格约束块的 token 上限/下限并且希望长度计算与 embedding 模型所用的分词对齐cl100k_base兼容 OpenAI 的 embedding 模型——用TokenCountSplitter你的文档有清晰的结构性分隔Markdown 标题、段落、句子希望块尽量落在这些边界上并且可能需要重叠上下文——用RecursiveSplitter并显式传入适合文档格式的separators。另一个来自文档的边界情况如果 parser 用的是DoclingParser它本身会按标题、段落、列表等结构做分块块长不均匀文档明确说“若需要更均匀的块可以在 DoclingParser 之上再叠加TokenCountSplitter或RecursiveSplitter”。也就是说结构感知的解析和 token 尺度的分块并不互斥。配置方法以下 Python 示例直接取自文档。TokenCountSplitterfrom pathway.xpacks.llm.splitters import TokenCountSplitter text_splitter TokenCountSplitter( min_tokens100, max_tokens500, encoding_namecl100k_base )这组配置产生 100–500 token 的块使用cl100k_base分词器文档说明其兼容 OpenAI 的 embedding 模型。RecursiveSplitter以 Markdown 文档为例splitter RecursiveSplitter( chunk_size400, chunk_overlap200, separators[\n#, \n##, \n\n, \n], # separators for markdown documents model_namegpt-4o-mini, )separators的顺序就是回退顺序文档示例给的就是面向 Markdown 的一组分隔符model_name用于让 tiktoken 按该模型的编码方式统计 token 数。注意chunk_overlap200意味着相邻块之间有 200 token 的重叠检索返回的块总量会比无重叠时更多。如果走 YAML 模板而非 Python项目文档同样提供了两种 splitter 的 YAML 配置形态见 RAG 配置示例 的 “Chunking (Splitters)” 部分字段与上面的 Python 参数一一对应本文以 Python 形式为准。把 Splitter 接进 DocumentStore来自 Document Indexing 文档 的最小用法准备一个字节流的data列、一个 embedder 和一个 retriever_factory再把 splitter 传给DocumentStorefrom pathway.xpacks.llm.document_store import DocumentStore from pathway.xpacks.llm.splitters import TokenCountSplitter import pathway as pw data_sources pw.io.fs.read( ./sample_docs, # 替换为你的文档目录需能读出 binary 数据 formatbinary, with_metadataTrue, ) text_splitter TokenCountSplitter() store DocumentStore( docsdata_sources, retriever_factoryretriever_factory, # 由 BruteForceKnnFactory 等构造见上文文档示例 splittertext_splitter, )换成RecursiveSplitter时只需把text_splitter换成上一节的配置对象其余不变。验证分块结果分块是否正确可以在两个层面检查验证手段都来自项目文档和测试代码。1. 用检索结果验证端到端。文档给出的方式是构造一个 queries CSV列固定为query、k、metadata_filter可选、filepath_globpattern可选printf query,k,metadata_filter,filepath_globpattern\n\Who is Regina Phalange?\,3,,\n queries.csvquery pw.io.fs.read( queries.csv, formatcsv, schemaDocumentStore.RetrieveQuerySchema ) result store.retrieve_query(query)运行retrieve_query后看命中的块是否落在你预期的边界上切得太大整段文档一块或太碎块内没有完整语义都会让查询匹配偏离。这一步能直接观察到 splitter 选择对检索内容的影响。2. 用单文档微验证只看分块行为不依赖向量。项目测试 test_splitters.py 展示了一个可以照抄的验证方式取一句 26 tokencl100k_base编码下的句子用\n\n重复拼接 5 段再用RecursiveSplitter(encoding_namecl100k_base, chunk_size30, chunk_overlap0)切分——由于chunk_size30大于一句的 26 token 而小于两句预期每个段落恰好成为一个块共 5 块且第一块内容等于原句。测试里的断言即验证标准len(result) 5且result.iloc[0].ret[0] txt。TokenCountSplitter的文档字符串splitters.py 中的 Example 段也给了一个文档示例输出对cooltext用TokenCountSplitter(min_tokens1, max_tokens1)分块结果为((cool, pw.Json({})), (text, pw.Json({})))。这只是文档示例用来说明输出形态是(chunk_text, metadata)的配对列表metadata 会传播给同一段输入产生的所有块实际分块时请按你的min_tokens/max_tokens判断不要把这个示例当成固定预期。限制与边界chunk_overlap开启后总块数增加文档明确提示这“could impact performance”——这是 RecursiveSplitter 路径上唯一被文档点名的代价配置 overlap 前需权衡检索延迟与跨块上下文的收益。文档示例中cl100k_base是“兼容 OpenAI embedding 模型”的编码如果你的 embedder 不是 OpenAI 系编码名应改为与该 embedder 匹配的分词口径文档没有给出其他编码的对照表只能依据 tiktoken 的编码列表自行确认。DoclingParser自身的结构分块不按 token 计数块长不均文档给出的处理方式是叠加分块器或设chunkFalse关闭其分块二者择一不要假设结构块与 token 上限同时受控。下一步可以按 Document Indexing 文档 中的 REST Server 一节把DocumentStore用DocumentStoreServer暴露为服务用curl -X POST http://localhost:8765/v1/retrieve发起查询请求在生产形态下复核分块效果。【免费下载链接】pathwayPython ETL framework for stream processing, real-time analytics, LLM pipelines, and RAG.项目地址: https://gitcode.com/GitHub_Trending/pa/pathway创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考