谷歌EG 2模型+Milvus实测：最适合低成本本地部署的多模态embedding模型来了

EG2核心特性：小模型覆盖四模态与灵活资源调度

传统多模态检索往往需维护多套embedding模型：文本用一套，图片用一套视觉模型，音频再单独接一条链路。想实现用文字搜图片或用声音搜素材，还需组合不同模型，再将各路检索结果合并排序。

Google最近开源的EmbeddingGemma 2（以下简称EG2）提供了一个更便捷的方案：740M参数，可以把文本、图片、视频和音频编码到同一个向量空间。

相比此前已有的统一多模态模型如ImageBind，EG2最大的特点在于它的模型规模和资源配置：完整模型只有740M参数，编码器可以按模态加载，默认的768维向量还可以裁剪到256维甚至128维。

EG2采用Apache 2.0协议，默认输出768维向量。它可以单独编码文本、图片、视频和音频，也可以接收交错包含多种模态的输入，生成一条统一的embedding。例如，一张狗的照片、一段狗叫音频，以及“一只狗正在叫”的文字描述，都可以分别转换为向量，并在同一个空间内计算相似度。

在Milvus中，这些数据可以共用一个collection和一个FLOAT_VECTOR字段，再通过modality字段区分数据类型。

按需加载编码器

EG2的视觉和音频编码器可以按需加载，对应的模型规模如下：

此外，还可以素材入库时使用完整的多模态模型，面向文字搜索的线上查询服务则可以只加载270M的文本部分。270M配置相比完整740M模型，参数数量减少约63.5%。

向量维度可裁剪

EG2支持Matryoshka Representation Learning（MRL），可以使用768、512、256或128维向量。向量维度越低，每条数据的存储量越小。对于拥有数百万甚至数千万条素材的数据库，维度变化会直接影响向量存储规模。

Google官方模型卡给出了不同维度的表现：

256维的综合得分与768维相对接近，128维的多模态指标则出现了更明显的下降。因此，本轮实验重点比较768维和256维，观察实际检索任务中的精度与存储取舍。

实验设计：三类模型对照与多模态评测方法

为了评价EG2在小模型规模下的竞争力，我们选取了三款模型作为对照。

EG2的对手有两类。第一类是Nomic和qwen3.7-text-embedding-flash这样的文本模型。它们适合文本到文本的检索，但不能直接接收图片或音频。

第二类是Qwen3-VL-Embedding这样的多模态模型。它可以处理文本和图片，图文效果更强，但本轮使用的接口不接收音频。

其中，Qwen3-VL-Embedding-2B的模型规模约为EG2的2.7倍，也支持多模态统一表示。通过这组对比，可以观察EG2在更小体量下的文本和图文检索表现。

本轮使用Flickr8k和ESC-50的部分数据进行测试。

实验环境使用Milvus 2.6.23、FLAT索引和COSINE距离。每个模型使用独立collection，按照对应的向量维度建立字段。图文任务采用精确配对关系计算Recall@K，音频任务采用类别关系计算Hit@K。

例如，图文任务要求模型找到与查询对应的图片；音频任务中，查询“狗叫”，前K个结果只要包含属于狗叫类别的音频，即视为命中。这些样本主要用于观察模型在具体检索任务中的表现和工程取舍。

EG2 + Milvus 实战接入教程

先看EG2如何接入Milvus。本次使用本地Ollama调用embeddinggemma-2:740m，通过PyMilvus连接Milvus 2.6.23。

接入演示中，文本、图片和音频都放进同一个collection。每条数据保存模态、素材标识和向量。

schema = MilvusClient.create_schema(auto_id=True)
schema.add_field(
    field_name="id",
    datatype=DataType.INT64,
    is_primary=True,
)
schema.add_field(
    field_name="modality",
    datatype=DataType.VARCHAR,
    max_length=16,
)
schema.add_field(
    field_name="ref",
    datatype=DataType.VARCHAR,
    max_length=256,
)
schema.add_field(
    field_name="vector",
    datatype=DataType.FLOAT_VECTOR,
    dim=768,
)

三种模态共用vector字段：

