Les services IA de DnC

IndexServer, client Pyro5

Bertrand Degoy — 2026-07-04T15:06:18Z

IndexServer occupe une position centrale dans l'architecture v200 en assurant un accès rapide et sécurisé à l'index RAG.

Les deux rôles d'IndexServer

IndexServer occupe une position centrale dans l'architecture v200 et assume deux responsabilités complémentaires : un rôle statique en tant que façade RPC du daemon, et un rôle dynamique en tant que chef d'orchestre du chargement et de la gestion des index en mémoire.

1. Rôle statique : façade RPC du daemon

Lors de l'initialisation du système, le daemon instancie IndexServer et l'enregistre auprès de Pyro5.
Dans cette phase, IndexServer devient l'interface publique du daemon, c'est‑à‑dire :

le point d'entrée pour toutes les requêtes externes liées aux index,
le service exposé via RPC,
l'unique API métier accessible aux clients distants.

Le daemon ne fournit aucune logique métier : il se contente d'héberger IndexServer et de maintenir l'infrastructure RPC.
Dans cette perspective, IndexServer est bien la façade du daemon.

IndexServer est le service maître du système d'indexation dans l'architecture v200.
Il est initialisé par le daemon et constitue le point central de gestion des index en RAM.

Rôle structurel

Coordonne le chargement des index (via ThemeIndexLoaderManager).
Gère la présence des index en RAM (via MemoryManager).
Crée et expose les RemoteIndexService (un par thème).
Fournit une API Pyro5 permettant aux clients d'accéder aux index.
Garantit qu'un index n'est chargé qu'une seule fois dans le processus du daemon.

Position dans l'architecture

daemon.py ↓ initialise
MemoryManager
IndexServer ↓ crée à la demande
RemoteIndexService (un par thème) ↓ utilise
Index en RAM ↑ fourni par
ThemeIndexLoaderManager

IndexServer est donc le chef d'orchestre :
il ne charge jamais directement depuis le disque, mais délègue au loader, puis stocke le backend dans MemoryManager.

2. Rôle dynamique : chargement et gestion des index

Une fois initialisé, IndexServer prend en charge l'ensemble des opérations internes liées aux index :

interrogation de MemoryManager pour vérifier la présence d'un backend en RAM,
déclenchement du chargement depuis le disque via ThemeIndexLoaderManager lorsque nécessaire,
instanciation des loaders concrets (FAISS, LlamaIndex, Dummy),
construction du backend unifié,
stockage du backend en RAM,
création et gestion des RemoteIndexService pour chaque thème.

Dans cette phase, IndexServer agit comme le coordinateur opérationnel du système d'indexation.
Le daemon n'intervient plus : il n'est pas consulté, ne participe à aucune décision, et ne possède aucune méthode métier.

Voici ce que fait IndexServer lorsqu'un client demande un index pour un thème donné.

1. Le client appelle IndexServer :

get(theme)

2. IndexServer interroge MemoryManager :

MemoryManager.get(theme)

Si l'index est déjà en RAM, IndexServer le retourne immédiatement.
Sinon, il déclenche la chaîne de chargement.

3. Index absent → IndexServer appelle ThemeIndexLoaderManager :

ThemeIndexLoaderManager.load(theme)

4. Le loader manager instancie le loader concret :

LlamaIndexLoader
FAISSLoader
DummyLoader
(selon la configuration du thème)

5. Le loader concret charge les données depuis le disque :

fichiers FAISS
fichiers LlamaIndex (docstore, vector_store, index_store)
ou backend factice

Il retourne un index brut.

6. ThemeIndexLoaderManager encapsule l'index brut dans un backend unifié :

LlamaIndexBackend
FaissBackend
DummyBackend

7. IndexServer stocke le backend unifié dans MemoryManager :

MemoryManager.set(theme, backend)

8. IndexServer retourne le backend au client ou au RemoteIndexService

L'index est maintenant en RAM, prêt à être utilisé pour :

retrieve()
query()
astream()

3. API d'IndexServer (v200)

IndexServer expose une API Pyro5 orientée service.

3.1. `get(theme_name)`

Retourne un backend unifié pour le thème demandé.

Comportement :

Vérifie si l'index est en RAM via MemoryManager.
Si absent → déclenche le chargement via ThemeIndexLoaderManager.
Retourne le backend unifié (FAISS, LlamaIndex, Dummy).

Signature :

