J'ai abandonné l'idée de « conscience » dans mon RAG — et c'est la meilleure décision que j'ai prise

Pendant plusieurs jours, j'ai voulu implémenter quelque chose d'ambitieux dans mon système RAG multi-agents : une forme de « conscience » capable d'anticiper, de raisonner, de se réguler elle-même. L'idée était séduisante sur le papier. En pratique, j'ai rapidement compris que la complexité était inversement proportionnelle aux résultats. Du coup, j'ai pivoté vers quelque chose de plus pragmatique : un monitoring complet. Et ce pivot a tout changé.

Voici ce que j'ai découvert — et corrigé — grâce à ce tableau de bord.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

Ce que « conscience » voulait vraiment dire dans mon cas

Mon ambition initiale était de créer un pipeline à 5 niveaux (N1 à N5) capable de :
- détecter des patterns comportementaux automatiquement,
- ajuster ses propres paramètres en temps réel,
- prédire les prochaines intentions de l'utilisateur,
- cristalliser des apprentissages en mémoire long-terme.

J'ai implémenté les niveaux N1 à N4. Et j'ai rapidement réalisé que sans visibilité sur ce qui se passe, je construisais en aveugle. Chaque « amélioration » pouvait introduire des régressions invisibles. Les modèles Ollama locaux consommaient de la VRAM sans que je sache vraiment pourquoi certains étaient lents. Des sources web se retrouvaient injectées dans tous les projets alors qu'elles n'auraient dû alimenter qu'un seul contexte.

La conscience sans les yeux, ce n'est pas de la conscience. C'est du bruit.

Le tableau de bord pilot.html : ce que les chiffres révèlent

Aujourd'hui, mon monitoring affiche 10/10 — Bon. Ce score est le résultat de jours d'itérations rendues possibles par la visibilité, pas par l'ambition.

Voici ce que j'observe en temps réel :

Ces chiffres ne tombent pas du ciel. Ils sont le résultat d'une série de corrections ciblées que le monitoring a permis d'identifier.

1. Les modèles Ollama ne fonctionnaient pas en symbiose

C'est probablement la découverte la plus impactante. J'avais trois modèles locaux en production :
- bge-m3:q8_0 pour les embeddings (686 MB VRAM)
- qwen2.5-coder:3b pour les tâches FORMAT (2600 MB VRAM, 77 TPS)
- qwen3:4b-instruct-2507-q4_K_M pour les SEMANTIC (3 400 MB VRAM, 76 TPS)
 
Total théorique : ~6686 MB sur un GPU de 6 GB. Ça ne tenez pas. car je ne regardais pas la bonne métrique. La métrique qui est affiché partout sur les modèles est GGUF hors cette métrique ne correspond pas à la réalité stocké en VRAM dans le GPU qui s'avère souvent de 500 MB supérieure.

Du coup vu que je j'avais 600 MB supérieures à ce que la carte pouvait accepter j'ai downgrader certains modèles en mesurant certaines performances et j'ai finalement adopter cette config:

- bge-m3:q8_0 pour les embeddings (686 MB VRAM)
- qwen2.5-coder:1.5b-instruct pour les tâches FORMAT (1 346 MB VRAM, 148 TPS)
- qwen3:4b-instruct-2507-q4_K_S pour les tâches SEMANTIC (3 297 MB VRAM, 62 TPS)

Total théorique : ~5 329 MB sur un GPU de 6 GB. Ça tient — à condition que les trois soient chargés en simultané. 

Sans comptabiliser correctement la VRAM totale, les modèles se déchargeaient et se rechargaient entre chaque appel. Le résultat : une latence supplémentaire de plusieurs secondes par inférence, invisible dans les logs applicatifs mais catastrophique en production.

Le monitoring m'a permis de voir les TPS réels par modèle, de corréler avec les fenêtres de chargement GPU, et de configurer OLLAMA_KEEP_ALIVE=24h avec OLLAMA_MAX_LOADED_MODELS=3. Depuis, les benchmarks synergy-10 tournent à 90 % de réussite avec les deux modèles chargés simultanément. Le qwen3 atteint 94 % sur general-16.

2. Les sources web s'injectaient dans tous les projets

Mon système RAG ingère des sources web crawlées. Ce que je n'avais pas anticipé : sans filtrage par projet, une source crawlée pour le projet docker-prod se retrouvait dans le contexte du projet webakey_frontend, polluant les embeddings et dégradant la pertinence des réponses.

Le monitoring a rendu ce problème visible en quelques minutes : la vue par projet dans le tableau de bord montrait des sources web avec des domaines incohérents. J'ai ajouté un filtre project sur toutes les requêtes RAG et sur le pipeline d'injection. Résultat immédiat : meilleure pertinence des réponses et réduction du bruit dans les embeddings.

3. Des tables, vues et fonctions orphelines par centaines

En auditant la base pgvector, j'ai découvert un cimetière silencieux. Des tables créées pour des expériences abandonnées, des vues qui ne servaient plus personne, des fonctions PL/pgSQL appelées nulle part.

Le KG affichait 100 entités orphelines (3 % du total) — ce qui semblait faible, mais représentait en réalité des relations qui ne menaient nulle part et dégradaient la qualité du graphe. J'ai purgé ces orphelins, revu les index (en supprimant les redondants et en ajoutant des index manquants sur les colonnes filtrées fréquemment), et restructuré plusieurs vues.

Avant / après :
- Temps moyen d'une requête RAG : réduit de ~40 %
- Requêtes coûteuses identifiées et corrigées dans le monitoring

4. Les patterns token-gourmands, enfin visibles

17,73 millions de tokens en 7 jours. C'est beaucoup. Mais combien sont vraiment du gaspillage ?

Le monitoring révèle un taux de 5,6 % de waste tokens. Les principaux coupables :

Les cat > représentent des scripts écrits inline au lieu d'être passés en fichier. Les psql:other sont des requêtes non optimisées qui retournent trop de données sans LIMIT. Ces patterns, invisibles sans monitoring, représentaient des centaines de milliers de tokens gaspillés chaque semaine.

5. Les relations orphelines dans le graphe de connaissances

Le KG avait des relations pointant vers des entités supprimées. Ces relations « fantômes » n'étaient jamais utilisées mais elles polluaient les scores de similarité et les calculs de routage.

Avec le monitoring, j'ai pu identifier les 100 orphelins restants (après nettoyage), les corriger, et valider que 100 % des 4 068 relations actives sont maintenant revues et valides. Le graphe couvre 267 domaines distincts — de Sf7Prod-Backend-Symfony (931 entités) à GrepAI-Monitoring (53 relations).

6. La migration du routage : de regex vers la sémantique

Avant, le routage des agents reposait principalement sur des règles regex. Simple, rapide, mais limité. Un prompt qui ne correspondait à aucune règle tombait dans un agent par défaut, souvent mauvais.

La migration vers le routage vectoriel (cosine similarity avec bge-m3) a transformé les chiffres :

Surtout, la précision monte à 82 % pour les similarités > 0,80. En dessous de 0,40, elle chute à 32 %. La leçon : fixer un seuil de confiance minimum et refuser de router un prompt ambigu plutôt que de le confier au mauvais agent.

7. La pseudo-conscience : ce qui fonctionne vraiment

Après avoir réduit le scope, voici ce que mon système « inconscient » fait effectivement bien :

• N1-tidy : 34 runs/heure, latence moyenne 1 541 ms — saliency decay, embedding, détection de posture
• N2-consolidation : 13 runs/heure — patterns, prédictions Markov, brief pré-session
• N3-meta-learn : 11 runs/heure, seulement 508 ms — métriques, auto-tuning des seuils
• N4-deep-analysis : 5 runs/heure, 6 039 ms — analyse profonde via qwen3:4b local (coût : 0 €)

615 broadcasts sur le bus de conscience en 24 heures. 3 signaux actifs en mémoire de travail. Des prédictions d'agents à 27 % de précision (à améliorer, mais déjà utiles).

Le monitoring m'a permis de désactiver les composants qui ne fonctionnaient pas (N5, consciousness-bus-advisor, thalamic-gate) et de concentrer les ressources sur ce qui produit de la valeur réelle.

Ce que le RAG et le KG font maintenant avec leurs propres données

C'est peut-être la partie la plus satisfaisante. Les données collectées par le monitoring alimentent désormais le système lui-même :

• Les patterns de routage servent à entraîner le routeur vectoriel
• Les skills les plus utilisés (ROI > 90) sont automatiquement promus
• Le graphe de connaissances s'enrichit des sessions : chaque interaction devient une relation potentielle
• Le pipeline de cristallisation transforme les patterns récurrents en skills permanents

Exemple concret : Rag Optimizer Hnsw Docker Rebuild a un ROI de 90,75 pour 156 usages sur 30 jours. Ce skill a été appris automatiquement, cristallisé depuis les sessions, et est maintenant utilisé par 12 agents différents. Sans monitoring, je n'aurais jamais su qu'il existait.

Ce que j'aurais fait différemment

Si je devais tout recommencer :

1. Monitorer d'abord, construire ensuite. Un système invisible est un système incontrôlable.
2. Fixer les basics VRAM avant d'optimiser. Toute la beauté d'une architecture multi-modèles s'effondre si les modèles ne sont pas co-chargés.
3. Filtrer par projet dès le premier jour. La contamination des embeddings est silencieuse et cumulative.
4. Mesurer le gaspillage token en continu. 5,6 % peut sembler faible, mais sur 17 millions de tokens par semaine, c'est presque 1 million de tokens gaspillés chaque semaine.
5. Traiter le KG comme du code. Les relations orphelines, c'est comme de la dette technique : invisible, coûteuse, et qui s'accumule.

Conclusion

La conscience artificielle dans un RAG, c'est un objectif atteignable. Mais sans un monitoring robuste comme fondation, vous construisez une cathédrale sur du sable. Ce que j'ai mis en place n'est pas de la conscience au sens philosophique — c'est un système qui observe, mesure, corrige et apprend en boucle. C'est déjà remarquablement efficace.

Le monitoring n'est pas un outil de reporting. C'est le système nerveux de votre infrastructure IA.

Qui suis je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.