Computer vision voor e-commerce — visual search implementeren

Computer vision voor e-commerce — visual search implementeren

62% van de consumenten wil visueel zoeken als dat beschikbaar is. Toch biedt minder dan 10% van de webshops het aan. Dat gat is geen technisch probleem — het is een implementatieprobleem. Computer vision en visual search zijn in 2024 bereikbaar voor middelgrote webshops, zonder een team van ML-engineers in dienst te nemen.

Dit artikel legt uit hoe visual search werkt, welke use cases rendement opleveren, wat de integratiekosten zijn, en wanneer je er beter van weg kunt blijven. En ja — er is ook een scenario waarin je het beter niet kunt doen.

Wat is visual search — en wat niet

Visual search laat een gebruiker een foto uploaden en vergelijkbare producten vinden. Dat klinkt eenvoudig, maar er zijn meerdere lagen:

• Zoeken op foto (query-by-image): gebruiker laadt een afbeelding op, systeem retourneert visueel vergelijkbare producten.
• Auto-tagging: computer vision analyseert productfoto's en genereert automatisch attributen (kleur, patroon, snit, materiaal).
• Vergelijkbare producten (visual similarity): op een productpagina toon je "shop the look"-blokken op basis van visuele overeenkomst, niet op categorie-match.

Dit zijn drie aparte systemen die je apart — of gecombineerd — kunt inzetten. Begin nooit met alle drie tegelijk. Kies de use case met de hoogste businessimpact voor jouw catalogus en bouw van daaruit.

Hoe werkt het technisch

De kern is een embedding-model. Een convolutioneel neuraal netwerk (CNN) of een Vision Transformer (ViT) converteert elke productafbeelding naar een vector — een lijst van honderden tot duizenden floats die de visuele "betekenis" van een afbeelding vastleggen.

Twee afbeeldingen die op elkaar lijken, hebben vectors die dicht bij elkaar liggen in de vector space. Zoeken wordt daarmee een nearest-neighbour-probleem. Tekst-zoekopdrachten en visuele zoekopdrachten gebruiken hetzelfde principe — het verschil is dat de query nu een afbeelding is in plaats van een zoekreeks.

Vector search in de praktijk

Je hebt twee onderdelen nodig:

1. Embedding-pipeline: productfoto's omzetten naar vectors en opslaan.
2. Vector index: een database die approximate nearest neighbour (ANN) search kan uitvoeren.

Populaire opties voor de vector index zijn Pinecone, Weaviate, Qdrant en pgvector (PostgreSQL-extensie). Voor embedding-modellen werk je met CLIP (OpenAI, open source), Google Vision AI of AWS Rekognition.

Een minimale Laravel-integratie voor het indexeren van productafbeeldingen ziet er zo uit:

// app/Jobs/IndexProductEmbedding.php

class IndexProductEmbedding implements ShouldQueue
{
    public function __construct(private Product $product) {}

    public function handle(EmbeddingService $embedder, VectorIndex $index): void
    {
        $imageUrl = $this->product->getMainImageUrl();

        // Stuur afbeelding naar embedding API (bijv. CLIP via eigen endpoint of externe API)
        $vector = $embedder->fromImageUrl($imageUrl);

        // Sla vector op in Qdrant of Pinecone met product-ID als payload
        $index->upsert(
            id: $this->product->id,
            vector: $vector,
            payload: [
                'sku'        => $this->product->sku,
                'name'       => $this->product->name,
                'price'      => $this->product->price,
                'url'        => $this->product->url,
                'category'   => $this->product->category,
            ]
        );
    }
}

Bij een nieuwe of gewijzigde productfoto dispatch je deze job via een Magento webhook of een Laravel Observer. De zoekfunctie is dan een POST naar dezelfde vector index met de query-vector.

Use cases — welke lonen het meest

Niet elk assortiment profiteert even sterk van visual search. Wij zien bij klanten een duidelijk patroon.

De businesscase is het sterkst in fashion en interieur. Gebruikers weten wat ze willen maar kunnen het niet goed verwoorden. Een jurk of een lamp visueel zoeken converteert beter dan tien typfouten in een zoekbalk. In de praktijk zien we click-through rates op visueel vergelijkbare producten 2-3x hoger liggen dan op tekstgebaseerde "gerelateerde producten"-blokken — simpelweg omdat de visuele match relevanter is.

Auto-tagging: de onderschatte use case

Visual search voor gebruikers trekt de aandacht, maar auto-tagging levert vaak eerder ROI. Waarom? Omdat productdata in de meeste webshops inconsistent is.

Wij zien bij klanten dat 30-40% van de productattributen ontbreekt of incorrect is na een catalogus-import. Auto-tagging lost dat structureel op:

• Kleurdetectie: "navy blue" vs "dark blue" vs "donkerblauw" worden gestandaardiseerd.
• Patroonherkenning: gestreept, geblokt, egaal — automatisch als attribuut opgeslagen.
• Snit en silhouet: voor fashion herkennen modellen een A-lijn of slim-fit.

De output voedt je facet-navigatie en je reguliere tekstgebaseerde zoekindex. Betere attributen = betere filtrering = meer conversie. Dat meetje concreet in sessieduur en add-to-cart rate per gefilterde categorie.

Auto-tagging is ook een tijdsbesparing voor merchandisers. Een catalogus van 10.000 producten handmatig taggen kost weken werk. Met een auto-tagging pipeline doe je de bulk in uren, en laat je de merchandiser alleen afwijkingen corrigeren. De kwaliteit van vision-modellen op kleur, patroon en materiaalherkenning ligt in de praktijk boven 90% voor goed gelichtte productfoto's op een neutrale achtergrond.

Integratie-aanpak — stap voor stap

Stap 1: Kies je embedding-model

