基于BLIP-2的视觉问答实战：让AI看懂图片并回答自然语言问题

1. 为什么我想做“让AI看懂图片并回答问题”这个项目这个项目听起来很像一个玩具但真正做完之后我发现它是可以挂进生产流程里的“图片问答服务”。核心目标很简单给模型一张图问一句自然语言问题让它返回一句像人一样的答案。选 BLIP-2 的原因也很直接——它是目前开源社区里最容易跑通、效果也足够稳定的视觉-语言模型之一配合 Python 侧的 Transformers 库几百行代码就能封装成自己的图片理解模块。如果你有相册整理、商品图自动标注、素材库检索这类需求或者只是想体验一下视觉问答到底能做到什么程度这篇文章的完整流程基本可以照着抄。我会从为什么要选它开始一直讲到代码实现、批量处理、中文提问、踩坑排查和性能优化尽量把我在实际运行中遇到的细节都交代清楚。1.1 从图像分类到视觉问答需求发生了什么变化过去我们说到“让AI看懂图片”第一反应往往是图像分类给一张图判断它是猫、狗、汽车还是风景。这个范式很成熟但它的天花板也很明显——分类只能回答“这是什么”很难回答“这只猫在干什么”“画面里一共有几个人”“这张图适合做什么用的封面”这类问题。后者不仅需要识别对象还需要理解对象之间的关系、场景氛围、动作逻辑甚至需要一定的常识推理。视觉问答Visual Question Answering简称 VQA就是在这个背景下出现的任务。它把“看图”和“说话”合并在一起输入是图片加上一段文本问题输出是一段文本答案。举个例子一张图片里有个小孩在公园里踢球分类模型只能告诉你“图片里有一个小孩”但 VQA 模型可以回答“小孩在做什么”“周围的环境是什么”“这个场景是室外还是室内”。这种能力用固定标签基本没法覆盖因为“问题”的空间几乎是无限的。BLIP-2 这批模型正好把这件事做了一个很务实的落地不需要你准备几百万张标注数据去训练一个全新模型也不用理解背后复杂的训练细节直接用预训练权重就能做推论。这个特点让我觉得它非常适合做个人项目和中小型业务的原型验证。1.2 为什么是 BLIP-2而不是更大的多模态模型选择 BLIP-2 之前我其实试过几条不同的路线。有些模型走的是“视觉编码 文本生成”两个阶段拆分效果不错但依赖特别重光是安装和模型文件就能把人劝退。还有一些超大尺寸的通用模型效果当然更好但在普通显卡上根本跑不起来推理速度也太慢。BLIP-2 恰好卡在一个很理想的位置效果够用、模型体积可控、生态成熟。它最特别的地方在结构设计。BLIP-2 不是让视觉编码器和语言模型直接硬凑在一起而是在中间加了一个很小但很关键的 Querying Transformer用来把图片信息“翻译”成语言模型能理解的表示。你可以把它想象成两个部门之间的对接人视觉部门很专业语言部门也很专业但两边术语不一样强行开会效率肯定低。有了中间层图片特征先被提取成一段关键的向量再喂给语言模型生成回答这样训练成本低效果反而更稳定。对使用者来说这意味着同一个架构可以搭配不同的语言底座。你可以根据显存和需求选择更轻量的底座也可以换成规模更大、理解能力更强的底座。再加上它本身是开源权重没有封闭平台限制我最终才确定用它来做这个项目。1.3 这个项目到底能用在哪些地方图像问答不是只能用来“玩”。做了一圈之后我发现它至少能落在四个比较实际的场景里。第一是商品图批量处理。电商场景里经常需要给商品图生成标题、卖点描述、场景标签用脚本挨个问 BLIP-2“这个商品是什么颜色”“图片里有什么配件”比人工标注快得多。第二是相册和素材库检索。给一批图片先生成描述文字再配合常规文本搜索就能做到“找一张有人在喝咖啡的照片”这种需求不用专门训练图像搜索模型。第三是无障碍辅助。把照片转成一句完整描述或者对着一张街景回答“前面有没有红绿灯”可以帮忙视障用户理解周围环境。第四是多模态对话的前置模块。如果你的聊天机器人只支持文本可以把用户上传的图片先交给图像问答模块把结果转成文字再进入后续对话流程。这些场景都说明一件事图像问答不是一个孤立技术它更像是连接图片和自然语言的转换层。接下来的内容我会从环境准备开始把这层“转换”的代码一步步拆开。2. 动手前的环境准备硬件、Python 和依赖2.1 硬件要求没有高端显卡也能跑出效果先说我的实际配置用的是普通中端显卡显存 8G 左右跑 BLIP-2 的小号模型加半精度推理没有问题。如果你手里的显卡显存更大比如 12G 或 16G可以尝试参数量更大的底座回答质量会明显更细腻。所谓“大号”“小号”的差别主要体现在语言理解能力和生成句子的通顺程度上对图像识别本身的差距没有想象中那么大。没有 NVIDIA GPU 也能跑但体验完全不同。纯 CPU 推理一张图可能需要几十秒到几分钟用来验证代码是够的想批量处理几百张图就不太现实。所以我的建议很简单项目初期先用 CPU 跑通逻辑确认输出格式没问题再切到 GPU 上做正式处理。还有一个常被忽略的点是内存。模型加载时不仅占显存RAM 也要留足。我遇到过本地环境明明显示显存够却因为内存不足导致进程被杀的情况。保险起见建议内存至少 16GSDD 剩余空间也要有几十 G因为模型权重文件加起来并不算小。2.2 安装依赖版本匹配比装得全更重要代码只用到了几个库torch、transformers、pillow、accelerate。很多教程喜欢列一大堆依赖但实际跑通核心流程并不需要那么多。核心安装命令我建议这样写pip install torch transformers accelerate pillow这四个库就可以跑通后面所有代码。如果你已经装了别的项目对应的 torch先确认版本不要太旧也不要太新。我踩过一个比较典型的坑torch 版本太高但 transformers 还是老版本结果模型加载时报了一堆莫名其妙的方法缺失错误。遇到这种情况不用纠结直接同时升级 torch 和 transformers 到当前兼容的版本就好。这里多解释一句 accelerate 的作用。它主要负责帮我们处理设备管理比如自动把模型放到 GPU、处理半精度配合device_mapauto参数可以让模型自动分配到可用设备上。这个参数对新手很友好因为不用自己手动把每个模块搬到 GPU也避免出现“模型在 GPU、输入在 CPU”这种低级错误。2.3 把模型权重准备好离线加载也不慌第一次运行代码时模型库会自动下载权重文件。下载过程可能需要一段时间具体取决于网络环境。我的经验是先把模型文件下到一个固定的缓存目录方便以后复用。设置方式是在启动脚本前加环境变量export TRANSFORMERS_CACHE/data/model_cache这样所有预训练权重都会统一存放在这个目录下就算后续代码写错了重新运行时也不需要二次下载。再补充一个细节模型加载时如果中断过不要立刻清缓存因为下载是支持断点续传的重新运行往往能继续。如果要在完全离线的机器上使用可以在下载好的目录结构完整的前提下设置离线模式环境变量export HF_OFFLINE1然后再次运行加载代码即可。网上不少教程直接给一个完整的模型编号比如blip2-opt-2.7b但在实际项目里模型 ID 前面通常会带上上传权重文件的组织账号前缀。你只要把它当成“模型库里的完整路径”来理解使用你自己能下载到的完整编号后面的代码逻辑都是一样的。3. 核心代码实现图像描述、问答与提示词设计3.1 初始化模型和处理器先跑通“看图说话”先写一个最基础的版本加载模型读入一张图片生成一句自然语言描述。我把完整的可运行代码放在下面。import torch from PIL import Image from transformers import Blip2Processor, Blip2ForConditionalGeneration MODEL_NAME your-model-space/blip2-opt-2.7b processor Blip2Processor.from_pretrained(MODEL_NAME) model Blip2ForConditionalGeneration.from_pretrained( MODEL_NAME, torch_dtypetorch.float16, device_mapauto, ) image Image.open(demo.jpg).convert(RGB) prompt a photo of inputs processor( imagesimage, textprompt, return_tensorspt ).to(devicecuda, dtypetorch.float16) generated_ids model.generate(**inputs, max_new_tokens50) caption processor.batch_decode(generated_ids, skip_special_tokensTrue)[0].strip() print(caption)这段代码里有两个非常关键的设计。第一是torch_dtypetorch.float16它把模型权重切换成半精度显存占用直接减少接近一半。视觉语言模型对这种精度切换并不敏感输出质量肉眼几乎看不出差别。第二是device_mapauto它让 accelerate 自动决定把模型加载到哪块设备上不需要手动实现.cuda()。读取图片时我特意加了.convert(RGB)。原因是有一些图片虽然是 JPG但内部可能是灰度模式或包含透明通道不统一转成 RGB 容易出现维度不匹配。描述结果默认是英文因为模型预训练数据以英文为主这样生成最稳定。3.2 让模型回答具体问题视觉问答的调用格式“看图说话”只是第一步。更有价值的是让模型回答具体问题。代码的改动非常小只需要把提示词从“a photo of”换成带有提问和回答引导的格式question what is the person doing? prompt fQuestion: {question} Answer: inputs processor( imagesimage, textprompt, return_tensorspt ).to(devicecuda, dtypetorch.float16) generated_ids model.generate(**inputs, max_new_tokens64) answer processor.batch_decode(generated_ids, skip_special_tokensTrue)[0].strip() print(answer)注意这里的“Question: ... Answer:”不是随便写的字符串。BLIP-2 在预训练阶段见过大量这种格式的数据所以当提示词看起来和训练数据形态接近时模型会更准确地知道当前任务是回答问题而不是续写故事。我在实际测试中发现如果只给一个问句不加 Answer 引导模型有时会复述问题有时会生成一段带有解释性的句子输出不够干净。加上 Answer 之后模型基本会把回答限制在答案本身。我还建议把max_new_tokens控制在合理范围。问题类任务一般 32 到 64 个 token 就够了给太多反而容易让模型在回答完后继续编内容。简单问题给 32复杂问题给 64是一个比较稳的起点。3.3 提示词设计BLIP-2 对“提问方式”比想象中敏感跑了大量测试之后我得说一句实话视觉语言模型对提示词确实敏感但它的敏感点和大语言模型不完全一样。大语言模型吃“请你详细描述一下”这类指令BLIP-2 这类模型的处理能力更依赖底层语言模型的表达能力提示词过度复杂反而可能干扰它。我整理了一套亲测有效的提示词模板直接照抄就行任务目标推荐提示词备注生成图片描述a photo of最通用输出短句描述回答图片问题Question: 问题内容 Answer:输出稳定几乎不会跑题提取场景信息This is a picture of适合想让结果以“这是一张...”开头判断图片属性Is the image about 某个主题? Answer yes or no.适合做二分类式判断用这些模板跑出来的结果普遍比自由发挥的提示词更干净。举个例子我想问图里的人是站还是坐写“Question: Is the person standing or sitting? Answer:”比写“请判断这个人的姿势并告知”要稳定得多。因为前者的训练分布更常见模型理解成本更低。如果你的问题包含多个对象尽量不要挤在一个句子里问。比如“图片里的人和狗分别在干什么”这类复合问题模型容易只回答其中一个对象。我的做法是先问“图里有哪几个主要对象”再针对每个对象单独提问。虽然多调几次 API 或多次推理但准确性明显更好。4. 实战扩展批量处理、中文输入与结构化输出4.1 批量给一批图片生成描述顺便存成 JSON 文件单张图跑通之后马上想到的自然就是批量处理。批量场景里最容易出的问题不是模型太慢而是一张图片读取出错导致整个脚本崩溃。所以处理函数里一定要加异常捕获把出错的图片单独记录下来。import json from tqdm import tqdm def process_image(path, prompta photo of): image Image.open(path).convert(RGB) inputs processor(imagesimage, textprompt, return_tensorspt).to( devicecuda, dtypetorch.float16 ) generated_ids model.generate(**inputs, max_new_tokens50) return processor.batch_decode(generated_ids, skip_special_tokensTrue)[0].strip() results [] for img_path in tqdm(image_paths): try: caption process_image(img_path) results.append({file: img_path, caption: caption}) except Exception as exc: results.append({file: img_path, error: str(exc)}) with open(captions.jsonl, w, encodingutf-8) as f: for item in results: f.write(json.dumps(item, ensure_asciiFalse) \n)用 JSONL 格式而不是一个 JSON 数组来存结果是我比较推荐的做法。每一行都是一条独立结果即使某一行写坏了也不影响其他数据后续用 pandas 读取也方便。ensure_asciiFalse一定要写否则中文内容会被转成一串 Unicode 转义字符可读性很差。批量性能方面我的实测数据是在普通中端显卡上每张图大约耗时 2 到 5 秒。瓶颈通常不是模型而是磁盘 IO 和图片解码。如果图片特别大先压缩到宽度 768 以内再推理速度和显存占用都会明显改善质量损失可以接受。4.2 中文提问怎么办翻译、规则映射和固定模板BLIP-2 的处理器在中文支持上很弱直接传中文问题往往效果不稳定。我在一开始也试过强行传中文结果模型要么输出英文答非所问要么生成一段与图片无关的内容。后来我总结出两条可行路线。第一条路线是把中文问题翻译成英文再调用模型。如果项目里已经有翻译服务比如在线翻译 API那直接串起来就行。每张图片的问题先翻译成英文走英文回答再翻译回中文。这个方案通用性最高但会引入额外延迟和成本。第二条路线是规则映射。如果业务场景非常固定比如你只关心“图片里有几个人”“颜色是什么”“主体在做什么”完全可以建一个中文问题模板到英文提示词的映射表QUESTION_MAP { 颜色: What color is the main object?, 数量: How many objects are there?, 动作: What is the person doing?, 场景: Is this indoor or outdoor?, } def ask_chinese(image, keyword): prompt fQuestion: {QUESTION_MAP[keyword]} Answer: inputs processor(imagesimage, textprompt, return_tensorspt).to( devicecuda, dtypetorch.float16 ) generated_ids model.generate(**inputs, max_new_tokens64) return processor.batch_decode(generated_ids, skip_special_tokensTrue)[0].strip()这种方式好处是零额外依赖速度也快缺点是需要自己维护英文提示词。我在实际项目中两种路线都用过对外服务用翻译路线内部数据清洗用规则映射。你可以根据自己的使用频率来选择。4.3 从自由文本到结构化数据接进业务流程模型输出的是一段自由文本比如“The man is cooking in the kitchen”。直接拿来展示没问题但想把它接进自动标注、报表统计这些流程最好还是先转成结构化数据。我的做法是先定义几个固定提问项把每个问题跑一遍再把结果组装成一条完整记录record { file: img_path, scene: ask_question(image, Is this indoor or outdoor?), action: ask_question(image, What is the person doing?), color: ask_question(image, What color is the main object?), time_hint: ask_question(image, Is this day or night?), }有这些字段之后你就有能力做非常粗糙但可用的“图片数据库”了。数据量大一点后还能把回答结果拼成一句话送入向量模型做语义检索。我自己最常用的是这个组合BLIP-2 生成结构化字段再联合现有文本检索系统实现“找一张白天的厨房里有人在做饭的照片”这类复合查询。5. 常见问题与排查技巧实录5.1 显存不足、加载失败这类“环境型”问题怎么破这一部分是所有用类似模型的同行都会经历的。我把高频问题整理成了下面的速查表现象可能原因解决办法CUDA out of memory模型底座太大或显存不足换更小的底座全程用 float16单张图片处理必要时用 8bit 量化模型加载后推理还是报 GPU 错误输入没有和模型在同一个设备上把inputs.to(cuda)并在需要时指定dtypetorch.float16加载时缺少某个模块方法torch 和 transformers 版本不匹配同时升级 torch、transformers、accelerateCPU 推理特别慢模型在 CPU 上运行换 GPU如果必须 CPU建议用最小的底座并限制图片尺寸显存问题是最常见的尤其是对于中端显卡。我的经验是先跑一个最小可用的组合小号底座、float16、单张图片。确认这条链路稳定之后再一步步扩大模型规模。不要一开始就追求大模型否则你很难判断瓶颈到底是显存、内存还是代码问题。5.2 生成结果短、重复、乱答问题出在生成参数很多人遇到生成结果不理想时第一反应是换模型。但我发现大部分问题其实出在生成参数上换模型反而更浪费。举几个真实案例。如果回答只输出一两个词往往是max_new_tokens设得太小模型还没说完就被截断了。这时把它从 10 调到 50 或 64 就能解决。如果出现循环重复比如一直重复同一个词或短语可以加上no_repeat_ngram_size3这会禁止模型连续重复已经出现过的三连词组合。如果模型答非所问先不要怀疑模型回头检查提示词格式。我遇到过几次都是因为我在提示词末尾写成了中文冒号或者漏掉了 Answer 引导结果模型不知道自己在做问答。把提示词规范成“Question: 内容 Answer:”之后效果立刻恢复正常。我自己常用的保守生成参数如下generated_ids model.generate( **inputs, max_new_tokens64, num_beams3, no_repeat_ngram_size3, do_sampleFalse, )要注意num_beams和do_sampleFalse是搭配着用的它表示使用束搜索而不是随机采样。对固定问题类任务来说这种模式输出更稳定不会每次结果都不一样。5.3 踩坑总结下载、缓存、图片格式等细节还有几个零碎但容易卡住人的细节我单独拎出来说。模型权重下载到一半中断是最烦的情况。解决办法是不要马上删除缓存目录第二次运行通常可以继续下载。如果一直卡在某个文件上换一个网络环境或者把已经下好的权重目录完整拷贝到目标机器上再用离线模式加载。图片格式问题很隐蔽。有些手机拍摄的照片包含旋转信息直接打开会把方向弄反。常规的.convert(RGB)不会处理这个信息需要额外用ImageOps.exif_transposefrom PIL import ImageOps image Image.open(path) image ImageOps.exif_transpose(image).convert(RGB)还要注意透明背景的 PNG。强行按 RGB 读入后透明区域有时会变成黑色虽然不报错但会影响模型判断。如果你需要处理这种图最好先把透明区域合成到白色背景上。中文路径也是个容易被忽视的点。Windows 下如果图片文件名包含中文部分环境下Image.open会直接失败。处理办法是用Path对象传入而不是字符串或者在读取前先对路径做编码处理。6. 性能优化与后续玩法6.1 半精度、8bit 量化把显存需求压下来如果你只有 8G 显存但又想尝试更大的模型底座可以考虑用 8bit 量化。Transformers 的加载接口里可以直接通过一行参数开启model Blip2ForConditionalGeneration.from_pretrained( MODEL_NAME, device_mapauto, load_in_8bitTrue, )注意这里不需要再额外写torch_dtypetorch.float16否则会和 8bit 量化冲突。开启后显存占用会进一步下降但推理速度会稍微变慢因为要加上反量化的计算。如果显存预算已经足够我建议还是优先用 float16速度和效果都更理想。还有一个小优化是图片尺寸。BLIP-2 内部会把图片缩放成固定尺寸但你输入一张 2000px 的大图时解码和预处理阶段会白白消耗内存。我在批量处理前会统一把图片最长边缩到 1024 以下不仅更快显存也更稳。对大多数描述和问答任务来说这个分辨率完全够用。6.2 快速封装一个命令行工具跑通脚本之后封装成命令行工具可以让同事或自己用起来更顺手。这里提供一个极简版本的思路import argparse parser argparse.ArgumentParser() parser.add_argument(--image, requiredTrue) parser.add_argument(--question, defaultNone) args parser.parse_args() image Image.open(args.image).convert(RGB) if args.question: prompt fQuestion: {args.question} Answer: else: prompt a photo of inputs processor(imagesimage, textprompt, return_tensorspt).to( devicecuda, dtypetorch.float16 ) generated_ids model.generate(**inputs, max_new_tokens64) print(processor.batch_decode(generated_ids, skip_special_tokensTrue)[0].strip())使用方式很简单python blip2_cli.py --image demo.jpg python blip2_cli.py --image demo.jpg --question what is the person doing?封装成命令行工具之后你就能在 shell 脚本里直接调用它了。批量场景甚至可以结合循环对每个图片文件自动生成描述文件。虽然跟完整 API 相比还很简陋但做内部工具已经足够。6.3 后续还能怎么扩展项目跑完以后可以扩展的方向其实很多。一个比较自然的路线是结合视频抽帧把视频拆成关键帧逐帧做图像问答再按时间顺序拼成一段短视频描述。画面变化越快抽帧密度就要越高同时也需要去重逻辑来避免连续帧反复输出同一句话。另一个方向是把它作为数据生产工具。我想给一批图片做分类标签但人工打标成本高就先让 BLIP-2 生成一堆问题和答案再用这些文本去辅助构建训练集。虽然生成的答案会有噪声但作为初筛和高置信样本的候选效率比纯人工高很多。最后分享一个我自己的操作习惯。每跑一批新图片前我都会先随机抽三张做人工核对看看模型输出的句式是否正常、是否存在幻觉式描述。这个步骤花不了几分钟但能及时发现因为图片主题大变化而引发的输出质量滑坡。毕竟模型不会告诉你它“看不懂”某类图片它只会用一段流畅的英文把它理解错的东西讲给你听。保持对输出质量的抽查意识是这个项目里最重要的一条经验。