Une architecture de base de connaissances à 4 niveaux pour améliorer la précision des agents d'IA

Un développeur sur r/openclaw a détaillé une architecture pour une base de connaissances structurée conçue pour transformer des agents LLM génériques en experts de domaine en fournissant un contexte spécifique sur les outils, les workflows et les politiques.

Le problème avec les approches RAG courantes

La source identifie plusieurs problèmes avec les implémentations RAG typiques : pas de classification des requêtes (chaque question reçoit le même pipeline de récupération), pas de hiérarchisation (les documents de gouvernance traités de la même manière que les articles de blog), pas de budget (la fenêtre de contexte de l'agent remplie de fragments non pertinents), et pas d'auto-réparation (les documents obsolètes/cassés restent cassés pour toujours).

Un pipeline de base de connaissances à 4 niveaux

Le système utilise quatre niveaux distincts :

• Niveau de gouvernance — Toujours chargé. Contient l'identité de l'agent, les politiques et les règles comme contexte non négociable.
• Niveau de l'agent — Documentation par agent. Par exemple, un agent vocal nommé Lucy reçoit des documents sur la gestion des appels, tandis qu'un agent nommé Binky (CRO) reçoit des documents sur la conversion.
• Niveau pertinent — Récupération dynamique par requête avec correspondance titre/corps, limitée à un maximum de 5 documents et un budget de 12 000 caractères par document.
• Niveau wiki — Plus de 200 articles de référence consultables via un pont de système de fichiers, couvrant l'histoire de l'IA, les définitions d'outils, les modèles de workflow et les comparaisons de plateformes.

La classification des requêtes comme arme secrète

Avant toute récupération, un classificateur basé sur des regex détermine la quantité de contexte nécessaire pour une question :

• DIRECT — Pour des tâches comme "Résumez ce texte" où aucune base de connaissances n'est nécessaire.
• SKILL_ONLY — Pour des tâches comme "Écrivez-moi un tweet" où la documentation des compétences de l'agent est suffisante.
• HOT_CACHE — Pour des questions comme "Qui gère la facturation ?" répondues à partir des documents de gouvernance et d'agent dans le cache mémoire.
• FULL_RAG — Pour des requêtes complexes comme "Comparez les prix de n8n vs Zapier" nécessitant une recherche vectorielle complète et un pont wiki.

Cette classification seule aurait réduit les coûts en tokens d'environ 40 % car la plupart des questions n'ont pas besoin d'un RAG complet.

Structure et organisation de la base de connaissances

Chacun des 200+ articles suit un format cohérent : un titre clair avec portée, un contenu pratique (tableaux, exemples de code, cadres décisionnels), 2+ sources citées avec de vraies URL, 5 descriptions de référence d'images et 2 références vidéo.

Le contenu est organisé en domaines spécifiques :

• Fondations IA/ML (18 articles) — histoire, transformers, embeddings, agents
• Outillage (16 articles) — définitions, sécurité, taxonomie, gestion des erreurs, audit
• Workflows (18 articles) — types, plateformes, analyse des coûts, modèles HIL
• Génération d'images (115 fichiers) — 16 fournisseurs, comparaisons, cadres d'invite
• Génération vidéo (109 fichiers) — traitements, pipelines, guides de plateforme
• Support (60 articles) — contenu du centre d'aide client

Système d'auto-réparation

L'architecture inclut un système d'évaluation qui note la santé de la base de connaissances sur une échelle de 0 à 100 et traite automatiquement les problèmes : les embeddings manquants déclenchent un ré-embedding, le contenu obsolète est signalé pour rafraîchissement, et les références cassées sont réparées ou supprimées. Le score de santé serait passé de 71 à 89 après la première passe de réparation.

Résultats et points clés à retenir

Avant la mise en œuvre de la base de connaissances, les agents inventaient des définitions d'outils, créaient des prix et donnaient des conseils de workflow génériques. Après la mise en œuvre, les agents citent des documents spécifiques, fournissent des comparaisons précises de plateformes avec de vrais prix, et savent quand dire "Je n'ai pas de données actuelles sur cela."

Points clés à retenir de l'implémentation :

• Classez avant de récupérer — toutes les questions n'ont pas besoin de RAG.
• Budgétisez votre fenêtre de contexte — 60 000 caractères au total, avec une limite stricte par document.
• La structure l'emporte sur le volume — 200 articles bien organisés valent mieux que 10 000 fragments aléatoires.
• L'auto-réparation n'est pas optionnelle — les bases de connaissances se dégradent, donc construisez une surveillance dès le premier jour.
• Écrivez pour les agents, pas pour les humains — privilégiez les tableaux aux paragraphes, les cadres décisionnels à la prose, et les exemples concrets aux explications abstraites.