Limites des capacités des grands modèles et évolution continue au niveau système

Les grands modèles sont désormais devenus unebase de capacitésfiable : compréhension sémantique, génération de code et de solutions, raisonnement multi-étapes, appels d'outils et de fonctions — elle suffit à soutenir un mode d'interaction où « poser une question produit immédiatement des candidats ». Mais plus cette base est puissante, plus elle masque facilement un fait d'ingénierie :le modèle génère les possibilités, mais la boucle fermée doit être portée par le système. Cette page vise précisément à démontrer cettelimite des capacités, et pourquoi l'évolution continue est une responsabilité au niveau système, et non un prolongement naturel des capacités du modèle.

I. Ce que le modèle maîtrise déjà

Compréhension sémantique: transformer une demande floue en une description de problème exécutable et identifier les contraintes et objectifs implicites.
Capacité de génération: produire en quelques minutes du code, des configurations, des solutions et des explications, avec auto-correction possible au sein d'un même échange.
Raisonnement multi-étapes: décomposer les tâches, enchaîner les déductions et justifier les compromis, avec une forme de sortie naturellement propice à « proposer des candidats et en expliquer les raisons ».
Appel d'outils: déclencher recherche, calcul et interfaces externes via des appels de fonctions, reliant les sorties linguistiques à des actions réelles.

Ces quatre points signifient ensemble que la « génération de candidats » est désormais quasi gratuite. La ressource vraiment rare n'est pas le nombre de candidats, maisle mécanisme qui applique une pression de sélection aux candidats.

II. Lacune structurelle : une seule session ne peut pas fermer la boucle

État volatil en session: dès que le contexte est épuisé, la mémoire inter-tâches se rompt et les leçons apprises lors du cycle précédent ne se transmettent pas automatiquement au suivant.
Absence de vérité de référence: le modèle ne peut ni définir par lui-même « ce qui est correct », ni fournir un critère d'évaluation indépendant de sa propre production.
Absence d'orchestration expérimentale: les tests de référence par lots, les tests de significativité statistique, la vérification de conformité aux contraintes, ainsi que l'exécution dans des environnements réels coûteux, échappent au contrôle du modèle.

La conclusion est claire : le modèle ne peut pas accomplir seul, en une seule session ou une seule tâche, la boucle ferméegénération de candidats — vérification en environnement — capitalisation des résultats. Ce n'est pas un manque de capacité, maisune responsabilité qui n'incombe tout simplement pas au modèle.

III. Les quatre types de travaux que le système doit prendre en charge

Génération et mutation de candidats: organiser les sorties du modèle, élargir activement et structurer l'espace de recherche.
Construction et invocation des environnements: mettre en place des environnements d'expérimentation reproductibles, en charge de l'orchestration, de l'exécution et de la validation.
Évaluation et sélection: définir la vérité de référence et les évaluateurs, réaliser le classement, la sélection et le jugement de significativité.
Capitalisation et réutilisation: inscrire les résultats réussis et les leçons des échecs dans la mémoire à long terme, pour en faire le point de départ de la tâche suivante.

Le principe de répartition tient en une phrase :le modèle génère les possibilités, le système applique la pression de sélection et préserve l'historique. Les deux sont irremplaçables — sans modèle, le système n'a pas de diversité à filtrer ; sans système, le modèle repart de zéro à chaque fois.

IV. Changement de critère : de « la qualité d'une sortie ponctuelle » à « l'amélioration peut-elle s'accumuler »

Pour juger si un système évolue réellement, le critère ne doit pas être « la qualité d'une sortie ponctuelle », mais « l'amélioration peut-elle s'accumuler d'une tâche à l'autre et d'un cycle d'Agent à l'autre ». Une sortie impressionnante mais non héritable reste essentiellement une consommation à usage unique. Lorsque la production de chaque tâche est figée en actifs d'ingénierie réutilisables — code, configurations, évaluateurs, recueil de cas d'échec — le point de départ des tâches suivantes est plus élevé que le précédent : c'est ce qu'on appelle l'Évolution continue au niveau projet. La pratique d'EvoX offre un paradigme de capitalisation d'ingénierie stable et fiable : à travers les Agents et les cycles de tâches, figer l'expérience en actifs plutôt que de la laisser dans l'historique des conversations.

