Lokale AI in de praktijk: duizenden afbeeldingen beschreven zonder externe AI dienst

Een enorme database van afbeeldingen zonder trefwoorden of organisatie. Zoeken in de collectie van dit illustratie archief lukte nauwelijks, en alles met de hand beschrijven zou weken kosten. Dus kwam de vraag die we steeds vaker horen: kan AI dat niet doen?

Dat kon. Na een halve dag bouwen had de collectie in enkele uren trefwoorden, beschrijvingen en de tekst die op de beelden staat. Het model draaide lokaal, op onze eigen hardware, en geen enkel beeld ging naar een externe AI-dienst.

Dit artikel hoort bij onze serie over lokale AI-modellen. Dat zijn open modellen die je zelf draait, in plaats van je gegevens naar een grote AI dienst zoals die van Anthropic of ChatGPT te sturen. We laten het zien aan de hand van echte (kleine) projecten: wat het oplevert, wat ervoor nodig is en waar de grenzen liggen.

Waar het om draaide

Het archief bewaart zijn collectie in ResourceSpace, een systeem voor het beheren van beeldbestanden. De beelden zijn het belangrijkste bezit van het archief, en ze zijn voor intern gebruik. Ze naar een grote AI-dienst in de cloud sturen, betekent elk bestand afgeven aan een derde partij, onder voorwaarden die het archief niet zelf bepaalt.

Dat was het uitgangspunt: wel AI, maar zonder dat er een beeld naar een externe AI-dienst gaat. Daarom draaide het model op onze eigen hardware, bij ons op locatie in Duitsland. De beelden gingen alleen van het archief naar ons en weer terug, net als bij het andere werk dat we al voor deze klant deden.

Eerst een concept

We begonnen met de vraag wat voor data we eigenlijk nodig hebben. Dat bleken drie dingen per beeld: trefwoorden, een korte beschrijving en alle tekst die op het beeld staat, zoals gedrukte bijschriften of handgeschreven notities. Alles moest direct in ResourceSpace terechtkomen, zodat er voor de gebruikers niets verandert aan hoe ze werken.

Voordat er iets werd weggeschreven, beoordeelden we 50 resultaten in een overzicht met miniaturen. Op hun aanwijzingen hebben we de instructies voor het model bijgesteld. Zo kwam bijvoorbeeld aan het licht dat namen van kunstenaars in de beschrijvingen belandden, iets wat geen automatische test had gevonden.

Daarna de bouw

De bouw zelf was een koppeling tussen het model en ResourceSpace. Die koppeling is aan de hand van de bestaande APIs gebouwd en koppelt de afbeeldingen met onze LLM. Het resultaat is een kleine, vaste route voor elk beeld:

1. Het beeld wordt opgehaald uit ResourceSpace.

2. Eerst leest het model alleen de tekst op het beeld, woord voor woord. Een model dat tegelijk leest en beschrijft, gaat wat het leest "verbeteren".

3. Daarna beschrijft het het beeld: een titel, een beschrijving en 8 tot 15 trefwoorden.

4. De trefwoorden worden afgestemd op de termen die het archief al gebruikt, zodat er niet steeds nieuwe varianten bijkomen.

5. Het resultaat gaat terug naar ResourceSpace, maar alleen in velden die leeg zijn of nog de eigen eerdere uitkomst bevatten. Wat een gebruiker zelf heeft ingevuld, blijft behouden.

Wat het opleverde

Alle beelden hebben nu trefwoorden, en waar de velden leeg waren ook een beschrijving en de tekst van het beeld. Per 1500 beelden gebruikten de scripts ongeveer 1 uur. Later toegevoegde afbeeldingen kunnen los verwerkt worden

Het model is niet perfect: soms leest het te veel in een figuur. De uitkomst is een stevig startpunt voor de beheerders, en weinig tijd verlies in het taggen van nieuwe afbeeldingen. Over tijd verbetert de kwaliteit zich vanzelf, aan de hand van eerder behandelde afbeeldingen.

Wat dit betekent voor jouw systeem

Bijna elk bedrijf heeft wel een verzameling waar niemand meer goed in kan zoeken: productfoto's, technische tekeningen, gescande documenten, inspectiefoto's. Dezelfde aanpak werkt daar ook. Het systeem dat je al hebt blijft staan, de gegevens gaan niet naar een externe AI dienst, en de mensen die de collectie kennen beoordelen het resultaat voordat er iets wordt opgeslagen.

Technisch bekeken

Dit is een korte uitleg over de specifieke setup die voor dit project gebruikt is. Er zijn natuurlijk verschillende manieren om dit aan te vliegen, deze werkte goed voor dit project.

• Model: Qwen3-VL-30B-A3B, een open source model geserveerd met vLLM.

• Hardware: een NVIDIA DGX Spark (128 GB gedeeld geheugen). Het model gebruikt ongeveer 45 GB, waarvan 30 GB gewichten; ongeveer 75 GB schijfruimte. een server GPU met minimaal 48 GB geheugen werkt.

• Snelheid: ongeveer 2,5 seconden per beeld, zo'n 1.500 beelden per uur.

• Koppeling: de ResourceSpace API voor het ophalen van voorvertoningen en het terugschrijven van velden. Het enige verkeer loopt tussen de tagger en de eigen server.

• Opbouw: twee aparte stappen (eerst transcriptie, dan beschrijving), gestructureerde uitvoer, trefwoorden gekoppeld aan de bestaande termenlijst, en een schrijfregel die alleen lege velden of eigen eerdere uitkomsten overschrijft.

• Uit de praktijk: sommige voorvertoningen waren kleurgeïnverteerd, sommige originelen heel klein, en één tekening liet het model in herhaling vallen tot het zijn limiet bereikte. Elk geval vroeg een kleine aanpassing.

Een vraag als deze?

Speelt er bij jou een vraagstuk over je eigen lokale AI? Leg hem gerust bij ons neer. We beginnen altijd met een concept: wat heb je nodig, wat mag het systeem uit, en welke gegevens moeten binnen blijven.