Pourquoi ça compte
Quand LIA appelle un modèle de langage, elle lui envoie du texte : ta question, le contexte utile, et la description des outils qu'il peut utiliser. Ce texte se paie à la quantité, en jetons, et plus il est long, plus la réponse tarde. LIA couvre des dizaines de domaines et beaucoup d'outils. Les décrire tous à chaque demande coûterait cher, et un planificateur noyé sous les options choisit moins bien.
L'excès inverse est aussi un piège : retirer au modèle une information dont il a besoin, c'est l'obliger à deviner.
Ce que je voulais
Je voulais que chaque modèle reçoive ce dont il a besoin, rien de moins, et pas grand-chose de plus. Et qu'on n'appelle pas un modèle pour ce qu'une règle simple sait déjà faire. Trois services se partagent ce travail en amont du mode Pipeline, celui qui planifie avant d'agir.
Comprendre la question d'emblée
Le premier service lit ta question et en tire l'essentiel : est-ce une conversation ou une action, quels domaines sont concernés, à quoi renvoient tes mots. « Quel temps fait-il chez mon frère ? » touche la météo, mais aussi tes contacts, puisqu'il faut l'adresse de ton frère. « Ma femme » devient le prénom que ta mémoire connaît. « Le premier » désigne le premier élément de la liste que LIA vient de te montrer. Tout le reste du traitement part de cette analyse, sans la refaire.
Ne montrer que les bons outils
Le deuxième service prépare le catalogue que voit le planificateur : seulement les outils des domaines repérés et du type d'action demandé, décrits de façon compacte. Deux filets évitent que ce tri n'enlève l'essentiel. D'abord, si un outil retenu a besoin d'une donnée que seul un autre outil sait produire, cet autre outil est ajouté : sans lui, aucun plan ne serait possible. Ensuite, si malgré tout le planificateur ne trouve aucun plan exécutable, LIA recommence une seule fois avec un catalogue élargi. Tout cela se joue avant la moindre exécution.
Sauter ce qui est déjà connu
Le troisième service écrit le plan, et il sait parfois se passer de modèle. « Montre-moi le détail du premier » : l'élément est déjà identifié, le plan s'écrit directement. « Cherche le restaurant de ce rendez-vous » : le lieu de l'événement part tel quel vers la recherche de lieux.
Il s'appuie aussi sur des suites d'outils déjà validées, par exemple « chercher un contact, puis envoyer un e-mail ». Une suite souvent validée est suggérée au planificateur. Quand la confiance est très élevée, le plan peut même se dispenser d'une vérification supplémentaire par un modèle. Ce registre est commun à toute l'installation et ne retient que la suite d'outils, rien de ce que tu as écrit. L'opérateur peut y charger des suites de référence et, s'il le décide, laisser LIA enregistrer celles qui passent la vérification. Par défaut, cet enregistrement est coupé : LIA se sert des suites présentes sans en apprendre de nouvelles.
Les limites
Ce tri a ses angles morts. Si l'analyse rate un domaine, le planificateur ne voit pas ses outils, et le catalogue élargi ne sert qu'une fois. Les raccourcis ne couvrent que des cas simples. Le registre des suites retient ce qui marche pour tout le monde, pas tes préférences à toi. Et ces services préparent le mode Pipeline : en mode ReAct, LIA choisit ses outils autrement, soit par un classement de pertinence calculé sur ta question, soit en gardant tous tes outils sous la main, selon le rythme d'échanges que tu as choisi.
Pour approfondir : Retrouver ce qui compte sans tout ramener : les seuils de la recherche par le sens ; Un chef d'orchestre et des spécialistes : comment LIA traite ta demande.