Eine GDPVal-Aufgabe unter der Lupe – Wenn das Modell denken und Dokumente liefern muss

Die GDPVal-Aufgabe zur Interview-Terminplanung liegt genau dazwischen: zu strukturiert für einen einfachen Chat-Prompt, zu klein für einen Enterprise-Workflow — eingegrenzte Wissensarbeit, die eine kompetente Person in einer Sitzung erledigen könnte.

Über GDPVal

GDPVal ist OpenAIs Benchmark, um Modellleistung an ökonomisch relevanter, realer Wissensarbeit zu messen — statt an synthetischen akademischen Aufgaben. OpenAI beschreibt es als Evaluation über realistische berufliche Aufgaben, mit einem öffentlichen Leaderboard und einem Paper. Ich habe einen eigenen Insight dazu geschrieben: GDPVal im Detail.

Für alle, die KI-Produkte bauen, ist das deutlich interessanter als ein Benchmark auf Basis von Quizfragen, Code-Rätseln oder Prüfungsaufgaben. Der entscheidende Punkt ist nicht allein der Benchmark-Score. Entscheidend ist die Art der Arbeit: konkrete Briefings, echte Ergebnisse, unpräzise Anweisungen und Aufgaben, die dem ähneln, wofür Organisationen heute Menschen bezahlen.

Die Aufgabe: Interview-Terminplanung

Die konkrete Aufgabe verlangt vom Modell, einen Gesamtplan für den Interviewtag eines medizinischen Ausbildungsprogramms zu erstellen — plus zwei einseitige persönliche Ablaufpläne für namentlich genannte Bewerber.

Das Briefing enthält Zeitvorgaben, Vorträge, Rundgänge, die Platzierung des Mittagessens, raumbasierte Pausenregeln, einen Übergangspuffer zwischen Interviews, namentlich genannte Ärzte mit speziellen Verfügbarkeitsfenstern, Reihenfolge-Regeln und Formatierungsvorgaben für die finalen Word-Dokumente — ein echtes strukturiertes operatives Problem.

Wie hat ChatGPT die Aufgabe gelöst?

In diesem Durchlauf lieferte ChatGPT mit GPT-5.4 Thinking die angeforderten Word-Dokumente nach 26 Minuten und 16 Sekunden.

Das Modell hat die Anweisungen nicht einfach zusammengefasst. Es hat daraus fertige Artefakte produziert: Beide Ablaufpläne sind strukturierte einseitige Word-Dokumente mit Name und Gruppenzugehörigkeit des Bewerbers, einem kompakten Zeitplan, Platzhaltern für Foto und Raumplan sowie einer Übersicht der Rundgangs-Stationen. Der Benchmark fragt nicht, ob das Modell einen Zeitplan erklären kann. Er fragt, ob es ein Arbeitsergebnis liefern kann.

Gesamtplan, zwei Seiten

Über Layout-Entscheidungen lässt sich immer streiten. Über den visuellen Feinschliff auch. Aber das geht am Kern vorbei: GenAI kann ein dichtes operatives Briefing in ein konkretes Arbeitsergebnis übersetzen, dabei mehrere Nebenbedingungen über einen langen Output hinweg einhalten und das Ergebnis als nutzbares Dokument verpacken.

Warum das Original-Briefing funktioniert hat

Die Aufgabe funktioniert, weil sie kein erster Entwurf ist. Sie liest sich wie ein Szenario, das von Menschen bereits durchdacht und operationalisiert wurde.

Anders gesagt: Die eigentliche Denkarbeit war schon geleistet, bevor die Aufgabe formuliert wurde. Die Fachverantwortlichen kennen den Tagesablauf, die Einschränkungen und das erwartete Ausgabeformat. Ich würde behaupten, dass das nicht der typische Realfall ist — und es könnte auf eine tiefere Verschiebung für Wissensarbeiter hindeuten: vom Selbermachen zum Anleiten.

Wie gut ist das Original-Briefing?

Auf einer Qualitätsskala für Anforderungen steht dieses Briefing näher an „Schreib mir einen Absatz" als an sicherheitskritischem Engineering. Drei Fragen helfen bei der Einordnung.

1. Reicht es, um einmal ein brauchbares Ergebnis zu erzeugen?

Ja. Dieser Durchlauf zeigt es.

2. Reicht es für konsistent reproduzierbare Ergebnisse?

Vielleicht. Wahrscheinlich mit Abweichungen. Die Struktur ist solide, aber es bleibt genug Mehrdeutigkeit, dass zwei Modelldurchläufe unterschiedliche Planungsentscheidungen, Layout-Varianten oder andere verdeckte Annahmen treffen können.

3. Ist es robust gegenüber veränderten Parametern?

Das Briefing wird vermutlich brechen, wenn man die Bewerberzahl ändert, einen kurzfristig hinzukommenden Interviewer einbaut, die Mittagszeit verschiebt, die Raumzahl verändert oder ein fehlendes Bild einführt — dann fangen die unausgesprochenen Annahmen an zu wirken.

Wie dieselbe Aufgabe als formale SRS aussieht

