OpenKB : compiler des documents en wiki maintenu par LLM, sans base vectorielle

Le problème : la connaissance redécouverte à chaque requête

Le README pose le diagnostic sans détour : dans un RAG classique, chaque question relance une recherche et rien ne s'accumule. OpenKB part d'un principe inverse, attribué à un concept d'Andrej Karpathy cité dans le README. Les LLM génèrent des résumés, des pages de concepts et des renvois croisés, et cet ensemble se maintient tout seul. La connaissance se cumule au lieu d'être redérivée à chaque interrogation.

La cible est donc l'ingénieur ou le chercheur qui accumule des documents sur un domaine et veut une couche de synthèse persistante, pas un simple moteur de questions-réponses. Le README mentionne aussi une Skill Factory, qui distille des compétences d'agent redistribuables à partir du wiki. C'est un usage différent : produire un artefact portable, pas répondre à une question ponctuelle.

Deux étages : le wiki comme socle, les générateurs comme sortie

L'architecture décrite dans le README sépare nettement deux couches. En bas, la fondation wiki : les documents bruts passent par markitdown ou PageIndex, puis par une compilation LLM qui produit des pages Markdown reliées. En haut, les générateurs (query, chat, Skill Factory) consomment ce wiki pour produire une réponse, une conversation ou une compétence d'agent.

Le tableau du README distingue deux chemins selon la taille du document. Un document court est converti par markitdown en Markdown, les images sont extraites en ligne via pymupdf, et le LLM lit le texte intégral. Un PDF long, à partir de 20 pages selon le tableau, passe par PageIndex : un index arborescent avec résumés, et le LLM lit des arbres de document plutôt que le texte complet. Les images sont alors extraites par PageIndex. Le résultat est le même dans les deux cas, un résumé plus des concepts.

Ce seuil de 20 pages est une heuristique interne, pas un paramètre exposé dans le README. Il faut le garder en tête : la qualité de la retrieval sur un PDF de 19 pages et sur un PDF de 21 pages ne repose pas sur le même mécanisme.

Pas de base vectorielle, mais une dépendance externe assumée

Le sous-titre du projet annonce « No Vector DB ». La retrieval est décrite comme vectorless et reasoning-based, assurée par PageIndex, un projet distinct de la même organisation VectifyAI. Concrètement, le LLM ne compare pas des embeddings : il parcourt une arborescence de document et raisonne sur les titres et résumés de nœuds pour localiser l'information.

L'argument est cohérent avec le reste du projet : un wiki en Markdown se relit, se versionne et s'ouvre dans Obsidian, ce qu'un index vectoriel ne permet pas. Mais cette conception déplace la dépendance plutôt qu'elle ne la supprime. Toute la partie longue-document repose sur PageIndex, et le README ne dit rien du fonctionnement hors ligne de ce composant ni de son mode de distribution. Un lecteur qui cherche un système entièrement local doit le vérifier avant de s'engager, car le README ne le garantit pas.

Mise en route : init, add, query

L'installation tient en une commande : pip install openkb. Le README donne aussi deux variantes, pip install git+https://github.com/VectifyAI/OpenKB.git pour la version courante du dépôt, et une installation éditable depuis les sources avec git clone puis pip install -e .

Le démarrage suit cinq étapes. On crée un répertoire, on l'initialise avec openkb init, on ajoute des documents avec openkb add paper.pdf, openkb add ~/papers/ pour un répertoire entier, ou openkb add https://arxiv.org/pdf/2509.11420 pour une URL. On interroge ensuite avec openkb query "What are the main findings?" ou on ouvre une session avec openkb chat. Le README mentionne des sessions persistées, donc une conversation peut être reprise.

La configuration du modèle passe par openkb init ou par le fichier .openkb/config.yaml, au format provider/model de LiteLLM, par exemple anthropic/claude-sonnet-4-6. Les modèles OpenAI peuvent omettre le préfixe, comme gpt-5.4. La clé se place dans un fichier .env sous la variable LLM_API_KEY. Les fournisseurs par abonnement qui s'authentifient par OAuth device flow, cités sous la forme chatgpt/* et github_copilot/*, n'ont pas besoin de clé, et OpenKB saute l'avertissement correspondant. Le README ne détaille pas les autres clés de config.yaml, ce qui limite ce qu'on peut affirmer sur la configuration fine.

Interface web et sorties annexes

Une interface web est fournie, appelée Knowledge Workbench. Elle s'installe séparément avec pip install "openkb[web]" puis se lance avec openkb-web, qui sert l'API et l'interface sur http://127.0.0.1:7566/. Par défaut l'authentification est désactivée, position assumée local-first ; la variable OPENKB_API_TOKEN permet d'exiger un jeton bearer avant d'exposer le serveur. C'est le seul garde-fou mentionné, et il faut le poser avant toute exposition réseau.