Point de décision clé : la cause racine des problèmes de limites est une lacune d'architecture

Face à un problème d'« amélioration non cumulative », notre premier réflexe est souvent de « changer pour un modèle plus puissant ». Or la cause racine des problèmes de limites réside généralement dans une lacune d'architecture, et non dans une insuffisance du modèle. La bonne action est decompléter le système, et non de changer de modèle. Testez-le : confier la même tâche à un modèle plus performant suffit-il à obtenir automatiquement une mémoire inter-tâches, un jugement de vérité de référence et une orchestration expérimentale ? Si non, le problème ne vient pas du modèle.

Enfin, traçons une frontière avec les thèmes voisins : cette page démontre uniquement «pourquoi une évolution continue au niveau système est nécessaire», sans développer le mécanisme d'évolution à double niveau propre aux algorithmes (voir le contenu MetaDE ultérieur).

Schéma des relations entre les capacités des modèles d'IA et l'organisation de la boucle fermée au niveau système

Observez le schéma des relations entre les capacités des modèles d'IA et l'organisation de la boucle fermée au niveau système, puis présentez les points clés que vous relevez.

Question 1

Concernant les limites des capacités d'un grand modèle au sein d'une session unique, quelle description est la plus exacte ?

Il suffit que le contexte soit assez long pour que le modèle acquière automatiquement une mémoire à long terme inter-tâches.

Le modèle manque de capacités de compréhension et de génération du langage, il ne peut donc pas produire de candidats de façon autonome.

Le modèle peut générer des candidats, mais ne peut pas accomplir seul, en une seule session, la boucle fermée « génération de candidats — vérification en environnement — capitalisation des résultats ».

La capacité d'appel d'outils du modèle lui permet désormais d'orchestrer et de valider de façon autonome des expériences en environnement réel.

Question 2

Parmi les quatre types de travaux que le système doit prendre en charge, lequel cible directement la lacune de « l'absence de vérité de référence » ?

Évaluation et sélection

Construction et invocation des environnements

Capitalisation et réutilisation des résultats et des leçons d'échec

Génération et mutation de candidats

Question 3

Face au problème d'« amélioration non cumulative d'une tâche à l'autre », pourquoi « changer pour un modèle plus puissant » ne constitue-t-il pas une solution ?

Parce qu'un modèle plus puissant ne peut traiter qu'un contexte plus court.

Parce qu'un modèle plus puissant refuse d'exécuter des appels d'outils.

Parce que le coût d'appel d'un modèle plus puissant est trop élevé, le rapport coût-bénéfice n'est pas avantageux.

Parce que la cause racine des problèmes de limites est une lacune d'architecture : sans système, impossible d'appliquer une pression de sélection et de préserver l'historique ; changer de modèle ne modifie pas cette structure.

Question 4

Selon le changement de critère présenté sur cette page, quel est le bon critère pour juger si un système évolue réellement de façon continue ?

La taille des paramètres du modèle et la fenêtre de contexte sont-elles suffisamment grandes.

L'amélioration peut-elle s'accumuler d'une tâche à l'autre et d'un cycle d'Agent à l'autre, de sorte que le point de départ des tâches suivantes soit plus élevé que le précédent.

Le nombre de candidats produits par unité de temps est-il suffisamment élevé.

Le score d'une sortie ponctuelle lors d'une évaluation humaine est-il suffisamment élevé.

Question 5

Quelle est la valeur directe de figer la production de chaque tâche en actifs d'ingénierie réutilisables ?

Rendre l'appel d'outils inutile pour le modèle.

Empêcher à jamais l'épuisement du contexte d'une session unique.

Faire entrer les succès comme les échecs dans la mémoire à long terme, rehausser le point de départ de la tâche suivante et éviter de répéter les mêmes erreurs.

Réduire le coût de calcul de l'inférence du modèle.