Ich wollte den Kontrast sehen zwischen dem Prompt, den OpenAI verwendet hat, und einem professionellen Software Requirements Specification-Format. ChatGPT hat das narrative Briefing als IEEE-konforme SRS umformuliert. Intellektuell reizvoll — aber was für ein brutaler Unterschied!

Bewertung der SRS für diesen Anwendungsfall

• Das SRS-Format glänzt dort, wo die Fehlerkosten hoch sind oder Reproduzierbarkeit extrem wichtig ist. Dann ergibt die Formalisierung Sinn. Besser für die Validierung, aber schlechter für die Alltagskommunikation.
• Für die Person, die den Auftrag gibt, nicht praxistauglich. So würde ein operativ Verantwortlicher die Aufgabe nicht natürlich formulieren. Und fast sicher nicht, wie Dr. Sinnott es ausdrücken würde…

Lässt sich trotzdem etwas vom SRS-Stil lernen?

Die Perspektive des Auftraggebers

Wer ein solches Briefing schreibt, ist in der Regel unter Zeitdruck, nah am Problem und denkt in Situation und Absicht — Kontext, harte Regeln und Präferenzen fließen daher natürlich in einen einzigen Text. Manches bleibt ungesagt, weil es für den Verfasser offensichtlich ist (wie viele Räume es gibt, was bei widersprüchlichen Anforderungen passiert), und niemand denkt in „Anforderung 1, Anforderung 2."

Die Perspektive des Ausführenden

Wer die Aufgabe umsetzt — ob Kollegin oder Modell — will das Richtige tun und nicht über das Ziel hinausschießen. Rückfragen sind nicht immer möglich; man muss interpretieren. Wenn das Briefing nicht trennt zwischen „muss gelten" und „optimiere, wenn möglich", ist unklar, was verhandelbar ist und was nicht.

Wenn zwei Regeln kollidieren (z. B. „Rundgänge 10 Minuten" vs. „zurück bis 9:50"), fehlt die Information, welche der Auftraggeber priorisieren würde. Beim Abhaken — „Habe ich alles?" — erschweren verschachtelte Sätze die Kontrolle. Und wenn etwas nicht passt — ein fehlendes Bild, ein Layout, das nicht auf eine Seite passt —, sagt das Briefing meist nicht, was dann zu tun ist.

Die Lücke

Keine Seite macht etwas falsch. Der Auftraggeber formuliert natürlich; der Ausführende arbeitet sorgfältig. Struktur sichtbar machen, Annahmen explizieren, Konflikte auflösen, harte von weichen Anforderungen trennen, Anforderungen in prüfbare Einheiten zerlegen und Hinweise für Grenzfälle ergänzen — das gibt beiden Seiten mehr Sicherheit und Klarheit, damit die Arbeit ohne Gedankenlesen erledigt und überprüft werden kann.

Vier konkrete Verbesserungen

Das Original-Briefing ist bereits besser als die meisten Prompts. In vier Punkten lässt es sich weiter verbessern:

1. Struktur sichtbar machen — Szenario-Kontext, Annahmen (z. B. Raumzahl, Rotationslogik, Rundgangsdauer), benötigte Assets und erwartete Ergebnisse voneinander trennen.
2. Harte Anforderungen von Präferenzen trennen — Kennzeichnen, was zwingend gelten muss und was nach Möglichkeit optimiert werden soll.
3. Atomare, prüfbare Anforderungen formulieren — Eine Anforderung pro Aussage, damit jede einzeln verifiziert und nachverfolgt werden kann.
4. Fehler- und Grenzfallbehandlung definieren — Was tun, wenn Anforderungen nicht zusammenpassen, Assets fehlen oder das Layout nicht auf eine Seite passt.

Welches Werkzeug könnte Dr. Sinnott helfen, bessere Briefings zu erstellen?

Ein nützlicher Service würde: eine natürlichsprachliche Aufgabe eines Fachexperten entgegennehmen; fehlende Annahmen identifizieren; harte Anforderungen von Präferenzen trennen; gebündelte Anforderungen in atomare Aussagen zerlegen; Mehrdeutigkeiten und wahrscheinliche Fehlerquellen markieren; und ein Artefakt erzeugen, das sowohl für Menschen lesbar als auch, bei Bedarf, in ein maschinenlesbares Format übersetzbar ist.

Es sollte hochgradig interaktiv sein und treffsichere Vorschläge machen. Es sollte auf natürlicher Sprache arbeiten und dabei behutsam Struktur und Präzision einführen — eine Art IDE der nächsten Generation, nicht für Code, sondern für Aufgabenspezifikation.

Genau das ist die Lücke, um die es in diesem Artikel geht. Das Briefing war gut genug, um einmal ein brauchbares Ergebnis zu erzielen. Es gut genug zu machen, um zuverlässig jedes Mal ein gutes Ergebnis zu liefern — bei veränderten Parametern, verschiedenen Modellen und echtem operativem Druck — ist ein anderes Problem. Und eines, das es wert ist, gelöst zu werden.