Les services IA de DnC

WsgiChatBot

Bertrand Degoy — 2026-07-30T07:30:00Z

Cette application est un serveur HTTP au standard WSGI. Il est statique (restfull) : pour réaliser une conversation, ceci impose de gérer l'historique des échanges au niveau de l'application appelante. Loin d'être une contrainte, c'est au contraire une facilité permettant de gérer finement le contexte dans lequel sera analysée la question.

Tester WsgiChatBot (retour JSON)
Tester WsgiChatBot (réponse textuelle)

Routes

WsgiChatBot est un web service au standard WSGI (Web Server Gateway Interface) répondant en JSON à chaque question qui lui est posée par HTTP.

Les routes comprennent principalement :

GET /api/	Message d'accueil
GET /api/version/	Version du service
GET /api/ping	Test fonctionnel. Retourne le temps d'exécution (ms) ou 0 en cas d'erreur
GET /api/themes/	Liste les thèmes (ensemble de données d'une entité) disponibles.
GET /api/details/	Liste les différents niveaux d'élaboration de la réponse.
GET /api/history/	Retourne l'historique de la conversation comprimé.
POST /api/post/	Exécute la requête passée par POST. paramètres du post : voir ci-dessous.
POST /api/stream/	Exécute la requête passée par POST avec les mêmes paramètres que api/post. Permet un affichage progressif.

POST, action = 'query'

Tous les paramètres du post sont du type String.

Paramètre		Description
action	obligatoire	'query' : La seule action dans l'état actuel du développement.
theme	obligatoire	Espace de données (un répertoire sur le serveur).
prompt	obligatoire	La requête de l'utilisateur
detail	option	Niveau de détail de la réponse (voir la route 'details').
history	option	Contexte (ou historique) dans lequel la question est analysée.
language	option	Langage imposé pour la réponse.

La réponse au format JSON est un tableau de trois éléments :
– response : une chaîne au format MarkDown,
– ws_error : une simple chaîne décrivant une éventuelle erreur.

En l'absence d'un proxy inverse, WsgiChatBot ne répond qu'à l'hôte (localhost ou 127.0.0.1) sur le port 5002.

Exemple d'appel (PHP)

$data = array(
'action' => 'query',
'theme' => $theme, // Theme du chat
'prompt' => $prompt, // Qu'est-ce que OAuthSD ?
'detail' => 'Normal',
'history' => $history,
'language' => "Français"
);
$h = curl_init("localhost:5002/api/post"); # local
curl_setopt($h, CURLOPT_POST, 1);
curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data));
curl_setopt($h, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($h, CURLOPT_TIMEOUT, 100); // 100 secondes
$result = curl_exec($h);

Télécharger

STREAM, action = 'query'

Variante de streaming SSE de /api/post, appelée avec les mêmes paramètres.

La réponse est de type text/event-stream et comprend trois types d'événements :
- event : token -> data : "delta" : "..." (jetons LLM bruts, un ou plusieurs par événement)
- event : final -> data : "response" : "...", "history" :[] (texte enrichi issu de rework() + historique mis à jour)
- event : end -> data : {} (marqueur de fin)
En cas d'échec : event : error -> data : "message" : "..."

Lancement du serveur WSGI en ligne de commande

Le script wsgi_chatbot.sh permet de lancer le serveur tout en s'assurant qu'il n'y a qu'un seul process en route :

#!/usr/bin/env bash
# contourner l'erreur "ImportError: /lib64/libstdc++.so.6: cannot allocate memory in static TLS block"
export LD_PRELOAD=/lib64/libstdc++.so.6
# stop any process running on port 5002
/usr/sbin/fuser -k 5002/tcp;
# change to virtual python env
cd /home/iadnc/domains/chat.ia.dnc.global/PythonApp
source PythonAppVenv/bin/activate;
# run
nohup /home/iadnc/domains/chat.ia.dnc.global/PythonApp/wsgi_chatbot.py # pour debugger : pas de nohup

Télécharger

Il est important d'utiliser ce script pour éviter l'accumulation de process et la saturation de la mémoire du serveur.

Quelques détails du code

Lancement de l'application Flask comme serveur WSGI sécurisé et local

if __name__ == '__main__':
# Connection behind a local proxy
# @see: https://flask.palletsprojects.com/en/2.3.x/deploying/proxy_fix/
from werkzeug.middleware.proxy_fix import ProxyFix
app.wsgi_app = ProxyFix(
app.wsgi_app,
x_for=1, # Header to determine the originating IP of the client.
x_proto=1, # Trust the header for knowing whether the client used HTTP or HTTPS.
x_host=1, # Trust the header for the original request's host value.
x_prefix=1 # Trust the header for URL prefix adjustments.
)
# Allow cross-origin requests, restrict to local clients.
CORS(app, resources={r"/api/*": {"origins": ["http://localhost", "http://127.0.0.1"], "methods": ["GET", "POST"]}})
# Serve on localhost
http_server = WSGIServer(('localhost', PORT_SERVER), app)
try:
http_server.serve_forever() # continuously listen for incoming requests.
except Exception as e:
# Handle server-level exceptions gracefully
trace(f"Server error: {str(e)}")

Télécharger

Ce bloc de code :
– Configure l'application Flask pour fonctionner derrière un éventuel proxy tout en ajustant les attributs des requêtes.
– Autorise uniquement les clients locaux à effectuer des requêtes via les règles 'CORS'.
– Démarre un serveur WSGI sécurisé et local pour servir l'application.
– Intercepte toute exception pour ne pas stopper le serveur. Les erreurs sont inscrites dans un fichier contigu à l'application.

Notes à propos de la sécurité :
– Bien qu'il s'agisse d'une connexion locale, la règle 'CORS' est nécessaire ; elle permet de plus de préciser les origines et les méthodes.
– Sans proxy inverse, ce serveur ne peut être interrogé que depuis 'localhost'. S'il existe un proxy inverse ouvert sur le WAN, celui-ci ne peut qu'être local et on peut lui faire confiance, d'où les attributs de requêtes naïfs. Il revient au proxy inverse d'assurer la sécurité de l'accès depuis le WAN.

Gestion de l'historique : paramètre 'history'

Ainsi qu'il est mentionné dans l'introduction, le service est statique. Pour donner l'illusion d'une conversation, l'application appelante doit poster par le paramètre 'history' une chaîne représentative de l'historique des échanges. Cette chaîne est stockée dans la session de l'utilisateur.

Exemple de chaîne 'history' :

history = "
User : What is the best way to learn Python ?
Assistant : Start with basic syntax and practice with small projects.

User : Can you suggest a beginner project ?
Assistant : Try creating a simple to-do list app using Python.
"

Elaboration de l'historique par le client
L'expérience montre que, si on passe tout l'historique (depuis le lancement ou depuis le dernier Reset), il y a un 'effet d'entonnoir' : les question successives étant noyées dans l'historique, les réponses deviennent courtes et tendent à être identiques.
Différents procédés peuvent être appliqués :
– n'inclure dans l'historique que le dernier échange,
– inclure la première question et le dernier échange.
– se limiter aux derniers échanges,
etc.

Les questions et réponses doivent être balisées respectivement par les titres "User : " et "Assistant : "

Dans tous les cas, le volume de chaque échange doit être limité. Limiter la réponse de l'assistant à la première phrase peut s'avérer suffisant.

Exemple de construction d'un historique très simple :

Elaboration de l'historique par le serveur
Le serveur ne peut stocker l'historique, mais il peut, après la requête courante, en élaborer une version synthétique.
Le client lit le nouvel historique à l'aide de la route GET history et se contente de le repasser au prochain appel.

'Reset' de l'historique
Puisque le service n'a pas de mémoire des échanges et que l'historique doit être géré par l'application appelante, le 'Reset' de l'historique est géré par cette dernière. Cela peut se résumer à l'effacement du contexte dans la session de l'utilisateur.

Elaboration de l'historique par le serveur : développements

Managing token limits effectively is key when handling conversation history as a single string, especially with models like `mistralai-small`. Here's how you can optimize it :

### **1. Limit the Number of Past Exchanges**
Since models have a token limit, you should only keep **the most relevant past exchanges**. You can do this by :
– Keeping only the **last N exchanges** (e.g., last 3 conversations).
– Trimming older history beyond a certain character/token limit.

Example :
```python
MAX_TOKENS = 1024 # Adjust based on model limits

def trim_history(history) :
"""Trims conversation history if it exceeds max token limit."""
if len(history) > MAX_TOKENS :
# Keep only the last N exchanges
trimmed_history = "\n".join(history.split("\n")[-10 :]) # Keep last 10 exchanges
return trimmed_history
return history
```

— -

### **2. Use Summary-Based Compression**
Instead of keeping full conversations, generate **summarized versions** of prior exchanges and store those instead.

Example using OpenAI's GPT-4-turbo for summarization :
```python
import openai

def summarize_history(history) :
"""Generate a concise summary of past conversations."""
prompt = f"Summarize the following conversation for context preservation :\n\nhistory"

response = openai.ChatCompletion.create(
model="gpt-4-turbo",
messages=["role" : "system", "content" : prompt]
)

return response["choices"][0]["message"]["content"]
```

Then, when querying :
```python
history = summarize_history(history)
new_query = "What libraries would be useful for that project ?"
final_query = f"history\nUser : new_query"
```

— -

### **3. Use Rolling History Buffer**
Instead of maintaining **one big string**, store history as a **rolling buffer** that automatically removes older entries.

Example using Python `deque` :
```python
from collections import deque

chat_history = deque(maxlen=10) # Keep only the last 10 exchanges

def add_to_history(user_msg, assistant_msg) :
"""Adds conversation entries while maintaining rolling buffer."""
chat_history.append(f"User : user_msg")
chat_history.append(f"Assistant : assistant_msg")

# Example usage
add_to_history("Tell me about Python", "Python is a powerful programming language.")
add_to_history("How do I install it ?", "Use the official website or package manager.")

# Convert deque to a string before querying
formatted_history = "\n".join(chat_history)
print(formatted_history) # Keeps only the last 10 exchanges
```

— -

### **Which Approach Works Best ?**
– **Short conversations ?** → Keep last N exchanges (`trim_history()`).
– **Long conversations ?** → Use summarization (`summarize_history()`).
– **Dynamic conversations ?** → Use rolling history buffer (`deque`).

Les modes de synthèse

Bertrand Degoy — 2026-07-28T15:02:23Z

Le Moteur RAG de la v200 offre différents modes de synthèse des passages extraits de la documentation : "condense", "tree summarize", "node summarize, "tool".
Donnant des résultats très différents, il doivent être choisis en fonction de l'application et de la qualité de la documentation.
La pertinance du Reranker est mise en question.

Résumé de la problématique

Le mode condense produit des réponses plus pertinentes et plus “intelligentes” que les modes stricts (tree summarize, node summarize, tool), notamment lorsqu'il faut répondre à une question sans correspondance documentaire directe. La raison principale est que condense préserve davantage de matière textuelle et laisse au modèle une latitude d'inférence plus large, alors que les modes stricts réduisent fortement la richesse du contexte.

1. Différence de traitement du contexte

condense : concatène les passages et génère un résumé global.
- Préserve les redondances.
- Conserve les signaux faibles.
- Maintient les ambiguïtés utiles.
- Offre un espace d'inférence large.

De plus, ce mode est rapide et économique en token.

tree_summarize / node_summarize / tool : imposent une structure précoce.
- Compression agressive.
- Hiérarchisation ou segmentation.
- Normalisation du contenu.
- Réduction des co‑occurrences latentes.
- Perte d'informations implicites.

2. Impact sur les capacités du modèle

Les modèles modernes exploitent efficacement :

les corrélations faibles,
les ambiguïtés,
les patterns latents,
les fragments d'information dispersés.

Le mode condense leur fournit un contexte riche permettant :

l'inférence,
la reconstruction de sens,
la réponse indirecte à des questions non couvertes explicitement.

Les modes stricts limitent ces mécanismes en réduisant la matière disponible.

3. Cas d'usage des modes stricts

Les modes stricts restent adaptés lorsque :

le contexte est très volumineux (nécessité de structuration),
la tâche exige une réponse déterministe,
l'application impose une traçabilité stricte,
un agent ReAct doit consommer un format compact et non ambigu.

4. Conséquence architecturale

Le mode condense se comporte comme un pré‑RAG génératif :
il agrège et densifie le contexte sans le contraindre, ce qui maximise la capacité du modèle à produire une réponse pertinente même en absence de support documentaire direct.

Recommandation d'usage

Mode par défaut : condense
Contextes très longs : tree_summarize
Analyse par chunk : node_summarize
Agents ReAct : tool

Pertinence du reranker

L'effet du reranker dépend fortement du mode de post‑traitement utilisé.
Dans les modes stricts, il est souvent redondant ou contre‑productif.
Dans le mode condense, il peut être utile, mais pas toujours nécessaire, car ce mode exploite déjà la capacité du modèle à combiner des signaux faibles.

1. Interaction générale entre reranker et modes

Le reranker agit avant la phase de summarization.
Il modifie :

l'ordre des passages,
la sélection des passages (top‑k / top‑n),
la distribution des signaux faibles.

Son impact dépend donc de la manière dont le mode consomme les passages.

2. Effet par mode

Mode condense

Le modèle reçoit un bloc textuel riche.
Le reranker peut améliorer la pertinence en mettant les passages les plus utiles en tête.
Cependant, condense exploite aussi les signaux faibles et les co‑occurrences.
Un reranker trop strict peut réduire la diversité des passages et donc diminuer la capacité d'inférence.

Effet : utile mais non indispensable.
Risque : perte de matière latente si le reranker est trop agressif.

Mode tree_summarize

Ce mode structure le contenu en niveaux hiérarchiques.
Il dépend moins de l'ordre initial des passages.
Le reranker apporte peu de valeur, car la hiérarchie reconstruit déjà une importance relative.

Effet : faible.
Risque : compression excessive si le reranker filtre trop.

Mode node_summarize

Chaque passage est résumé individuellement.
L'ordre n'a presque aucune importance.
Le reranker n'améliore pas la qualité du résumé par passage.
Il peut même réduire la couverture documentaire.

Effet : marginal.
Risque : perte de diversité des chunks.

Mode tool

Format strict, compact, destiné aux agents.
Le reranker peut aider à sélectionner les passages les plus factuels.
Mais l'objectif est la déterminisme, pas l'inférence.

Effet : modéré.
Risque : suppression de passages utiles pour les actions de l'agent.

3. Utilité réelle du reranker

Le reranker est utile lorsque :

le corpus est très bruité,
les chunks sont hétérogènes,
le retriever renvoie trop de passages non pertinents,
la question est très ciblée.

Il est moins utile lorsque :

les chunks sont propres et homogènes,
les modes stricts restructurent déjà le contenu,
le modèle doit combiner des signaux faibles (cas du mode condense).

4. Synthèse

Mode	Utilité du reranker	Commentaire
condense	moyenne	améliore la pertinence mais peut réduire la diversité utile
tree_summarize	faible	la hiérarchie interne remplace le tri
node_summarize	très faible	résumés indépendants, ordre peu important
tool	modérée	utile pour filtrer, mais risque de perte d'information

Recommandation

Le reranker doit être activé uniquement dans les cas où la diversité des passages nuit à la pertinence.
Pour un pipeline moderne, la stratégie optimale est :

condense sans reranker par défaut,
condense avec reranker si le corpus est bruité,
modes stricts sans reranker.

Le Daemon Pyro5

Bertrand Degoy — 2026-07-07T09:30:51Z

Dans une architecture multi‑processus et multi‑utilisateur, on ne peut charger un même modèle dans chaque composant (NSOrchestrator, ReActEngine, workers, tests, scripts).
Pour cette raison, les modèles doivent être servis via un daemon.

Position du problème

Un LLM ou un SLM représente plusieurs gigaoctets en mémoire, et leur rechargement dans chaque processus provoquerait une explosion de la consommation RAM, une fragmentation CUDA, des temps de démarrage prohibitifs et une instabilité générale du système. Le mode daemon résout ce problème en garantissant qu'un modèle n'est chargé qu'une seule fois dans un processus dédié, puis partagé entre tous les autres via RPC. Cela permet un fonctionnement réellement concurrent, une gestion propre du streaming token‑par‑token, une isolation des erreurs, et une stabilité mémoire indispensable en production.

Pour cette raison, le LLM et le SLM doivent être servis via un daemon. Les deux modèles sont sollicités par plusieurs utilisateurs, plusieurs sessions et plusieurs moteurs internes, parfois simultanément. Les Thought et les réponses finales de ReAct doivent être générées sans jamais recharger les poids des modèles, sans bloquer les autres processus, et sans dépendre de l'environnement local de chaque composant. En les exécutant tous deux en daemon, l'architecture v200 devient cohérente, déterministe et scalable : un seul chargement, un seul point d'accès, un comportement identique pour tous les clients, et une capacité à monter en charge sans modifier le code des orchestrateurs ou des moteurs internes.

Ce raisonnement vaut également pour les index.

Rôle du daemon

Le daemon Pyro5 est un fournisseur multi-services.

Via ModelsConfigurator, il :

Charge les modèles définis dans models.json, ce qui initialise AppSettings et les modèles globaux (embedding, LLM, SLM).
Charge les services déclarés dans services.json et les instancie dynamiquement.
Enregistre chaque service dans Pyro5 sous un nom stable :
- llm.server
- slm.server
- embedding.server
- rag.reader

Puis : Lance la boucle d'événements Pyro5.

Exemple : chargement d'un index par RagRuntime :

Composants principaux

1. MemoryManager

Arbitre global de la RAM.
Suit les allocations d'objets persistants.
Applique une politique d'éviction (LRU locale).
Fournit un état mémoire complet.
Thread-safe.

2. InDaemonRagReader

Reader interne au daemon. Une architecture qui séparerait le modèle d'embedding et l'index dans des daemons distincts conduirait à un grand nombre d'échanges RCP et à des temps de traitement prohibitifs. InDaemonRagReader permet d'éviter cela :

Encode les requêtes via le modèle d'embedding global.
Interroge le backend vectoriel (FAISS, LlamaIndex ...).
Renvoie des RichNode.
Fournit un mode streaming (astream).

Interaction avec le client

Le client utilise InDaemonRagReaderProxy pour contacter rag.reader.

Flux typique :

RagRuntime.retrieve() → InDaemonRagReaderProxy("rag.reader").retrieve(theme, query, top_k) → InDaemonRagReader.retrieve() → encode la requête → interroge le backend vectoriel → renvoie des RichNode

Le client ne voit jamais MemoryManager : tout est encapsulé dans le daemon.

Avantages de cette architecture

Un seul daemon → cohérence mémoire.
Plusieurs services → modularité.
MemoryManager central → contrôle RAM industriel.
InDaemonRagReader → moteur RAG unifié.
Structure simple → facile à étendre.

v200 : Introduction

Bertrand Degoy — 2026-07-04T08:16:29Z

La v200 introduit une architecture RAG entièrement refondue, centrée sur la modularité, la performance et la robustesse. Elle s'appuie sur l'écriture de services dédiés pour les modèles et les index, un daemon Pyro5 pour l'accès rapide aux index en mémoire, et une API interne unifiée permettant d'abstraire totalement les backends.
L'ensemble garantit un moteur RAG totalement indépendant de toute bibliothèque (LlamaIndex, LangChain ...) .
Cette version fournit ainsi une base industrielle, stable et extensible pour un pipeline RAG totalement propriétaire.

La v200 constitue une réarchitecture complète du pipeline RAG, conçue pour offrir une modularité stricte, une indépendance vis‑à‑vis de LlamaIndex ou de toute autre bibliothèque, et une performance accrue grâce à un daemon gérant les index en mémoire persistante. Elle introduit une séparation nette des responsabilités, une normalisation des API internes, et un modèle d'exécution cohérent pour tous les types d'index et de modèles.

1. Objectif : Modularité systémique

1.1. Modularité des modèles

La v200 définit des services dédiés pour les modèles :

services/llm/
services/embeddings/

Chaque service expose une API normalisée :

generate()
astream()
embed()

Cette abstraction permet de remplacer un modèle (OpenAI, Ollama, HF, local) sans impact sur le reste du pipeline.

1.2. Modularité des index

Les index sont encapsulés dans des backends interchangeables :

FaissBackend
LlamaIndexBackend
DummyBackend

Tous implémentent une API unifiée :

retrieve(query, top_k)
query(query)
astream(query)
ping()

Cette normalisation garantit que le RAG ne dépend plus du type d'index sous‑jacent.

1.3. Rapidité via daemon Pyro5

La v200 introduit un daemon Pyro5 :

chargé de maintenir les index en mémoire,
exposant une API RPC homogène,
permettant un accès rapide depuis n'importe quel worker.

Le client est minimal :

IndexesManager → IndexService → RemoteIndexBackend

Un mécanisme de **fallback local** assure la continuité de service en cas d'indisponibilité du daemon. ### **1.4. Couche interne de normalisation** Une couche interne (`internal/`) garantit : - la normalisation des résultats des backends, - la conversion des formats hétérogènes en structures standardisées, - la cohérence des données consommées par RagRuntime. Tous les résultats sont convertis en dictionnaires homogènes :

```python { "text": "...", "score": None, "metadata": {} }

2. Objectif : RAGEngine indépendant d'API externes

2.1. Suppression des dépendances structurelles

La v200 élimine toute dépendance directe à LlamaIndex ( ou autre) dans le moteur RAG :

plus de QueryEngine,
plus de Node, Document, Response,
plus de formats étrangers.

Par exemple, LlamaIndex est encapsulé dans LlamaIndexBackend, qui expose l'API unifiée. Dans l'état actuel du développement, il existe une adaptation à FAISS.

2.2. RAGEngine basé sur une API interne stable

Le moteur RAG (RagRuntime) ne dépend plus :

du type d'index,
du type de modèle,
de LlamaIndex ou FAISS.

Il consomme uniquement l'API unifiée :

retrieve()
query()
astream()

2.3. Normalisation systématique des résultats

Les résultats bruts des backends (souvent des chaînes de caractères) sont systématiquement convertis en objets structurés avant traitement par RagRuntime.

Cela garantit :

la stabilité du pipeline,
la compatibilité avec les hooks,
l'absence d'erreurs liées à des formats hétérogènes.

2.4. Fallback local cohérent

En cas d'indisponibilité du daemon :

IndexService.connect() → RemoteIndexBackend (si daemon disponible) → LocalIndexBackend (si daemon indisponible)

LocalIndexBackend est un proxy thread‑safe, totalement indépendant du type d'index.

Synthèse

La v200 est une architecture RAG :

modulaire, grâce à des services dédiés pour les modèles et les index,
performante, via un daemon Pyro5 servant les index en mémoire,
normalisée, grâce à une API interne unifiée pour tous les backends,
résiliente, via un fallback local automatique,
indépendante de LlamaIndex, grâce à l'encapsulation complète dans LlamaIndexBackend,
stable, grâce à une couche de normalisation systématique pour RagRuntime.

Elle constitue une base industrielle, cohérente, et extensible pour un pipeline RAG moderne.

Politique LRU/MRU

Bertrand Degoy — 2026-06-29T09:04:20Z

Dans l'architecture Pyro5, les index ( et certains modèles ) sont chargés depuis le disque puis conservés en RAM pour être accessibles rapidement par les services distants. Le daemon joue le rôle de processus maître.

Pour les index par exemple, il les expose via IndexServer, et sert de point d'accès unique pour tous les RemoteIndexService.

Comme ces index peuvent être volumineux et que le daemon est conçu pour rester actif longtemps, il doit gérer sa mémoire de manière autonome et efficace. C'est précisément pour cela qu'une politique LRU/MRU est indispensable : elle permet de conserver en RAM les index les plus récemment utilisés (MRU), tout en évinçant automatiquement ceux qui ne sont plus sollicités (LRU).

Cette stratégie garantit que le flowchart Pyro5 fonctionne de manière fluide, sans surcharge mémoire, et que les services distants accèdent toujours aux index pertinents sans rechargement inutile depuis le disque.

Politique LRU/MRU

La politique LRU/MRU (Least Recently Used / Most Recently Used) est un mécanisme de gestion de la mémoire qui permet de décider quel objet doit être évincé lorsque la RAM atteint sa capacité maximale. Elle repose sur un principe simple :

MRU = objets récemment utilisés → à conserver
LRU = objets peu utilisés récemment → candidats à l'éviction

Dans notre système, cette politique est appliquée par le MemoryManager, qui maintient un ordre strict des objets en RAM grâce à un OrderedDict.

MRU — Most Recently Used

Un objet devient MRU lorsqu'il est :

chargé en RAM,
accédé via get(),
marqué via touch().

Le MemoryManager déplace alors la clé à la fin de l'OrderedDict :

[ LRU ... → ... MRU ]

Cela signifie :

cet index est actif,
il doit être conservé en priorité,
il ne doit pas être évincé tant que d'autres objets moins utilisés existent.

LRU — Least Recently Used

L'objet LRU est celui qui :

n'a pas été utilisé depuis le plus longtemps,
n'a pas été touché récemment,
se trouve au début de l'OrderedDict.

Lorsqu'une éviction est nécessaire (ex : len(store) > max_items), le MemoryManager fait :

key, _ = self._store.popitem(last=False)

Ce qui retire le premier élément, donc le LRU.

Pourquoi LRU/MRU est idéal dans ton architecture

1. Les index sont lourds

Ils peuvent peser plusieurs centaines de Mo.
Il est donc crucial d'éviter de recharger inutilement depuis le disque.

2. Les RemoteIndexService sont stateless

Ils ne conservent rien : tout repose sur la RAM du daemon.
LRU/MRU garantit que les index réellement utilisés restent disponibles.

3. Le daemon est long-lived

Il doit s'auto-réguler sans intervention humaine.
LRU/MRU fournit une politique simple, déterministe et efficace.

4. Les thèmes ont des patterns d'accès naturels

Certains thèmes sont consultés souvent (MRU), d'autres rarement (LRU).
La politique s'adapte automatiquement à ces usages.

Résultat : une mémoire auto-optimisée

Grâce à LRU/MRU :

Les index actifs restent en RAM → latence minimale
Les index inactifs sont évincés → RAM maîtrisée
Le daemon ne recharge que si nécessaire → I/O minimisées
Le système reste stable même sous forte charge → robustesse

Construction des modèles : models.json et services.json

Bertrand Degoy — 2026-06-23T08:51:00Z

L'architecture v200 repose sur une séparation stricte entre la définition des modèles, leur construction centralisée, et la déclaration des services qui les consomment.
Les modèles sont décrits dans un fichier unique (`models.json`), puis construits une seule fois au démarrage par le `ModelsConfigurator`, avant d'être stockés dans `AppSettings` pour être partagés par l'ensemble du runtime.
Les services Pyro5, déclarés dans `services.json`, ne chargent jamais de modèles eux‑mêmes : ils se contentent d'exposer des capacités en s'appuyant sur les objets déjà initialisés, garantissant ainsi cohérence, performance et isolation des responsabilités.

Construction des modèles : `models.json` et `services.json`

1. Présentation générale : comment les modèles sont construits dans v200

L'architecture v200 repose sur une séparation stricte des responsabilités :

1. `models.json` décrit les modèles

Ce fichier déclare uniquement les modèles utilisés par le runtime :

embedding
slm
tokenizer
llm

Chaque entrée décrit :

model_name
model_path (optionnel)
backend
device
api_key_env (si backend = API) etc.

2. ModelsConfigurator construit les modèles

Le composant ModelsConfigurator :

lit models.json
instancie les modèles (HF, API, local, etc.)
crée les objets Python correspondants

Il ne connaît pas les services Pyro5.

3. AppSettingsManager stocke les modèles

Une fois construits, les modèles sont transmis à :

AppSettingsManager.load_models(...)

Ce composant :

crée un objet AppSettings
stocke les modèles dans des attributs statiques
verrouille la configuration

4. Les services Pyro5 consomment les modèles

Les services (EmbeddingServer, SLMServer, IndexServer, MemoryManager) :

ne chargent pas de modèles
ne reçoivent pas de paramètres de modèle
récupèrent les modèles via :

from runtime_v2.settings.app_settings import AppSettings self.embedding = AppSettings.embedding
self.slm = AppSettings.slm
self.tokenizer = AppSettings.tokenizer
self.llm = AppSettings.llm

5. `services.json` décrit uniquement les services

Ce fichier :

déclare les services Pyro5
indique leur classe Python
fournit uniquement les paramètres nécessaires aux RPC (ex : nom d'un autre service)

Il ne doit jamais contenir de paramètres de modèle.

2. Comment écrire `models.json`

Voici la structure de base :

{ "__comment": "Source de ModelsConfigurator pour la configuration des modèles du runtime v200.", "embedding": { "__comment": "Embedding local basé sur SentenceTransformers (ST). Utilise BGE-small en mode léger, sans AutoModel/AutoTokenizer, pour éviter la surcharge mémoire des modèles HF.", "model_type": "embedding", "model_name": "BAAI/bge-small-en-v1.5", "model_path": "/home/iadnc/.models/bge-small", "backend": "st", "device": "cpu" }, "slm": { "__comment": "SLM local optionnel (TinyLlama, Phi, etc.). Null = désactivé.", "model_type": "causal_lm", "model_name": null, "model_path": null, "backend": null, "device": null }, "tokenizer": { "__comment": "Tokenizer HF externe (Mixtral), téléchargé via HF.", "model_type": "tokenizer", "model_name": "mistralai/Mixtral-8x7B-Instruct-v0.1", "model_path": null, "backend": "hf", "device": null }, "llm": { "__comment": "LLM principal via Daemon.", "model_type": "causal_lm", "backend": "mistral_daemon", "model_name": "mistral-medium-latest", "api_key_env": "MISTRAL_API_KEY", "daemon_host": "127.0.0.1", "daemon_port": 50050 }
}

Ou, plus ambitieux ( à condition que les backends aient été écrits) :

{ "__comment": "Configuration canonique v200 — aucun champ implicite, aucun type déduit automatiquement.", "llm_api": { "model_name": "mistral-medium-latest", "backend": "mistral_api", "model_type": "causal_lm", "api_key_env": "MISTRAL_API_KEY", "max_new_tokens": 2048, "temperature": 0.2 }, "llm_daemon": { "model_name": "mistral-medium-latest", "backend": "mistral_daemon", "model_type": "causal_lm", "api_key": "env:MISTRAL_API_KEY", "daemon_host": "127.0.0.1", "daemon_port": 50050, "max_new_tokens": 2048, "temperature": 0.0 }, "slm": { "model_name": "TinyLlama/TinyLlama-1.1B-Chat-v1.0", "backend": "hf_local", "model_type": "hf_causal_lm", "model_path": "/home/iadnc/.models/TinyLlama-1.1B-Chat-v1.0", "device": "cpu", "dtype": "float16", "max_new_tokens": 512, "temperature": 0.0 }, "embedding": { "model_name": "BAAI/bge-small-en-v1.5", "backend": "st", "model_type": "embedding", "model_path": "/home/iadnc/.models/bge-small", "device": "cpu" }, "tokenizer": { "model_name": "mistralai/Mixtral-8x7B-Instruct-v0.1", "backend": "hf", "model_type": "tokenizer", "device": "cpu" }, "service_router": { "model_name": "router-v1", "backend": "internal", "model_type": "router", "strategy": "round_robin", "targets": ["llm_api", "llm_daemon", "slm"] }, "reranker": { "model_name": "colbertv2", "backend": "hf_local", "model_type": "reranker", "model_path": "/home/iadnc/.models/colbertv2", "device": "cuda", "dtype": "float16" }, "vision_encoder": { "model_name": "openai/clip-vit-base-patch32", "backend": "hf_local", "model_type": "vision_encoder", "model_path": "/home/iadnc/.models/clip-vit-base-patch32", "device": "cuda" }, "audio_encoder": { "model_name": "facebook/wav2vec2-base-960h", "backend": "hf_local", "model_type": "audio_encoder", "model_path": "/home/iadnc/.models/wav2vec2", "device": "cpu" }, "http_service": { "model_name": "custom-service", "backend": "http", "model_type": "service", "service_url": "http://127.0.0.1:8080/infer", "timeout": 30 }
}

Règles :

Chaque modèle doit avoir un model_name
model_path peut être null si HF doit télécharger automatiquement
backend détermine le loader (hf, hf_local, mistral_api, etc.)
device peut être cpu, cuda, ou null
api_key est utilisé uniquement pour les backends API

3. Comment écrire `services.json`

Voici la version minimale, conforme à v200 :

{ "daemon": { "host": "127.0.0.1", "port": XXX }, "services": [ { "name": "llm.server", "class": "runtime_v21.services.llm.llm_server.LlmServer", "params": {} }, { "name": "slm.server", "class": "runtime_v21.services.llm.slm_server.SlmServer", "params": {} }, { "name": "memory.server", "class": "runtime_v21.services.memory_manager.MemoryManager", "params": {} } ], "index": { "loader": { "class": "runtime_v21.services.index.loaders.loader_manager.ThemeIndexLoaderManager", "params": {} }, "reserved_ram": 100000000 }
}, "tokenizer": { "model_name": "mistralai/Mixtral-8x7B-Instruct-v0.1", "backend": "hf", "model_type": "tokenizer", "device": "cpu" }
}

Règles :

Aucun service ne doit recevoir de modèle
→ pas de model, model_name, backend, device, etc.
Les services doivent recevoir uniquement :
- des noms de services Pyro5 (pour RPC)
- des paramètres métier (rare)
Les services doivent récupérer les modèles via AppSettings.

4. Résumé

Élément	Rôle	Contenu
`models.json`	Décrit les modèles	model_name, backend, device, path
`ModelsConfigurator`	Construit les modèles	HF, API, local
`AppSettingsManager`	Stocke les modèles	AppSettings.embedding, etc.
`services.json`	Décrit les services	classes, RPC, dépendances
Services Pyro5	Consomment les modèles	via AppSettings

Protocoles des API LLM

Bertrand Degoy — 2026-06-16T08:12:06Z

Ce document décrit les deux modes d'appel aux API utilisés par les modèles LLM dans l'architecture v200 : synchrone et streaming.

Protocoles d'appel LLM : synchrone vs streaming

Ce document décrit les deux modes d'appel utilisés par les modèles LLM dans l'architecture v200 :

appel synchrone (generate)
appel en streaming (stream_generate)

Les deux modes utilisent HTTP(S), mais pas le même protocole.

Dans la v200, les InternalLLM sont les seules classes responsables :

de la configuration backend (client, modèle, URL si HTTP)
de l'appel synchrone
de l'appel streaming
de la normalisation des réponses

1. Appel synchrone : HTTP POST classique

L'appel synchrone (generate) utilise un POST HTTP standard.

Caractéristiques

Une seule requête
Une seule réponse
Format JSON complet
Pas de flux
Pas de tokens intermédiaires

Exemple (OpenAI/Mistral-like)

POST /v1/chat/completions
Content-Type: application/json { "model": "mistral-large", "messages": [...]
}

Réponse :

200 OK
Content-Type: application/json { "id": "...", "choices": [ { "message": { "content": "réponse complète" } } ]
}

2. Appel streaming : HTTP POST + protocole de flux

L'appel stream_generate utilise également un POST HTTP, mais la réponse n'est pas un JSON unique.
Le serveur envoie un flux d'événements ou de chunks.

Deux protocoles sont utilisés selon les backends :

2.1. SSE (Server-Sent Events)

C'est le protocole utilisé par :

OpenAI
Mistral
Anthropic
Groq
LM Studio (mode OpenAI)

Caractéristiques

Content-Type: text/event-stream
Transfer-Encoding: chunked
Chaque ligne commence par data:
Chaque événement contient un fragment (delta)
Le flux se termine par data: [DONE]

Exemple

data: {"choices":[{"delta":{"content":"Bon"}}]}
data: {"choices":[{"delta":{"content":"jour"}}]}
data: {"choices":[{"delta":{"content":" !"}}]}
data: [DONE]

2.2. Chunked Transfer Encoding (Ollama)

Ollama n'utilise pas SSE mais un flux de JSON successifs, un par chunk.

Exemple

{"response": "Bon"}
{"response": "jour"}
{"response": " Bertrand"}
{"done": true}

Caractéristiques

Pas de data:
Pas de SSE
Chaque chunk est un JSON indépendant
Le client doit lire le flux chunk par chunk

3. Pourquoi deux protocoles différents ?

Parce que :

un appel synchrone renvoie une réponse complète
un streaming renvoie un flux de tokens

HTTP classique ne permet pas d'envoyer plusieurs réponses successives.
Les serveurs utilisent donc :

SSE → flux d'événements textuels
chunked transfer → flux de JSON partiels
WebSocket (rare) → flux bidirectionnel

4. Conséquences pour l'architecture v200

4.1. `generate()`

utilise un appel HTTP simple
renvoie un JSON complet
normalisation effectuée dans la classe LLM

4.2. `stream_generate()`

utilise SSE ou chunked transfer
lit les fragments au fur et à mesure
normalise chaque fragment en format v200 :

{ "delta": "texte" }
...
{ "delta": "", "meta": {...} }

Retourne un flux de chunks représentant la réponse en streaming. Contrat de l'interface :

La méthode doit produire un itérable de chunks.

Convention v200 (obligatoire pour toutes les implémentations) :
- Les chunks intermédiaires sont des dicts contenant : { "delta": "" }
- Le dernier chunk contient en plus des métadonnées : { "delta": "", "meta": {...} } Cette convention garantit un format standardisé pour toutes les
implémentations InternalLLM, indépendamment du backend utilisé.

5. Résumé

6. Exemple

from commons.models.internal.base import BaseGenerativeModel
from commons.models.response import Response
class MistralAPIInternalLLM(BaseGenerativeModel):
"""
Implémentation Mistral API pour v200.
Cette classe contient :
- la configuration backend (client, modèle)
- generate() : appel synchrone
- stream_generate() : appel SSE
- normalisation des réponses
"""
def __init__(self, client, model_name: str):
self.client = client
self.model_name = model_name
def generate(self, prompt: str, **kwargs) -> Response:
"""
Appel synchrone : requête HTTP complète, pas de streaming.
Le format exact de la réponse dépend du backend.
"""
raw = self.client.chat.completions.create(
model=self.model_name,
messages=[{"role": "user", "content": prompt}],
stream=False,
**kwargs,
)
try:
text = raw["choices"][0]["message"]["content"]
except Exception:
text = str(raw)
return Response(
response=text,
raw_response=raw,
source_nodes=None,
metadata={},
)
def stream_generate(self, prompt: str, **kwargs):
"""
Retourne un flux de chunks.
Le format exact dépend de l'implémentation.
Convention interne v200 :
- chunks intermédiaires : {"delta": "..."}
- chunk final : {"delta": "", "meta": {...}}
"""
stream = self.client.chat.completions.create(
model=self.model_name,
messages=[{"role": "user", "content": prompt}],
stream=True,
**kwargs,
)
final_message = None
for chunk in stream:
delta = ""
if chunk.choices:
c = chunk.choices[0]
if getattr(c, "delta", None) and getattr(c.delta, "content", None):
delta = c.delta.content or ""
if getattr(c, "message", None):
final_message = c.message
yield {"delta": delta}
yield {
"delta": "",
"meta": {
"raw_response": final_message,
"nodes": None,
"metadata": {},
},
}

Télécharger

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 !

Comment ReActAgent s'insère dans le Workflow LlamaIndex

Bertrand Degoy — 2026-04-13T10:15:10Z

Dans LlamaIndex, la boucle ReAct repose sur un principe simple : le workflow orchestre, l'agent raisonne. À chaque appel, génère un prompt, interroge le LLM, reconstruit une étape de raisonnement et laisse le finalizer décider de la suite. Une mécanique minimale côté workflow, une intelligence maximale côté agent.

La boucle de raisonnement ReAct

Comment `ReActAgent` s'insère dans le Workflow LlamaIndex

LlamaIndex ReActAgent, construit sur Workflow, fournit le code du step dans un workflow. Le workflow appelle :

BaseAgent.run_agent_step() → ReActAgent.take_step()

Donc :

le workflow = chef d'orchestre (encore un !)
l'agent = une étape du workflow
take_step() = la logique ReAct pour une étape

Comment sont construites les steps ReAct ?

En vérité : Le Workflow ne construit pas des steps ReAct. C'est ReActAgent qui les fait construire par le LLM. Le Workflow ne fait que :

appeler take_step()
attendre un AgentStepOutput (Thought, Action, Action Input ...)
décider avec ReActFinalizer si une nouvelle étape doit être exécutée

Voici ce qui se passe dans ReActAgent.take_step() pour construire une étape :

Étape 1 — Construire le prompt ReAct

L'agent génère le prompt ReAct qui fixe les règles que devra suivre le LLM pour élaborer les THOUGHT, ACTION et ACTION INPUT, pour appeler les outils etc. Le prompt contient également l'historique des échanges et, in fine, la question de l'utilisateur. Voici un exemple très naïf :

You are a ReAct agent.
First, think step-by-step and write:
THOUGHT:
Then, if needed, write:
ACTION:
ACTION INPUT:

Étape 2 — Appeler le LLM

L'agent appelle :

llm.stream(prompt)

Le LLM génère la réponse au prompt. → Le LLM produit progressivement, par petits fragments, les deltas.

Étape 3 — Le parser reconstruit les blocs

Le ReActStreamParser transforme les deltas en blocs :

THOUGHT: ...
ACTION: ...
OBSERVATION: ...
...
FINAL_ANSWER: ...

Étape 4 — Le ReActFinalizer décide si l'étape est terminée

Le finalizer :

valide les blocs
détecte les erreurs
empêche les boucles
décide si une nouvelle étape doit être lancée

Étape 5 — Le workflow relance `take_step()` si nécessaire

Si le finalizer dit “continue”, alors :

workflow → BaseAgent.run_agent_step → ReActAgent.take_step()

Et une nouvelle étape ReAct est produite.

En résumé : rôle du Workflow

Le workflow LlamaIndex ne fait qu'appeler take_step() en boucle.
ReActAgent.take_step() génère une étape ReAct en appelant le LLM.
Le ReActStreamParser reconstruit les blocs ReAct à partir des deltas.
Le ReActFinalizer décide si une nouvelle étape doit être lancée.
Le workflow relance take_step() si nécessaire.

Voyez aussi :
– ReActEngine v1 : Modules et traitements

ReActEngine v1 : Finalizer et StreamParser

Bertrand Degoy — 2026-04-13T09:34:02Z

Les modules ReActFinalizer, ReActStreamParser, font partie du niveau supérieur ou "Orchesrtrateur" du traitement. Ils ont été développés spécialement pour atteindre les objectifs du ReActEngine v1.

Architecture ReAct : Finalizer et StreamParser

Rôles et responsabilités

ReActStreamParser

Fait le lien entre le niveau applicatif et le ReActEngine.

Responsable de :

La segmentation du flux brut en blocs ReActBlock
L'identification du type de chaque bloc (ReActType)
La gestion du buffer et du flush final
La conservation de l'historique des blocs extraits

Ne décide jamais de l'arrêt ou de la modification du raisonnement.

Expose :

has_final_answer() : indique si un bloc FINAL_ANSWER est présent dans les blocs extraits
get_final_answer() : retourne le contenu du dernier bloc FINAL_ANSWER si présent

ReActFinalizer

Responsable de :

L'orchestration du raisonnement jusqu'à résolution
L'arrêt du flux dès qu'un bloc de type FINAL_ANSWER, ANSWER, RESPONSE ou CONCLUSION est rencontré
La détection de boucles ou d'anomalies de raisonnement, avec relance du raisonnement via un Thought injecté.

Ne connaît pas l'état interne du parser. Il ne peut pas appeler parser.has_final_answer().

Règle de séparation stricte

Le Finalizer ne doit pas inspecter parser.blocks ni utiliser ses méthodes internes.
Le Parser ne doit pas décider de l'arrêt ou la modification du raisonnement.
La détection de la résolution se fait uniquement dans le Finalizer, en fonction du type des blocs yieldés.

Exemple de flux

Thought: I need to search.
Action: search[weather]
Observation: It's raining.
Final Answer: Bring an umbrella.

Le Parser extrait 4 blocs typés.
Le Finalizer s'arrête dès réception du bloc FINAL_ANSWER.

La classe `ReActType`

Héritage :

class ReActType(str, Enum):

Hérite de str pour permettre des comparaisons directes avec des chaînes (block.type == "thought").
Hérite de Enum pour garantir l'énumération stricte des types.

Types ReAct fondamentaux

Type	Rôle dans le flux ReAct
`THOUGHT`	Raisonnement interne
`ACTION`	Appel d'outil
`OBSERVATION`	Résultat d'outil
`FINAL_ANSWER`	Clôture explicite
`ANSWER`	Réponse directe
`RESPONSE`	Variante de réponse
`CONCLUSION`	Clôture synthétique
`TOOL_CALL`	Appel structuré (optionnel)
`TOOL_RESULT`	Résultat structuré
`UNKNOWN`	Valeur de secours

3. Cohérence avec les finalizers et parsers

Les types FINAL_ANSWER, ANSWER, RESPONSE, CONCLUSION sont utilisés comme types de clôture dans le Finalizer.
Les types TOOL_CALL et TOOL_RESULT sont utiles pour des flux structurés (JSON, agents avancés).
UNKNOWN est une bonne pratique pour la robustesse du parsing.

Pourquoi deux parsers ?

Les parsers ont pour fonction d'assembler un flux de réponse brut (les tokens) en messages typés ReAct.

Les lecteurs attentifs auront remarqué que :

il existe un ReActOutputParser directement à la sortie du LLM et, pourtant, ReActEngine émet un flux brut de token ;
l'application cliente doit reconstruire les messages ReAct, par exemple avec StreamlitChatTracer.

Voici la distinction essentielle — et pourquoi elle est nécessaire — entre :

ReActOutputParser (côté LLM, logique interne de l'agent)
ReActEngine / Workflow (côté runtime, flux brut de tokens)
StreamlitChatTracer / client (côté application, reconstruction des messages)


Deux parser en parallèle avec des objectifs et une temporalité différents

**1. Le ReActOutputParser n'est pas utilisé pendant le streaming**

ReActOutputParser est conçu pour analyser un bloc complet de texte produit par le LLM, contenant typiquement :

Thought: ...
Action: tool_name
Action Input: {...}

ou bien :

Thought: ...
Answer: ...

Ce parser fonctionne uniquement lorsque le LLM a fini de produire tout le message.
Il ne peut pas fonctionner sur un flux token-par-token, car :

le pattern ReAct n'est pas encore complet,
les sections Thought / Action / Observation / Answer peuvent arriver dans n'importe quel ordre,
le LLM peut réviser sa sortie en cours de génération.

Donc : pendant le streaming, LlamaIndex ne peut pas appliquer ReActOutputParser.

2. Pourquoi ReActEngine émet un flux brut de tokens

Le moteur ReAct dans LlamaIndex Workflow est conçu pour :

exposer l'intégralité du raisonnement ReAct,
permettre au client de suivre la progression en temps réel,
laisser la liberté au développeur de tracer, filtrer ou visualiser les étapes.

Le flux brut contient donc :

les Thought : intermédiaires,
les Action : et Action Input :,
les Observation :,
les Answer : finales.

Ce flux est intentionnellement non structuré, car :

il reflète exactement ce que le LLM produit,
il permet d'afficher la réflexion pas à pas,
il évite d'imposer un format unique de parsing pendant le streaming.

Le moteur ne structure pas le flux, car cela casserait la transparence et la flexibilité du workflow.

3. Pourquoi le client doit reconstruire les messages ReAct

Comme le flux est brut, c'est l'application cliente qui doit :

détecter les segments Thought / Action / Observation / Answer,
les afficher proprement,
éventuellement les agréger ou les filtrer,
ou les transformer en messages de chat.

Pour une application de chatbot fondée sur StreamLit, nous avons développé StreamlitChatTracer qui a l'avantage de produire en streaming un flux décoré (police, couleur etc.).

LlamaIndex fournit des helpers comme :

LlamaTrace
OpenInference instrumentation

Ces outils :

écoutent les événements AgentStream, ToolCall, ToolCallResult, etc.,
reconstruisent une vue structurée du raisonnement,
permettent une visualisation claire dans le client.

La reconstruction côté client est volontaire : elle permet d'adapter l'affichage au contexte (UI, logs, monitoring, etc.).

4. Pourquoi cette séparation est nécessaire

A. Le LLM produit du texte libre → pas structuré

Même si ReAct impose un format, le LLM reste libre dans sa génération.
Le parser ne peut fonctionner qu'une fois la sortie complète.

B. Le streaming impose de ne pas parser prématurément

Un parser ReAct ne peut pas fonctionner sur :

un Thought incomplet,
un Action Input partiellement généré,
un Answer tronqué.

C. Le workflow doit rester générique

Le moteur ReAct doit :

fonctionner avec n'importe quel LLM,
ne pas dépendre d'un format strict,
permettre des outils de tracing externes.

D. Le client peut choisir son mode de visualisation

Certains veulent :

tout afficher (Thoughts inclus),
masquer les Thoughts,
afficher uniquement les Tool Calls,
ou ne montrer que la réponse finale.

Impossible de satisfaire tous les cas dans le moteur lui-même.

Conclusion

La différence est nécessaire car :

ReActOutputParser est un outil post-hoc pour analyser une sortie complète.
ReActEngine doit fournir un flux brut pour permettre le streaming et la transparence.
Le client doit reconstruire les messages ReAct selon ses besoins (UI, logs, monitoring).

Cette architecture garantit :

flexibilité,
transparence,
compatibilité avec tous les LLM,
et contrôle total côté application.

Les services IA de DnC

WsgiChatBot

Routes

POST, action = 'query'

Exemple d'appel (PHP)

STREAM, action = 'query'

Lancement du serveur WSGI en ligne de commande

Quelques détails du code

Gestion de l'historique : paramètre 'history'

Elaboration de l'historique par le serveur : développements

Les modes de synthèse

Résumé de la problématique

1. Différence de traitement du contexte

2. Impact sur les capacités du modèle

3. Cas d'usage des modes stricts

4. Conséquence architecturale

Recommandation d'usage

Pertinence du reranker

1. Interaction générale entre reranker et modes

2. Effet par mode

Mode condense

Mode tree_summarize

Mode node_summarize

Mode tool

3. Utilité réelle du reranker

4. Synthèse

Recommandation

Le Daemon Pyro5

Position du problème

Rôle du daemon

Composants principaux

1. MemoryManager

2. InDaemonRagReader

Interaction avec le client

Avantages de cette architecture

v200 : Introduction

1. Objectif : Modularité systémique

1.1. Modularité des modèles

1.2. Modularité des index

1.3. Rapidité via daemon Pyro5

2. Objectif : RAGEngine indépendant d'API externes

2.1. Suppression des dépendances structurelles

2.2. RAGEngine basé sur une API interne stable

2.3. Normalisation systématique des résultats

2.4. Fallback local cohérent

Synthèse

Politique LRU/MRU

Politique LRU/MRU

MRU — Most Recently Used

LRU — Least Recently Used

Pourquoi LRU/MRU est idéal dans ton architecture

1. Les index sont lourds

2. Les RemoteIndexService sont stateless

3. Le daemon est long-lived

4. Les thèmes ont des patterns d'accès naturels

Résultat : une mémoire auto-optimisée

Construction des modèles : models.json et services.json

Construction des modèles : models.json et services.json

1. Présentation générale : comment les modèles sont construits dans v200

1. models.json décrit les modèles

2. ModelsConfigurator construit les modèles

3. AppSettingsManager stocke les modèles

4. Les services Pyro5 consomment les modèles

5. services.json décrit uniquement les services

2. Comment écrire models.json

Règles :

3. Comment écrire services.json

Règles :

4. Résumé

Protocoles des API LLM

Protocoles d'appel LLM : synchrone vs streaming

1. Appel synchrone : HTTP POST classique

Caractéristiques

Exemple (OpenAI/Mistral-like)

2. Appel streaming : HTTP POST + protocole de flux

2.1. SSE (Server-Sent Events)

Caractéristiques

Exemple

2.2. Chunked Transfer Encoding (Ollama)

Exemple

Construction des modèles : `models.json` et `services.json`

1. `models.json` décrit les modèles

5. `services.json` décrit uniquement les services

2. Comment écrire `models.json`

3. Comment écrire `services.json`

4.1. `generate()`

4.2. `stream_generate()`

Comment `ReActAgent` s'insère dans le Workflow LlamaIndex

Étape 5 — Le workflow relance `take_step()` si nécessaire

La classe `ReActType`

**1. Le ReActOutputParser n'est pas utilisé pendant le streaming**