def get(self, theme_name: str): ...

3.2. `list()`

Retourne la liste des thèmes disponibles ou déjà chargés.

Signature :

def list(self) -> List[str]: ...

3.3. `ping()`

Permet de vérifier que le service IndexServer est opérationnel.

Signature :

def ping(self) -> str: return "index.server.pong"

3.4. `create_remote_service(theme_name)`

Crée un RemoteIndexService pour un thème donné si nécessaire.

Signature :

def create_remote_service(self, theme_name: str): ...

3.5. `has(theme_name)`

Indique si un backend est déjà chargé en RAM.

Signature :

def has(self, theme_name: str) -> bool: ...

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

Chargement des index

Bertrand Degoy — 2026-06-25T06:58:00Z

Le chargement des index repose sur une architecture modulaire où chaque composant joue un rôle précis, depuis le daemon initial jusqu'aux services distants qui exploitent les données en RAM.
L'objectif est de garantir un chargement efficace, unifié et non redondant des index, tout en permettant une mise en mémoire centralisée et partagée.
Grâce au ThemeIndexLoaderManager, les index sont reconstruits depuis le disque via des loaders spécialisés, normalisés en backends homogènes, puis mis à disposition des services Pyro5 pour répondre aux requêtes des clients. L'ensemble forme une chaîne cohérente, optimisée pour la performance et la réutilisation.

Chargement des index

Architecture générale

daemon.py ↓ initialise
MemoryManager
IndexServer ↓ crée à la demande
RemoteIndexService (un par thème) ↓ utilise
Index en RAM ↑ fourni par
ThemeIndexLoaderManager (chargement disque → backend unifié)

Interprétation : daemon.py initialise les services (MemoryManager, IndexServer).

IndexServer est le maître : il gère les index et crée les RemoteIndexService.

RemoteIndexService exécute les requêtes RAG sur les index en RAM.

MemoryManager stocke les backends unifiés en RAM.

ThemeIndexLoaderManager est un composant externe appelé par IndexServer uniquement quand un index n'est pas en RAM

Dynamique du chargement

Vue depuis le daemon :

Description des composants

daemon.py

Point d'entrée du système.
Responsable de l'initialisation :

MemoryManager (gestion centralisée des backends en RAM)
IndexServer (service maître Pyro5)
enregistrement des services Pyro5

Le daemon n'interagit jamais avec le disque : il délègue tout chargement à IndexServer, qui lui-même délègue aux loaders.

MemoryManager

Gestionnaire RAM partagé.

Stocke les backends unifiés (FAISS, LlamaIndex, Dummy)
Applique une politique LRU/MRU
Fournit :
- get(theme)
- set(theme, backend)
- touch(theme) pour la mise à jour de l'ordre d'utilisation

MemoryManager garantit qu'un index n'est chargé qu'une seule fois.

IndexServer

Service maître Pyro5.

Centralise le chargement des index
Un backend par thème
Crée les RemoteIndexService à la demande
Réutilise les services existants
Ne charge jamais depuis le disque

Lorsqu'un index est absent de la RAM :

IndexServer appelle ThemeIndexLoaderManager
Le loader charge depuis le disque
Le loader construit un backend unifié
IndexServer stocke ce backend dans MemoryManager

RemoteIndexService

Service Pyro5 par thème.

Exécute les opérations sur l'index en RAM :
- retrieve()
- query()
- astream()
Ne charge jamais depuis le disque
Ne connaît pas les loaders
Ne manipule que des backends unifiés

ThemeIndexLoaderManager (IndexLoaderFactory)

Factory de loaders.
Responsable de toute la chaîne de chargement depuis le disque.

Fonctions :

Lire la configuration du thème
Déterminer le type d'index :
- llama_index
- faiss
- dummy
Instancier le loader concret
Charger les données persistées
Construire un backend unifié :
- LlamaIndexBackend
- FaissBackend
- DummyBackend
Retourner ce backend à IndexServer

IndexServer ne manipule jamais les loaders concrets.

Chaîne de chargement des index depuis le disque

Vue d'ensemble

ThemeIndexLoaderManager ↓
Sélection du loader concret ↓
Chargement depuis le disque ↓
Construction du backend unifié ↓
Retour à IndexServer ↓
Stockage dans MemoryManager (RAM) ↓
RemoteIndexService utilise l'index

Sélection du loader

