UniNote：统一多模态嵌入

小红书的核心思路很简单：一篇笔记、一个嵌入、一条搜索路径。 UniNote 不再用彼此独立的系统处理文本、图像、视频和音频，而是将它们放进同一个共享向量空间，同时用于检索和排序。

如果把这篇论文浓缩一下，我认为最重要的是以下几点：

• UniNote 为每篇笔记生成一个多模态嵌入
• 它采用两个训练阶段，其中包括 InfoNCE 损失和困难负样本挖掘
• 它力求让同一套嵌入系统同时承担检索与排序
• 目标是改善跨模态搜索，例如将照片与商品页面匹配，或匹配视频片段
• 论文展示了跨模态检索方面的提升；相关共享空间研究所引用的一项结果显示，NDCG@10 最多可提高 26 个百分点
• 局限也依然明显：细粒度不匹配、视频时间窗口仅为 3 到 25 秒，以及不同信号无法对齐时的排序错误

换句话说，它的重点并不是再增加一个模型，而是消除不同媒体类型之间相互割裂的流水线。对于从事搜索、信息流或购物发现的团队，这可能意味着_一个索引_、更简单的系统流程，以及更少的检索与排序不一致。

我的结论很直接：共享嵌入可以让多模态搜索更易于运行，但对齐质量仍决定着结果是否真正符合直觉。

Qwen3-VL-Embedding 与 Qwen3-VL-Reranker：面向最先进多模态检索的统一框架

UniNote 的工作原理：架构、训练与检索—排序设计

跨模态的统一笔记表示

UniNote 首先使用 ASR、OCR 和 VLM 将音频、图像与视频转换为统一的笔记格式，再把这些信号映射到一个公共向量空间。每种模态都经过各自的编码器，可训练的投影层则将这些输出送入同一个高维空间。最终，无论一篇笔记包含哪些信号，都会为它生成一个嵌入。

这种设置让小红书能用一条流水线搜索文本、图像、视频和音频。系统不再把每种格式视为彼此孤立的信息孤岛，而是将它们放在同一张地图上。

当然，前提是模型能够学会不同格式之间的强对齐关系。

两阶段训练与困难负样本挖掘

UniNote 采用两阶段方法。

第一阶段使用带有 InfoNCE 损失的对比学习。这样能教会模型把相互匹配的内容拉近，即使这些内容以不同格式呈现也是如此。

第二阶段通过相关性感知优化和困难负样本挖掘来提升排序质量。困难负样本是指在上下文中看似接近、语义上却并不正确的条目。这一点非常重要。如果模型能区分近似但错误的结果与真正匹配的结果，排序就会更加准确。

UniNote 还使用可变长度嵌入。这意味着，当任务不需要完整精度时，可以缩短嵌入。直白地说，系统可以牺牲少量细节，换取更低的存储占用和更快的检索速度。

随后，同一个嵌入便可同时处理候选检索和最终排序。

为什么用一个模型同时完成检索与排序能简化系统设计

许多推荐系统用一个模型做检索，再用另一个模型做排序。理论上听起来很工整，实践中却可能造成两个阶段之间的偏移：一个模型学会一种相关性定义，另一个模型学会的定义又略有不同。

UniNote 避免了这种割裂。它让检索和排序共用一套嵌入框架，使两个阶段保持对齐。正是这种共享设置，让检索与排序在生产环境中的行为更加一致。

接下来的问题是，这种设计在真实检索任务中的表现究竟如何。

研究结果：任务、表现与当前局限

条目到条目检索任务与基准范围

UniNote 在_条目到条目检索_任务上进行了测试。简单来说，就是让模型在同一个共享嵌入空间中，匹配不同格式下相同或相关的内容。

核心测试非常简单：一个嵌入能否跨格式连接内容，而不让检索经过彼此独立的流水线？这一点比乍看之下更重要。同一个嵌入必须身兼两职：既支持检索和排序，又要保持不同模态之间的语义不变。

跨模态检索的性能提升

在检索基准中，UniNote 测试的是：一个共享空间能否在不依赖各模态独立流水线的情况下，提高匹配质量。GR-CLIP 会在共享嵌入空间中重新定位聚类中心，与标准 CLIP 相比，它让 NDCG@10 最多提高了 26 个百分点^[1]。

这绝不是微小增幅。在检索系统中，即使排序指标只出现温和变化，也可能明显改变下游推荐结果。

但天下没有免费的午餐，这些提升也伴随着取舍。

统一嵌入仍存在哪些不足

当不同模态无法清晰对齐时，统一嵌入仍会遇到麻烦。此时，系统可能排错结果，或产生某种类似幻觉的错误。模型在细粒度内容上的表现也可能下降，尤其是视觉信号与文本信号方向不一致时。

