LLM Council (Local, Distributed)
Système de consensus multi-LLM local avec Ollama : réponses parallèles → revue anonymisée → synthèse chairman.
Teaser démo
Ce que vous voyez en 30 secondes : réponses (Stage 1), revue anonymisée (Stage 2), synthèse (Stage 3), santé + latences.
Problème
Un seul modèle peut produire des réponses fragiles, biaisées ou inconsistantes. Comparer plusieurs modèles de façon reproductible est difficile, et il est souvent impossible d’expliquer pourquoi un résultat final a été retenu.
Le local-first compte : les données sensibles restent sur la machine, l’inférence fonctionne hors ligne, les coûts sont prévisibles et l’on évite le vendor lock‑in.
Solution (vue d’ensemble)
LLM Council sépare les rôles en services indépendants : membres (réponses), orchestrateur (coordination + anonymisation), chairman (synthèse) et UI (visualisation).
L’orchestrateur n’appelle pas les LLMs ; il coordonne uniquement les requêtes et agrège les réponses.
Architecture
Architecture en bref — L’UI envoie un prompt et une politique à l’orchestrateur. Celui-ci distribue vers les pairs Ollama, anonymise, collecte les votes, puis transmet au chairman pour une réponse JSON finale. Health/heartbeat et historique de runs sont stockés localement.
- UI : 5173 • Orchestrateur : 9000 • Chairman : 9100
- Membres : 8001–8003 • Ollama : 11434
- Trafic local uniquement ; aucune inférence externe.
Pipeline (Stages 1–3)
- Input : prompt + politique depuis l’UI.
- Action : les membres appellent les modèles Ollama locaux.
- Output : N réponses candidates + latences.
- Tolérance : un membre manquant n’arrête pas le run.
- Input : réponses mappées en A/B/C.
- Action : revues et scores anonymisés (évite le biais d’identité).
- Output : classements + critiques.
- Tolérance : nécessite au moins 2 réponses.
- Input : top réponses + reviews.
- Action : synthèse finale avec schéma JSON strict.
- Output : réponse unique + métadonnées.
- Tolérance : synthèse même si reviews incomplètes.
Décisions d’ingénierie
- Contrats JSON/Zod stricts à chaque frontière.
- Agrégation type Borda pour un classement stable.
- Monitoring heartbeat + /health agrégé.
- SQLite + WAL pour démos reproductibles.
- Tolérance aux pannes partielles (Stage 2 >=2 réponses).
Reproductibilité
npm install
npm --prefix orchestrator install
npm --prefix chairman install
npm --prefix ui install
cp .env.example .env
cp orchestrator/.env.example orchestrator/.env
cp chairman/.env.example chairman/.env
cp ui/.env.example ui/.env
./scripts/run_all_local.sh
open http://localhost:5173Astuce : cliquez sur Run Pipeline puis ouvrez les onglets Stage 1–3.
Sécurité & confidentialité
- Inférence locale via Ollama ; aucun appel cloud.
- Historique SQLite activable/désactivable selon la sensibilité des démos.
- Pas d’auth/rate limiting par défaut (à ajouter pour un usage LAN partagé).
Limites & roadmap
- Pas d’auth ni rate limiting par défaut (scope démo).
- Pas de persistance distribuée (état local uniquement).
- Qualité dépendante des modèles et du matériel locaux.
- Retry/backoff pour modèles instables.
- Auth + rôles pour démos LAN partagées.
- Client d’inférence consolidé pour configs uniformes.
- Tests étendus sur transitions et schémas.
- Tracing OpenTelemetry optionnel.
Ce que cela démontre
| Capacité | Preuve | Où regarder |
|---|---|---|
| Orchestration distribuée | Coordination + fan-out | orchestrator/src/server.ts |
| Contrats stricts | Schémas Zod + validation JSON | orchestrator/src/contracts/* |
| Observabilité | Heartbeat + /health agrégé | orchestrator/src/health.ts |
| Visualisation UI | Vues Stage + run history | ui/ |