Letzte Quartal führten wir ein Projekt durch, das auf dem Papier einfach klang: 28.840 Produktdatensätze mit KI-generierten Beschreibungen, Kategorien und Metadaten anreichern. Der Client hatte einen riesigen E-Commerce-Katalog, der zu einem Headless CMS migriert wurde, und jeder einzelne Datensatz benötigte bessere Inhalte. Was folgte, war eine Meisterklasse in allem, was schiefgehen kann – und richtig läuft – wenn man Zehntausende von Datensätzen gegen eine KI-API wirft.

Das ist kein theoretischer Leitfaden. Ich werde Sie durch die tatsächliche Architektur führen, die wir aufgebaut haben, die exakten Kosten, die wir gezahlt haben, die Fehlermodi, auf die wir gestoßen sind, und die Muster, die uns gerettet haben. Falls Sie KI-Masseninhaltserweiterung für Ihr eigenes Projekt in Betracht ziehen, sollte dies Ihnen ein paar Wochen schmerzhafter Entdeckungen ersparen.

Inhaltsverzeichnis

Warum wir AI-Anreicherung der manuellen Arbeit vorgezogen haben

Die Mathematik war brutal einfach. Unser Client hatte 28.840 Produktdatensätze – jeder benötigte eine überarbeitete Beschreibung (150-300 Wörter), drei SEO-freundliche Kategorietags, eine Meta-Beschreibung und strukturierte Attribute extrahiert aus unstrukturierten Texten. Bei einer konservativen Schätzung von 8 Minuten pro Datensatz für einen menschlichen Copywriter sind das 3.845 Stunden Arbeit. Bei $35/Stunde sprechen wir von $134.575 und etwa 6 Monaten mit einem kleinen Team.

Wir haben die KI-Anreicherung in 11 Tagen für unter $3.200 in API-Kosten plus etwa 80 Stunden Engineering- und QA-Zeit abgeschlossen. Selbst unter Berücksichtigung unserer Entwicklungsstunden lag die Gesamtkosten bei etwa einem Zehntel des manuellen Ansatzes.

Aber hier ist das, was niemand Ihnen sagt: Der schwierige Teil besteht nicht darin, die API aufzurufen. Es ist alles drumherum. Datenbereinigung, Prompt-Optimierung, Qualitätsvalidierung, Fehlerbehandlung und die unvermeidlichen Sonderfälle, die Sie an Ihrer Karrierewahl zweifeln lassen.

Die Architektur: Wie wir die Pipeline gebaut haben

Wir haben die Anreicherungs-Pipeline als Node.js-Anwendung gebaut, was angesichts unserer Expertise in Next.js-Entwicklung und TypeScript sinnvoll war. Hier ist die übergeordnete Architektur:

Quell-CSV → Parser → Batch-Warteschlange → Claude API → Response-Validator → Output Store → QA-Dashboard

Die Datenschicht

Wir haben SQLite als unsere lokale Verarbeitungsdatenbank verwendet. Klingt unsexy, richtig? Aber für Batch-Verarbeitung wie diese ist es perfekt. Kein Server zum Verwalten, Transaktionen sind schnell und Sie können Ihre Ergebnisse leicht abfragen. Jeder Datensatz erhielt eine Statusspalte, die seinen Weg verfolgte:

interface EnrichmentRecord {
  id: string;
  original_title: string;
  original_description: string;
  raw_attributes: string;
  status: 'pending' | 'processing' | 'completed' | 'failed' | 'needs_review';
  enriched_description: string | null;
  enriched_categories: string[] | null;
  enriched_meta: string | null;
  structured_attributes: Record<string, string> | null;
  attempts: number;
  last_error: string | null;
  token_usage: number;
  created_at: string;
  updated_at: string;
}

Das Warteschlangensystem

Wir haben eine einfache Job-Queue mit BullMQ im Hintergrund von Redis implementiert. Jeder Job repräsentierte eine einzelne Datensatzanreicherung. Wir konfigurieren es mit:

  • Parallelität: 5 parallele Worker (mehr dazu später)
  • Max Wiederholungen: 3 pro Datensatz
  • Backoff: Exponentiell, beginnend bei 30 Sekunden
  • Job-Timeout: 60 Sekunden
