当前位置：首页 > news >正文

OHiFormer：基于结构相对位置编码的Transformer模型实现UI屏幕摘要

news 2026/5/26 22:15:51

1. 项目概述：当Transformer遇见UI——屏幕摘要的挑战与机遇

在移动应用开发与用户体验设计的日常工作中，我们常常面临一个看似简单却极其繁琐的任务：如何向用户、测试人员或文档编写者清晰、准确地描述一个手机屏幕界面（UI）的内容与功能？传统方法依赖人工编写，不仅耗时耗力，而且难以保证一致性。随着应用界面日益复杂，元素数量动辄上百，这个痛点愈发明显。屏幕摘要（Screen Summarization）任务应运而生，它旨在自动生成简洁的文本描述，概括屏幕的核心内容和功能。这对于提升视障用户的可访问性（通过屏幕阅读器）、加速应用文档（如用户手册）的生成、乃至辅助自动化测试脚本的编写，都具有巨大的实用价值。

然而，将自然语言生成技术直接套用到UI屏幕上，会遇到一个根本性的挑战：UI屏幕并非普通的图像或文本序列，而是一个具有严格层次化结构的多模态对象集合。每个UI元素（如按钮、文本框、图片）不仅包含视觉外观（图像切片）、文本标签，还拥有在视图层级树（View Hierarchy）中的精确位置（边界框）和父子关系。早期的尝试，如Screen2Words模型，虽然开创性地将UI摘要任务形式化，但其采用绝对位置编码（如节点的深度、前序索引）来表征结构，这种方法存在天然局限——它只告诉模型“某个元素在树中的哪个绝对位置”，却无法直接表达“这个按钮是那个文本输入框的子控件”或“这两个开关是并列关系”等关键的层次化依赖关系。这就像只给你一张公司通讯录（只有姓名和工号），却不告诉你汇报关系，你很难理解整个组织的运作逻辑。

正是在这样的背景下，OHiFormer（Object-wise Hierarchical Dependency-based Transformer）模型被提出。它的核心思想非常直观且有力：将UI屏幕上的每个对象视为自然语言处理中的一个“词元”（Token），然后利用Transformer强大的自注意力机制来建模这些对象之间的相互关系。但关键在于，它没有使用标准的绝对位置编码，而是创新性地引入了结构相对位置编码，专门设计了一种名为OHi-Attention的注意力机制，将UI对象间的父子、兄弟等层级关系直接注入到注意力权重的计算中。这样一来，模型在“阅读”UI时，不仅能“看到”每个元素是什么，还能“理解”它们之间是如何组织、关联的，从而生成更符合逻辑、更精准的摘要。

我曾在多个涉及UI自动化理解和文档生成的项目中，深刻体会到忽略结构关系所带来的问题，比如生成的描述会混淆主次功能，或无法正确关联相关的UI元素组。OHiFormer的思路，正是从工程实践痛点出发，对Transformer这一“万能骨架”进行的一次精准“外科手术”，使其能更好地消化UI这种特殊的“结构化多模态数据”。接下来，我将深入拆解这个模型的每一个技术细节、实现要点，并分享在实际复现和应用此类模型时可能遇到的“坑”与应对技巧。

2. 核心思路拆解：为什么是“结构相对位置编码”？

要理解OHiFormer的创新之处，我们必须先厘清UI数据结构的特点以及现有方法的不足。一个UI屏幕，在开发者眼中，远不止是一张截图（Screenshot）。它背后对应着一份结构化的元数据，通常是一个JSON文件，描述了一个视图层级树。树上的每个节点对应一个UI对象，节点属性包括其类名（如android.widget.Button）、资源ID（如com.example:id/login_button）、屏幕上显示的文本、以及一个精确的边界框坐标[left, top, right, bottom]。

2.1 绝对位置编码的局限

先前的主流方法，如Screen2Words，采用了一种三维坐标[depth, preorder_index, postorder_index]来表示一个节点在树中的绝对位置。

深度：节点到根节点的距离。
前序索引：在深度优先搜索（DFS）前序遍历中访问该节点的顺序。
后序索引：在DFS后序遍历中访问该节点的顺序。

