DeepSeek R1 vs. DeepSeek V3.2: Wie Sie zwischen explizitem Reasoning und Effizienz in einem überprüfbaren Workflow entscheiden

Die Entscheidung lautet nicht, welches Modell besser wirkt, sondern welches Risiko der Workflow reduziert

Der Vergleich zwischen DeepSeek R1 und DeepSeek V3.2 sollte von einer konkreten operativen Entscheidung ausgehen. Ein Beispiel: Ein technisches Dossier analysieren, auf Nutzerseite bereitgestellte Dokumente auf anwendbare Anforderungen prüfen, eine strukturierte Empfehlung abgeben und eine nachfolgende Aktion vorbereiten. Diese Aktion kann etwa einen Entwurf erzeugen, einen Vorgang eröffnen oder einen Genehmigungsweg vorschlagen. Sie darf jedoch nicht ohne die menschlichen und systemseitigen Validierungen ausgeführt werden, die der Prozess verlangt.

In einem solchen Workflow sind eine lange Antwort oder sichtbares Reasoning nicht automatisch ein Vorteil. Entscheidend ist, ob sie einen wesentlichen Fehler verringern: eine Empfehlung, die nicht mit den Belegen vereinbar ist, einen falschen Dokumentverweis, einen Tool-Aufruf mit fehlerhaften Parametern, das Ausbleiben einer Enthaltung bei unzureichenden Daten oder eine Ausgabe, die das empfangende System nicht verarbeiten kann.

Die Kauf- oder Bereitstellungsfrage lässt sich falsifizierbar formulieren: Senkt R1 bei mehrdeutigen Fällen und Fällen mit mehreren Schritten wesentliche Fehler und den Aufwand der menschlichen Prüfung ausreichend, um Antwortzeit, Tokens und Integrationskomplexität zu rechtfertigen? Erreicht V3.2 denselben Schwellenwert bei Korrektheit, Belegen, Enthaltung und Struktur mit weniger Ressourcen, rechtfertigt längeres Reasoning für sich allein nicht, die Aufgabe an R1 zu routen.

Dieser Beitrag setzt nicht voraus, dass eines der beiden Modelle ein universeller Ersatz für das andere ist. Er schlägt einen Test für Produkt-, Plattform- und Engineering-Verantwortliche vor, die je Fall einen Pfad wählen und für Entscheidungen mit operativen Folgen eine menschliche Freigabe beibehalten müssen.

Bestimmen Sie exakt, was verglichen wird, bevor Sie Ergebnisse messen

„DeepSeek V3.2“ ist als experimenteller Bezeichner nicht präzise genug. Die Release-Dokumentation beschreibt DeepSeek-V3.2 als Nachfolger von V3.2-Exp, während das Änderungsprotokoll die Aktualisierung der Aliase deepseek-chat und deepseek-reasoner auf DeepSeek-V3.2 zum 1. Dezember 2025 nennt. Ein reproduzierbarer Bericht muss daher den angefragten Identifikator, den tatsächlich verwendeten Alias, Datum und Uhrzeit der Ausführung, den Zugangskanal sowie bei einem lokal ausgeführten Checkpoint dessen Version oder Revision erfassen.

Die veröffentlichte Karte von DeepSeek-V3.2 ermöglicht es, ein Artefakt für eine lokale Evaluierung festzuschreiben. Ein lokaler Test und ein Test über eine API sind jedoch nicht automatisch austauschbar. Sie können sich bei Hardware, Runtime, Quantisierung, Inferenzserver, Kontextgrenzen, Warteschlangen, Sicherheitskontrollen, Wiederholungsrichtlinien und Preis unterscheiden. Auch das Chat-Template oder die Tool-Verarbeitung können abweichen. Der Vergleich muss solche Unterschiede offenlegen, statt sie dem Modell zuzuschreiben.

Auch bei DeepSeek R1 muss das verwendete Verfahren dokumentiert werden. Das offizielle Repository beschreibt einen Kontext von 128K und nennt für die veröffentlichte Evaluierung eine maximale Generierung von 32.768 Tokens, eine Temperatur von 0,6 und top_p von 0,95 beim Sampling. Diese Werte garantieren nicht, dass sie für jede Aufgabe optimal sind, bilden aber einen wichtigen Bezugspunkt. Weicht der Versuch davon ab, sollte dies begründet und geprüft werden, ob die Änderung R1 begünstigt oder benachteiligt.

