Aller au contenu principal
Comment créer une base de connaissances IA entièrement interrogeable avec OpenKB, OpenRouter et Llama
OutilsMarkTechPost1h

Comment créer une base de connaissances IA entièrement interrogeable avec OpenKB, OpenRouter et Llama

1 source couvre ce sujet·Source originale ↗·

Un tutoriel publié récemment détaille comment construire une base de connaissances locale entièrement interrogeable en combinant trois outils : OpenKB, la plateforme OpenRouter et le modèle Llama 3.3 70B de Meta, accessible gratuitement sans carte bancaire. Le guide couvre l'ensemble du pipeline, de l'installation d'OpenKB via pip jusqu'à l'interrogation structurée de documents Markdown, en passant par la génération automatique de résumés et de pages conceptuelles au format wiki. La clé API OpenRouter est récupérée de façon sécurisée via la bibliothèque Python getpass, sans jamais être inscrite en dur dans le code. Le résultat est un système de connaissance navigable, avec gestion des liens croisés entre pages, capable de répondre à des requêtes en langage naturel et d'être mis à jour de manière incrémentale.

Ce type d'architecture présente un intérêt concret pour les développeurs, chercheurs et équipes qui souhaitent organiser et interroger des corpus de documents internes sans envoyer leurs données vers des services cloud payants. En s'appuyant sur un modèle de 70 milliards de paramètres disponible gratuitement via OpenRouter, l'approche élimine le coût d'inférence tout en offrant des capacités de synthèse comparables à des solutions propriétaires. La possibilité d'analyser programmatiquement les relations entre pages et les liens croisés ouvre également des usages avancés : cartographie de concepts, détection de lacunes documentaires, ou navigation thématique automatisée dans de larges volumes de texte.

L'émergence de ce genre de tutoriel s'inscrit dans une tendance plus large de démocratisation des outils RAG (retrieval-augmented generation), qui permettent d'ancrer les réponses d'un LLM dans une base documentaire locale plutôt que dans ses seuls paramètres d'entraînement. OpenRouter joue ici un rôle d'intermédiaire unifié, donnant accès à des dizaines de modèles open source via une API commune, ce qui réduit la friction technique pour expérimenter. OpenKB, de son côté, se positionne comme une couche d'abstraction au-dessus de ces modèles, spécialisée dans la structuration wiki et la navigation sémantique. Alors que des acteurs comme Notion AI ou Confluence intègrent des fonctions similaires dans des produits fermés, des solutions comme celle-ci permettent de garder le contrôle total sur les données et l'infrastructure, un enjeu croissant pour les entreprises soumises à des contraintes de confidentialité ou de souveraineté.

Impact France/UE

Cette architecture locale répond directement aux enjeux de souveraineté des données pour les entreprises et administrations européennes soumises au RGPD et aux contraintes de confidentialité.

À lire aussi

Claude Code réfléchissait trop, puis plus assez : Anthropic corrige le coup de mou
1Next INpact 

Claude Code réfléchissait trop, puis plus assez : Anthropic corrige le coup de mou

