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 d’agents à long horizon. 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 met l’accent sur une programmation renforcée, les opérations dans le terminal et des 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 comme valeur par défaut. Le fabricant recommande max pour les travaux de programmation complexes; low offre une option de raisonnement plus légère pour les étapes simples. Utilisez le niveau sélectionné avec un livrable final clair et des critères d’achèvement. Par exemple : « Examine ces fichiers et ces résultats d’échec, retrace la cause dans les modules touchés, propose une correction qui préserve l’interface publique et explique quels contrôles établissent que la régression est résolue. »

Le fabricant précise une fenêtre de contexte de 1M jetons et une longueur de sortie maximale de 128K jetons. Organisez le contenu long autour de la relation que le modèle doit examiner. Préservez les noms de fichiers, les définitions pertinentes, les étiquettes des sources et l’ordre des observations, et laissez de l’espace pour le raisonnement et la réponse finale à l’intérieur du contexte de travail applicable. Une grande fenêtre est utile pour les dépendances entre modules ou pour une longue séquence d’observations d’agent; elle ne transforme pas une archive non ciblée de contenus sans rapport entre eux en une tâche bien définie.

Pour le 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 de préciser le comportement touché avant de proposer un correctif. Pour un remaniement, 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 corrige 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é à des outils afin 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 initiale et des mesures comme 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 goulots d’étranglement, l’optimisation, les expériences et les résultats qui préservent l’exactitude. Une demande pratique est : « Utilise ce profil pour repérer le goulot d’étranglement le plus important, propose une modification mesurable et explique quel résultat justifierait de la conserver. » Distinguez une hypothèse sur les performances 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, ses frontières de confiance prévues et ses conditions d’exécution. Demandez un constat qui relie un problème présumé à l’entrée et au comportement touchés ainsi qu’à une correction ciblée. Séparez une faiblesse potentielle d’une défaillance reproduite et conservez l’observation utilisée pour la valider. Un rapport est plus utile lorsqu’il donne priorité aux preuves concrètes et aux corrections proposées plutôt que 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 retournez 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. Gardez distinctes les actions proposées, les opérations exécutées et les vérifications non résolues. Le fabricant documente aussi des réponses diffusées en continu, qui renvoient séparément les fragments de raisonnement et de réponse; assemblez la réponse terminée avant de la traiter comme le rapport final ou l’explication de code finale.

La fiche locale du modèle donne un détail précis sur le réglage de l’historique : son gabarit de clavardage conserve la réflexion par défaut, tandis que le fabricant recommande d’effacer explicitement l’ancienne réflexion pour les scénarios de clavardage ordinaires. Appliquez la structure de conversation appropriée au cas d’usage, en conservant les réponses réellement terminées et les résultats d’outils nécessaires à la poursuite du travail. Évitez de considérer les paramètres 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 les résultats structurés, précisez les champs, les types et les règles de source attendus. Un livrable utile pourrait ê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 préciser la réponse ou le livrable révisé, les éléments de preuve qui l’appuient 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 réussi ses contrôles ou qu’une affirmation factuelle est appuyée au-delà du contenu fourni.