Avec le workflow LLM Wiki, un développeur n'a plus à réexpliquer le contexte à son IA

Sur Habr, l'auteur d'un blog technique présente le workflow LLM Wiki. Au lieu de réexpliquer le contexte au réseau de neurones à chaque requête, le modèle enrichit et organise progressivement une base de connaissances stockée dans un vault Obsidian. Plusieurs articles de Habr ont servi de sources pour l'alimenter, et le traitement des tâches repose sur Codex.

De quoi se compose le workflow

Le système associe plusieurs outils et trois processus successifs, que l'auteur a implémentés lui-même par-dessus un vault Obsidian existant.

• Stockage des connaissances : un vault Obsidian
• Traitement des requêtes et génération : via Codex
• Sources pour alimenter la base : plusieurs articles de Habr
• Trois processus dans le pipeline : ingest (chargement des contenus), query (interrogation de la base), lint (contrôle qualité)
• Coût de l'ingest : calculé par l'auteur sur le modèle Yandex Foundation Models

En articulant le workflow autour de trois processus distincts (ingest, query et lint), l'auteur sépare les responsabilités. Le chargement de nouveaux contenus, l'interrogation des connaissances déjà accumulées et le contrôle de leur qualité constituent des étapes autonomes, et non une opération monolithique unique.

En quoi cela diffère d'un RAG classique

Une approche RAG classique recherche à chaque requête les fragments pertinents dans une base documentaire et les injecte dans le prompt. Le modèle ne retient rien d'une session à l'autre, et il faut reconstruire le contexte de zéro à chaque fois. Avec LLM Wiki, le modèle complète et structure au contraire le vault de façon incrémentale : le résultat de chaque requête répond à l'utilisateur, mais vient aussi s'ajouter à la base de connaissances sous la forme d'une couche wiki distincte. Celle-ci peut être réutilisée lors des requêtes suivantes sans réexpliquer le contexte.

Dans son article, l'auteur montre la structure même du vault et des exemples concrets de cette couche wiki. Il compare l'approche obtenue à un RAG classique, en termes de praticité comme de coût. Selon lui, la différence clé ne tient pas à l'origine des faits utilisés par le modèle, mais au sort de la réponse une fois obtenue : avec un RAG classique, elle se perd à la fin de la session ; avec LLM Wiki, elle reste dans la base pour les requêtes ultérieures.

Quels risques présente l'approche

L'auteur examine à part les risques qui apparaissent vite en pratique avec cette approche. Il cite notamment le coût d'un ingest permanent de nouveaux contenus et la nécessité d'un processus lint dédié, pour éviter que la base de connaissances ne se dégrade et n'accumule des entrées contradictoires à mesure qu'elle grossit.

L'auteur n'a pas évalué le coût de l'ingest dans l'abstrait, mais explicitement sur un modèle précis, Yandex Foundation Models. Signe qu'il cherche à mesurer l'économie réelle de l'approche, et pas seulement à en décrire l'architecture en théorie.

Ce que cela signifie

Le workflow LLM Wiki offre une alternative au RAG traditionnel. Plutôt que de reconstruire à chaque fois le contexte à partir de documents bruts, le modèle entretient une base de connaissances vivante, mise à jour en continu. Cela peut réduire le nombre de tokens consacrés à l'explication du contexte, mais impose un contrôle qualité dédié via lint pour que la base reste fiable.

Pour ceux qui utilisent des LLM sur de grands volumes de questions récurrentes, qu'il s'agisse d'une base de connaissances personnelle dans Obsidian ou d'une documentation d'entreprise, cette approche montre une voie concrète pour réduire le coût lié à la répétition permanente du même contexte dans les prompts.