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.