DeepSeek R1 in der Produktion: So testen Sie Prompt-Vorlagen, ohne Ihre Anwendung zu beschädigen

Empfehlungen sind ein Ausgangspunkt, keine Garantie

Eine Prompt-Vorlage kann die Antwort des Modells verbessern und zugleich die Integration erschweren. Eine Anweisung, die ausführlichere Erklärungen fördert, kann beispielsweise bei einer Analyseaufgabe hilfreich sein, aber den Vertrag einer API verletzen, die eine kurze JSON-Antwort erwartet. Bei der Bereitstellung von DeepSeek R1 lautet die praktische Frage deshalb nicht nur, welche Konfiguration der Anbieter empfiehlt. Entscheidend ist auch, ob diese Konfiguration die tatsächlichen Aufgaben verbessert, ohne Regressionen zu verursachen, die sich auf das Produkt auswirken.

Das offizielle Repository von DeepSeek R1 enthält Nutzungsempfehlungen zur Position von Anweisungen, zur Systemnachricht und zum Beginn der Antwort des Assistenten. Außerdem empfiehlt es, bei der Evaluierung mehrere Testläufe durchzuführen. Diese Hinweise bilden eine Grundlage für den Versuchsaufbau, beweisen aber nicht von sich aus, dass eine bestimmte Vorgehensweise für jede Anwendung überlegen ist. Das Team muss sie anhand seiner Aufgaben, Abnahmekriterien und der Folgen einzelner Fehler überprüfen.

Dieser Artikel schlägt eine kontrollierte Ablation vor: Ändern Sie jeweils einen Faktor, halten Sie die übrigen konstant und erfassen Sie nicht nur, ob eine Antwort korrekt erscheint, sondern auch, ob sie den Ausgabevertrag einhält. Ziel ist es, DeepSeek R1 innerhalb einer konkreten Anwendung zu bewerten. Es geht weder um einen Vergleich mit anderen Modellen noch um die Frage, ob R1 besser schlussfolgert als DeepSeek V3.2. Ebenso wenig wird vorausgesetzt, dass der unter einer Reasoning-Kennung erzeugte Text einen internen Prozess zuverlässig wiedergibt.

Legen Sie zuerst fest, welche Version und Konfiguration Sie testen

Bevor Sie Prompts vergleichen, dokumentieren Sie, welches Modell und welcher Inferenzpfad bei den einzelnen Ausführungen zum Einsatz kommen. Das offizielle Modellprofil auf Hugging Face, die Generierungskonfiguration und die Chat-Vorlage im Repository dienen als Referenzen, um diese Angaben festzuhalten. Die Vorlage ist insbesondere hilfreich, um nachzuvollziehen, wie Nachrichten serialisiert werden. Zwei Bedingungen, die in einer Benutzeroberfläche unterschiedlich aussehen, können letztlich in verschiedene Tokenfolgen umgewandelt werden. Umgekehrt sind zwei Tests möglicherweise nicht mehr vergleichbar, wenn sich die Vorlage zwischen den Durchläufen ändert.

Notieren Sie die genaue Kennung oder Revision der Gewichte, die Laufzeitumgebung und deren Version, die Chat-Vorlage, die Generierungsparameter sowie zusätzliche Mechanismen der Anwendung: Tools, Validatoren, Wiederholungsversuche oder nachgelagerte Transformationen. Ändern Sie nicht gleichzeitig Vorlage, Temperatur und Laufzeitumgebung. Wenn mehrere Variablen zugleich geändert werden, lässt sich eine Verbesserung oder Verschlechterung nicht eindeutig dem untersuchten Faktor zuordnen.

Wenn Sie statt der Gewichte in einer eigenen Laufzeitumgebung einen kompatiblen Dienst verwenden, halten Sie fest, welche Parameter sich steuern lassen und welche außerhalb des Einflussbereichs Ihres Teams liegen. Eine kompatible Schnittstelle garantiert nicht automatisch, dass Serialisierung oder sämtliche Inferenzdetails identisch sind. Lässt sich eine Angabe nicht überprüfen, kennzeichnen Sie sie im Bericht als Unsicherheit, statt sie als bekannte Bedingung darzustellen.

Machen Sie aus den Empfehlungen vergleichbare Testfaktoren

