【人工智能】Transformers之Pipeline（二十三）：文档视觉问答（document-question-answering）

本文对transformers之pipeline的文档视觉问答（document-question-answering）从概述、技术原理、pipeline参数、pipeline实战、模型排名等方面进行介绍，读者可以基于pipeline使用文中的2行代码极简的使用多模态中的文档视觉问答（document-question-answering）模型。

weixin_48007632

2373人浏览 · 2024-11-12 19:25:08

weixin_48007632 · 2024-11-12 19:25:08 发布

一、引言

二、文档问答（document-question-answering）

2.1 概述

2.2 impira/layoutlm-document-qa

2.3.1 pipeline对象实例化参数

一、引言

pipeline（管道）是huggingface transformers库中一种极简方式使用大模型推理的抽象，将所有大模型分为音频（Audio）、计算机视觉（Computer vision）、自然语言处理（NLP）、多模态（Multimodal）等4大类，28小类任务（tasks）。共计覆盖32万个模型

今天介绍多模态的第一篇：文档问答（document-question-answering），在huggingface库内有201个文档问答（document-question-answering）模型。

二、文档问答（document-question-answering）

2.1 概述

文档问答（也称为文档视觉问答）是回答文档图像上的问题的任务。文档问答模型以（文档，问题）对作为输入，并以自然语言返回答案。模型通常依赖于多模态特征，结合文本、单词位置（边界框）和图像。

2.2 impira/layoutlm-document-qa

LayoutLM系列模型是微软发布的、文档理解多模态基础模型领域最重要和有代表性的工作。目前为止总计发布LayoutLM v1、LayoutLM v2、LayoutXLM、LayoutLM v3四个版本：

LayoutLM v1：首次在一个框架内联合学习文本（text）和布局（layout）用于文档级预训练的模型。
LayoutLM v2：在一个单一的多模态框架中对文本（text）、布局（layout）和图像（image）之间的交互进行建模。
LayoutXLM：LayoutXLM是 LayoutLMv2的多语言扩展版本。
LayoutLM v3：借鉴了ViLT和BEIT，不需要经过预训练的视觉backbone，通过MLM、MIM和WPA进行预训练的多模态Transformer。在以视觉为中心的任务上（如文档图像分类和文档布局分析）和以文本为中心的任务上（表单理解、收据理解、文档问答）都表现很好。

2.2.1 LayoutLM v1

LayoutLMv1的架构相当简洁，其输入源于表格图像（见图3右下角），该图像经处理后产出两部分关键信息：

文本特征表示：这一过程涉及从图像中提取文字信息。具体来说，通过应用PDF/OCR技术，图像被解析为一系列bounding boxes（边界框），每个框界定了一段文本的位置，用坐标(x0, y0, x1, y1)表示，相当于文本在表单中的位置编码。接下来，执行文本嵌入，这是NLP领域的一项基本操作，即将识别的文字转换为高维向量。此外，为了整合位置信息，这些坐标经过归一化处理至0到1000之间，旨在消除因图像尺寸差异可能引起的识别偏差。
图像特征表示：至于图像本身的特征提取，则借助Faster R-CNN模型作为基础网络，负责捕捉图像的视觉特征。特别地，为了与文本特征中的[CLS]标记相对应，采用整个图像的ROI特征作为全局表示，其余特征则与特定文本块一一匹配。

完成上述步骤后，经过预训练的模型（LayoutLM依然依托Transformer架构）会融合这些经过预处理的文本特征与图像特征。此综合特征向量随后可被用于各种下游任务的进一步处理和分析。

2.2.2 LayoutLM v2

