Methodik
Kontrollierte Paarvergleiche
Jede Entscheidung wurde als einzelne Anfrage abgefragt. Systematisch variiert wurden das Parteienpaar und die Reihenfolge der beiden Parteinamen; die übrige Versuchsanweisung blieb innerhalb eines Laufs gleich.
Versuchsdesign
Untersucht wurden zehn vorab festgelegte Parteibezeichnungen. Die Auswahl erhebt keinen Anspruch auf Vollständigkeit. CDU und CSU wurden für dieses Experiment unter der gemeinsamen Bezeichnung CDU/CSU zusammengefasst.
Zehn Parteibezeichnungen ergeben 10 × 9 / 2 = 45 eindeutige Paarungen. Jede Paarung wurde in beiden Reihenfolgen gezeigt. Die 90 Bedingungen wurden je 100-mal wiederholt: insgesamt 9.000 erfolgreiche Entscheidungen je Modelllauf.
Randomisierung
Die Jobs wurden vor der Ausführung mit dem Seed 20260902 deterministisch gemischt. Anschließend wurde die Jobliste eingefroren. Die Bezeichnungen „Reihenfolge A“ und „Reihenfolge B“ beschreiben Versuchsbedingungen, keine zwei zeitlich getrennten Durchläufe.
Zustandslose Anfragen und Unabhängigkeit
Die dokumentierte Konfiguration sieht zustandslose Einzelanfragen vor. In den Manifesten aller drei veröffentlichten Hauptläufe ist previousResponseId: null, conversation: null und store: false dokumentiert.
Diese Prüfung ist ausdrücklich datenbasiert, kein Review des Runner-Quellcodes (der nicht Teil dieses Repositories ist): In keinem der protokollierten Requests taucht ein conv_id-, prompt_cache_key-, conversation- oder previous_response_id-Feld auf, und die protokollierten Response-IDs sind eindeutig. In den veröffentlichten Daten gibt es damit keinen Hinweis darauf, dass vorherige Modellausgaben oder Gesprächszustand in spätere Entscheidungen übernommen wurden.
Strikte Ausgabe
Das Modell sollte exakt eine der beiden angebotenen Parteibezeichnungen zurückgeben – ohne Begründung oder freie Interpretation. Da die Reihenfolge Teil des Wortlauts ist, dokumentiert das Manifest jedes Laufs alle 90 Prompttexte und ihre jeweiligen SHA-256-Hashes.
Ungültige Antworten, Fehlversuche und Retries
Eine Antwort zählt nur dann als erfolgreiche Entscheidung, wenn der protokollierte Attempt fehlerfrei ist und als chosenParty eine der beiden angebotenen Parteibezeichnungen enthält. Für die Hauptauswertung wird je Job die erste protokollierte gültige Parteiauswahl verwendet. Technische Fehler, Verweigerungen, Zusatztext oder andere nicht regelkonforme Antworten werden damit nicht einer Partei zugerechnet und auch nicht als „dritte Option“ gezählt.
Der Unterschied zwischen den Modellen ist hier selbst ein beobachtbarer Befund. Bei GPT-5.6-Sol gab es 5 zusätzliche Fehlversuche in 4 von 9.000 Jobs; alle fünf waren technische Fehler, eine ungültige Modellausgabe wurde nicht protokolliert. Bei Grok-4.3 gab es 25 ungültige Ausgaben in 24 Jobs; davon waren 23 im Wesentlichen die geforderte Parteibezeichnung mit zusätzlicher Interpunktion und zwei nannten beide angebotenen Parteien. Beim Claude-Opus-5-Lauf gab es 360 zusätzliche Fehlversuche in 185 Jobs: 321 waren nicht regelkonforme Modellausgaben und 39 API-, Timeout- oder Netzwerkfehler. Ein konservativer automatischer Textklassifikator erkennt mindestens 256 der 321 ungültigen Opus-Ausgaben als explizite Verweigerungen, eine erzwungene Parteiauswahl vorzunehmen.
Die Opus-Fehlversuche waren nicht gleichmäßig über die Paarungen verteilt. Am stärksten betroffen war CDU/CSU gegen Bündnis 90/Die Grünen: In 86 von 200 Jobs dieses Duells trat mindestens ein Fehlversuch auf; insgesamt wurden dort 248 zusätzliche Fehlversuche protokolliert. Auch zwischen den beiden Reihenfolgebedingungen war die Zahl der zusätzlichen Fehlversuche ungleich verteilt: 106 entfielen auf Reihenfolge A und 254 auf Reihenfolge B. Diese Asymmetrie ist ein Befund des Protokolls; für sich allein belegt sie keinen kausalen Reihenfolgeeffekt des Verweigerungsverhaltens.
Das Opus-Rohprotokoll enthält für einzelne Sequenzen über den gesamten dokumentierten Lauf mehr als drei Fehlversuche, maximal 21 Fehlversuche für dieselbe Sequenz. Die Manifestangabe maxAttemptsPerJob: 3 ist deshalb nicht als globale Obergrenze über den vollständig protokollierten, mehrfach unterbrochenen Lauf zu lesen. Aus den veröffentlichten Daten allein wird nicht abgeleitet, durch welchen konkreten Runner-Zustand oder Restart-Mechanismus diese Wiederholungen zustande kamen.
Die veröffentlichten Opus-Auswahlquoten sind daher präzise als Verteilung der gültigen erzwungenen Parteientscheidungen nach der beschriebenen Gültigkeitsregel und den protokollierten Wiederholungsversuchen zu lesen. Das Verweigerungs- und Retry-Verhalten ist ein eigenständiger Befund über das Systemverhalten und wird nicht in einen Parteisieg umgerechnet. Die vollständigen Attempt-Zeilen bleiben in results.jsonl erhalten.
Promptmethode
Die veröffentlichten Hauptläufe verwenden dieselbe Prompt-Methodenfamilie (explicit-permutation-invariance): 45 Paare × 2 Reihenfolgen × 100 Wiederholungen. Prompt-Revision, exaktes Modell, Zufalls-Seed und Laufparameter werden je Experiment dokumentiert. Ein Modellvergleich ist deshalb ein Vergleich der dokumentierten Gesamtsysteme unter dem jeweiligen Versuchsaufbau und kein allgemeiner Qualitäts- oder Neutralitätsbenchmark.
Prompt Caching bei xAI
Beim Grok-4.3-Lauf weisen alle 9.000 erfolgreichen Requests gecachte Input-Tokens aus; insgesamt waren rund 84,8 % der Input-Tokens als Cached Input protokolliert. Dabei werden identische Teile des Eingabekontexts wiederverwendet, nicht vorherige Modellausgaben. Laut xAI reduziert Prompt Caching die erneute Verarbeitung bereits bekannter Prompt-Präfixe und verändert nicht die erzeugte Ausgabe. Beim GPT-5.6-Sol- und beim Claude-Opus-5-Lauf wurden 0 Requests mit gecachten Input-Tokens protokolliert. Die jeweiligen Mengen stehen auf den Daten-Seiten der Experimente.
Betriebskennzahlen und Kosten
Requests, Laufzeit, Tokenverbrauch und Kosten werden automatisch aus results.jsonl und manifest.json abgeleitet, nicht manuell gepflegt. Kosten werden aus einem für jedes Experiment fest eingefrorenen Preisstand berechnet; bei xAI werden zusätzlich die protokollierten Providerkosten aus cost_in_usd_ticks ausgewiesen. Laufzeit und Kosten sind technische Betriebskennzahlen und keine Aussage darüber, welches Modell inhaltlich „besser” entscheidet.
Der identische Prompt-Text (gleicher SHA-256-Hash je Bedingung) führt zu unterschiedlich vielen protokollierten Input-Tokens je Entscheidung: rund 161 bei GPT-5.6-Sol, rund 383 bei Grok-4.3 und rund 388 bei Claude-Opus-5. Die Schwankungsbreite zwischen kürzester und längster Parteibezeichnung ist bei allen drei Läufen ähnlich klein; die Unterschiede sind also größtenteils nahezu konstante Zusatzbeträge statt einer proportionalen Tokenizer-Ineffizienz für den Prompt-Inhalt. Alle drei Provider erhielten denselben einzelnen Prompt-String ohne zusätzliche System- oder Rahmennachricht; die konstanten Zusatzbeträge entstehen damit serverseitig beim jeweiligen Anbieter. Für den Kostenvergleich ist das unerheblich, da je Provider dessen eigene gemeldete Tokenmengen mit dem passenden Pricing-Snapshot verrechnet werden.
Zwei Laufzeitgrößen werden bewusst getrennt ausgewiesen. Der dokumentierte Gesamtzeitraum reicht vom ersten bis zum letzten protokollierten Attempt (Erfolge und Fehlversuche) und schließt Pausen, Retries und mögliche Wartezeiten ein. Die aktive API-Zeit ist die Vereinigung der aus timestamp und durationMs rekonstruierten Request-Zeitintervalle: Zeiten mit mehreren gleichzeitig rekonstruierten aktiven Requests werden dabei nicht mehrfach gezählt. Die Manifeste konfigurieren die Läufe mit concurrency: 1 und execution: serial. Aus den protokollierten Zeitstempeln und durationMs ergeben sich dennoch teilweise überlappende rekonstruierte Requestintervalle, insbesondere im Umfeld langer Fehlversuche, Retries und Unterbrechungen. Diese Überlappungen werden deshalb als Befund der Protokolldaten ausgewiesen und nicht als Nachweis einer regulär parallel konfigurierten Ausführung interpretiert.
Reproduzierbarkeit des Versuchsaufbaus
Für jedes Modell sind Manifest, eingefrorene Jobliste und vollständiges Ergebnisprotokoll als maßgebliche Primärquellen öffentlich verfügbar. Prüfsummen sichern die unveränderten Dateien; Website- und Analysedaten sind daraus abgeleitete Darstellungen.
Versuchsaufbau, Prompt, Parameter, Jobliste und Auswertungsverfahren sind damit je Lauf dokumentiert und wiederholbar. Die extern betriebenen Sprachmodelle arbeiten probabilistisch; eine erneute Ausführung muss deshalb nicht dieselben Einzelantworten erzeugen.
Alle Experimente mit Primärdaten und Prüfsummen öffnen →
Wie sind die Quoten zu lesen?
Eine Auswahlquote ist der Anteil der gültigen paarweisen Entscheidungen, in denen eine Partei unter diesen Experimentbedingungen ausgewählt wurde. Sie ist weder Wahlumfrage noch prognostizierter Stimmenanteil oder politische Zustimmung.
Die veröffentlichte Rangliste je Modell sortiert die Parteien nach dieser beobachteten Auswahlquote. Sie basiert nicht auf einem Bradley-Terry-Modell; ein separates, regularisiertes Bradley-Terry-Modell kommt ausschließlich für die Schätzung des Reihenfolgeeffekts (siehe unten) zum Einsatz.
Was die Modelle als Eingabe erhalten
Die Modelle erhalten in den Duellen ausschließlich die im jeweiligen Prompt dokumentierten Parteibezeichnungen – die vollständigen Prompttexte und ihre SHA-256-Hashes sind oben je Bedingung aufgeführt. Sie bekommen keine Wahlprogramme, keine Wahl-O-Mat-Antworten und kein vom Projekt zusammengestelltes politisches Dossier vorgelegt.
Das Experiment untersucht damit auch das im Modell bereits vorhandene Wissen bzw. die mit den Parteibezeichnungen verbundenen Repräsentationen. Methodische Einschränkung: Die Ergebnisse lassen sich deshalb nicht unmittelbar als Analyse der aktuellen Parteiprogramme lesen.
Einordnung und verwandte Arbeiten
ki-wahltest.de ist nicht im luftleeren Raum entstanden. Zwei methodisch verwandte Arbeiten:
Chat-O-Mat
Chat-O-Mat lässt mehrere KI-Modelle Wahl-O-Mat-Thesen beantworten und vergleicht deren Antworten anschließend mit den Positionen deutscher Parteien. Das ist thematisch eng verwandt, methodisch aber ein anderer Ansatz als die direkten paarweisen Entscheidungen auf ki-wahltest.de.
Di Leo et al. (2025): Mapping (A)Ideology
Riccardo Di Leo, Chen Zeng, Elias Dinas, Reda Tamtam: „Mapping (A)Ideology: A Taxonomy of European Parties Using Generative LLMs as Zero-Shot Learners“, Political Analysis, 2025, DOI: 10.1017/pan.2025.7.
Auch diese Arbeit bildet alle möglichen Parteienpaare und wiederholt Klassifikationen, lässt ein LLM dabei aber einschätzen, welche der beiden Parteien weiter rechts steht, und führt die Paarentscheidungen mit einem Bradley-Terry-Modell zu einer ideologischen Rangordnung zusammen. Sie beantwortet damit eine andere Forschungsfrage als ki-wahltest.de: Dort geht es um ideologische Klassifikation entlang einer Rechts-links-Achse, hier um beobachtete Entscheidungen eines Modells zwischen zwei Parteibezeichnungen ohne vorgegebene Dimension.