DeepSeek R1 vs DeepSeek V3.2 : comment choisir entre raisonnement explicite et efficacité dans un flux révisable

La décision n’est pas de savoir quel modèle paraît meilleur, mais quel risque le flux réduit

La comparaison entre DeepSeek R1 et DeepSeek V3.2 doit partir d’une décision opérationnelle précise. Il peut s’agir, par exemple, d’analyser un dossier technique, d’identifier les exigences applicables dans des documents fournis par l’utilisateur, de produire une recommandation structurée et de préparer une action ultérieure. Cette action peut consister à créer un brouillon, ouvrir un dossier ou proposer un circuit d’approbation, mais elle ne doit pas être exécutée sans les validations humaines et système exigées par le processus.

Dans ce type de flux, une réponse longue ou un raisonnement visible ne constitue pas, en soi, un avantage. Ce qui compte est de savoir s’ils diminuent une erreur matérielle : une recommandation incompatible avec les éléments de preuve, une référence documentaire erronée, un outil appelé avec de mauvais paramètres, l’absence d’abstention lorsque les données sont insuffisantes, ou une sortie que le système destinataire ne peut pas traiter.

La question d’achat ou de déploiement peut être formulée de façon falsifiable : R1 réduit-il suffisamment les erreurs matérielles et la charge de revue humaine dans les cas ambigus et à étapes multiples pour compenser son temps de réponse, ses tokens et sa complexité ? Si V3.2 atteint le même seuil de correction, de preuve, d’abstention et de structure avec moins de ressources, un raisonnement plus long ne justifie pas à lui seul de lui acheminer la tâche.

Cet article ne suppose pas que l’un des deux modèles soit un substitut universel de l’autre. Il propose un test destiné aux responsables produit, plateforme et ingénierie qui doivent choisir une route selon le cas tout en conservant une approbation humaine pour les décisions ayant des conséquences opérationnelles.

Identifiez exactement ce qui est comparé avant de mesurer les résultats

« DeepSeek V3.2 » n’est pas un identifiant expérimental suffisant. La documentation de lancement présente DeepSeek-V3.2 comme le successeur de V3.2-Exp, tandis que le journal des modifications indique que les alias deepseek-chat et deepseek-reasoner ont été mis à jour vers DeepSeek-V3.2 le 1er décembre 2025. Un rapport reproductible doit donc consigner l’identifiant demandé, l’alias réellement utilisé, la date et l’heure d’exécution, le canal d’accès et la version ou révision de l’artefact local lorsqu’un checkpoint est exécuté.

La fiche publiée de DeepSeek-V3.2 permet de fixer un artefact pour une évaluation locale, mais un test local et un test via API ne sont pas automatiquement interchangeables. Ils peuvent différer par le matériel, le runtime, la quantification, le serveur d’inférence, les limites de contexte, les files d’attente, les contrôles de sécurité, la politique de reprises et la tarification. Le modèle conversationnel ou le traitement des outils peut également changer. La comparaison doit déclarer ces écarts au lieu de les attribuer au modèle.

DeepSeek R1 requiert lui aussi que la procédure utilisée soit documentée. Le dépôt officiel décrit un contexte de 128K et indique, pour son évaluation publiée, une génération maximale de 32 768 tokens, une température de 0,6 et un top_p de 0,95 pour l’échantillonnage. Ces paramètres ne garantissent pas qu’ils soient optimaux pour chaque tâche, mais ils constituent une référence importante. Si l’essai s’en écarte, il doit l’expliquer et évaluer si ce changement favorise ou désavantage R1.

Il n’est pas pertinent d’imposer une configuration identique lorsque les interfaces documentées ont des contraintes différentes. L’égalité utile est celle de l’opportunité de résoudre la tâche : même corpus, mêmes outils disponibles, mêmes règles de réussite, même limite de temps métier et politique de reprises définie avant l’observation des résultats. Les réglages propres à chaque modèle doivent être enregistrés comme partie intégrante de l’expérience.

Formulez une hypothèse qui peut être invalidée

L’hypothèse ne doit pas être que R1 « raisonne mieux » ni que V3.2 « est plus efficace ». Ces expressions sont trop imprécises pour une décision de plateforme. Une hypothèse utile pourrait être la suivante : dans les dossiers présentant des preuves contradictoires, des dépendances entre documents et un besoin de consulter des outils simulés, R1 atteint un taux plus élevé de décisions correctes et d’abstentions correctes, ce qui réduit de manière opérationnellement significative le nombre de revues humaines.

