Aller au contenu

LightRAG — RAG dual : knowledge graph + vecteurs

Resume

LightRAG (30K stars, MIT) est un système RAG qui combine extraction de graphe de connaissance et recherche vectorielle. Au lieu du RAG classique (chunk → embed → nearest neighbor), LightRAG extrait entités et relations des documents pour construire un KG persistent, puis au query-time combine traversée du graphe + similarité vectorielle. Multiple backends : PostgreSQL, Neo4j, MongoDB, Milvus, Chroma, OpenSearch. API REST Ollama-compatible. Web UI. L'extraction KG nécessite des LLMs >= 32B paramètres.

Analyse critique

Ce qui change par rapport au RAG classique :

Le RAG plat (FAISS) répond à la question "quels chunks sont sémantiquement proches de ma requête ?". Il ne peut pas répondre à "quels documents parlent d'un concept A en relation avec un concept B ?" parce qu'il n'y a pas de représentation des relations.

LightRAG répond aux deux. Exemple concret pour ProbatioVault : "quelles stories ont eu des problèmes avec la validation crypto qui dépendent de l'HSM ?" — un RAG plat retourne des chunks avec "HSM" et "validation crypto". Un KG peut suivre le lien story → a_eu_problème_avec → composant → dépend_de → HSM et retourner uniquement les stories où cette chaîne existe.

La citation automatique des sources (quel document a fourni quel fait) est le feature le plus utile pour un workflow de gouvernance où la traçabilité compte.

Ce qui est lourd :

L'extraction KG nécessite un LLM >= 32B. Sur IA-Server (2x RTX 5090), Llama 3.3 70B ou Qwen 35B sont disponibles — c'est utilisable mais coûteux en indexation initiale. La maintenance du graphe (ajout de documents) requiert de relancer l'extraction, pas juste un re-embed.

Comparaison avec l'existant :

Système Approche Query type Infra
FAISS actuel Vecteurs plats Similarité sémantique Léger
LightRAG KG + vecteurs Sémantique + relationnel LLM 32B+
OpenViking Hiérarchique Localité + sémantique Serveur Rust

Les trois approches sont complémentaires sur des dimensions différentes.

Pertinence ProbatioVault

Impact modéré — techniquement le plus intéressant de la veille du jour, actionabilité limitée à court terme.

Ce qui mapperait : data/learnings.jsonl + data/contracts.jsonl indexés en KG permettraient des requêtes relationnelles au step 0 : "quels learnings concernent des composants en relation avec X ?" plutôt que juste similarité sur le texte.

Frein actuel : L'indexation initiale est coûteuse (LLM 32B pour extraction). Les 30K+ stories et learnings actuels représentent une charge d'indexation non négligeable. À évaluer quand le volume de learnings justifie la complexité — probablement autour de 300+ learnings (actuellement ~80).

À surveiller : La RAG-Anything integration (multimodale) pour indexer les artefacts binaires (PDFs de preuve, documents d'audit). Pour un SAE, c'est un use case réel.