DeepSeek R1 en production : tester le modèle de prompt sans casser l’application

Les recommandations sont un point de départ, pas une garantie

Un modèle de prompt peut améliorer la réponse du modèle tout en compliquant son intégration. Une instruction qui encourage des explications plus détaillées peut être utile pour une tâche d’analyse, mais ne pas respecter le contrat d’une API qui attend une réponse courte au format JSON. Lors du déploiement de DeepSeek R1, la question pratique n’est donc pas seulement de savoir quelle configuration le fournisseur recommande : il faut aussi vérifier si elle améliore les tâches réelles sans introduire de régressions susceptibles d’affecter le produit.

Le dépôt officiel de DeepSeek R1 propose des recommandations d’utilisation portant notamment sur l’emplacement des instructions, le message système et le début de la réponse de l’assistant. Il conseille également d’effectuer plusieurs essais lors de l’évaluation. Ces indications constituent une base pour concevoir des expériences, mais ne prouvent pas à elles seules qu’une consigne donnée sera supérieure dans toutes les applications. Il revient à l’équipe de la valider en fonction des tâches, des critères d’acceptation et des conséquences de chaque erreur.

Cet article propose une ablation contrôlée : ne faire varier qu’un facteur à la fois, maintenir les autres constants et consigner non seulement si la réponse semble correcte, mais aussi si elle respecte le contrat de sortie. L’objectif est d’évaluer DeepSeek R1 dans une application précise. Il ne s’agit ni de comparer R1 à d’autres modèles ni d’étudier s’il raisonne mieux que DeepSeek V3.2. Nous ne partons pas non plus du principe que le texte généré entre des balises de raisonnement décrit fidèlement un processus interne.

Commencez par fixer la version et la configuration évaluées

Avant de comparer les prompts, consignez le modèle et le chemin d’inférence utilisés pour chaque exécution. La fiche officielle du modèle sur Hugging Face, le fichier de configuration de génération et le modèle de chat du dépôt sont des références utiles pour documenter ces éléments. Le fichier de modèle de chat permet notamment de déterminer comment les messages sont sérialisés. Deux conditions qui semblent différentes dans une interface peuvent être converties en séquences de jetons différentes ; à l’inverse, deux essais peuvent cesser d’être comparables si le modèle de chat change entre-temps.

Notez l’identifiant ou la révision exacte des poids, le runtime et sa version, le modèle de chat, les paramètres de génération, ainsi que tout mécanisme supplémentaire de l’application : outils, validateurs, nouvelles tentatives ou transformations en aval. Ne modifiez pas simultanément le modèle de chat, la température et le runtime. Si plusieurs variables changent à la fois, il devient difficile d’attribuer clairement une amélioration ou une dégradation au facteur que vous vouliez évaluer.

Si vous utilisez un service compatible plutôt que les poids dans votre propre runtime, précisez les paramètres qu’il accepte et ceux qui échappent au contrôle de l’équipe. Une interface compatible ne garantit pas à elle seule que la sérialisation ou tous les détails d’inférence soient identiques. Si certaines informations ne peuvent pas être vérifiées, signalez-les comme des incertitudes dans le rapport plutôt que de les présenter comme des conditions connues.

Transformez les recommandations en facteurs comparables

Concevez les conditions de façon à ce que chaque comparaison réponde à une question précise. Pour étudier l’emplacement des instructions, gardez un contenu équivalent et comparez, par exemple, une condition où elles figurent dans le message système à une autre où elles sont intégrées au message de l’utilisateur. Si vous voulez également comparer différentes positions dans le message de l’utilisateur, créez une condition distincte et conservez le texte de l’instruction. Vous éviterez ainsi d’attribuer à son emplacement un effet qui pourrait en réalité être dû à une reformulation.

Évaluez le préfixe « <think> » comme un facteur distinct. Comparez une condition où le début de la réponse de l’assistant n’est pas forcé à une autre où le préfixe indiqué dans la documentation est ajouté, en vérifiant sa sérialisation dans le prompt réellement envoyé. Ne combinez pas cette comparaison avec la modification du message système : si une condition change ces deux éléments, la différence observée ne permet pas de savoir lequel l’a produite.

