Z.ai: GLM 5.3 (batch)

Z.ai GLM 5.3 est un modèle de raisonnement textuel à grande échelle conçu pour l’ingénierie logicielle complexe et le travail des agents sur de longues séquences. Le fabricant indique qu’il utilise le même modèle de base que GLM 5.2, les nouveaux gains provenant du post-entraînement. Cette version vise une programmation renforcée, les opérations en terminal et des tâches plus larges comprenant plusieurs étapes dépendantes. Il accepte du texte et produit du texte, dont du code, des explications, des plans et des demandes d’appel d’outils dans une application connectée à des outils.

Le mode de raisonnement documenté est toujours activé. GLM 5.3 propose trois niveaux d’effort : low, high et max, avec max par défaut. Le fabricant recommande max pour les tâches de programmation complexes ; low offre une option de raisonnement plus légère pour les étapes simples. Associez le niveau sélectionné à un livrable final et à des critères d’achèvement clairs. Par exemple : « Examinez ces fichiers et résultats en échec, remontez à la cause dans les modules concernés, proposez une correction qui préserve l’interface publique et expliquez quelles vérifications établissent que la régression est résolue. »

Le fabricant spécifie une fenêtre de contexte de 1M tokens et une longueur de sortie maximale de 128K tokens. Organisez les longs contenus autour de la relation que le modèle doit étudier. Préservez les noms de fichiers, définitions pertinentes, étiquettes des sources et l’ordre des observations, et laissez de la place pour le raisonnement et la réponse finale dans le contexte de travail applicable. Une grande fenêtre est utile pour les dépendances entre modules ou une longue séquence d’observations d’agent ; elle ne transforme pas une archive sans objectif précis contenant des éléments sans rapport en une tâche bien définie.

Pour travailler sur un dépôt, fournissez le comportement attendu, le texte source pertinent, les versions des dépendances et la sortie d’erreur réelle. Demandez au modèle d’identifier le comportement affecté avant de proposer un correctif. Pour une refactorisation, nommez l’interface et les invariants à conserver intacts. Une réponse utile contient le code révisé, la raison pour laquelle la modification répond au problème observé et les cas nécessaires pour vérifier le résultat. Réinjectez les résultats réels dans un processus connecté aux outils pour que l’étape suivante repose sur l’état modifié plutôt que sur la proposition précédente.

Pour le travail sur les performances, fournissez une charge de travail, une référence de départ et des mesures telles que des durées, des profils ou des relevés d’allocation. Z.ai décrit des tâches d’entraînement portant sur le diagnostic des goulets d’étranglement, l’optimisation, les expériences et des résultats préservant l’exactitude. Une demande pratique est : « Utilisez ce profil pour identifier le goulet d’étranglement le plus déterminant, proposez une modification mesurable et expliquez quel résultat justifierait de la conserver. » Distinguez une hypothèse de performance d’une amélioration enregistrée. Conservez la même charge de travail et les conditions pertinentes lors de l’examen d’un résultat.

Cette version développe également la capacité d’analyse des vulnérabilités. Pour une revue défensive des sources, fournissez le code pertinent, ses frontières de confiance prévues et les conditions dans lesquelles il s’exécute. Demandez un constat qui relie un problème soupçonné à l’entrée et au comportement affectés, ainsi qu’à une correction ciblée. Séparez une faiblesse potentielle d’un défaut reproduit et conservez l’observation utilisée pour le valider. Un rapport est plus utile lorsqu’il privilégie des éléments concrets et des corrections proposées plutôt que de traiter chaque motif suspect comme une vulnérabilité confirmée.

L’appel de fonctions permet à l’application environnante d’exposer des opérations externes au modèle. Définissez l’objectif, les arguments et le résultat attendu de chaque outil, puis renvoyez l’observation réelle de l’outil pour l’étape suivante. Le modèle peut raisonner sur ce résultat et déterminer comment il modifie la tâche. Distinguez les actions proposées, les opérations exécutées et les vérifications non résolues. Le fabricant documente aussi des réponses en diffusion continue, qui renvoient séparément les fragments de raisonnement et de réponse ; assemblez la réponse complète avant de la traiter comme le rapport final ou l’explication du code.

La fiche locale du modèle fournit un détail précis de réglage de l’historique : son gabarit de conversation conserve la réflexion par défaut, tandis que le fabricant recommande d’effacer explicitement l’ancienne réflexion pour les conversations ordinaires. Appliquez la structure de conversation adaptée au cas d’usage, en conservant les réponses effectivement terminées et les résultats d’outils nécessaires à la poursuite. Évitez de traiter les paramètres de contrôle du raisonnement de GLM 5.2 ou des éditions distinctes GLM 5.3 Flash comme interchangeables avec les commandes low/high/max de ce modèle.

Pour les résultats structurés, précisez les champs, types et règles de source attendus. Un livrable utile peut être un tableau de défauts, un plan de modification ou un objet JSON résumant les observations. Validez la structure et les valeurs avant leur utilisation par une application. Le résultat final doit identifier la réponse ou le livrable révisé, les éléments qui l’étayent et les hypothèses restantes. Un effort de raisonnement accru n’établit pas qu’un outil a été exécuté, qu’un correctif proposé a passé ses vérifications ou qu’une affirmation factuelle est étayée au-delà des éléments fournis.