多模态与工具链

⏱️ 40分钟

Multimodal Tooling

Multimodal AI 最容易被做成“什么都能传”的 feature，但真正上线时问题很多：图像理解不稳、OCR 成本高、视频太慢、audio pipeline 难管、tool schema 一复杂就容易炸。AI engineer 真正要做的，不是把 modality 加得越多越好，而是把每一种 modality 变成可控的 product capability。

所以这页讲的不是模型列表，而是 multimodal tooling 应该怎么选、怎么接、怎么控。

Multimodal Tooling Matrix

先说结论：先拆 modality，再选工具

很多 team 一看到支持 vision / audio / video 的模型，就想“一把梭”。
更稳的顺序应该是：

明确你要处理哪种输入
判断是直接多模态理解，还是先转成 text
再决定用通用模型还是专用工具

不是所有 multimodal task 都该直接交给一个大模型做。

不同 Modality，工程问题完全不同

Modality	常见任务	工程重点
image	OCR、caption、UI understanding、chart Q&A	resolution、OCR quality、region reference
audio	STT、meeting note、TTS	noise、speaker、chunk、timestamp
video	transcript、scene summary、event extraction	frame sampling、长时长、成本
files	PDF、slides、spreadsheet、repo	parsing、metadata、page mapping
tools	web search、DB query、code exec	schema、permission、latency、safety

如果你把这些问题当成一类处理，后面很容易又贵又不稳。

一个更现实的工具选择逻辑

场景	更稳的方案
简单图片理解	vision-capable LLM
高质量 OCR	先 OCR，再交给 text LLM
meeting transcript	先 STT，再做 summary / action item
长视频分析	transcript + scene summary，而不是逐帧硬喂
结构化图表理解	专用解析 + LLM 解释

很多 multimodal 系统真正跑得稳，是因为先做 preprocessing，而不是直接把原始输入丢给模型。

Metadata 是 multimodal 系统的命根子

一旦进入图片、音频、视频、PDF，metadata 就变得非常关键。

最少要保留：

filename / source id
page / frame / timestamp
chunk order
extraction method
confidence if available

没有这些，后面 citation、review、debugging 都会变得非常困难。

Multimodal RAG，不是把文件扔进向量库就结束

更靠谱的做法通常是：

extract text / OCR / transcript
  -> add metadata
  -> embed/index
  -> retrieve by source-aware chunks
  -> generate with citations

尤其是 image 和 video，真正可检索的常常不是原始像素，而是：

OCR text
caption
scene summary
timestamped transcript

这也是为什么 multimodal RAG 更像一个 data pipeline，不只是 model feature。

Tool Integration 的核心是 schema 和 permission

只要接外部工具，就不能只想“能不能调通”。

更该关注：

问题	为什么重要
tool schema 是否清晰	不清楚就会频繁调用错
domain / DB scope 是否受限	防止越权和脏查询
timeout 和 retry 怎么设	tool call 很容易拖慢整链路
output 怎么回灌模型	避免上下文污染和格式乱掉

多模态系统一旦接 tool，稳定性难度会明显上升。

UX 上别忘了告诉用户系统看到了什么

这点很重要。
很多用户上传文件后，根本不知道系统到底识别了哪些内容。

更好的 multimodal UX 通常会展示：

upload status
file / duration / page limits
extracted summary preview
citation 到 page / timestamp
error on unsupported input

用户一旦不知道系统“看到了什么”，就很难建立 trust。

测试不能只做文本样本

Multimodal eval 至少要分 modality 做。

测试项	为什么要单独测
noisy image / OCR	真实图像不会都很干净
noisy audio	会议环境常常很差
long video	成本和延迟会突然上升
chart / slide understanding	很容易看错结构
tool-augmented output	一旦接 tool，错误类型更多

只用理想样本测试 multimodal feature，基本等于没测。

最容易被低估的成本

Multimodal 成本不仅是模型调用本身。

还包括：

OCR / STT 预处理成本
大文件存储和传输成本
更复杂的日志与排障成本
更高的 eval 和人工 review 成本

如果只预算 LLM 调用价，通常会低估很多。

Practice

拿一个你要做的 multimodal feature，先回答这 4 个问题：

真实输入是什么 modality
先转 text 会不会更稳
metadata 要保留哪些字段
citation 和 error UX 怎么展示

这 4 个问题答清楚后，再开始接模型和工具。

📚 相关资源

Gemini API 快速上手

❓ 常见问题

关于本章主题最常被搜索的问题，点击展开答案

多模态系统应该把所有输入都直接喂给一个大模型吗？

不该。更稳的顺序是先拆 modality、再决定路径。简单图片用 vision LLM；高质量 OCR 应该先 OCR 再交给 text LLM；会议录音先 STT 再做 summary；长视频用 transcript + scene summary，而不是逐帧硬喂。多模态系统真正跑得稳，是因为先做 preprocessing —— 把原始像素 / audio 变成带 metadata 的文本，而不是把 raw 数据扔给模型让它自己整。

做 multimodal RAG 至少要保留哪些 metadata？

最少五件事：filename / source id、page / frame / timestamp、chunk order、extraction method、confidence（如有）。没有这些后面 citation、review、debugging 全部炸 —— 用户看到一段答案问 "这是 PDF 哪一页?"，你查不出来就丢失信任。图片 / 视频真正可检索的常常不是原始像素，而是 OCR text、caption、scene summary、timestamped transcript，所以 metadata 是命根子。

多模态系统的真实成本里，最容易被低估的是哪一块？

预处理 + 长尾运维。LLM 调用价只是表面 —— OCR / STT 预处理、大文件存储和传输、更复杂的日志和排障、更高的 eval 和人工 review 成本，加起来通常比模型调用更贵。一个长视频 transcript pipeline 跑一次几毛钱，但每天跑一万个 + 失败重试 + 标注审查，月度成本完全是另一个量级。只预算 LLM token 的团队基本都会超支。

多模态 feature 的 UX 上最容易遗漏的是什么？

告诉用户 "系统看到了什么"。用户上传 PDF / 图 / 录音后，根本不知道你识别出了哪些内容 —— 这种黑盒会直接摧毁信任。最少要给：upload status、file / duration / page limits、extracted summary preview、citation 到 page / timestamp、unsupported input 的明确报错。让用户能验证你看到的和他想的是不是同一件事，是 multimodal UX 的底线。

multimodal feature 的测试为什么不能只用干净样本？

真实世界没有干净样本。eval 必须按 modality 分别测：noisy image / OCR、noisy audio（会议环境通常很差）、long video（成本和延迟会突然爆）、chart / slide understanding（结构最容易看错）、tool-augmented output（一旦接 tool 错误类型立刻翻倍）。只用理想样本测过的多模态系统，上线第一周就会被用户的真实输入暴打 —— 模糊扫描件、地铁里的语音、200 页 PDF 是常态。