给知识库切文档，Unstructured 会先分清标题、正文和表格

给知识库准备文档时，直接每隔一千字切一刀，容易把一个小节的结尾与下一个小节的开头放在同一片段里。Unstructured先把文件分成标题、正文、列表项、表格等元素，再围绕这些元素组织后续分块。

完整开源README用LayoutParser论文演示提取过程，标题、作者、摘要和正文先成为可处理的内容。它的重点是为后续系统准备材料，不是直接替用户回答论文问题。

一份文档，不只是一堵文字墙

文档元素包含类型、文本、标识与元数据。官方元素说明区分Title、NarrativeText、ListItem、Table、Header等对象；元数据在可取得时还可保留文件名、页码、坐标与层级关系。

以为公共服务说明建立检索库为教学情境。一份文件前半讲申请资格，后半讲办理流程，如果只按字数拼接，检索片段可能同时夹带两类条件。先辨认标题与段落，才有机会让片段更接近文档本来的组织方式。

不过，标题类型是解析结果，不是作者意图的保证。一行很短的列表项可能被错认成Title，后面怎样合并小节，也就成为实际需要考虑的规则。

完整分块文档说明，普通分块尽量合并连续完整元素，只有单个元素超过上限时才做文本切分；表格单独处理，不与正文随意拼在一起。超长表格仍可能继续分成TableChunk。

by_title策略以Title启动新段，还可选择是否允许同一小节跨页。与此同时，它允许将过小的相邻小节合并，以缓解标题误判造成的碎片。需要严格保留每个小节边界时，可以关闭这项小节合并；不能只听到“按标题”就以为所有边界都天然固定。

这使调整更有对象：片段太碎时，先看标题识别与小节合并；某一长段被截断时，再看单元素大小限制。它比不断增加重叠字数，更能解释文档为什么会变成现在的样子。

一个分块可能由多页上的几个元素组成，合并后很难只填一个页码或坐标。Unstructured可通过metadata.orig_elements找回组成它的原始元素及各自元数据；序列化时，这部分会压缩编码保存，读取时需要相应解码。

因此，检索命中一段内容后，应用仍有机会展示它来自哪页、原来属于哪些元素，而不是只保留一条被拼接后的长字符串。元数据是否完整，取决于源文件与所用解析方式。

开源库采用Apache-2.0，不同文件类型仍需相应OCR、渲染或Office依赖。官方如今另推商业Transform v2，不能把其新模型效果直接当成本地开源库的表现。对于自建知识库，Unstructured值得看的成果是有结构、有出处的材料片段，让后面的检索先从一份组织清楚的输入开始。