Ein Crowd-Job ohne Input Data ist ein statischer Survey: Jeder Worker sieht dieselben Fragen mit demselben fixen Text. Das funktioniert für eine Handvoll Aufgabentypen, aber die meisten sinnvollen Crowd-Annotationen erfordern, dass jeder Worker ein spezifisches Inhaltselement beurteilt — einen bestimmten Nachrichtenartikel, ein bestimmtes Bild, eine Produktbeschreibung aus einer bekannten Quelle. Input Data ist der Mechanismus, der diese per-Worker-Variabilität einbringt.
Man erstellt ein Input-Data-Set aus einem Batch von Quellinhalten — etwa 500 Nachrichtenartikel — und hängt es an einen Crowd-Job an, sodass Workern je ein Artikel zugewiesen werden kann. Sets können auf ein einzelnes Projekt beschränkt oder organisationsweit geteilt werden, sodass dieselbe Inhaltsbibliothek mehrere Jobs über die Zeit hinweg versorgen kann. Die genaue API-Referenz findet sich unter docs.crowdee.ai.
Inhaltlich ist Input Data in vier verschachtelten Ebenen organisiert, jede mit einer spezifischen Rolle.
| Ebene | Rolle |
|---|---|
| Set | Übergeordneter benannter Container für einen Batch von Inhalten, verknüpft mit der Organisation oder einem Projekt |
| Liste | Eine benannte Liste innerhalb eines Sets; ein Set kann mehrere Listen enthalten |
| Gruppe | Eine Gruppe von Varianten, die dasselbe reale Element repräsentieren |
| Variante | Eine Darstellung des Elements (z. B. verschiedene Sprachen oder Formate) |
Eine Gruppe kann in mehreren Listen gleichzeitig vorkommen, sodass derselbe Inhalt über verschiedene Gruppierungen hinweg wiederverwendet werden kann, ohne ihn zu duplizieren.
Auf der Variantenebene befinden sich die eigentlichen Inhalte. Eine Gruppe, die einen Nachrichtenartikel repräsentiert, könnte zwei Varianten haben: den englischen Originaltext und eine maschinell übersetzte deutsche Version. Ein Worker, der dieser Gruppe zugewiesen wird, bekommt eine Variante; welche er bekommt, wird zuverlässig nachgehalten. Das ermöglicht es, dasselbe zugrunde liegende Element in verschiedenen Formen verschiedenen Workern zu präsentieren oder dieselbe Form job-übergreifend wiederzuverwenden, ohne den Inhalt zu duplizieren.
Beim Erstellen eines Crowd-Jobs verknüpft man ihn mit einem Input-Data-Set. Crowdee weist Workern dann Gruppen aus diesem Set zu. Bei der Zuweisung wird der Task jedes Workers an einen Snapshot des genauen Inhalts gebunden, der ihm gezeigt wurde — keine lebende Referenz darauf. Dieser Snapshot ist unveränderlich: Auch wenn das Input-Data-Set später bearbeitet wird, spiegelt der Task des Workers immer das wider, was er tatsächlich gesehen hat.
Jobs können so konfiguriert werden, dass niemals zwei Worker derselben Gruppe zugewiesen werden — die richtige Einstellung für Annotationsaufgaben, bei denen jedes Inhaltselement unabhängig beurteilt werden soll, ohne dass sich Worker gegenseitig beeinflussen. Alternativ kann dieselbe Gruppe bewusst mehreren Workern zugewiesen werden — nützlich, wenn man mehrere unabhängige Urteile über dasselbe Element für eine Inter-Annotator-Agreement-Analyse möchte.
Eine feinere Option erlaubt es, zu begrenzen, wie oft eine bestimmte Gruppe über alle Worker hinweg wiederverwendet werden darf, ohne zu verlangen, dass jede Gruppe genau einmal zugewiesen wird. Das ist nützlich, wenn das Input-Data-Set kleiner als die Zielannotationszahl ist oder wenn eine gewichtete Abdeckung bestimmter Gruppen gewünscht wird.
Der vollständige Per-Task-Variationsmechanismus funktioniert wie folgt: Das Survey-Template enthält Platzhalter für die Inhaltselemente, die variieren sollen (zum Beispiel einen Platzhalter für den Beitragstext und einen für die Quell-URL). Die Input-Data-Variante der zugewiesenen Gruppe enthält passende Werte für diese Platzhalter. Bei der Task-Zuweisung lädt Crowdee das Survey-Template, ersetzt die Platzhalter durch die Werte der Variante und legt das Ergebnis als Task des Workers fest. Der Survey des Workers wird aus dieser festgelegten Version gerendert, nicht aus dem Live-Template oder den Live-Input-Daten.
Diese Trennung ist wichtig: Die festgelegte Version dokumentiert, was der Worker tatsächlich gesehen hat, was für eine reproduzierbare Qualitätsanalyse unerlässlich ist. Wenn man später verstehen möchte, warum ein bestimmter Worker eine unerwartete Antwort gegeben hat, kann man sich den genauen Survey ansehen, den er bekommen hat — keine rekonstruierte Version.
Die Platzhalter-Substitution funktioniert auch für strukturierte Inhalte. Eine Variante kann mehrere zusammengehörige Felder auf einmal enthalten — etwa eine Überschrift, einen Fließtext und ein Veröffentlichungsdatum — und das Template kann auf jedes Feld unabhängig referenzieren. Das hält Varianten auch bei reichhaltigeren Inhaltstypen einfach zu erstellen und nachzuvollziehen.
Eine der mächtigeren Funktionen der Crowd-Pipeline ist die Möglichkeit, akzeptierte Crowd-Antworten als Input-Daten für einen nachfolgenden Job zu verwenden. Crowdee kann die akzeptierten Antworten eines abgeschlossenen Jobs direkt in ein neues Input-Data-Set umwandeln.
Das schafft eine Rückkopplungsschleife: Job A bittet Worker, Audioclips zu transkribieren. Die akzeptierten Transkriptionen werden in ein Input-Data-Set umgewandelt. Job B bittet eine andere Gruppe von Workern, diese Transkriptionen zu überprüfen und zu korrigieren, wobei sie als variierender Inhalt im Review-Survey verwendet werden. Das Ergebnis von Job B ist ein qualitativ hochwertigeres Transkriptionsset. Dieses Pipeline-Muster — generieren in Job A, überprüfen in Job B — ist für jeden Inhaltstyp wiederverwendbar, bei dem Crowd-Generierung und Crowd-Überprüfung separate Schritte sind.
Akzeptierte Antworten lassen sich auch in einen Datensatz statt in ein Input-Data-Set umwandeln — nützlich, wenn der Antwortinhalt in eine breitere Datenpipeline statt in einen weiteren Crowd-Job fließen soll. In beiden Fällen werden nur akzeptierte Antworten verwendet — ausstehende und abgelehnte Antworten werden automatisch herausgefiltert. Die vollständigen Optionen finden sich unter docs.crowdee.ai.
Artikel teilen:
