Claude Code + LightRAG : Obsidian peut vraiment scaler ?

Mon volt obsidiane va-t-il frapper un mur ? C'est la question que je me suis posée sur hypothèse et c'est aussi une question qui m'est revenue. C'est bien avec le volt qui grossit au fur et à mesure du temps, est-ce que ça va pas se mettre à bouffer du token ?

Ça fait maintenant plusieurs semaines que j'utilise mon volt obsidiane quotidiennement avec cloud code. On voit de plus en plus de connexion qui se lie. Je suis tout à fait conquis avec cette méthodologie d'Obsidian et ce contexte, on va dire, qui va être persistant entre chaque session, je trouve ça génial. J'ai d'ailleurs bien respecté la méthodologie Carpati pour faire mon volt obsidian qui, je trouve, est une super solution. D'ailleurs, j'en ai fait une vidéo, elle sera en description.

Donc là, ça marche mais je dois avoir tout au plus une centaine de notes. Je pense que j'en ai 50 environ. Mais qu'est-ce qui va se passer quand tu as 500, 1000 notes dans ton volt ? Est-ce qu'on va pas frapper un plafond de verre ? Est-ce que justement on va pas arriver à un stade où même si c'est indexé ou pour peu qu'il y a d'indexation, bah Claude Code va passer plus de temps à mouliner pour chercher les informations et bouffer énormément de tokens parce que ce serait pas là le plafond de verre d'Obsidian à accumuler les notes. Chercher par mot ou par lien, telle est la question.

Typiquement, si on a un Volt qui sature, on peut se dire "Bon bah OK, je vais faire un rag." L'idée derrière la base vectorielle est intéressante, mais on va pas se mentir, un rag dans les fesses, ça reste ni plus ni moins qu'un espèce de contrôle F amélioré. C'est-à-dire que on va prendre les documents, on va les décuper en partie, on va les indexer et quand on va faire une recherche, on va rechercher à partir de la base vectorielle le "ça ressemble à". C'est bien pour des questions simples, mais quand il s'agit de questions compliquées ou à mesure que le RAC grossit, et ben en fait, on se retrouve face au même problème qu'un Volt. C'est-à-dire que ça va bouffer du token justement pour chercher la bonne information similaire avec la plus grosse probabilité de cohérence et de corrélation. Un rag c'est bien oui, mais seulement pour des questions simples. Dès qu'il s'agit de questions complexes, c'est là où on se perd et ça bouffe du token.

Ben dans ce cas, pourquoi pas ajouter des liens dans le rag et donc faire une base de données contextuelle, faire un graph rag. Bien comment ça marche ? Bien on va aller chercher un lien entre plusieurs documents pour ajouter du contexte. C'est une base de données contextuelle. Ça va traverser des connexions. Les projets sont liés comment ? Et ça va te donner une réponse. La base de données contextuelle où ça répond à la question du "ça rassemble à" parce que le LM va rechercher à quoi ça ressemble et le pourquoi. C'est top, mais c'est bien pour des questions qui sont complexes. Pour une question simple, c'est un peu overkill et donc pourquoi pas rassembler les deux pour profiter du meilleur des deux mondes. Et c'est la solution qui est proposée par Light Rag.

Light Rag fait les deux en parallèle. Et là, on va faire une mise en situation. Tu as justement ton volt obsidienne qui sature. Tu aimerais, on va dire, scaler ton volt et passer justement à l'rag parce que tu es convaincu de cette solution. Comment ça va se passer ? Et bien, dans un premier temps, tu vas évidemment exporter tes notes obsidian et les injecter dans le light rag. Le light rag, qu'est-ce qu'il va faire ? Il va faire deux procédures en parallèle sur tes documents. Il va prendre ton document brut, il va le découper en vecteur pour faire la base vectorielle. En plus, sur ce même document brut, il va aller chercher, détecter, décortiquer les entités et les relations entre les différents documents. Et ça, ça va constituer le knowledge graph, un lastar d'obsidienne. Et comme ça, à la fin, tu auras quatre types de requêtes intelligentes. Selon ton type de requête, il y aura quatre façons de rechercher détecté par rag. Ce sera soit de la manière naïve donc par le rag classique, soit de manière locale pour suivre les liens directs de ta requête, soit de manière globale, donc là on va plus utiliser la base contextuelle ou alors même une manière hybride, c'est-à-dire combiner le meilleur des trois mondes. Tu l'auras compris, l'hragoteur de recherche avec la carte mentale pour que dans une seule solution, tu puisses faire des requêtes simples tout comme faire des requêtes complexes pour que tu puisses combiner base de données vectorielles avec base de données contextuelles.