Gestalten Sie die Bedingungen so, dass jeder Vergleich eine klar definierte Frage beantwortet. Um die Position der Anweisungen zu untersuchen, halten Sie ihren Inhalt gleich und vergleichen Sie zum Beispiel eine Bedingung, in der sie in der Systemnachricht stehen, mit einer Bedingung, in der dieselben Anweisungen in der Benutzernachricht enthalten sind. Wenn Sie zusätzlich verschiedene Positionen innerhalb der Benutzernachricht vergleichen möchten, legen Sie dafür eine eigene Bedingung an und lassen Sie den Anweisungstext unverändert. So vermeiden Sie, einen Effekt der Position zuzuschreiben, der in Wirklichkeit durch eine andere Formulierung ausgelöst wurde.

Das Präfix „<think>“ sollte als eigener Faktor untersucht werden. Vergleichen Sie eine Bedingung, in der der Beginn der Assistentenantwort nicht erzwungen wird, mit einer Bedingung, in der das in der Dokumentation angegebene Präfix ergänzt wird. Prüfen Sie dabei, wie es im tatsächlichen Prompt serialisiert wird. Kombinieren Sie diesen Vergleich nicht mit einer Änderung der Systemnachricht: Ändert eine Bedingung beide Aspekte, können Sie eine beobachtete Abweichung keinem davon eindeutig zuordnen.

Die Empfehlung, ein Präfix zu verwenden, belegt weder, dass es alle Aufgaben verbessert, noch, dass es in jeder Laufzeitumgebung nötig ist. Ebenso wenig lässt sich daraus schließen, dass sichtbarer Reasoning-Text direkt misst, wie das Modell intern arbeitet. Bewerten Sie, was die Anwendung tatsächlich erhält und überprüfen kann: Antwort, Struktur, Latenz, Fehler und Konsistenz.

Beziehen Sie Aufgaben mit unterschiedlichen Ausgabeverträgen ein

Ein Testsatz, der ausschließlich aus mathematischen Aufgaben besteht, bildet nicht zwangsläufig eine Anwendung ab, die außerdem Daten extrahiert, kurze Fragen beantwortet und Dokumente verarbeitet. Erstellen Sie auf Grundlage der tatsächlichen Produktaufgaben einen kleinen, aber vielfältigen Testsatz. Diese Vielfalt ist kein Selbstzweck: Sie hilft zu erkennen, ob eine Konfiguration einen Aufgabentyp unterstützt und einen anderen beeinträchtigt.

Legen Sie für eine kurze Faktenantwort im Voraus fest, welche Informationen enthalten sein müssen und welche zusätzlichen Inhalte als Verstoß gelten. Definieren Sie bei strukturierter Extraktion das Schema, Pflichtfelder und den Umgang mit fehlenden Daten. Halten Sie bei einer überprüfbaren Mathematikaufgabe die richtige Antwort und das Prüfverfahren fest. Stellen Sie bei einer dokumentbasierten Aufgabe allen Bedingungen dieselben Belege bereit. Bewerten Sie, ob sich die Antwort darauf stützt, fehlende Informationen als solche kennzeichnet und keine sachfremden Angaben hinzufügt.

Nehmen Sie auch Fälle auf, in denen das richtige Verhalten darin besteht, sich einer Antwort zu enthalten oder darauf hinzuweisen, dass die verfügbaren Belege nicht ausreichen. Ohne solche Fälle könnte eine Bewertung selbstbewusste, aber unbelegte Antworten belohnen. Bewahren Sie bekannte Fehlerbeispiele und Grenzfälle auf, trennen Sie aber die Daten, mit denen Sie eine Vorlage anpassen, von den Daten für die abschließende Evaluierung. Werden die Anweisungen während des Experiments überarbeitet, dokumentieren Sie die Änderung und führen Sie die vergleichbaren Bedingungen erneut aus.

Bewerten Sie Qualität und Kompatibilität getrennt

Die Hauptbewertung sollte abbilden, ob die Antwort die Aufgabe gemäß Kriterien löst, die festgelegt wurden, bevor die Ergebnisse vorlagen. Fassen Sie nicht alles zu einem allgemeinen Eindruck zusammen. Erfassen Sie zusätzlich die Befolgung von Anweisungen, die Gültigkeit des Formats, fehlende oder unerwartete Felder, angemessene Enthaltungen und ungerechtfertigte Enthaltungen. Bei Anwendungen mit Parsern gehört auch die Frage zu den betrieblichen Kennzahlen, ob sich die Antwort ohne manuelle Nachbearbeitung verarbeiten lässt.

