JieGou liefert Starter-Pakete für neun Abteilungen, jeweils mit 7-10 Recipes und 2-5 Workflows. Das sind ungefähr 150 Recipes und 40 Workflows. Jedes einzelne von Hand zu schreiben, mit realistischen Eingaben zu testen, die Ausgabequalität zu bewerten und zu iterieren, bis es gut genug zum Ausliefern ist — das ist ein Vollzeitjob für ein Team.
Wir brauchten einen besseren Ansatz. Also haben wir die Recipe Factory gebaut: eine automatisierte Pipeline, die Templates im großen Maßstab generiert, testet, bewertet und promotet.
Die Pipeline
Die Recipe Factory durchläuft fünf Phasen:
1. Katalog → Generieren
Jedes Recipe beginnt als Spezifikation im Katalog: ein Titel, eine Beschreibung, die Zielabteilung, erwartete Eingabefelder, erwartete Ausgabefelder und Qualitätskriterien. Der Katalog enthält derzeit ~150 Recipe-Spezifikationen über 9 Abteilungen.
Die Generierungsphase nimmt jede Spezifikation und verwendet ein LLM, um ein vollständiges Recipe zu produzieren: ein ausgearbeitetes Prompt-Template, ein detailliertes Eingabeschema mit Feldbeschreibungen und ein strukturiertes Ausgabeschema. Das LLM folgt einem Meta-Prompt, der unsere Standards für Recipe-Qualität kodiert — klare Anweisungen, angemessener Detailgrad und Schema-Best-Practices.
2. Generieren → Testdaten
Für jedes generierte Recipe produziert ein zweiter LLM-Aufruf 3-5 synthetische Testeingaben. Diese decken den typischen Fall, Randfälle (minimale Eingabe, ungewöhnlich lange Eingabe, mehrdeutige Eingabe) und abteilungsspezifische Szenarien ab. Die Testeingaben sind realistisch genug, um bedeutungsvolle Ausgaben zu produzieren, ohne echte Kundendaten zu benötigen.
3. Testdaten → Tests ausführen
Jedes Recipe wird gegen ein echtes LLM mit den synthetischen Testeingaben ausgeführt. Dies fängt Probleme ab, die im Template gut aussehen, aber zur Laufzeit scheitern: Schema-Unstimmigkeiten, Prompts, die Off-Target-Ausgaben produzieren, Templates, die Kontextlimits überschreiten, und Anweisungen, die das Modell anders interpretiert als beabsichtigt.
4. Tests ausführen → Bewerten
Hier kommt LLM-as-Judge ins Spiel. Ein separates LLM bewertet jedes Testergebnis über fünf Dimensionen:
- Schema-Compliance — Entspricht die Ausgabe dem erwarteten Schema? Sind alle erforderlichen Felder vorhanden und korrekt typisiert?
- Vollständigkeit — Behandelt die Ausgabe alle Aspekte der Eingabe? Gibt es Lücken oder fehlende Abschnitte?
- Handlungsfähigkeit — Ist die Ausgabe nützlich? Kann eine Person darauf reagieren, ohne erhebliche zusätzliche Arbeit?
- Formatqualität — Ist die Ausgabe gut organisiert, klar geschrieben und angemessen detailliert?
- Konsistenz — Produziert das Recipe über mehrere Testeingaben hinweg konsistent strukturierte Ausgaben?
Jede Dimension erhält eine Bewertung von 0-100. Die Gesamtbewertung ist ein gewichteter Durchschnitt.
5. Bewerten → Promoten
Recipes, die insgesamt 75+ erreichen, ohne dass eine Dimension unter 50 liegt, werden in das Demo-Konto in Firestore promotet. Recipes, die durchfallen, werden für manuelle Überprüfung und Iteration markiert.
Was LLM-as-Judge uns lehrte
Der Aufbau eines automatisierten Qualitätsbewertungssystems brachte mehrere nicht-offensichtliche Erkenntnisse.
Prompt-Spezifität ist wichtiger als Länge. Frühe Recipe-Templates waren lang und detailliert. Der LLM-as-Judge bewertete kürzere, spezifischere Prompts konsistent höher bei Schema-Compliance und Formatqualität. Ein 200-Wörter-Prompt, der genau sagt, was zu tun ist, übertrifft einen 500-Wörter-Prompt, der jeden Randfall abdeckt. Das Modell folgt klaren Anweisungen besser als umfassenden Anweisungen.
Ausgabeschemata sind der wichtigste Qualitätshebel. Recipes mit detaillierten Ausgabeschemata — Feldbeschreibungen, Enum-Constraints, verschachtelte Objektstrukturen — erzielten signifikant höhere Bewertungen bei Vollständigkeit und Konsistenz. Das Schema fungiert als zweiter Satz von Anweisungen, der die Ausgabe des Modells unabhängig vom Prompt einschränkt.
Randfall-Testeingaben offenbaren Fragilität. Der Standardtestfall funktioniert normalerweise. Die Randfälle — minimale Eingabe, ungewöhnliche Formatierung, fehlende optionale Felder — enthüllen Recipes, die unter realen Bedingungen brechen. Ein Recipe, das 90 beim typischen Fall erzielt, aber 40 bei Randfällen, ist nicht produktionsreif.
Bewertungskriterien brauchen Kalibrierung. Unser erster Durchlauf der LLM-as-Judge-Bewertung war zu nachsichtig. Recipes erzielten 85+, die mittelmäßige Ausgaben produzierten. Wir verschärften den Bewertungs-Prompt mit spezifischen Beispielen, wie jede Bewertungsstufe aussieht. “Handlungsfähigkeit” bei 80+ bedeutet, dass die Ausgabe spezifische nächste Schritte enthält, nicht nur Analyse. “Formatqualität” bei 80+ bedeutet klare Überschriften, konsistente Struktur und angemessene Länge.
Abteilungsübergreifende Konsistenz erfordert gemeinsame Standards. Ein Sales-Prospect-Research-Recipe und ein HR-Lebenslauf-Screening-Recipe extrahieren beide strukturierte Daten aus unstrukturierter Eingabe. Die Qualitätslatte sollte die gleiche sein. Wir standardisierten Bewertungskriterien über Abteilungen hinweg, sodass die Factory konsistente Standards unabhängig von der Domäne des Recipes anwendet.
Die Workflow Factory
Nachdem die Recipe Factory sich als effektiv erwiesen hatte, bauten wir eine äquivalente Pipeline für Workflows. Die Workflow Factory generiert mehrstufige Workflows aus Spezifikationen, erstellt Testeingaben, die den gesamten Workflow ausüben (einschließlich Bedingungsverzweigungen und Schleifeniterationen), führt sie End-to-End aus und bewertet die zusammengesetzte Ausgabe.
Die Workflow-Bewertung ist schwieriger als die Recipe-Bewertung, weil die Qualität davon abhängt, wie gut die Schritte zusammen verketten, nicht nur von der individuellen Schrittqualität. Ein Workflow, bei dem jeder Schritt individuell 85 erzielt, könnte insgesamt 60 erzielen, wenn die Daten nicht sauber zwischen Schritten fließen. Die Bewertungskriterien umfassen Inter-Schritt-Datenintegrität und Gesamtkohärenz.
Die Factory ausführen
Die gesamte Pipeline wird mit einem einzigen Befehl ausgeführt: npm run recipe-factory. Sie nimmt die Katalogspezifikationen, generiert Recipes, erstellt Testdaten, führt Tests aus, bewertet Ergebnisse und promotet bestandene Recipes in das Demo-Konto.
Einzelne Phasen können separat für Iteration ausgeführt werden:
npm run generate-recipes— Recipes aus Katalogspezifikationen regenerierennpm run generate-test-inputs— Neue Testdaten erstellennpm run run-recipe-tests— Recipes gegen LLM ausführennpm run evaluate-recipes— Die Ergebnisse bewertennpm run promote-recipes— Bestandene Recipes nach Firestore pushen
Diese Modularität ermöglicht es uns, an einer bestimmten Phase zu iterieren, ohne die gesamte Pipeline neu auszuführen.
Warum das für Benutzer wichtig ist
Die Recipe Factory ist ein internes Tool, aber ihre Auswirkungen sind benutzerseitig. Jedes Recipe in einem Starter-Paket wurde:
- Aus einer Spezifikation generiert, die Qualitätskriterien definiert
- Mit realistischen Eingaben einschließlich Randfällen getestet
- Von einem LLM-Judge über fünf Qualitätsdimensionen bewertet
- Nur promotet, wenn es den Qualitätsschwellenwert erreicht
Wenn Sie ein Starter-Paket installieren, sind die Recipes keine Rohentwürfe. Sie haben eine automatisierte Qualitätspipeline durchlaufen, die die häufigsten Probleme abfängt, bevor sie Sie erreichen.
Das heißt, sie sind Ausgangspunkte. Die spezifische Terminologie, Qualitätsstandards und Ausgabepräferenzen Ihres Teams sind Dinge, die die Factory nicht wissen kann. Die Recipes sind so konzipiert, dass sie angepasst werden können — die Factory stellt sicher, dass sie mit einem hohen Ausgangsniveau beginnen, sodass Ihre Anpassung Verfeinerung ist, nicht Behebung.