AI 辅导工具最常见的问题不是回答不出题目而是它在图里看不见你说的是哪个东西。你拿一道几何题截图问它“为什么这两个角相等”它如果只根据文字猜答案就会一本正经解释错。视觉基础Visual Grounding要解决的正是这种“文本指代 图像定位”的问题模型看得到图能在图上指出目标区域再结合该区域解释。这个方向对 AI 教育产品很有价值也适合任何想给现有学习工具加上“可见答案”能力的开发者。下面按一个真实可运行的思路拆开讲。1. 先想清楚视觉基础在辅导里到底负责什么1.1 不是让 AI 帮你做题是让 AI 先找到你说的对象视觉基础这个术语听起来很学术翻译成实际能力就一句话模型根据一段文字指令在图像里找到对应的物体或区域并用坐标框、遮罩或箭头表示出来。比如学生上传一道生物题截图问“这个结构是不是线粒体”。模型必须知道“这个结构”在图片的哪个位置然后圈出那个区域再解释判断理由。如果只输出一段文字“是线粒体”学生根本不知道它看的是哪一个也就无法判断答案可不可信。辅导场景里视觉基础真正解决的是让 AI 和学生之间拥有“共同坐标”。学生说“这里”“这一步”“上面那个三角形”AI 得把这些指代词和图像中的具体像素位置对应起来。否则对话越深入歧义越大。我建议产品需求里把视觉基础写成一个独立模块而不是“模型多模态能力”的一部分。独立模块的好处是可以单独测试、单独优化、单独设置失败降级。如果哪天模型回答文本很好但定位总偏你至少知道问题出在定位层而不是把整个系统推倒重来。1.2 容易被误认为 OCR、文档解析、自动答题做 AI 辅导项目时很多人会把视觉基础和 OCR、文档解析、自动答题混在一起结果需求边界越来越模糊。OCR 负责把图片里的文字抽出来但它不管“这几个字为什么重要”。文档解析负责版面切分能分出标题、正文、图片、表格但它不理解数学公式之间的关系。自动答题则更偏向直接给结论很多自动答题系统甚至可以不看图靠题库匹配或文本猜测也能答对一部分题。视觉基础不是这三者的替代品。它更像一座桥左端是文字问题右端是图像区域中间必须做到可验证。所以评估一个 AI 辅导系统有没有真正用上图像最简单的方法是做一次“空白图测试”同一道题把图片换成一张空白图看模型是不是还在硬指。如果它仍然返回坐标框说明系统大概率在靠问题文本猜而不是在看图。这个测试成本很低效果却非常直观。2. 一个可用系统的基本组成别一开始就上大而全2.1 输入侧截图、拍照、白板、电子教材先处理输入因为后面所有定位工作都依赖一张质量足够好的图片。常见输入包括四类电子教材截图一般是 PNG 或 JPG清晰度较高问题最少。手机拍照可能出现透视变形、阴影、反光需要让学生先裁剪出题目区域。白板照片绿板或白板上的手写字颜色差异大低对比度区域容易识别失败。PDF 文件不能直接丢给视觉模型时需要先转成图片再按页处理。输入侧最容易犯的错是把图片压缩得太小。有些模型接口对图片尺寸有限制开发者为了省流量把一张 2000 像素宽的教材截图压缩到 512 像素结果模型看不清公式里的上下标定位自然不准。更稳妥的办法是保留原图用于展示传给模型时用归一化坐标并做合理缩放而不是在输入阶段就大幅牺牲清晰度。2.2 理解侧多模态模型 指代任务理解侧是整个系统的核心。当前主流的做法是使用多模态大模型同时接收图片和文本问题输出解释文字和定位坐标。如果只用纯文本模型就必须先把图片转成文字描述比如“图中有两个三角形、一个圆”。这种做法在简单图上能用但一旦图变复杂文字描述会丢失太多空间关系。三角形 A 在左上三角形 B 在右下这种位置信息用文字描述非常啰嗦还容易出错。所以在理解侧我建议默认让模型直接吃图片并要求它输出结构化的定位结果。坐标体系建议使用归一化坐标图片左上角为原点x 和 y 都取 0 到 1 之间的小数。归一化的好处是无论模型内部把图片缩放成多大输出的坐标都能映射回原图前端展示时只要乘回原图宽高即可。2.3 输出侧同一结果给两条通道输出侧不要只画一个框也不要只给解释文字。更好的方式是把结果拆成两层文本层用简短话解释结论以及为什么。视觉层在图片上用框或高亮区域标出模型所依据的位置。这两层必须保持一致。如果模型解释的是第三个公式却把框画在第二个公式上对学生来说就是一次极差的体验。因此后端返回的数据结构里建议把“文字解释”和“定位坐标”放在同一个响应对象中并且用同一个任务 ID 关联。前端拿到后先展示定位框再展示解释文字顺序不要颠倒。为了说明模块划分下面是一个简单对照表模块要解决的事最常见问题输入模块把截图、拍照、白板变成模型可读取的图片图片模糊、方向错误、压缩过度理解模块把问题文本映射到图像对应区域模型不看图根据问题文字猜答案输出模块把坐标画回原图并配解释文案坐标基准不一致框偏移交互模块支持学生追问“那这个呢”多轮对话中图片上下文丢失3. 搭一个最小可运行原型先跑通三类问题3.1 环境准备搭建原型的准备工作不需要很复杂。常用的 Python 环境配上图片处理库再接入一个支持视觉输入的多模态模型接口就能开始。图片处理建议使用 Pillow 或 OpenCV。Pillow 用来读取图片、转格式、调整尺寸OpenCV 还可以做旋转校正和边缘检测。模型部分线上接口和本地模型都可以原型阶段优先选能最快跑通的方案。测试图片准备五到十张就够了。我建议覆盖这几种类型一张几何证明题截图、一张教材段落截图、一张生物结构图、一张白板手写内容、一张表格截图。这几类基本覆盖了最常见辅导场景。图片准备好之后统一放在一个固定目录下方便反复测试。3.2 一个可参考的请求结构下面这段代码是请求结构示意不依赖特定厂商。重点在于把图片内容、用户问题、坐标体系和返回格式一起传给模型。import base64 import json def build_payload(image_path, question): with open(image_path, rb) as f: image_b64 base64.b64encode(f.read()).decode(utf-8) payload { image: image_b64, question: question, coordinate_system: normalized, response_format: { answer: brief_explanation, boxes: [x_min, y_min, x_max, y_max] } } return payload实际接入时不同的模型接口在字段命名上会有差异。有的要求图片放在 image_url 里有的接受本地文件路径有的希望坐标用像素值而不是归一化值。这些都不重要重要的是你的数据结构里必须把“问题”“图片”“坐标格式”和“解释要求”四件事分开否则调试时很难判断是模型问题还是请求格式问题。3.3 提示词怎么设计视觉基础任务里提示词的作用非常大。因为在纯文本问答中模型可以绕开图像作答但在带定位要求的任务中你必须让它先回答问题指向哪个区域再给解释。一个可以参考的提示词结构如下你是一位耐心、严谨的辅导老师。 用户会上传一张图片并针对图中的内容提问。 请你按下面的步骤处理 1. 先判断用户问题指向图中的哪个区域。 2. 用归一化坐标 [x1, y1, x2, y2] 指出该区域原点在图片左上角。 3. 用不超过三句话给出解释。 4. 如果图中不存在用户提到的对象请直接说“图中没有找到”不要猜测。 要求 - 坐标必须准确落在目标内容上。 - 宁可不给坐标也不要给错误坐标。为什么要把“宁可不给坐标也不要给错误坐标”写进去因为定位错误比定位缺失更误导学生。要是模型无法定位至少可以触发一个“看不清请重新截图”的反馈流程如果模型硬画一个错误框学生就会开始怀疑整个系统的可靠性。3.4 验证方式原型搭好后不要急着做大而全的测试。先跑通三类问题指类别问题“图中哪个三角形面积最大请指出并解释。”区域类问题“把第二段中的关键句框出来并解释为什么它是观点句。”纠错类问题“这张白板里第一步计算错在哪里请把错误位置标出来。”每跑一条结果记录三列文本是否答对、框是否覆盖目标、框和文本是否一致。不要只看模型返回的坐标有没有值还要看坐标对应到原图后是不是真的落在目标位置。坐标有值不等于坐标正确。4. 想把定位做准不能只靠改提示词4.1 构造带坐标的问答数据提示词能让模型表现稳定一点但想让视觉基础真正变准需要数据。尤其是当你要针对数学几何、生物结构图或某本教材做优化时通用模型未必能理解你定义的目标区域。比较可行的方式是做一个带坐标标注的小数据集。每一条数据包含四部分图片路径用户问题目标区域坐标标准答案文字刚开始不需要做几千条。先做 50 到 200 条覆盖典型题型跑一轮评测看定位错误都出现在哪。这个数量已经足够暴露大部分问题。常见问题包括模型把两个相近结构搞混、框只覆盖了目标的一半、把题干里的文字误当成公式位置等。标注工具不需要多高大上。能画框、能导出坐标就行。关键是坐标要和训练或评测时使用的图片尺寸保持一致建议统一记录为归一化坐标避免后续缩放带来额外换算。4.2 归一化坐标和负样本数据准备阶段两个细节值得单独说。第一个细节是归一化坐标。如果你用像素坐标原图 2000 像素宽模型内部压缩到 800 像素同一个目标在两个坐标系里的位置会完全不同。归一化坐标把尺寸变化这件事屏蔽掉前端展示时再按实际图片尺寸换算是最省心的方法。第二个细节是负样本。很多定位数据集只标注“正确答案在哪里”却忽略了“图中没有这个对象”的情况。实际辅导中学生可能问“图中的抛物线在哪个位置”但图上根本没有抛物线。如果模型没有见过这种负样本它会倾向于硬找一个相似区域来响应。这样错误比“找不到”更危险。负样本的构造也不难把原有问题里的对象名替换成图片中不存在的对象即可。比如教材截图中没有圆问题改成“请指出图中圆的圆心”模型应该回答“图中没有找到”并返回空坐标。4.3 评估指标怎么定文本问答可以用“答对率”来评价但视觉基础任务不能只看答对率。定位不准的回答即使文本看着对也不能算成功。我建议至少看三个指标定位精度用 IoU 计算预测框和真实框的重叠程度。一般可以设定一个阈值比如 IoU 不低于 0.5 才算定位通过。文本正确率回答内容是否正确仍需要人工或规则判断。端到端成功率文本正确、定位通过、且没有多指或漏指三者同时满足才算一次成功。产品层面还可以加两个指标学生一次提问后需要几次追问才能理解以及学生发起纠正的次数。如果一个系统经常需要学生二次说明“不是那个是左边那个”说明定位体验还远没有达标。5. 线上接口和本地模型取舍点要提前想5.1 线上多模态接口适合快速验证原型阶段用线上多模态接口是最省力的。你不用关心显存、依赖、模型文件把图片和问题发送过去拿结果就行。这也是我建议先跑通原型再考虑本地部署的原因。但线上接口有它的代价。第一是延迟视觉类任务通常比纯文本慢答一道题可能需要好几秒。第二是隐私学生上传的作业、手写笔记、甚至包含人脸的照片都会经过第三方服务。第三是成本图片请求的消耗通常比文字请求高。做内部验证没问题做成公开展示产品前这些都要重新评估。5.2 本地部署要考虑资源和维护本地部署适合对隐私敏感、需要离线运行、或者请求量很大的场景。但本地部署不只是一个模型文件的问题还包括推理服务、并发队列、显存管理和版本更新。如果你的机器显存或内存有限可以先用这些策略把输入图片先压缩到适当尺寸不要直接传原图。不要开过大的 batch宁可一次处理一张。给接口设置超时和重试避免服务被慢请求拖死。用任务队列接收批量请求而不是让每个用户直接打到模型服务上。“能启动模型”不代表“能稳定提供服务”。我见过不少项目本地模型能在单条测试时给出不错结果一放到班级场景就超时。原因往往不是模型变差了而是并发请求把资源占满导致排队时间过长。5.3 按场景选型不同阶段、不同使用场景适合的方案并不一样。下面是我的选型建议场景建议原因产品原型验证线上接口快不需要管理模型和GPU辅导机构内部使用本地模型学生数据不出内网隐私更可控离线学习工具本地模型 任务队列弱网环境下也能稳定跑通面向公众的在线产品线上接口或自建服务需要考虑弹性扩容和请求高峰期选型不是一个单选题。也可以先跑线上接口验证效果再根据延迟、成本和隐私要求决定要不要本地化。6. 定位失败时按这个顺序排查6.1 先看输入图像定位不准第一件事不要改模型参数先看输入图像。把用户上传的图片保存下来自己打开看一眼。图片是否模糊、是否旋转、是否被裁掉关键部分、是否有大面积阴影反光、是否因为压缩出现明显马赛克。这些问题都会直接导致定位失败但它们在代码层面不一定报错。如果是手机拍照建议在产品端增加一个“重新拍摄”的引导而不是让模型硬处理。很多透视变形可以通过 OpenCV 校正但校正本身也可能改变坐标基准。原型阶段宁可让用户重新上传也不要让系统在变形的图上猜。6.2 再查坐标映射坐标映射是定位系统最常见的工程 bug。很多前端展示框时会把模型返回的坐标直接画在显示图上。如果模型返回的是归一化坐标前端必须乘上当前展示图片的宽高。如果中间发生缩放、裁剪、旋转坐标换算就必须同步处理。否则模型定位其实是对的但画出来的框位置完全不对。排查时先在后端打印模型返回的原始坐标再把坐标映射到原图上看是否落在目标区域。如果原始坐标正确而前端显示错误问题一定在映射逻辑里不用继续怀疑模型。6.3 然后确认模型是不是“真看”图这一步很多人会忽略。模型返回了坐标不代表它真的看到了目标。尤其是当问题文本里已经带有关键信息时模型可能根据文字猜测一个位置。这个位置看起来像模像样实际上和图片内容无关。用两个简单测试可以判断问一句“图片左上角画的是什么”不提供任何目标提示。把原图换成一张纯色空白图同一个问题再问一次看模型是否仍然返回坐标框。如果模型在空白图上仍然给出坐标说明系统对图片内容的依赖很低定位结果不可信。这个时候要优先检查图片是否真的传到了模型那边、图片编码是否正确、以及模型当前版本是否真的支持细粒度视觉定位。6.4 多轮场景里图像是否丢失最后排查多轮对话。AI 辅导不能只回答一次学生会继续追问。追问时系统是否还保留图片上下文直接关系到后续定位是否准确。有些聊天实现为了省 token会把图片转成一段文本描述然后只把文本放进多轮上下文。第二、第三轮时模型已经看不到原图只能根据文字描述猜。表现就是第一轮定位不错第二轮开始偏移第三轮甚至输出和目标无关的框。如果产品是多轮对话形态建议每一轮都携带图像 ID并在必要时重新发送图片或裁剪后的局部图。至少保证模型在回答“那这个呢”的时候还能看到当前正在讨论的图片内容。调试过程中建议把每一条请求和响应的关键信息记下来图片 ID、用户问题、模型返回坐标、画框后的截图、用户是否反馈纠正。有了日志后续分析定位问题会快很多。没有日志只能反复猜测是哪一层出了问题。7. 离真实课堂还差几步7.1 先做辅助助教不做全自动老师视觉基础能让学生和 AI 的沟通更准确但它距离一个真正的老师还差很远。老师能判断学生卡在哪里、为什么卡住、用什么方式讲更容易理解。AI 目前更适合做“看得见、指得准、讲得清”的辅助助教。落地时可以先这样设计AI 负责定位和初步解释老师负责确认答案、补充引导、处理复杂提问。这样即使模型偶尔定位不准也有老师在最后把关不会把错误信息直接交给学生。7.2 给模型加“不会就明说”的约束产品设计上一定要给模型留出一条“承认不懂”的路径。在提示词里可以明确写如果图片模糊、目标对象不明确、或者没有把握定位请直接说“这张图我看不清楚请重新上传”而不是强行输出一个框。很多学生不会怀疑 AI 给出的框所以错误的定位比“不知道”更容易破坏信任。交互上可以在前端加一个“这个框准不准”的反馈按钮。学生反馈“不准”的数据会自动进入后续评测集形成一条简单但有效的数据迭代闭环。7.3 数据隐私和最小留存学生上传的图片里可能包含作业内容、姓名、笔迹甚至个人照片。这些信息属于敏感数据不应长期留存。如果你的系统跑在本地优先只保存定位结果和必要的日志不上传原图。如果必须使用线上接口建议对接前先做数据脱敏和最小化处理比如把图片裁剪到只保留题目区域再发送给模型。不要为了一时方便就把整张截图原封不动放进日志里。如果让我重来一次我不会一开始就做全科自动答疑。更合理的路径是先选一到两门课的题目类型准备一百条带定位的问答数据把单轮定位跑准再扩展到多轮和整页讲解。视觉基础真正带来的不是“更会答题”而是让学生和 AI 之间的沟通有了共同坐标。这个能力一旦稳定产品体验会比纯文字问答提升一个台阶。