index_type = theme_config.get("index_type", "llama_index") if index_type == "llama_index": loader = LlamaIndexLoader(theme_name, theme_config)
elif index_type == "faiss": loader = FAISSLoader(theme_name, theme_config)
else: loader = DummyLoader(theme_name)

Chaque loader connaît :

son répertoire de stockage,
son format de données,
la manière de reconstruire un backend utilisable.

Chargement depuis le disque

LlamaIndexLoader

Construit un StorageContext
Charge les fichiers persistés :
- docstore.json
- vector_store.json
- index_store.json
Reconstruit un VectorStoreIndex
Retourne un backend unifié :

LlamaIndexBackend(index)


### **FAISSLoader**
- Charge le fichier `.faiss`
- Charge les métadonnées associées
- Reconstruit l'index FAISS en RAM
- Retourne :

FaissBackend(faiss_index, embeddings, documents)


### **DummyLoader**
Retourne un backend minimal :

DummyBackend()


## **Construction du backend unifié**
Chaque loader retourne un objet brut :
- LlamaIndex → `VectorStoreIndex`
- FAISS → `faiss_index`
- Dummy → rien (backend direct)
ThemeIndexLoaderManager encapsule cet objet dans un backend unifié :
- `LlamaIndexBackend`
- `FaissBackend`
- `DummyBackend`
Tous exposent la même API :
- `retrieve()`
- `query()`
- `astream()`
- `ping()`

