Beveiligingsvergelijking van embeddingmodellen
Beveiligingsvergelijking van toonaangevende embeddingmodellen — OpenAI, Cohere, sentence-transformers — met kwetsbaarheidsprofielen, adversarial robuustheid en privacykenmerken.
De keuze van het embeddingmodel beïnvloedt de beveiligingshouding van elk systeem dat op semantische gelijkenis steunt — RAG-pipelines, semantisch zoeken, contentmoderatie en aanbevelingssystemen. Verschillende embeddingmodellen hebben verschillende kwetsbaarheidsprofielen, en inzicht in die verschillen is essentieel voor zowel redteamers die deze systemen beoordelen als de engineers die ze bouwen.
Deze pagina vergelijkt de beveiligingskenmerken van de meest uitgerolde embeddingmodellen, over commerciële API's en open-sourceopties heen.
Het landschap van embeddingmodellen
Commerciële API-modellen
OpenAI Embeddings (text-embedding-3-small, text-embedding-3-large, text-embedding-ada-002) zijn de meest uitgerolde commerciële embeddingmodellen. Ze worden benaderd via de API van OpenAI, wat betekent dat de embedding-berekening op de infrastructuur van OpenAI plaatsvindt. De modellen zijn closed-source, zonder toegang tot de gewichten of architectuurdetails buiten wat OpenAI publiceert.
Cohere Embeddings (embed-english-v3.0, embed-multilingual-v3.0) bieden zowel Engelstalige als meertalige embedding-mogelijkheden via een API. De modellen van Cohere ondersteunen classificatie van het invoertype (search_document, search_query, classification, clustering), wat het embedding-gedrag beïnvloedt.
Google Embeddings (text-embedding-004 via Vertex AI) bieden embeddings via de API van Google Cloud. Deze modellen ondersteunen het specificeren van het taaktype, vergelijkbaar met de invoertypen van Cohere.
Amazon Titan Embeddings bieden embedding-mogelijkheden via AWS Bedrock, nauw geïntegreerd met de AWS-infrastructuur en -toegangscontroles.
Open-sourcemodellen
sentence-transformers is de populairste open-source embedding-bibliotheek en biedt toegang tot honderden voorgetrainde modellen. Populaire modellen zijn onder meer all-MiniLM-L6-v2, all-mpnet-base-v2 en instructor-large. Deze modellen kunnen zelf worden gehost, wat volledige controle over de embedding-pipeline geeft.
BAAI BGE-modellen (bge-small-en, bge-base-en, bge-large-en) zijn hoogpresterende open-sourcemodellen van de Beijing Academy of Artificial Intelligence.
E5-modellen van Microsoft Research presteren sterk op retrieval-taken en zijn in meerdere groottes beschikbaar.
Beveiligingsvergelijkingsmatrix
| Beveiligingseigenschap | OpenAI | Cohere | sentence-transformers | BGE/E5 |
|---|---|---|---|---|
| Adversarial robuustheid | Gemiddeld-hoog | Gemiddeld | Laag-gemiddeld | Laag-gemiddeld |
| Inversiebestendigheid | Hoog (API) | Hoog (API) | Laag (lokaal) | Laag (lokaal) |
| Dataprivacy | Afhankelijk van beleid | Afhankelijk van beleid | Volledige controle | Volledige controle |
| Supply chain-risico | Laag (beheerd) | Laag (beheerd) | Gemiddeld (zelf-gehost) | Gemiddeld (zelf-gehost) |
| Transparantie | Laag (closed) | Laag (closed) | Hoog (open) | Hoog (open) |
| Aanpasbaarheid | Beperkt | Beperkt | Volledig | Volledig |
Adversarial robuustheid
Adversarial robuustheid meet hoe makkelijk het is om invoer te maken die misleidende embeddings oplevert — invoer die semantisch verschilt van een target maar er dichtbij embedt, of invoer die semantisch lijkt maar ver weg embedt.
Commerciële API-modellen vertonen doorgaans een hogere adversarial robuustheid, omdat het grotere modellen zijn met meer capaciteit om semantische nuance te vatten. Ze zijn op meer diverse data getraind, wat de gevoeligheid voor distributiespecifieke aanvallen vermindert. Ze kunnen adversarial training of op robuustheid gerichte trainingsfasen bevatten. En ze worden regelmatig bijgewerkt, waarmee bekende adversarial zwaktes mogelijk worden aangepakt.
Open-sourcemodellen, vooral kleinere zoals MiniLM, zijn gevoeliger voor adversarial invoer, omdat hun kleinere capaciteit een sterkere compressie van de semantische ruimte afdwingt. Een aanvaller die het model lokaal kan downloaden en analyseren, kan via white-boxaanvallen efficiënter adversarial invoer maken.
Open-sourcemodellen hebben echter een transparantievoordeel: je kunt het gedrag van het model analyseren, de zwaktes identificeren en gerichte verdedigingen implementeren. Bij commerciële API's moet je het model als een black box behandelen en verdedigingen ontwerpen zonder inzicht in de specifieke faalmodi van het model.
Inversiebestendigheid
Embedding-inversie is het proces waarbij de oorspronkelijke tekst uit een embeddingvector wordt hersteld. Dit is een privacyzorg, omdat organisaties vaak embeddings van gevoelige documenten opslaan in de veronderstelling dat de embeddings de brontekst niet onthullen.
Commerciële API-modellen bieden een hogere inversiebestendigheid, omdat de modelgewichten niet beschikbaar zijn voor aanvallers. Een aanvaller kan alleen black-boxinversie uitvoeren door de API te bevragen en embeddings te matchen, wat aan rate limiting onderhevig en kostbaar is. De modellen zijn groot, waardoor de embedding-naar-tekstafbeelding complexer en moeilijker te inverteren is.
Open-sourcemodellen zijn kwetsbaarder voor inversie, omdat de modelgewichten beschikbaar zijn, wat white-boxinversietechnieken mogelijk maakt. Een aanvaller kan een inversiemodel trainen met het embeddingmodel als component. Kleinere modellen produceren embeddings met minder informatiecomplexiteit, waardoor inversie makkelijker wordt.
Dataprivacy
Privacyzorgen rond data verschillen aanzienlijk tussen API-gebaseerde en zelf-gehoste modellen.
Bij commerciële API-modellen wordt de brontekst voor het embedden naar de infrastructuur van de aanbieder verstuurd. Afhankelijk van het bewaar- en verwerkingsbeleid van de aanbieder kan deze tekst worden opgeslagen, gelogd of gebruikt voor modelverbetering. Voor organisaties met strenge eisen aan dataverwerking (zorg, financiën, overheid) kan dit onaanvaardbaar zijn.
Het beleid van OpenAI voor datagebruik is in de loop van de tijd geëvolueerd, en enterpriseklanten kunnen specifieke voorwaarden voor dataverwerking onderhandelen. Cohere en Google bieden vergelijkbare enterpriseovereenkomsten. Maar het fundamentele feit blijft: een API-gebaseerd embeddingmodel gebruiken betekent dat je je data naar een derde partij stuurt.
Zelf-gehoste open-sourcemodellen houden alle data op je eigen infrastructuur. Er is geen datablootstelling aan derden, geen afhankelijkheid van extern beleid voor dataverwerking en geen risico dat data zonder toestemming voor modeltraining wordt gebruikt.
Supply chain-risico
Commerciële API-modellen kennen een lager supply chain-risico, in de zin dat de aanbieder de modelgewichten, serving-infrastructuur en updates beheert. Je vertrouwt erop dat de aanbieder de integriteit en beveiliging van het model handhaaft.
Zelf-gehoste open-sourcemodellen brengen supply chain-risico's met zich mee die de organisatie zelf moet beheren. Modelgewichten die uit publieke repositories worden gedownload, kunnen zijn gemanipuleerd. Modelafhankelijkheden (PyTorch, transformers, tokenizers) kunnen kwetsbaarheden bevatten. Modelbestanden in pickle-formaat kunnen tijdens het laden willekeurige code uitvoeren. En modelupdates moeten door de organisatie worden beheerd.
Aanbiederspecifieke kwetsbaarheden
OpenAI Embeddings
Misbruik van dimensionaliteitsreductie: de text-embedding-3-modellen van OpenAI ondersteunen dimensionaliteitsreductie via de parameter dimensions. Embeddings met minder dimensies verliezen semantische nuance, wat adversarial aanvallen mogelijk makkelijker maakt. Organisaties die dimensies reduceren om kosten te besparen, kunnen onbedoeld de beveiligingseigenschappen van hun embeddingruimte verzwakken.
Blootstelling van API-sleutels: omdat embeddings API-aanroepen vereisen, moeten API-sleutels beschikbaar zijn voor elke dienst die embeddings genereert. Organisaties met complexe architecturen kunnen API-sleutels over veel diensten verspreid hebben, wat het blootstellingsrisico vergroot.
Rate limiting en kosten: OpenAI past rate limits toe op embedding-API-aanroepen. Een aanvaller die buitensporig veel embedding-operaties uitlokt (via een vloed aan documentuploads of query-amplificatie) kan rate limiting veroorzaken die de dienst verslechtert, of kostenamplificatie die de budgetten raakt.
Cohere Embeddings
Manipulatie van het invoertype: de invoertypeparameter van Cohere (search_document vs. search_query) beïnvloedt de embedding. Een aanvaller die de invoertypeparameter kan beheersen, kan documenten als queries laten embedden of andersom, wat de retrieval-nauwkeurigheid verstoort.
Risico's van het meertalige model: het meertalige model van Cohere embedt tekst uit verschillende talen in een gedeelde ruimte. Dit maakt cross-linguale aanvallen mogelijk, waarbij een injection-payload in de ene taal dicht bij een doel-query in een andere taal wordt geëmbed, waarmee taalspecifieke contentfilters mogelijk worden omzeild.
sentence-transformers
Modelverwisseling: omdat sentence-transformers-modellen op naam worden geladen vanuit HuggingFace of lokale opslag, kan een aanvaller die het modellaadpad of de lokale modelcache kan aanpassen, een kwaadaardig model in de plaats stellen. Het kwaadaardige model produceert voor de meeste invoer normaal ogende embeddings, maar gemanipuleerde embeddings voor specifieke invoer.
Tokenizer-kwetsbaarheden: sentence-transformers-modellen gebruiken tokenizers die kwetsbaar kunnen zijn voor adversarial invoer — speciaal geprepareerde strings die op onverwachte manieren tokeniseren en zo de embedding-uitvoer kunnen beïnvloeden.
Manipulatie van de pooling-strategie: sentence-transformers gebruikt pooling om representaties op tokenniveau om te zetten in één embeddingvector. Verschillende pooling-strategieën (mean, max, CLS) hebben verschillende beveiligingseigenschappen. Mean pooling is gevoeliger voor token-injection-aanvallen, waarbij het toevoegen van specifieke tokens de embedding verschuift. CLS pooling is gevoeliger voor prefix-aanvallen.
Beoordelingsmethodologie
Volg bij het beoordelen van een implementatie van een embeddingmodel deze methodologie.
Fase 1: identificatie van model en configuratie
Identificeer het specifieke embeddingmodel en de versie die in gebruik is. Documenteer de embeddingdimensie, de gelijkenismetriek (cosinus, dotproduct, euclidisch) en eventuele nabewerking die op embeddings wordt toegepast. Controleer op dimensionaliteitsreductie, normalisatie of kwantisatie.
Fase 2: testen van adversarial robuustheid
Maak adversarial invoer die is ontworpen om misleidende embeddings te produceren. Test semantische collision-aanvallen waarbij niet-gelijkende tekst dicht bij een target embedt. Test semantische repulsie-aanvallen waarbij gelijkende tekst ver van een target embedt. Test embedding-flooding waarbij veel gelijkende embeddings worden geïnjecteerd om de retrieval-resultaten te domineren.
Meet het slaagpercentage en de vereiste verstoringsmagnitude. Vergelijk de resultaten over verschillende modellen heen als het systeem meerdere modellen ondersteunt.
Fase 3: inversietesten
Als embeddings worden opgeslagen en mogelijk toegankelijk zijn, test dan de inversiebestendigheid. Gebruik black-boxinversietechnieken als je alleen API-toegang hebt. Gebruik white-boxinversietechnieken als de modelgewichten beschikbaar zijn. Beoordeel welke informatie kan worden hersteld en of dat een privacyrisico vormt.
Fase 4: infrastructuurbeoordeling
Beoordeel de infrastructuur rond het embeddingmodel. Controleer het beheer en de rotatie van API-sleutels. Verifieer de netwerkbeveiliging voor API-aanroepen. Beoordeel de beveiliging van de modelopslag en het laden voor zelf-gehoste modellen. Bekijk de toegangscontroles op embedding-databases.
Fase 5: integratiebeoordeling
Beoordeel hoe embeddings in het bredere systeem worden gebruikt. Controleer of gelijkenisscores van embeddings het enige retrieval-criterium zijn of dat aanvullende filtering wordt toegepast. Verifieer of het systeem valideert dat opgehaalde documenten passen bij het autorisatieniveau van de gebruiker. Test of de embedding-pipeline de veiligheidsgrenzen van de brondata behoudt.
Richtlijnen voor modelkeuze
Houd bij het kiezen van een embeddingmodel voor een beveiligingsgevoelige applicatie rekening met deze factoren.
Voor applicaties met strenge eisen aan dataprivacy verdienen zelf-gehoste open-sourcemodellen de voorkeur, ondanks hun lagere adversarial robuustheid. De privacyvoordelen van het op je eigen infrastructuur houden van data wegen in de meeste gevallen zwaarder dan de beveiligingsvoordelen van de robuustheid van commerciële modellen.
Voor applicaties waarbij adversarial robuustheid de belangrijkste zorg is (contentmoderatie, spamdetectie), bieden commerciële API-modellen een betere basisrobuustheid. Vul dit aan met verdedigingen op applicatieniveau (re-ranking, verificatie met een cross-encoder, menselijke beoordeling) voor beslissingen met hoge inzet.
Voor applicaties waarbij zowel privacy als robuustheid kritiek zijn, kun je overwegen om een groot open-sourcemodel (BGE-large, E5-large) zelf te hosten met aanvullende adversarial training op je domeinspecifieke data. Dit biedt zowel controle over de data als verbeterde robuustheid, ten koste van een hogere operationele complexiteit en rekenvereisten.
Geen enkel embeddingmodel is veilig by default. Het model is één component van een systeem, en de beveiliging van het systeem hangt af van hoe het model wordt geïntegreerd, geconfigureerd en verdedigd.