KI-Moodboards für die Modebranche: Von der relationalen Datenbank zur Vektorsuche

Ein Produktkatalog kann vollständig erfasst sein und trotzdem die wichtigste Frage nicht beantworten: Passt dieses Teil zur gewünschten Stimmung?

Ein mittelständischer Hersteller entwickelt und produziert Modeaccessoires für die Fashion- und Sportswear-Branche: Schnallen, Knöpfe, D-Ringe, Verschlüsse, Zipper und zahlreiche dekorative Elemente.

Zweimal im Jahr entstehen neue Kollektionen mit rund 1.500 Artikeln. Am Anfang jeder Saison werden Themes und Moodboards erstellt. Dabei legen Designer eine gestalterische Richtung fest, zum Beispiel:

Warme, gebürstete Metalle, Art-déco-Geometrie und gedeckte Erdtöne.

Anschließend suchen sie Produkte, die zu dieser Stimmung passen.

Das Problem war dabei nie ein Mangel an Auswahl. Das Problem war, in einem sehr großen Katalog genau die richtigen Produkte zu finden.

„Passt das zur Stimmung?“ ist keine Stichwortsuche

Eine klassische Produktsuche arbeitet mit strukturierten Merkmalen:

• Artikelnummer
• Kategorie
• Material
• Farbcode
• Abmessungen

Diese Angaben sind wichtig, beantworten jedoch nicht die zentrale Frage beim Aufbau eines Themes oder Moodboards:

Fühlt sich dieses Produkt für die neue Kollektion richtig an?

Dabei geht es um visuelle und gestalterische Eigenschaften:

• Oberfläche
• Form
• Materialwirkung
• Stil
• Charakter
• historische oder kulturelle Assoziationen

Diese Merkmale liegen nicht zuverlässig in einzelnen Datenbankspalten vor.

Mitarbeiter durchsuchten den Katalog Bild für Bild und wählten Produkte aus, die zur gewünschten Stimmung passten. Das war zeitaufwendig, hing stark vom persönlichen Produktwissen ab und skalierte nicht mit einem Sortiment, das jedes Jahr um etwa 3.000 neue Artikel wächst.

Unser Ziel war daher:

Designer sollen eine Stimmung in natürlicher Sprache beschreiben und unmittelbar passende Produkte finden können.

Der Ansatz: Produktbilder in Bedeutung übersetzen

Semantische Suche funktioniert nicht über identische Begriffe, sondern über inhaltliche Ähnlichkeit. Dafür wird jeder Inhalt als sogenanntes Embedding dargestellt: als numerischer Vektor, der seine semantischen Eigenschaften abbildet.

In diesem Vektorraum liegen ähnliche Inhalte näher beieinander als unterschiedliche. Die Suche besteht dann nicht mehr aus einem klassischen Textvergleich, sondern aus einer Distanzberechnung:

1. Produktbilder werden in Vektoren übersetzt.
2. Die Suchanfrage wird ebenfalls in einen Vektor übersetzt.
3. Das System sucht die Produktvektoren mit der geringsten Distanz zur Anfrage.

Unsere Verarbeitungspipeline läuft offline in drei Schritten.

1. Das Produktbild beschreiben

Jedes Produktfoto wird von einem Vision-Modell analysiert.

Das Modell erstellt eine ausführliche Beschreibung dessen, was ein Designer auf dem Bild wahrnehmen würde, zum Beispiel:

• Form
• Oberflächenstruktur
• Finish
• Farbwirkung
• Stil
• dekorative Merkmale

Die Beschreibung soll nicht lediglich wiedergeben, dass es sich beispielsweise um eine Schnalle handelt. Sie soll erfassen, wie das Produkt gestalterisch wirkt.

2. Die Beschreibung einbetten

Aus der erzeugten Beschreibung wird ein hochdimensionales Embedding erstellt. In der produktiven Anwendung besitzt jeder Vektor 3.072 Dimensionen.

3. Den Vektor speichern und indexieren

Das Embedding wird gemeinsam mit dem Produkt gespeichert und für die spätere Suche indexiert.

Gibt ein Designer anschließend eine Stimmung ein, wird auch diese Anfrage eingebettet. Danach liefert das System diejenigen Produkte zurück, deren Vektoren der Anfrage am nächsten liegen.

Das Beschreiben und Einbetten der Produkte war technisch nicht der schwierigste Teil.

Die eigentliche Architekturfrage lautete:

Wie speichern und durchsuchen wir Millionen hochdimensionaler Zahlen zuverlässig und schnell?

Version 1: Similarity Search mit MySQL

Das Unternehmen betrieb bereits eine MySQL-Datenbank. Der pragmatische erste Schritt bestand deshalb darin, die Embeddings dort zu speichern. Jedes Embedding lag als JSON-Spalte neben dem zugehörigen Produktdatensatz.