Es ist nicht sinnvoll, identische Einstellungen zu erzwingen, wenn dokumentierte Schnittstellen unterschiedliche Einschränkungen haben. Relevant ist die Chancengleichheit bei der Lösung der Aufgabe: derselbe Korpus, dieselben verfügbaren Tools, dieselben Erfolgsregeln, dieselbe geschäftliche Zeitgrenze und eine vor der Auswertung festgelegte Wiederholungsrichtlinie. Modellspezifische Einstellungen müssen als Teil des Experiments dokumentiert werden.

Formulieren Sie eine Hypothese, die verlieren kann

Die Hypothese darf nicht lauten, R1 „reasoniere besser“ oder V3.2 sei „effizienter“. Beide Aussagen sind für eine Plattformentscheidung zu unpräzise. Eine brauchbare Hypothese könnte sein: Bei Dossiers mit widersprüchlichen Belegen, Abhängigkeiten zwischen Dokumenten und der Notwendigkeit, simulierte Tools abzufragen, erzielt R1 eine höhere Rate korrekter Entscheidungen und korrekter Enthaltungen, die die Zahl menschlicher Prüfungen operativ relevant senkt.

Auch die Gegenhypothese muss definiert sein: Bei direkten Anfragen mit ausreichender Evidenz und einem einzelnen Entscheidungsschritt erreicht V3.2 den vereinbarten Qualitätsschwellenwert mit geringerer Latenz, weniger Ausgabetokens oder niedrigeren Kosten pro akzeptiertem Ergebnis. In diesem Fall wäre V3.2 für dieses Segment der bevorzugte Pfad, selbst wenn R1 eine leicht höhere durchschnittliche Punktzahl erzielt.

Legen Sie vorab fest, welches Ergebnis jeden Vorschlag widerlegt. R1 rechtfertigt beispielsweise keinen spezialisierten Pfad, wenn seine Verbesserung bei wesentlichen Fehlern den festgelegten Abstand nicht übersteigt, wenn der Vorteil bei Wiederholungen verschwindet oder wenn er aus einem anderen Prompt-Format, einer anderen Dokumentenrückgewinnung oder einer anderen Infrastruktur resultiert. V3.2 sollte nicht als Standardpfad dienen, wenn es eine inakzeptable Rate unbelegter Empfehlungen beibehält oder sich nicht angemessen enthält.

Die Schwellenwerte müssen aus dem jeweiligen Prozess stammen. Ein Workflow, der interne Antworten mit geringer Auswirkung vorbereitet, kann eine Stichprobenprüfung tolerieren. Ein Workflow, der vertragliche Zusagen, den Betrieb oder Personen betrifft, kann verpflichtende Belege, regelbasierte Sperren und eine menschliche Freigabe in jedem Fall verlangen. Die Evaluierung misst Leistung unter bestimmten Bedingungen; sie macht das Modell nicht zu einer autonomen Instanz.

Entwerfen Sie das Experiment so, dass es eine Aufgabe misst und nicht die Fähigkeit zu beeindrucken

Erstellen Sie einen eingefrorenen Korpus, bevor das erste Modell ausgeführt wird. Jeder Fall sollte die Dokumente und Metadaten enthalten, die beide Systeme erhalten, einen unabhängig erstellten Bewertungsschlüssel sowie ein Segment-Label. Der Korpus kann direkte Aufgaben, lange Dossiers, absichtlich angelegte Mehrdeutigkeiten, Widersprüche, unvollständige Informationen und Fälle umfassen, in denen die richtige Antwort Enthaltung oder Eskalation an eine Person ist.

Der Bewertungsschlüssel muss überprüfbare Fakten von Expertenkriterien trennen. Zu den Fakten können eine korrekte Entscheidung, Pflichtfelder, Verweise auf zulässige Belege, erwartete Tool-Parameter und Bedingungen für Enthaltung gehören. Expertenkriterien können Klarheit, Priorisierung oder die Qualität der Erklärung bewerten. Letztere sollten gegenüber dem Modell blind geprüft werden; Anweisungen und die Auflösung von Meinungsverschiedenheiten sind zu dokumentieren.