L’hypothèse inverse doit aussi être définie : pour les demandes directes, disposant de preuves suffisantes et comportant une seule étape décisionnelle, V3.2 atteint le seuil de qualité convenu avec une latence plus faible, moins de tokens de sortie ou un coût inférieur par résultat accepté. Dans ce cas, V3.2 deviendrait la route privilégiée pour cette strate, même si R1 obtenait une note moyenne légèrement supérieure.

Il convient de fixer à l’avance quel résultat invalide chaque proposition. Par exemple, R1 ne justifie pas une route spécialisée si son amélioration sur les erreurs matérielles ne dépasse pas la marge établie, si elle disparaît lors de la répétition des cas, ou si elle résulte d’un format de prompt, d’une récupération documentaire ou d’une infrastructure différents. V3.2 ne doit pas devenir la route par défaut s’il conserve un taux inacceptable de recommandations non étayées ou s’il ne s’abstient pas de manière adéquate.

Les seuils doivent être propres au processus. Un flux qui prépare des réponses internes à faible impact peut tolérer une revue par échantillonnage. Un flux qui affecte des engagements contractuels, des opérations ou des personnes peut exiger des preuves obligatoires, un blocage par règles et une approbation humaine dans tous les cas. L’évaluation mesure les performances dans des conditions données ; elle ne transforme pas le modèle en autorité autonome.

Concevez l’expérience pour mesurer une tâche, pas la capacité à impressionner

Constituez un corpus figé avant d’exécuter le premier modèle. Chaque cas doit contenir les documents et métadonnées reçus par les deux systèmes, une clé d’évaluation élaborée indépendamment et une étiquette de strate. Le corpus peut inclure des tâches directes, des dossiers longs, des ambiguïtés délibérées, des contradictions, des informations incomplètes et des cas dans lesquels la réponse correcte est de s’abstenir ou d’escalader vers une personne.

La clé d’évaluation doit distinguer les faits vérifiables des critères d’expertise. Les faits peuvent inclure une décision correcte, des champs obligatoires, des références à des preuves autorisées, les paramètres attendus des outils et les conditions d’abstention. Les critères d’expertise peuvent évaluer la clarté, la priorisation ou la qualité de l’explication. Ces derniers doivent être revus à l’aveugle quant au modèle, avec des consignes et une résolution des désaccords documentées.

Fournissez aux deux modèles exactement le même contenu métier et le même schéma de sortie. Si des outils sont activés, simulez des réponses déterministes afin qu’un écart ne provienne pas de systèmes externes changeants. Le guide des appels d’outils documente la prise en charge des outils en mode thinking à partir de V3.2 et un mode strict visant la conformité avec JSON Schema. Si cette option est utilisée, appliquez-la de façon cohérente là où elle est compatible et mesurez séparément la validité syntaxique du JSON et la validité sémantique de ses valeurs.

Consignez la température, top_p, la limite de sortie, la graine lorsqu’elle est disponible, le nombre maximal d’appels, la limite de temps et la politique de reprises. Pour R1, la documentation publiée recommande une configuration précise pour son évaluation et conseille plusieurs exécutions dans certains scénarios. Une seule réponse par cas ne suffit donc pas à estimer la stabilité : répétez chaque cas un nombre fixé à l’avance et communiquez la distribution des résultats, et non seulement le meilleur essai.

Ne mélangez pas les changements de prompt avec les changements de modèle. Si le format échoue, conservez une phase diagnostique distincte de la comparaison principale. Si le prompt ou le parseur est modifié après l’observation d’un échec, exécutez de nouveau les deux modèles avec la nouvelle configuration. Sinon, l’expérience ne distingue plus l’effet du modèle de l’effet de l’itération de l’équipe.

Mesurez séparément la correction, la preuve, l’abstention et le coût

L’exactitude finale est nécessaire, mais insuffisante. Une recommandation peut coïncider par hasard avec la clé tout en citant une preuve erronée ou en préparant une action avec des paramètres non sûrs. Mesurez la correction de la décision, la couverture des éléments obligatoires et la fidélité des preuves : chaque affirmation importante doit pouvoir être reliée à un extrait autorisé du corpus du cas.

L’abstention exige une métrique propre. Distinguez l’abstention correcte — le modèle identifie qu’il ne peut pas décider avec les données disponibles — de l’abstention excessive — il renvoie des cas pourtant résolubles — et de la fausse assurance — il décide alors qu’il aurait dû escalader. Cette dernière est souvent plus importante qu’une baisse modérée de productivité dans les processus à impact. La grille doit préciser quelles données absentes, quels conflits ou quelles limites d’autorité imposent une escalade.

