Comparaison des modèles de plates-formes Cursor : DeepSeek V3/R1 vs Claude 3.5 Sonnet Tests

DeepSeek Test du dernier modèle : V3 vs. Claude 3.5 Sonnet, qui est le meilleur ?

DeepSeek a récemment fait une annonce en Curseur La plateforme a lancé ses deux nouveaux modèles, DeepSeek V3 et R1. Actuellement, de nombreux développeurs (dont nous) utilisent Claude 3.5 Sonnet (dernière version claude-3-5-sonnet-20241022) comme modèle linguistique principal. Afin de voir comment les nouveaux modèles fonctionnent dans la pratique, nous avons décidé de faire un test de comparaison réel entre ces deux modèles DeepSeek et Claude 3.5 Sonnet.

Introduction au modèle DeepSeek

DeepSeek a fait l'objet de beaucoup d'attention ces derniers temps pour avoir mis en open source son puissant modèle R1, qui est censé être comparable au modèle o1 d'OpenAI en termes de performances, ce qui n'est pas une mince affaire. La plateforme Cursor a toujours été rapide à agir, et dès que le modèle DeepSeek a été mis en ligne, les gens étaient impatients de commencer à le tester dans des applications réelles.

Comparaison des performances Référence
Communiqué officiel de DeepSeek DeepSeek R1 et V3 par rapport aux modèles o1 et o1-mini d'OpenAI.

Vue d'ensemble des tâches de test

Ce test de comparaison comporte deux parties principales :

• Mode chat -- Simule des scénarios de développement quotidiens et explore comment ajouter des actions côté serveur à un composant de boîte de dialogue dans une application Next.js.
• mode de génération de code -- Modifier un fichier de configuration CircleCI pour simuler un scénario de maintenance de code dans le but de supprimer les étapes de configuration et de test E2E (de bout en bout) liées au déploiement du front-end qui ne sont plus nécessaires.

Il est important de noter que le "mode agent" de la plateforme Cursor, qui se réfère généralement à un mode dans lequel un modèle peut effectuer des opérations et invoquer des outils par lui-même, n'est actuellement disponible que pour la plateforme Cursor. Anthropique et GPT-4o sont ouverts, de sorte que ce test n'implique pas le modèle de substitution.

Comparaison des modes de discussion

déclaration de mission

La question que nous avons posée était de savoir comment ajouter correctement des actions côté serveur à un composant de boîte de dialogue dans une application Next.js. La question spécifique était la suivante :

"Veuillez expliquer comment mettre en œuvre une opération côté serveur et la transmettre correctement à ce composant de boîte de dialogue.

Afin de fournir un contexte plus spécifique, nous avons également joint le fichier contenant le code relatif au composant de la boîte de dialogue.

Performance de DeepSeek R1

Le DeepSeek R1 était naturellement notre premier choix pour les tests en raison de son profil élevé. Cependant, en utilisant le R1, nous avons rapidement découvert deux problèmes assez évidents :

• Le flux de sortie est lent
  R1 est lent à générer des réponses et doit attendre plus longtemps avant de voir le résultat complet.
• La réponse commence par un bloc clair
  R1 produit une grande partie du contenu entouré d'étiquettes avant de répondre formellement, de manière similaire à la présentation d'un processus de pensée. Cette étape de prétraitement est acceptable si elle améliore sensiblement la qualité de la réponse finale. Le problème, cependant, est que lorsqu'elle est superposée à une sortie en flux lent, elle retarde considérablement la présentation d'informations réellement valides. Par exemple, si le modèle produit une grande partie du contenu avant de diffuser lentement la réponse réelle, le temps d'attente total devient très long. En théorie, il serait possible de définir la règle du curseur de manière à ce qu'il saute des sections, mais cela n'entrait pas dans le cadre de ce test d'état par défaut.

De plus, la réponse de R1 suggère d'installer la bibliothèque next-safe-action/hooks pour résoudre le problème, mais elle n'explique pas davantage comment utiliser cette bibliothèque pour les opérations côté serveur dans une réponse ultérieure. Pour un problème relativement simple comme celui que nous avons posé, il semble un peu "trivial" de suggérer simplement l'installation d'une bibliothèque supplémentaire.

