面试题 · 多模态
搜索「Agent 架构」匹配到追问内容，相关段落已展开。查看匹配内容 ↓
当用户提供一个软件或网页界面的截图时，如何利用检索增强生成（RAG）技术，结合视觉理解与知识库，解释界面上各个组件的功能与用途？请描述整体流程与关键技术点。
1. 视觉理解与组件解析
2. 多模态知识库构建
3. 跨模态检索
4. 增强生成
学习内容与项目面试，在同一条路上。
| 环节 | 技术选择 | 要点 |
|---|---|---|
| 视觉编码 | CLIP/SigLIP/专用UI模型 | 关注细粒度对齐能力，小图标区分度 |
| 组件检测 | DETR系列或SAM | 需支持任意形状UI元素 |
| 跨模态对齐 | 对比学习微调 | 用产品内部UI数据继续训练 |
| 检索策略 | 稀疏+稠密混合 | 组件名称用BM25，视觉语义用向量 |
建议系统学习该知识点
场景切入
假设你接到一个需求：用户上传一张有bug的软件截图，系统要自动解释每个按钮和输入框是干嘛的。你打算怎么用RAG实现？先说说你理解的流程。
层层追问
如果用户给你一张界面截图，你怎么让系统看懂上面有什么组件？……然后怎么关联到功能说明？……如果知识库里只有文本文档，没有图片匹配呢？
直球架构
设计一个基于RAG的界面截图解释系统，要求能识别组件并检索知识库生成功能说明。说清楚视觉理解、跨模态检索、生成整合这三个环节的具体技术选型和流程。
这道题问的是怎么让大模型看懂一张软件截图，然后结合知识库给出每个组件的功能解释。说白了，就是给大模型装上一双眼睛和一个知识库，让它能像产品经理一样给你讲清楚这个按钮是干嘛的、那个输入框怎么填。
具体怎么做呢？我把它拆成四步。第一步是视觉理解，你得先知道图里有什么。我会用UI检测模型，比如ScreenSpot或者CogAgent，把按钮、输入框、图标这些元素全框出来，再用[[OCR]]把上面的文字读下来，最后拿到一个结构化的东西：组件类型、位置坐标、文本内容。这一步没什么花哨的，但组件检测的精度直接影响后面所有环节，如果小图标没识别到，后面检索和生成就白搭。
第二步是建知识库。光有截图不行，得把每个组件的功能说明配对存起来。我会收集产品手册、设计规范、甚至内部Wiki，然后把组件截图和对应的功能描述做成图像-文本对。这里有个关键点：不能用纯文本[[Embedding]]，得用[[多模态]]模型，比如[[CLIP]]或者专门做UI的UIBert，把图像和文本映射到同一个向量空间。这样后面检索时，用户截图可以直接用视觉Embedding去匹配知识库里的组件。
第三步是检索。用户截图进来后，先用同样的视觉模型算出它的Embedding，然后去知识库找最像的组件。我倾向用两级检索：先全局匹配，看看这张截图属于什么界面类型，比如是设置页还是订单列表；再组件级局部匹配，把每个框出来的元素单独去匹配。这样既快又准，因为全局匹配能缩小范围，局部匹配能精准定位。
最后一步是生成。把组件位置图、OCR文本、检索到的功能说明拼成一个Prompt，送给大模型。这里有个坑：大模型容易忽略位置顺序，所以我会在Prompt里强制要求按从上到下、从左到右的顺序描述，并且结合业务场景解释用途。比如一个“申请退款”按钮，不能说“这是一个按钮”，得说“在订单详情页底部，用于发起退款流程，点击后跳转到退款原因选择页”。
不过话说回来，这套流程有个前提：知识库必须足够丰富且准确。如果知识库里某个组件的说明是错的，或者新上线了一个组件没入库，那检索结果就会误导大模型。所以上线后我会特别关注知识库的更新频率和覆盖率，最好搞个自动化流程，每次发版后自动抓取新组件的截图和文档，重新生成Embedding。另外，检索结果的置信度也很关键，我通常会设一个阈值，分太低的就不用了，直接让模型说“不确定”，避免胡编。
所以整体上，我更倾向于把[[RAG]]当成一个可解释、可更新的外挂，而不是把所有理解能力都压在大模型本身。纯多模态模型虽然也能看图，但解释的来源是黑盒，出了问题没法排查；RAG至少能溯源到具体文档，内部术语和业务逻辑也能通过知识库灵活注入，不用每次改个文案就重新微调模型。当然，如果界面非常复杂、组件间交互很多，RAG也扛不住，那就得结合[[Agent]]或者多步推理了。