Aujourd'hui, la plupart des systèmes d'intelligence artificielle personnalisent surtout ce qui est visible : le ton, le niveau de détail, le format ou le vocabulaire employé.
Cette personnalisation peut être utile, mais elle agit principalement sur la manière dont la réponse est formulée. Elle ne garantit pas que le modèle ait analysé le problème différemment.
Latcher explore une autre direction :
Construire une architecture capable d'apprendre progressivement quelles transformations internes sont utiles pour un utilisateur ou un environnement donné, sans imposer au modèle une réponse précise ni un chemin de raisonnement prédéfini.
Le système cherche plutôt à placer le modèle dans des états où d'autres voies deviennent accessibles. Le modèle reste alors libre d'explorer, de comparer et de découvrir lui-même la direction la plus pertinente.
L'ambition n'est donc pas de dire au modèle où il doit arriver.
Elle consiste à modifier temporairement les conditions de sa réflexion afin qu'il puisse emprunter des chemins qu'il n'aurait pas nécessairement explorés spontanément, puis apprendre avec le temps lesquels produisent les effets les plus utiles.
Cette personnalisation ne repose pas sur l'ajout du profil de l'utilisateur sous forme de texte dans la fenêtre de contexte du Core. Le modèle reçoit toujours la question ou la tâche à traiter, mais les informations durables sur l'utilisateur — son historique, ses besoins, les stratégies déjà essayées ou les effets observés — sont exploitées par Echo, puis traduites en modulations internes. L'information de personnalisation est donc transmise au modèle par un canal différent du prompt.
Ne pas personnaliser uniquement la surface
Deux utilisateurs peuvent poser exactement la même question sans avoir besoin du même raisonnement pour parvenir à une réponse utile.
Dans un contexte éducatif, un élève peut avoir besoin que le modèle conserve plusieurs hypothèses avant de choisir. Un autre peut bénéficier d'une vérification plus rigoureuse. Un troisième peut au contraire avoir besoin d'une démarche plus directe, afin de ne pas rendre le problème inutilement complexe.
Les approches classiques peuvent demander explicitement au modèle :
- —d'être plus prudent ;
- —de raisonner étape par étape ;
- —de vérifier sa réponse ;
- —d'adopter une méthode particulière.
Mais cela revient encore à lui fournir une cible définie à l'avance.
Latcher cherche à fonctionner autrement. Le système ne lui dicte pas exactement la stratégie à suivre. Il modifie certaines conditions internes pour rendre accessibles plusieurs formes de raisonnement, puis laisse le modèle produire sa propre trajectoire.
La réponse finale ne serait donc pas la reproduction d'une méthode imposée. Elle émergerait d'un espace de réflexion temporairement élargi ou réorganisé.
Personnaliser sans injecter le profil dans le contexte
Dans de nombreux systèmes, la personnalisation consiste à ajouter au prompt des informations telles que le niveau de l'utilisateur, ses préférences, son historique ou des consignes sur la manière de lui répondre.
Latcher cherche à séparer ces informations de la fenêtre de contexte utilisée par le Core.
Le Core reçoit la demande actuelle et conserve la responsabilité du raisonnement. En revanche, le profil durable de l'utilisateur n'est pas ajouté à la conversation sous forme d'un bloc de texte qu'il devrait lire et interpréter.
Ces informations sont traitées en amont par Echo. Echo transforme l'état de l'utilisateur en signaux de modulation capables d'agir directement sur les conditions internes du raisonnement du Core.
Ainsi, le système peut produire une adaptation très précise sans remplir la fenêtre de contexte avec une description de l'utilisateur ni lui imposer une consigne explicite.
Le profil n'est pas raconté au Core : il est traduit en conditions internes de raisonnement.
Explorer avant de décider
Un modèle de langage possède naturellement des préférences : il privilégie certaines interprétations, certaines méthodes et certaines conclusions plutôt que d'autres.
Ces préférences sont utiles, mais elles peuvent aussi l'amener à :
- —choisir trop rapidement la première solution ;
- —ignorer une hypothèse moins évidente ;
- —conclure avant d'avoir vérifié ;
- —poursuivre une représentation du problème devenue peu adaptée.
Latcher cherche à intervenir à ce niveau.
Il pourrait permettre au modèle de maintenir momentanément plusieurs directions possibles, d'en approfondir certaines, d'en abandonner d'autres et de décider ensuite laquelle mérite d'être poursuivie.
L'objectif n'est pas de remplacer la décision du modèle par celle d'un contrôleur externe.
Latcher ne choisit pas la réponse idéale à la place du modèle. Il cherche à créer les conditions permettant au modèle de la découvrir lui-même.
Une architecture qui apprend dans le temps
Cette logique ne repose pas uniquement sur une intervention ponctuelle.
Latcher est conçu comme un système capable d'apprendre progressivement des effets de ses propres actions.
Une intervention peut sembler pertinente immédiatement, tout en étant inutile ou nuisible à plus long terme. Dans l'éducation, par exemple, une réponse correcte ne signifie pas nécessairement que l'élève a compris, retenu ou gagné en autonomie.
Le système doit donc observer une chaîne plus large :
À partir de ces observations, il pourrait apprendre quelles interventions semblent utiles, pour quels profils, dans quelles situations et avec quelles limites.
Cet apprentissage ne consiste pas à mémoriser une réponse idéale pour chaque utilisateur. Il consiste à construire progressivement une compréhension de la manière dont certaines transformations du raisonnement influencent les résultats.
Dans la vision mature de Latcher, cette organisation repose sur trois fonctions principales : le modèle qui raisonne, le contrôleur qui organise temporairement la réflexion et le système d'apprentissage qui observe les effets et améliore les interventions futures.
Core, Echo et Forge
Le Core est le modèle de langage.
Il comprend la demande, réalise le calcul et produit la réponse finale. Il reste responsable de ce qu'il écrit.
Latcher ne cherche pas à remplacer ses capacités ni à rédiger à sa place.
Echo est le contrôleur de la réflexion.
Il ne connaît pas nécessairement à l'avance la réponse correcte ou la trajectoire parfaite. Son rôle est plutôt de modifier temporairement les possibilités offertes au Core : maintenir une alternative, encourager une exploration, retarder une conclusion ou augmenter le niveau de vérification.
Echo agit sur les conditions du raisonnement, pas directement sur le texte final.
Il constitue également l'interface entre la mémoire durable de l'utilisateur et le Core. Cette mémoire n'est pas copiée dans le prompt : Echo l'interprète et la convertit en modulations internes adaptées à la situation présente.
Forge représente la capacité d'apprentissage du système.
Il observe ce qui s'est passé après les interventions : ce qui a aidé, ce qui a échoué, ce qui a produit un effet inattendu et ce qui semble se reproduire.
Avec le temps, Forge doit permettre à Latcher de mieux sélectionner les transformations utiles, sans enfermer le modèle dans une stratégie fixe.
De nombreux travaux existent déjà sur la modulation interne
L'idée d'intervenir directement dans les représentations internes des modèles de langage n'est pas nouvelle.
Plusieurs travaux ont montré qu'il était possible de modifier les activations d'un modèle afin d'influencer des propriétés comme le sentiment, le respect d'instructions ou certains comportements. L'activation engineering et la representation engineering ont contribué à structurer ce domaine. ReFT apprend des interventions sur les représentations cachées d'un modèle gelé. HyperSteer génère des vecteurs de contrôle conditionnés par une demande et par les états internes du modèle. Des travaux plus récents explorent également des formes de contrôle en boucle fermée.
Ces recherches montrent que les modèles peuvent être influencés de l'intérieur.
Elles montrent aussi les limites de l'exercice : une direction de contrôle peut fonctionner sur certains exemples et produire l'effet inverse sur d'autres ; une intervention trop forte peut dégrader la qualité ; et certains comportements ne correspondent pas nécessairement à une direction interne simple et stable.
Latcher ne part donc pas d'un territoire vide. Il s'inscrit dans un domaine de recherche déjà actif.
Ce que Latcher cherche à apporter de différent
La différence recherchée ne repose pas simplement sur une nouvelle manière d'ajouter un vecteur dans un modèle.
Elle repose sur la combinaison de plusieurs principes.
Ne pas utiliser la fenêtre de contexte comme canal principal de personnalisation
Latcher ne cherche pas à personnaliser le Core en ajoutant continuellement son historique, son profil ou ses besoins sous forme de texte dans le prompt.
Ces informations restent extérieures au contexte de génération. Elles sont interprétées par Echo, qui les transforme en interventions internes temporaires.
Cette séparation vise deux objectifs : préserver la fenêtre de contexte pour la tâche en cours et permettre une personnalisation qui ne dépend pas de la capacité du Core à relire puis à suivre une longue description textuelle de l'utilisateur.
Ne pas imposer une cible comportementale unique
Beaucoup de méthodes de steering cherchent à rapprocher le modèle d'un comportement défini à l'avance : davantage d'honnêteté, un sentiment particulier, une meilleure conformité à une instruction ou une représentation cible.
Latcher cherche plutôt à intervenir sans définir entièrement la trajectoire finale.
Le système peut favoriser l'exploration, maintenir plusieurs alternatives ou modifier la manière dont le modèle répartit son effort, mais il laisse au Core la responsabilité de trouver la solution.
Il existe toujours des objectifs généraux — exactitude, sécurité, utilité pour l'utilisateur — mais pas nécessairement une réponse ou un raisonnement précis à reproduire.
Personnaliser à partir d'un état durable
L'intervention n'est pas déterminée uniquement par la requête actuelle.
Elle peut dépendre d'un état construit dans le temps : historique de l'utilisateur, stratégies déjà essayées, effets observés, incertitudes et évolution du contexte.
La personnalisation devient alors longitudinale plutôt que ponctuelle.
Apprendre à partir des conséquences
Latcher ne cherche pas uniquement à savoir si une intervention a modifié la sortie.
Il cherche à apprendre si cette modification a réellement produit un effet utile.
Cette boucle entre intervention, conséquence et apprentissage constitue l'un des centres de la vision.
Séparer stratégie et apparence
Un modèle peut écrire « vérifions notre réponse » sans avoir réellement effectué une vérification utile.
Latcher cherche donc à mesurer ce qui a changé dans la dynamique du modèle, et pas seulement dans son vocabulaire ou la structure visible de son texte.
Rester temporaire et réversible
Les interventions ne doivent pas devenir une personnalité artificielle permanente.
Elles sont conçues pour être limitées, surveillées et retirées. Le modèle doit pouvoir revenir à son fonctionnement normal lorsque le contrôle n'est pas nécessaire.
Une réponse qui reste celle du modèle
L'un des principes les plus importants de Latcher est que le modèle doit rester l'auteur de sa réponse.
Le système ne cherche pas à lui fournir une conclusion cachée ni à construire une phrase qu'il devra ensuite reproduire.
Il agit en amont : sur les possibilités, les priorités et les directions accessibles pendant la réflexion.
Cette intervention ne prend pas la forme d'une consigne textuelle ajoutée au contexte du Core. Le modèle ne reçoit pas une description du profil lui indiquant comment répondre ; il reçoit uniquement la tâche, tandis qu'Echo module directement certaines conditions internes de son calcul.
Puis l'intervention est retirée.
La réponse finale doit rester le produit naturel du Core, mais d'un Core ayant pu explorer une trajectoire différente de celle qu'il aurait suivie spontanément.
L'éducation comme premier terrain
L'éducation constitue le premier terrain d'application de cette recherche.
Elle permet d'étudier une personnalisation qui dépasse largement les préférences de style. Les besoins d'un élève évoluent selon les notions, les erreurs rencontrées, son niveau d'autonomie et les stratégies pédagogiques qui ont déjà fonctionné ou échoué.
Mais la vision de Latcher ne se limite pas à l'éducation.
Une architecture capable d'apprendre à adapter la délibération d'un modèle pourrait également être étudiée dans l'informatique, la recherche, l'analyse complexe, l'accompagnement professionnel ou d'autres environnements où les utilisateurs et les situations nécessitent des stratégies différentes.
Une architecture encore à prouver
Latcher est avant tout un programme de recherche.
Sa valeur ne dépendra pas uniquement de l'élégance de ses concepts, mais de sa capacité à démontrer plusieurs choses :
que les interventions modifient réellement la stratégie du modèle, qu'elles ne dégradent pas ses capacités, qu'elles restent contrôlables et que l'apprentissage à partir des effets produit une amélioration réelle.
La vision est ambitieuse, mais elle doit rester falsifiable.
Cette introduction présente volontairement l'architecture de manière générale. D'autres articles détailleront progressivement :
- —comment le système représente l'état d'un utilisateur ;
- —comment Echo intervient sans imposer une réponse ;
- —comment plusieurs voies de raisonnement pourraient être maintenues ;
- —comment distinguer une stratégie réelle d'une modification de style ;
- —comment Forge apprend à partir des conséquences ;
- —comment les mécanismes de contrôle et de sécurité encadrent l'ensemble.
Latcher part finalement d'une question centrale :
Peut-on construire une intelligence artificielle qui n'apprend pas seulement à mieux répondre, mais à découvrir progressivement comment organiser sa propre réflexion pour chaque utilisateur et chaque situation ?
