EmbeddingGemma 2: Validating Vector Truncation

黎 浩然/ 16 10 月, 2026/ 大语言模型/LARGELANGUAGEMODEL/LLM, 教程/TUTORIAL, 机器学习/MACHINELEARNING/ 0 comments

EmbeddingGemma 2 supports truncating its 768-dimensional output to 512, 256, or 128 dimensions. That does not mean slicing vectors is enough to reuse an existing index. Re-normalize, align query and corpus processing, and evaluate the target retrieval task. Coordinate storage scales with dimension; retrieval quality does not follow the same simple ratio.

Contents
  1. The roundup date is not the model launch date
  2. Truncation support comes from training
  3. Calculate coordinate storage explicitly
  4. Do not credit dimension for a precision change
  5. A normalized vector does not stay normalized after slicing
  6. Retain the conditions behind model-card guidance
  7. Define the indexing contract before migration
  8. Separate representation changes from index approximation
  9. On-device embeddings do not make the whole app offline
  10. Choose a dimension from task evidence
  11. Sources and verification scope

A three-dimensional counterexample explains the ranking issue, followed by storage arithmetic for one million vectors. 阅读中文版.

The roundup date is not the model launch date

Google News indexed the Google Open Source roundup dated October 15, 2026, which highlights EmbeddingGemma 2. The original launch announcement is dated October 6. This is an engineering reading of a recent model highlighted in the roundup, not a claim that the model launched with that roundup.

The announcement describes mapping text, images, audio, and video into a shared representation. For local-search developers, the interesting decision is how far that representation can be shortened under a resource budget. Multimodal support alone does not establish reliable results for every application.

Truncation support comes from training

The official model card lists native 768-dimensional output and MRL options at 512, 256, and 128 dimensions, with normalization after truncation. Such training aims to make prefixes useful. It is not a mathematical guarantee that arbitrary embeddings can safely lose their final coordinates.

Output dimension and model weights are different budgets. Reducing a vector from 768 to 128 dimensions mainly reduces costs associated with storing and processing those coordinates. It does not reduce the encoder’s parameters sixfold. Device inference memory also depends on loaded encoders, precision, and runtime overhead.

1
Fix model and input format
2
Keep a supported prefix length
3
Normalize the retained vector
4
Match corpus and query contracts
Original processing order: truncation changes length and direction; corpus and queries must follow the same contract.

Calculate coordinate storage explicitly

For N dense vectors of dimension d using b bytes per coordinate, coordinate storage is N×d×b. One million float32 vectors use 3,072,000,000 bytes at 768 dimensions and 512,000,000 bytes at 128 dimensions: an exact six-to-one ratio.

These are arithmetic byte counts, not measured database footprints. Index structures, metadata, text, replicas, reserved capacity, and allocation overhead add storage. Query-time memory can include other structures too. Coordinate bytes are therefore not the peak memory requirement of the application.

768d

3072000000 bytes

512d

2048000000 bytes

256d

1024000000 bytes

128d

512000000 bytes

Original storage chart: coordinate bytes for one million float32 vectors, relative to 768d; index and metadata excluded.

Do not credit dimension for a precision change

One million 256-dimensional float16 vectors also contain 512,000,000 coordinate bytes, matching 128-dimensional float32 storage. Relative to 768-dimensional float32, the sixfold reduction combines threefold dimensional reduction with half the coordinate byte width. Changing both at once prevents attributing quality or speed differences entirely to truncation.

First hold storage precision fixed while comparing dimensions, then hold dimension fixed while comparing precision. Verify the database’s actual storage format. Model inference precision, output array type, and internal index compression can be three different settings. Labeling a file float16 does not establish that the serving path avoids conversion to another format; measure the representation actually used.

A normalized vector does not stay normalized after slicing

A unit-length full vector generally has a shorter norm after retaining only its prefix. If an index uses inner product as a cosine proxy, retained norm differences can affect ranking. Establish whether the database uses inner product, cosine, or another distance, and which component owns normalization.

Take q=(1,0,0), A=(0.6,0,0.8), and B=(0.8,0.6,0). All full vectors have unit norm. Their full dot products rank B at 0.8 above A at 0.6. After keeping two dimensions, A has norm 0.6 while B still has norm one. Re-normalizing turns A into (1,0), now ranking above B.

This shows two distinctions: raw prefix inner product can differ from prefix cosine, and correctly normalized prefix rankings can differ from full-space rankings. The vectors are constructed geometry, not EmbeddingGemma 2 outputs or a measurement of that model’s degradation.

# Constructed vectors: this does not run EmbeddingGemma 2.
import math

def prefix_unit(v, dim):
    if not isinstance(dim,int) or isinstance(dim,bool) or not 0 < dim <= len(v):
        raise ValueError("invalid prefix dimension")
    part = v[:dim]
    length = math.sqrt(sum(x*x for x in part))
    if length == 0 or not math.isfinite(length):
        raise ValueError("retained vector cannot be normalized")
    return [x/length for x in part]

def dot(a,b):
    if len(a)!=len(b):
        raise ValueError("dimension mismatch")
    return sum(x*y for x,y in zip(a,b))