## **Retour à IndexServer**
IndexServer reçoit le backend unifié :
```python
backend = loader_manager.load(theme_name)

Puis :

le stocke dans MemoryManager
crée un RemoteIndexService si nécessaire

IndexServer ne recharge jamais un index déjà en RAM.

Stockage dans MemoryManager

MemoryManager stocke :

memory.set(theme_name, backend)

et applique une politique LRU/MRU :

MRU : objets récemment utilisés → conservés
LRU : objets peu utilisés → candidats à l'éviction

Utilisation par RemoteIndexService

RemoteIndexService :

récupère le backend via MemoryManager
exécute les requêtes :
- retrieve()
- query()
- astream()
ne charge jamais depuis le disque

Résumé du chargement depuis le disque

Étape	Composant	Rôle
1	ThemeIndexLoaderManager	Sélection du loader + orchestration
2	Loader concret	Lecture disque + reconstruction
3	LoaderManager	Construction du backend unifié
4	IndexServer	Stockage + exposition Pyro
5	MemoryManager	Mise en RAM + LRU
6	RemoteIndexService	Utilisation de l'index

Trois modes de chargement des modèles

Bertrand Degoy — 2026-06-24T09:23:00Z

Dans l'architecture v200, les modèles peuvent être chargés de trois manières : via une API distante (comme Mistral), en local sans persistance (chargement HuggingFace classique dans le process), ou en mémoire persistante grâce à un service Pyro5.

Les deux premiers modes sont simples mais limités : l'API impose une latence réseau et des coûts, tandis que le chargement local disparaît dès que le process se termine.

Pyro5 apporte une troisième voie : un daemon Python indépendant, capable de conserver des objets lourds (embedding, index, SLM) en RAM de manière durable, et de les exposer via RPC à tous les composants du runtime.

Dans ce modèle, models.json décrit les modèles à charger, ModelsConfigurator les instancie une seule fois au démarrage, puis AppSettings les expose à l'ensemble du système.

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 (embedding, SLM, indexation, mémoire) en s'appuyant sur les objets déjà initialisés, garantissant ainsi cohérence, performance et séparation stricte des responsabilités.

Introduction

Dans l'architecture v200, la gestion des modèles repose sur une séparation stricte entre trois modes de chargement :

API distante (ex. Mistral) — aucun coût mémoire local, mais latence réseau et dépendance externe.
Chargement local non persistant — les modèles HF sont chargés dans le process courant, mais disparaissent dès que le process se termine.
Chargement persistant via Pyro5 — un daemon Python indépendant conserve les modèles lourds en RAM et expose leurs capacités via RPC, permettant une mutualisation entre plusieurs composants du runtime.

Cette architecture permet d'adapter le chargement des modèles aux contraintes matérielles (CPU, GPU, RAM), tout en garantissant une cohérence stricte :

models.json décrit les modèles à charger.
ModelsConfigurator les instancie une seule fois.
AppSettings les stocke en mémoire.
Les services Pyro5 les consomment via RPC sans jamais les recharger.

Vue d'ensemble du pipeline v200

1. Les trois modes de chargement des modèles

1.1 Modèles API (ex. Mistral)

Caractéristiques :

Aucun coût mémoire local
Latence réseau
Dépendance à un fournisseur
Coût financier potentiel
Pas de GPU requis

Exemple dans models.json :

"llm": { "model_name": "mistral-medium-latest", "backend": "mistral_api", "api_key": "env:MISTRAL_API_KEY"
}

Quand utiliser ?

Pas de GPU disponible
RAM limitée
Besoin d'un modèle puissant (Mixtral, Mistral Large)
Déploiement cloud ou edge léger

1.2 Modèles locaux non persistants (HF dans le process)

Caractéristiques :

Chargés par HuggingFace dans le process courant
Disparaissent à la fin du process
Temps de chargement non négligeable
Nécessitent RAM + CPU/GPU
Idéal pour tests, scripts, outils CLI

Exemple :

"slm": { "model_name": "TinyLlama/TinyLlama-1.1B-Chat-v1.0", "model_path": "/home/user/.models/TinyLlama", "backend": "hf", "device": "cpu"
}

Quand utiliser ?

Développement local
Tests unitaires
Modèles légers (<2 GB)
Pas besoin de persistance

Sur ce dernier point, notons qu'un service HTTP Rest ne chargera les modèles qu'une fois à son lancement ; dans cette configuration, on pourra s'accommoder de la non-persistance, au prix d'un délai au re-lancement du service.

1.3 Modèles persistants via Pyro5 (daemon)

Caractéristiques :

Modèles chargés une seule fois dans un daemon
Persistants en RAM
Accessibles via RPC
Mutualisés entre plusieurs composants
Idéal pour embeddings, index, SLM

Exemple dans services.json :

{ "name": "embedding.server", "class": "runtime_v2.services.embedding.embedding_server.EmbeddingServer", "params": {}
}

Quand utiliser ?

Modèles lourds (embedding, SLM)
Besoin de persistance
Plusieurs clients doivent accéder au même modèle
RAM suffisante (8–32 GB selon modèles)

2. Quelle solution pour quel modèle ? (selon contraintes matérielles)

2.1 Embedding (BGE-small, BGE-large, E5, etc.)

Contrainte	Recommandation
< 4 GB RAM	API ou modèle très léger (BGE-small)
4–8 GB RAM	HF local non persistant
> 8 GB RAM	Pyro5 persistant (recommandé)

Pourquoi Pyro5 ?
Les embeddings sont appelés très souvent → éviter les rechargements → gain x10 en latence.

2.2 SLM (TinyLlama, Phi-2, Gemma 2B)

Contrainte	Recommandation
CPU only	TinyLlama / Phi-2 via Pyro5
GPU 4–8 GB	Gemma 2B local
GPU 16 GB	Mixtral 8x7B local (rare)

Pourquoi Pyro5 ?
Les SLM sont lourds à charger → persistance indispensable.

2.3 Tokenizer

Contrainte	Recommandation
Toujours	HF local non persistant

Pourquoi ?
Le tokenizer est léger (<200 MB) → inutile de le mettre dans Pyro5.

2.4 LLM principal (Mistral, Mixtral, Claude, GPT)

Contrainte	Recommandation
Pas de GPU	API obligatoire
GPU 24–48 GB	Mixtral local possible
GPU > 80 GB	Modèles 70B locaux

Conclusion :
Dans 99 % des cas → API.

3. Exemples complets

3.1 Exemple `models.json` optimisé pour machine CPU 16 GB

Embedding en Pyro5
SLM en Pyro5
Tokenizer local
LLM via API

{ "embedding": { "model_name": "BAAI/bge-small-en-v1.5", "model_path": "/models/bge-small", "backend": "hf", "device": "cpu" }, "slm": { "model_name": "TinyLlama/TinyLlama-1.1B-Chat-v1.0", "model_path": "/models/tinyllama", "backend": "hf", "device": "cpu" }, "tokenizer": { "model_name": "mistralai/Mixtral-8x7B-Instruct-v0.1", "backend": "hf" }, "llm": { "model_name": "mistral-medium-latest", "backend": "mistral_api", "api_key": "env:MISTRAL_API_KEY" }
}

3.2 Exemple `services.json` correspondant

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

{ "daemon": { "host": "127.0.0.1", "port": 50050 }, "services": [ { "name": "embedding.server", "class": "runtime_v2.services.embedding.embedding_server.EmbeddingServer", "params": {} }, { "name": "slm.server", "class": "runtime_v2.services.llm.slm_server.SLMServer", "params": {} }, { "name": "index.server", "class": "runtime_v2.services.index.index_server.IndexServer", "params": { "embedding_service": "embedding.server" } }, { "name": "memory.server", "class": "runtime_v2.services.memory_manager.MemoryManager", "params": { "embedding_service": "embedding.server", "index_service": "index.server" } } ]
}

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 (si backend = API)

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 officielle :

{ "embedding": { "model_name": "BAAI/bge-small-en-v1.5", "model_path": "/home/iadnc/.models/bge-small", "backend": "hf", "device": "cpu" }, "slm": { "model_name": "TinyLlama/TinyLlama-1.1B-Chat-v1.0", "model_path": "/home/iadnc/.models/TinyLlama-1.1B-Chat-v1.0", "backend": "hf", "device": "cpu" }, "tokenizer": { "model_name": "mistralai/Mixtral-8x7B-Instruct-v0.1", "model_path": null, "backend": "hf", "device": null }, "llm": { "model_name": "mistral-medium-latest", "backend": "mistral_api", "api_key": "env:MISTRAL_API_KEY", "model_path": null, "device": null }
}

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 correcte, conforme à v200 :

{ "daemon": { "host": "127.0.0.1", "port": 50050 }, "services": [ { "name": "embedding.server", "class": "runtime_v2.services.embedding.embedding_server.EmbeddingServer", "params": {} }, { "name": "slm.server", "class": "runtime_v2.services.llm.slm_server.SLMServer", "params": {} }, { "name": "index.server", "class": "runtime_v2.services.index.index_server.IndexServer", "params": { "embedding_service": "embedding.server" } }, { "name": "memory.server", "class": "runtime_v2.services.memory_manager.MemoryManager", "params": { "embedding_service": "embedding.server", "index_service": "index.server" } } ]
}

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

IndexServer, client Pyro5

Les deux rôles d'IndexServer

1. Rôle statique : façade RPC du daemon

Rôle structurel

Position dans l'architecture

2. Rôle dynamique : chargement et gestion des index

1. Le client appelle IndexServer :

2. IndexServer interroge MemoryManager :

3. Index absent → IndexServer appelle ThemeIndexLoaderManager :

4. Le loader manager instancie le loader concret :

5. Le loader concret charge les données depuis le disque :

6. ThemeIndexLoaderManager encapsule l'index brut dans un backend unifié :

7. IndexServer stocke le backend unifié dans MemoryManager :

8. IndexServer retourne le backend au client ou au RemoteIndexService

3. API d'IndexServer (v200)

3.1. get(theme_name)

3.2. list()

3.3. ping()

3.4. create_remote_service(theme_name)

3.5. has(theme_name)

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

Chargement des index

Chargement des index

Architecture générale

Dynamique du chargement

Description des composants

daemon.py

MemoryManager

IndexServer

RemoteIndexService

ThemeIndexLoaderManager (IndexLoaderFactory)

Chaîne de chargement des index depuis le disque

Vue d'ensemble

Sélection du loader

Chargement depuis le disque

LlamaIndexLoader

Stockage dans MemoryManager

Utilisation par RemoteIndexService

Résumé du chargement depuis le disque

Trois modes de chargement des modèles

Introduction

Vue d'ensemble du pipeline v200

1. Les trois modes de chargement des modèles

1.1 Modèles API (ex. Mistral)

1.2 Modèles locaux non persistants (HF dans le process)

1.3 Modèles persistants via Pyro5 (daemon)

2. Quelle solution pour quel modèle ? (selon contraintes matérielles)

2.1 Embedding (BGE-small, BGE-large, E5, etc.)

2.2 SLM (TinyLlama, Phi-2, Gemma 2B)

2.3 Tokenizer

2.4 LLM principal (Mistral, Mixtral, Claude, GPT)

3. Exemples complets

3.1 Exemple models.json optimisé pour machine CPU 16 GB

3.2 Exemple services.json correspondant

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.1. `get(theme_name)`

3.2. `list()`

3.3. `ping()`

3.4. `create_remote_service(theme_name)`

3.5. `has(theme_name)`

3.1 Exemple `models.json` optimisé pour machine CPU 16 GB

3.2 Exemple `services.json` correspondant

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**