IndexServer, client Pyro5 Architecture v200

, par Bertrand Degoy

IndexServer occupe une position centrale dans l’architecture v200 en assurant un accès rapide et sécurisé aux index RAG persistant en RAM.

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.

PNG - 1.5 Mo

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