Entre fin mars et mi-avril 2026, les utilisateurs de Claude Code ont constaté une dégradation notable du service : oubli de contexte, réponses incohérentes, consommation anormale de tokens. Anthropic a publié un post-mortem détaillé confirmant trois problèmes distincts, tous résolus le 20 avril avec la version v2.1.116. Le premier remonte au 4 mars : pour accélérer les réponses suite à des retours d'utilisateurs se plaignant de latences excessives, l'entreprise a abaissé le niveau de raisonnement par défaut de « high » à « medium ». Le gain en rapidité était réel, mais au prix d'une qualité de réponse nettement inférieure. Anthropic a fait marche arrière le 7 avril, repassant sur « high effort » pour Opus 4.6 et introduisant un nouveau palier « xhigh effort » pour Opus 4.7. Le deuxième problème, un bug, est apparu le 26 mars lors de l'activation du prompt caching : au lieu de supprimer l'ancien raisonnement une seule fois après une heure d'inactivité, le système effaçait chaque nouveau message passé ce seuil, ne conservant qu'un fragment infime de contexte. Résultat : le modèle agissait sans mémoire de ce qu'il faisait, les requêtes étaient recalculées de zéro à chaque échange, et les quotas fondaient à toute vitesse. Le bug a été identifié et corrigé le 10 avril, non sans mal : il a fallu plus d'une semaine de diagnostic, et c'est Opus 4.7 qui l'a finalement détecté lors de son analyse, là où Opus 4.6 n'avait rien trouvé. Troisième problème enfin : pour contenir la verbosité d'Opus 4.7, Anthropic a imposé le 16 avril une limite de 100 mots par réponse et 25 mots entre appels d'outils, étouffant au passage la capacité du modèle à raisonner en profondeur. La contrainte a été supprimée quatre jours plus tard. Ces trois incidents révèlent les tensions inhérentes au déploiement continu d'un outil d'IA utilisé professionnellement à grande échelle : chaque optimisation de performance ou de coût peut introduire des régressions fonctionnelles difficiles à détecter avant qu'elles n'atteignent les utilisateurs. L'impact a touché Claude Code ainsi que le Claude Agent SDK et Claude Cowork, mais pas l'API ni la couche d'inférence, ce qui indique des problèmes situés dans la couche applicative plutôt que dans le modèle lui-même. Pour des développeurs qui s'appuient sur l'outil pour des sessions de travail longues et complexes, la perte de contexte et la dégradation du raisonnement ont eu des conséquences concrètes sur la productivité. En réponse, Anthropic s'engage à plusieurs changements de processus : utiliser plus systématiquement la version publique de Claude Code plutôt que des builds internes de test, produire des analyses d'impact plus rigoureuses avant chaque modification du système, et déployer des outils d'audit et de suivi des changements en production. Le post-mortem lui-même, publiquement disponible, témoigne d'une volonté de transparence inhabituelle dans le secteur. Ces épisodes surviennent alors que la concurrence entre outils d'IA pour développeurs s'intensifie, avec GitHub Copilot, Cursor et d'autres acteurs qui scrutent chaque faux pas. Pour Anthropic, dont Claude Code est l'un des produits les plus visibles auprès des développeurs, maintenir la confiance technique passe désormais autant par la fiabilité du service que par les capacités brutes du modèle.

OutilsOpinion
1 source
RAG sans vecteurs : PageIndex récupère l'information par raisonnement
2MarkTechPost 

RAG sans vecteurs : PageIndex récupère l'information par raisonnement

PageIndex propose une alternative radicale aux systèmes de RAG (Retrieval-Augmented Generation) traditionnels : plutôt que de découper les documents en fragments et de rechercher les plus similaires par calcul vectoriel, la plateforme construit un index hiérarchique en forme d'arbre, modélisant la structure du document telle qu'elle existe, chapitres, sous-sections et titres imbriqués compris. Un modèle de langage comme GPT-5.4 raisonne ensuite sur cet arbre, navigue entre les noeuds et identifie les sections pertinentes avant même de lire le texte complet. La démonstration proposée porte sur le célèbre article scientifique "Attention Is All You Need", publié en 2017, qui a fondé l'architecture Transformer aujourd'hui omniprésente dans l'IA. Deux requêtes croisées sont posées sur ce document sans qu'un seul vecteur ou embedding ne soit calculé. Les performances de PageIndex ont été mesurées notamment sur FinanceBench, un benchmark spécialisé dans les documents financiers complexes, où l'approche surpasse significativement les pipelines vectoriels classiques. L'enjeu dépasse la simple optimisation technique. Dans les rapports financiers, les textes juridiques ou les articles de recherche, la réponse à une question ne se trouve pas toujours dans le paragraphe "le plus proche" sémantiquement : elle exige de relier des informations dispersées sur plusieurs sections, de comprendre la structure du document et d'effectuer un raisonnement en plusieurs étapes. Les systèmes RAG classiques échouent silencieusement sur ce type de requêtes, en retournant des résultats plausibles mais inexacts. PageIndex rend le processus de récupération interprétable et traçable, ce qui est crucial pour les applications professionnelles où une hallucination ou une approximation peut avoir des conséquences réelles, que ce soit dans un cabinet d'avocats, une salle d'analyse financière ou un laboratoire de recherche. Le RAG vectoriel s'est imposé comme l'architecture de référence pour connecter les LLM à des bases de connaissances externes depuis 2022-2023, porté par des bibliothèques comme LangChain ou LlamaIndex. Mais les limites de la recherche par similarité sémantique sont connues et documentées : les chunks perdent le contexte, les distances cosinus ne capturent pas la logique, et les documents longs déjouent systématiquement les pipelines standards. Plusieurs équipes cherchent des alternatives, comme GraphRAG de Microsoft, qui s'appuie sur des graphes de connaissances, ou les approches à base d'agents orchestrant plusieurs appels LLM. PageIndex s'inscrit dans cette tendance en pariant sur le raisonnement structuré plutôt que sur la puissance brute des embeddings. Avec l'arrivée de modèles toujours plus capables comme GPT-5.4, cette approche devient viable à grande échelle et pourrait redéfinir la manière dont les systèmes d'IA extraient l'information de documents complexes.