Maintenant, on va installer ça. On va tester ça, voir ce que ça donne. Bon, j'ai encore un petit volt, donc à voir ce que ça va donner et on tirera une conclusion. Passons à l'installation de Light Rag. Les instructions sont ici. Alors, tu as plusieurs manières d'installer Light Rag, soit via le package manager de Python, soit directement via la source avec Make, donc ce serait fait avec du C, il me semble. Peut-être que je dis des bêtises là-dessus, mais ça m'a l'air d'être la plus compliquée. Soit pour moi la plus simple, c'est via Docker Compose. Donc tu l'auras compris, ici euh je vais te montrer l'installation avec Docker Compose, ce qui demande d'avoir Docker d'installer sur ta machine avec Docker Desktop. Je te conseille de faire la même chose parce que c'est la solution la plus simple en fait à mettre en place à mon goût. Donc ensuite ce qu'on va faire c'est qu'on va simplement suivre les instructions pour installer le serveur Light Rag avec le dogur compose. Je clone premièrement le ripo de Light Rag. Ça a été cloné. Ensuite, ben je fais un site de la track pour me rediriger à la racine du dossier. Voilà. Et là maintenant, il me demande de copier et de mettre en place les variables d'environnement. Logique.

Alors, ne sois pas intimidé par la modification des variables d'environnement. Dans la documentation, il est mentionné qu'il faut mettre à jour la variable d'environnement avec les configurations LLM et unbeding. Honnêtement, je trouve mal foutu la documentation, mais ce que ça veut dire littéralement, ça veut dire changer au minimum quatre lignes. Ces deux variables là pour le LLM Binding host, le LLM binding IP en fait c'est quel va être l'hôte de la PII que tu vas utiliser et quelle va être ta clé API du LLM que tu vas utiliser. Typiquement, si tu utilises Open Router, bah tu vas remplacer ce lien là par l'API d'Open router/V1. Ou alors si tu veux encore moins te prendre la tête, tu te crées une clé API sur la plateforme Open API et c'est tout. Donc tu as ces deux variables là à changer pour la partie LLM et tu as ces deux variables là à changer pour la partie embeding. Ce sont exactement les mêmes. Tout dépend de l'hôte que tu utilises et de la clé API que tu as à mettre. C'est tout.