这种方法为每个节点分配了一个唯一的、可学习的嵌入向量。然而，其问题在于：

无法直接表达关系：两个具有父子关系的节点，它们的绝对位置向量在嵌入空间中的距离，未必比两个毫无关系的节点更近。模型需要从大量数据中隐式地学习这种关系，效率低下且不直观。
泛化能力弱：对于一棵新的、未见过的UI树，即使其结构模式（如一个列表项内包含一个图标和一段文字）很常见，模型也需要重新适应其绝对位置编码，因为索引值完全不同了。
对复杂UI不友好：当UI对象数量很多（超过300个）时，树结构变得庞大而复杂。绝对位置编码难以让模型聚焦于局部紧密相关的对象组，容易导致生成的摘要过于笼统或遗漏关键细节。

这就像用经纬度坐标（绝对位置）来描述城市中建筑的关系，虽然精确，但无法直接告诉你“A大厦是B公司的总部，而C餐厅在A大厦的一楼”（相对关系）。

2.2 结构相对位置编码的优势

OHiFormer的灵感来源于代码摘要（Code Summarization）领域。在代码的抽象语法树（AST）中，节点间的结构关系（如父子、兄弟）对于理解程序逻辑至关重要。研究者们发现，将节点间的最短路径距离或相对层级关系编码进Transformer的注意力机制，能显著提升模型性能。

OHiFormer将这一思想迁移到UI领域。它不再关注节点在整棵树中的“绝对地址”，而是关注任意两个节点之间的“相对关系”。具体来说，它定义了一个层次化依赖矩阵H。对于树中的任意两个对象oi和oj：

如果oi是oj的子节点，则H(i, j) = 2。
如果oi是oj的父节点，则H(i, j) = 1。
其他情况（无直接父子关系），H(i, j) = 0。

这个简单的0/1/2矩阵，直接、显式地刻画了UI对象间最核心的两种结构关系。随后，这个矩阵被映射为一个可学习的嵌入表ER，从而得到结构相对位置编码R。在计算注意力时，这个编码会与查询（Q）和键（K）进行交互，从而让注意力分数不仅基于对象的内容相似性，还基于它们的结构关联性。

这么做的工程意义何在？

归纳偏置（Inductive Bias）的引入：我们明确告诉模型“UI对象是有层次结构的”，这相当于为模型提供了一个强大的先验知识，让它不用从零开始学习这个规律，从而加速训练，提升在小数据集上的性能。
更好的泛化性：无论树有多大，节点索引如何变化，“父子”、“兄弟”这种关系定义是稳定的。模型学到的“父子关系应具有较高注意力”这一模式，可以很容易地迁移到新的、结构类似的UI上。
聚焦局部上下文：注意力机制会天然地给具有直接父子或兄弟关系的对象分配更高的权重，这使得模型在生成描述时，能更好地将相关元素组合在一起描述（例如，“一个包含用户名和密码输入框的登录表单”）。

2.3 OHiFormer的整体架构蓝图

理解了核心思路后，我们来看OHiFormer的整体工作流程，它遵循了经典编码器-解码器（Encoder-Decoder）框架，但每个环节都针对UI数据做了定制：

对象嵌入：对于屏幕上的每个UI对象，分别提取其多模态特征。
- 图像：根据边界框裁剪出对象区域，缩放至64x64像素，通过预训练的ResNet-18提取视觉特征。
- 文本：提取对象显示的文本和资源ID（Resource-id），通过GloVe词嵌入进行编码，并通过求和池化得到固定维度的文本特征。
- 位置：使用可学习的傅里叶特征编码方法（借鉴VUT模型）对边界框坐标[l, t, r, b]进行编码，得到空间位置特征。
- 融合：将图像特征和文本特征拼接后投影，再与位置特征相加，最终形成每个对象的统一嵌入向量。所有对象的嵌入按顺序排列，构成UI的序列化表示X。
OHiFormer编码器：这是模型的核心。编码器接收序列X，并利用OHi-Attention机制进行多层变换。OHi-Attention在标准自注意力计算(QK^T)/√dk的基础上，额外加上了两项：(QR^T)/√dk和(KR^T)/√dk。这两项将之前计算好的结构相对位置编码R注入其中，使得注意力权重的计算同时考虑了内容相关性和结构相关性。
Transformer解码器：一个标准的Transformer解码器，以自回归的方式，根据编码器输出的上下文表示，逐个生成摘要词汇。

