Kwipu

Questions posées à un dossier de notes, réponses citées

Kwipu indexe un dossier de documents .md, .txt, .pdf ou .docx sous forme de graphe de propriétés, puis répond aux questions en langage naturel en citant les passages d'origine. Le graphe croise deux sources de relations : celles déjà écrites dans les notes, par les wikilinks et le frontmatter YAML, et celles qu'un LLM extrait du texte. Le projet vise d'abord les coffres Obsidian, mais n'importe quel dossier convient, et les fichiers sources sont lus sans jamais être réécrits. La recherche se fait au moment de la question, là où LLM Wiki compile les documents en un wiki Markdown tenu à jour.

Wikilinks résolus, provenance à la ligne et recherche hybride

• Un lien désigne une note, pas une chaîne : [[Bob]], [[Bob#Role]], [[People/Bob]], [[Bob|B.]] et l'entrée aliases: d'une note renommée aboutissent au même nœud. Deux notes homonymes dans des dossiers différents reçoivent un nom qualifié par leur chemin (People/Alice, Archive/Alice).
• Relations nommées par le texte qui précède le lien : les mots placés avant un wikilink donnent le type de relation ; à défaut, la relation reste une simple association, libellée dans la langue de la ligne. Les motifs couvrent le français, l'anglais, l'italien, l'allemand, l'espagnol et le portugais. Chaque relation structurelle retient son origine, son fichier, son champ de frontmatter, sa ligne et une empreinte du contenu de la note.
• Recherche hybride : similarité vectorielle, BM25 et métadonnées temporelles, plus un retriever de synonymes par LLM que le mode --fast, le serveur MCP et le bridge laissent de côté.
• Un index, trois accès : une CLI interactive qui surveille le dossier, une API JSON FastAPI qui alimente un graphe 3D dans le navigateur, et un serveur MCP en stdio qui expose query_graph et query_graph_detailed, le second avec ses citations.
• Source rouverte sans LLM : l'endpoint /expand relit le document derrière un nœud cité, texte des PDF et DOCX compris, sans nouvel appel au modèle.
• Mises à jour atomiques : l'écriture passe par une génération de staging publiée par échange de répertoire, et le bridge comme le serveur MCP chargent d'eux-mêmes la nouvelle révision avant de répondre.

Modèle cloud par défaut et index reconstruit à chaque modification

Le LLM par défaut tourne dans le cloud. La description GitHub du dépôt annonce un moteur « fully local », « No cloud », mais le modèle par défaut, gpt-oss:20b-cloud, peut transmettre à son fournisseur des extraits de documents, le contexte retrouvé et les questions, même quand Ollama répond sur localhost. Le README le signale en tête et demande de choisir avant le premier indexage, avec qwen2.5:7b comme exemple local ; les embeddings (nomic-embed-text) restent locaux dans les deux cas.

Toute modification de note reconstruit l'index entier. Seuls les nouveaux fichiers s'insèrent de façon incrémentale : une modification ou une suppression déclenche une reconstruction complète, tout comme l'enregistrement atomique d'un éditeur, qui peut apparaître comme une suppression suivie d'une création. Changer de modèle d'embedding impose un nouvel index.

L'API web n'a ni authentification ni limite de débit. Sa configuration par défaut est volontairement locale, limitée à localhost et au serveur Vite. Pour la production, la documentation du bridge demande de garder Uvicorn sur une interface privée, derrière un reverse proxy TLS authentifié. Une session web fait tourner quatre processus (Ollama, l'indexeur, le bridge et Vite), alors que le terminal seul se contente de Python 3.12 et d'Ollama.

Aucune release ni tag : l'installation passe par un git clone ou une archive ZIP du dépôt. Ouvert le 21 avril 2026, le dépôt compte 46 commits, dont 41 de son auteur. Aucun commit de juin à août, puis 22 en octobre, le dernier le 22 octobre 2026. Ni le README ni le site ne donnent de statut de maturité. Le dépôt inclut une suite de tests unittest.