Geben Sie beiden Modellen exakt denselben geschäftlichen Inhalt und dasselbe Ausgabeschema. Wenn Tools aktiviert sind, simulieren Sie deterministische Antworten, damit Unterschiede nicht aus sich verändernden externen Systemen stammen. Der Leitfaden für Tool Calls dokumentiert Tool-Unterstützung im Thinking-Modus ab V3.2 sowie einen strikten Modus, der auf die Einhaltung von JSON Schema ausgerichtet ist. Wird diese Option eingesetzt, wenden Sie sie dort konsistent an, wo sie kompatibel ist, und messen Sie die syntaktische JSON-Gültigkeit getrennt von der semantischen Gültigkeit der Werte.

Erfassen Sie Temperatur, top_p, Ausgabelimit, Seed sofern verfügbar, maximale Anzahl von Aufrufen, Zeitlimit und Wiederholungsrichtlinie. Für R1 nennt die veröffentlichte Dokumentation eine konkrete Konfiguration für die Evaluierung und empfiehlt in bestimmten Szenarien mehrere Ausführungen. Eine einzige Antwort pro Fall genügt daher nicht, wenn Stabilität geschätzt werden soll: Wiederholen Sie jeden Fall eine vorab festgelegte Anzahl von Malen und berichten Sie die Ergebnisverteilung, nicht nur den besten Versuch.

Vermischen Sie Prompt-Änderungen nicht mit Modelländerungen. Falls das Format versagt, führen Sie eine separate Diagnoserunde neben dem Hauptvergleich durch. Wird Prompt oder Parser nach Beobachtung eines Fehlers verändert, führen Sie beide Modelle unter der neuen Konfiguration erneut aus. Andernfalls kann das Experiment den Modelleffekt nicht mehr vom Effekt der Teamiteration trennen.

Messen Sie Korrektheit, Belege, Enthaltung und Kosten getrennt

Die finale Genauigkeit ist notwendig, aber nicht ausreichend. Eine Empfehlung kann zufällig mit dem Bewertungsschlüssel übereinstimmen und dennoch falsche Belege zitieren oder eine Aktion mit unsicheren Parametern vorbereiten. Messen Sie die Korrektheit der Entscheidung, die Abdeckung der Pflichtelemente und die Belegtreue: Jede relevante Aussage muss mit einer zulässigen Passage aus dem Fallkorpus verknüpft werden können.

Enthaltung braucht eine eigene Kennzahl. Unterscheiden Sie korrekte Enthaltung — das Modell erkennt, dass es mit den verfügbaren Daten nicht entscheiden kann — von übermäßiger Enthaltung, bei der lösbare Fälle weitergeleitet werden, und falscher Sicherheit, bei der entschieden wird, obwohl eskaliert werden müsste. Letzteres ist bei Prozessen mit Auswirkungen oft wichtiger als ein moderater Produktivitätsverlust. Das Bewertungsraster muss angeben, welche fehlenden Daten, Konflikte oder Kompetenzgrenzen eine Eskalation verlangen.

Bei Tools sollten Sie mindestens vier Aspekte messen: Auswahl des passenden Tools, gültige Parameter, korrekte Interpretation der Antwort und eine anschließende Entscheidung, die mit dieser Antwort konsistent ist. Ein Aufruf mit gültigem JSON ist nicht zwangsläufig nützlich. Umgekehrt kann eine Antwort mit unvollkommenem Format eine richtige Entscheidung enthalten, die das System nicht akzeptieren kann. Halten Sie Struktur- und Inhaltsmetriken getrennt.

Die operative Messung sollte Ende-zu-Ende-Latenz nach Perzentilen, Ausgabetokens, Zahl der Tool-Aufrufe, Wiederholungen und Kosten pro akzeptiertem Fall enthalten. Der Nenner ist entscheidend: Werden die Kosten durch alle Antworten geteilt, können die Kosten der nach Validierung tatsächlich nutzbaren Ergebnisse verdeckt bleiben. Berichten Sie auch das benötigte Volumen menschlicher Prüfung und die Korrekturzeit nach Fehlertyp.

Diagnostizieren Sie die Ursache eines Unterschieds, bevor Sie ihn dem Reasoning zuschreiben

Stellen Sie Ergebnisse nach Segmenten dar, zusätzlich zu einem Gesamtdurchschnitt. Ein Mittelwert kann verdecken, dass R1 nur bei einer Minderheit mehrdeutiger Dossiers zusätzlichen Nutzen bringt oder dass V3.2 den Großteil einfacher Anfragen ausreichend löst. Kreuzen Sie die Ergebnisse mit Kontextlänge, Zahl der Dokumente, Tool-Bedarf, Widersprüchen zwischen Quellen und Enthaltungsbedingung.

