截图组件功能怎么用 RAG 解释?

这道题问的是怎么让大模型看懂一张软件截图，然后结合知识库给出每个组件的功能解释。说白了，就是给大模型装上一双眼睛和一个知识库，让它能像产品经理一样给你讲清楚这个按钮是干嘛的、那个输入框怎么填。

具体怎么做呢？我把它拆成四步。第一步是视觉理解，你得先知道图里有什么。我会用UI检测模型，比如ScreenSpot或者CogAgent，把按钮、输入框、图标这些元素全框出来，再用[[OCR]]把上面的文字读下来，最后拿到一个结构化的东西：组件类型、位置坐标、文本内容。这一步没什么花哨的，但组件检测的精度直接影响后面所有环节，如果小图标没识别到，后面检索和生成就白搭。

第二步是建知识库。光有截图不行，得把每个组件的功能说明配对存起来。我会收集产品手册、设计规范、甚至内部Wiki，然后把组件截图和对应的功能描述做成图像-文本对。这里有个关键点：不能用纯文本[[Embedding]]，得用[[多模态]]模型，比如[[CLIP]]或者专门做UI的UIBert，把图像和文本映射到同一个向量空间。这样后面检索时，用户截图可以直接用视觉Embedding去匹配知识库里的组件。

第三步是检索。用户截图进来后，先用同样的视觉模型算出它的Embedding，然后去知识库找最像的组件。我倾向用两级检索：先全局匹配，看看这张截图属于什么界面类型，比如是设置页还是订单列表；再组件级局部匹配，把每个框出来的元素单独去匹配。这样既快又准，因为全局匹配能缩小范围，局部匹配能精准定位。

最后一步是生成。把组件位置图、OCR文本、检索到的功能说明拼成一个Prompt，送给大模型。这里有个坑：大模型容易忽略位置顺序，所以我会在Prompt里强制要求按从上到下、从左到右的顺序描述，并且结合业务场景解释用途。比如一个“申请退款”按钮，不能说“这是一个按钮”，得说“在订单详情页底部，用于发起退款流程，点击后跳转到退款原因选择页”。

不过话说回来，这套流程有个前提：知识库必须足够丰富且准确。如果知识库里某个组件的说明是错的，或者新上线了一个组件没入库，那检索结果就会误导大模型。所以上线后我会特别关注知识库的更新频率和覆盖率，最好搞个自动化流程，每次发版后自动抓取新组件的截图和文档，重新生成Embedding。另外，检索结果的置信度也很关键，我通常会设一个阈值，分太低的就不用了，直接让模型说“不确定”，避免胡编。

所以整体上，我更倾向于把[[RAG]]当成一个可解释、可更新的外挂，而不是把所有理解能力都压在大模型本身。纯多模态模型虽然也能看图，但解释的来源是黑盒，出了问题没法排查；RAG至少能溯源到具体文档，内部术语和业务逻辑也能通过知识库灵活注入，不用每次改个文案就重新微调模型。当然，如果界面非常复杂、组件间交互很多，RAG也扛不住，那就得结合[[Agent]]或者多步推理了。