Bonprix AI Projekt

Die Projektdateien befinden sich hier:: dev02:/home/picalike/projects/bonprix_ai

This page is not current, more current information is found in bonprix_ai_service and the git

https://git.picalike.corpex-kunden.de/incubator/bonprix-ai

Das besprochene Interface sieht wie folgt aus:

• Input: api_key, Bilddaten im POST, [url_list: Optional]
• Output: JSON-Dictionary wie im Vertrag

Der api_key wird mit bonprix geteilt, ohne diesen ist kein Zugang möglich. Derzeitiger Stand ist ein Mockup Modus, der zufällig Daten generiert. Die Rückgabe ist aber gemäß der Taxonomie, also gültige Attribute + Ausrägungen, dann jeweils mit zufälligen Scores

https://docs.google.com/document/d/1hbqpF5AfeEAjJEVZeWc0ttoXHmaFcAN4/edit

(PDF) [persistenter Link aus Slack…]

Werden derzeit NICHT verwendet

Ordner mit Bildern ist hier zu finden:
https://drive.google.com/drive/folders/1oSLEY_N9kbsk-flmsgFLzq_u-vCf9iMm

Datei mit Übersicht der fehlenden Attribute:
https://docs.google.com/spreadsheets/d/1g_Cy4a4thasKb5A-H5nYEZptFdkYmekT/edit#gid=1752532373

