多模态与工具链
Multimodal Tooling
Multimodal AI 最容易被做成“什么都能传”的 feature，但真正上线时问题很多：图像理解不稳、OCR 成本高、视频太慢、audio pipeline 难管、tool schema 一复杂就容易炸。AI engineer 真正要做的，不是把 modality 加得越多越好，而是把每一种 modality 变成可控的 product capability。
所以这页讲的不是模型列表，而是 multimodal tooling 应该怎么选、怎么接、怎么控。
先说结论：先拆 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 个问题答清楚后，再开始接模型和工具。