Une fois que tu as mis tes variables d'environnement en place, il y a plus qu'à faire docker compose up. Normalement tout est bien configuré. Il y a plus qu'à appuyer sur enter et le conteneur va s'initialiser. Bon, au départ, ça va prendre un petit peu de temps, c'est normal, ça va aller récupérer les images de l'rag pour créer les conteneurs de cœur. Et euh une fois que tout ça sera opérationnel, on pourra voir au local ce que ça va donner. Et si après le docker compose up, tu vois ce genre d'information, donc la configuration serveur, la configuration du dossier qui en soit une espèce de volt en fait maintenant qui va être différent de celui d'Obsidian, la configuration LM, l'embedding et cetera, c'est que c'est bon. Et si tu cliques sur le web UI local, l'URL ici et que tu tombes sur cette page là, tu es opérationnel pour utiliser Lightrag. Lightrag d'installer. Voilà, maintenant c'est vide, hein. Donc on va l'enrichir. Et pour ça, bah je vais prendre mon volt et je vais le plader en fait dans Lightrag. Et tout ça au travers de Cloud code. Et si tu demandes comment on va pouvoir utiliser Cloud code pour manipuler le track, bah c'est très simple he on va simplement utiliser la PI. Là, on voit bien que Lightrag nous propose toute une documentation API, hein. Donc c'est un swagger qui regroupe tous les endables et à quoi ils servent. Et bien on va utiliser cela avec Cloud code. Et pour ça, j'ai ouvert une nouvelle session cloud code. Je vais lui coller le contexte de Lightrag et je vais lui dire de s'incorporer la documentation de Lightrag. Voilà. Donc j'ai bien le lien localhost. Je souhaite utiliser et tester Lightrag. Commence par te documenter sur son utilisation via la documentation API accessible via le lien ci-dessus. C'est parfait. Code code a fetch tout le contexte, toute la documentation API de Light RAG. Il a même carrément récupéré la config utilisée sur ce rag en question. Et bien maintenant, on va juste upload de V et l'interroger. J'ai lancé un petit prompt simple parce que lui-même a reconnu que Light rag la base actuelle était vide. Donc je vais simplement réitérer. La base est actuellement vide. Dans l'idée, j'aimerais injecter mon volt obsidian dans l'rag et tester des queries dessus, analyser des nuages de points et cetera. Est-ce que tu me suis ? Oui, parfaitement le plan. Et puis là, il me met le plan. Donc injecter, tester les queries rag, explorer le edge grave généré. Et là, il est lui-même en train de me mentionner les avantages de Light Rag. C'est que le truc intéressant avec Lightrag, c'est qu'il va construire un graphe de connaissance à partir des notes, pas juste du vector search BS. Donc on pourra voir comment il relie les concepts entre eux, quel cluster émerge et si les queries multip fonctionnent bien. Alors queries multi-hop, je ne sais pas du tout ce que ça veut dire. J'imagine que c'est de l'ingénierie contextuelle qu'a derrière. Je vais me renseigner là-dessus. Il m'affiche le tableau. Donc le wiki avec 72 fichiers, l'euro avec 11 fichiers. Il y a 16 Mo de de de contenu déjà total dans le volt et il me recommande directement de commencer par injecter wiki. C'est la couche compilée, celle qui a plus de valeur sémantique et on pourra rajouter l'euro et le reste. Je suis d'accord. On part sur wiki d'abord et c'est là toute la différence entre un rag des naïfs et un rac de connaissance. Un rag naïf va le juste chercher de la sémantique. Un contrôle Un rag naïf va juste chercher de la sémantique hein. Donc un contrôle F, on va dire amélioré. Tiens, je recherche cette information. Ça ressemble Ah bah je te sors ça là avec le graphe et rag, on est vraiment dans la base de données contextuelle. Ça ne va pas juste classer les notes et les vectoriser et faire du contrôle F. Ça va prendre les notes, ça va les lire, ça va itérer dessus, ça va en extraire les concepts et les liens entre eux. Et puis ça va aussi créer des clusters. Donc tuer des catégories selon les notes qui peuvent être similaires ou qui peuvent appartenir à une même catégorie. Donc la recherche de la base de données contextuelle est quand même une fin beaucoup plus poussée que la vectorisation avec les les rag naïfs. Grosso modo, je me suis vite fait renseigner sur les queries multihop. Les courriels multihop, en fait, ce sont des queries contextuelles, j'ai l'impression. C'est-à-dire que ça va chercher l'information plus le contexte autour et ça va chercher des liaisons entre justement les informations. Ah bah, apparemment ma clé API n'a pas été configurée. Je pensais l'avoir mise donc peut-être une erreur de ma part. Je je vais voir ça. OK, en ton prompt. En fait, c'est encore plus stupide que ça. J'avais bien mis les clés API mais j'avais simplement oublié de sauvegarder le fichier. J'oublie toujours de sauvegarder le fichier. Bref, on réessaye. Voilà. Donc réessaye l'injection du volt comme décidé. C'est bon, ça passe sans processing. Claude code me dit que l'indexation de 72 documents prend un moment. Bon ben voilà, ça prend un petit moment et je reviens vers toi dès que c'est fini. Très bien.