Wenn ein Unterschied vorliegt, klassifizieren Sie den ersten Fehlerpunkt. Er kann bei der Belegrückgewinnung, dem Verständnis einer Anweisung, der Planung eines Aufrufs, der Generierung von Argumenten, dem Parser, einem Zeitablauf, einer Wiederholung oder der Infrastruktur liegen. Prüfen Sie Traces, ohne den Bewertenden offenzulegen, welches Modell sie erzeugt hat, sofern dies praktikabel ist. Der Thinking-Mode-Leitfaden behandelt Reasoning-Inhalte als Elemente mit besonderer Verarbeitung und formuliert Anforderungen für bestimmte Tool-Workflows; das Test-Harness muss diesen Vertrag einhalten, statt Reasoning-Inhalte improvisiert mit dem Verlauf zu vermischen.

Nutzen Sie offengelegtes Reasoning nicht als Wahrheitsbeweis. Es kann bei der Diagnose helfen, sofern Kanal und Datenrichtlinie seine Protokollierung erlauben. Die Validierung muss jedoch auf der finalen Ausgabe, den gelieferten Belegen und den Tool-Ereignissen beruhen. Zudem kann die Aufbewahrung von Traces Datenschutz-, Sicherheits- und Governance-Auswirkungen haben, die gesondert bewertet werden müssen.

Verschwindet der Unterschied nach Angleichung von Quantisierung, Server, maximaler Länge oder Wiederholungen, belegt das Ergebnis keine allgemeine Überlegenheit eines Modells. Wenn ein Modell seinen Vorteil durch einen spezialisierten Prompt erhält, lautet die gültige Schlussfolgerung ebenso, dass die Kombination aus Modell und Konfiguration unter diesem Harness besser funktioniert — nicht, dass das Modell isoliert in jeder Umgebung überlegen ist.

Machen Sie aus den Ergebnissen eine Routing-Regel und behalten Sie menschliche Kontrollen bei

Das Ergebnis des Experiments sollte eine operative Regel sein, keine pauschale Siegererklärung. Eine mögliche Richtlinie besteht darin, direkte Fälle an V3.2 zu senden, wenn sie den Schwellenwert für Korrektheit, Belege und Struktur innerhalb eines definierten Budgets überschreiten; Dossiers mit Mehrdeutigkeit, mehreren Abhängigkeiten oder Tool-Planung an R1 zu senden, wenn dieses nachweislich wesentliche Fehler stärker reduziert; und Konflikte bei Belegen, kritische Datenlücken sowie Fälle außerhalb der delegierten Befugnis an eine Person zu eskalieren.

Testen Sie die Regel vor dem Rollout im Schattenmodus. Das System kann eine Empfehlung und eine vorbereitete Aktion erzeugen, ohne dass diese Wirkung entfaltet, während eine prüfende Person die Ergebnisse mit dem bestehenden Prozess vergleicht. Richten Sie Warnungen für zunehmende unterlassene Enthaltungen, einen Rückgang gültiger Belege, eine Verschlechterung der Latenz und Verhaltensänderungen nach einer Aktualisierung von Alias oder Infrastruktur ein.

Die finale Genehmigung darf nicht allein deshalb delegiert werden, weil das Modell einen Test bestanden hat. Die Evaluierung belegt weder aktuelles Wissen außerhalb des Korpus noch die Sicherheit realer Tools, regulatorische Konformität, Widerstandsfähigkeit gegenüber adversarialen Eingaben oder Generalisierbarkeit auf eine andere Domäne. Sie beseitigt auch nicht die Notwendigkeit minimaler Berechtigungen, deterministischer Parametervalidierung, auditierbarer Protokolle und Rückabwicklungsmechanismen.

Für DeepSeek V3.2 ist eine dokumentierte Verfügbarkeit in App, Web und API angegeben, und die API-Dokumentation beschreibt Thinking- und Tool-Funktionen. Diese Tatsachen erleichtern die Definition eines Tests, belegen aber nicht, dass ein Kanal für sich genommen Anforderungen an Datenresidenz, Aufbewahrung, Kapazität, Preis oder Verfügbarkeit erfüllt. Solche Bedingungen müssen vor einer Kaufentscheidung für das konkrete Konto, die Region und den Vertragszeitpunkt bestätigt werden.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.