Les services IA de DnC

Orchestration : ReAct et Backtracking

Bertrand Degoy — 2026-05-17T10:04:49Z

Une boucle ReAct "Raisonne" en marche avant, selon une suite d'étapes successives. Si le raisonnement échoue à donner une réponse à la question posée, la boucle s'arrête sans réponse. Même si une réponse est trouvée, elle n'a pas été élaborée par l'exploration de plusieurs branches : le résultat reste non exhaustif.
Cet article décrit comment on pourrait revenir en arrière et recommencer sur une hypothèse différente (backtracking), à la façon d'un moteur d'inférences.

Nous proposons une architecture dans laquelle ReAct (Reasoning + Acting) est accompagné par un Superviseur qui peut remonter l'arbre de décisions ("backtracking") et explorer des alternatives en cas d'échec ou d'insatisfaction. Dans cette approche, le superviseur serait un méta-contrôleur.

Un moteur d'inférences logiques peut jouer un rôle central dans l'orchestration des actions et des décisions à suivre en cas d'échec.
En effet, un moteur logique excelle dans :
– la détection de situations complexes,
– la représentation déclarative ("symbolique") de règles, de contraintes et d'alternatives ,
– le raisonnement sur des violations et des exceptions,
– le retour en arrière (backtracking) dans un arbre de solutions pour explorer les alternatives.

L'approche développée — ReAct + Inférence logique — se distingue nettement de tout ce qui existe aujourd'hui :

– elle est originale,
– elle est techniquement solide,
– elle répond à un besoin non couvert par les architectures actuelles,
– elle combine deux mondes rarement réunis :
agents LLM et moteurs logiques déterministes.

Aucun travail MIT, Stanford, DeepMind ou autre ne couvre cette architecture.

La version v2 de ReActEngine (en développement) est fondé sur cette architecture. Un moteur ReAct complet, en streaming entièrement écrit à la main, sans LlamaIndex ou autre, avec un LLM de Mistral AI : Made in France, cocorico !

ReAct : Schémas d'entrée et de sortie

Bertrand Degoy — 2025-09-12T08:37:58Z

Une définition complète et rigoureuse d'outils pour ReAct ( Function Tools ) comprend la définition des classes d'E/S Pydantic dans deux buts :
– aider ReAct à identifier le bon outil,
– passer des données d'entrée sous le bon format, valider les schémas de sortie ...
Oui, mais cela ralentit considérablement l'exécution et cela demande d'écrire des centaines de lignes de code.
Inutilement ?

Faut-il utiliser les schémas Pydantic ?

Sans schéma Pydantic = moins de vérifications explicites