La recommandation d’utiliser un préfixe ne démontre pas qu’il améliore toutes les tâches ou qu’il est nécessaire dans tous les runtimes. Elle ne permet pas non plus de conclure que le texte de raisonnement visible mesure directement le fonctionnement interne du modèle. Évaluez ce que l’application reçoit et peut vérifier : réponse finale, structure, latence, erreurs et cohérence.

Incluez des tâches représentatives de différents contrats

Un jeu d’essai constitué uniquement de problèmes mathématiques ne représente pas nécessairement une application qui extrait aussi des données, répond à des questions brèves et traite des documents. Construisez un jeu réduit mais varié, composé de tâches propres au produit. Cette diversité n’est pas accessoire : elle permet de détecter qu’une configuration peut aider pour un type de tâche et nuire à un autre.

Pour une réponse factuelle courte, définissez à l’avance les informations qui doivent apparaître et les ajouts qui constitueraient un manquement. Pour l’extraction structurée, précisez le schéma, les champs obligatoires et la manière de traiter les données absentes. Pour une tâche mathématique vérifiable, conservez la réponse correcte et la méthode de vérification. Pour une tâche fondée sur des documents, fournissez les mêmes éléments de preuve à toutes les conditions et évaluez si la réponse s’appuie sur eux, distingue les informations non documentées et évite d’ajouter des données extérieures.

Incluez également des cas où la bonne conduite consiste à s’abstenir ou à signaler que les éléments disponibles ne suffisent pas. Sans ces cas, une évaluation risque de récompenser des réponses assurées mais infondées. Conservez des exemples d’erreurs connues et des cas limites, mais séparez les données utilisées pour ajuster un modèle de prompt de celles qui servent à l’évaluation finale. Si vous révisez les instructions pendant l’expérience, consignez le changement et relancez les conditions comparables.

Mesurez séparément la qualité et la compatibilité

Le score principal doit indiquer si la réponse résout correctement la tâche selon des critères rédigés avant l’examen des résultats. Ne réduisez pas tout à une impression générale. Consignez également le respect des instructions, la validité du format, les champs manquants ou inattendus, les abstentions appropriées et les abstentions injustifiées. Dans les applications qui utilisent des analyseurs syntaxiques, mesurez aussi si la réponse peut être traitée sans réparation manuelle.

Mesurez la latence de façon cohérente et précisez le segment mesuré : génération, appel complet ou temps perçu par l’utilisateur. Consignez aussi les erreurs d’exécution et les nouvelles tentatives. Les réponses répétitives ou vides méritent une catégorie distincte et des règles d’identification explicites ; ne les dissimulez pas dans un score moyen de qualité. Une réponse peut être en partie correcte et néanmoins inutilisable si elle répète du texte, omet la fermeture d’une structure ou enfreint le format exigé.

Effectuez plusieurs essais par condition lorsque le système est susceptible de varier. Conservez les résultats individuels en plus des moyennes et des synthèses. Même avec des entrées déterministes et des paramètres de génération qui le permettent, les répétitions peuvent aider à vérifier la stabilité de l’environnement ; en présence d’aléatoire, indiquez le nombre d’exécutions et la dispersion observée. Ne présentez pas une petite différence comme un effet robuste sans montrer combien de cas l’étayent.

Interprétez les résultats contrastés sans masquer les régressions

Supposons qu’une condition améliore le score des problèmes mathématiques, mais augmente les erreurs de format lors de l’extraction. Il serait inexact de la qualifier simplement de « meilleure ». La décision dépend de la tâche considérée comme critique, du coût de l’erreur et de la présence de mécanismes fiables pour la détecter et y remédier. Une amélioration moyenne peut masquer une régression importante dans une fonctionnalité précise.

Commencez par comparer chaque tâche séparément, puis présentez une synthèse globale en expliquant la méthode d’agrégation. Si vous appliquez des pondérations, indiquez qui les a choisies et quelle importance elles représentent. Pour les petits jeux de données, ajoutez les nombres de cas aux pourcentages : passer de zéro à une erreur et de dix à onze ne correspond pas à la même situation, même si un taux agrégé peut sembler comparable. Ne modifiez pas les pondérations après avoir vu quelle condition est favorisée.