这个流程清晰地展示了如何将多模态、结构化的UI数据，“翻译”成一句流畅的自然语言描述。接下来，我们将进入实操环节，看看如何具体实现这些步骤。

3. 实操要点与核心环节实现

理论清晰后，实现是关键。下面我将结合论文细节和工程经验，拆解OHiFormer实现中的核心环节、参数选择以及需要注意的陷阱。

3.1 数据预处理与对象嵌入生成

这是整个流程的第一步，也是最容易出错的环节。UI的原始数据通常来自Android的uiautomator或iOS的XCUITest，格式为视图层级树JSON。

实操步骤：

解析视图层级树：你需要一个解析器来遍历JSON树，提取每个节点的属性。关键字段包括：class,text,resource-id,bounds（边界框）。注意，有些节点可能是不可见的（visibility=gone）或尺寸为0，这些节点通常需要过滤掉，因为它们不对应屏幕上的实际元素。
构建对象列表：遍历后，你得到一个UI对象列表O = {o1, o2, ..., on}。每个对象oi的属性集合为P = {p_image, p_text, p_rid, p_bbox}。
图像裁剪与处理：
- 边界框处理：bounds格式通常是[x1, y1, x2, y2]，需确保坐标在屏幕范围内。有时坐标会超出截图尺寸，需要进行clamp操作。
- 裁剪与缩放：使用PIL或OpenCV根据边界框从屏幕截图中裁剪出对象区域。这里有一个重要技巧：直接缩放小区域到64x64可能导致严重失真。论文中采用ResNet-18，其输入是3x64x64。对于文本按钮等小对象，建议先将其粘贴到一个64x64的空白画布中央，再进行归一化，这比直接拉伸效果更好。
- 特征提取：加载一个在ImageNet上预训练的ResNet-18，移除最后的全连接层，使用其全局平均池化后的输出（512维）。然后通过一个线性层投影到指定的嵌入维度d（论文中为128）。
文本与资源ID处理：
- 分词与截断：对text和resource-id字段进行分词（或按字符处理），并截断或填充到最大长度l（论文设为10）。
- 词嵌入：使用预训练的GloVe词向量（如glove.6B.100d）。对于OOV词，使用随机初始化或零向量。注意：resource-id通常像com.example:id/button_ok，包含路径信息，可以按/和_分割后再嵌入，能更好地捕捉语义。
- 池化：对一个对象内多个词的嵌入向量进行求和池化，得到该对象文本侧的统一向量（128维）。然后将text和resource-id的向量拼接（256维），再通过一个线性层投影回128维，得到最终的文本特征e_text。
边界框编码：
- 论文采用了VUT中的可学习傅里叶特征方法。这是一种将连续坐标映射到高维空间的有效技术，比简单的线性投影更能捕捉空间周期性。具体实现时，可以将[l, t, r, b]四个坐标值分别进行傅里叶特征映射（使用sin/cos函数和可学习频率参数），然后拼接起来，再通过一个线性层得到128维的位置特征e_bbox。
特征融合：
- 将图像特征e_image和文本特征e_text在特征维度上拼接（256维），通过一个线性层W_F投影到128维。
- 最后，将投影后的特征与位置特征e_bbox相加：X = concat(e_image, e_text) * W_F + e_bbox。这个“相加”操作是关键，它将空间位置信息直接注入到每个对象的融合特征中，为后续的结构感知注意力提供基础。

注意事项：多模态特征的对齐至关重要。确保图像、文本、位置特征的嵌入维度d一致。在训练初期，由于文本和图像模态差异巨大，融合后的特征可能不稳定。可以考虑在投影层后加入LayerNorm，或者对图像/文本特征分别进行归一化后再拼接，有助于训练收敛。