const enrichmentQueue = new Queue('enrichment', {
  connection: redisConnection,
  defaultJobOptions: {
    attempts: 3,
    backoff: {
      type: 'exponential',
      delay: 30000,
    },
    timeout: 60000,
    removeOnComplete: false, // Keep for auditing
  },
});

Der Processing Worker

Jeder Worker zog einen Datensatz, konstruierte den Prompt, rief Claudes API auf, validierte die Response-Struktur und schrieb die Ergebnisse zurück. Falls die Response nicht unserm erwarteten JSON-Schema entsprach, ging sie in einen needs_review-Bucket statt den Datensatz stillschweigend zu beschädigen.

Claude API für Massenverarbeitung wählen

Wir haben drei Optionen bewertet, bevor wir uns auf Claude einigte (konkret Claude 3.5 Sonnet und später Claude 3.5 Haiku für einfachere Aufgaben):

Merkmal Claude 3.5 Sonnet GPT-4o Gemini 1.5 Pro
Input-Kosten (pro 1M Token) $3.00 $2.50 $1.25
Output-Kosten (pro 1M Token) $15.00 $10.00 $5.00
Rate Limits (RPM, Stufe 2) 1.000 500 360
JSON-Modus-Zuverlässigkeit Ausgezeichnet Gut Inkonsistent
Strukturierte Output-Qualität Beste in der Klasse Sehr gut Gut
Batch API Rabatt 50% 50% N/A

Preise ab Q1 2025. Aktuelle Preisgestaltung überprüfen – diese ändern sich häufig.

Wir haben uns aus mehreren Gründen für Claude entschieden. Erstens war die Befolgung von Anweisungen für strukturierte Outputs deutlich besser als bei den Alternativen während unseres 500-Datensatz-Tests. Wenn Sie fast 29.000 Datensätze verarbeiten, sparen Sie sogar eine 2%ige Verbesserung der Format-Compliance Ihnen Hunderte von manuellen Korrektionen. Zweitens bot Anthropics Batch API einen 50%igen Rabatt für nicht zeitkritische Arbeiten, was die Wirtschaft noch günstiger machte.

Ehrlich gesagt wäre GPT-4o auch in Ordnung gewesen. Die Unterschiede auf dieser Skala sind eher eine Frage von Rate Limits und Preisgestaltung als von roher Qualität. Aber Claudes Konsistenz bei JSON-Output war der ausschlaggebende Faktor.

Warum wir sowohl Sonnet als auch Haiku verwendeten

Hier ist ein Trick, der uns etwa 40% bei API-Kosten sparte: Wir verwendeten nicht das gleiche Modell für alles. Produktbeschreibungen brauchten Sonnets Qualität. Aber Klassifizierung von Kategorien und Attribut-Extraktion? Haiku handhabte diese zu einem Bruchteil der Kosten.

Wir teilten die Anreicherung in zwei Durchgänge auf:

  1. Durchgang 1 (Haiku): Kategorienklassifizierung, Attribut-Extraktion, grundlegende Metadaten – $0.25/1M Input, $1.25/1M Output
  2. Durchgang 2 (Sonnet): Beschreibungsumschreibung, Meta-Beschreibungen, SEO-Inhalte – $3.00/1M Input, $15.00/1M Output

Prompt Engineering in großem Maßstab

Hier versagen die meisten Tutorials Sie. Sie zeigen Ihnen einen einzelnen Prompt und nennen es einen Tag. Wenn Sie 28.840 Datensätze durch die gleiche Prompt-Vorlage durchlaufen, werden winzige Fehler zu massiven Problemen verstärkt.

Die Prompt-Vorlage

Nach etwa 15 Iterationen (ja, wir verfolgten sie in git), hier ist die grobe Struktur, die funktionierte:

const buildPrompt = (record: SourceRecord): string => `
You are enriching product data for an e-commerce catalog. Generate the following for the product below:

1. A product description (150-300 words, second person, benefit-focused)
2. Exactly 3 category tags from this allowed list: ${CATEGORY_LIST}
3. A meta description (120-155 characters)
4. Structured attributes as key-value pairs

Rules:
- Do NOT invent features not present in the source data
- If information is ambiguous, use the "uncertain" flag
- Match the brand's tone: professional but approachable
- Description must be unique -- do not repeat the title verbatim in the first sentence

Respond ONLY with valid JSON matching this schema:
${JSON_SCHEMA}

Source product data:
Title: ${record.title}
Existing description: ${record.description}
Raw attributes: ${record.attributes}
Price: ${record.price}
Brand: ${record.brand}
`;