La documentation de DeepSeek recommande d’effectuer plusieurs essais lors de l’évaluation. En pratique, cela signifie qu’il faut conserver les variations entre exécutions et ne pas sélectionner uniquement une réponse favorable. Cela implique aussi de ne pas généraliser au-delà du jeu testé : les résultats obtenus sur un ensemble de tâches propres à une application constituent des éléments de preuve pour cette application et ces conditions, pas une garantie universelle sur R1.

Ne confondez pas le texte de raisonnement avec une explication fiable

La balise « <think> » fait partie de l’interface textuelle de certains formats de conversation de R1, mais l’observation de texte sous cette balise ne prouve pas qu’il s’agit d’une transcription complète ou littérale d’un processus interne. L’évaluation doit porter sur des résultats observables et vérifiables. Pour une réponse mathématique, vérifiez la réponse ; pour une extraction, comparez les champs au document ; pour une abstention, déterminez si les éléments disponibles étaient insuffisants.

L’étude publiée sous le titre DeepSeek-R1 Thoughtology analyse certains aspects du comportement de raisonnement de R1, notamment la longueur, la contrôlabilité et la rumination. Ce contexte justifie l’observation des réponses répétitives et de leur longueur, mais ne remplace pas les mesures propres à l’application et ne démontre pas à l’avance ce qui se passera si le modèle de prompt change. Une longue explication ne prouve pas, à elle seule, que la réponse est meilleure ; une explication brève ne prouve pas non plus que la tâche a été résolue sans raisonnement.

Si le produit ne doit ni afficher ni conserver ce contenu, vérifiez séparément ce que le runtime expose, ce que l’application enregistre et ce que l’utilisateur reçoit. Ne supposez pas que masquer une chaîne dans l’interface revient à la supprimer des journaux ou des traces. Ces propriétés dépendent de l’intégration et doivent faire l’objet de vérifications distinctes.

Consignez la décision dans un rapport de régression

Un rapport utile permet de reproduire l’expérience et de comprendre pourquoi une condition a été retenue. Incluez les révisions exactes du modèle et du modèle de chat, la configuration de génération, les prompts complets, le jeu de tâches et les règles de notation. Présentez les résultats par type de tâche, et pas seulement sous la forme d’un chiffre agrégé. Conservez des exemples représentatifs de réussites et d’erreurs, en traitant les données sensibles conformément aux politiques de l’équipe.

Décrivez ce qui a changé entre les conditions et ce qui est resté constant. Notez également les limites, par exemple si le service ne fournit pas la révision des poids ou si certains paramètres ne peuvent pas être contrôlés. Si le résultat n’est pas concluant, c’est une conclusion valable : vous pouvez élargir le jeu de tests, répéter l’expérience ou conserver la configuration en place pendant l’enquête. Ne transformez pas l’absence de preuve d’une régression en preuve de son absence.

La recommandation opérationnelle finale doit être précise : quel modèle de prompt est accepté, pour quelles tâches, avec quelle version et selon quels seuils. Si une variante ne fonctionne bien que pour un flux donné, limitez-la à ce flux au lieu de la présenter comme un modèle universel pour DeepSeek R1.

Critère pratique : conserver ce qui résiste à l’épreuve de l’application

Le modèle de prompt le plus utile pour une application DeepSeek R1 est celui qui améliore ses tâches sans affaiblir ses contrats de sortie ni ses mécanismes de sécurité et de récupération. Pour le déterminer, définissez une référence, isolez les changements, incluez des tâches variées, répétez les essais lorsque c’est pertinent et présentez les résultats de façon détaillée. Un préfixe, la position d’une instruction ou l’absence d’un message système ne doivent être ni adoptés par habitude ni écartés par intuition : il faut en vérifier les effets dans des conditions consignées.

Lorsque les résultats sont cohérents et respectent les seuils définis, déployez la configuration en surveillant les métriques qui ont motivé la décision. Si l’environnement, les poids, le modèle de chat ou les tâches évoluent, réévaluez les conditions pertinentes. Les recommandations officielles restent ainsi utiles comme hypothèses de départ, tandis que les éléments de preuve issus de l’application déterminent la configuration finale.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.