Messen Sie die Latenz mit einer einheitlichen Methode und legen Sie fest, welchen Zeitraum Sie erfassen: die Generierung, den vollständigen Aufruf oder die vom Nutzer wahrgenommene Antwortzeit. Halten Sie auch Ausführungsfehler und Wiederholungsversuche fest. Wiederholende oder leere Antworten verdienen eine eigene Kategorie mit klaren Erkennungskriterien. Verstecken Sie sie nicht in einem Durchschnittswert für Qualität. Eine Antwort kann teilweise korrekt und trotzdem unbrauchbar sein, wenn sie Text wiederholt, den Abschluss einer Struktur auslässt oder das vorgeschriebene Format verletzt.

Führen Sie mehrere Ausführungen pro Bedingung durch, wenn das System Variabilität aufweist. Bewahren Sie die Einzelergebnisse zusätzlich zu Mittelwerten oder anderen Zusammenfassungen auf. Auch bei deterministischen Eingaben und Generierungsbedingungen, die solche Tests erlauben, können Wiederholungen sinnvoll sein, um die Stabilität der Umgebung zu überprüfen. Bei vorhandener Zufälligkeit berichten Sie die Zahl der Ausführungen und die beobachtete Streuung. Stellen Sie einen kleinen Unterschied nicht als robusten Effekt dar, ohne zu zeigen, wie viele Fälle ihn stützen.

Interpretieren Sie gemischte Ergebnisse, ohne Regressionen zu verschleiern

Angenommen, eine Bedingung verbessert die Bewertung mathematischer Aufgaben, erhöht aber die Zahl der Formatfehler bei der Extraktion. Es wäre nicht angemessen, sie einfach als „besser“ zu bezeichnen. Die Entscheidung hängt davon ab, welche Aufgabe kritisch ist, welche Kosten ein Fehler verursacht und ob die Anwendung über zuverlässige Mechanismen verfügt, um ihn zu erkennen und zu beheben. Ein besserer Durchschnitt kann eine schwerwiegende Regression in einer bestimmten Funktion verdecken.

Vergleichen Sie zunächst jede Aufgabe einzeln und erstellen Sie anschließend eine Gesamtübersicht, deren Aggregationsmethode Sie erklären. Wenn Sie Gewichtungen verwenden, geben Sie an, wer sie festgelegt hat und welche Bedeutung sie darstellen. Bei kleinen Testsätzen sollten Sie neben Prozentwerten auch absolute Fallzahlen nennen: Von null auf einen Fehler zu steigen ist nicht dasselbe wie von zehn auf elf, auch wenn eine aggregierte Rate ähnlich aussehen mag. Ändern Sie die Gewichtungen nicht nachträglich, wenn bereits feststeht, welche Bedingung davon profitiert.

DeepSeek empfiehlt, bei der Evaluierung mehrere Tests durchzuführen. In der Praxis heißt das, die Variabilität zwischen Ausführungen zu dokumentieren und nicht nur eine günstige Antwort auszuwählen. Es heißt auch, keine weitergehenden Schlüsse als die getesteten Bedingungen zu ziehen: Ergebnisse mit einem anwendungsspezifischen Aufgabensatz sind Belege für diese Anwendung und diese Bedingungen, keine allgemeine Garantie für R1.

Verwechseln Sie Reasoning-Text nicht mit einer verlässlichen Erklärung

Die Kennung „<think>“ ist in bestimmten Gesprächsformaten von R1 Teil der textuellen Schnittstelle. Text unter dieser Kennung zu sehen, beweist jedoch nicht, dass es sich um eine vollständige oder wörtliche Aufzeichnung eines internen Prozesses handelt. Die Evaluierung sollte sich auf beobachtbare und überprüfbare Ergebnisse konzentrieren. Bei einer Mathematikaufgabe prüfen Sie die Antwort; bei einer Extraktion vergleichen Sie die Felder mit dem Dokument; bei einer Enthaltung überprüfen Sie, ob die verfügbaren Belege tatsächlich unzureichend waren.

