Unstract：可靠的AI文档提取管道

基于大语言模型的结构化信息提取从企业文档中变得越来越具有挑战性。在我的AI咨询和研发项目中，我经常遇到涉及采购订单、检查记录、语音数据、医疗和人力资源文档、多源报告以及内部政策文档等用例。

为什么组织对结构化提取感兴趣？因为结构化信息可以被处理、分析，并与数据库、业务应用和自动化工作流集成。

然而，企业文档通常不遵循适合基于大语言模型处理的结构。它们可能具有多样化的布局，结合多列、旁注、页眉、页脚、正常阅读顺序之外定位的文本，以及跨页延伸、合并单元格和不规则行的表格。

文档也可能是扫描的、手写的或视觉质量差的。同样，重要信息可能包含在图表和图形中。

这是一个布局混乱的采购订单示例。

几个因素会降低基于大语言模型提取的质量。这些问题甚至在信息到达大语言模型之前就已产生。解析（将文档转换为机器可读形式）的第一步可能会扁平化表格、将值与其标签分离、跨页拆分行，或断开语句与其所属部分的连接。因此，提取可能产生包含错误信息的有效输出。

可靠的基于大语言模型的提取系统不仅应处理文档格式的多样性，还应处理组织需求的差异。即使对于相同的文档类型，不同组织可能需要不同的字段、验证规则和输出结构。因此，一次性模式和提示可能难以维护，因为新用例不断引入。

那么我们需要做什么来将混乱的文档转化为我们可以信任的结构化数据呢？

这就是本文要讨论的内容。我将讨论文档提取从基于规则到基于代理的方法的演变，以及生产就绪的文档提取管道需要什么。使用Unstract作为实际示例，我将演示如何构建、测试、评估和部署基于大语言模型和基于代理的文档提取管道。

1、文档提取是如何演变的

过去几年，文档提取已从指导软件在哪里找到值转变为解释该值的含义。

传统文档提取将OCR与文档模板、位置、关键字、正则表达式和规则相结合。固定规则读取所需字段旁边的文本或从页面预定区域提取值。

如果企业文档遵循稳定的格式（这很少见），这些方法仍然有效。布局、字段标签或文档变体的变化会破坏规则，并需要添加更多规则。

为新布局添加无数规则的问题由机器学习和专门的文档理解模型解决，这些模型可以识别文本块、表格、键值对和布局元素。然而，机器学习模型依赖于它们训练的标注示例。为组织的特定文档类型创建标注数据集可能过于昂贵和费力，尤其是当每种文档的示例很少时。

大语言模型引入了前所未有的灵活性。用户无需训练机器学习模型进行文档理解。相反，他们可以描述字段的含义，并要求以定义的结构返回结果。即使对于以前未见过的文档，这也有效。

几种基于大语言模型的实现是可能的。解析器优先方法在将文档传递给大语言模型之前，将其转换为机器可读形式（文本、Markdown、HTML）。这一步骤至关重要，因为丢失重要关系和未能保留布局可能导致错误的提取输出。

可以单独将文档页面发送到视觉大语言模型，以保留扫描表单、复杂布局表格、图表和其他依赖布局内容的更多视觉上下文。这种方法效果更好，但可能更慢、更昂贵且更难追踪。我的一篇文章解释了使用视觉大语言模型的高效解析方法。

如何使用AI准确提取文档中的所有内容要求AI模型以特定格式输出如何改变一切

我们也可以使用传统解析器解析较简单的内容（文本和表格），并使用视觉模型解释视觉元素（如图表、图形、图表）。在下面的文章中，我解释了这种混合方法，其中视觉元素被发送到视觉模型，解释被放置在正确的位置。我的下一篇文章实现了这种方法。

如何使用AI提取文档中的所有内容我创建了一个视觉增强的文档解析器和RAG分块器

代理工作流通过将不同阶段分配给专门的代理来扩展此过程。这些代理可以分析示例文档、生成模式和提取提示、测试输出、识别错误并优化配置。

尽管取得了这些进展，工程工作仍然存在。它只是从维护模板和规则转变为配置解析器、模式、提示、验证规则、评估集和部署工作流。

2、构建可靠的基于大语言模型的提取管道

可靠的基于大语言模型的文档提取管道由多个阶段组成。解析通常是第一步，它试图保留文档布局和元素之间的关系；如果失败，可能会向下游大语言模型发送误导性上下文，后者可能自信地提取错误信息。

需要一个模式来定义大语言模型应提取什么以及结果应如何组织。模式可以是手写的，也可以从任务规范和/或源文档推断（需要大语言模型或代理）。模式生成是一次性操作。批准的模式被存储、版本化并重用，直到提取需求发生变化。

