FEATURED · 精选文章

LangChain 文本分割器详解:字符分割、Token 分割、硬约束递归分割实战

发布时间 / 2026/9/14 19:32:24
来源 / 创域科博编辑部
栏目 / 资讯中心
LangChain 文本分割器详解:字符分割、Token 分割、硬约束递归分割实战 我挖掘了一个巨牛的 人工智能 学习网站通俗易懂风趣幽默忍不住分享一下给大家。点击跳转到网站。前言在 RAG 检索增强生成完整流程中文档加载器负责读取 PDF、Markdown、TXT 等各类文件并统一转换为 LangChain 的Document文档对象。但原始文档往往篇幅很长无法直接送入向量库与大模型大模型存在固定上下文窗口上限超长文本会直接超出限制整块大文本检索粒度粗糙用户查询很难精准匹配到关键信息完整长文本嵌入向量时算力消耗更高检索准确率偏低。因此文本分割Text Splitters是 RAG 不可或缺的核心环节作用就是将长篇文档拆分为短小、语义连贯、便于检索与模型读取的文本块。本文结合实战代码拆解 LangChain 三类主流文本分割方案基于字符分割、基于 Token 分割、递归式硬约束分割同时讲解中文文档适配优化方案。一、文本分割核心设计思路文本拆分本质是把大文本切割为可管理的小块行业主流实现思路分为两大分支按文本长度切割分为字符长度统计、Token 长度统计两种计量标准兼顾语义完整性优先按照段落、换行、标点分层切割尽可能不破坏完整句子、段落语义重叠块设计通过chunk_overlap让相邻文本块保留重复内容避免关键信息被分割在两块边界而检索丢失。二、基于字符长度分割 CharacterTextSplitter2.1 基础原理CharacterTextSplitter是最简单的文本分割器通过内置len()函数统计字符数量判断块大小仅支持单一分隔符切割默认推荐分隔符优先级[\n\n, \n, , ]。 核心特点软性长度约束优先保全完整段落语义。 当一段文本使用指定分隔符切割后字符长度依旧超过chunk_size分割器不会强行截断文本而是完整保留整块内容并打印日志提示块超长避免一句话、专业术语被劈成无意义片段影响向量检索效果。2.2 完整实战代码from langchain_community.document_loaders import UnstructuredMarkdownLoader from langchain_text_splitters import CharacterTextSplitter # 加载本地Markdown文档 markdown_path ../Docs/Markdown/脚手架级微服务租房平台QA.md loader UnstructuredMarkdownLoader(markdown_path) data loader.load() # 加载完成得到Document列表 # 初始化字符文本分割器 text_splitter CharacterTextSplitter( separator\n\n, # 段落分隔符双换行区分不同段落 chunk_size100, # 目标单块字符上限 chunk_overlap20, # 相邻文本块重叠字符数 length_functionlen, # 使用len统计字符长度 is_separator_regexFalse # 分隔符非正则表达式 ) # 执行文档分割 texts text_splitter.split_documents(data) # 循环打印前10个分割后的文本块 for document in texts[:10]: print(* * 30) print(f{document}\n)2.3 超长日志说明与解决方案运行代码后控制台会持续输出如下提示Created a chunk of size 128, which is longer than the specified 100 Created a chunk of size 133, which is longer than the specified 100 Created a chunk of size 1171, which is longer than the specified 100很多新手会误以为是程序报错实际这是预期内的提示日志分割器优先使用\n\n段落分隔若单段文本全部字符超过设定chunk_size无更小分隔符可以拆分该段落时有两种选择方案 A强行截断文本会拆分完整语句、专有名词语义破碎方案 B完整保留整个超长段落输出日志告知用户 分割器默认选择方案 B保证语义完整。优化处理方式 观察日志大部分文本块长度集中在 100~200 字符直接调大chunk_size参数即可大幅减少超长块提示我设置的是\n\n 双换行这通常代表段落之间text_splitter CharacterTextSplitter( separator\n\n, chunk_size200, chunk_overlap20, length_functionlen, is_separator_regexFalse, )三、基于 Token 长度分割适配 OpenAI 大模型3.1 Token 与 tiktoken 基础认知所有 OpenAI 系列大模型GPT-3.5、GPT-4不直接识别字符底层以 Token 为最小计算单位输入输出都受 Token 数量限制。因此对接 OpenAI 接口时基于 Token 计数分割是最精准的方案。tiktoken是 OpenAI 官方分词工具cl100k_base是OpenAI tiktoken 提供的一套 BPE 分词编码规则专门给gpt-3.5-turbo、GPT-4、OpenAI 向量嵌入模型使用用来把文字拆成模型能识别的最小单元 Token词汇表总量约 100256 个。名字拆解含义cl Chat models对话类模型专用100k 词汇表约 10 万条 tokenbase 基础标准版编码tiktoken 简单演示代码import tiktoken # 加载GPT系列通用编码规则 enc tiktoken.get_encoding(cl100k_base) # 文本编码为Token数字列表 enc_output enc.encode(my name is LiHua!) print(f编码后的token{enc_output}) # 遍历每个Token还原对应文本片段 for token in enc_output: byte_text enc.decode_single_token_bytes(token) real_text byte_text.decode(utf-8) print(ftoken:{token} 对应文本片段:{real_text})输出结果编码后的token[2465, 836, 374, 14851, 39, 4381, 0] token:2465 对应文本片段:my token:836 对应文本片段: name token:374 对应文本片段: is token:14851 对应文本片段: Li token:39 对应文本片段:H token:4381 对应文本片段:ua token:0 对应文本片段:!3.2 LangChain Token 分割器使用CharacterTextSplitter.from_tiktoken_encoder()快速创建基于 Token 计数的分割器底层自动调用 tiktoken 统计 Token 数量参数chunk_size代表 Token 上限。from langchain_community.document_loaders import UnstructuredMarkdownLoader from langchain_text_splitters import CharacterTextSplitter markdown_path ../Docs/Markdown/脚手架级微服务租房平台QA.md loader UnstructuredMarkdownLoader(markdown_path) data loader.load() # 创建基于tiktoken的Token分割器 text_splitter CharacterTextSplitter.from_tiktoken_encoder( encoding_namecl100k_base, chunk_size200, # 单块最大200个token chunk_overlap50 # 块重叠50个token ) texts text_splitter.split_documents(data) # 打印前10个分割结果 for document in texts[:10]: print(* * 30) print(f{document}\n)该分割器依旧是软性约束超长段落不会强制截断控制台同样会打印 Token 数量超限日志适合优先保证段落完整、对接 OpenAI 的知识库场景。基于字符串长度分割和基于Token长度分割的代码写法区别一、核心 4 大差异点1. 长度计算标准最关键区别1普通写法length_functionlen统计字符个数中文 1 个字 1、英文 1 个字母 1、标点 1和模型真实消耗的 token 数量完全无关适合简单测试、本地开源模型粗略分割。2from_tiktoken_encoder()快捷方法底层自动替换 length_function使用tiktoken(cl100k_base)统计GPT 真实 token 数量chunk_size200 代表最多 200 个大模型输入 token精准匹配 OpenAI GPT3.5/GPT4 上下文窗口线上生产必用。2. 分隔符传参方式不同1普通构造器CharacterTextSplitter(separator\n\n)参数是单个字符串 separator仅使用\n\n这一种分隔符切割没有分层递归逻辑只会按双换行一刀切文档一段超长时不会尝试换行、空格二次分割直接整块保留。2from_tiktoken_encoder 内部自带separators[\n\n, \n, , ]列表多层优先级分隔符自动递归切割先段落\n\n→ 单行\n→ 空格会多层拆分尽可能把文本压缩到 chunk_size 以内语义完整性更好代码看不到分隔符参数是方法内部封装写死的。3. 依赖与适用场景不同1普通字符分割无需安装 tiktoken仅按字符切割不贴合 GPT 模型限制适合演示、非 OpenAI 模型、简单短文。2tiktoken token 分割必须安装tiktoken库严格对齐 GPT 输入限制防止调用接口时报上下文超限企业 RAG、对接 OpenAI 接口标准写法。四、硬性长度约束RecursiveCharacterTextSplitter 递归分割器4.1 核心优势前面两种分割器都存在软性约束会产生超长文本块。如果业务场景严格限制单块长度比如模型窗口极小、向量库对文 本长度有硬性限制需要使用RecursiveCharacterTextSplitter递归分割器支持多层级分隔符优先级列表递归分层切割硬长度约束所有分割后的文本块长度一定小于等于设定chunk_size同样支持字符计数、Token 计数两种模式。默认分隔符优先级[\n\n, \n, , ]切割逻辑自上而下递归执行先用双换行\n\n按段落切割切割后块仍超限使用单换行\n分行切割依旧超限使用空格分词切割无可用分隔符时直接强制截断文本保证长度合规。4.2 Token 版递归分割实战代码from langchain_community.document_loaders import UnstructuredMarkdownLoader from langchain_text_splitters import RecursiveCharacterTextSplitter markdown_path ../Docs/Markdown/脚手架级微服务租房平台QA.md loader UnstructuredMarkdownLoader(markdown_path) data loader.load() # 递归式Token分割器硬约束块长度 text_splitter RecursiveCharacterTextSplitter.from_tiktoken_encoder( encoding_namecl100k_base, chunk_size100, chunk_overlap0, ) texts text_splitter.split_documents(data) # 打印前10个分割结果 for document in texts[:10]: print(* * 30) print(f{document}\n)运行后不会再输出块超长日志但会出现完整句子、词语被强制拆分的情况牺牲部分语义完整性换取严格统一的文本块长度。五、中文文档分割优化方案原生默认分隔符仅适配英文文本中文长句仅依靠空格、换行分割极易将完整词语、一句话拆分为零散汉字破坏语义。 自定义分隔符列表新增中文句号、逗号优先按完整句子切割大幅提升中文知识库分割效果text_splitter RecursiveCharacterTextSplitter( separators[ \n\n, # 段落 \n, # 单行 。, # 中文句号分句 , # 中文逗号分句 , , ], chunk_size200, chunk_overlap30, length_functionlen )切割优先级段落 → 单行 → 完整中文句子 → 空格最大程度保留中文语句完整性。六、三类分割器选型总结分割器长度计量长度约束适用场景CharacterTextSplitter字符 len ()软性保留超长段落Markdown、分段清晰文档追求完整语义CharacterTextSplitter(tiktoken)Token 计数软性对接 GPT 系列模型、段落完整优先RecursiveCharacterTextSplitter字符 / Token 双支持硬性全部块合规严格限制文本长度、模型窗口小、线上生产强约束场景通用参数配置建议chunk_size中文知识库推荐 150~300Token 模式 100~250chunk_overlap设置为 chunk_size 的 1/4 ~ 1/3平衡上下文完整性与冗余纯中文文档必须自定义分隔符添加。分句符号只要调用 OpenAI 相关模型优先选用 tiktoken Token 分割避免上下文超限报错。结语文本分割是决定 RAG 问答准确率的关键步骤没有万能分割器需要根据文档格式、使用的大模型、业务长度限制灵活选择。分段清晰的 Markdown、问答文档优先使用软性约束分割器保证语义无分段纯长文本、有严格长度限制场景选用递归硬约束分割器并针对中文场景优化分隔符列表兼顾检索精度与系统稳定性。
RELATED — 相关阅读

相关资讯

LATEST — 最新资讯

最新发布

TODAY — 本日精选

新闻

WEEKLY — 本周精选

新闻

MONTHLY — 本月精选

新闻