3.2 层次化依赖矩阵与OHi-Attention实现

这是OHiFormer的灵魂所在，实现时需要格外小心。

实操步骤：

构建依赖矩阵H：
- 输入是视图层级树，每个节点对应一个UI对象索引。
- 你需要实现一个函数，对于任意两个节点索引i和j，判断它们在树中的关系。
- 高效实现技巧：在预处理时，为每个节点记录其父节点索引。构建H矩阵时，对于一个n x n的矩阵，朴素的双重循环复杂度是O(n²)。当n很大时（如超过500），这会成为性能瓶颈。可以利用稀疏矩阵格式（如COO）来存储，因为H中非零元素（表示直接父子关系）非常少。或者，在计算注意力时动态计算关系，而不是构建完整矩阵。
- 论文中定义了H(i,j)=2表示i是j的子节点，=1表示i是j的父节点。注意这是非对称的，即H(i,j)不一定等于H(j,i)，这正好符合父子关系的方向性。
生成结构相对位置编码R：
- 定义一个可学习的嵌入层：self.struct_embed = nn.Embedding(3, d)。因为H中的值只有0, 1, 2三种。
- 将矩阵H（元素值为0,1,2）作为索引，输入嵌入层，得到R，其形状为[n, n, d]。R[i, j, :]就是一个d维向量，表示对象i相对于对象j的结构位置编码。

实现OHi-Attention：

标准的多头注意力计算为：Attention(Q, K, V) = softmax( (QK^T) / √dk ) V。

OHi-Attention的修改如下：

# 假设 Q, K 形状为 [batch, heads, n, d_k], R 形状为 [batch, n, n, d] 或 [n, n, d] # 需要将R投影到与Q/K相同的head空间，或者更简单的方法，将Q/K投影到d维与R交互 # 论文中的公式是：softmax( (QK^T + QR^T + KR^T) / √dk ) V # 其中 R 是结构编码。QR^T 和 KR^T 需要维度对齐。 # 一种实现方式是：将R通过一个线性层投影到 d_k 维度，得到 R_k，然后计算： attn_scores = torch.matmul(Q, K.transpose(-2, -1)) # [b, h, n, n] # 计算 QR^T 项：Q是[b, h, n, d_k], R是[b, n, n, d] -> 需要将R变换并广播 # 我们可以将R视为与head无关，先投影：R_proj = linear(R) # [b, n, n, d_k] # 然后计算: qr_term = torch.matmul(Q, R_proj.transpose(-2, -1)) # [b, h, n, n] # 同理计算 kr_term = torch.matmul(K, R_proj.transpose(-2, -1)) # 最终： attn_scores = (attn_scores + qr_term + kr_term) / math.sqrt(d_k) attn_weights = F.softmax(attn_scores, dim=-1) output = torch.matmul(attn_weights, V)

维度对齐的陷阱：这是实现中最容易出错的地方。确保QR^T和KR^T计算后的张量形状与QK^T一致，都是[batch, heads, n, n]。通常的做法是将R从[n, n, d]通过一个线性层投影到[n, n, d_k]，然后在head维度上进行广播。
梯度流：确保结构嵌入层self.struct_embed的参数能够通过QR^T和KR^T项接收到梯度，从而在训练中学习到有意义的相对位置表示。

实操心得：在初次实现时，可以先忽略QR^T和KR^T项，只实现标准注意力，确保模型能正常训练并过拟合一个小数据集。然后再加入结构项，观察验证集指标是否有提升。同时，可以可视化训练后的self.struct_embed.weight，看看模型为“父子”(1)、“子父”(2)、“无关”(0)这三种关系学到了什么样的向量，这有助于理解模型是否真的利用了结构信息。

3.3 模型训练与解码策略

模型搭建好后，训练策略同样重要。

训练配置要点（基于论文）：