rows = [
    {
        "modality": "text",
        "ref": "dog",
        "vector": embed("一只狗在叫"),
    },
    {
        "modality": "image",
        "ref": "dog",
        "vector": embed({
            "image": image_base64,
        }),
    },
    {
        "modality": "audio",
        "ref": "dog",
        "vector": embed({
            "audio": audio_base64,
        }),
    },
]

用文字搜图片时，加上模态过滤：

hits = client.search(
    collection_name="eg2_mm",
    data=[embed("狗叫")],
    filter='modality == "image"',
    limit=5,
    output_fields=["ref", "modality"],
    consistency_level="Strong",
)

需要搜索音频时，将过滤条件改为：

filter='modality == "audio"'

去掉modality过滤条件，就可以让文本、图片和音频一起参与搜索和排序。这意味着，应用可以用同一个collection支持多种搜索方式。用户可以输入文字，再根据需要获取图片、声音或混合结果。

将向量裁剪到256维

EG2支持MRL，因此可以直接截取768维向量的前256维，再做L2归一化。

import numpy as np

def truncate_256(vector):
    v = np.asarray(
        vector,
        dtype=np.float32,
    )[:256]
    norm = np.linalg.norm(v)
    if norm == 0:
        raise ValueError("Zero-length vector")
    return (v / norm).tolist()

调用方式：

full_vector = embed("一只狗在叫")
vector_256 = truncate_256(full_vector)

在Milvus中使用256维向量时，需要创建维度为dim=256的目标向量字段，并确保查询与入库向量使用相同维度。如果已经保存了完整的768维向量，可以直接进行截取和归一化，无需重新编码原始素材。

至此，文本、图片和音频的统一入库、跨模态检索，以及向量裁剪都可以在Milvus中实现。

横向评测结果：精度、模态覆盖与存储效率权衡

文本检索：EG2高于两款文本基线

我们使用Flickr8k图片描述的改写与配对关系，测试模型能否通过一条描述找到对应文本。最终EG2高于Nomic和qwen3.7-text-embedding-flash，略低于Qwen-VL。

也就是说，EG2在覆盖视觉和音频能力的同时，仍然保持了良好的短文本语义匹配效果。不过，这组任务主要使用Flickr8k的caption，文本较短，语义相对具体。对于代码搜索、长文档RAG等任务，还需要使用对应的数据集判断模型效果。

图文检索：EG2距离Qwen-VL仍有一段距离

两项图文任务中，EG2都略低于Qwen-VL，但差距不大。但两者的模型规模存在明显差异：

• EG2完整模型：740M参数
• Qwen3-VL-Embedding-2B：约2B参数

EG2的参数量约为Qwen-VL的37%，却在本轮图文任务中取得了相对接近的检索成绩。

音频检索：链路可行但排序稳定性待优化

音频部分只测试EG2。因为云端两款对照模型本轮接口不接收音频，无法做同条件比较。

这里使用Hit@K，表示前K个结果中是否至少命中一个同类别样本。结果来说，音频链路可以跑通，但排序不稳定。此前的接入演示中，中文查询“狗叫”时，猫叫音频以0.860排在第一，狗叫音频为0.853；换成英文a dog barking后，狗叫才回到第一。

这组结果说明，EG2能够直接建立文字与声音的语义关联，但实际排序质量会受到查询表达和模型语义对齐能力的影响。另外，本轮演示使用的是原始文本查询，没有加入Google推荐的检索任务前缀。任务前缀也是后续优化音频检索效果时值得考虑的因素。

768维和256维对比：存储减66.7%，精度损失可控

EG2支持MRL截维。本次直接截取768维向量的前256维，再做L2归一化，没有重新调用模型。

float32下，768维向量需要3,072字节，256维向量需要1,024字节，原始向量存储减少66.7%。

按一百万条向量计算，原始向量数据大约从3.072GB降到1.024GB（这个数字不包含Milvus索引、标量字段、副本和其他运行开销），而这组数据上的Recall@1下降不到2个百分点。

从官方数据看，EG2的MMEB v2总分在768维时为59.01，256维时为56.24，下降2.77分。更低的128维则降至45.65。因此，实际落地中，256维是一个值得关注的折中配置。

适用场景总结

如果只做文本检索，纯文本模型会更直接；如果只追求图文排序的最高分，Qwen-VL在本轮测试中更高。EG2更适合需要本地运行、同时处理多种模态，或者对向量存储容量敏感的场景。