Lektionen zu Prompts in großem Maßstab

Seien Sie ungeheuerlich spezifisch über das Output-Format. Wir haben das vollständige JSON-Schema in jede Anfrage eingebunden. Ja, es fügt Token hinzu. Nein, überspringen Sie es nicht. Beim einen Mal, als wir nur auf System-Anweisungen verließen, fiel unsere Format-Compliance von 97% auf 81%.

Beschränken Sie das Output-Vokabular. Für Kategorietags haben wir eine explizite zulässige Liste bereitgestellt. Offene Kategorisierung produzierte 847 eindeutige Kategorien über unseren Test-Batch. Die eingeschränkte Version? Genau die 42, die wir wollten.

Fügen Sie Schutzmaßnahmen gegen Halluzinationen hinzu. Produkte würden gelegentlich Features sprießen, die sie nicht hatten. Das Hinzufügen von „Do NOT invent features not present in the source data" reduzierte halluzinierte Attribute um etwa 70%. Das Hinzufügen des uncertain-Flags fing die meisten der verbleibenden Fälle.

Temperatur ist wichtiger als Sie denken. Wir ließen uns auf 0.3 nieder. Niedriger als das und Beschreibungen wurden sich wiederholend über ähnliche Produkte. Höher und wir bekamen kreatives Schreiben, das nicht der Markensprache entsprach.

Rate Limits, Wiederholungen und die Kunst, nicht gesperrt zu werden

Dieser Abschnitt sollte wirklich „der Teil, der die meiste Engineering-Zeit erforderte" genannt werden. Anthropics Rate Limits sind gut dokumentiert, verhalten sich aber unter anhaltender Last anders als erwartet aus dem Lesen der Docs.

Unsere Rate Limit Strategie

Bei Stufe 2 (die Sie nach Ausgaben von $40+ erhalten), gibt Claude Ihnen 1.000 Anfragen pro Minute und 80.000 Token pro Minute. Klingt großzügig, bis Sie erkennen, dass unsere durchschnittliche Anfrage etwa 1.200 Input-Token und 800 Output-Token war. Das bedeutete unsere praktische Grenze war etwa 40 gleichzeitige Anfragen, bevor Token-Limits getroffen wurden.

Wir führten 5 gleichzeitige Worker aus, jeder verarbeitete einen Datensatz auf einmal, mit einer 200ms Verzögerung zwischen Anfragen. Dies gab uns ungefähr 15-20 Anfragen pro Minute – deutlich unter dem RPM-Limit und komfortabel innerhalb der Token-Budgets.

const rateLimiter = new Bottleneck({
  maxConcurrent: 5,
  minTime: 200, // ms between requests
  reservoir: 900, // requests per minute (leaving buffer)
  reservoirRefreshAmount: 900,
  reservoirRefreshInterval: 60 * 1000,
});

Warum so konservativ? Weil Rate Limits zu kaskadierten Ausfällen führen. Eine 429-Response löst eine Wiederholung aus, die die Warteschlange hinzufügt, was die Parallelität erhöht. Wir haben dies beim ersten echten Durchlauf um 3 Uhr gelernt, als aggressive Einstellungen einen Wiederholungssturm verursachten, der die Pipeline effektiv für 45 Minuten stilllegte.

Die Batch API Alternative

Halbwegs durch das Projekt wechselten wir teilweise zu Anthropics Batch API. Statt einzelne Anfragen zu machen, laden Sie eine JSONL-Datei mit Anfragen hoch und erhalten Ergebnisse innerhalb von 24 Stunden. Der Kompromiss: 50% Kostenreduktion, aber Sie verlieren Echtzeit-Feedback.

