WorkFactory soll Trainingsaufgaben für Arbeitsagenten systematisch absichern

Probe-Ausführung als Qualitätskontrolle

Nach der Materialisierung lässt WorkFactory die Aufgabe von einem Probe-Solver mit denselben für den späteren Agenten sichtbaren Informationen bearbeiten. Der Probe-Solver erhält laut Beschreibung weder den Informationsgraphen noch den Konstruktionsplan oder frühere Diagnosen. Er soll also aus der tatsächlichen Arbeitsumgebung heraus feststellen, ob ein Problem vorliegt, statt lediglich die interne Spezifikation abzugleichen. Berücksichtigt werden sollen Hindernisse, die die Aufgabenerledigung tatsächlich blockieren, nicht legitime offene Entscheidungen oder Fehler des Probe-Solvers. [5]

Bei einem festgestellten Informationsmangel kann ein Refiner den Auftrag oder vorhandene Referenzdateien überarbeiten. Die Änderung muss den ursprünglichen Arbeitszweck und die wesentlichen Arbeitsschritte erhalten. Im Beispiel kann eine fehlende Frachtkostenangabe ergänzt werden; die eigentliche Kostenrechnung wird nicht für den Agenten erledigt. Jede Überarbeitung durchläuft erneut Konstruktionsprüfungen und eine Prüfung, ob die ursprüngliche Arbeit erhalten blieb. Danach folgt eine neue Probe-Ausführung. Aufgaben mit ungelösten Blockaden oder nicht bestandenen Prüfungen werden verworfen. [5]

Die Reparaturschleife adressiert eine Schwäche, die eine reine Prüfung von Aufgabenplänen nicht notwendigerweise erfasst: Ein geplanter Informationsbaustein kann beim Erzeugen von Dateien fehlen oder mit Angaben in einem anderen Dokument kollidieren. Die Autoren berichten, dass Planung und Reparatur in kontrollierten Komponentenanalysen die durch Probes diagnostizierten Umgebungsfehler verringern und die nachgelagerte Modellleistung verbessern. Die verfügbaren Auszüge nennen dafür jedoch keine Effektgrößen, anhand derer sich der Beitrag der einzelnen Komponenten beziffern ließe. [2][5]

112.686 Aufgaben über 612 Berufe

Mit WorkFactory erstellten die Autoren nach eigenen Angaben 112.686 Aufgaben, die 612 Berufe abdecken. Der Datensatz umfasst 53 Ziel-Dateiendungen, sofern eine Endung mindestens zehnmal vorkommt; bei den Referenzdateien zählen sie 317 Endungen nach derselben Mindesthäufigkeit. Im Durchschnitt enthält eine Aufgabe 4,15 bereitgestellte Referenzdateien mit einer mittleren Größe von 1,56 MiB. Ein Teil der Aufgaben kommt ohne solche Dateien aus und setzt stattdessen voraus, dass der Agent benötigte Informationen über eine Websuche beschafft. [2][5]

Die Teacher-Trajektorien sind umfangreich: Die Autoren geben im Mittel 57,36 Assistant-Turns und 62,95 Tool-Aufrufe pro Trajektorie an. Der durchschnittliche Gesamtumfang wird mit 136,18 Tausend Tokens ausgewiesen. Die Zielergebnisse verteilen sich auf unterschiedliche Büroformate; in den verfügbaren Angaben gehören Tabellen, PDF- und Textdokumente sowie Präsentationen dazu. Das deutet auf Aufgaben hin, die mehrere Arbeitsschritte und Werkzeuge verbinden, nicht nur auf kurze Frage-Antwort-Beispiele. [4][5]

Die Trajektorien wurden laut Paper mit einem unabhängigen Teacher gesammelt; der Methodenauszug nennt dafür GLM-5.3. Auf ihnen wurden die WorkPilot-Modelle durch überwachte Feinabstimmung trainiert. Die im Paper aufgeführten Größen sind Qwen3.5-4B, Qwen3.6-27B und Qwen3.6-35B-A3B. Die Zusammenfassung nennt drei Größen, belegt aber nicht, dass eine vergleichbare Produktivumgebung oder ein vollständig unabhängiger Datensatz verwendet wurde. [2][4][5]