Die unter dem Titel DeepSeek-R1 Thoughtology veröffentlichte Arbeit untersucht Merkmale des Reasoning-Verhaltens von R1 und behandelt unter anderem Länge, Steuerbarkeit und Rumination. Dieser Kontext begründet, warum Wiederholungen und Antwortlänge erfasst werden sollten. Er ersetzt aber weder Messungen in der Anwendung noch belegt er im Voraus, was sich bei einer Änderung der Vorlage ergibt. Eine lange Erklärung ist für sich genommen kein Beweis für eine bessere Antwort; eine kurze Erklärung beweist ebenso wenig, dass die Aufgabe ohne Reasoning gelöst wurde.

Wenn das Produkt diese Inhalte weder anzeigen noch speichern soll, überprüfen Sie getrennt, was die Laufzeitumgebung bereitstellt, was die Anwendung protokolliert und was der Nutzer erhält. Gehen Sie nicht davon aus, dass das Ausblenden einer Zeichenfolge in der Benutzeroberfläche gleichbedeutend damit ist, sie auch aus Protokollen oder Traces zu entfernen. Das hängt von der Integration ab und muss separat geprüft werden.

Dokumentieren Sie die Entscheidung in einem Regressionsbericht

Ein hilfreicher Bericht ermöglicht es, das Experiment zu wiederholen und nachzuvollziehen, warum eine Bedingung gewählt wurde. Er enthält die exakten Revisionen von Modell und Vorlage, die Generierungskonfiguration, die vollständigen Prompts, den Aufgabensatz und die Bewertungsregeln. Fassen Sie die Ergebnisse nach Aufgabentyp zusammen, nicht nur mit einer aggregierten Kennzahl. Bewahren Sie aussagekräftige Beispiele für Erfolge und Fehler auf und behandeln Sie sensible Daten gemäß den Richtlinien des Teams.

Beschreiben Sie, was sich zwischen den Bedingungen geändert hat und was konstant blieb. Halten Sie auch Einschränkungen fest, etwa wenn der Dienst die Revision der Gewichte nicht offenlegt oder bestimmte Parameter nicht kontrollierbar sind. Ist das Ergebnis nicht eindeutig, ist das eine zulässige Schlussfolgerung. Sie können den Testsatz erweitern, den Versuch wiederholen oder die bestehende Konfiguration beibehalten, während Sie weiter untersuchen. Verwechseln Sie fehlende Hinweise auf eine Regression nicht mit dem Beleg, dass es keine Regression gibt.

Die abschließende operative Empfehlung sollte konkret sein: Welche Vorlage wird für welche Aufgaben, mit welcher Version und unter welchen Schwellenwerten akzeptiert? Funktioniert eine Variante nur in einem Ablauf gut, beschränken Sie sie darauf, statt sie als universelle Vorlage für DeepSeek R1 darzustellen.

Praktische Leitlinie: Behalten Sie, was sich in Ihrer Anwendung bewährt

Die nützlichste Prompting-Vorgehensweise für eine DeepSeek-R1-Anwendung ist diejenige, die ihre Aufgaben verbessert, ohne Ausgabeverträge oder Sicherheits- und Wiederherstellungsmechanismen zu schwächen. Um das festzustellen, legen Sie eine Ausgangsbasis fest, isolieren Sie Änderungen, beziehen Sie unterschiedliche Aufgaben ein, wiederholen Sie Tests bei Bedarf und weisen Sie Ergebnisse nach Aufgaben getrennt aus. Ein Präfix, die Position einer Anweisung oder das Weglassen einer Systemnachricht sollte weder aus Gewohnheit akzeptiert noch aus dem Bauch heraus verworfen werden: Die Auswirkungen müssen unter dokumentierten Bedingungen überprüft werden.

Sind die Ergebnisse konsistent und erfüllen sie die festgelegten Schwellenwerte, stellen Sie die Konfiguration bereit und überwachen Sie weiterhin die Kennzahlen, die der Entscheidung zugrunde lagen. Ändern sich Umgebung, Gewichte, Vorlage oder Aufgaben, bewerten Sie die relevanten Bedingungen erneut. So bleiben die offiziellen Empfehlungen als Ausgangshypothesen nützlich, während die Evidenz aus der Anwendung die endgültige Konfiguration bestimmt.

Weiter entdecken

Korrekturen und Transparenz

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