Wir verwendeten die Batch API für Durchgang 1 (Haiku-Klassifizierung) und Echtzeit-API für Durchgang 2 (Sonnet-Beschreibungen). Dieser Hybrid-Ansatz war das süße Spot für uns – schnelles Feedback zur teuren kreativen Arbeit, Batch-Wirtschaft zur Waren-Klassifizierung.

Qualitätskontrolle: Die Realität des menschlichen Eingriffs

Wer behauptet, KI-Anreicherung ist vollständig automatisiert, lügt oder hat es nicht in großem Maßstab getan. Wir haben einen QA-Prozess gebaut, der Probleme früh erkannte und verhinderte, dass Müll in die Produktion gelangte.

Automatisierte Validierung

Jede API-Response durchlief eine Validierung, bevor sie akzeptiert wurde:

const validateEnrichment = (result: EnrichmentResult): ValidationOutcome => {
  const issues: string[] = [];
  
  // Length checks
  if (result.description.length < 400 || result.description.length > 2000) {
    issues.push('description_length');
  }
  
  // Category validation
  const invalidCats = result.categories.filter(c => !ALLOWED_CATEGORIES.includes(c));
  if (invalidCats.length > 0) issues.push('invalid_categories');
  
  // Meta description length
  if (result.meta.length > 160) issues.push('meta_too_long');
  
  // Hallucination signals
  const hallucination_phrases = ['I think', 'probably', 'might be', 'as an AI'];
  if (hallucination_phrases.some(p => result.description.includes(p))) {
    issues.push('possible_hallucination');
  }
  
  // Duplicate detection (fuzzy match against already-processed records)
  if (isDuplicateDescription(result.description)) {
    issues.push('duplicate_content');
  }
  
  return {
    valid: issues.length === 0,
    issues,
    needsReview: issues.length > 0 && issues.length < 3,
    rejected: issues.length >= 3,
  };
};

Manuelle Überprüfungs-Stichprobenentnahme

Wir haben 5% aller verarbeiteten Datensätze (etwa 1.440) für manuelle Überprüfung beprobt. Unser QA-Team bewertete jede nach Genauigkeit, Markensprache und Vollständigkeit. Hier sind die Zahlen aus unserer tatsächlichen Überprüfung:

Metrik Bewertung
Faktische Genauigkeit 94,2%
Markensprache-Übereinstimmung 87,6%
Format-Compliance 97,1%
Kategorien-Genauigkeit 91,8%
Datensätze needing revision 8,3%
Datensätze vollständig abgelehnt 1,9%

Diese 8,3%, die überarbeitet benötigen, ist wichtiger Kontext. Das bedeutet, etwa 2.400 Datensätze benötigten menschliche Bearbeitung. Immer noch viel weniger als alle 28.840 manuell zu schreiben – aber es ist nicht Null. Budget dafür.

Echte Kostenaufschlüsselung

Zeit für Transparenz. Hier ist, was wir tatsächlich ausgegeben haben:

Kostenkategorie Betrag
Claude 3.5 Haiku (Durchgang 1 - Batch API) $312
Claude 3.5 Sonnet (Durchgang 2 - Echtzeit) $2.147
Fehlgeschlagene/Wiederholungsanfragen (~6% Overhead) $189
Redis-Hosting (2 Wochen) $15
Engineering-Zeit (80 Stunden × $150) $12.000
QA-Überprüfungszeit (40 Stunden × $45) $1.800
Gesamt $16.463
Nur API-Kosten $2.648

Vergleichen Sie das mit der $134.575-Schätzung für vollständig manuelle Arbeit. Selbst unter Berücksichtigung aller Engineering- und QA-Zeit liegen wir bei etwa 12% der manuellen Kosten. Und die Pipeline ist wiederverwendbar – das nächste Mal, wenn wir ein ähnliches Projekt durchführen, sinken die Engineering-Kosten auf nahe Null.

Die API-Kosten pro Datensatz betrug etwa $0.092. Unter einem Dollar pro Datensatz für KI-Anreicherung. Das ist die Nummer, die Führungskräfte zum Aufhorchen bringt.

Was wir falsch gemacht haben

Datenbereinigung unterschätzt