Quand on n'utilise pas de classe Pydantic, on relie l'outil via un schéma JSON brut (dans la description de l'outil). Dans ce cas :
• Le LLM ne fait pas de validation stricte côté Python.
• Il fait confiance au schéma JSON pour comprendre les types attendus.
• Il génère les inputs en se basant sur la description, mais sans vérification automatique des types ou des valeurs.
Résultat :
✅ Exécution plus rapide
✅ Moins de friction
⚠️ Moins de sécurité sur les entrées (si l'agent hallucine ou malformate les données)

Avec Pydantic = validation rigoureuse
Si on utilise une classe Pydantic (déclaré dans le paramètre fn_schema du FunctionTool) pour définir les paramètres :
• Le LLM doit conformer les inputs à la structure attendue.
• Chaque champ est validé (type, présence, valeur).
• Tu obtiens des erreurs explicites si l'input est mal formé.
Résultat :
✅ Robustesse
✅ Clarté des erreurs
⚠️ Temps de traitement plus long
⚠️ Risque de blocage si le LLM ne formate pas parfaitement.

Gestion des retours de fonction

C'est un point souvent négligé dans les workflows ReAct : la gestion des retours de fonction.

Comment ReAct gère les retours de fonction
Dans LlamaIndex ReAct, l'agent ne lit pas directement le code Python de la fonction. Il se base sur :
1. La docstring de la fonction (si elle est fournie)
2. Le nom de la fonction
3. Le contexte de la requête utilisateur
4. L'observation du résultat après appel de la fonction
Autrement dit, il ne sait pas à l'avance ce que la fonction retourne, sauf cela lui est expliqué.

Bonnes pratiques pour que ReAct comprenne le retour
Voici comment on peut l'aider à bien interpréter le résultat :
1. Docstring explicite dans la fonction :

def extract_values_by_key(data_list, key):
"""
Retourne une liste contenant les valeurs associées à une clé donnée
dans chaque dictionnaire de la liste.
"""
return [item[key] for item in data_list if key in item]

Télécharger

2. Description claire dans le schéma JSON :

"description": "Retourne une liste des valeurs correspondant à une clé spécifique dans une liste de dictionnaires."

3. Nom de fonction évocateur
Un nom comme 'extract_values_by_key' est déjà très parlant. Éviter les noms trop génériques comme 'process_data'.
4. Observation du résultat
Après appel de la fonction, l'agent voit le retour (par exemple ['Alice','Bob','Charlie']) et peut l'utiliser dans sa chaîne de raisonnement suivante.

L'annotation de type de retour () dans la signature Python est utile pour le développeur, mais elle n'a aucun impact direct sur le comportement de l'agent ReAct :
LlamaIndex ReAct ne lit pas le code source de la fonction. Il ne fait pas d'analyse statique comme un IDE ou un linter. Ce qu'il utilise pour comprendre le comportement d'un outil, c'est :
• Le nom de la fonction,
• La description (dans le schéma JSON ou la docstring),
• Les paramètres définis dans le schéma,
• Le résultat observé après exécution.

Pour aller plus loin…

On peut aussi encapsuler le retour dans un dictionnaire pour le rendre plus lisible :

def extract_values_by_key(data_list, key):
return {"values": [item[key] for item in data_list if key in item]}

Télécharger

Cela permet à l'agent de mieux comprendre la structure du résultat, surtout si tu veux enchaîner avec d'autres outils.

ReAct : Mémoire contextuelle

Bertrand Degoy — 2025-08-30T07:54:28Z

La mémoire contextuelle dans ReAct permet à l'agent de retenir ses observations, erreurs et paramètres passés pour mieux agir. Une mémoire plus riche éviterait les répétitions et les appels incorrects.
Mais ReAct progresse par tâtonnements : il teste, observe, corrige. Ce manque de rigueur initial est compensé par sa capacité à s'adapter, comme un humain qui apprend en marchant.
Faut-il viser la précision dès le départ, ou valoriser l'exploration et l'ajustement en cours de route ?

Qu'est-ce que la "mémoire contextuelle" dans ReAct ?

Dans le cadre d'un agent ReAct, la mémoire contextuelle désigne l'ensemble des informations que l'agent garde en tête au fil de ses raisonnements et actions. Cela inclut :
• Les observations précédentes (résultats d'outils, réponses d'API, etc.)
• Les intentions passées (ce qu'il a essayé de faire)
• Les erreurs ou ajustements (ce qui n'a pas marché et pourquoi)
• Les données extraites ou calculées (valeurs, documents, filtres, etc.)

Pourquoi "plus riche" ?

Par "plus riche", il faut imaginer que l'agent pourrait :
• Mieux structurer ce qu'il a déjà vu ou fait.
• Mémoriser plus finement les paramètres utilisés, les formats attendus, les erreurs rencontrées.
• Anticiper les besoins futurs en se basant sur ce qu'il a appris dans les étapes précédentes.
Autrement dit, une mémoire contextuelle plus riche permettrait à l'agent de ne pas refaire les mêmes erreurs, ou de paramétrer correctement dès le premier appel.

Exemple concret

Voici un comportement qui devrait être évité : non seulement l'agent se trompe dans les paramètres (alors qu'il a déjà utilisé correctement l'outil dans une étape précédente), mais au moment de récupérer l'erreur, il s'aperçoit (comment ?) qu'il avait déjà la réponse :

Je vais maintenant récupérer les détails complets de ces interventions pour fournir une réponse claire et détaillée.
 Action: interventionsGetInterventionsByEntityIdFiltered
 Action Input: {'entityId': '23:4202'}
 Observation: Error: 3 validation errors for EntityIdTimestampsFilteredInput
 sinceTstamp
 Field required [type=missing, input_value={'entityId': '23:4202'}, input_type=dict]
 For further information visit https://errors.pydantic.dev/2.11/v/missing
 untilTstamp
 Field required [type=missing, input_value={'entityId': '23:4202'}, input_type=dict]
 For further information visit https://errors.pydantic.dev/2.11/v/missing
 filters
 Field required [type=missing, input_value={'entityId': '23:4202'}, input_type=dict]
 For further information visit https://errors.pydantic.dev/2.11/v/missing
 > Running step 7f431607-2599-43f4-b1f5-1fc819f498e4. Step input: None
 Thought: Je vois que j'ai déjà les informations nécessaires dans les résultats précédents. Je vais synthétiser les informations des interventions terminées en 2024 pour fournir une réponse claire et complète.

Si sa mémoire contextuelle était plus riche, il aurait pu éviter l'erreur dès le premier appel :
– Se rappeler qu'il avait déjà le résultat.
– Se souvenir du format attendu par le filtre.

Mémoire contextuelle vs. planification

Ce qu'on appelle "mémoire contextuelle" est souvent lié à la capacité de planification :
– Un agent qui planifie bien anticipe les formats, les conversions, les dépendances.
– Un agent avec une mémoire riche peut réutiliser intelligemment ce qu'il a déjà vu.

Ce qui importe, ce n'est pas seulement une question de "richesse" de la mémoire, mais aussi une prise en compte plus systématique. Il faut donc considérer l'adéquation des instructions générales, de la description des outils et de leur classes d'E/S, la bonne rédaction des routines.

En amont de ReAct, il y a l'orchestrateur, qui élabore un plan à partir du prompt, des instructions générales et des routines. Le plan est transmis à ReAct sous la forme d'une liste ordonnée d'étapes.
Le plus souvent, quand on constate un errance de ReAct, on constate également que le plan était très pertinent et qu'il n'a pas été appliqué, ou l'est en seconde intention.

Oui mais non, peut être ?

Ce comportement erratique se produit dans un contexte de system-prompt, de description des outils avec leurs classes Pydantic d'E/S détaillées, de routines très précises et, finalement, d'un plan élaboré par l'orchestrateur. Il faut dès lors se poser la question : pourquoi ce la ne fonctionne pas bien du premier coup ? Peut-on éviter cela ?
Faudrait-il :
• Des outils mieux documentés ?
• Un prompt plus précis, plus autoritaire ?
• Une mémoire contextuelle plus riche ?

Ou faut-il considérer ce comportement comme bénéfique et l'accepter ?

Pourquoi ReAct peut se tromper au premier appel ?

Le raisonnement est incrémental
ReAct fonctionne par boucles de réflexion et d'action. Il ne planifie pas tout d'un coup (mais c'est le rôle de l'orchestrateur), mais avance étape par étape :
• Il réfléchit à ce qu'il doit faire.
• Il agit (appelle un outil).
• Il observe le résultat.
• Il ajuste son raisonnement.
Cela signifie que le premier appel peut être basé sur une hypothèse partielle ou incorrecte, que l'agent corrige ensuite.
C'est là qu'on aimerait un peu plus de rigueur en ne négligeant pas la mémoire contextuelle.

Exploration et affinement
Les agents ReAct sont conçus pour explorer avant de converger :
• L'agent peut faire un premier appel avec des valeurs par défaut ou une interprétation approximative.
• Puis, en analysant l'observation, il comprend qu'il faut affiner les paramètres (par exemple, convertir une durée en millisecondes, ou filtrer selon un champ spécifique).
• C'est une forme de résilience algorithmique : mieux vaut se tromper et corriger que rester bloqué.
Autrement dit : j'essaye au pif et je lis la doc après ?

Comportement réaliste et humain
Ce genre de correction peut être toléré dans ReAct :
• Cela rend l'agent plus flexible, plus adaptable, et même plus humain dans son raisonnement.
• Un humain aussi peut se tromper dans un premier calcul, puis se corriger — ReAct imite cette dynamique.

Mais en pratique, cette capacité à se "récupérer" est une force, pas une faiblesse. Elle permet à l'agent de fonctionner dans des environnements ambigus, incomplets ou dynamiques.

Tentative de conclusion

Il faut vérifier et renforcer tout ce qui peut favoriser un premier essai sans erreur, et particulièrement la planification. Mais sinon, la capacité de ReAct à explorer et trouver une solution est une grande force. Encore faut-il ne pas faire deux fois les mêmes erreurs, c'est là que la mémoire contextuelle "plus riche" doit jouer.

à suivre : comment enrichir la mémoire contextuelle.

Embeddings : caractéristiques et comparaison des modèles

Bertrand Degoy — 2025-06-19T08:34:03Z

Si nous cherchons un modèle local pour sa rapidité et son économie, un bon choix semble être BAAI/bge-small-en.
Comment se modèle se compare-t-il et pourquoi fonctionne-t-il bien en français ? Voir la conclusion.

Pour comparer les embeddings entre plusieurs modèles, on peut observer plusieurs aspects :
– Dimension de l'embedding : Par exemple, un modèle peut produire des vecteurs de dimension 512, un autre 768 ou même 1024. Cela influence la finesse des représentations.
– Distribution statistique : regarder la moyenne, l'écart-type, ou la densité des valeurs dans l'embedding. Cela peut révéler des différences de calibrage entre modèles.
– Projection visuelle : on peut réduire les dimensions (avec PCA ou t-SNE par exemple) pour voir comment les phrases sont groupées dans un espace 2D. Très utile pour comparer la structure sémantique.
– Performance dans une tâche spécifique : on peut utiliser les embeddings pour une tâche de classification ou de clustering et comparer les performances.
– Distances entre embeddings : avec des métriques comme la cosine similarity ou la distance euclidienne, on peut évaluer si deux phrases similaires restent proches dans différents espaces

Comparaisons

Critère	ada-002	text-embedding-3-small	mistral-embed	BAAI/bge-small-en-v1.5	BGE-M3
Taille de l'embedding	1536	1536	1024	384	1024
Langue principale	Anglais (multilingue léger)	Multilingue (meilleure couverture que ada)	Multilingue	Anglais	Multilingue (100+ langues)
Objectif	Embedding généraliste	Embedding généraliste, optimisé RAG	Embedding généraliste, retrieval	Recherche dense / retrieval	Dense, sparse & multi-vector retrieval
Vitesse	Rapide via API	Très rapide via API	Rapide via API	Ultra rapide en local	Rapide via API ou local (FlagEmbedding)
Qualité sémantique	Bonne généralisation	Meilleure que ada-002 sur plusieurs tâches	Très bonne, bien groupée sémantiquement	Excellente pour similarité	Excellente, top sur MIRACL & MKQA
Utilisation recommandée	Clustering, recherche, etc.	Recherche, clustering, QA, RAG	Recherche, clustering, NLP généraliste	Recherche sémantique, FAQ, RAG	Recherche multilingue, RAG, QA longue doc

Pourquoi BAAI/bge-small-en-v1.5 fonctionne-t-il bien en français ?

Réponse de Copilot :

Même si BAAI/bge-small-en-v1.5 est officiellement un modèle monolingue anglais, il fonctionne étonnamment bien en français pour plusieurs raisons :
– Contamination multilingue dans les données : Lors de l'entraînement, les corpus web en anglais incluent souvent des phrases ou documents multilingues (comme des tweets, des articles ou des forums). Le modèle a donc probablement vu du français, même sans l'avoir ciblé explicitement.
– Structure linguistique proche : Le français et l'anglais partagent beaucoup de vocabulaire (surtout dans les domaines techniques ou académiques), ce qui facilite la généralisation.
– Tokenisation compatible : Le modèle utilise une tokenisation basée sur des sous-mots (comme WordPiece ou BPE), ce qui lui permet de traiter des mots français même s'ils ne sont pas dans son vocabulaire d'origine.
– Robustesse des modèles modernes : Les modèles comme BGE sont entraînés avec des objectifs de similarité sémantique qui les rendent capables de capturer le sens, même dans des langues non ciblées, tant que la structure reste cohérente.

Réponse de Le Chat :
Le modèle BAAI/bge-small-en-v1.5 est principalement conçu pour l'anglais, mais il peut également fonctionner relativement bien en français pour plusieurs raisons :

- Architecture du Modèle : Les modèles de langage modernes, comme ceux basés sur l'architecture des transformers, sont capables de capturer des motifs linguistiques complexes. Ces motifs peuvent être partagés entre différentes langues, surtout si elles appartiennent à la même famille linguistique. Le français et l'anglais, par exemple, partagent de nombreuses similitudes en termes de vocabulaire et de structure grammaticale.
– Entraînement Multilingue : Bien que le modèle soit principalement entraîné sur des données en anglais, il est possible qu'il ait été exposé à des données multilingues pendant son entraînement. Cela permet au modèle de développer une certaine compréhension des autres langues, y compris le français.
– Transfer Learning : Les modèles de langage bénéficient du transfer learning, où les connaissances acquises dans une langue peuvent être transférées à une autre langue. Cela signifie que même si le modèle est principalement entraîné sur l'anglais, il peut encore performer de manière acceptable en français.
– Similarités Lexicales : Le français et l'anglais partagent de nombreuses racines latines et germaniques, ce qui signifie qu'il y a un chevauchement significatif dans le vocabulaire. Cela permet au modèle de reconnaître et de comprendre de nombreux mots et expressions en français.
– Robustesse des Modèles : Les modèles de langage modernes sont conçus pour être robustes et généralisables. Ils peuvent souvent gérer des variations et des différences dans les données d'entrée, ce qui leur permet de fonctionner dans des contextes multilingues.

En résumé, bien que BAAI/bge-small-en-v1.5 soit optimisé pour l'anglais, sa capacité à fonctionner en français est due à une combinaison de facteurs, y compris l'architecture du modèle, l'entraînement multilingue, le transfer learning, les similarités lexicales et la robustesse générale des modèles de langage modernes.

Réponse de ChatGPT :
Le modèle BAAI/bge-small-en-v1.5, bien que présenté comme un modèle monolingue anglais, fonctionne étonnamment bien en français (et parfois dans d'autres langues européennes). Voici pourquoi :

1. Entraînement implicite sur des données multilingues

Même si le modèle est officiellement décrit comme "anglais", il est probable que :
* Des phrases en **français ou dans d'autres langues** soient apparues dans les jeux de données utilisés pour l'entraînement, comme Common Crawl, Wikipedia, etc.
* Certains jeux de données populaires utilisés dans l'entraînement de modèles open-source contiennent du texte multilingue (souvent non filtré).

2. Alignement sémantique interlingue
Les modèles de type "embedding" (comme ceux de la famille BGE ou Sentence-BERT) apprennent à encoder le sens, pas seulement les mots.
* Beaucoup de concepts sont sémantiquement proches entre les langues indo-européennes (comme l'anglais et le français).
* Même si le modèle n'a pas été formellement entraîné sur des phrases françaises, il peut projeter des phrases françaises dans un espace vectoriel proche des phrases anglaises similaires.

3. Évaluation empirique : bonnes performances dans certaines tâches

Des utilisateurs et chercheurs ont constaté que :

BAAI/bge-small-en-v1.5 donne des résultats compétitifs en français, surtout pour les tâches de recherche sémantique, similarité, ou classement de documents.
* Il peut surpasser certains modèles explicitement multilingues dans des cas concrets, probablement en raison de sa qualité d'entraînement et de son efficacité en encodage sémantique.

Limites à garder en tête

* Le modèle peut échouer sur des phrases très idiomatiques, complexes, ou rares en français.
* Les performances sont variables selon la tâche (classification, recherche, etc.).

Que faire si tu travailles en français ?
BGE-small-en-v1.5 peut très bien fonctionner, surtout si tu as besoin d'un modèle léger et rapide.
Pour des performances multilingues plus robustes, tu peux tester :
* `BAAI/bge-m3` (multilingue)
* `sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2`
* `intfloat/multilingual-e5-small` ou `mistral-embed`

Conclusion
Nous pouvons utiliser BGE-small-en-v1.5 en français,
MAIS :
l'expérience montre qu'il est préférable de formuler les instructions (system prompt, description des outils, plans, formats etc.) en anglais.

Confidentialité : Contrôle de l'accès aux applications

Bertrand Degoy — 2025-04-07T09:36:14Z

Damien 28/03/2025

Du fait des problèmes de confidentialité sur les données et ayant retrouvé les fichiers de configuration du serveur, j'ai mis en place une sécurité sur les accès à :

chat.ia.whatiswhat.cloud qui permet l'accès aux fenêtres de chat
ia.whatiswhat.cloud/data qui permet le téléchargement des fichiers

Pour le second, j'ai réussi à ce que les accès au sous-répertoire thewiw-help soit OK, mais, pour le premier, il y a un blocage quasi complet qui le rend inutilisable sans utilisateur + mot de passe.

En l'état, je préfère une telle configuration qu'avoir une passoire sur certains fichiers commerciaux ! Si vous souhaitez y accéder néanmoins, je peux vous créer un identifiant.

Bertrand : est-ce qu'on pourrait regarder cela en détail la semaine prochaine ?