RAG sur vos documents d’entreprise : faut-il une base vectorielle ?

Dans sa proposition LLM Wiki, Andrej Karpathy décrit des sources conservées séparément et un wiki Markdown entretenu par un agent. Les pages de synthèse sont reliées entre elles ; un index aide à les retrouver. Une partie des rapprochements entre documents est ainsi préparée avant la question suivante.

Les liens internes d’Obsidian, aussi appelés wikilinks, permettent de naviguer entre les notes. Obsidian sert à les consulter ; les liens seuls ne lisent pas les documents et ne vérifient pas les affirmations. Il faut définir qui prépare les notes, qui accepte les corrections et comment revenir aux sources.

Avec une navigation par index et une recherche textuelle, on peut commencer sans calculer de représentation vectorielle de chaque passage ni exploiter une base vectorielle dédiée. On conserve la lecture des sources, la préparation des notes, les droits d’accès et les contrôles des réponses. Ce choix déplace le travail ; il ne le rend pas gratuit.

Le travail de recherche à l’origine du RAG décrit une génération appuyée sur la récupération de passages. Au sens large, un agent qui cherche dans un wiki avant de répondre reste dans cette logique. La distinction utile ici est donc « wiki et recherche textuelle » ou « recherche vectorielle », plutôt que « vrai » ou « faux » RAG.

Prenez la page des tarifs et la FAQ de l’accueil. Notez leur date de consultation. Préparez une fiche « abonnement » avec les références des passages utilisés, puis reliez-la à une fiche « responsabilités ».

Posez cette question : « L’entretien de l’agent comprend-il la relecture des messages destinés aux clients ? » La réponse attendue doit distinguer l’exploitation du service de la relecture des messages, qui reste à la charge du client. Une réponse sans passage justificatif doit être revue, même si sa conclusion est correcte.

Ajoutez ensuite : « Quel délai contractuel de rétablissement est garanti ? » Dans ce dossier de test, aucun délai contractuel chiffré ne doit être déduit des explications sur la surveillance. L’absence de preuve doit rester explicite. Vérifiez les pages sources à nouveau si l’offre évolue.

Je testerais d’abord le wiki seul lorsque les sujets sont récurrents, les notes peuvent rester relisibles et le vocabulaire est assez stable. Si les recherches échouent sur des formulations différentes, si trop de sources restent hors des notes ou si les mises à jour dépassent la capacité de contrôle, il faut comparer un autre dispositif.

QMD propose une recherche locale par mots, vectorielle et hybride. Activer ses modes vectoriels réintroduit des modèles et des index à entretenir. Le wiki et le moteur de recherche peuvent donc se compléter : le premier organise les synthèses, le second aide à retrouver les passages.

Pour décider, comparez les deux variantes sur les mêmes questions, y compris les questions sans réponse. Le test d’un dossier partagé détaille ces contrôles. Aucun seuil universel de nombre de documents ne remplace cet essai.

Le budget comprend la préparation initiale, les appels au modèle, les mises à jour des notes et leur relecture. Un wiki peu consulté mais constamment réécrit peut coûter davantage qu’une recherche directe. L’article sur le coût d’un agent IA fournit une grille pour comparer ces postes.

L’entretien de la mémoire compris dans TARS couvre les liens entre notes, la qualité de ce qui s’y écrit et l’accompagnement des mises à jour du système. Il ne comprend pas le retrait ou la datation systématique des informations périmées. Le propriétaire des documents doit identifier les changements de règle à faire vérifier.

Un wiki peut aussi recopier une donnée confidentielle dans une synthèse. Les droits de la source doivent être respectés dans les notes dérivées. Des fichiers locaux ne garantissent pas que les passages restent sur la machine : le modèle cloud utilisé pour répondre reçoit le contenu qui lui est transmis. Le choix d’un modèle local et du matériel se cadre séparément.