循序渐进 · 教学 · 多模态与嵌入 Multimodal & Embedding

让文本、图片、表格都能被「算」进同一个空间

这一篇讲两类模型：多模态模型（能读懂图、表）和嵌入模型（把文本变成可计算的向量）。学完你会知道什么时候该用现成模型、怎么为多语言或长文本调整策略。

全部目录 ← 上一篇多模态与嵌入下一篇 →

原文 Process multimodal and embedding models 预计阅读 9 分钟 含 互动演示 + 6 道测验

本文来源 · Source 内容整理自 Palantir Foundry 官方文档：
https://www.palantir.com/docs/foundry/ontology/aip-multimodal-and-embedding-models/
原始标题：Process multimodal and embedding models

★

一句话速览

让文本、图片、表格都能被「算」进同一个空间：这一篇讲两类模型：多模态模型（能读懂图、表）和嵌入模型（把文本变成可计算的向量）。学完你会知道什么时候该用现成模型、怎么为多语言或长文本调整策略。

1 这一篇在讲什么

做语义搜索或检索增强生成（RAG），光有「文本进、文本出」的大语言模型（LLM）往往不够

2 让 LLM 看懂图与表

原文开篇就点明了一个朴素的现实

3 把文本变成向量

嵌入模型（embedding model）的输出是一串数字——也就是向量（vector）

4 Ada 与查询 / 片段

原文把嵌入模型分成两类使用场景，这直接影响你该选哪种模型

这一篇在讲什么？

两类模型：多模态模型读懂图/表，嵌入模型把文本变成向量。

做语义搜索或检索增强生成（RAG），光有「文本进、文本出」的大语言模型（LLM）往往不够。原文这页标题就叫 Process multimodal and embedding models（处理多模态与嵌入模型），它把模型分成两条线来讲：

多模态模型 Multimodal

能直接吃图片、表格等非文本输入，弥补纯文本 LLM 的短板。

嵌入模型 Embedding

把文本编码成一串数字（向量），让「含义相近」的东西在向量空间里离得近。

这一篇偏「选型与原理」，具体的搭建步骤会在本系列后面的语义搜索、本体增强生成两篇里展开。

多模态模型：让 LLM 看懂图与表

文本进文本出的 LLM，对图表往往束手无策。

原文开篇就点明了一个朴素的现实：

If you want to answer questions based on diagrams, LLMs with the text-in-text-out architecture will be of no help. 如果你想基于图表来回答问题，那种「文本进、文本出」架构的 LLM 帮不上忙。

也就是说，当你要回答「这张表格里哪个值超标了」「这张图说明了什么」，纯文本 LLM 读不进去。原文提到几种能处理图像输入的选项：

模型 / 方案	特点
GPT-4o / GPT-4o mini	都能接受图像输入，是官方闭源里能直接读图的现成选择。
Pix2Struct	开源模型；原文在德语表格的质量检查（QA）上初测表现不错，可在 Hugging Face 试用。
Microsoft UDOP	开源的「通用文档处理」模型，但未上架 Hugging Face。

一种常见组合：先用文本提取得到文字（方便先搜一轮），再在原始来源页面（图片）上跑多模态模型，让它真正「看」图/表作答。这样检索和精读各取所长。

嵌入模型：把文本变成向量

含义相近的文本，在 N 维空间里离得近。

嵌入模型（embedding model）的输出是一串数字——也就是向量（vector）。如果模型够好，在 N 维空间里彼此靠近的向量，就代表含义相近的文本；检索本质就是「找最近的向量」。

原文特别提到，如果你的语料是英文，可以试试 MSMARCO 系列模型（来自 sentence-transformers）。 MS MARCO 是一批基于真实 Bing 搜索查询构建的大规模信息检索数据集，而这些模型：

these models were specifically trained to put queries and relevant passages close together in embedding space. 这些模型经过了专门训练，让「查询」和「相关段落」在嵌入空间里彼此靠近。

这一点很关键：它意味着 MSMARCO 这类模型天生适合「从用户查询出发」的语义搜索—— 你给一个关键词、一句话或一个问题，它就能找出相关的段落。

对照理解：这和上一页讲的概念一脉相承——向量越近 = 含义越近。多模态模型解决「怎么读图」，嵌入模型解决「怎么把文本变成可比的距离」。

等长 vs 非对称：Ada 与查询 / 片段