Berichtete Zuwächse auf vier Benchmarks

Nach Darstellung der Autoren verbessern sich alle drei WorkPilot-Modelle gegenüber ihren jeweiligen Basismodellen auf vier Benchmarks für professionelle Arbeit. Für WorkPilot-35B-A3B weist die im Paper wiedergegebene Benchmarkgrafik folgende Werte aus: auf GDPval-AA v2.1 einen Anstieg von 879 auf 1.565 Elo, auf JobBench von 28,9 auf 62,4, auf WorkspaceBench von 47,1 auf 56,5 und auf OmegaUse-OfficeVal von 7,1 auf 21,2. Die Skalen sind nicht einheitlich; insbesondere sollten die Zahlen der verschiedenen Tests nicht direkt miteinander verglichen werden. [2][4]

Die Ergebnisse stützen innerhalb der Studie die These, dass die aus WorkFactory gewonnenen Demonstrationen für das Feintuning nützlich sind. Sie belegen aber nicht ohne Weiteres, wie sich die Modelle in realen Unternehmensprozessen verhalten. Die vorliegenden Quellen dokumentieren Autorenangaben aus dem Paper, nicht eine unabhängige Nachprüfung der Aufgaben, Auswertungen oder Einsatzbedingungen. Auch lässt sich aus den Benchmarkwerten allein nicht ableiten, wie zuverlässig ein Modell mit abweichenden Datenformaten, betrieblichen Zugriffsrechten oder organisationsspezifischen Regeln umgeht. Das sind offene Fragen für eine Übertragung in den Betrieb. [2][4]

Zusätzlich berichten die Autoren, WorkPilot-27B erreiche auf GDPval-AA v2.1 eine lokal geschätzte Elo-Zahl von 1.612. Die verfügbare Beschreibung erläutert die Messbedingungen dieser Schätzung nicht näher. Deshalb lässt sich der Wert nicht als belastbarer Beleg dafür verwenden, dass das 27B-Modell dem 35B-Modell überlegen ist: Die berichteten Zahlen sollten nicht als kontrollierter Größenvergleich gelesen werden, solange die Vergleichbarkeit der Messungen nicht geklärt ist. [4][5]

Skalierung bringt nicht durchgehend lineare Effekte

Die Arbeit untersucht außerdem, wie sich Leistung und Ausführungsverhalten verändern, wenn die Trainingsdatenmenge wächst. Die Autoren berichten von modellabhängig abnehmenden Zusatzgewinnen. Auch die Länge der Ausführungen steigt laut Abstract zunächst und sinkt danach wieder. Zuverlässigkeit bei der Werkzeugnutzung verändert sich ebenfalls; für diese Veränderung enthält die vorliegende Zusammenfassung jedoch keine Richtung oder konkreten Zahlen. [2][5]

Für die betriebliche Planung ist diese Beobachtung ein Hinweis, dass mehr synthetische Aufgaben nicht automatisch proportional bessere Agenten hervorbringen. Der Nutzen kann von der Modellgröße und dem Umfang der bereits vorhandenen Daten abhängen. Die bereitgestellten Quellen erlauben keine quantitative Aussage darüber, ab welcher Datensatzgröße der Grenznutzen sinkt oder welche Kosten für Erzeugung, Probe-Ausführung und Teacher-Trajektorien anfallen. Unternehmen müssten diese Größen deshalb für ihre eigenen Aufgaben, Modelle und Qualitätsanforderungen gesondert messen. Diese Schlussfolgerung ist eine Analyse der beschriebenen Skalierungsbefunde. [2][5]

Nutzen und Grenzen für Unternehmen

Der Ansatz ist für Organisationen interessant, die Agenten nicht nur auf allgemeine Sprachaufgaben, sondern auf mehrstufige digitale Arbeit vorbereiten. Die explizite Zuordnung von Informationen zu Arbeitsschritten könnte die Erstellung konsistenter Trainingsumgebungen strukturieren. Die Probe-Ausführung fügt eine Qualitätsstufe hinzu, die gezielt nach fehlenden oder widersprüchlichen Angaben sucht, bevor Demonstrationen in den Trainingsbestand gelangen. Beides adressiert Probleme, die bei Aufgaben mit mehreren Dateien, Berechnungen und Ergebnissen entstehen können. [2][5]

