Unstructured：文档变结构化数据的开源 ETL

把 PDF、Word、扫描件拆成带类型的元素，再交给 RAG 或模型消费。

做文档类 RAG 的人都有一个共同的坑：把 PDF 一股脑转成纯文本，标题、正文、表格、页眉全混在一起，检索出来一段话你都不知道它在说哪一节。Unstructured 把这一步做成了正经的 ETL：先把文档拆成带类型的元素（Title、NarrativeText、Table、ListItem），再序列化成 JSON，下游想怎么用都行。仓库 Apache-2.0，约 1.6 万星（以 GitHub 为准）。

核心能力

1. partition：一个函数完成拆解
核心入口是 partition()，传文件路径或文件对象，返回一串元素对象，每个元素带 type、text、metadata。metadata 里有页码、坐标、所属父节点，这些字段在后面做引用溯源时是关键——用户问“这个结论哪来的”，你能直接定位到第几页哪一块。

2. 先分类型再拼文本，而不是无差别拼接
同样的内容，拼成一个长字符串和保留元素类型，对模型的效果差别很大。保留类型后，你可以在构建上下文时只取 NarrativeText 与 Table，丢掉 PageHeader、PageFooter 这类噪声；也可以把 Table 单独转成 Markdown 表格再喂。这一步做完，检索准确率通常会明显上升。

3. 表格与扫描件：高精度模式兜底
普通模式抽不出来的扫描 PDF，可以切 strategy="hi_res"，走版面检测 + OCR 的路径。代价是慢且吃资源，所以正确策略是先跑 fast 看结果，只在表格多或扫描件上开高精度。

4. 分块（chunking）按标题层级走
支持按标题分块（chunk_by_title），把同一小节的内容归到一块，并保留父子关系。对长报告很重要：按固定字数切会把一个结论切成两半，按标题切则保留了语义完整性。

5. 格式覆盖面广
官方列的支持类型包括 PDF、DOCX、PPTX、XLSX、HTML、图片、EML/MSG、EPUB 等。实际项目里常见的是混合输入：合同是扫描 PDF、报价是 Excel、需求是 Word，用同一套接口处理比给每种格式写一个解析器省很多事。

6. 开源库与企业平台是同一条路线
开源包自己跑，企业平台提供生产级的 partitioning、enrichment、chunking 与 embedding。好处是原型到生产不用换技术栈：先用开源版跑通，量大了再考虑托管。

使用上手

1. 装包。pip install unstructured，需要处理 PDF 时按官方文档补装对应依赖（如 poppler、tesseract）。
2. 先跑一份典型文件。用你手上最脏的那份 PDF 试，而不是用干净的示例文件。
3. 看元素类型分布。统计一下 type 字段，如果大量内容被归为 UncategorizedText，说明模式选错了，切 hi_res 再试。
4. 必要时做分块。需要进向量库时用 chunk_by_title，并保留 parent 关系。
5. 序列化落盘。把元素写成 JSON Lines，后续既可以直接进向量库，也可以回逆成 Markdown 人工检查。
6. 大批量时上并行。它是 CPU 密集型，按核数拆文件跑，不要单进程硬扑。

优点与不足

优点：

• 先分类型再拼文本，从根上解决“拼成一团”的问题。
• metadata 完善，页码与坐标让引用可溯源。
• 格式覆盖广，一套接口处理混合文档。
• Apache-2.0，商用友好，无传染性条款。

不足：

• 依赖较重，PDF 高精度模式需额外装系统库。
• hi_res 模式速度慢，大批量扫描件成本高。
• 中文表格的版式还原仍不稳定，需人工抽查。
• GitHub 语言标签与实际主体语言不一致，新手容易误解。

适合谁

• 做企业文档 RAG、需要引用溯源的开发者。
• 手里有大量扫描件、合同、报告的行业应用团队。
• 想先把文档清洗做好、再选向量库的工程师。

下载与访问

• 仓库：https://github.com/Unstructured-IO/unstructured
• 官网：https://unstructured.io/
• PyPI：https://pypi.org/project/unstructured/

许可证与部署

本文属于「项目」分类的 AI 资源专栏，更多评测见分类页。