---
title: "EmbeddingGemma 2 zoekt beeld en audio"
date: 2026-10-06
author: "Redactie WatisAI"
featured_image: "https://watisai.nl/wp-content/uploads/2026/10/embeddinggemma-2-lokaal-zoeken.jpg"
categories:
  - name: "Uncategorized"
    url: "/category/uncategorized.md"
---

# EmbeddingGemma 2 zoekt beeld en audio

![Drie mensen zoeken met een laptop in tekst, beelden en audio; redactionele illustratie](https://watisai.nl/wp-content/uploads/2026/10/embeddinggemma-2-lokaal-zoeken.jpg)Redactionele illustratie; geen opname van een producttest.Je weet dat ergens tussen je foto’s, notities en geluidsopnamen dat ene gesprek staat. Zoeken op de bestandsnaam helpt niet. Met EmbeddingGemma 2 wil Google zulke bestanden ook op hun inhoud vindbaar maken, op je eigen apparaat.

Google DeepMind bracht het model op [6 oktober 2026](https://blog.google/innovation-and-ai/technology/developers-tools/embeddinggemma-2/) uit. Het zet tekst, code, beeld, video en audio om in vergelijkbare getallenreeksen. Daarmee kun je passende bestanden zoeken. Het schrijft zelf geen antwoord zoals een chatbot dat doet.

## EmbeddingGemma 2 is een zoekmodel

Een embedding is een reeks getallen die inhoud vertegenwoordigt. Een zoekvraag en een document krijgen zo allebei een plek in dezelfde rekenruimte. De zoeksoftware vergelijkt die plekken en geeft vermoedelijk relevante bestanden terug. Een overeenkomst is nog geen bewijs dat een gevonden passage je vraag juist beantwoordt.

Dat onderscheid past bij onze uitleg van [wat is AI](https://watisai.nl/): de taak bepaalt wat een model moet kunnen. Een lokaal zoekmodel is iets anders dan een model dat teksten genereert, zoals in ons bericht over [Meta’s lokale model](https://watisai.nl/meta-muse-glimmer-open-model).

Modelgegevens volgens de Google-modelkaartOnderdeelOpgegeven eigenschapVolledig model740 miljoen parametersAlleen tekst270 miljoen parameters; beeld en audio zijn afzonderlijk te ladenUitvoervector768, 512, 256 of 128 getallenLicentieApache 2.0## Kleinere vectoren schelen ruimte, geen denkwerk

De [modelkaart](https://ai.google.dev/gemma/docs/embeddinggemma/model_card_2) laat toe de vectoren in te korten. Voor één miljoen bestanden, één vector per bestand en twee bytes per getal, is de kale opslag bij 768 dimensies: 1.000.000 × 768 × 2 = 1.536.000.000 bytes, ongeveer 1,54 GB.

Bij 128 dimensies wordt dat 256.000.000 bytes, ongeveer 0,26 GB. Dat is zesmaal minder vectoropslag. De bestanden zelf, zoekindex, metadata en werkgeheugen zitten niet in deze rekensom. Een opname die je in veel fragmenten opsplitst, levert bovendien meer dan één vector op.

Ook kwaliteit kost ruimte. Googles eigen meertalige MTEB-score daalt van 61,36 bij 768 dimensies naar 57,89 bij 128. De maker adviseert 128 vooral voor tekst. De codescore stijgt tegenover de voorganger van 68,76 naar 78,68: 9,92 punten op die benchmark, geen bewijs dat iedere eigen zoekvraag beter wordt gevonden.

De aangekondigde circa 191 MB voor tekstgewichten en 567 MB voor het volledige gekwantiseerde model zijn metingen op een Pixel 11 Pro. Het zijn geen totale geheugeneisen voor jouw app. Ook bij het [27B-model in 5,9 GB](https://watisai.nl/27b-ai-model-5-9-gb) telt het verschil tussen gewichten en de volledige uitvoering.

## Lokaal zoeken is pas privé als de hele route lokaal blijft

Wij vinden de afzonderlijk laadbare onderdelen nuttiger dan de claim dat één model alles kan. Wie alleen tekst zoekt, hoeft niet ook beeld en audio te laden. Dat maakt een gerichte proef overzichtelijker.

Maar ons enthousiasme voor lokaal draaien heeft een zwakke plek. Een lokale zoekstap kan gevonden passages vervolgens naar een cloudchatbot sturen. Telemetrie, synchronisatie en de opslag van de index blijven eveneens onderdeel van je gegevensroute. ‘Lokaal model’ is geen privacygarantie voor de hele toepassing.

De [licentie en open gewichten](https://watisai.nl/open-source-vs-gesloten-ai) beantwoorden ook een andere vraag dan privacy. En zoals bij [Computer History](https://watisai.nl/chatgpt-computer-history) telt welke informatie je werkelijk laat verzamelen. De AP beschrijft waarom [AI met persoonsgegevens](https://www.autoriteitpersoonsgegevens.nl/en/themes/algorithms-ai/algorithms-ai-and-the-gdpr) om een afzonderlijke beoordeling vraagt.

## Begin met tien zoekvragen waarvan je het antwoord al kent

1. Kies een kleine map met niet-gevoelige testbestanden.
2. Noteer tien echte zoekvragen en wijs vooraf het juiste bestand aan.
3. Vergelijk dezelfde vragen met 768 en 256 dimensies. Tel hoe vaak het bedoelde bestand bij de eerste resultaten staat.
4. Noteer ook zoektijd, geheugen en welke gegevens het apparaat verlaten.

Dit is een voorgestelde proef, geen testuitslag van ons. Terugvinden en antwoorden aanvullen is al langer een onderzoeksrichting; de [REALM-publicatie uit 2020](https://arxiv.org/abs/2002.08909) beschreef documentretrieval voor vraagbeantwoording. De nieuwe vraag is hoeveel verschillende bestanden nu bruikbaar op een klein apparaat kunnen worden doorzocht.

De volgende onafhankelijke praktijktests moeten laten zien hoeveel zoekkwaliteit overblijft na inkorten en op gewone hardware. Tot die tijd zijn de modelkaart en een eigen, herkenbare set zoekvragen bruikbaarder dan het etiket ‘best in class’.