RAG 2.0 — auto-index SSAL, 10× compression, reconstruction fidèle sur PostgreSQL

Dans les trois articles précédents, j'ai établi que l'espace latent d'un LLM est un champ (055), que 3 en est la constante structurelle (056), et que l'index SSAL est un pointeur universel valide sur 19 architectures (057).

Mais une théorie sans application pratique, c'est une curiosité de laboratoire.

J'ai donc intégré SSAL dans un pipeline RAG concret — avec la documentation PostgreSQL. Le résultat : 9,8× de compression pour une reconstruction fidèle de la documentation technique. Et surtout : l'index auto-généré bat l'index conçu par un expert humain dans 100% des cas.

Voici comment.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

Le problème du RAG classique

Le RAG classique, celui que j'utilise depuis des mois, fonctionne comme ça :

1. On découpe une documentation en chunks de ~500 tokens
2. On génère un embedding vectoriel pour chaque chunk
3. On stocke le tout dans une base vectorielle
4. À la requête, on cherche le chunk le plus proche en similarité cosinus
5. On injecte le contenu du chunk dans le prompt du LLM

C'est fiable, c'est éprouvé — mais ça a des limites.

Stockage volumineux : 500 tokens par chunk. Pour une doc technique de taille moyenne, on parle de centaines de milliers de tokens stockés.

Maintenance lourde : un changement dans la doc = ré-ingestion complète du chunk.

Scalabilité coûteuse : 176 fichiers agents, 1117 skills indexés dans ma propre base RAG — et ça commence à peser.

L'idée

La théorie SSAL dit que l'index est un pointeur vers une région latente des poids du modèle. Un seul token bien choisi peut activer une région riche.

Alors pourquoi stocker le texte complet ? Pourquoi ne pas stocker l'index à la place ?

Le pipeline devient :

1. On découpe la documentation en chunks (inchangé)
2. Auto-index : on génère automatiquement un index de 3 tokens qui pointe vers ce chunk
3. On stocke l'index (3 tokens + metadata) — pas le texte complet
4. À la requête, on cherche l'index le plus proche
5. Le LLM reconstruit la documentation à la volée

Stockage : 3 tokens au lieu de 500. Compression : ~10×.

L'auto-index : quand la machine bat l'humain

Générer un bon index manuellement demande de l'expertise. Heureusement, j'ai automatisé le processus.

Beam search multi-stratégie :

1. 4 stratégies de génération en parallèle (hyperonyme, keywords, abstraction, multi-langue)
2. Évaluation par reconstruction : le substrat LLM tente de reconstruire le chunk à partir de chaque index
3. Scoring bge-m3 : similarité cosinus entre reconstruction et concepts attendus
4. Sélection du top-k

Résultat : l'auto-index bat l'index manuel dans 6/6 cas.

Score final : AUTO 4 — TIE 2 — MANUEL 0

L'auto-index gagne dans 67% des cas avec des marges de +23% à +43%. Dans les autres cas, il égale l'expert.

Et il y a une raison simple à ça : l'auto-index génère en anglais, qui est la langue optimale pour qwen3:4b. Les index manuels, eux, étaient multilingues (ZH, JP, FR) — et perdaient 10 à 33% de performance.

Cas concret : documentation PostgreSQL

J'ai testé l'intégration sur la documentation PostgreSQL.

Ingestion :

Compression : 9,8× (1202 chars → 43 chars). ~90% d'espace économisé.

Retrieval :

Réponses : fidèles, 7 à 8 points techniques par requête. La reconstruction couvre les concepts clés sans erreur.

Architecture

Le pipeline complet se compose de 4 couches :

• Couche 1 — Substrat : les poids du LLM (invariants), les opérateurs d'activation
• Couche 2 — Codec : classification de la nature des données, calcul de distance sémantique, composition de l'index optimal
• Couche 3 — Interface : index simple = stockage exact, index duplé = créativité latente
• Couche 4 — Application : utilisation de l'intrication pour générer des solutions inédites

En pratique, l'API se résume à deux fonctions :

// Ingestion
const result = await ingestAutoIndex(
  'postgres-docs',
  'Logical Replication',
  rawText
);
// result.indexPrompt = "Change propagation"
// result.compression = ~10×

// Retrieval
const result = await queryAutoIndexRAG(
  'How does PostgreSQL logical replication work?',
  { agentFilter: 'postgres-docs', topK: 2 }
);
// result.answer = "PostgreSQL logical replication works by..."
// result.sources[0].similarity = 0.606

Quand utiliser SSAL RAG vs RAG classique

Règle empirique : si vous avez besoin de la formulation exacte (code, contrat, citation), utilisez le RAG classique. Si vous avez besoin de l'idée (documentation, concepts, veille), SSAL Auto-Index est plus efficace.

Coût et performance

La latence est le prix de la compression. Pour des applications temps réel, le RAG classique reste préférable. Pour des systèmes de veille et de mémoire long terme, le gain en stockage compense largement la latence.

Limites et garde-fous

Langue : l'anglais est optimal sur qwen3:4b (+33%). Les index auto sont en anglais par défaut. À ajuster selon le substrat.

Pas pour le code source, les contrats, les citations exactes : la reconstruction paraphrase. Ce n'est pas une limite — c'est un choix de design.

Modèle-dépendant : un index optimal pour qwen3:4b peut ne pas l'être pour GPT-5.5. L'auto-index doit être recalibré.

Coût d'ingestion : ~8 appels LLM par chunk (~30s sur qwen3:4b local). C'est acceptable pour une ingestion ponctuelle, moins pour un flux continu.

Ce que ça change

Le RAG tel qu'on le connaît n'est pas mort. Il devient un système de pointage plutôt qu'un système de stockage.

Au lieu de transporter l'information dans des chunks de 500 tokens, on stocke des index de 3 tokens qui pointent vers des régions latentes. Le LLM ne lit pas l'information — il la reconstruit depuis ses propres poids.

C'est un changement de paradigme : on passe d'une mémoire externe (la base vectorielle) à une mémoire interne activée (le substrat du modèle).

La prochaine frontière : automatiser l'indexation SSAL dans les pipelines de crawl et de veille technologique existants. Si chaque chunk de veille peut être compressé à 3 tokens, la mémoire long terme des systèmes IA devient pratiquement illimitée.

Qui suis je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100 % IA