模型尺寸：4层编码器，4层解码器，8个注意力头，嵌入维度d=128。这是一个较小的模型，适合在单张消费级GPU（如RTX 3080 10G）上进行实验。
优化器：Adam，初始学习率5e-5。这是一个比较小的学习率，因为使用了预训练的ResNet和GloVe，需要微调。
正则化：Dropout比率设为0.2，用于防止过拟合。
批大小：仅为4。这是因为UI序列长度n（对象数量）可变，且可能很长，导致内存占用大。如果GPU内存不足，可以考虑梯度累积。
早期停止：在验证集性能连续30个epoch不提升时停止训练，最大epoch为100。
损失函数：标准的交叉熵损失，用于自回归语言建模。

解码策略：

在测试阶段，使用集束搜索，束宽为4。集束搜索是一种启发式图搜索算法，在每一步保留概率最高的k个候选序列，能比贪婪搜索获得更好的结果。
长度惩罚：论文未提及，但在实践中，为集束搜索加上长度归一化（如除以生成长度的α次方，α通常取0.6-0.7）可以避免模型倾向于生成过短的句子。

数据与词汇表：

使用Screen Summarization数据集，需按应用划分训练、验证、测试集，防止数据泄露。
构建词汇表时，只保留出现次数大于5的单词，低频词用<unk>代替。总词汇量约10000，包括特殊标记<start>,<end>,<pad>。

4. 效果评估、问题排查与深度分析

模型训练完成后，我们需要科学地评估其性能，并理解其内部工作机制。论文提供了详实的实验，这里我们结合实践进行解读。

4.1 性能评估与对比分析

论文使用BLEU、ROUGE-L和CIDEr作为评估指标。这些指标各有侧重：

BLEU：侧重n-gram精度，衡量生成摘要与参考摘要表面词的重合度。BLEU-1到BLEU-4分别计算1到4元组的精度。
ROUGE-L：基于最长公共子序列，能更好地捕捉句子结构的相似性。
CIDEr：通过TF-IDF加权，强调生成摘要应包含那些在参考摘要中重要（频繁出现）且在其他摘要中不常见（具有区分度）的词汇，对摘要的信息含量和多样性更敏感。

OHiFormer的优势体现：从表1结果看，OHiFormer在CIDEr指标上领先幅度最大（17.58%）。这说明OHiFormer生成的摘要不仅用词准确（BLEU高），而且能生成更多样化、信息更丰富的描述。这正是因为结构相对位置编码帮助模型更好地理解了UI的功能分组。例如，对于一个设置页面，模型能识别出“声音设置”区块（包含静音开关、音量滑块等子对象）是一个整体，从而生成“Sound settings panel with mute switch and volume slider”这样具体、信息量大的句子，而不是泛泛的“A page with many switches and sliders”。

与其它结构编码方法的对比（表2）：论文对比了多种将结构信息注入Transformer的方法：

Embed-3D：Screen2Words的方法，使用绝对位置（深度、前序、后序索引）的三维坐标嵌入。
Learnable-Fourier+MLP：VUT的方法，将上述3D坐标映射到傅里叶空间。
SPR-abs / SPR-rel：来自机器翻译领域的方法，分别使用节点深度的绝对差和相对差作为结构编码。

OHiFormer（基于父子关系）在多数指标上胜出。这证明了对于UI这种强交互、组件化的结构，直接建模父子依赖关系比单纯使用深度距离更有效。父节点通常代表容器（如LinearLayout），子节点才是具体功能项，这种关系直接对应了“包含”语义，对摘要生成至关重要。

4.2 可视化分析与可解释性

论文通过可视化编码器最后一层几个注意力头的热力图，提供了宝贵的模型可解释性分析（图8）。这是我们理解模型“看到了什么”的关键。

如何解读注意力热力图？热力图的横纵轴都是UI对象索引。颜色越亮（如红色），表示在生成当前上下文表示时，该行对象（作为Query）对位列对象（作为Key）的关注度越高。

从热力图中我们能学到什么？