J'ai 62 documents qui ont été bien complétés. Donc indexés via plus knowledge graphé entre guillemets. Alors faut que tu sois patient, faut que tu sois patient surtout si tu fais la transition de Obsy Lightrag, ça met beaucoup de temps à se faire, c'est normal, ça décortique tous les documents, c'est les index, ça va chercher les liaisons et normalement OK, je je vais rafraîchir. OK et voilà un petit peu les monstres de liaison qu'il peut avoir ne serait-ce qu'avec en fait 60 documents quoi. Et il y a plusieurs liaisons qui sont possibles. Tu as cl code, cl code cl.md, l'atelier. Il y a plein de liaisons de partout. Je pense quand même qu'il y a une certaine courbe de progression à avoir là-dessus parce que vraiment il m'a fait toutes les liaisons. En fait, il m'a fait plein de sections. Il a détecté énormément de sections. Ouais, c'est quand même énorme. C'est quand même assez énorme. Ah en fait non, ça ah c'est juste les nœuds en fait. Pardon. Ça va refaire des recherches des nœuds et ça c'est les nœuds principaux qui a détecté. Et ça tout ça c'est tout le knowledge graphe qui a autour et c'est assez énorme surtout autour de Claude Code, tu m'étonnes. C'est c'est le sujet principal. Il y a énormément de choses mais moi je suis perdu. Comme je le dis hein, je pense qu'il y a une certaine quand même marge d'apprentissage à avoir en utilisant ce genre de d'outil. Donc c'est pas à prendre à la légère, donc à réfléchir avant de faire la transition quand même bien connaître le truc et bien le paramétrer. Mais voilà, en tout cas voilà, tout a été bien processé puis euh c'est sûr qu'après il a dû avoir 10 fois plus de liaison ici déjà que sur l'obsidian quoi. Donc il y a vraiment énormément de contextuel qui est chargé. B je passe un petit peu temps, un petit peu à découvrir tout ça. Là je peux faire une query aussi depuis light track simplement depuis Cloud code via la API. Justement, on a la documentation API ici. Donc voilà. Donc ce qu'il faut comprendre, c'est que tu as une section de documents qui permet de charger les documents et de voir un petit peu l'état des documents uploadés. C'est la gestion document. Tu as le knowledge graphe qui est le monstre, le mastodonte on va dire de ce fameux light rag ici où tu as vraiment un recherche un tri par node en fait. Tu as une section retrieval. Ça c'est pour la query donc qui va aller rechercher dans le le knowledge graph. Et tu as la PI. Bon la documentation pour la PI. Très bien.

De retour sur mon terminal Cloud code, j'ai trois questions pour tester trois modes différents. Le mode local, le mode le global, le mode mix. Première question au local, qu'est-ce que le framework dev et comment il fonctionne ? Assez précis là, ce que je juste une réponse justement sur un document à quoi il ressemble. Donc là, c'est du mode rag essentiellement qui va être utilisé. J'exécute la query là. Ici, CL code va directement faire une query à partir de la documentation vers la PI. Et maintenant, bah là ça va mouliner un petit peu parce qu'il y a un autre modèle derrière justement qui va tourner pour chercher la réponse. Ça pour l'instant c'est un défaut je trouve, c'est que pour l'instant alors je viens juste de l'installer, je suis un peu en mode découverte, il y a certainement moyen de pouvoir directement fusionner Cloud code avec euh Light Rack pour pouvoir utiliser directement le Celite Cloud Code pour faire des requests sur Lightrag. Mais là, en tout cas, sur l'installation, on va dire simple, là il y a deux modèles qui tournent. un modèle cloud code pour aller faire la requête, un modèle ici je crois que c'est Openia modèle chat GPT justement qui va aller chercher les réponses dans le graphe voilà après on part sur une solution scaling ça veut dire qu'on a énormément de texte énormément de document donc en même temps un deuxième modèle pour faire de la recherche uniquement pour ça serait peut-être pertinent dans ce genre de contexte mais overkill dans le cas où je suis certainement bon ben c'est bien en plus j'ai mon cloud qui sait que je suis en mode démo donc il me dit résultat impeccable en mode local a trouvé l'entité framework dans le graphe et a remonté toute sa structure trois phases define execute vérifie 12 sources référencées, la source principale les temps. Voilà, bref avec des connexions vers les bonnes pratiques et cetera. OK, le mode local a bien fait ce job. Il est parti d'une framework dans le knowledge. J'ai suivi le relation direct pour suivre une réponse détaillée. Oui, ça c'est le mode local donc c'est pas du tout un mode R, c'est un mode va chercher les liaisons scopées courtes à partir d'un point précis.