从「查询」出发、还是从「已有片段」出发，选模型的逻辑不同。

原文把嵌入模型分成两类使用场景，这直接影响你该选哪种模型：

✗ 直接拿 Ada 嵌入「查询」

场景：用查询去比一堆 chunk 的嵌入查询和段落是「不同类型」的文本直接比 → 不是同一个概念效果可能不如专门的模型

→

✓ 用「非对称」嵌入模型

场景：从用户查询出发的语义搜索 MSMARCO 类模型专为「查询↔段落」靠近而训或先用 LLM 生成「假设片段」(HyDE) 再嵌入桥接查询与答案之间的不对称

反过来讲，OpenAI Ada 更适合「从已有片段出发，找相似的片段」—— 比如你手里已经有一个 chunk，想找和它语义相近的其他 chunk。

还有一个实操坑：原文提醒，大多数非 Ada 的嵌入模型只支持 512 个 token，所以你的分块（chunking）策略必须相应调整——块不能太长。

Most non-ada embedding models only support 512 tokens, so you need to adapt your chunking strategy accordingly. 大多数非 Ada 嵌入模型只支持 512 个 token，因此你需要相应地调整分块策略。

动手演示：不同模态进入同一嵌入空间

点一个模态，看它被编码后落在共享嵌入空间的哪个位置。

下面这个空间（横竖只是示意）里，三种不同模态的「内容」最终都被表示成同一个空间里的点。点按钮看看每种模态靠什么模型被编码、又落在哪里——这正是「多模态 + 嵌入」能一起工作的原因。

动手试试 · 模态 → 嵌入空间

语义空间 →

语义空间 ↑

点上面的模态，看它被编码后落在共享嵌入空间的哪个位置。

说明：点的位置是教学示意（真实坐标由模型算出）。重点在于——无论文本、图片还是表格，最终都被映射进「同一个可比空间」，检索时才能量化「谁离谁更近」。

选型与踩坑：照着原文的建议来

语言、模型可得性、token 限制，都是选型变量。

原文最后给了几条非常落地的建议，我们整理成「照着做」的清单：

英文语料：优先试 MSMARCO 系列（sentence-transformers），专为查询-段落靠近而训。
从查询出发搜：用非对称嵌入模型，或先让 LLM 生成「假设片段」（HyDE）再嵌入，弥合查询与答案的不对称。
从已有片段出发找相似：Ada 更合适。
非 Ada 模型多限制 512 token：务必把分块切小，配合文档处理那一篇的 chunking 策略。
德语等小语种：原文提到，目前 GPT 是少数表现还行的 LLM，德语语料可尝试 ada。

一句话心法：先想清楚你的搜索是「从一句话出发」还是「从一段已有文本出发」，再决定用哪种嵌入模型——这一步选对了，后面的语义搜索才站得住。

一页带走

① 多模态读图

文本 LLM 读不进图/表，需 GPT-4o、Pix2Struct、UDOP 等。

② 嵌入即向量

文本被编码成向量，近邻=近义，检索即找最近点。

③ 选对不对称

查询出发用非对称/HyDE；片段找相似用 Ada。

④ 注意 512

非 Ada 多限 512 token，分块要切小。

延伸阅读 · 相关页面

按主题横向跳转，不必顺着目录一篇篇读。

常见问题速答 · FAQ

关于「让文本、图片、表格都能被「算」进同一个空间」，读者最常问的几个问题。

这一篇在讲什么？

做语义搜索或检索增强生成（RAG），光有「文本进、文本出」的大语言模型（LLM）往往不够。原文这页标题就叫 Process multimodal and embedding models（处理多模态与嵌入模型），它把模型分成两条线来讲。

嵌入模型：把文本变成向量是什么？

嵌入模型（embedding model）的输出是一串数字——也就是向量（vector）。如果模型够好，在 N 维空间里彼此靠近的向量，就代表含义相近的文本；检索本质就是「找最近的向量」。

Ada 与查询 / 片段是什么？

原文把嵌入模型分成两类使用场景，这直接影响你该选哪种模型。

动手演示：不同模态进入同一嵌入空间是什么？

下面这个空间（横竖只是示意）里，三种不同模态的「内容」最终都被表示成同一个空间里的点。点按钮看看每种模态靠什么模型被编码、又落在哪里——这正是「多模态 + 嵌入」能一起工作的原因。

全部目录 ← 上一篇：文档处理下一篇：本体增强生成 →