尧图建网站 尧图建网站 YAOTU WEB BUILD 免费咨询
ARTICLE DETAIL

资讯详情

深耕网站建设与建站编程的一线实战洞察。

给DeepSeek安上眼睛:伪多模态识图问答流水线搭建实践

给DeepSeek安上眼睛:伪多模态识图问答流水线搭建实践 实际使用 DeepSeek 时很多人会撞上同一个坎DeepSeek 目前的主流 API 是文本接口不支持直接传图片也不能像多模态模型那样直接“看”截图。于是“给 DeepSeek 安上眼睛支持识图”的伪多模态方案就成了一种非常实用的工程补法。所谓伪多模态并不是给 DeepSeek 注入视觉能力而是用 OCR、视觉语言模型等外部模块先把图片转成文字描述再把文字作为上下文交给 DeepSeek 做推理。下面从架构、环境、代码、参数、排错和生产化六个层面搭建一条可复用的识图问答流水线。1. “伪多模态”是什么先想清楚架构再动手1.1 DeepSeek 是文本模型图片输入需要外挂“眼睛”DeepSeek 的 API 形态是 Chat Completion输入的消息内容以文本为主。如果你尝试把图片的 base64 字符串直接塞进 prompt模型并不会像原生多模态模型那样“看懂”图片只会把它当成一串无意义的字符。这不是模型能力不行而是接口设计本身不接收图像 token。伪多模态的常见理解是保留 DeepSeek 作为推理大脑在它前面额外接一个“眼睛”模块。眼睛模块负责把图片翻译成文本包括图片里的文字、物体、场景、表格结构等。翻译结果再作为问题上下文交给 DeepSeek从而让一个纯文本模型做到“能根据图片回答问题”。这种设计在工程上非常常见甚至比原生多模态更适合某些场景。因为视觉提取器可以按需替换识别单据时用 OCR理解截图时用视觉语言模型检索图片时用向量模型。管道是解耦的哪一环效果不好就单独优化哪一环。原生多模态与伪多模态的关键差异如下表所示对比项原生多模态模型DeepSeek 外部视觉模块图片输入直接传图需要先把图片转成文本描述信息损耗模型可看到完整像素依赖视觉模块的描述完整度模型选择只能使用支持图片输入的模型DeepSeek 负责推理视觉模块可自由更换成本控制图片 token 通常更贵本地 OCR 免费远程视觉模型按量计费隐私控制图片必须发给模型服务方本地 OCR 可以做到图片不出本机开发复杂度较低需要设计多模块管线和文本模板1.2 “眼睛”选型OCR、视觉语言模型、向量检索、结构化预标注先确定你要让 DeepSeek“看”出什么再选择眼睛模块。常见的做法有四种适用场景完全不同。第一种是纯 OCR。OCR 只负责提取文字适合票据、截图、合同、车牌等以文字为主要信息的图片。它的优点是部署简单、成本低、可本地运行缺点是无法回答“图里有什么颜色”“这是什么场景”这类问题。第二种是视觉语言模型VLM。这类模型可以直接输入图片并输出自然语言描述可以回答物体、场景、人物行为、图表内容等。适合通用识图问答、无障碍辅助、截图分析。缺点是视觉模型通常较大远程调用时图片数据会离开本机本地部署时对显存有要求。第三种是 CLIP 这类图文向量模型。CLIP 不生成描述而是把图片映射成向量适合做相似图检索、图片分类、标签过滤。它通常作为前置召回模块输出候选结果后再交给 DeepSeek 总结而不是直接回答用户问题。第四种是结构化预标注。提前用脚本保存图片的文件名、大小、拍摄时间、GPS 信息、项目 ID 等元数据再配合少量规则生成描述。这种方法信息密度低但胜在完全离线、稳定可复现适合做兜底。选型时可以按这个顺序判断图片里最重要的是文字吗是则 OCR。图片需要理解语义吗是则 VLM。图片数量很多、需要先筛出相关图吗是则向量检索。图片元数据能覆盖用户问题吗是则结构化预标注。实际项目中OCR 和 VLM 经常组合使用形成“文字 场景”的双通道描述。1.3 最小链路图片 - 文本描述 - DeepSeek 推理不管最终选哪种眼睛伪多模态的链路都可以抽象成四步读取图片并做基本预处理例如压缩、转正方向、转 RGB。调用视觉提取器生成文本化描述例如 OCR 结果或 VLM 场景描述。把描述文本与用户问题组装成 prompt交给 DeepSeek。DeepSeek 基于这段文本上下文返回答案。这个链路最核心的一点是DeepSeek 的答案质量上限取决于视觉提取器把图片“翻译”得是否完整。它只能基于给定文本推理无法补全图片中未被描述出来的细节。社区里一些桌面端或终端工具会把“视觉插件”装进 DeepSeek 客户端原理仍然是外挂眼睛模块理解这条链路之后再看这些工具会容易很多。注意伪多模态中模型必须清楚自己是通过“间接描述”了解图片而不是直接看到图片。这样设计 prompt能明显减少模型“脑补”图片内容带来的幻觉。2. 环境准备从依赖到项目骨架2.1 运行环境与依赖清单本文实现采用 Python 3.10 或更高版本。建议先创建虚拟环境避免依赖冲突。核心依赖如下依赖库用途是否必选openai调用 DeepSeek 的 OpenAI 兼容接口必选Pillow图片读取、压缩、格式转换必选python-dotenv从 .env 文件读取密钥配置必选paddleocr本地 OCR 提取文字可选paddlepaddlePaddleOCR 的深度学习运行时可选fastapi将识图能力封装成 HTTP 服务可选安装命令如下python -m venv .venv source .venv/bin/activate pip install -U pip pip install openai Pillow python-dotenv如果决定使用本地 OCR再执行pip install paddlepaddle paddleocrPaddleOCR 在不同平台的安装方式有差异CPU 环境可以安装 CPU 版 PaddlePaddle有 NVIDIA GPU 的环境可以安装 GPU 版。这里以功能演示为主不深入显卡驱动配置。远程视觉语言模型方案不需要安装 PaddleOCR只需要一个支持 OpenAI 风格接口的视觉模型服务。2.2 创建项目目录推荐按下面的目录结构组织代码deepseek-vision/ ├── .env ├── .gitignore ├── requirements.txt ├── cli.py ├── deepseek_client.py ├── vision/ │ ├── __init__.py │ ├── extractor.py │ ├── local_ocr.py │ └── remote_vlm.py └── images/ └── demo.png各文件职责如下.env存放 API Key、模型名等环境变量不入库。requirements.txt记录 Python 依赖。vision/extractor.py定义视觉提取器抽象接口。vision/local_ocr.py实现本地 OCR 提取器。vision/remote_vlm.py实现远程视觉语言模型提取器。deepseek_client.py封装 DeepSeek 调用。cli.py命令行入口串联整条识图问答流程。.gitignore中至少写入.env .venv/ __pycache__/ images/ *.log2.3 准备 DeepSeek API Key在 DeepSeek 开放平台创建 API Key 后写入.envDEEPSEEK_API_KEYsk-你的key DEEPSEEK_BASE_URLhttps://api.deepseek.com DEEPSEEK_MODELdeepseek-chat如果同时使用远程 VLM再加几项VLM_BASE_URLhttps://your-vlm-service/v1 VLM_MODELyour-vlm-model然后在代码中通过python-dotenv加载。不把 Key 写进代码是为了避免项目上传到 Git 仓库时泄露密钥。验证 Key 是否可用可以跑一个最小请求python -c from openai import OpenAI import os from dotenv import load_dotenv load_dotenv() client OpenAI(api_keyos.environ[DEEPSEEK_API_KEY], base_urlos.environ.get(DEEPSEEK_BASE_URL, https://api.deepseek.com)) resp client.chat.completions.create( modelos.environ.get(DEEPSEEK_MODEL, deepseek-chat), messages[{role: user, content: ping}], ) print(resp.choices[0].message.content) 如果返回文本而不是报错说明 Key、网络和模型名都可用。注意不同版本的 SDK 对base_url的拼接方式不同实际使用以你所用的 OpenAI SDK 文档和 DeepSeek 官方文档为准。2.4 准备可选的本地 OCR 运行环境本地 OCR 适合图片内容以文字为主、且对隐私要求较高的场景。PaddleOCR 首次运行时会自动下载检测和识别模型需要联网。如果运行环境无法联网需要提前下载模型并在初始化时指定模型目录。安装完成后可以先用一张截图做冒烟测试python -c from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch, show_logFalse) result ocr.ocr(images/demo.png, clsTrue) print(result) 这里要注意PaddleOCR 不同版本之间的返回结构有差异。有的版本返回[ [ [box, (text, score)], ... ] ]有的版本会改变参数名。生产代码中建议先打印原始结构再写解析逻辑不要照搬网络上的老代码。3. 实现“识图”管线让 DeepSeek 能看图回答问题3.1 设计视觉提取器接口为了让下游代码不依赖具体视觉实现先定义一个抽象接口。后续无论换成 OCR、VLM还是以后接入官方多模态能力调用方都不需要大改。# vision/extractor.py from abc import ABC, abstractmethod class VisionExtractor(ABC): abstractmethod def extract_text(self, image_path: str) - str: 输入图片路径返回图片的结构化文本描述 raise NotImplementedError这里的extract_text返回的是文本。对于 OCR 来说返回识别出的文字对于 VLM 来说返回自然语言描述。这样 DeepSeek 收到的始终是同一类结构一段与图片有关的文本。3.2 实现本地 OCR 提取器下面实现一个基于 PaddleOCR 的提取器。它会把识别出的每一行文字和置信度拼接起来便于后续过滤低质量结果。# vision/local_ocr.py from .extractor import VisionExtractor class LocalOCRExtractor(VisionExtractor): def __init__(self, lang: str ch): from paddleocr import PaddleOCR self.ocr PaddleOCR(use_angle_clsTrue, langlang, show_logFalse) def extract_text(self, image_path: str) - str: result self.ocr.ocr(image_path, clsTrue) lines [] if not result: return for page in result: if not page: continue for box, line in page: text line[1][0] score line[1][1] lines.append(f{text}\t置信度:{score:.2f}) return \n.join(lines)这段代码有几个关键点。box是目标框坐标这里没有使用line是一个包含(text, score)的二元结构。真实项目中如果置信度低于 0.5通常可以直接丢弃避免把明显错误的文字喂给 DeepSeek。注意PaddleOCR 的返回值兼容性较弱。不同版本可能把坐标、文本、置信度的嵌套顺序调整。在项目初期建议先打印一次result按实际结构修改解析代码。3.3 实现远程视觉语言模型提取器如果图片里除了文字还需要理解物体、场景、图表比例等OCR 就不够了。可以接入一个支持 OpenAI 兼容接口的视觉语言模型服务。这里的模型不是 DeepSeek而是真正能接受图片输入的视觉模型。# vision/remote_vlm.py import base64 from openai import OpenAI from .extractor import VisionExtractor class RemoteVLMVisionExtractor(VisionExtractor): def __init__(self, base_url: str, model: str, api_key: str local): self.client OpenAI(base_urlbase_url, api_keyapi_key) self.model model def extract_text(self, image_path: str) - str: with open(image_path, rb) as f: image_data base64.b64encode(f.read()).decode() resp self.client.chat.completions.create( modelself.model, messages[ { role: user, content: [ { type: text, text: 请用中文描述这张图片包括文字、物体、布局和图表内容。如果图片中有重要数字请准确提取。, }, { type: image_url, image_url: { url: fdata:image/png;base64,{image_data} }, }, ], } ], max_tokens1000, ) return resp.choices[0].message.content or 这里base64编码会把图片体积膨胀约三分之一。如果图片非常大建议先做压缩避免请求体超限。另外本地一些推理框架提供的是/v1/chat/completionsOpenAI 兼容接口api_key可以随便填一个非空字符串因为本地服务通常不校验。3.4 实现 DeepSeek 调用模块视觉模块给出图片的文本描述后下一步就是把描述和问题一起交给 DeepSeek。# deepseek_client.py import os from openai import OpenAI class DeepSeekClient: def __init__(self): self.client OpenAI( api_keyos.environ[DEEPSEEK_API_KEY], base_urlos.environ.get( DEEPSEEK_BASE_URL, https://api.deepseek.com ), ) self.model os.environ.get(DEEPSEEK_MODEL, deepseek-chat) def ask(self, image_context: str, question: str) - str: resp self.client.chat.completions.create( modelself.model, messages[ { role: system, content: ( 你是图像分析助手。你不会直接看到图片必须依据用户提供的 图片文字描述和 OCR 结果回答问题。不要编造图片中不存在的信息。 ), }, { role: user, content: f图片描述\n{image_context}\n\n问题{question}, }, ], temperature0.2, max_tokens2000, ) return resp.choices[0].message.content or system prompt 是这条链路能否稳定工作的关键。它明确告诉模型你没有直接看到图片所有图片信息都来自给定的描述。没有这句约束模型很容易顺着用户的提问“看图说话”编造出视觉模块从未提取过的细节。3.5 组装识图问答函数现在把视觉提取器和 DeepSeek 客户端串起来。命令行程序允许用户选择ocr或vlm作为眼睛后端。# cli.py import argparse import os from dotenv import load_dotenv from vision.local_ocr import LocalOCRExtractor from vision.remote_vlm import RemoteVLMVisionExtractor from deepseek_client import DeepSeekClient load_dotenv() def build_extractor(backend: str): if backend ocr: return LocalOCRExtractor() if backend vlm: return RemoteVLMVisionExtractor( base_urlos.environ[VLM_BASE_URL], modelos.environ[VLM_MODEL], ) raise ValueError(funknown backend: {backend}) def main(): parser argparse.ArgumentParser(description给 DeepSeek 安上伪多模态眼睛) parser.add_argument(image, help图片路径) parser.add_argument(question, help对图片提出的问题) parser.add_argument(--backend, choices[ocr, vlm], defaultocr) args parser.parse_args() extractor build_extractor(args.backend) context extractor.extract_text(args.image) if not context.strip(): print(提示视觉提取器没有产出有效文本DeepSeek 可能无法回答这个问题。) print(视觉提取结果) print(context) print(\n--- DeepSeek 回答 ---) client DeepSeekClient() print(client.ask(context, args.question)) if __name__ __main__: main()运行方式python cli.py images/demo.png 这张图片里有哪些文字如果使用远程视觉模型python cli.py images/demo.png 请总结这张截图的内容 --backend vlm先看到“视觉提取结果”是否合理再判断 DeepSeek 的回答是否可信。如果视觉模块提取的内容本身就缺字那 DeepSeek 答错并不是它的责任而是“眼睛”没看清。4. 关键参数与提示词模板决定识别质量的关键细节4.1 DeepSeek 推理参数速查调用 DeepSeek 时几个重要参数会直接影响回答风格和稳定性。参数建议值影响temperature0.2 到 0.7越低越严格适合事实类问答越高越有创造性适合写作和头脑风暴top_p0.7 到 0.9控制候选词范围与 temperature 配合使用一般不需要同时调太激进max_tokens500 到 2000控制回答最大长度过长会增加耗时和费用frequency_penalty0 到 0.5降低重复内容适合长文本生成presence_penalty0 到 0.5鼓励模型谈论新话题适合开放问答streamfalse / true生产环境可以开启流式输出提升用户感知速度识图问答属于信息抽取和判断类任务建议temperature设置在 0.2 左右让它更忠于给定文本而不是发挥想象力。如果希望 DeepSeek 在描述基础上做推理例如推断图片中人物可能的状态可以适度提高到 0.4 到 0.6。4.2 用提示词模板约束输出伪多模态的常见失败原因不是模型答错而是模型根本不知道自己“看不到图”。一个可复用的 system prompt 模板如下你是图像分析助手。用户会提供一段由视觉模块生成的“图片文字化结果”其中可能包含 OCR 文本、目标描述、置信度等。 规则 1. 只能基于给定的图片描述回答不能声称自己看到了图片。 2. 如果描述中没有足够信息回答请明确说出缺少哪些信息。 3. 遇到数字、金额、编号时先引用来源再下结论。 4. 输出不超过 500 字。这个模板包含四层约束身份约束、信息来源约束、缺失信息处理、输出格式约束。对新手来说第 2 条最容易忽略。如果不告诉模型“没有信息就承认”模型会选择编造一个看似合理的答案这在把图片内容转成文本的间接推理场景里尤其危险。把模板与用户问题拼接成最终 message 时要保证图片描述出现在问题之前并且用明显标记分隔图片描述 [视觉模块输出的 OCR 或 VLM 文本] 问题 [用户问题]4.3 图像描述质量对结果的影响DeepSeek 只能“看到”文本化的图片描述所以描述质量决定了推理上限。常见问题有以下几类第一OCR 漏字。印章盖住正文、文字倾斜、模糊截图都会导致漏识别。解决方式是先用 OpenCV 或 Pillow 做图像矫正和增强再交给 OCR。第二VLM 描述过于概括。有些视觉模型会输出“这是一张人物合照”这样的大类描述但用户实际问的是“照片里的门牌号是多少”。此时描述里没有数字DeepSeek 自然答不出来。第三图表信息丢失。折线图、柱状图只靠 OCR 很难还原趋势。建议让视觉模型输出结构化数据例如“x 轴月份y 轴销量2025 年 3 月销量最高”再交给 DeepSeek 做趋势分析。为了提高描述质量可以把多个视觉模块组合起来context_parts [] ocr_text ocr_extractor.extract_text(image_path) vlm_desc vlm_extractor.extract_text(image_path) if ocr_text.strip(): context_parts.append(OCR 结果\n ocr_text) if vlm_desc.strip(): context_parts.append(VLM 场景描述\n vlm_desc) full_context \n\n.join(context_parts)这样 DeepSeek 收到的信息更完整既能看到文字也能看到场景语义。不过 token 消耗也会增加实际项目需要在信息完整度和成本之间取舍。5. 常见问题与排查路径5.1 API 返回 401、429、400 怎么查调用 DeepSeek 时最常见的错误可以按下面的表格排查。错误现象可能原因检查方式处理建议401 invalid api keyKey 错误、过期或格式不对打印环境变量检查是否有多余空格在开放平台重新生成 Key429 rate limit请求频率过高或账户余额不足查看平台用量和计费降低并发增加退避重试或充值400 模型名不存在传入了不存在的 model打印 model 字段修改为官方文档中的模型名400 图片字段不支持直接向 DeepSeek 传递 image_url 内容检查请求体把图片先转成文本再调用 DeepSeek400 reasoning_content 错误思考模式字段未被正确回传查看代理工具日志中的 upstream_status使用支持透传的代理或关闭 thinking 模式关于reasoning_content这个错误常见出现在用第三方代理工具转发 DeepSeek 请求时。DeepSeek 的思考模式会返回reasoning_content字段一些工具在下一轮请求时没有把这个字段原样传回导致上游返回 400。排查方法是先看代理工具日志确认报错来自 DeepSeek 还是本地代理再检查工具版本是否支持 DeepSeek 思考模式如果不需要思考过程可以关闭相关开关。5.2 图片预处理问题视觉模块对图片格式和大小有要求。常见坑包括图片过大base64 超限。处理方式是压缩到合适尺寸。图片带透明通道某些视觉模型不支持。处理方式是转成 RGB。手机照片带 EXIF 旋转信息OCR 可能识别倾斜文字。处理方式是先用 PIL 读取并转正。多页 PDF 不能直接识别。处理方式是逐页转成图片。一个通用的预处理片段from PIL import Image img Image.open(input.png) img img.convert(RGB) img.thumbnail((1280, 1280)) img.save(resized.jpg, JPEG, quality85)压缩后图片体积会明显下降远程 VLM 请求更快本地 OCR 也能提速。但注意压缩不能太狠否则小字号文字会糊掉。5.3 本地 OCR 运行问题本地 OCR 的常见问题集中在安装、性能和返回结构三方面。安装慢或失败时先确认 Python 版本和 PaddlePaddle 版本是否匹配CPU 环境安装也建议先装小版本再升级。首次运行需要下载模型如果公司网络受限可以手动下载模型文件并配置模型路径。性能慢时优先压缩图片并关闭不必要的识别选项。例如只识别中文时langch就足够不需要方向分类时可以关闭use_angle_cls。返回结构变化问题时不要死记旧代码。直接打印result看实际嵌套结构再写解析。5.4 伪多模态的边界问题伪多模态的边界必须提前想清楚。DeepSeek 无法理解图片中的颜色、人脸表情、物体空间关系除非视觉模块把这些信息写出来。例如用户问“这张照片里红色气球在哪”如果 VLM 描述只写了“房间里有很多气球”没有提到位置DeepSeek 就只能说“根据描述无法判断”。这不是 DeepSeek 不行而是视觉模块没提供关键信息。另一个边界是上下文记忆。当前cli.py是一次性问答没有记忆能力。如果用户想连续追问“上一张图里那个人的名字是什么”需要把历史对话一起传给 DeepSeek同时把图片描述保存为会话上下文而不是只传最后一次提问。5.5 一条整体排错链路遇到问题别急着调 DeepSeek先按下面的顺序分段验证直接用一张文字清晰的截图测试视觉提取器确认 OCR 或 VLM 有输出。打印视觉提取结果判断问题是“眼睛没看清”还是“大脑答不好”。直接向 DeepSeek 发一段固定文本确认 API Key 和模型名可用。如果 DeepSeek 回答跑偏检查 system prompt 是否限制了“只能基于给定描述回答”。如果回答总是一样检查是否命中缓存以及 temperature 是否设置过低。如果线上频繁超时检查图片压缩是否生效以及视觉模块是否在同步任务中阻塞。这条链路把问题拆成了图片侧、接口侧、模型侧、应用侧能避免在错误层级上反复折腾。6. 生产环境建议与扩展方向6.1 学习环境与生产环境的差异本地脚本适合验证思路但如果要做成 Web 服务差距不小。维度学习环境生产环境调用方式命令行一次调用HTTP API支持并发图片存储本地路径对象存储或临时文件系统耗时处理同步等待异步任务、消息队列、轮询结果密钥管理.env密钥管理服务环境变量注入日志print结构化日志Trace ID接口鉴权无API Key、签名、白名单一个最简单的 FastAPI 封装可以这样写from fastapi import FastAPI, File, Form, UploadFile from dotenv import load_dotenv from vision.local_ocr import LocalOCRExtractor from deepseek_client import DeepSeekClient load_dotenv() app FastAPI() extractor LocalOCRExtractor() client DeepSeekClient() app.post(/v1/image-qa) async def image_qa( file: UploadFile File(...), question: str Form(...), ): image_bytes await file.read() temp_path /tmp/input.png with open(temp_path, wb) as f: f.write(image_bytes) context extractor.extract_text(temp_path) answer client.ask(context, question) return {context: context, answer: answer}生产环境不能这样直接写至少还要加上文件大小限制、内容类型校验、请求鉴权和超时控制。图片也不能固定写到/tmp/input.png否则并发请求会互相覆盖。6.2 工程化改进缓存、异步、日志、监控图片识别是耗时操作尤其是本地 OCRCPU 环境单张可能需要几秒甚至更久。工程化时重点考虑四点。第一结果缓存。同一张图片的 OCR 结果可以被多次复用建议以图片内容哈希作为缓存 key缓存到 Redis 或本地 KV。这样用户问不同问题时不需要重新跑 OCR。第二异步化。FastAPI 接口中如果直接跑 OCR会阻塞事件循环。应把 OCR 任务放到 Celery、RQ 或独立 worker调用方先拿到任务 ID再轮询结果。第三日志。至少记录图片尺寸、提取器类型、OCR 耗时、VLM 耗时、DeepSeek 耗时、token 数、错误类型。没有日志生产环境出问题时只能盲猜。import logging import time logger logging.getLogger(vision-pipeline) start time.monotonic() context extractor.extract_text(image_path) logger.info( extract cost%.2fs context_len%d, time.monotonic() - start, len(context), )第四监控。统计 OCR 成功率、VLM 响应时长、DeepSeek 调用失败率、接口 P95 耗时的变化。出现明显波动时要能定位到是视觉模块、网络还是模型侧的问题。6.3 隐私与合规如果图片包含身份证、病历、聊天记录、财务数据等敏感信息就不能随意把图片发给远程视觉模型。建议优先使用本地 OCR 或本地 VLM。远程调用时至少确认服务方是否留存图片、是否用于模型训练、是否提供删除接口。另外不要在前端页面里暴露 DeepSeek API Key。生产环境应通过后端鉴权把密钥保存在服务端用最小权限原则限制 Key 的调用范围。6.4 扩展方向多模态搜索、截图自动描述、知识库辅助伪多模态管线做熟之后可以继续扩展。一是多模态搜索。用 CLIP 把图片向量化用户输入文字描述后先检索相似图片再让 DeepSeek 对候选图片生成总结。适合相册管理、商品图库、设计素材检索。二是截图自动描述。定时截屏后自动执行 OCR 和 VLM生成工作日志。例如记录每日开发过程中看到的报错截图自动归类到问题库。三是知识库辅助。把发票、合同扫描件先转成文本再结合 RAG 检索让 DeepSeek 回答“某合同里违约条款是什么”这类问题。这里的重点不是让 DeepSeek 看图而是把图片里的信息变成可检索的文档。如果未来 DeepSeek 官方推出了支持图片输入的多模态版本这套管线的价值也不会浪费。视觉提取器的输出可以退化为“预筛选”和“辅助描述”下游 prompt 逻辑仍然可以复用。伪多模态的核心不是让模型真的长出一双眼睛而是学会在模型能力边界外用工程手段把信息无损地搬到模型能理解的语言里。先跑通 OCR再加入 VLM再考虑异步和生产化是这条路上最稳妥的顺序。
返回列表