D'autres commandes apparaissent dans le README : openkb skill new my-expert "..." pour produire une compétence d'agent, openkb visualize pour un graphe de connaissances interactif, et openkb deck new my-deck "..." pour un jeu de diapositives en HTML autonome. Le développement du front se fait avec cd frontend && npm install && npm run dev, le serveur Vite relayant /api vers un openkb-web en cours d'exécution, ou npm run build pour régénérer openkb/web/.

Le README annonce que les pages du wiki suivent la spécification Google OKF pour le partage de connaissances, et que des pages d'entités (personnes, organisations, lieux, produits) sont extraites automatiquement et maintenues synchronisées. Ce sont les deux évolutions récentes mises en avant.

Ce que le README ne dit pas

La compilation LLM est le cœur du produit, et c'est la partie la moins documentée. Le README ne décrit ni le nombre d'appels par document, ni le coût en jetons, ni le comportement quand deux documents se contredisent, alors que la page d'accueil affirme que les contradictions sont signalées. Comment, et sous quelle forme dans le wiki ? Aucun exemple de page compilée n'est fourni.

Autre angle mort : la mise à jour. Le README parle de wiki « gardé à jour » et d'entités « maintenues synchronisées », sans indiquer de commande de rafraîchissement ni de mécanisme de détection de changement. Si vous modifiez un PDF déjà ajouté, rien dans le matériel fourni ne précise ce qui se passe. Pour un outil dont l'argument principal est justement l'accumulation dans le temps, c'est une lacune réelle.

Le projet est par ailleurs très actif : la dernière version listée est v0.4.5, datée du 20 juillet 2026, précédée de v0.4.4 et d'une rc1 le 10 juillet. Un rythme de publication aussi serré sur une version 0.x signifie que l'API en ligne de commande et le format du wiki peuvent encore bouger. Traitez le format comme instable tant que la série 0.x continue.

Quand préférer un index vectoriel classique

L'alternative directe est un pipeline RAG conventionnel, par exemple LlamaIndex ou LangChain avec une base vectorielle. La différence n'est pas une question de qualité mais de modèle de données. Un index vectoriel stocke des plongements et retrouve des passages similaires à une requête ; il ne produit aucun artefact lisible, et deux requêtes proches ne partagent rien. OpenKB produit des fichiers .md liés entre eux, consultables dans Obsidian et versionnables dans git.

Cette différence a un coût. Un index vectoriel s'incrémente en ajoutant des vecteurs, opération peu coûteuse et bien outillée. OpenKB doit faire passer les documents par un LLM pour produire des pages, et le README ne chiffre pas ce coût. Sur un gros corpus, la compilation initiale peut donc être nettement plus lourde qu'une indexation vectorielle, sans que le matériel permette de quantifier l'écart.

Inversement, si votre besoin est la recherche de similarité à grande échelle sur des millions de passages, avec latence basse et budget maîtrisé, OpenKB n'est pas le bon outil. Il vise la profondeur sur un corpus que vous connaissez, pas le rappel massif sur un corpus ouvert.

Licence, maintenance et coût de mise à jour

OpenKB est publié sous Apache-2.0. Cette licence est permissive : usage commercial, modification et redistribution sont autorisés, avec conservation des mentions et de l'état des modifications. Elle inclut une concession de brevets. Rien dans le matériel fourni n'indique de clause additionnelle, mais je ne donne pas d'avis juridique : si la redistribution compte pour vous, faites relire les fichiers de licence du dépôt.

Un point mérite attention : la licence Apache-2.0 couvre OpenKB, pas PageIndex. Ce dernier est un projet distinct, et le README ne mentionne pas sa licence. Comme la retrieval sur documents longs en dépend entièrement, la licence de cette brique fait partie de l'évaluation, pas de la note de bas de page.

Côté maintenance, le rythme de publication observé, trois versions en une douzaine de jours autour de juillet 2026, suggère un projet en développement actif plutôt qu'un dépôt abandonné. Cela implique de suivre les versions de près si vous déployez en production. Le README signale aussi que LiteLLM est épinglé à une version qualifiée de sûre, avec un lien vers une note de sécurité de mars 2026 : c'est un choix délibéré, à conserver lors des mises à jour plutôt qu'à contourner pour obtenir une version plus récente.

Conclusion éditoriale

OpenKB convient à qui veut un wiki Markdown lisible, versionnable et interrogeable, plutôt qu'un index vectoriel opaque. Il ne convient pas si vous avez besoin d'un système mature, documenté en détail et sans dépendance forte à un service externe : la retrieval repose entièrement sur PageIndex, dont le comportement hors ligne n'est pas décrit dans le README. Avant d'adopter, vérifiez deux points concrets : le contenu réel de .openkb/config.yaml après openkb init (le README n'en montre que la clé de modèle) et la licence du paquet pageindex, distincte de l'Apache-2.0 d'OpenKB.

Sources officielles

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. VectifyAI/OpenKB on GitHub