GUI元素定位中的词汇耦合：句子嵌入跨移动端与Web的标签追踪

# GUI元素定位中的词汇耦合：句子嵌入在移动与Web平台跨标签追踪
来源：https://arxiv.org/html/2608.21794
Qijia Chen  
所属机构：计算机科学系  
所属机构：赫尔辛基大学  
所属机构：芬兰赫尔辛基  
电子邮件：[[email protected]](mailto:)
Giulio Jacucci  
所属机构：计算机科学系  
所属机构：赫尔辛基大学  
所属机构：芬兰赫尔辛基  
电子邮件：[[email protected]](mailto:)
###### 摘要
在GUI定位评估中，通过将UI元素暴露为文本来进行评估的方法，常将高指令-元素嵌入相似度视为语义定位的证据。我们通过跨三个移动与Web基准测试的研究表明，这种解释常被可见标签的恢复所混淆。词汇基线方法在Top-1指标上仍具有竞争力，标签贫乏的目标对于纯文本方法而言依然较弱，而编码器的Top-1命中率可由词汇排名、候选池大小及标签类型预测。我们将每个操作视为同屏排序任务，将五种现成的单向量编码器与词汇基线方法进行比较。编码器能恢复部分词汇遗漏的情况，但可部署的融合方案带来的增益远小于目标感知预言机（oracle）的增益。这些发现表明，基于嵌入的评估可能将可见标签的恢复与语义GUI定位混为一谈。因此，基于嵌入的评估应报告词汇基线、标签类型分层和可部署融合诊断结果。我们发布的仓库提供了分析脚本和去文本化的逐步面板：https://github.com/qijia123/lexical-coupling-release。