OK, maintenant on va bouffer un peu plus de token. Peut-être pas, mais on va aller copier la deuxième question pour aussi chercher le mode global. Donc là, ça va faire vraiment la recherche contextuelle. Quels sont les principaux projets en cours et comment ils se relient entre eux ? Voilà, bim. Et là, on va faire un mode global là-dessus. Voilà la réponse. Il a pris la hauteur sur tout le graphe identifier six projets avec leur synergie. La cartographie, les liens pipeline alimente le site et YouTube scrapper. OK. 17 sources croisées depuis ses objectifs stratégiques jusqu'au débrief c'est exactement la force du mode global. Il ne cherche pas une entité précise. Il analyse les communautés et patterns à travers tout le knowledge graphe. OK, pourquoi pas ? Difficile de voir pour l'instant la rajouter dans le sens où je peut-être un volt qui est encore trop petit. C'est c'est pour ça. On passe à la dernière query et là on passe en mode mix, c'est-à-dire question précise mélangée avec une question globale. Quel est le profil du client idéal et quel contenu au stratégie sont en place pour l'atteindre ? Voilà, hop, on envoie la question et on voit ce que ça donne. Dernière question, il a tout croisé, ICP, stratégie croisée, 15 sources qui ont été filtrées de partout, c'est la force du mode mix. Bah effectivement, il a su combiner les recherches précises avec des recherches croisées contextuelles. Ça fait son boulot encore une fois et je pense que tu es d'accord avec moi. Pour l'instant, c'est rien de ce que ne peut pas faire un Volt mais encore une fois je me répète parce que mon volt est encore petit et donc voilà, c'était au moins pour tester pour être sûr que ça marche. Bon résultat ça marche. Donc voilà un petit peu pour ce setup et ce test de light rag. Je peux pas en tirer de grandes conclusions pour l'instant malheureusement parce que même pour moi c'est c'est une petite découverte. Ce que je peux noter pour l'instant, c'est que oui, ce qu'il faut prendre en compte, c'est qu'il faut mettre peut-être un deuxième modèle ajouté pour la recherche. Après, pour tout ce qui est recherche, hein, ça marche bien. Tu as du contexte, le knowledge graphe fonctionne super bien et le RAC fonctionne super bien. Donc je sens que c'est une bonne solution hein, mais qu'il faut exploiter et euh est-ce que j'exploiterai ça maintenant, vu que mon volt il est pour l'instant euh largement viable. En fait, c'est c'est une solution à tenir compte pour ceux qui ont déjà un volt qui est énorme et qui vaut peut-être une solution beaucoup plus scalable avec le Light track simplement. J'ai testé avec trois de mes questions où je connais déjà les réponses en plus et tout était pertinent, tout était super honnête. C'est vrai c'est vrai que les réponses aux questions étaient extrêmement propres et précises ça je dois le dire quand même. Donc c'est de très très c'est ça a l'air d'être super efficace là-dessus. Donc solution à considérer s'il y a besoin de s'il y a l'habilité, faut avoir le temps devant soi quand même, avoir le temps de de transférer tous ces fichiers pour en faire tout ce knowledge graph là. Mais ça peut être très intéressant de continuer à chercher là-dessus, à creuser là-dessus puis voir un petit peu comment aussi mieux synergiser entre cloud code et light track. Peut-être même synergiser entre cl, Obsidian, Light rag. Voilà. Mais en coup, en tout cas, c'est une solution comme une autre. Bah, dis-moi ce que tu en penses. Dis-moi ce que tu en penses de de ça. Est-ce que tu as d'autres solutions ? Est-ce que tu as d'autres projets aussi que tu avais en tête qui était intéressant ? Euh voilà, écoute euh bah sur ce, si tu es resté jusque là, c'est super, génial. Quoi qu'il en soit, si tu es intéressé par mes vidéos sur Obsidian, euh bah toutes les vidéos, toutes les ressources seront en description et je te dis à la prochaine.