Performances de DeepSeek V3

DeepSeek V3 est également assez performant, il recommande même l'utilisation de l'option Réagir 19 de la nouvelle fonctionnalité useFormStatus, ce qui suggère que le modèle V3 apprend à connaître les technologies frontales et les bases de code les plus récentes. Cependant, V3 présente un bogue critique dans la mise en œuvre de son code : il appelle des opérations côté serveur directement à partir de composants côté client. Dans Next.js, cela n'est pas possible. (Pour mémoire, Next.js exige que le code côté serveur soit exécuté dans l'environnement côté serveur pour des raisons de sécurité, de performance et d'organisation du code, tandis que le code des composants côté client s'exécute par défaut dans le navigateur. L'appel du code côté serveur directement dans les composants côté client peut entraîner des erreurs telles que des modules côté serveur non trouvés, des requêtes réseau qui échouent, etc.) Par exemple, l'appel d'une fonction côté serveur directement dans un code JavaScript côté client entraînera une erreur d'exécution, ou le code côté serveur ne sera pas exécuté du tout.

Comme pour le R1, la vitesse de diffusion du V3 est plus lente. Mais comme la V3 n'a pas les longs blocs de la R1, l'expérience globale est légèrement meilleure que la R1.

Exécution du sonnet de Claude 3.5

En comparaison, Claude 3.5 Sonnet est le plus rapide, même en "mode requête lente" (par exemple, lorsque le nombre de requêtes API par mois dépasse le quota gratuit et entre dans une requête payante, il peut rencontrer une limite de vitesse de requête). Bien que Sonnet ne recommande pas la dernière fonctionnalité de React (useFormStatus) comme l'a fait V3, et fait une erreur similaire à V3 en appelant des opérations côté serveur directement dans les composants côté client, il donne une solution qui est plus proche de la réponse réelle disponible. Sonnet suggère que l'ajout de la directive "use server" aux fonctions d'opération côté serveur permettra d'éviter les erreurs d'utilisation. Sonnet suggère que l'ajout de la directive 'use server' aux fonctions d'action côté serveur satisferait les exigences de Next.js.(Complément de connaissances : "utiliser le serveur") est une directive clé introduite dans Next.js version 13 et suivantes pour déclarer explicitement une fonction en tant qu'opération côté serveur. En ajoutant la directive utiliser le serveur". Next.js peut alors reconnaître correctement la fonction comme du code côté serveur et permettre aux composants côté client de l'appeler en toute sécurité.) En fait, il suffit d'ajouter utiliser le serveur". Pour mémoire, la solution de Sonnet résout essentiellement le problème et est plus pratique que la solution donnée par le modèle DeepSeek.

Comparaison des modes de génération de code

déclaration de mission

Dans cette session de test, nous fournissons un profil CircleCI pour le déploiement d'une application full-stack. Cette application contient un front-end React pur et un back-end Node.js. Le processus de déploiement original contient plusieurs étapes. Notre objectif est de modifier ce fichier de configuration pour faire les deux choses suivantes :