Die Similarity Search fand im Anwendungscode statt:

1. relevante Datensätze aus MySQL laden
2. jedes Embedding gegen den Anfragevektor vergleichen
3. Kosinus-Similarity berechnen
4. Ergebnisse sortieren
5. anhand eines Schwellwerts filtern
6. die besten Treffer zurückgeben

Das war für den Einstieg die richtige Entscheidung.

Die erste Version:

• konnte schnell umgesetzt werden
• erforderte keine zusätzliche Infrastruktur
• nutzte die vorhandenen Backups und Betriebsprozesse
• hielt Produkte und Embeddings im bestehenden Datenmodell zusammen
• erlaubte früh zu prüfen, ob die semantische Suche tatsächlich einen Nutzen brachte

Für einen begrenzten Teil des Katalogs waren die Antwortzeiten zunächst ausreichend.

Die Grenze des Ansatzes: erst laden, dann rechnen

MySQL speichert die Embeddings, kann eine semantische Distanz zwischen Vektoren aber nicht berechnen. Die Similarity musste deshalb außerhalb der Datenbank entstehen: Für jede Anfrage lud die Anwendung zunächst alle relevanten Embeddings aus MySQL in den Arbeitsspeicher und berechnete erst dort — Vektor für Vektor — die Distanz zur Anfrage.

Die Datenbank konnte dabei nichts vorab einschränken. Jede Suche war damit ein vollständiger Brute-Force-Scan: erst den gesamten Bestand laden, dann alles vergleichen. Ein wachsender Katalog verschärfte das nur zusätzlich. Die Ursache war aber nicht die Größe, sondern die Reihenfolge — erst laden, dann rechnen.

Um die Antwortzeiten noch erträglich zu halten, optimierten wir den Anwendungscode:

• Datensätze wurden seitenweise geladen.
• Berechnungen liefen parallel über mehrere CPU-Kerne.
• Die besten Treffer wurden laufend in einer begrenzten Datenstruktur gehalten.
• Unnötige Ergebnisse wurden so früh wie möglich verworfen.

Diese Maßnahmen verbesserten die Ausführung, lösten aber nicht das eigentliche Problem. Eine klassische relationale Datenbank versteht keine semantische Distanz zwischen Vektoren. Sie kann:

• keinen geeigneten Vektorindex verwenden
• den Suchraum nicht gezielt einschränken
• nahe Nachbarn nicht ohne vollständigen Vergleich ermitteln
• das Lesen großer Teile des Index nicht vermeiden

Die Anwendung übernahm damit im Arbeitsspeicher Aufgaben, für die die Datenbank selbst keine geeigneten Strukturen besaß.

Vektoren in einer relationalen Datenbank zu speichern war einfach.

Sie effizient zu durchsuchen war es nicht.

Version 2: eine spezialisierte Vektordatenbank

Für die zweite Version verlegten wir den Suchpfad auf Qdrant, eine speziell für Vektorsuche entwickelte Datenbank.

Approximative Nearest Neighbor Search

Qdrant verwendet einen HNSW-Index für die approximative Nearest Neighbor Search.

Statt jeden gespeicherten Vektor vollständig gegen die Anfrage zu prüfen, navigiert die Datenbank durch eine Graphstruktur. Dadurch erreicht sie sehr ähnliche Vektoren, ohne den Großteil des Datenbestands einzeln betrachten zu müssen.

Die Anwendung muss dafür nicht mehr den gesamten Vektorbestand laden und vergleichen.

Vektordistanz als native Operation

Kosinus-Ähnlichkeit ist in der Vektordatenbank keine nachträglich implementierte Schleife im Anwendungscode, sondern eine zentrale Datenbankoperation. Die Suchmaschine kann ihre internen Datenstrukturen gezielt darauf optimieren.

Metadatenfilter im selben Suchvorgang

Jeder Vektor enthält zusätzlich eine Payload mit Metadaten, zum Beispiel:

• Produkt-ID
• Bildreferenz
• Kollektion
• Import-Batch
• Kategorie
• URL

Dadurch lässt sich die semantische Suche bereits während der Vektorabfrage einschränken. Ein Designer kann etwa nur innerhalb der aktuellen Kollektion oder einer bestimmten Produktgruppe suchen, ohne zunächst einen großen unpassenden Ergebnisraum zu erzeugen.

MySQL bleibt die Quelle der Wahrheit

Trotz des Wechsels haben wir MySQL nicht ersetzt.

Die relationale Datenbank bleibt das führende System. Jedes Embedding wird dort weiterhin dauerhaft gemeinsam mit dem Produktdatensatz gespeichert.

Qdrant behandeln wir dagegen als spezialisierten Suchindex.