💬 Le problème avec le RAG par chunks, c'est que tu perds la structure du document avant même d'avoir posé ta question. PageIndex fait le pari inverse : construire un arbre qui reflète l'organisation réelle du document, puis laisser le LLM naviguer dedans plutôt que de faire des calculs de distance cosinus à l'aveugle. Ça marche visiblement bien sur les docs financiers complexes, et pour les usages pro où une hallucination coûte cher, c'est exactement le bon angle d'attaque.

OutilsOutil
1 source
GitNexus : un moteur de graphe de connaissances open source compatible MCP qui donne à Claude Code et Cursor une vision structurelle complète du code
3MarkTechPost 

GitNexus : un moteur de graphe de connaissances open source compatible MCP qui donne à Claude Code et Cursor une vision structurelle complète du code

Un étudiant en informatique indien a publié GitNexus, un moteur open source de graphe de connaissances conçu pour donner aux agents de codage IA une vision structurelle complète d'un dépôt de code. Le projet compte déjà plus de 28 000 étoiles et 3 000 forks sur GitHub, avec 45 contributeurs actifs. Son fonctionnement repose sur une commande unique, npx gitnexus analyze, qui lance un pipeline d'indexation en plusieurs phases : parcours de l'arborescence de fichiers, extraction de chaque fonction, classe, méthode et interface via des arbres syntaxiques Tree-sitter, puis résolution croisée des imports et des appels entre fichiers. Le résultat est un graphe complet des dépendances, stocké localement dans LadybugDB, une base de données graphe embarquée avec support vectoriel natif. Ce graphe est ensuite exposé aux agents IA via un serveur MCP (Model Context Protocol), permettant des recherches hybrides combinant BM25, embeddings sémantiques et RRF. L'option --skills génère en plus des fichiers SKILL.md ciblés pour chaque zone fonctionnelle détectée dans le code, déposés sous .claude/skills/generated/. Le problème que GitNexus cherche à résoudre est bien réel et coûteux : les agents IA comme Claude Code, Cursor ou Windsurf opèrent aujourd'hui essentiellement à l'aveugle. Ils lisent les fichiers proches du contexte ouvert et espèrent ne rien manquer. Résultat classique : un agent modifie le type de retour d'une fonction sans savoir que 47 autres fonctions en dépendent, les tests explosent, et le développeur passe deux heures à démêler ce que l'outil aurait dû savoir avant d'agir. GitNexus pré-calcule la structure complète des dépendances à l'indexation, de sorte que quand un agent interroge "qu'est-ce qui dépend de cette fonction ?", il obtient une réponse complète en une seule requête, sans enchaîner dix appels successifs à risque. Le tout tourne entièrement en local, sans qu'une seule ligne de code quitte la machine. La publication de GitNexus s'inscrit dans une dynamique plus large autour du Model Context Protocol, le standard lancé par Anthropic fin 2024 pour unifier la façon dont les agents IA accèdent à des sources de contexte externes. L'écosystème MCP s'est développé rapidement, mais la plupart des serveurs existants exposent des documents ou des APIs, pas la structure interne d'une base de code. GitNexus comble ce vide spécifique en s'appuyant sur Tree-sitter, le parseur incrémental développé à l'origine par GitHub, et sur la détection de communautés de Leiden pour regrouper les symboles par zones fonctionnelles cohérentes. La prochaine étape logique pour ce type d'outil est l'intégration dans les IDE et les pipelines CI, où une connaissance structurelle précise du code pourrait non seulement guider les agents en temps réel, mais aussi prévenir automatiquement les régressions avant qu'elles ne soient committées.