• Supprimer toutes les configurations liées au déploiement du front-end
• Sachant que l'application n'est que back-end, les tests E2E (End-to-End Testing, généralement utilisés pour tester le flux complet des utilisateurs) ne sont plus nécessaires et les étapes de configuration correspondantes sont supprimées. (Connaissance ajoutée : les tests E2E sont principalement utilisés pour simuler le comportement de l'utilisateur et vérifier le flux complet des interactions front-end et back-end. Si l'application est laissée avec un back-end et aucune interface utilisateur, les tests E2E n'ont pas de sens. Les cadres de test E2E couramment utilisés sont Cypress, Selenium, etc.)

Nous indiquons explicitement dans l'invite de problème de "supprimer toutes les sections liées au déploiement frontal" et de fournir le fichier de configuration complet de CircleCI au modèle en tant que contexte.

Performance de DeepSeek R1

Nous nous attendions à ce que le modèle R1 avec blocs soit plus performant dans les tâches qui nécessitent une compréhension du contexte et des modifications multiples (tâches de compositeur). Or, ce n'est pas le cas :

• R1 omet certaines configurations qui sont clairement liées au déploiement du front-end (par exemple, la partie du fichier de configuration qui se réfère à la construction des références de l'application web est toujours préservée). Mais, à son crédit, il identifie correctement l'élément déployer-netlify (l'étape de déploiement sur la plateforme Netlify, qui est généralement utilisée comme plateforme d'hébergement de ressources statiques) Cette étape n'est plus nécessaire et a été supprimée.
• En même temps, R1 supprime incorrectement l'étape de déploiement du backend intitulée deploy_production_apice qui peut avoir pour conséquence que les services back-end ne soient pas déployés correctement. En outre, le système R1 indétectable Le test E2E n'est plus pertinent et conserve la configuration associée.

Performances de DeepSeek V3

DeepSeek V3 est légèrement plus performant que R1 pour les tâches de modification de code. Elle corrige certaines configurations de déploiement en amont que R1 n'avait pas détectées, mais elle expose également de nouveaux problèmes - par exemple, V3 conserve toujours l'étape deploy-netlify, ce qui suggère qu'elle ne comprend pas complètement les exigences de la tâche. À sa décharge, la V3 a fait un bon travail en conservant l'étape de déploiement du back-end, et n'a pas supprimé par erreur la configuration de déploiement du back-end comme elle l'a fait dans la version R1. Cependant, comme R1, V3 n'a pas non plus déterminé que la section de test E2E pouvait être supprimée.

Exécution du sonnet de Claude 3.5

Le vénérable Claude 3.5 Sonnet a obtenu les meilleurs résultats dans cette tâche de modification du code :

• Sonnet a réussi à supprimer la plupart des commandes liées au déploiement du front-endBien que, comme le V3, il soit également Échec de la suppression de l'étape deploy-netlify.
• En ce qui concerne les étapes de déploiement en arrière-plan, Sonnet a également conservé l'intégrité de la base de données duNon, il n'y a pas eu de suppression accidentelle.
• Sonnet a reconnu avec précision que les tests E2E n'étaient plus nécessaires car seuls les services back-end subsistaient.En conséquence, Sonnet a supprimé toutes les configurations liées aux tests E2E, y compris le Cypress Binary Cache, qui est utilisé pour accélérer les tests Cypress. En conséquence, Sonnet a supprimé toutes les configurations liées aux tests E2E, y compris le Cypress Binary Cache (le cache utilisé pour accélérer les tests de Cypress).(Connaissances ajoutées : le Cypress Binary Cache est utilisé pour mettre en cache les binaires nécessaires à l'exécution des tests Cypress, ce qui peut accélérer le démarrage des tests suivants. Toutefois, si le test E2E est supprimé, cette configuration de cache doit également être supprimée afin d'éviter les configurations redondantes). C'était la meilleure solution dans ce test, démontrant la compréhension profonde de Sonnet de l'intention de la tâche et sa capacité à faire des changements de code plus complets.

résumés

La plateforme Cursor introduit constamment de nouveaux modèles d'IA, apportant toujours de nouvelles options et possibilités aux développeurs. Bien que la tâche de ce test comparatif soit relativement simple, elle était suffisante pour démontrer initialement les capacités des deux modèles DeepSeek dans un scénario de développement réel. Comparés à Claude 3.5 Sonnet, les modèles de DeepSeek ont leurs propres forces et faiblesses.

Au final, Claude 3.5 Sonnet devance nettement les deux modèles de DeepSeek dans ce test, tant en termes de vitesse de réponse que de qualité de sortie. Bien que la vitesse de réponse du modèle DeepSeek puisse être améliorée dans les versions futures en raison de l'optimisation du serveur, de la distribution du réseau et d'autres facteurs, Claude 3.5 Sonnet reste dans le peloton de tête en termes de praticité et de fiabilité si l'on se réfère aux résultats réels des tests effectués jusqu'à présent.

Dans l'ensemble, ce test montre que Claude 3.5 Sonnet reste le choix le plus mature et le plus fiable sur la plateforme Cursor aujourd'hui. Cependant, le nouveau modèle de DeepSeek présente également un certain potentiel et mérite que les développeurs continuent de s'y intéresser et de l'expérimenter. Au fur et à mesure des itérations et des améliorations, le modèle pourrait se révéler plus performant à l'avenir.