Unstract 评测：用 LLM 做文档抽取前，先看清 AGPL 和流程复杂度

Unstract 解决的是非结构化文档抽取到结构化输出的问题。它适合把文档处理接入 API、ETL 或后台审批流程，而不是只给用户一个聊天答案。

如果你有大量格式相近但内容不同的业务文件，它比临时 prompt 更接近可运营系统。

企业文档自动化的难点不只是读懂文字，而是把内容变成字段。发票金额、合同期限、客户名称、表单字段、审批条件都需要稳定抽取。Unstract 的意义在于把 LLM 抽取纳入工作流，而不是停留在一次性聊天窗口。

这类项目对 AdSense 内容也比较友好，因为它关注企业效率和数据工程，不涉及诱导或违规用途。

AGPL-3.0 是采用时必须正视的点。它不是不能商用，但对闭源网络服务很敏感。公司如果想把 Unstract 包进 SaaS 或客户可访问服务，应在架构前期判断源码开放义务。

因此商业可用性给 5 分，重点是许可摩擦而不是项目质量。

非技术用户可以先准备 30 份样本文档，并定义必须抽取的字段。不要只问“能不能总结”，而要看字段是否稳定、缺失值如何标记、错误能否被人工复核。

如果字段定义不清楚，任何 LLM 抽取平台都会变成不可靠自动化。

让 Codex 先搭一个单字段抽取流程：输入 10 份低敏文档，输出 JSON，记录每个字段的来源页、置信度或人工备注。确认稳定后再增加字段和 API。

不要第一天就接入生产审批流。

Unstract 的上限是把文档抽取变成可运营的数据管道。边界是 LLM 抽取永远需要质量控制，尤其在金额、合同、身份信息等高风险字段上。

它适合辅助人，而不是无监督替代人。

什么时候比普通 OCR 更合适

如果目标只是把图片变成文字，OCR 就够了。如果目标是把文档变成字段、JSON、API 或 ETL 输入，Unstract 的定位更合适。它关心的是抽取流程，而不是单次转换。

最终判断

Unstract 适合认真做文档自动化的团队，尤其是有重复文件类型和明确字段定义的业务。采用前必须先处理 AGPL-3.0 和质量审查机制。