Das Verfahren hat zugleich einen eigenen Prüfaufwand: Absichten müssen erzeugt und bewertet, Umgebungen materialisiert, Aufgaben probeweise ausgeführt und Änderungen erneut kontrolliert werden. Der Paper-Auszug beschreibt mehrere Sprachmodell- und Prüfkomponenten, beziffert aber weder deren Betriebskosten noch den Anteil verworfener Aufgaben. Auch die berichteten Diagnosen beruhen auf einem Probe-Solver und Sprachmodellprüfungen; aus den verfügbaren Angaben geht nicht hervor, wie oft diese Prüfungen selbst Fehler übersehen oder unnötige Reparaturen auslösen. Für einen Unternehmenseinsatz wären daher zusätzlich manuelle Stichproben und domänenspezifische Abnahmekriterien zu erwägen. Die letzte Empfehlung ist eine Analyse, keine berichtete Studienfeststellung. [5]

Die Autoren erklären, einen Teil der Aufgabendaten und die Modellgewichte öffentlich bereitzustellen. Das ist von einer vollständigen Veröffentlichung des gesamten Korpus zu unterscheiden: Im Methodenabschnitt ist ausdrücklich von einem Teilbestand die Rede. Die Hugging-Face-Seite verweist auf ein Projektarchiv, doch die mitgelieferten Informationen enthalten keine unabhängige Prüfung von Umfang, Lizenzdetails oder Reproduzierbarkeit der dort verfügbaren Dateien. [1][5]

Vorläufiger Forschungsstand

Das Paper liegt als arXiv-Version 1 vor; die arXiv-Seite nennt den 27. Oktober 2026 als Einreichungsdatum. Eine externe Begutachtung ist in den verfügbaren Quellen nicht belegt. Zudem unterscheiden sich die Plattformangaben zur Datierung: Hugging Face führt eine Veröffentlichung am 26. Oktober und eine Einreichung auf der Plattform am 30. Oktober auf, während arXiv den 27. Oktober als Einreichung nennt. Die Angaben beziehen sich auf unterschiedliche Plattformmetadaten und sollten nicht zu einem einheitlichen Veröffentlichungsdatum zusammengezogen werden. [1][2][4]

Insgesamt liefert WorkFactory eine systematische Methode, um professionelle Trainingsaufgaben nicht nur zu erzeugen, sondern ihre Informationsbasis vor der Sammlung von Demonstrationen zu prüfen. Die berichteten Benchmarkgewinne sind ein positives Ergebnis der Autoren, bleiben aber zunächst an die beschriebenen Modelle, Aufgaben und Auswertungen gebunden. Für die Entscheidung, ob sich das Verfahren auf konkrete Arbeitsabläufe übertragen lässt, wären veröffentlichte Details zu Kosten, Prüfqualität und unabhängigen Tests ebenso wichtig wie die Größe des Korpus. [2][4][5]

Quellen

1. [1] Paper page - WorkFactory: Turning Professional Intents into Executable Work for Scalable Agent Training — https://huggingface.co/papers/2610.37161 (abgerufen am 2026-10-30)
2. [2] [2610.37161] WorkFactory: Turning Professional Intents into Executable Work for Scalable Agent Training — https://arxiv.org/abs/2610.37161 (abgerufen am 2026-10-30)
3. [4] (PDF) WorkFactory: Turning Professional Intents into Executable Work for Scalable Agent Training — https://www.researchgate.net/publication/417009202_WorkFactory_Turning_Professional_Intents_into_Executable_Work_for_Scalable_Agent_Training (abgerufen am 2026-10-30)
4. [5] WorkFactory: Turning Professional Intents into Executable Work for Scalable Agent Training — https://arxiv.org/html/2610.37161 (abgerufen am 2026-10-30)