💬 C'est exactement le problème que je vis en ce moment avec Claude Code : l'agent touche une fonction, casse 5 trucs en aval, et toi tu passes l'heure suivante à réparer ce que l'outil aurait dû anticiper. GitNexus s'attaque à ça à la source, en pré-calculant tout le graphe de dépendances avant que l'agent commence à bricoler, et le tout tourne en local sans qu'une seule ligne de code parte ailleurs. 28 000 étoiles en quelques semaines, c'est pas du hasard.

OutilsOutil
1 source
Surveiller le comportement des LLM : dérives, nouvelles tentatives et patterns de refus
4VentureBeat AI 

Surveiller le comportement des LLM : dérives, nouvelles tentatives et patterns de refus

Les systèmes d'intelligence artificielle générative posent un défi fondamental aux équipes d'ingénierie : contrairement aux logiciels traditionnels, où une entrée A combinée à une fonction B produit toujours un résultat C, les modèles de langage sont stochastiques. Le même prompt peut retourner des réponses différentes d'un lundi à un mardi, rendant caducs les tests unitaires classiques. Pour répondre à ce problème, des équipes spécialisées dans le déploiement d'IA pour des clients Fortune 500 dans des secteurs à hauts risques, où une hallucination n'est pas anecdotique mais constitue un risque de conformité majeur, ont formalisé un cadre structuré : l'AI Evaluation Stack. Ce pipeline d'assertions remplace les simples "vibe checks" subjectifs par une infrastructure d'évaluation rigoureuse organisée en couches distinctes. La première couche repose sur des assertions déterministes, qui traitent en priorité les pannes les plus fréquentes en production : non pas les hallucinations sémantiques, mais les erreurs de syntaxe et de routage. Ces vérifications binaires posent des questions strictes, le modèle a-t-il généré le bon schéma JSON ? A-t-il invoqué le bon appel d'API avec les bons paramètres ? A-t-il correctement renseigné un identifiant GUID ou une adresse email ? Ce principe "fail-fast" est délibérément placé en amont pour éviter de déclencher des évaluations coûteuses sur des sorties déjà mal formées. La seconde couche intervient lorsque la syntaxe est validée : elle évalue la qualité sémantique via ce qu'on appelle le LLM-as-a-Judge, c'est-à-dire un modèle frontier (plus puissant que le modèle de production) chargé d'évaluer la nuance, la politesse ou le caractère actionnable d'une réponse, des dimensions qu'aucune regex ne peut capturer de façon fiable. Ce juge artificiel devient ainsi un proxy scalable de la relecture humaine, capable de traiter des dizaines de milliers de cas de test dans un pipeline CI/CD. Cette architecture répond à une maturité croissante du secteur face aux risques de dérive comportementale des LLMs en production. Dans les industries réglementées, finance, santé, juridique, un modèle qui dévie de ses instructions, refuse des requêtes légitimes ou produit des sorties mal structurées peut engendrer des conséquences opérationnelles et légales sérieuses. Les grandes entreprises technologiques et les startups d'observabilité IA, comme Braintrust, Langfuse ou Weights & Biases, investissent massivement dans ces outils d'évaluation. L'enjeu est de faire passer l'IA générative du statut de prototype impressionnant à celui de composant industriel fiable, soumis aux mêmes exigences de qualité que n'importe quel service critique en production.

UEL'AI Act européen impose une surveillance rigoureuse des systèmes IA à haut risque dans les secteurs réglementés (finance, santé, juridique), ce cadre d'évaluation structuré répond directement aux exigences de traçabilité et de conformité que devront démontrer les entreprises européennes déployant des LLMs en production.

OutilsOutil
1 source