Wir haben 3 Tage nur mit der Bereinigung der Quelldaten verbracht, bevor wir sie an Claude schickten. Datensätze hatten HTML-Entities, Unicode-Müll, abgeschnittene Beschreibungen und Felder in den falschen Spalten. Garbage in, Garbage out ist nicht nur ein Klischee – es ist das Grundgesetz der Massen-KI-Verarbeitung.

Batch API nicht von Anfang an verwendet

Wir haben etwa $400 extra in API-Kosten verbrannt, indem wir Durchgang 1 durch die Echtzeit-API liefen, bevor wir herausfanden, dass die Batch API halb so viel gekostet hätte. Lesen Sie die vollständige Dokumentation, bevor Sie beginnen. Alle davon.

Unzureichende Duplikatvermeidung

Unsere initiale Duplikatvermeidung war zu naiv – einfaches String-Matching. Claude würde Beschreibungen generieren, die strukturell identisch waren, aber etwas unterschiedliche Wörter für ähnliche Produkte verwendeten. Wir mussten Semantik-Ähnlichkeits-Überprüfung (unter Verwendung von Embeddings) implementieren, um diese zu erfassen, was einen Tag Arbeit hinzufügte.

JSON-Parsing Fehler

Etwa 2,4% der Responses kamen mit malformiertem JSON zurück. Manchmal ein nachfolgendes Komma, manchmal ein unverescaptes Anführungszeichen in einer Produktbeschreibung. Wir hätten einen nachsichtigeren JSON-Parser von Anfang an implementieren sollen, statt diese als harte Fehler zu behandeln.

// What we should have done from day one
const parseResponse = (raw: string): EnrichmentResult | null => {
  try {
    return JSON.parse(raw);
  } catch {
    // Try to extract JSON from markdown code blocks
    const jsonMatch = raw.match(/```json?\n?([\s\S]*?)\n?```/);
    if (jsonMatch) {
      try { return JSON.parse(jsonMatch[1]); } catch { /* fall through */ }
    }
    // Try jsonrepair library as last resort
    try { return JSON.parse(jsonrepair(raw)); } catch { return null; }
  }
};

Was wir beim nächsten Mal anders machen würden

  1. Starten Sie mit einem 1.000-Datensatz-Piloten, bevor Sie sich auf den ganzen Lauf verpflichten. Wir haben 500 gemacht und das war nicht genug, um alle Sonderfälle zu zeigen.

  2. Verwenden Sie strukturierte Outputs von Anfang an. Anthropic unterstützt jetzt Tool-Nutzung mit definierten Schemas, was die meisten JSON-Parsing-Probleme eliminiert. Wir migrierten halbwegs durch und wünschten, wir hätten dort begonnen.

  3. Bauen Sie das QA-Dashboard zuerst. Wir bauten es reaktiv, nachdem Probleme auftauchten. Es von Anfang an zu haben, hätte Probleme in den ersten 100 Datensätzen statt den ersten 2.000 erfasst.

  4. Investieren Sie in bessere Embeddings für Dedup. Wir würden ein dedizierten Embedding-Modell (wie text-embedding-3-small) von Anfang an für semantische Duplikatvermeidung verwenden.

  5. Erwägen Sie Hybrid-Modell-Routing. Einige Datensätze sind einfach (T-Shirts mit grundlegenden Attributen) und einige komplex (Elektronik mit Dutzenden Spezifikationen). Routing einfacher Datensätze zu Haiku und komplexer zu Sonnet – sogar für Beschreibungen – hätte weitere 20-30% bei API-Kosten gespart.

Falls Sie ein ähnliches Projekt planen und die schmerzhaften Teile überspringen möchten, haben wir wiederverwendbare Pipelines für diese Art von Arbeit als Teil unserer Headless CMS-Entwicklung gebaut. Gerne teilen Sie mehr Besonderheiten.

FAQ

Wie lange dauert es, 28.000+ Datensätze mit KI anzureichern?

Unsere tatsächliche Verarbeitungszeit betrug etwa 11 Tage, einschließlich Pipeline-Entwicklung, Tests, Verarbeitung und QA-Überprüfung. Die API-Verarbeitung selbst (Anfragen senden und Responses erhalten) dauerte grob 48 Stunden kontinuierliches Laufen. Falls Sie ausschließlich die Batch API verwenden, erwarten Sie 24-48 Stunden für die Verarbeitung plus 3-5 Tage für Engineering und QA.