Pour les outils, mesurez au moins quatre aspects : sélection de l’outil approprié, paramètres valides, interprétation correcte de la réponse et décision ultérieure cohérente avec cette réponse. Un appel dont le JSON est valide n’est pas nécessairement utile ; inversement, une réponse au format imparfait peut contenir une décision correcte que le système ne peut pas accepter. Conservez des métriques distinctes pour la structure et pour le contenu.

La mesure opérationnelle doit inclure la latence de bout en bout par percentiles, les tokens de sortie, le nombre d’appels d’outils, les reprises et le coût par cas accepté. Le dénominateur est important : diviser le coût par l’ensemble des réponses peut masquer le coût de celles qui sont réellement utilisables après validation. Communiquez aussi le volume de revue humaine requis et le temps de correction selon le type d’échec.

Diagnostiquez la cause d’un écart avant de l’attribuer au raisonnement

Présentez les résultats par strate en plus d’une moyenne globale. Une moyenne peut masquer que R1 n’apporte de valeur que dans une minorité de dossiers ambigus, ou que V3.2 résout suffisamment la plupart des demandes simples. Croisez les résultats avec la longueur du contexte, le nombre de documents, le besoin d’outil, la contradiction entre sources et la condition d’abstention.

Lorsqu’un écart apparaît, classez le premier point d’échec. Il peut se situer dans la récupération des preuves, la compréhension d’une instruction, la planification d’un appel, la génération d’arguments, le parseur, l’expiration du délai, la reprise ou l’infrastructure. Examinez les traces sans révéler à l’évaluateur quel modèle les a produites lorsque cela est réalisable. Le guide du mode thinking traite le contenu de raisonnement comme un élément ayant une gestion spécifique et fixe des exigences pour certains flux utilisant des outils ; le banc d’essai doit respecter ce contrat plutôt que de mélanger de façon improvisée les contenus de raisonnement à l’historique.

N’utilisez pas le raisonnement exposé comme preuve de vérité. Il peut aider au diagnostic si le canal et la politique de données autorisent son enregistrement, mais la validation doit reposer sur la sortie finale, les preuves fournies et les événements d’outils. De plus, la conservation de traces peut avoir des implications de confidentialité, de sécurité et de gouvernance qui doivent être évaluées séparément.

Si l’écart disparaît après égalisation de la quantification, du serveur, de la longueur maximale ou des reprises, le résultat ne démontre pas une supériorité générale du modèle. De même, si un modèle obtient un avantage parce qu’il reçoit un prompt spécialisé, la conclusion valable est que la combinaison modèle-configuration fonctionne mieux avec ce banc d’essai, et non que le modèle isolé est supérieur dans tout environnement.

Transformez les résultats en règle de routage et conservez des contrôles humains

La sortie de l’expérience doit être une règle opérationnelle, non une déclaration générale de vainqueur. Une politique possible consiste à envoyer à V3.2 les cas directs qui dépassent le seuil de correction, de preuve et de structure dans un budget défini ; à envoyer à R1 les dossiers comportant ambiguïté, dépendances multiples ou planification d’outils lorsqu’il a démontré une réduction matérielle des erreurs ; et à escalader vers une personne les conflits de preuves, les absences de données critiques et les cas hors de l’autorité déléguée.

Avant le déploiement, testez la règle en mode shadow. Le système peut produire une recommandation et une action préparée sans effet réel, pendant qu’un réviseur compare les résultats au processus existant. Mettez en place des alertes en cas d’augmentation des abstentions omises, de baisse des preuves valides, de dégradation de la latence ou de changement de comportement après une mise à jour d’alias ou d’infrastructure.

L’approbation finale ne doit pas être déléguée uniquement parce que le modèle a réussi un essai. L’évaluation ne prouve ni une connaissance à jour en dehors du corpus, ni la sécurité d’outils réels, ni la conformité réglementaire, ni la résistance aux entrées adversariales, ni la généralisation à un autre domaine. Elle n’élimine pas non plus le besoin d’autorisations minimales, de validation déterministe des paramètres, de journaux auditables et de mécanismes de réversibilité.

DeepSeek V3.2 dispose d’une disponibilité documentée dans l’application, sur le Web et via API, et la documentation de l’API décrit des capacités de thinking et d’outils. Ces faits facilitent la définition d’un essai, mais ne prouvent pas qu’un canal réponde à lui seul aux exigences de résidence des données, de rétention, de capacité, de prix ou de disponibilité. Ces conditions doivent être confirmées pour le compte, la région et la date de contractualisation concernés avant toute décision d’achat.

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.