## 1 引言
参考图注  
图1：测量审计概述。  
(A)基于文本元数据的GUI定位被视为给定指令下的同屏候选排序。  
(B)高指令-元素嵌入相似度可能反映的是可见标签重叠，而非语义定位。  
(C)我们将现成的单向量编码器与词汇基线进行比较，并通过标签类型分层、目标文本依赖性扰动、LCC和ESH诊断结果。  
GUI代理必须将自然语言指令映射到屏幕上的可操作元素 (8 (https://arxiv.org/html/2608.21794#bib.bib6); 10 (https://arxiv.org/html/2608.21794#bib.bib7); 3 (https://arxiv.org/html/2608.21794#bib.bib4); 21 (https://arxiv.org/html/2608.21794#bib.bib5))，而基准测试则提供了使这种映射可度量的元素级目标 (5 (https://arxiv.org/html/2608.21794#bib.bib3); 14 (https://arxiv.org/html/2608.21794#bib.bib1))。随着代理和基准测试规模的扩大，这种映射越来越多地通过基于文本元数据的指令-元素句子嵌入相似度来进行评分。但是，当指令重复目标的可见标签时，高相似度是模糊的：它可能反映的是标签恢复，而非基于任务或屏幕上下文的语义推理（图1 (https://arxiv.org/html/2608.21794#S1.F1)）。用Messick的话来说 (16 (https://arxiv.org/html/2608.21794#bib.bib14))，嵌入距离只有在它能提供超出词汇基线的信息时，才是一个有效的定位代理；本文是对GUI定位如何*被测量*的审计，而非提出一种新的定位模型。  
我们关注作为即插即用相似度度量的现成单向量句子编码器，并将微调作为控制条件。我们重新将每个定位步骤建模为对当前屏幕可见UI元素的排序任务，并比较词汇检索器与现成编码器在AndroidControl (14 (https://arxiv.org/html/2608.21794#bib.bib1))、MoTIF (1 (https://arxiv.org/html/2608.21794#bib.bib2)) 和 Mind2Web (5 (https://arxiv.org/html/2608.21794#bib.bib3)) 上的表现。我们按目标标签类型分层，用LCC和ESH总结词汇耦合与融合潜力，并利用STS-B (2 (https://arxiv.org/html/2608.21794#bib.bib24)) 加上AndroidControl-Curated (13 (https://arxiv.org/html/2608.21794#bib.bib9)) 来限定通用编码器的弱点与标注噪声。  
有三个发现。首先，跨AndroidControl、MoTIF和Mind2Web，没有一个现成的编码器能在R@1指标上始终优于BM25；图2 (https://arxiv.org/html/2608.21794#S1.F2) 显示了配对跨语料库的差值。其次，性能强烈依赖于暴露的目标标签：所有纯文本方法在标签贫乏的目标上仍然较弱，而遮蔽目标暴露的文本元数据会使R@1在等分配的三层样本中下降22-38个百分点。编码器的Hit@1结果也可从词汇排名、标签类型和候选池大小预测，AUC为0.82-0.88。针对任务的微调显著提高了Top-1排序准确性，但并未消除词汇耦合：微调模型的LCC仍高达0.877。在目标文本依赖性扰动下，其R@1也从0.694降至0.151，表明改进后的排序器仍强烈依赖于目标候选者暴露的文本。第三，嵌入包含互补信息，但在AndroidControl上，标准可部署融合仅捕获目标感知预言机潜力的一小部分，并且在组合多个相关检索器时可能降低Top-1准确性。

图2：每个句子嵌入检索器相对于BM25在三个语料库上的配对ΔR@1。误差条为基于episode或annotation_id的95%聚类自举置信区间。

贡献。  
(1) 我们证明，高的现成指令-元素嵌入相似度常反映可见标签的恢复，因此本身并不能确立语义GUI定位。  
(2) 我们揭示了这种效应背后一个稳定的跨语料库机制：指令常使用可见的UI标签来命名目标，而基准测试元数据在候选文本中再次暴露这些标签。  
(3) 我们开发了LCC和ESH，并将它们与词汇基线、标签类型分层和目标文本依赖性扰动一起置于审计套件中，量化词汇耦合并将目标感知预言机潜力与可部署融合增益分离。  
(4) 我们将这些发现转化为文本元数据GUI定位评估的实用报告协议。

## 2 相关工作
我们的审计位于GUI定位评估、NLP中的构念效度与捷径学习审计，以及信息检索中词汇与稠密检索的交叉点。

#### GUI定位基准测试与代理。
GUI定位基准测试评估模型是否能将自然语言指令映射到UI元素或屏幕坐标。我们使用三个文本元数据语料库：AndroidControl (14 (https://arxiv.org/html/2608.21794#bib.bib1))、MoTIF (1 (https://arxiv.org/html/2608.21794#bib.bib2)) 和 Mind2Web (5 (https://arxiv.org/html/2608.21794#bib.bib3))（大小和划分见§3.1 (https://arxiv.org/html/2608.21794#S3.SS1)）。像素级视觉定位器 (3 (https://arxiv.org/html/2608.21794#bib.bib4); 21 (https://arxiv.org/html/2608.21794#bib.bib5); 8 (https://arxiv.org/html/2608.21794#bib.bib6); 10 (https://arxiv.org/html/2608.21794#bib.bib7)) 和端到端Android代理工具 (23 (https://arxiv.org/html/2608.21794#bib.bib8)) 不在我们的文本相似度范围内。该领域文献探讨模型能否定位；我们则探究相似度分数衡量的是什么。

#### NLP中的构念效度与捷径学习。
我们建立在语言理解领域构念效度审计的基础上。16 (https://arxiv.org/html/2608.21794#bib.bib14) 确立了一个观点：基于分数的度量只有在它承载其所声称度量的构念时才是有信息的。9 (https://arxiv.org/html/2608.21794#bib.bib12) 和 15 (https://arxiv.org/html/2608.21794#bib.bib11) 表明NLI分类器可能从标注伪迹或词汇重叠启发式方法预测标签，而非基于蕴含关系本身；7 (https://arxiv.org/html/2608.21794#bib.bib13) 将此框架化为捷径学习。我们借鉴了审计逻辑但并非其结论：在GUI定位中，标签重叠通常是到达目标的有效途径，因此构念效度问题并非嵌入是否利用了捷径，而是它们的分数是否提供了超出该词汇途径的证据。我们的词汇基线、标签类型分层和残差逻辑回归审计正是这种方法论的迁移。

#### 词汇检索与稠密检索。
NLP构念效度审计所称的捷径，在信息检索领域被视为不应跳过的词汇基线：在将稠密相似度解释为语义证据之前，必须并列报告稠密和稀疏检索器的结果。BM25 (19 (https://arxiv.org/html/2608.21794#bib.bib16)) 是规范的词汇参考；像DPR (12 (https://arxiv.org/html/2608.21794#bib.bib17)) 这样的稠密检索工作为开放域问答中的神经语义匹配提供了动机，而BEIR (20 (https://arxiv.org/html/2608.21794#bib.bib15)) 表明BM25在各种文本检索任务中仍然是一个鲁棒的零样本基线。我们的设置提出了一个不同的测量问题：当句子嵌入相似度被用作GUI定位度量时，它是否提供了超出可见标签恢复的证据？GUI候选文本暴露了与标注者用于描述目标相同的标签，这使得词汇匹配既是一种有效的定位途径，也是将嵌入相似度解释为语义定位时的混淆因素。我们将此机制转化为可报告的词汇耦合与融合潜力诊断。倒数排名融合 (4 (https://arxiv.org/html/2608.21794#bib.bib18)) 是标准的排名融合基线；我们审计的编码器是标准的MTEB式句子编码器 (17 (https://arxiv.org/html/2608.21794#bib.bib19))（§3.5 (https://arxiv.org/html/2608.21794#S3.SS5)），而STS-B对比（§4.4 (https://arxiv.org/html/2608.21794#S4.SS4.SSS0.Px2)）表明这种耦合是语料库特定的，而非编码器能力弱的证据。

#### GUI定位质量审计。
两篇近期的GUI定位器审计与我们并行。11 (https://arxiv.org/html/2608.21794#bib.bib10) 使用对抗性多指令生成对模型进行鲁棒性（针对查询变化）的审计。AndroidControl-Curated (13 (https://arxiv.org/html/2608.21794#bib.bib9)) 识别AndroidControl中的歧义和事实错误，并发布了一个净化的子集，这是一种标注侧的清理，同时保持评估度量固定。我们的审计是度量侧审计：我们固定模型族和基准测试，探究相似度分数本身衡量的是什么。我们在§4.4 (https://arxiv.org/html/2608.21794#S4.SS4.SSS0.Px2) 中使用AndroidControl-Curated的标记作为鲁棒性检查；他们的基准测试净化和我们的度量审计是互补的。

## 3 方法
我们通过一个词汇控制的候选排序协议来操作化审计，该协议使用词汇和嵌入检索器对同屏UI元素进行排序，按目标标签可用性对结果进行分层，并用LCC和ESH总结词汇耦合与融合潜力。

### 3.1 数据集与候选池
#### AndroidControl。
AndroidControl (14 (https://arxiv.org/html/2608.21794#bib.bib1)) 提供了15,283个移动UI演示片段，每个步骤的指令与类型化操作配对。从每个定位步骤的辅助功能树中，我们提取每个可见的UI元素，并解析位于操作坐标处的目标，从而获得58,078个定位步骤和总计456万个候选（中位数为每个步骤62个，最大值为1,657个）。我们使用官方的训练/验证/测试划分；附录B (https://arxiv.org/html/2608.21794#A2) 提供了提取和连接键的细节。

#### 标签类型分类。
对于每个目标元素，我们记录辅助功能树中存在哪种文本功能：纯文本（visible text）、纯内容描述（cd-only）、两者皆有、仅资源ID（resource-only）、伪文本（pseudo，如“image container”或“layout header”等样板字符串）或无（none）。

#### 主要与诊断子集。
我们的主要分析使用“clean-main”：目标具有可见文本或内容描述的点击和长按操作（n=32,646）。标签贫乏的行（仅资源ID/伪文本/无）和全部58,078步集作为诊断结果单独报告，而非平均到主要指标中。

#### MoTIF。
为了进行跨语料库压力测试，我们在MoTIF (1 (https://arxiv.org/html/2608.21794#bib.bib2)) 上运行相同的目标排序协议，使用片段目标作为查询，因为MoTIF缺乏AndroidControl式的步骤指令。经过匹配预处理后，得到22,427个定位步骤；“clean-main”子集（文本/内容描述标记的点击目标）包含4,724行。标签类型分类和排序协议其他方面保持一致。

#### Mind2Web（跨域）。
我们在Mind2Web (5 (https://arxiv.org/html/2608.21794#bib.bib3)) 的三个测试划分上运行相同的协议（过滤后可用步骤为5,941；平均531，中位数410，最大4,301个候选/步骤），使用发布的pos+neg_candidates池。查询是任务加上目标操作之前的action_reprs前缀；我们排除当前步骤的target_action_repr，因为它是元素感知的，会泄露目标身份。标签类型分类映射到Web对应物（纯文本、仅aria、两者皆有、仅id/class、无）；DOM解析细节见附录B (https://arxiv.org/html/2608.21794#A2)。

### 3.2 用于控制检查的辅助数据集
#### AndroidControl-Curated。
AndroidControl-Curated (13 (https://arxiv.org/html/2608.21794#bib.bib9)) 提供了标注质量标记，我们用它来测试BM25的领先优势是否由标注噪声驱动；其中2,946行与我们的“clean-main”子集连接。每个标记的定义和计数见附录B (https://arxiv.org/html/2608.21794#A2)。

#### STS-B。
为了对比语料库特定的词汇耦合与规范的句子相似度，我们在STS-B开发+测试划分 (2 (https://arxiv.org/html/2608.21794#bib.bib24))（2,879对句子，黄金相似度在[0,5]区间）上评估了MiniLM、MPNet、BGE、E5和Qwen3。

### 3.3 候选排序协议
对于每个定位步骤，我们构建一个排序查询q和一个候选集C = {c1, ..., cn}，该集合由当前屏幕上每个解析后的UI元素组成。查询是步骤指令（AndroidControl）、片段目标（MoTIF）或任务加上前面操作历史前缀（Mind2Web；见§3.1 (https://arxiv.org/html/2608.21794#S3.SS1)）。正候选是位于记录的目标索引处的元素。检索器为每个候选评分；目标的排名是候选按分数降序排列时的位置，带有确定性的平局处理（附录D (https://arxiv.org/html/2608.21794#A4)）。我们报告标准的排名指标：R@1、R@5、R@10和平均倒数排名（MRR）。所有指标将每个定位步骤视为一个排名事件，并在所选子集内对步骤进行均匀聚合。

### 3.4 元素文本化
每个UI元素被序列化为一个检索器输入字符串，来源于visible text和辅助功能描述，当没有可读标签时，使用resource-id或class-name作为后备。词汇和嵌入检索器消耗相同的文本化候选字符串，因此任何词汇优势都不是由于BM25获得了更丰富的UI文本。语料库特定的解析、分词和停用词表见附录B (https://arxiv.org/html/2608.21794#A2)；仅在构建相关性中使用的替代变体见附录L (https://arxiv.org/html/2608.21794#A12)。

### 3.5 检索器
#### 随机（Random）。
一个参考基线，每步均匀随机对候选排序。期望R@1是每步的1/nx平均值；我们报告它以明确候选池的难度。

#### Jaccard。
对于每个候选，我们计算查询和候选令牌集之间的Jaccard系数。空集得分为零。

#### BM25。
我们使用固定的、标准的超参数（k1=1.5, b=0.75）对候选进行BM25评分，不使用语料库特定信息。