关注关键对象：热力图显示，模型对包含关键词（如“language”、“choose”）的对象（图8中对象17, 18, 26, 27）给予了高度关注。这说明模型成功地将视觉/文本特征与摘要任务关联了起来。
捕捉层级路径：热力图中可见清晰的“注意力路径”。例如，从对象17（可能是“English”选项）到其祖先节点（对象0, 1, 2, 5, 9）的注意力权重较高。这直观地展示了OHi-Attention如何沿着视图树的路径传播信息，将叶子节点的具体内容与其所在的上下文容器关联起来。
识别兄弟关系：对象{17,18}和{26,27}对同一组祖先节点表现出相似的注意力模式。这表明模型识别出它们是兄弟节点（共享相同的父容器），在语义上属于同一类别或同一功能区。

实操建议：在你自己的实现中，一定要加入注意力可视化工具。这不仅有助于调试（例如，检查模型是否关注了无关背景），更能让你直观感受结构编码是否生效。如果OHi-Attention工作正常，你应该能看到比标准注意力更清晰、更聚焦于结构相关对象的注意力模式。

4.3 常见问题与排查指南

在复现或应用OHiFormer时，你可能会遇到以下典型问题：

问题1：模型性能不佳，生成的摘要泛泛而谈（如“这是一个有很多按钮的屏幕”）。

可能原因A：结构编码未生效。
- 排查：检查依赖矩阵H的构建逻辑是否正确。打印几个样本的H矩阵，手动验证父子关系是否对应。可视化注意力热力图，看是否有关注层级路径的模式。
- 解决：确保QR^T和KR^T项被正确加入注意力分数计算，并且其梯度在反向传播中流通。可以尝试增大结构嵌入的初始学习率，或单独为其设置一个更高的学习率。
可能原因B：多模态特征融合不当。
- 排查：分别检查图像、文本、位置分支的输出特征。它们的尺度（均值、方差）是否差异巨大？在融合前进行层归一化（LayerNorm）可能会有帮助。
- 解决：尝试不同的融合方式，例如拼接后接更深的MLP，或者使用门控机制（Gating Mechanism）动态调整图像和文本特征的贡献。
可能原因C：数据噪声大。
- 排查：UI数据中可能存在大量无文本、无意义或重复的对象（如不可见的布局视图）。这些噪声对象会干扰模型学习。
- 解决：在预处理阶段进行更激进的过滤。例如，过滤掉text和resource-id都为空、或面积过小、或位于屏幕边缘不可交互的对象。

问题2：训练速度慢，内存占用高。

可能原因A：序列长度n过大。
- 排查：统计数据集中UI对象数量的分布。Transformer的注意力计算复杂度是O(n²)，当n很大时（>500），计算和内存开销剧增。
- 解决：
  1. 对象过滤：同问题1C。
  2. 序列截断：设定一个最大对象数（如200），只保留前N个对象（可按面积、或按在树中的深度排序）。
  3. 使用稀疏注意力：OHi-Attention中的结构矩阵H本身是稀疏的（只有直接父子关系非零）。可以尝试实现稀疏版的注意力计算，只计算H中非零位置对应的注意力分数，能极大降低计算量。
可能原因B：批大小太小。
- 解决：使用梯度累积。例如，设置实际批大小为4，但每4个step才更新一次梯度（累积步数为4），这相当于模拟批大小为16的训练效果，能提高训练稳定性，但不会增加单步内存消耗。

问题3：在嘈杂/不完整的屏幕截图（如加了高斯噪声）上性能下降严重。

分析：论文的噪声注入实验（图7）表明，所有模型的性能都会下降，但OHiFormer下降幅度最小，显示了其鲁棒性。这是因为OHiFormer不仅依赖图像模态，还严重依赖文本和结构信息。即使图像模糊，只要视图层级树（元数据）是完整的，模型依然能通过文本和结构关系推断出大量信息。
实践启示：在实际应用中，如果屏幕截图质量不可控（如不同设备截图压缩率不同），确保获取高质量的视图层级元数据比获取高清截图可能更重要。模型的多模态特性使其对单一模态的损坏有一定容错能力。

5. 超越论文：扩展思路与工程化思考

