Fallstudien · Fallstudie 07 · Datenarchitektur · KI
Ein Katalog mit 2,9 Millionen Produkten aus unsauberen Händler-Feeds, und ein öffentlicher MCP-Server, über den Claude und ChatGPT darin suchen.
Ein Marktplatz für den lokalen Handel importiert die Produkt-Feeds tausender Händler aus rund fünfzehn Märkten und führt sie zu einem Katalog zusammen, durchsuchbar nach Markt und Sprache. 2026 wurde dieser Katalog über einen öffentlichen Model-Context-Protocol-Server zugänglich gemacht: Ein KI-Assistent fragt ihn direkt ab, ohne API-Schlüssel und ohne eigene Integration. So ist er gebaut, was schiefging, und was ich ändern würde.
PDF · 3 Seiten Zugehörige Leistung: KI-Automatisierung →
Steckbrief
Rolle
Gründer und Architekt; ein Team von vier Entwicklern für Front-end, Back-end, Android und iOS
Stack
Eigenes PHP-Framework, MongoDB für Speicherung und Volltextsuche, Redis als Cache, Python-Jobs für Bereinigung und Exporte
Quellen
XML-Feeds der Händler im Google-Shopping-Stil, mit allen Varianten an Kodierung, Entitäten und fehlenden Feldern
Takt
Automatischer Importzyklus etwa alle neunzig Minuten; monatlicher Neuimport pro Händler im Volltarif; Exporte als Google-Shopping- und Facebook-Feeds
MCP-Server
Streamable-HTTP-Transport, Protokoll 2025-03-26, nur Werkzeuge, keine Authentifizierung, Katalog je Markt
Stand
Im Produktivbetrieb, täglich genutzt von Händlern und von KI-Assistenten
Ausgangslage
Händler schreiben Produktdaten nicht für Maschinen. Ein Feed kommt mit HTML-Entitäten in den Titeln, Preisen ohne Währung, Kategorien in den eigenen Worten des Händlers, Dienstleistungen und digitalen Gütern zwischen physischen Produkten. Multipliziert mit tausenden Händlern in fünfzehn Sprachen ist der Katalog nur so gut wie die Pipeline, die ihn bereinigt.
Problem
Drei Probleme zugleich. Unsaubere Feeds ohne menschliches Zutun und ohne Verlust von Artikeln einlesen. Einen Katalog führen, der sich trotzdem wie fünfzehn nationale verhält, denn wer in Lissabon einkauft, darf keine Preise aus Tokio sehen. Und ab 2026 das Ganze für Sprachmodelle nutzbar machen, die zur neuen Eingangstür der Produktsuche werden, ohne für jeden Assistenten eine eigene Integration zu bauen.
Was ich getan habe
- Ein toleranter Parser: Feeds werden geladen, von defekten Entitäten befreit, auf UTF-8 gezwungen, validiert und Artikel für Artikel gelesen, mit Feld-Fallbacks im Google-Shopping-Stil (Titel, Kategorie, Bild, Preis, Währung aus dem Gebietsschema, wenn sie fehlt, Versandkosten, Typ). Nichts wird wegen eines falschen Zeichens verworfen.
- Katalog von Anfang an je Markt und Sprache: eine Datenbank pro Site, Kategorien auf den Baum jedes Händlers abgebildet, Schlagwörter aus den Titeln, Textindizes auf Titel, Inhalt und Autor.
- Ein Daemon mit Sperren und Zeitlimits, damit sich Importe nie überlappen und ein hängender Job abgebrochen statt eingereiht wird; derselbe Zyklus erzeugt die Google-Shopping- und Facebook-Exporte.
- Ein Job zur massenhaften Neuklassifizierung, der Artikel in Paketen liest und mit gewichteten mehrsprachigen Regeln (Englisch, Italienisch, Deutsch, Spanisch, Französisch) in Produkte, Dienstleistungen und digitale Dateien sortiert, Kollisionen von Kennungen protokolliert und auflöst.
- Sprachmodell-Agenten im Produktivbetrieb für das, was Regeln nicht können: Kataloge bereinigen, Inhalte für Facebook und Instagram vorbereiten und veröffentlichen, tägliche Betriebsberichte.
- Ein öffentlicher MCP-Server mit sechs Werkzeugen: Volltextsuche mit Filtern nach Land, Stadt, Kategorie, Preis und Lieferung, Autovervollständigung, Kategorie- und Städtelisten mit Zählungen, Händlersuche mit Rückgriff auf OpenStreetMap, Händlerdetails. Nur lesend, ohne Schlüssel, damit jeder Assistent ihn vom ersten Tag an nutzen kann.
Ergebnis
Rund 2,9 Millionen Produkte von tausenden Händlern, durchsuchbar je Markt in etwa fünfzehn Sprachen, aktuell gehalten durch einen unbeaufsichtigten Zyklus. Der MCP-Server hat den Katalog zu einem Werkzeug gemacht, das Claude, ChatGPT oder jeder kompatible Assistent direkt aufrufen kann, ohne Entwickler auf einer der beiden Seiten. Für ein kleines Team ist das Reichweite, gekauft mit Architektur statt mit Marketing.
Was ich anders machen würde
- Beim Import klassifizieren, nicht danach. Produkte, Dienstleistungen und digitale Güter wurden zu spät unterschieden, und die Neuklassifizierung musste Kollisionen auflösen, die ein strengerer erster Durchlauf vermieden hätte.
- Den Markt in jedem Aufruf explizit machen. Der MCP-Server hat einen Standardmarkt, und es ist fast nie der, den der Assistent meint; die Werkzeugbeschreibungen sagen das inzwischen, aber das richtige Design ist ein Pflichtparameter.
- Volltextsuche über die Indizes der Datenbank war bei einer Million Produkten richtig und ist bei drei ein Kompromiss. Der nächste Schritt ist eine eigene Suchmaschine, gewählt, bevor der Katalog die Entscheidung erzwingt.
PDF per E-Mail erhalten
Diese Fallstudie als PDF, zum Aufbewahren oder Weiterleiten?
Das PDF kommt innerhalb einer Minute per E-Mail, als Anhang. Keine Anrufe, keine automatischen Serien.
Fallstudien
Ein Katalog, eine Datenpipeline oder eine KI-Integration, die dem Team entwachsen ist, das sie gebaut hat?
Schreiben Sie mir in zehn Zeilen, um welche Daten es geht, welche Mengen und wo es weh tut. Innerhalb von 48 Stunden erhalten Sie eine kostenlose erste Einschätzung: was bleibt, was neu gebaut wird, mit welchem Budget.