Compte-rendu du premier atelier "Connaître et évaluer les systèmes d'automatisation complexes pour les revues", Introduction aux architectures de systèmes complexes intégrant de l'"IA", présentation d'Alexia Schneider
Captation de l’atelier et des échanges qui ont suivi disponible sur Nakala : https://nakala.fr/10.34847/nkl.7eaeg131
Support disponible : https://alexiaschn.github.io/blog/slides/26-02-12_revue30_atelierAutomatisationSeance01.html#/title-slide
Présentation
Systèmes d’IA complexes
Dans l’IA générative, il y a toujours une instruction en langue naturelle.
Aujourd’hui, l’intégration des LLMs dans des pipelines est plus complexe.
Chatbot grand public : des applications qui vont interagir avec des LLMs. Les chatbot n’ont aucun impact sur le modèle, n’aident pas à l’explicabilité du modèle.
Agents IA: notion d’autonomie et d’agentivité. Un agent est en réalité un concatenation d’appels à un modèle.
Architecture d’un agent IA
Le "prompt système" contient une série d’instructions en langue naturelle:
- description du caractère attendu du LLM.
- description des outils
- description du format attendu de la réponse (JSON, XML, md etc.)
- + demande de l’utilisateur.ice.
L’"agent IA" procède par itération et concatenation des requêtes. Il y a notamment un processus de "pensée" (le modèle se "parle" avant de répondre).
RAG (Retrieval-Augmented Generation)
Les LLMs présentent deux grandes limites :
- La fenêtre contextuelle reste limitée (limitation du prompt malgré les progrès déclarés des entreprises)
- La représentation vectorielle du modèle est figée sur les données d’entrainement.
Principe du RAG : chercher à combler ces limites en externalisant des données qui peuvent être recherchées par le LLM si besoin.
Un RAG intègre au _prompt system_ envoyé à un LLM des morceaux ou chunks extraits de documents sources sélectionnés par la méthode de RI.
Architecture :
- Documents sources sélectionnés.
- Pré-traitement : vectorisation des textes contenus dans les documents et enregistrement dans un vector-store au besoin.
- Recherche d’information = extraction des informations pertinentes : Les stratégies de recherche d’information sont diverses. La RI peut être par recherche lexicale (TFiDF ou BM25) équivalente à un Ctrl+F boosté, ou par recherche dite "sémantique" par calcul de proximité cosinus des vecteurs (proximité entre la requête utilisateur et les documents sources).
- Pour un LLM - préférence pour les éléments en tête et en fin de prompt. Le RAG améliore le prompt en allant chercher des données externes qui enrichissent le prompt.
Plusieurs éléments importants à prendre en compte pour savoir à quoi s’intéresser/comment évaluer :
- les jeux de données externes peut être biaisés
- ajout de couches d’interprétation car plusieurs appels à des LLMs
- dissémination de l’information (quand elle se trouve dans plusieurs sources)
- angles morts quand l’information importante/recherchée est dans un morceau non extrait.
Questions qui préoccupent actuellement beaucoup les développeurs. --> Stratégie modes de censure actuels : il est plus simple de ne pas faire apparaître une information dans la grande masse informationnelle, plutôt que de simplement la supprimer (modification des stratégies des grandes plateformes). L’information parfois dite censurée n’a en fait jamais été prise en compte dans le prompt.
Discussion
Marcello Vitali-Rosati : "Je suis frappé par notre engouement pour des systèmes aberrants." --> multiplication des intermédiaires et des opérations (demander à un LLM de résoudre une opération simple au lieu de cliquer sur l’outil calculette). Energie computationnelle immense pour des choses qui ne sont pas complètement sûres (pas un système expert mais un système inductif). Délégation d’un effort cognitif minime.
Rhétorique de l’affranchissement pour les tâches lourdes, mais cet affranchissement implique une dépendance croissante pour un gain minuscule, par rapport au poids de l’infrastructure à maintenir.
Alexia Schneider : Ex. une requête LLM = 10 requêtes Google
Alix Chaguée (dans le chat): Je suis curieuse de savoir si tu as des détails à donner sur la manière dont fonctionne la partie "thinking" d’un LLM. Est-ce que le modèle s’appelle lui-même ? (si on reprend ton schema sur les séquence de préparation du prompt)
je pense à un exemple hier, je testais un VLM pour de la transcription, sa section "thinking" était pleine de "But wait, the user asked for A..." etc.
Alexia Schneider : Les LLM de raisonnement ne sont pas conçus pour de longues interactions. On a plutôt un système d’envoi de prompt à un LLM lui-même prompté pour interagir avec plusieurs autres LLM comme orchestrateurs. C’est lui qui gère la fonction "raisonnement". Cela permet de diviser les questions de raisonnement pour éviter les délais de latence.
Nicolas Sauret : est-ce qu’il y a une relation entre la partie "thinking" et la réponse finale ?
Tests avec Deepseek : parfois il ne prend pas la même décision, interprétait différemment le prompt initial. Est-ce du vent ou une vraie relation?
Alexia Schneider : on a fait des évaluations et les modèles donnent de meilleurs résultats si on les fait d’abord réfléchir plutôt que répondre d’abord et justifier ensuite. On s’est aperçu de lacunes dans les raisonnements un peu complexes (tests de turing par ex). Si on lui demande de réfléchir "step-by-step" (prompt Chain of Thought) amélioration du texte généré.
Marcello Vitali-Rosati : dans un système agentique on a le choix d’ajouter les parties de raisonnement dans le prompt pour la nouvelle itération ou non pour que le modèle se réponde à lui-même. Parfois il itère sur ses propres réponses.
Frédéric Clavert : nécessaire de mettre les pratiques de RAG en commun entre les communautés en SHS pour éviter GAFAM. Un petit RAG bien fait et fait maison : à la fois moins cher et plus efficace. Réflexion à avoir sur les pratiques qu’on a (cf exemple de la taille des chunks).
Marcello Vitali-Rosati : il y a Huma-Num qui travaille à l’implémentation de RAG sur Isidore. Potentiellement, discussion avec Stéphane Pouyllau et échange avec les revues et des chercheurs. PleIAs développe des petits modèles qui pourraient être adaptés au besoins des sciences humaines.
Frédéric Clavert (dans le chat): "Une anecdote: pour améliorer la vitesse d’une query sur RAG, j’avais "compressé" les chunks. Mais mes documents commençaient tous par la liste des personnes présentes à ces réunions du Comité des gouverneurs des banques centrales de la CEE, avec les mêmes personnes souvent présentes, puisqu’ayant un mandat de gouverneur de banque centrale assez long. Le résultat, c’est que le modèle, en se fondant sur les sources que j’avais fournies au système de RAG, ne voyait un gouverneur (Bernard Clappier, en l’occurrence) comme n’ayant participé qu’à une seule des réunions du comité, alors qu’il a été présent à ces réunions mensuelles pendant presque toutes les années 1970. Tous les chunks comprenant la liste des présents avaient été compressés en un seul chunk. bref, avec le RAG, le diable est dans les détails et l’utilisateurice a quand même intérêt à savoir ce qu’il se passe assez précisément."
Discussion sur les besoins spécifiques des revues.
Marcello Vitali-Rosati : On n’est pas obligés de suivre mode des GAFAM / évaluation par chatbot, mais si on se pose la question de comment ça marche, on peut plutôt tester des outils et des méthodes en interne.
Ex : analyse par RAG d’un article de revue de la littérature avec objectif de faire sortir points forts et faibles
Nicolas Sauret : question de la vérification : soit on va prendre la réponse du Chatbot telle quelle, soit on vérifie l’information => pas de gain du temps si on veut des réponses de qualité.
Marcello Vitali-Rosati : L’intérêt est dans le gain de la qualité, et non dans le gain du temps. Ex. recherche de sources pour revue de littérature, ou pour relecture (pour trouver des informations et les comparer avec les informations dans le texte à évaluer) --> Enjeux sur la bonne structuration de la bibliographie
Interface : moins là pour gagner du temps que pour gagner de la profondeur.
Alexia Schneider : possibilité d’entraîner un modèle pour faire de la classification qui appuierait l’évaluation de la revue de littérature.
Nicolas Sauret : on revient à un question presque ontologique, sur c’est quoi le travail d’un chercheur (cf. discussion autour de l’usage d’IA pour la structuration bibliographique). finalement ces technologies nous font prendre du temps.
Marcello Vitali-Rosati : 2 possibilités :
* Soit on refuse en bloc (on dit "c’est un truc des GAFAM, ça nous intéresse pas") ;
* Soit on prend la technologie à l’origine des LLMs et essaye de créer nos modèles (usage de ce type de LLMs pour enrichir la reflexion, pas pour gagner du temps)
Imaginer des économies qui portent des valeurs différents ; les LLMs ne portent pas de valeur productiviste intrinsèquement.
Approches algorithmiques ont un intérêt mais la manière de les marketer et vendre actuellement est aberrante.
Nicolas Sauret : les besoins des revues sont d’abord des questions de ressources (financières et humaines). Chercher à faire quelque chose plus rapidement, pour remplacer le mi-temps /
Besoin chercheurs / besoin éditeurs de revue sont-ils les mêmes ?