L'implémentation diffère, mais il suffit d’orienter le modèle avec des instructions et reproduire le même comportement.
Maintenant, sur les grand principes de l'implémentation, j'ai quelque chose qui ressemble à ça:
Python, parce que ce c'est pratique, tous les outils et toutes les bibliothèques seront disponibles simplement.
vllm pour l'inférence des llm, rapide et très performant. Mais si tu es seul utilisateur, peut être que llama.cpp peut suffire, surtout que l'écart de performance s'est réduit ces derniers temps (par contre llama.cpp est strictement orienté mono utilisateur). Sinon SGLang semble un bon choix mais je connais pas très bien.
SentenceTransformers pour la vectorisation de textes + chromadb pour le stockage (pour conserver du texte en mémoire et le retrouver). Simple à implémenter.
Redis en option si tu veux pouvoir implémenter le stockage persistant de certaines données avec un système de compte (instructions pour le llm en entrée par exemple).
Ray serve pour la gestion des différents services, mais un ensemble d'instance uvicorn pilotés par des scripts peuvent faire le boulot (surtout que gérer vllm depuis ray est un peu galère, je suis justement en train de me battre en ce moment pour passer de la version 0.7 à 0.13...).
Après tu pilotes tout ça avec un serveur reproduisant l'API OpenAI, ce qui te permet d'être compatible avec un maximum de client (c'est pas compliqué, mais ça peut être un peu chiant à faire).
Le serveur conserve pour chaque connexion un contexte, que tu viens compléter en utilisant les différents outils (par exemple injecter de la donné).
Enfin, l'architecture de l'exécution des requêtes (le passage d'un modèle à l'autre) est semblable à un parcours de graphe acyclique. Tu as pas exemple en entrée un choix entre différents outils, qui peut être à plusieurs niveaux, ce choix peut faire appel à d'autre outils, recherche des des bases de données, et terminer sur la génération d'une réponse.
Ce graphe peut être défini comme tu le souhaites, mais j'ai opté pour des fichiers YAML qui définissent un type d'outils, les instructions, différentes variables et d'autre fichiers liées par des noms.
Si tu comptes déployer un service avec de la répartition, chacun des sous-services devraient être implémenté dans des serveurs distincts.
Enfin, tu implémentes un service qui prends en entrée les requêtes utilisateur et parcourant le graphe pour générer la réponse (en gérant un contexte dans lequel les différents sous-service peuvent ajouter de la donné).
Si tu fais communiquer tout ça avec de l'HTTP, tu pourras faire de la répartition simplement (seuls les serveur de données comme chromadb vont être plus complexes à gérer).
Conseil: Ne pas de fier à un modèle spécifique car ça peut évoluer rapidement, il faut penser à la modularité dès le départ pour éviter d'avoir à tout réimplémenter plusieurs fois.
D'où mon choix d'une implémentation basée sur des fichiers YAML. Ca peut être critiqué, tu peux faire autrement, mais il est très important de bien séparer les instructions et les paramètres des modèles de l'implémentation.
Parce qu'il faut partir du principe que les paramètres des modèles sont temporaires et doivent pouvoir être réécrits à n'importe quel moment (un simple changement de formulation sur un llm pouvant améliorer la qualité des réponses !).
# J'ai déjà fais ça
Posté par Florian.J . En réponse au journal Réflexions sur la conception d’un système cognitif local orienté architecture et contrôle. Évalué à 1. Dernière modification le 17 janvier 2026 à 20:50.
Je suis pas certain d'avoir bien compris le sens de la demande, mais ça ressemble à quelque chose que j'ai déjà implémenté.
Je pense que le point de départ serait un modèle "router" tel que:
https://huggingface.co/katanemo/Arch-Router-1.5B
En gros tu spécifies un contexte, une liste de choix et le modèle choisit le plus probable.
J'ai utilise à la base un autre type de modèle axé sur la classification de texte (j'ai commencé avant que Sam Altman popularise le principe du routeur):
https://huggingface.co/MoritzLaurer/bge-m3-zeroshot-v2.0
L'implémentation diffère, mais il suffit d’orienter le modèle avec des instructions et reproduire le même comportement.
Maintenant, sur les grand principes de l'implémentation, j'ai quelque chose qui ressemble à ça:
Python, parce que ce c'est pratique, tous les outils et toutes les bibliothèques seront disponibles simplement.
vllm pour l'inférence des llm, rapide et très performant. Mais si tu es seul utilisateur, peut être que llama.cpp peut suffire, surtout que l'écart de performance s'est réduit ces derniers temps (par contre llama.cpp est strictement orienté mono utilisateur). Sinon SGLang semble un bon choix mais je connais pas très bien.
SentenceTransformers pour la vectorisation de textes + chromadb pour le stockage (pour conserver du texte en mémoire et le retrouver). Simple à implémenter.
Redis en option si tu veux pouvoir implémenter le stockage persistant de certaines données avec un système de compte (instructions pour le llm en entrée par exemple).
Ray serve pour la gestion des différents services, mais un ensemble d'instance uvicorn pilotés par des scripts peuvent faire le boulot (surtout que gérer vllm depuis ray est un peu galère, je suis justement en train de me battre en ce moment pour passer de la version 0.7 à 0.13...).
Après tu pilotes tout ça avec un serveur reproduisant l'API OpenAI, ce qui te permet d'être compatible avec un maximum de client (c'est pas compliqué, mais ça peut être un peu chiant à faire).
Le serveur conserve pour chaque connexion un contexte, que tu viens compléter en utilisant les différents outils (par exemple injecter de la donné).
Enfin, l'architecture de l'exécution des requêtes (le passage d'un modèle à l'autre) est semblable à un parcours de graphe acyclique. Tu as pas exemple en entrée un choix entre différents outils, qui peut être à plusieurs niveaux, ce choix peut faire appel à d'autre outils, recherche des des bases de données, et terminer sur la génération d'une réponse.
Ce graphe peut être défini comme tu le souhaites, mais j'ai opté pour des fichiers YAML qui définissent un type d'outils, les instructions, différentes variables et d'autre fichiers liées par des noms.
Si tu comptes déployer un service avec de la répartition, chacun des sous-services devraient être implémenté dans des serveurs distincts.
Enfin, tu implémentes un service qui prends en entrée les requêtes utilisateur et parcourant le graphe pour générer la réponse (en gérant un contexte dans lequel les différents sous-service peuvent ajouter de la donné).
Si tu fais communiquer tout ça avec de l'HTTP, tu pourras faire de la répartition simplement (seuls les serveur de données comme chromadb vont être plus complexes à gérer).
Conseil: Ne pas de fier à un modèle spécifique car ça peut évoluer rapidement, il faut penser à la modularité dès le départ pour éviter d'avoir à tout réimplémenter plusieurs fois.
D'où mon choix d'une implémentation basée sur des fichiers YAML. Ca peut être critiqué, tu peux faire autrement, mais il est très important de bien séparer les instructions et les paramètres des modèles de l'implémentation.
Parce qu'il faut partir du principe que les paramètres des modèles sont temporaires et doivent pouvoir être réécrits à n'importe quel moment (un simple changement de formulation sur un llm pouvant améliorer la qualité des réponses !).