Les services IA de DnC

Les modes de synthèse

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

Le Moteur RAG de la v200 (RagRuntime) 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 le 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é en mémoire 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 (service rag.reader)

Module de recherche RAG, interne au daemon. Une architecture qui séparerait le modèle d'embedding et l'index dans des services distincts du daemon 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 le service 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, RagRuntime

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 "RagRuntime" 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 : un RAG Engine 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.

2.2. un RAG Engine 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 notre 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 chacun leur fréquence d'accès

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, RagReader) :

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

Les services IA de DnC

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 (service rag.reader)

Interaction avec le client

Avantages de cette architecture

v200 : Introduction, RagRuntime

1. Objectif : Modularité systémique

1.1. Modularité des modèles

1.2. Modularité des index

1.3. Rapidité via daemon Pyro5

2. Objectif : un RAG Engine indépendant d'API externes

2.1. Suppression des dépendances structurelles

2.2. un RAG Engine 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 notre architecture

1. Les index sont lourds

2. Les RemoteIndexService sont stateless

3. Le daemon est long-lived

4. Les thèmes ont chacun leur fréquence d'accès

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é

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`