Voor de meeste webshops is CLIP (Contrastive Language-Image Pre-Training) het startpunt. Het model is open source, draait lokaal of via een API, en werkt goed zonder fine-tuning op fashion- en interieurcatalogi. OpenAI biedt CLIP-compatible endpoints aan, maar er zijn ook lichtere open source varianten zoals FAISS-compatibele modellen van Hugging Face die je zelf kunt hosten.

Wil je betere resultaten op een specifiek niche-assortiment, dan is fine-tuning op je eigen productafbeeldingen een optie. Reken op 2-4 weken extra werk en een gelabelde dataset van minimaal 5.000 afbeeldingen. Zonder voldoende gelabelde data levert fine-tuning zelden significant betere resultaten dan een generiek model.

Stap 2: Bouw de indexeer-pipeline

Bestaande catalogus: batch-job die alle productafbeeldingen verwerkt. Bij 50.000 producten met één afbeelding per product kost dit met een externe API doorgaans 2-6 uur en $10-50 aan API-kosten, afhankelijk van de provider.

Nieuwe producten: event-driven via een queue-job (zie het codevoorbeeld hierboven). Houd de pipeline asynchroon — blokkeer nooit de checkout of de catalogus-sync.

Stap 3: Kies je vector database

Voor een webshop tot 100.000 producten is pgvector een pragmatische keuze als je al Laravel + PostgreSQL draait. Je vermijdt een extra service en de zoeklatency is acceptabel (doorgaans onder 100ms bij een goed geïndexeerde tabel).

Stap 4: Bouw de zoek-UI

Drie patronen werken goed:

1. Camera-icoon in de zoekbalk: gebruiker uploadt foto, resultaten verschijnen als reguliere zoekresultaten.
2. "Vind vergelijkbare producten"-knop op de productpagina.
3. Shop the look-blok op categorie- en landingspagina's met visueel gerelateerde producten.

Begin met patroon 2 — het vereist geen UX-aanpassingen aan de zoekbalk en is in een Magento- of Shopify-thema in een dag te bouwen. Meet na twee weken de click-through op het blok. Pas als dat converteert, investeer je in de camera-integratie in de zoekbalk, wat meer frontend-werk vraagt.

Voor Magento integreer je dit als een custom UI component in het Hyva-thema. Voor Shopify is een custom Liquid sectie met een Alpine.js fetch naar je eigen API de snelste route. In beide gevallen leeft de vector search logic in een separate Laravel microservice of als een package in je bestaande backend.

Kosten — wat reken je in

Kosten bestaan uit vier componenten:

Een webshop met 20.000 producten, maandelijks 500 nieuwe SKUs en een self-hosted Qdrant-instance betaalt doorgaans minder dan €150/maand aan variabele kosten. De eenmalige ontwikkelinvestering is realistisch 40-80 uur, afhankelijk van de complexiteit van het platform en de kwaliteit van bestaande productdata.

Wanneer je het NIET moet doen

Visual search is geen goed idee als:

• Je catalogus minder dan 1.000 producten bevat. Tekstuele zoekresultaten zijn dan al overzichtelijk genoeg.
• Je productfoto's van slechte kwaliteit zijn. Garbage in, garbage out — embeddings van inconsistente, kleine of gecropte afbeeldingen leveren slechte resultaten.
• Je assortiment puur specificatie-gedreven is (onderdelen, elektronica met modelspecifieke zoekpatronen).
• Je nog geen werkende facet-navigatie hebt. Los dat eerst op — het levert meer conversie voor minder geld.

Wij zien bij klanten dat visuele zoekprojecten mislukken door één reden: de onderliggende catalogus is niet op orde. Inconsistente achtergronden, mixed foto-stijlen en ontbrekende productafbeeldingen maken de embeddings onbetrouwbaar. Investeer eerst in productdata-kwaliteit en een consistente fotografie-standaard. Daarna pas visual search.

Veelgestelde vragen

Werkt CLIP goed voor Nederlandse productnamen en -beschrijvingen?

CLIP is primair getraind op Engelstalige data, maar de visuele component is taalonafhankelijk. Voor query-by-image (gebruiker upload foto) maakt de taal niet uit. Voor multimodale zoekopdrachten waarbij tekst en afbeelding gecombineerd worden, presteert CLIP minder goed op Nederlandse tekst. Gebruik dan een apart taalmodel voor de tekstcomponent.

Hoe lang duurt het om een bestaande catalogus van 50.000 producten te indexeren?

Met een externe embedding API (bijv. Google Vision of OpenAI CLIP-compatible endpoint) en parallelle verwerking via Laravel queues reken je op 2-6 uur. Met een lokaal CLIP-model op een GPU-server gaat het sneller maar vergt meer setup. Stel de batch-job in met rate limiting om API-kosten te beheersen.

Heeft visual search invloed op mijn reguliere SEO?

Nee, niet direct. Visual search werkt client-side of via een interne API-aanroep en heeft geen effect op hoe zoekmachines je pagina's crawlen. Indirect kan betere auto-tagging wel de kwaliteit van productbeschrijvingen en alt-teksten verbeteren, wat wél SEO-voordeel geeft.

Voor welk platform is de integratie het makkelijkst?

In de praktijk is Laravel als backend de meest flexibele basis — je bouwt de vector search als een interne service en koppelt er elk frontend-platform aan. Voor Shopify Plus zijn er ook kant-en-klare apps (zoals Visenze of Syte) die je visuele zoekfunctionaliteit bieden zonder custom development, maar die vragen een maandelijks abonnement van doorgaans $500-2.000.

Wil je weten of visual search rendabel is voor jouw assortiment en platform? Neem contact op — we kijken concreet naar je catalogusgrootte, productdata-kwaliteit en het platform dat je gebruikt.