Die Architektur folgt damit einer klaren Aufgabenteilung:

MySQL

• führender Produktdatenbestand
• dauerhafte Speicherung
• bestehende Backups
• Transaktionen
• etablierte Betriebsprozesse

Qdrant

• Vektorindex
• schnelle Ähnlichkeitssuche
• HNSW-Navigation
• semantisches Retrieval
• kombinierte Metadatenfilter

Die Vektordaten werden aus MySQL nach Qdrant synchronisiert.

Sollte der Vektordienst ausfallen oder der Index beschädigt werden, gehen keine führenden Produktdaten verloren. Der Suchindex kann aus der relationalen Datenbank erneut aufgebaut werden. Die Anwendung kann in diesem Fall kontrolliert degradieren, anstatt ihren primären Datenbestand zu verlieren.

Warum die erste Version trotzdem richtig war

Die Umsetzung in MySQL war kein unnötiger Umweg.

Sie ermöglichte uns, die entscheidenden Fragen früh und mit geringem Infrastrukturaufwand zu beantworten:

• Ist eine bedeutungsbasierte Suche für die Designer tatsächlich hilfreich?
• Erzeugen die Bildbeschreibungen relevante Ergebnisse?
• Verstehen die Embeddings gestalterische Begriffe ausreichend gut?
• Nutzen die Mitarbeiter die Funktion im Arbeitsalltag?
• Welche Filter und Darstellungen werden tatsächlich benötigt?

Eine Vektordatenbank hätte diese Produktfragen nicht beantwortet. Sie hätte lediglich früher zusätzliche Infrastruktur eingeführt.

Die erste Version war daher eine bewusste Entscheidung:

Zuerst das einfachste System bauen und damit sowohl die Machbarkeit als auch den Nutzen validieren.

Der konkrete Nutzen für die Designer

Früher begann der Aufbau eines Moodboards mit einer aufwendigen manuellen Suche.

Mitarbeiter mussten sich erinnern, welche Produkte aus einem sehr großen historischen Katalog zur aktuellen Designrichtung passen könnten. Anschließend durchsuchten sie Bildbestände und Produktlisten nach geeigneten Kandidaten.

Heute kann ein Designer die gewünschte Stimmung direkt beschreiben.

Zum Beispiel:

Dunkles, mattes Metall mit industriellem Charakter, klaren geometrischen Formen und einer hochwertigen, zurückhaltenden Wirkung.

Das System übersetzt diese Beschreibung in einen Vektor und sucht Produkte mit ähnlicher visueller und stilistischer Bedeutung.

Innerhalb weniger Sekunden entsteht eine Auswahl von Accessoires, die als Ausgangspunkt für das Moodboard dienen kann.

Die Anwendung ersetzt dabei nicht die gestalterische Entscheidung. Sie verkürzt den Weg zu einer relevanten Vorauswahl.

Was wir daraus mitnehmen

Semantische Suche besteht aus mehr als einem Embedding-Modell. Die eigentliche Produktlösung benötigt eine vollständige Verarbeitungskette:

• Bilder analysieren
• visuelle Eigenschaften sprachlich beschreiben
• Beschreibungen einbetten
• Vektoren dauerhaft speichern
• Suchindex synchronisieren
• Metadaten filtern
• Ergebnisse bewerten und darstellen
• Ausfälle kontrolliert behandeln

Für einen Prototyp kann eine relationale Datenbank ein sinnvoller Startpunkt sein. Sie reduziert Komplexität und ermöglicht eine schnelle Validierung des fachlichen Nutzens. Auf Dauer ist sie jedoch selten der richtige Ort für eine große Ähnlichkeitssuche.

Die tragfähige Architektur bestand deshalb nicht darin, die relationale Datenbank zu ersetzen, sondern beide Systeme gezielt einzusetzen:

MySQL bleibt die Quelle der Wahrheit. Qdrant übernimmt die semantische Suche.

So verbindet die Anwendung skalierbares Retrieval mit dem bestehenden Datenmodell, den bekannten Betriebsprozessen und der notwendigen Wiederherstellbarkeit.

Für Teams, die eine semantische Suche evaluieren, ergibt sich daraus eine pragmatische Reihenfolge:

1. Die fachliche Pipeline zunächst mit möglichst wenig zusätzlicher Infrastruktur validieren.
2. Relevanz und tatsächliche Nutzung messen.
3. Die Grenzen des ersten Ansatzes beobachten.
4. Bei wachsendem Datenbestand einen spezialisierten Vektorindex einführen.
5. Die relationale Datenbank weiterhin als führendes System verwenden.
6. Den Suchindex so gestalten, dass er jederzeit wiederaufgebaut werden kann.

Der wichtigste Architekturgrundsatz lautet dabei:

Erst den Nutzen beweisen, dann die Suche spezialisieren.