RAG 文本切分器
将长篇文本分割成适合 Embedding / RAG 输入的单位。支持 4 种策略：固定字符数、固定令牌数、段落单位、Markdown 标题单位分割，包含重叠调整、各分块可视化、JSON / JSONL / Markdown 导出功能。
完全免费
无需注册
浏览器内完成
即刻下载
5 种语言
深色模式
块数
0
平均
0
最大
0
📖 常见的坑
把长文本切分为便于送入 Embedding 的单位。处理全部在浏览器内完成，文本不会被发送。RAG 检索效果不佳的原因，多数不在嵌入模型，而在切分方式——答案被切在两个分块之间，或标题与正文被分到不同分块导致上下文丢失，这类简单原因居多。
| 情形 | 会发生什么 | 怎么处理 |
|---|---|---|
| 凭感觉决定分块大小 | 太小则答案装不进一个分块；太大则一个分块里混入多个话题，向量被稀释。嵌入表示的是整段文本的平均方向，混入的无关内容越多，向量就越是对任何问题都「有点像」，对任何问题都不够像。 | 起点建议 512~1,024 token，重叠 10~20%，然后实际统计语料中一条典型答案有多长。若答案只有两三句（如 FAQ），256 就够；若一条答案是整整一节流程说明，1,024 也不够。用 Token 计数器先掌握字数与 token 数的关系，决策会具体得多。 |
| 单纯按字数机械切分 | 按固定长度切分，会切在句子中间、表格中间、代码块中间。尤其在流程文档或参考资料中，表头与表体一旦被分到不同分块，该分块单独看就说不清这是什么表。即便被检索命中，送进 LLM 时语义也已无法还原。 | 请优先遵循结构边界。Markdown 可先按标题（##）切分，仍然过长再按段落、再按句子逐级下沉。此外，在每个分块开头补上「文档标题 > 章 > 节」的面包屑，准确率会明显提升——因为单独阅读该分块也能知道它在讲什么。 |
| 检索不到就换嵌入模型 | 比模型差异更先起作用的，是问题与文档之间的用词落差。用户问「登录不了」，文档标题却是「认证错误的处理」——语义相近，但向量距离并不像预期那样贴近。而依赖精确字符串匹配的查询（型号、专有名词）恰恰是向量检索最不擅长的领域。 | 请采用混合检索：让 BM25 之类的关键词检索与向量检索并行，再融合排序（如 Reciprocal Rank Fusion）。关键词一侧能稳妥命中型号与人名，向量一侧则覆盖各种同义表述。若仍不够，可让 LLM 为每个分块生成 3 条「该分块能回答的问题」并一同嵌入。费用可先用 Embedding 成本估算预估。 |
分块不是一次定好就可以放着不管的设置。请记录真实提出的问题，查看未能回答的案例，并区分两种成因：正确的分块根本没进入检索前列，还是进入了但信息被截断。前者是检索方式的问题，后者是切分粒度的问题。混淆两者去调参数，就永远无法改善。
📖 使用方法
-
1
粘贴PDF / Markdown / 文章
-
2
策略 + 大小字符/token/段落/标题
-
3
JSON / JSONLembedding 管道
❓ 常见问题
推荐大小？
256-512 / 512-1024
重叠多少？
10-20%
标题策略？
语义分块
🐛 此工具出现问题了吗？
免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。
✅
感谢您的反馈！
已送达运营者,将用于改进工具。