OHiFormer提供了一个强大的基线模型，但在实际产品化或应对更复杂场景时，还有诸多可以探索和改进的方向。

5.1 模型扩展与改进

引入视觉骨干网络预训练：论文使用ImageNet预训练的ResNet-18。可以尝试使用在更大规模视觉-语言数据集（如LAION）上预训练的CLIP ViT作为图像编码器。CLIP的视觉特征本身就和文本语义空间对齐，可能对理解UI中图标与文本的对应关系更有帮助。
处理动态与交互式UI：当前模型处理的是静态屏幕快照。真实的UI是动态的，有状态变化（如按钮点击后变色、列表展开）。可以考虑将UI状态变化序列作为输入，使用循环或时序Transformer来建模动态过程，生成如“点击搜索按钮后，出现包含以下结果的列表...”的摘要。
融合屏幕流信息：一个应用由多个屏幕组成。可以引入图神经网络（GNN）或记忆网络，建模屏幕之间的跳转关系，生成更连贯、更具任务导向的多屏幕摘要。
解耦结构与内容编码：当前方法将结构编码R与内容Q/K交互。可以探索更解耦的方式，例如使用一个单独的结构感知模块来生成对象关系的权重，再与内容注意力权重相乘。

5.2 工程落地考量

推理速度优化：对于需要实时生成摘要的场景（如辅助屏幕阅读），推理速度至关重要。
- 模型轻量化：考虑使用更小的嵌入维度、更少的层数，或使用知识蒸馏将大模型的能力迁移到小模型上。
- 缓存机制：对于常见的、结构化的UI组件（如标准Material Design按钮、iOS导航栏），可以预计算其摘要模板，模型只需填充具体内容（如按钮文字），大幅减少计算。
领域适应与少样本学习：你的应用可能涉及大量特定领域的UI（如金融交易界面、工业控制面板）。收集大量标注数据成本高昂。
- 利用无监督数据：可以收集大量未标注的UI截图和层级数据，进行自监督预训练（例如，掩码对象预测、对比学习）。
- 提示学习：为OHiFormer的输入添加可学习的提示向量（Prompt），在少量标注数据上微调这些提示，而不是整个模型，实现高效领域适应。
评估指标的局限性：BLEU/ROUGE等基于n-gram重叠的指标，有时无法准确反映摘要的事实准确性和功能完整性。一个摘要可能BLEU得分高，但错误描述了某个按钮的功能。
- 人工评估：在关键项目中，必须引入人工评估，制定详细的评估标准（如：信息完整性、准确性、流畅度、简洁性）。
- 任务导向评估：将生成的摘要用于下游任务（如，基于摘要自动执行UI操作），以下游任务的成功率作为最终评估标准，更具说服力。

5.3 一个简单的实践建议

如果你正准备尝试将OHiFormer或类似技术应用于实际项目，我的建议是：从简单开始，快速迭代。

不要一开始就追求复现论文中的所有细节。可以先搭建一个简化版：

使用标准的Transformer编码器-解码器。
输入只使用对象的GloVe文本嵌入和边界框的简单线性编码（忽略图像）。
在Screen Summarization数据集的一个子集上训练，验证流水线是否通畅。

在基线模型能工作后，再逐步加入：

图像模态（ResNet特征）。
绝对位置编码（3D坐标）。
最后，替换为OHi-Attention。

这种渐进式的方法能帮助你隔离问题，清晰地看到每一项改进（如图像、结构编码）带来的实际收益。同时，密切关注注意力可视化，它是你理解模型内部运作、诊断问题的最有力工具。

屏幕摘要是一个充满挑战又极具应用价值的领域。OHiFormer通过巧妙地引入结构相对位置编码，为Transformer理解UI的复杂结构打开了一扇新的大门。它不仅提升了摘要质量，其背后“显式建模关系”的思想，对于任何需要处理图结构、树结构数据的多模态任务，都有着广泛的借鉴意义。希望这篇深入的拆解能为你探索这一领域提供扎实的起点和实用的指南。

查看全文

http://www.jsqmd.com/news/892757/