Cas pratique : transformer une optimisation d'algorithme d'ordonnancement en une trajectoire expérimentale héritable

Lisez le scénario puis répondez aux deux questions ; vos réponses doivent refléter la frontière de répartition entre le modèle et le système.

Une équipe souhaite optimiser un algorithme d'ordonnancement central sur son propre planificateur, avec pour objectif de réduire simultanément la latence moyenne et la latence de queue sous une charge métier réelle, tout en respectant les contraintes existantes (limite mémoire, politique de timeout, compatibilité des interfaces). L'ingénieur confie le besoin à un grand modèle, qui fournit en quelques minutes une dizaine d'implémentations et explique clairement leurs compromis respectifs. Mais l'équipe découvre rapidement que personne ne peut confirmer laquelle est vraiment la meilleure : pas de référence unifiée, pas de processus d'exécution par lots, pas de jugement sur la significativité statistique, et personne n'a consigné « quel type de modification échoue systématiquement dans ce scénario ». Deux avis s'opposent au sein de l'équipe : l'un préconise de changer pour un modèle plus puissant, l'autre de commencer par compléter les capacités côté système.

Listez séparément : « les trois choses que le modèle peut accomplir seul » et « les trois choses qui doivent être prises en charge par le système » dans ce cas, puis expliquez pourquoi, en l'absence de ces dernières, l'amélioration retombe à zéro.

Réponse :
Ce que le modèle peut accomplir seul : ① transformer le besoin d'optimisation en une description algorithmique exécutable et identifier les contraintes ; ② générer une dizaine d'implémentations algorithmiques et leurs explications de compromis ; ③ mener un raisonnement multi-étapes et une auto-vérification au niveau du code, en fournissant une comparaison entre les candidats. Ce qui doit être pris en charge par le système : ① la génération et la mutation de candidats — organiser les sorties du modèle, élargir activement et structurer l'espace de recherche ; ② la construction et l'invocation des environnements — mettre en place des environnements de référence par lots, en charge de l'orchestration, de l'exécution et de la validation sous charge réelle ; ③ l'évaluation et la sélection — définir la vérité de référence et les évaluateurs, réaliser le classement, le test de significativité statistique et la vérification de conformité aux contraintes ; ④ la capitalisation et la réutilisation — inscrire les configurations exploitables et le recueil de cas d'échec dans la mémoire à long terme. En l'absence de ces dernières, les candidats ne peuvent être comparés, les conclusions ne peuvent être reproduites et l'expérience ne peut être héritée : la tâche suivante repart de zéro ; ce que l'on appelle « amélioration » n'est qu'une sortie à usage unique non vérifiée, d'où la retombée à zéro.

Supposons que l'équipe décide de compléter les capacités côté système : concevez les actifs que ce mécanisme de capitalisation doit contenir et expliquez comment il permet au point de départ de la tâche suivante d'être plus élevé que le précédent.

Réponse :
Quatre catégories d'actifs doivent être capitalisées : ① code et configurations réutilisables (implémentation gagnante, paramètres clés et options) ; ② évaluateurs réutilisables (script de référence unifié, logique de jugement de latence et de contraintes, procédure de test de significativité) ; ③ recueil de cas d'échec (quel type de modification échoue dans ce scénario, sous quelles conditions et avec quels signaux) ; ④ trajectoire expérimentale tâche-résultat (entrées, candidats, mesures et conclusions de chaque tentative). Le mécanisme qui rehausse le point de départ réside dans le fait que la tâche suivante ne repart plus d'une page blanche, mais d'un espace de candidats existant et de frontières d'échec connues ; les évaluateurs permettent de comparer immédiatement les nouveaux candidats au meilleur historique ; le recueil de cas d'échec élimine directement les solutions médiocres connues et réduit l'espace de recherche ; la trajectoire expérimentale unifie les référentiels de mesure, rendant l'amélioration cumulative, auditable et transmissible. Le système fournit la pression de sélection et la mémoire à long terme ; le modèle n'a plus qu'à se concentrer sur la génération de possibilités plus prometteuses.