文本和版式的预训练已经在多种富含视觉元素的文档理解任务中证明了其有效性，这得益于其高效的模型架构以及大规模未标注扫描/数字文档的优势。微软提出了LayoutLMv2架构，并引入新的预训练任务，以便在一个单一的多模态框架中对文本、版式和图像之间的交互进行建模。具体而言，通过使用双流多模态Transformer编码器，LayoutLMv2不仅利用现有的掩码视觉语言建模任务，还采用了新的文本-图像对齐和文本-图像匹配任务，这使得模型在预训练阶段能更好地捕捉跨模态交互。同时，它还将空间感知的自注意力机制整合到Transformer架构中，从而使模型能够充分理解不同文本块之间的相对位置关系。实验结果显示，LayoutLMv2大幅度超越了LayoutLM，并在多种下游富含视觉元素的文档理解任务上达到了新的最佳水平，包括FUNSD（0.7895 → 0.8420）、CORD（0.9493 → 0.9601）、SROIE（0.9524 → 0.9781）、Kleister-NDA（0.8340 → 0.8520）、RVL-CDIP（0.9443 → 0.9564）以及DocVQA（0.7295 → 0.8672）。

2.2.3 LayoutXLM

LayoutXLM是 LayoutLMv2的多语言扩展版本。结合文本、版式和图像的多模态预训练已经在视觉丰富的文档理解任务上达到了最先进的（SOTA）性能，这展示了跨不同模态联合学习的巨大潜力。LayoutXLM是一个面向多语言文档理解的多模态预训练模型，旨在为视觉丰富的文档理解打破语言障碍。为了准确评估LayoutXLM，论文中还引入了一个多语言表单理解基准数据集，名为XFUND，该数据集包含了7种语言（中文、日语、西班牙语、法语、意大利语、德语、葡萄牙语）的表单理解样本，并为每种语言的手工标注了键值对。实验结果表明，LayoutXLM模型在XFUND数据集上显著超越了它之前的跨语言预训练模型的SOTA性能。

2.2.4 LayoutLM v3

自监督预训练技术在文档AI领域取得了显著进展。大多数多模态预训练模型采用掩码语言建模（MLM）目标来学习文本模态上的双向表示，但它们在图像模态的预训练目标上存在差异。这种不一致性为多模态表示学习增加了难度。LayoutLMv3旨在通过统一的文本和图像掩码方式预训练多模态Transformer以服务文档AI。此外，LayoutLMv3还通过word-patch alignment目标进行预训练，通过预测文本词对应的图像块是否被掩码，来学习跨模态对齐。

这一简单统一的架构和训练目标使得LayoutLMv3成为既适用于文本为中心也适用于图像为中心的文档AI任务的通用预训练模型。

实验结果表明，LayoutLMv3不仅在以文本为中心的任务上，包括表单理解、收据理解及文档视觉问答，取得了最前沿的表现，而且在以图像为中心的任务上，如文档图像分类和文档布局分析，也同样表现出色。

如下图所示，与之前的工作（例如，DocFormer[2]和SelfDoc[31]）的比较：

（1）图像嵌入：LayoutLMv3使用线性patches来减少CNN的计算瓶颈，并消除在训练目标检测器时对区域监督的需求；

（2）图像模态的预训练目标：LayoutLMv3学习重构遮罩patches的离散图像tokens，而不是原始像素或区域特征，以捕获高层次的布局结构而不是噪声细节。

2.3 pipeline参数

2.3.1 pipeline对象实例化参数

