文本从整体结构上区分，大致可分为有明确层次结构的文档和一般文档，有明确层次结构的文档如html，markdown等，这类文档相似内容分布在相同的标题下。如果破坏结构切割可能会导致文档检索不全的问题，这时候使用有针对性的切割器，先从文档结构层面对文档做初步切分，切割后的长文本再用文本切割器进行切分，是合理的处理方案。

每种切割器都有适用的独特场景，不能一概而论，要根据实际场景中通过考虑“语义完整性要求”，“上下文边界要求”，“技术栈一致性要求”，“性能与成本控制要求”等方面有侧重地选择切割器。以下是不同切割器在不同场景选型的考量。

RecursiveCharacterTextSplitter

优点：

1） 保持语义单元完整性，如代码、json等，不会出现语句被切割导致乱码情况
2） 轻量、速率极快，无需外部模型
3） 输出块的大小相对均匀
4） 支持多语言

缺点：

1）规则驱动，并不能真正按照语义切割，不够智能
2）高度依赖于分隔符列表，如果列表配置不当，严重影响切割效果
3）最终生成的 Token 数不可预测，可能会超出后续模型 max tokens限制
4）合并策略（合并后为一个文本块）简单（在 chunk_size 内尽可能多的合并），可能会导致一个块包含多个不相关短句，也可能会把一个连贯的长逻辑分割开，影响 LLM 答案准确性和连贯性

总结：

语义和结构优先,破坏语义结构会破坏信息价值的场景

1）考虑保持文本的结构化语义优先级高于 token 数量的计算精确度。
2）高度结构化的文档内容（如 html,markdown,yaml,json,xml等）
3）对语义完整性要求极致（如法律条文，合同，学术论文，技术标准，操作手册等）
4）多语言混合格式内容的文档（如文档中除自然语言还穿插有 json，代码，公式等)

NLTKTextSplitter

优点

1）基于句子分割，保持语义完整性
2）使用 NLTK 的预训练模型 punkt，分割智能程度有限提升（如英文的人名 David.Smith, 会保持人名完整）

缺点

1）中文文档支持不足
2）合并策略粗糙（按照固定长度 sentences_per_chunk合并），无法保证块内语义连贯性

总结

不建议在生产环境应用

spaCyTextSplitter

优点

1）优先在句子边界切割，高质量保持句子完整性和语义连贯性
2）基于强大的语言学模型
3）按 token 数进行合并，块且边界一定是完整句子
4）多语言支持（需要对应语言的 spaCy 模型）

缺点

1）依赖 spaCy 模型，对资源要求较高，不够轻量
2）块的大小波动较大
3）速率较低

总结

1）数据是纯自然语言，句子是核心语义单元
2）小说、新闻文章、论文、产品描述、法律条文，纯文本无格式但保持完整语言结构的文档
3）对语言完整性要求较高，不接受从句子中间被切断

以上的切割器都是按句子切割，能够保持句子语义完整性

tiktoken标记切割器

优点

​1）分割精确
2）与 OpenAI 模型完美对齐
3）速率极快

缺点

1）破坏句子或单词结构
2）块的物理长度不可控（相同 token 数的块，字符数可能差异较大）
3）与开源的 Sentence Transformer 模型（BGE，all-MiniLM 有自己的 tokenizer）不匹配
4）依赖 overlap 的配置（需要设置足够大的 overlap来确保被切断语义单元的上下文完整），导致向量数据库存储和检索压力

总结

​1）使用 OpenAI LLM模型的场景
2）要求 token 计算精确度有严格要求
3）切割效率要求较高，海量数据处理处理效率更快
4）强大的多语言支持，不需要切换模型

SentenceTransformersTokenTextSplitter

优点

​1）与 Sentence Transformer 模型（如 BGE, all-MiniLM）对齐，适合检索和嵌入
2）分割精确

缺点

​1）破坏句子结构
2）依赖特定模型

总结

在使用 Sentence Transformers模型的场景，使用此切割器效果更好

关于切割器选型的总结

1. 一致性原则：你的文本分割器应该与你的嵌入模型和LLM的tokenizer保持一致。

   • OpenAI生态 -> 用 tiktoken
   • Hugging Face / Sentence Transformers 生态 -> 用 SentenceTransformersTokenTextSplitter

2. 质量优先原则：如果一致性不是问题（例如，你只关心内容而不调用外部API），且对语义完整性要求高，选择 spaCyTextSplitter。

3. 实验验证：没有绝对的“最佳”。在你的测试集上，用不同的分割器生成块，设置不同的 chunk_size(如512,1024)，然后比较最终的检索质量和答案生成质量。这是最可靠的判断方法。

4. 重叠（Overlap）是关键：无论选择哪种分割器，一定要设置合理的 chunk_overlap（例如50-100个token）。这可以有效地防止一个完整的语义单元被硬生生切断，能显著提升检索召回率。

5. 分层切割策略：对于结构复杂的文档（如HTML、Markdown），不要一刀切。应采用递归切割：先按标题（#， <h1>）等大边界分割，再在章节内部使用上述切割器进行细粒度分割。LangChain的RecursiveCharacterTextSplitter正是此思想的体现。

​