Z.ai: GLM 5.3 (batch)

Z.ai GLM 5.3 est un modèle de raisonnement textuel à grande échelle conçu pour le génie logiciel complexe et le travail d'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 interdé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, max étant la valeur par défaut. Le fabricant recommande max pour les travaux de programmation complexes ; low propose un raisonnement plus léger 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 ces résultats en échec, remontez à 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 spécifie une fenêtre de contexte de 1M tokens et une longueur maximale de sortie de 128K tokens. Organisez les contenus longs autour de la relation que le modèle doit examiner. Conservez les noms de fichiers, les définitions pertinentes, les étiquettes 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 sans orientation, composée d'éléments sans rapport, en une tâche bien définie.

Pour un travail 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 refonte du code, 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 à la vérification du résultat. Réinjectez les résultats réels dans le processus connecté aux outils pour que l'étape suivante repose sur l'état modifié plutôt que sur la proposition précédente.

Pour un travail sur les performances, fournissez une charge de travail, une référence initiale et des mesures telles que des durées, profils ou 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 les résultats qui préservent le bon fonctionnement. Une requête pratique est : « Utilisez ce profil pour identifier le goulet d'étranglement ayant le plus d'impact, proposez une modification mesurable et expliquez quel résultat justifierait de la conserver. » Distinguez une hypothèse de performance d'une amélioration mesurée. Conservez la même charge de travail et les conditions pertinentes lorsque vous examinez un résultat.

Cette version développe aussi la capacité d'analyse des vulnérabilités. Pour une revue défensive du code source, fournissez le code pertinent, les frontières de confiance prévues et ses conditions d'exécution. Demandez un constat qui relie le problème suspecté à l'entrée concernée, au comportement et à une correction ciblée. Séparez une faiblesse potentielle d'un défaut reproduit et conservez l'observation ayant servi à le valider. Un rapport est plus utile lorsqu'il donne la priorité aux preuves concrètes 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 de chaque outil, ses arguments et son résultat attendu, puis retournez l'observation réelle de l'outil pour l'étape suivante. Le modèle peut raisonner sur ce résultat et déterminer son effet sur la tâche. Gardez distincts les actions proposées, les opérations exécutées et les contrôles non résolus. Le fabricant documente également des réponses en diffusion continue, qui renvoient séparément des fragments de raisonnement et de réponse ; assemblez la réponse achevée 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 gestion de l'historique : son gabarit de conversation conserve le raisonnement par défaut, tandis que le fabricant recommande d'effacer explicitement l'ancien raisonnement pour les conversations ordinaires. Appliquez la structure de conversation adaptée à l'usage, en conservant les réponses effectivement achevées et les résultats d'outils nécessaires à la continuation. Ne considérez pas les réglages de 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 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 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 supérieur n'établit pas qu'un outil a été exécuté, qu'un correctif proposé a réussi ses contrôles ou qu'une affirmation factuelle est étayée au-delà des éléments fournis.