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 venant du post-entraînement. La version se concentre sur une programmation renforcée, les opérations en terminal et les tâches plus larges comportant plusieurs étapes dépendantes. Il accepte du texte et produit du texte, notamment 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 la programmation complexe ; low offre une option de raisonnement plus légère pour les étapes simples. Associez le niveau choisi à un livrable final clair et à des critères d’achèvement. Par exemple : « Examinez ces fichiers et les résultats en échec, retracez la cause dans les modules concernés, proposez une correction qui préserve l’interface publique et expliquez quels contrôles établissent que la régression est résolue. »

Le fabricant précise une fenêtre de contexte de 1M tokens et une longueur de sortie maximale de 128K tokens. Organisez les éléments longs autour de la relation que le modèle doit étudier. Préservez les noms de fichiers, les définitions pertinentes, les libellés des sources et l’ordre des observations, et laissez de la place au 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 non ciblée d’éléments sans lien en 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 concerné avant de proposer un correctif. Pour une refactorisation, nommez l’interface et les invariants qui doivent rester intacts. Une réponse utile contient le code révisé, la raison pour laquelle la modification traite le 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 afin que l’étape suivante repose sur l’état modifié plutôt que sur la proposition antérieure.

Pour un travail de performance, fournissez une charge de travail, une référence 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 de goulots d’étranglement, l’optimisation, les expériences et les résultats préservant la validité du comportement. Une requête pratique est : « Utilisez ce profil pour identifier le goulot d’étranglement le plus important, proposez une modification mesurable et expliquez quel résultat justifierait de la conserver. » Distinguez une hypothèse de performance d’une amélioration constatée. Conservez la même charge de travail et les conditions pertinentes lors de l’examen d’un résultat.

La version développe aussi la capacité d’analyse des vulnérabilités. Pour une revue défensive du code source, fournissez le code pertinent, ses frontières de confiance prévues et les conditions d’exécution. Demandez un constat reliant un problème suspecté à l’entrée concernée, au comportement et à une correction ciblée. Distinguez une faiblesse potentielle d’un défaut reproduit et conservez l’observation utilisée pour la valider. Un rapport est plus utile lorsqu’il donne la priorité aux éléments concrets et aux corrections proposées, au lieu de traiter chaque motif suspect comme une vulnérabilité confirmée.

L’appel de fonctions permet à une 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 contrôles non résolus. Le fabricant documente aussi les réponses diffusées en continu, qui renvoient séparément les fragments de raisonnement et de réponse ; assemblez la réponse achevée avant de la considérer comme le rapport final ou l’explication du code.

La fiche du modèle local fournit un détail précis sur le réglage de l’historique : son gabarit de conversation conserve le raisonnement par défaut, tandis que le fabricant recommande d’effacer explicitement l’ancien raisonnement dans les scénarios de conversation ordinaires. Appliquez la structure de conversation adaptée au cas d’usage, en préservant les réponses réellement achevées et les résultats d’outils nécessaires à la poursuite. Évitez de considérer les réglages de raisonnement de GLM 5.2 ou des éditions distinctes GLM 5.3 Flash comme interchangeables avec les réglages low/high/max de ce modèle.

Pour des résultats structurés, précisez les champs attendus, les types et les règles relatives aux sources. 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 qu’une application les utilise. 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 contrôles ou qu’une affirmation factuelle est étayée au-delà des éléments fournis.