视频是另一个难点。许多系统仍然只能处理 3 到 25 秒的时间上下文，这会严格限制它们能够利用多少序列层面的语义。

在需要大规模处理混合格式内容、变化迅速的搜索和推荐系统中，这个问题会更加突出。

在搜索、推荐和多模态 AI 工作流中的实际用途

只有当这些检索提升能让生产环境中的搜索与推荐更容易运行时，它们才真正有意义。

面向社交电商与媒体的跨模态搜索和推荐

UniNote 式嵌入的主要用例是商品发现和内容匹配。借助统一嵌入系统，同一个查询可以把购物者上传的照片与商品列表、创作者测评或短视频相匹配，而团队无需为每种格式分别构建流水线。

这对社交电商和媒体非常重要。用户可能上传截图、粘贴文案，也可能用商品名称搜索。如果所有这些输入都位于同一个嵌入空间，系统就更有可能返回横跨文本、图像和视频的相关条目。

它也有助于推荐。相关帖子、文案和视频片段会保持足够接近，从而支持更紧密的内容聚类与更好的信息流推荐。从运维角度看，团队还能维护一个索引而非多个索引，减少大量额外的活动部件。

多模态索引、延迟与基础设施考量

改用统一嵌入模型会直接改变索引方式。团队无需分别运行文本、图像和视频向量库，而是可以将它们整合到单个近似最近邻（ANN）索引中。这样既简化了查询路由，也降低了运维开销。

视频又增加了一层复杂性。团队需要通过预处理保留时序信号，同时不能拖慢检索。实践中，这通常意味着：

• 对帧进行采样
• 通过同一条多模态流水线编码视频片段
• 保持足以用于生产环境的检索速度

这种设置也能降低模型集成开销。你无需为文本连接一条路径、为图像连接另一条路径，再为视频连接第三条路径。流水线变得更简单，往往也意味着日后的维护烦恼更少。

APIMart 如何融入统一多模态工作流

APIMart 通过一个兼容 OpenAI 的端点（api.apimart.ai/v1）提供文本、图像和视频模型。这能降低协议、认证和速率限制方面的开销。

对于构建多模态工作流的团队来说，这意味着同一个集成层就能处理不同类型的模型，无需每次重写底层连接逻辑。工程工作可以聚焦于嵌入逻辑和业务逻辑，而非 API 管理。

面向开发者与 AI 团队的关键要点

从 UniNote 中应当理解什么

了解检索和基础设施细节后，主要结论落在运营层面：UniNote 使用一个语义空间处理多模态搜索和排序。这一点很重要，因为彼此独立的流水线往往会在规模扩大后产生不一致的结果。

简单来说，不同模态之间的交接更少，排序不匹配也更少。对于开发者而言，这意味着跨模态搜索中的活动部件更少。当同一个嵌入同时负责检索和排序，而无需为每种格式拼接彼此独立的模型时，把商品图片与描述匹配、将短视频与文案关联，以及为社交电商运行多模态搜索都会变得更简单。

实际做法很直接：围绕一个共享语义空间构建索引、检索和推荐，这样接入新模态时就不必重建流水线。一个索引、一套排序逻辑、更少的集成点。

常见问题

如何从混合媒体中构建一个嵌入？

UniNote 和类似系统会将文本、图像、视频与音频映射到一个共享语义向量空间，从而创建单一嵌入。

它们通常依靠基于 Transformer 的模型，将每种输入类型转换为一种统一表示。此后，它们使用跨模态注意力与投影层，让同一个概念在不同格式间对齐。这样一来，系统就能衡量不同媒体类型之间的语义相似度。

为什么检索和排序要使用同一个嵌入？

检索和排序使用同一个嵌入，可以让一切都处于同一个共享语义空间中。这一点比乍看之下更加重要。

当文本、图像和视频以相同方式映射时，就可以直接比较它们。文字查询可以与图像对齐，视频可以匹配文本描述，相关内容也能跨格式保持同步，而不会逐渐偏离。

这会改善跨模态搜索与检索，缩小模态鸿沟，并帮助推荐流水线保持稳定一致。

UniNote 目前最大的局限是什么？

当 UniNote 尝试把文本、图像、视频和音频放进同一个共享语义空间时，就会遇到最大的局限。理论上听起来很简洁，但实践中这些模态不会自行对齐，因此训练会更加困难，学到的表示也可能较弱。

联合训练期间还有另一个问题：模态懒惰或冲突。简单来说，模型可能过度依赖最容易处理的输入，而减少对其他输入的关注。这会导致某些模态训练不足。当真实数据不完整（例如缺少音频）时，问题还会进一步恶化。模型的总体表现可能下降，或者过分依赖恰好最强的那种模态。