model（PreTrainedModel或TFPreTrainedModel）— 管道将使用其进行预测的模型。对于 PyTorch，这需要从PreTrainedModel继承；对于 TensorFlow，这需要从 TFPreTrainedModel继承。
tokenizer ( PreTrainedTokenizer ) — 管道将使用其对模型的数据进行编码的 tokenizer。此对象继承自 PreTrainedTokenizer。
image_processor ( BaseImageProcessor ) — 管道将使用的图像处理器来为模型编码数据。此对象继承自 BaseImageProcessor。
modelcard（str或ModelCard，可选） — 属于此管道模型的模型卡。
framework（str，可选）— 要使用的框架，"pt"适用于 PyTorch 或"tf"TensorFlow。必须安装指定的框架。
task（str，默认为""）— 管道的任务标识符。
num_workers（int，可选，默认为 8）— 当管道将使用DataLoader（传递数据集时，在 Pytorch 模型的 GPU 上）时，要使用的工作者数量。
batch_size（int，可选，默认为 1）— 当管道将使用DataLoader（传递数据集时，在 Pytorch 模型的 GPU 上）时，要使用的批次的大小，对于推理来说，这并不总是有益的，请阅读使用管道进行批处理。
args_parser（ArgumentHandler，可选） - 引用负责解析提供的管道参数的对象。
device（int，可选，默认为 -1）— CPU/GPU 支持的设备序号。将其设置为 -1 将利用 CPU，设置为正数将在关联的 CUDA 设备 ID 上运行模型。您可以传递本机torch.device或str太
torch_dtype（str或torch.dtype，可选） - 直接发送model_kwargs（只是一种更简单的快捷方式）以使用此模型的可用精度（torch.float16，，torch.bfloat16...或"auto"）
binary_output（bool，可选，默认为False）——标志指示管道的输出是否应以序列化格式（即 pickle）或原始输出数据（例如文本）进行。

2.3.2 pipeline对象使用参数

image（str或PIL.Image）——管道处理三种类型的图像：

包含指向图像的 http 链接的字符串
包含图像本地路径的字符串
直接在 PIL 中加载的图像
该管道可以接受单幅图像或一批图像。如果给定单幅图像，则可以将其广播到多个问题。

question( str) — 针对文档提出的问题。
word_boxes（List[str, Tuple[float, float, float, float]]，可选）— 单词和边界框的列表（标准化 0->1000）。如果您提供此可选输入，则管道将使用这些单词和边界框，而不是在图像上运行 OCR 来为需要它们的模型（例如 LayoutLM）导出它们。这允许您在管道的多次调用中重复使用 OCR 的结果，而不必每次都重新运行它。
top_k（可选int，默认为 1）— 返回的答案数量（将按可能性顺序选择）。请注意，如果上下文中没有足够的选项，我们将返回少于 top_k 个答案。
doc_stride（int，可选，默认为 128）— 如果文档中的单词太长，无法满足模型的问题，则会将其分成几个部分，并有一定的重叠。此参数控制重叠的大小。
max_answer_len（int，可选，默认为 15）——预测答案的最大长度（例如，只考虑长度较短的答案）。
max_seq_len ( int，可选，默认为 384) — 传递给模型的每个块的标记中整个句子（上下文 + 问题）的最大长度。如果需要，上下文将被分成几个块（使用doc_stride重叠）。
max_question_len ( int，可选，默认为 64) — 标记化后问题的最大长度。如果需要，它将被截断。
handle_impossible_answer（bool，可选，默认为False）——我们是否接受不可能作为答案。
lang（str，可选）— 运行 OCR 时使用的语言。默认为英语。
tesseract_config（str，可选）——运行 OCR 时传递给 tesseract 的附加标志。
timeout（可选float，默认为 None）— 等待从网络获取图像的最长时间（以秒为单位）。如果为 None，则不设置超时，并且调用可能会永远阻塞。

2.3.3 pipeline返回参数

score（float）—— 与答案相关的概率。
start ( int) — 答案的起始词索引（在输入的 OCR 版本中或提供的中 word_boxes）。
end ( int) — 答案的结束词索引（在输入的 OCR 版本中或提供的中 word_boxes）。
answer( str) — 问题的答案。
words ( list[int]) — 答案中每个单词/框对的索引

2.4 pipeline实战

基于pipeline的document-question-answering任务，采用impira/layoutlm-document-qa进行文档视觉问答，代码如下：

import os
os.environ["HF_ENDPOINT"] = "https://hf-mirror.com"
os.environ["CUDA_VISIBLE_DEVICES"] = "2"

from transformers import pipeline
from PIL import Image

document_qa = pipeline(task="document-question-answering",model="impira/layoutlm-document-qa")
image = Image.open("./image.jpg")                   
output=document_qa(
    image=image,
    question="What is the purchase amount?",
)
print(output)

需要先安装tesseract-ocr：