Wie hoch sind die Kosten pro Datensatz für KI-Inhaltserweiterung?

Mit Claude 3.5 Sonnet und Haiku in Kombination betrugen unsere API-Kosten ungefähr $0.092 pro Datensatz für die Generierung einer Produktbeschreibung, Kategorien, Meta-Beschreibung und strukturierte Attribute. Ihre Ergebnisse variieren je nach Ein-/Ausgabelängen und welchem Modell Sie wählen. Batch API-Verarbeitung schneidet dies grob in die Hälfte.

Ist Claude oder GPT-4 besser für die Massen-Datenerweiterung?

Beide funktionieren gut. Wir wählten Claude 3.5 Sonnet wegen seiner überlegenen JSON-Format-Compliance während unserer Tests (97,1% vs ~94% für GPT-4o). Allerdings ist GPT-4o leicht günstiger für Output-Token. Falls Ihre Anreicherung eher Klassifizierung als Inhaltsgeneration ist, ist der Unterschied unbedeutend. Testen Sie beide mit 500 Datensätzen, bevor Sie sich verpflichten.

Wie behandeln Sie Rate Limits bei Tausenden API-Aufrufen?

Verwenden Sie eine Rate Limiter-Bibliothek wie Bottleneck, setzen Sie konservative Parallelität (5-10 parallele Anfragen), implementieren Sie exponentielles Backoff für Wiederholungen und lassen Sie einen 10-15% Buffer unter veröffentlichten Rate Limits. Für zeitunkritische Arbeiten vermeidet Anthropics Batch API Rate Limit-Bedenken vollständig und kostet 50% weniger.

Welcher Prozentsatz von KI-angereicherten Datensätzen benötigt menschliche Überprüfung?

In unserem Projekt benötigten 8,3% der Datensätze irgendeine Form von menschlicher Bearbeitung und 1,9% wurden vollständig abgelehnt und manuell umgeschrieben. Ihre Zahlen hängen von der Datenqualität, Prompt Engineering und akzeptablen Qualitätsschwellen ab. Planen Sie 5-15% menschlichen Eingriff als realistischen Baseline.

Kann KI-Massenanreicherung mehrere Sprachen verarbeiten?

Ja, aber die Qualität variiert erheblich je nach Sprache. Claude und GPT-4 handhaben große europäische Sprachen gut, aber Genauigkeit fällt für weniger häufige Sprachen. Wir empfehlen, separate Prompt-Vorlagen pro Sprache auszuführen und muttersprachliche Sprecher in Ihrer QA-Stichprobe zu haben. Erwarten Sie, dass der menschliche Überprüfungsprozentsatz für nicht-englische Inhalte ungefähr verdoppelt wird.

Wie verhindern Sie KI-Halluzinationen in Produktdaten?

Drei Schichten: Prompt-Anweisungen, die Erfindungen von Features explizit verbieten, ein „uncertain"-Flag für mehrdeutige Daten und automatisierte Validierung, die bereicherte Attribute gegen Quelldaten vergleicht. Wir verwendeten auch Semantik-Ähnlichkeits-Scoring, um Beschreibungen zu kennzeichnen, die zu weit von den ursprünglichen Produktinformationen abwichen. Dies reduzierte halluzinierte Attribute um ungefähr 70%.

Lohnt es sich, eine benutzerdefinierte Pipeline zu bauen oder sollte ich ein vorhandenes Werkzeug verwenden?

Für unter 1.000 Datensätze können Werkzeuge wie Clay, Bardeen oder sogar ein gut strukturiertes Google Sheets + Apps Script-Setup funktionieren. Darüber hinaus zahlt sich eine benutzerdefinierte Pipeline schnell selbst aus. Die Kontrolle über Wiederholungslogik, Qualitätsvalidierung und Kostenoptimierung, die eine benutzerdefinierte Lösung bietet, ist essentiell in großem Maßstab. Unsere Pipeline war ungefähr 2.000 Zeilen TypeScript – nicht trivial, aber auch nicht ein massives Projekt. Überprüfen Sie unsere Preisseite, falls Sie möchten, dass wir eine für Ihren Anwendungsfall bauen.