解析后的内容、模式和提取提示然后传递给大语言模型（或代理）以返回提取的信息，并以所需结构组织。输出会根据模式进行验证，以确认所需字段和预期数据类型。然而，解析阶段的错误值仍可能通过验证，因为它可能是正确字段中的有效数字。我的下一篇文章实现了自动生成模式和符合模式的提取。

构建用于组织特定用例的通用知识提取AI框架允许非技术用户用自然语言指定需求，自动生成模式，并提取...

评估提取准确性对于应对此问题非常重要。提取的值可以与人工验证的参考数据进行比较，以计算准确性指标。然而，当提取管道投入运营时，参考数据将不可用。在这种情况下，源引用、值定位和大语言模型生成的置信度分数可以帮助人工审查。

最后一步包括部署经过测试的文档提取系统到业务系统。该系统可以部署为API，支持应用程序按需发送文档并接收结构化结果。它也可以部署为ETL（提取、转换、加载）管道，定期从定义的源（例如Google Drive、SharePoint）收集文档，自动处理，并将结果存储到数据库或组织的ERP中。

3、使用Unstract实践提取管道

构建可靠的文档提取管道需要一个受控的工作流，该工作流保留文档结构、形式化业务需求、验证和评估输出、支持人工监督，并将输出交付给现有系统。

为了演示如何实现这样的管道，我使用Unstract作为实际示例。Unstract允许用户构建可配置的、模式引导的文档提取系统。它解析源文档（提供多种解析选项），提取每个定义字段的上下文，并将该上下文和相应的提取提示传递给用户选择的大语言模型，以获得结构化输出。

要使用Unstract，只需克隆其GitHub仓库并运行安装脚本。

# 克隆并启动
git clone https://github.com/Zipstack/unstract.git
cd unstract
./run-platform.sh

随后，在浏览器中访问http://frontend.unstract.localhost，并使用用户名：unstract，密码：unstract登录。

我首先创建了一个Prompt Studio项目。Prompt Studio是一个无代码提示工程环境，您可以在其中加载示例文档并选择任何大语言模型和解析器的组合。

当我首次启动Unstract的开源版时，我配置了一个大语言模型、一个向量数据库、一个嵌入模型和一个文本提取器。

我加载了一个示例采购订单（+ 添加文档），该订单布局混乱（如文章开头所示）。期望从客户文档中获得此类结构是很常见的。如果此类文档未以正确的布局解析，提取器也会无法提取正确的值。

使用默认设置，我通过“+ 添加提示”为每个必需字段添加了提取提示，并指定了其预期输出类型，例如文本、数字、日期或JSON。下面的截图显示了生成的Prompt Studio配置。

可以在Settings → Parsers中选择解析器。我选择了LLMWhisperer，并使用通过Unstract Cloud获得的试用API密钥。用户也可以选择其他解析器，例如Unstructured社区版（开源）。

以下截图显示了提取和解析（原始视图）PDF的组合输出。LLMWhisperer保留了足够的行结构和跨页布局，使得提取提示能够在此示例中正确识别所需的值。

4、使用Unstract的云版本

Unstract Cloud是该平台的托管版本，不需要用户操作底层基础设施。它包含一个代理提示工作室（截至2026年8月的Beta功能），该工作室使用多个代理进行模式生成、创建提取提示和提取结构化输出。

它分析输入文档，提议提取的字段，协调不同标签的字段，并生成JSON模式和提取指令。生成的配置和输出仍需用户审查。

为了测试，我注册了14天的Unstract Cloud试用，并创建了一个空白的代理提示工作室项目。在设置中，我选择GPT-4o作为提取器和代理大语言模型，LLMWhisperer作为解析器。然后我使用一个手写的就业申请样本来构建和测试提取管道。

解析后，摘要代理识别潜在字段，包括它们的名称、描述、数据类型和示例值。另一个代理协调包含相似信息但在不同文档中使用不同标签的字段。最终代理然后将合并的字段映射转换为JSON模式。

以下截图显示了我遵循的序列，从文档解析和字段识别到模式生成、提示创建和提取。

解析文档后，摘要代理提出了一组潜在的提取字段。我可以在继续之前编辑这些字段。然后我使用已验证数据选项生成参考数据。我审查了生成的值并在未更改的情况下批准了它们。

接下来，一个代理基于提出的字段和文档结构生成了JSON模式。在审查并批准模式后，我使用另一个代理创建提取提示。我在未更改的情况下审查并批准了提示，并运行了提取，之后符合模式的输出在“提取数据”选项卡中可用。

