Le développeur a remplacé l'explication de contexte répétée du réseau de neurones par le flux de travail LLM Wiki

Un auteur de blog technique sur Habr a démontré un flux de travail LLM Wiki : au lieu de réexpliquer le contexte à un réseau de neurones à chaque demande, le modèle remplit progressivement et organise une base de connaissances dans le stockage Obsidian. Plusieurs articles de Habr lui-même ont été utilisés comme sources pour remplir la base, et le traitement des tâches a été construit sur Codex.

Sur Quoi le Flux de Travail Est Construit

Le système repose sur une combinaison de plusieurs outils et trois processus séquentiels que l'auteur a implémentés indépendamment en plus d'un vault existant dans Obsidian.

• Stockage des connaissances — vault dans Obsidian
• Traitement des demandes et génération — via Codex
• Sources pour remplir la base — plusieurs articles de Habr
• Trois processus de pipeline : ingest (chargement de matériaux), query (interrogation de la base), lint (vérification de la qualité)
• L'auteur a calculé le coût de l'ingest sur le modèle Yandex Foundation Models

Construire le flux de travail autour de exactement trois processus séparés — ingest, query et lint — permet à l'auteur de diviser les responsabilités : charger de nouveaux matériaux, accéder aux connaissances déjà accumulées et vérifier la qualité se font comme des étapes indépendantes, pas comme une seule opération monolithique.

Comment Cela Diffère du RAG Régulier

L'approche RAG classique, à chaque demande, recherche à nouveau des fragments pertinents dans une base de documents et les substitue dans le prompt — le modèle ne se souvient de rien entre les sessions, et le contexte doit être réassemblé de zéro à chaque fois. Dans LLM Wiki, le modèle, en revanche, complète et structure progressivement le vault : le résultat de chaque requête non seulement répond à l'utilisateur, mais s'ajoute également à la base de connaissances sous forme de couche wiki séparée qui peut être réutilisée dans les requêtes ultérieures sans réexpliquer le contexte.

L'auteur montre dans l'article la structure du vault elle-même et des exemples de ce à quoi ressemble cette couche wiki en pratique, comparant l'approche résultante avec RAG régulier en termes de commodité et de coût. Selon sa description, la différence clé n'est pas de où le modèle obtient les faits, mais ce qui arrive à la réponse après sa réception : dans le RAG classique, la réponse est perdue après la session, tandis que dans LLM Wiki, elle reste partie de la base pour les requêtes ultérieures.

Quels Risques l'Approche Présente-t-elle

L'auteur analyse séparément les risques qui se manifestent rapidement dans la pratique avec une telle approche — en particulier, la question du coût de l'ingest constant de nouveaux matériaux et la nécessité d'un processus lint séparé pour que la base de connaissances ne se dégrade pas et n'accumule pas d'entrées contradictoires à mesure qu'elle grandit.

L'auteur a calculé les coûts d'ingest non pas abstraitement, mais sur un modèle spécifique — Yandex Foundation Models — ce qui parle d'une tentative d'évaluer l'économie de l'approche en pratique, plutôt que de simplement décrire son architecture en théorie.

Ce Que Cela Signifie

Le flux de travail LLM Wiki offre une alternative au RAG traditionnel : au lieu de réassembler le contexte à partir de documents bruts à chaque fois, le modèle maintient une base de connaissances vivante et constamment mise à jour — cela peut réduire le nombre de jetons dépensés pour expliquer le contexte, mais nécessite un contrôle de qualité séparé via lint pour garder la base fiable.

Pour ceux qui travaillent avec LLM sur de gros volumes de questions répétitives — qu'il s'agisse d'une base de connaissances personnelle dans Obsidian ou de documentation d'entreprise — une telle approche montre un moyen pratique de réduire le coût de la répétition constante du même contexte dans les prompts.