AI 应用算法工程师一面面经

1. 请做一下自我介绍 2. GUI Agent 中，基于坐标的动作空间和基于元素的动作空间各有什么问题？ 答案： 基于坐标的动作空间通常输出 click(x, y)、drag(x1, y1, x2, y2) 等动作，优点是能够操作 Canvas、远程桌面和没有 DOM 的原生应用。问题是对分辨率、缩放、窗口位置和页面布局变化敏感，同一个按钮在不同设备上的坐标不一致。 基于元素的动作空间输出元素 ID、可访问性节点或 DOM 节点，语义更稳定，也方便校验元素是否可见、可点击。但很多图标、游戏界面、虚拟列表和跨域组件无法提供可靠元素树，元素树还可能包含视觉上不可见的节点。 生产系统可以使用混合动作空间：优先通过元素树定位，在元素缺失或树与截图不一致时退化到视觉定位。执行前把目标元素映射成边界框，并验证可见面积、遮挡关系和交互属性；执行后重新观察界面，不能仅根据工具返回的“点击成功”判断任务状态。 3. 为什么 GUI Agent 在离线动作准确率很高，闭环任务成功率仍然可能很低？ 答案： 离线评测一般在专家访问过的状态上预测下一步动作，本质上测的是条件模仿能力。闭环执行时，Agent 会访问由自身错误产生的新状态，而这些状态通常不在训练分布中。一次轻微点击偏移可能打开错误页面，后面的每一步即使在局部上合理，也无法回到正确轨迹。 假设每一步独立正确率为 (p)，一个必须连续正确执行 (T) 步的任务，其理想化成功率近似为： 即使单步准确率达到 95%，连续执行 30 步的成功率也只有约 21%。实际系统中错误还具有相关性，结果通常更差。 因此必须做闭环评测，记录状态恢复率、首次错误位置、无效动作率和错误后的剩余完成概率。训练数据也不能只有专家轨迹，还应包含模型自己产生的偏离状态，以及如何识别错误、撤销操作和重新规划的恢复轨迹。 4. GUI Agent 的奖励函数如何避免只奖励“看起来完成了”，却没有真正改变环境状态？ 答案： 不能根据模型生成的“任务已完成”或最终截图的表面相似度直接给奖励。可靠奖励应建立在环境中的可验证状态上，例如数据库是否新增工单、表单字段是否正确保存、目标文件是否生成、页面路由和业务状态是否同时满足约束。 可以把奖励拆成任务结果、约束满足、动作成本和风险惩罚： 中间奖励只能对应不可伪造的状态变化。例如进入正确页面可以获得少量奖励，但“点击了疑似正确的按钮”不应获得奖励。否则模型可能学会在两个高奖励页面之间反复跳转。 还应使用独立验证器读取环境状态，避免策略模型同时负责执行和判分。对于删除、提交和付款等不可逆动作，先在副本环境中验证，或者要求满足前置条件后再由确定性程序执行。 5. 在线强化学习训练 GUI Agent 时，怎样处理环境吞吐远低于模型训练吞吐的问题？ 答案： GUI 环境需要截图、渲染、网络请求和业务响应，采样速度通常远低于 GPU 更新速度。如果训练严格同步等待所有环境返回，慢实例会造成严重的尾部阻塞。 可以将采样和训练解耦：大量 Actor 异步运行环境，将轨迹写入带版本信息的缓冲区；Learner 持续消费轨迹并更新策略。但异步会带来策略滞后，轨迹由旧策略生成，不能无限制地用于新策略更新。 处理方式包括限制轨迹最大版本差、按新鲜度降低样本权重，并使用重要性比率修正分布差异： 为了控制方差，需要对ρt截断。环境侧还可以复用登录状态和静态页面、并行运行容器、缓存不影响动作结果的视觉特征。任何缓存都不能绕过真实状态转移，否则训练环境与部署环境会产生偏差。 6. GUI Agent 的图标语义无法区分时，为什么单纯增加截图数据未必有效？ 答案： 视觉相近的图标可能需要结合页面区域、悬浮提示、前后状态和业务上下文才能区分。例如相同的铅笔图标在不同页面分别表示编辑资料、修改规则或批注，单张截图并不包含足够信息。 如果监督标签只有点击坐标，模型还可能学到位置先验，而没有理解图标作用。增加同分布截图只会加强这种捷径。数据应覆盖图标换位、主题变化、缩放变化和相似干扰项，并显式标注元素边界、可交互属性和动作结果。 执行时可以先移动鼠标获取 Tooltip，或调用无副作用的界面探测工具，再决定是否点击。训练目标也可以加入动作前后状态预测：如果模型无法预测点击后页面会发生什么，它对图标语义的理解通常不够可靠。 7. 如何处理 GUI Agent 中截图、DOM 和可访问性树互相矛盾的问题？ 答案： 三种观察具有不同故障模式。截图反映最终渲染结果，但缺少结构化语义；DOM 包含结构和属性，却可能有隐藏节点、透明遮罩和过期状态；可访问性树语义清晰，但覆盖范围依赖应用实现。 融合时不能把三者直接拼接后交给模型。应先把 DOM 或可访问性节点投影到截图坐标，检查边界框是否在视口内、是否被遮挡、是否有可见像素，再生成统一元素表示。每个元素应保留来源和置信度，冲突时根据操作类型选择证据。 例如填写表单时可优先使用 DOM 属性，点击 Canvas 控件时依赖视觉；涉及关键提交时，则要求视觉状态与结构状态同时确认。页面变化后必须使旧元素引用失效，防止模型操作已经被重新渲染的节点。 8. GUI Agent 使用小参数模型时，瓶颈一定来自模型容量吗？ 答案： 不一定。GUI Agent 的失败可能来自分辨率不足、视觉编码器丢失小字、动作表达不精确、轨迹标注错误或环境反馈延迟。如果瓶颈在观察和执行接口，更换更大的语言模型也不会解决问题。 可以通过分阶段上界实验定位：给模型提供人工标注的正确元素框，测试规划能力；提供正确子目标，测试元素定位；直接执行标准动作，测试环境稳定性。如果加入正确元素框后成功率大幅提升，瓶颈主要在视觉定位，而不是推理容量。 小模型还可以通过候选元素裁剪、结构化状态、动作约束和大模型蒸馏减少搜索空间。只有在相同观察、相同候选动作和相同评测条件下，小模型仍持续败在长程决策或歧义消解上，才能更有把握地归因于容量不足。 9. 如何判断一次 GUI 操作已经生效，而不是因为界面延迟导致 Agent 重复执行？ 答案： 操作完成不能只依赖固定时间的 sleep。不同机器和网络条件下，固定等待要么过短导致重复操作，要么过长降低吞吐。 每个动作应定义预期后置条件，例如 URL 改变、目标元素出现、按钮禁用、特定区域像素稳定或后端业务状态更新。执行后使用事件驱动等待或条件轮询，并同时设置超时。若超时，应查询当前状态，而不是直接重复执行。 对提交类操作还要生成动作 ID，并尽可能传递到后端作为幂等键。即使界面没有显示成功，只要后端已经提交，就不能再次点击。对无法查询结果的操作，应进入“不确定”状态并触发人工确认，而不是把不确定等同于失败。 import time from typing import Callable def wait_until( predicate: Callable[[], bool], timeout: float, interval: float = 0.1, ) -> bool: deadline = time.monotonic() + timeo