截图显示文档的布局在很大程度上得到保留，这使得提取代理能够识别所需的字段并以批准的结构返回它们。对于此示例文档，所有提取的值都与批准的参考数据匹配。但是，由于参考数据和提取输出是从同一文档生成的，因此此结果应解释为样本内一致性检查，而不是提取准确性的独立测量。

然后我测试了从建筑蓝图中提取信息（见下文）。

代理提示工作室正确提出了左右列的所有字段；但是，它未能提出图表的字段。然后我编辑模式以仅添加顶部图表的尺寸对象，重新生成提取提示和参考数据，并再次运行提取。这一次，所有定义的字段都正确提取了。这表明人工参与审查和改进模式和/或提取提示很重要。

5、部署项目

测试提取项目后，它可以在开源和云版本中部署为API或ETL管道。API处理应用程序提交的文档，并按需返回结构化JSON。ETL管道自动从源收集文档，运行提取工作流，并将结构化结果存储到目标。

Prompt Studio项目可以直接使用部署为API部署为API，这会自动创建所需的工作流。或者，该项目可以导出为可重用工具并添加到自定义工作流。工作流连接输入源、处理工具和输出目标，然后可以配置为API或ETL部署。

我选择了基于工作流的方法，以便在API和ETL部署中重用相同的导出提取工具。我首先在Prompt Studio的导出菜单中选择导出为工具。在工作流部分，我通过选择API作为源和目标创建了API工作流，将导出的Prompt Studio工具添加为处理步骤，并将工作流部署为API。

我通过从API部署下载其预定义的Postman集合来测试部署的API，无需编写代码。将集合导入Postman桌面应用程序后，我打开了处理文档请求，选择了正文，在文件字段中上传了输入文档，然后单击发送。API处理了文档并以JSON响应返回了提取的数据。

要将项目部署为ETL管道，我配置了单独的源和目标连接器。在Settings → Connectors下，我将Google Drive连接为传入采购订单的输入源。然后可以安排管道定期检查选定的文件夹，并为新文档运行提取工作流。

对于目标，我使用Aiven for PostgreSQL创建了一个空的免费层PostgreSQL数据库，并通过其服务URI将其连接到Unstract。然后ETL管道可以将提取的结构化数据直接写入数据库。

这是部署的ETL管道。它每小时运行一次，以拉取新的采购订单，从中提取数据，并将结构化数据推送到Postgres数据库。

以下截图显示了Postgres数据库中提取记录的示例。

6、关键要点和限制

可靠的文档提取系统取决于整个提取管道的质量。提取模型无法恢复重要内容，或者布局信息在解析过程中丢失。即使文档解析正确，不正确的模式仍可能导致错误的提取输出。

Unstract允许用户构建提取管道，通过API或ETL管道对其进行测试和部署。其基于云的代理提示工作室（截至2026年8月的Beta版）进一步促进了这一过程，并在我的实验中显示出有希望的结果。它展示了基于代理的方法如何减少配置文档提取所涉及的手工工作。

但是，在提示工作室和代理提示工作室中评估准确性需要仔细解释。从文档中提取的值被用作参考数据来评估在同一文档上执行的提取。参考数据还包含各个字段的示例，使得准确性评估具有误导性。评估方法应将用于模式和提示开发的文档与包含以前未见过的文档的保留测试集分开。

此外，正如LlamaParse最近的论文中提到的，单个聚合分数无法揭示提取错误的具体来源。因此，他们使用顺序不敏感的统一度量F1来衡量值准确性，并辅以单词级和页面级定位F1来衡量源可追溯性。

此外，某些任务可能涉及通过公共字段链接的多个文档。例如，我测试了一个示例，其中采购订单中每个项目的附加信息包含在单独的物料清单中，通过物料编号链接。代理提示工作室无法构建正确的模式。

可追溯性是代理提示工作室中的一个重要功能。可以单击源文档中可用高亮显示的字段，以检查提取值在源文档中的位置。但是，在当前测试版（截至2026年8月）中，它仅部分正确工作。例如，请参阅以下屏幕截图。

尽管高亮显示的位置接近正确位置，但用户可能仍需四处查找以找到所需的值。

代理提示工作室还必须允许用户指定其需求并直接从任务描述推断模式。这就是我们的生成式AI工具包（称为GAIK）的模式生成器和提取器组件所做的。

这对于长文档也很重要，这些文档可能有数百或数千个潜在的结构化字段需要提取。由于代理提示工作室创建了所有潜在字段的摘要，用户可能必须大量编辑模式以删除许多字段并仅保留所需的字段。

原文链接: Building Reliable AI Document Extraction Pipelines

汇智网翻译整理，转载请标明出处