Simone hat in einer Excel-Tabelle (Teams→Dateien: https://teams.microsoft.com/l/file/94EFE4B8-4219-4A65-81F9-121AB4B20FF5?tenantId=8794e153-c3bd-4479-8bea-61aeaf167d5a&fileType=xlsx&objectUrl=https%3A%2F%2Fog2gether.sharepoint.com%2Fsites%2FAP-PicalikeBonprix%2FFreigegebene%20Dokumente%2FGeneral%2Fbonprix%20ai.xlsx&baseUrl=https%3A%2F%2Fog2gether.sharepoint.com%2Fsites%2FAP-PicalikeBonprix&serviceName=teams&threadId=19:af1e5fb777474f8c836fc3dcad70cdf5@thread.tacv2&groupId=fe409595-49b8-456c-9e8f-e1572057781f) Feedback zu den Bildern zusammengetragen.

FAZIT: Externe Agentur-Bilder sollen nicht direkt mit Styles verknüpft werden, sonder dienen als zusätzliches Trainingsmaterial.

Der Dienst wird nach außen hin, unter http://api.picalike.com:8060 [/get_image_attributes]. Die Anfrage wird auf sandy.picalike.corpex-kunden.de:8060 weitergeleitet. Dort läuft (bald) der eigentliche Dienst.

Auf sandy lebt der Dienst unter:
/home/picalike/bonprix_ai

Der API-Key ist fest auf 59db0943c6ef48544ffdfa4a0a3c9e10 gesetzt.

Test für den Dienst:

curl http://api.picalike.com:8060/health

MVP Deadline: 8 Wochen nach Zugang des letzten Daten-Batches

Ziel: einen Web-Dienst, basierend auf FastAPI, der eine Annotation (Attribute) von Produkt-Bildern von Bonprix ermöglicht.

INPUT: Mehrere Arbeitsbilder, wobei das Format 'Professional' oder 'Schnapsschuss' sein kann.

OUTPUT: JSON-Dokument (Dictionary) mit Format gemäß Vertrag, d.h. erkannte Attribute + Score + Ausprägung + Score.

Jeden Freitag um 08:30, um einmal mögliche Fragen durchgehen und Fortschritte zu präsentieren.
Im März ist es noch jeden Mittwoch um 08:30.

Notizen zu Gesprächen. Ziel ist es auch, eine Guideline für Daten gemeinsam zu erarbeiten, da die Bilder bisher nicht nach gewählten Kriterien ausgewählt worden. Das schließt Bildgröße, Ausrichtung, etc. ein.

• Aufgrund mehrerer Fragen hat der Workshop heute nicht stattgefunden. Es wurde entschieden, 521 als Attribut nicht mehr zu trainieren, da es ein Vermarktungsattribut ist.
• Auch gibt es dort 'Hidden' Attribute, die auf dem Bild nicht sichtbar sind
• Die falsch eingefügten Bilder werden seitens Bonprix korrigiert. Die Annahme ist, dass es nur wenig sind und wir zeitnah einen neuen Datensatz erhalten.
• Ziel ist es jetzt, die restlichen Attribute zu trainieren und die Modelle zu aktualisieren

• Bonprix hat die QA beendet und uns neue Daten geschickt. Dort sind noch 2-3 Ausreißer, aber die korrigiert Adrian und schickt uns eine neue Version des Datensatzes
• Die möchten zügig eine neue Bewertung. Ich fange am 16.08 an und habe hoffentlich in 2-3 Tagen belastbare Zahlen. Danach wollen wir uns zügig mit Bonprix treffen und die Situation bewerten
• Weitere Kategorien werden erst angegangen, wenn wir zeigen können, dass eine Verbesserung der Vorhersagen vorhanden ist

• Bonprix erzeugt heute ein Report, der zeigt, wie viel geändert werden muss. Wir rechnen aber mit mindestens 14 Tage bevor es wieder los geht
• Gute Neuigkeiten sind, dass die Otto International Bilder schon integriert wurden
• Wir bekommen nächste Woche die Info, wie lange es dauert, bzw. wie viele Style nachgearbeitet werden müssen

• Fazit ist, dass Bonprix längere Zeit, 1-3 Wochen wohl, benötigt, um den Datenbestand nochmal zu prüfen. In der Zeit wird das Projekt ruhen. Sobald der Prozess abgeschlossen ist, meldet sich Bonprix
• Der Workshop ist ebenfalls auf unbestimmte Zeit verschoben.

• Klärung Neckdiameter-Attribut: eigentlich auf jeden Produkt bei PoC vorhanden, aber teilweise nicht im Style. Gründe dafür sind (1) Style nicht komplett gepflegt, (2) bei Spaghetti-Trägern wird das Attribut nicht gesetzt, weil diese keine Kragenweite haben. Diese Regeln spaghetti→none(484233910) werden seitens Bonprix erfasst, um unsinnige Vorhersagen zu korrigieren. Fazit ist, bei dem Attribut gibt es kein None, zumindest nicht für die PoC-Kategorien. Bei allen Kategorien könnten None-Werte aus den anderen Kategorien gezogen werden
• Styles mit weniger als 4 Attributen sollten als nicht gepflegt eingestuft werden und für das Training nicht berücksichtigt werden
• Herausforderung: Entscheidungen die nur auf wenigen Pixeln basieren, wie 'wide' vs. 'normal' bei 1908069453 vs. 1689607957 werden bei 224×224 (Netz-Input) schwer ableitbar sein
• Die Alien-Kategorien beim neuesten Export sollen korrigiert werden
• Ziel ist es, 100 zusätzliche Styles zu bekommen, mit Büstenbildern. Problem bei den Bilder ist allerdings ein sichtbares Logo, dass z.B. als Muster für eine Klassifikation einiger Merkmale verwendet werden kann. Bonprix plant, einige Logos zu retuschieren.

• Der automatische Job für Eval läuft 13/18 Uhr jeden Tag
• API: Es kam die Frage nach der Kategorie auf. Wie werden die richtigen Modelle/Attribute gewählt? Die Aussage ist, dass die Kategorie mit übertragen wird und wir dann den Modell-Satz auswählen (über die Produkt-Klasse)
• Mit dem Baseline-Modell liegen wir bei nur 28-30%.
• Es wird einen Test mit der Agentur und Pseudo-Styles geben, bonprix gibt uns eine Liste von wichtigen Attributen ~5. Ein Pseudo-Style hat 3 Bilder
• Seitens Bonprix werden noch mehr Styles zur Verfügung gestellt
• Wir können Bilder augmentieren, solange wir nicht die Perspektive ändern, oder stauchen/strecken
• Der zeitliche Horizont bei den Änderungen ist auf Seiten von bonprix min. 2 Wochen
• Wir stellen unsere Methodik von 'ordinärer' Klassifikation auf Few-Shot Klassifikation um, um overfitting und die geringe Anzahl Bilder pro Ausprägung zu kompensieren

• Der Dienst + API steht, der Wunsch war noch eine API, die alle Attribute und deren Ausprägungen zurückliefert (dict). Priorität ist aber gering, da nicht direkt benötigt. Der Service ist damit feature-complete. Modell-Update durch Restart bleibt erstmal so
• Bezüglich Bilder der Agentur: Wir erbitten ein weiteres Testsets, wobei jedes Produkt k=3 Bilder unterschiedlicher Sichten haben sollte. Gewählt werden die Ausprägungen, die 'fast' vollständig sind, also bei dem Schwellenwert liegen. Da hätten wir gerne so viele wie (kostenlos) noch möglich.
• Es gibt automatisiert eine Auswertung der aktuellen Modelle durch bonprix. Diese wird einmal täglich erzeugt und in Teams zur Verfügung gestellt.
• Die derzeitigen Modelle liefern auf den Testdaten im Schnitt eine eher mangelhafte Auswertung
• Produktionsbilder werden seitens Bonprix noch nachgereicht
• Die unvollständigen Styles benötigen noch mehr Zeit seitens Bonprix
• Nächster Schritt ist die Modellverbesserung

Wir haben uns noch mit Adrian getroffen, um nochmal zu klären, ob wir nicht auf Bildebene trainieren können. Fazit: bei widersprüchlichen Einzelvorhersagen ist eine Aggregation schwierig, weshalb wir auf Style-Ebene bleiben, um eine “kohärente” Vorhersage für die Bildmenge, also den Style zurückzugeben.

• Training sollte mit zufälligen Teilmengen der Bilder sein, weil zur Testzeit nicht alle Perspektiven vorhanden sind
• Agentur: der Vorschlag ist, mehrere Perspektiven / Farben für ein Produkt/Attribut zu generieren, um Styles zu emulieren
• Ein Mapping Label→Perspektive ist ggf. sinnvoll, um zu sagen, ob ein Attribut auf der Ansicht überhaupt sichtbar ist. Ist aber nicht so wichtig, wenn wir auf Style-Ebene bleiben, da das Modell die relevanten Bilder automatisch wählt
• Wir schicken Adrian eine Liste von Attributen + Ausprägungen, damit die nichts testen, was wir nicht trainiert haben
• Es besteht die Möglichkeit, dass wir zusätzliche Styles erhalten, aber ohne Arbeitsbilder. Damit könnten wir Ausprägungen auffüllen. Die Präferenz bei Styles ist aber klar, mit Arbeitsbild, da es dem Test-Modus entspricht.

• Bilder der Agentur sollten nur aus den MVP-Kategorien stammen
• Simone hat eine Excel-Liste für das Feedback bereitgestellt
• Am 14.4 wird bei Bonprix ein Zwischenstand präsentiert. Bis dahin brauchen wir einen Dienst mit realen Modellen und Prediktionen
• Agentur: Es werden nur noch Bilder bei Bedarf geordert, nicht automatisch für alle Ausprägungen unter dem Schwellenwert
• Wie werden zusätzliche Bilder der Agentur verwendet? Nicht in den Style anfügen, sondern als generelle Hilfe für das Training. Wie genau das technisch abläuft, muss noch entschieden werden
• Wir erhalten von Bonprix den letzten Stand der Daten heute noch. Lediglich einige Bilder fehlen (404), sind aber weniger als 10

Deadline: 12.4 für den Prototypen

• wie soll mit falschen Bildern umgegangen werden?

• Wenn zu viele Bilder einer Ausprägung falsch sind → Feedback zu Agentur: Mindestens ein Exemplar-Bild, wo die wichtigen Merkmale farblich markiert sind + Prosa
• Geteiltes Dokument mit in dem falsche Bilder gelistet werden
• → Mapping Ordnername - Ausprägung falls diese nicht übereinstimmen
• Pricing: wie teuer ist ein Bild / der gesamte Datensatz
• Mehrwert: wie viel besser ist der Algorithmus mit weiteren Bildern?
• Bildmodalität: Agentur mitteilen: keine weiteren Objekte im Vordergrund. Hintergrund ist okay. Störobjekte aus der Modewelt generell verhindern.
• neue Daten nächste Woche; wahrscheinlich mit Information über die Bildorientierung
• FastAPI Schnittstelle zeitnah
• Laut Bonprix haben die zusätzlichen Bilder Arbeitsbild-Charakter (gut)

• erste Resultate für Attribut gezeigt (Genauigkeit one vs. rest auf Trainset)
• gemeinsame Datenablage: Teams-Order wird von Bonprix organisiert für Grafiken und andere Dokumente
• Der finale Datensatz wird von Bonprix nächste Woche geliefert. Dann keine weiteren Updates mehr, außer QA
• Auffüllen von unterbesetzten Attributen/Ausprägungen durch externen Dienstleister. Organisiert von Sebastian
• Seitens Bonprix gab es den Wunsch auf eine API-Spezifikation + Test-Webdienst damit die Entwicklung auf deren Seiten beginnen kann
• Nochmal geklärt: PoC umfasst Gruppe 1, 6 Kategorien und deren Labels
• Um Fortschritt festzuhalten nutzen wir den bestehenden Plot. Es gab noch den Wunsch, Genauigkeit für Attribute und Ausprägungen im Plot zu gruppieren

• Bonprix schickt und jedesmal ein Gesamtpaket an Daten, wodurch die älteren Daten ersetzt werden.
• Die nicht genannten (MVP) Kategorien im Datensatz sind irrelevant.
• Es wurden redundante Attribute entfernt. Dadurch haben einige Produkte weniger Attribute als zuvor. Es kam dadurch auch zu dem Fehler, dass manche Produkte gar keine Attribute mehr haben. Das wird von Bonprix behoben.

• Kleinere Bilder: es handelt sich um ältere Bilder, diese können vorkommen, neuere Bilder werden aber ochauflösender sein.
• Rotation von Bildern: ebenfalls legacy, und die Guideline ist, dass neue Bilder nur 'aufrecht' fotografiert werden.
• Outfit-Bilder: sind ebenfalls reingerutscht und werden in Zukunft nicht vorkommen
• Hintergrund ohne Produkt: Bei Shootings werden Umgebungen aufgenommen, diese haben leider keine Annotation, sollen aber auch nicht in unseren Datensatz eingefügt werden.
• Typen von Bildern: Zeichnungen sind möglich und müssen berücksichtigt werden. Die sollen in Zukunft einen eigenen Typen bekommen.
• Test-Metrik: die Verteilung von Bildern ist genau wie im Datensatz, d.h. wir können ganze Style-IDs entfernen und mit der Verteilung der Bilder testen.
• Welche Attribute visuell identifizierbar sind, stellen wir mit eigenen Tests fest und teilen die Ergebnisse Bonprix mit.
• Attribute wie sweats_{NO,SL,HE}_Stitching sind tatsächlich unterschiedlich. Sie beziehen sich auf Saum, Ärmel, Kragen etc. Ob eine Unterscheidung möglich ist, muss geklärt werden.

Montag soll es den nächsten Schwung Daten geben.

Unser Commit bis Mittwoch: einmal eine einfache Pipeline (Attribute erkennen) anwenden und denen erste Ergebnisse mitteilen.

• Bei Ausprägungen sind wir noch nicht angelangt, Fragen diesbezüglich klären wir in späteren Treffen

Wir haben 532 Beispiele erhalten.

Eindeutige ID ist 'style_id', Bild-URLs sind unter 'images' mit Annotationen für die Perspektive. Die restlichen Einträge sind Attribute als key-value-Paare.

Es gibt insgesamt 41 normale Attribute, mit 321 Ausprägungen.

[Genauere Übersicht der Datei sollte noch folgen]

Es werden drei Arten von Kategorien im Feed bereitgestellt.

Nach Feedback haben wir erneut Daten erhalten.

Diese beinhalten 152 Attribute. Das mapping Attribut - ID kann hier gefunden werden:

https://docs.google.com/spreadsheets/d/1hoKGdZV0OmqCcXbQd85iXmL94k72wQQx/edit#gid=1560664826

Eine Liste der Ausprägungen ist nun auch vorhanden:

https://docs.google.com/spreadsheets/d/1JPmV4bkZYI1k4g0-9VPrBTxMhGumi_2u/edit#gid=1338974510

Da ein Produkt aus mehreren Bildern besteht wäre es sinnvoll, auch mehre Bilder für die Vorhersage von Attributen zu verwenden. Dafür gibt es sogenannte Multi-Image Netze [https://arxiv.org/pdf/2101.04909.pdf%5D, die eine Transformer-Schicht verwenden, und dann (Sum-)Pooling, um die variable Menge an Bildern in eine Darstellung fester Länge zu überführen.

https://d-nb.info/118841030X/34 Abschnitt 3

Hinweis: wir beschränken uns bei der Recherche und Methodik auf Ansätze basierend auf Neuronalen Netzen.

https://arxiv.org/pdf/2011.14027.pdf

Passt nahezu perfekt und ist zu 80% genau der Ansatz, den ich mir auch überlegt habe.

ich habe einige vorläufige Experimente durchgeführt und es gibt einige offene Fragen, die vor der Implementierung geklärt werden müssen.

Da für die Aufgabe mehrere unterschiedliche Klassifikationsstufen nötig sind ist es nicht trivial eine Metrik auszuwählen. Die aufgezählten Metriken gehen davon aus, dass die Netz-Ausgabe durch ein beliebiges Verfahren, z. B. Thresholding, zu Nullen und Einsen konvertiert wurde.

Die Liste von Metriken ist zusammengestellt aus den folgenden Quellen:

https://towardsdatascience.com/journey-to-the-center-of-multi-label-classification-384c40229bff
https://mmuratarat.github.io/2020-01-25/multilabel_classification_metrics
https://en.wikipedia.org/wiki/Multi-label_classification#Statistics_and_evaluation_metrics

Relevante Metriken sind:

• Precision / Recall / F1 Score, jeweils im Mikro oder Makro Average
• Hamming Loss: Verhältnis von falschen Labels zu Anzahl Labels (oder unnormalisiert als Error Counter)
• Exact Match Ratio: Anteil exakt richtig klassifizierter Produkte (entspricht Accuracy), kann abgeschwächt werden zu Anteil Produkte mit mehr als X% korrekt klassifizierten Attributen.

Generell sind Labels nicht gleichverteilt, sodass Metriken ggf. extra Gewichtungen benötigen.