q, a, b = [1.,0.,0.], [0.6,0.,0.8], [0.8,0.6,0.]
assert dot(q,a) < dot(q,b)  # Full vectors: B ranks above A.
raw_a,raw_b = dot(q[:2],a[:2]),dot(q[:2],b[:2])
assert raw_a < raw_b
q2,a2,b2 = [prefix_unit(v,2) for v in [q,a,b]]
assert dot(q2,a2) > dot(q2,b2)  # Retained-space cosine: A above B.
assert math.isclose(dot(a2,a2),1.)
for bad,dim in [([0.,0.,1.],2),([1.],0),([1.],2)]:
    try:
        prefix_unit(bad,dim)
    except ValueError:
        pass
    else:
        raise AssertionError("invalid normalization accepted")
assert 1_000_000*768*4 == 3_072_000_000
assert (1_000_000*768*4)//(1_000_000*128*4) == 6
print("full: B>A; normalized prefix: A>B; invalid inputs rejected")

The code was executed locally for ranking reversal, norm, zero prefixes, invalid dimensions, and storage arithmetic. No model was downloaded or run, and retrieval quality was not measured. Two dimensions make the geometry visible; actual use should follow supported model-card dimensions.

Retain the conditions behind model-card guidance

The card reports dimension-specific evaluations and recommends 128 dimensions primarily for text workloads. That is not equivalent to lossless 128-dimensional retrieval across every modality. Vendor evaluations have particular datasets, metrics, and precision conditions; a target corpus still needs its own checks.

Documents, code fragments, screenshots, and audio can require different relevance labels. A multimodal application should inspect each relevant modality and cross-modal query type rather than choose a global setting from text-only examples. Reprinting vendor score tables would not replace an application acceptance exercise.

Define the indexing contract before migration

Model version, chunking, input format, and task prefixes affect representation alongside dimension and normalization. The official card provides task-specific query and document formatting. Changing database dimensions while also changing input processing prevents attributing observed differences to dimension alone.

Keep a non-sensitive configuration record with model version, output dimension, normalization order, distance metric, corpus version, and input format. Query and indexing components should check the same contract. Reject mismatches explicitly instead of accepting a runnable request whose ranking has no clear interpretation.

Migrating a 768-dimensional index to 256 dimensions generally needs data and an index matching the new contract. Deriving it from stored original vectors is only appropriate when those vectors and processing rules are verifiable. Equal dimensions do not make vectors from different models or processing versions interchangeable.

Separate representation changes from index approximation

On a fixed small corpus, first compare 768, 512, 256, and 128 dimensions using exact retrieval while keeping other processing unchanged. This isolates representation changes. Then fix a dimension and compare an approximate index with its exact reference to investigate a second source of error.

Use relevance-labeled queries, record whether relevant documents appear in the top k, and inspect failures. The site’s RAG recall denominator article explains counting scope. Repeated chunks from one document should not hide the absence of a critical document by appearing as several independent correct results.

Retain query groups and sample counts so many easy text queries do not conceal degraded code retrieval. If the application sometimes should return nothing, top-k alone still supplies candidates; separately validate thresholds or abstention. The objective is a smaller system that still performs its task, not just a smaller storage screenshot.

A migration can begin with a parallel test index evaluated on the same queries before switching. Retaining the previous contract and corpus version gives a useful rollback and diagnostic reference if a query group regresses. This is deployment guidance; no real index was migrated for this article.

On-device embeddings do not make the whole app offline

Generating embeddings locally reduces the need to upload source input. Whether the full application stays offline also depends on model downloads, logs, telemetry, remote indexes, and generative-model calls. A model’s local capability does not automatically establish application-wide privacy.

Plan offline retrieval with non-sensitive examples first, then inspect where inputs, vectors, retrieved passages, and logs are stored or transmitted. No dataset or tracking service was connected for this article, and no private material was used in the examples.

Choose a dimension from task evidence

Find the smallest candidate dimension meeting quality needs on representative tasks, then measure index footprint, query latency, and update cost on the actual device. If 128 dimensions works only for some tasks, design around that distinction rather than accepting quality loss merely to keep one setting everywhere.

EmbeddingGemma 2 supplies a choice of representation budgets. An application still needs evidence for the selected budget. If the normalization example and migration checks save you an indexing detour, voluntary support through the section below is welcome.

Sources and verification scope

The October 15 Google Open Source roundup, October 6 launch announcement, and official model card. The Google News roundup item is timestamped October 15 at 18:32:19 UTC, before this slot. Both diagrams and code are original teaching content. Storage values are calculated, not measured device or model results.

Support

If the explanations or examples helped you solve a problem or save time, you’re welcome to support this site with a voluntary tip.

WeChat support QR code; click to enlarge
WeChat
Alipay support QR code; click to enlarge
Alipay
Buy Me a Coffee; support this site
Buy Me a Coffee

Click a QR code to enlarge. More options: support page。

Share this Post

Leave a Comment

您的邮箱地址不会被公开。 必填项已用 * 标注

*
*