Auto-hébergement de Cognee : choisir un LLM sur Ollama

Test de Cognee avec des LLM locaux - résultats réels

Sommaire

Cognee est un framework Python permettant de construire des graphes de connaissances à partir de documents en utilisant des LLM. Mais fonctionne-t-il avec des modèles auto-hébergés ?

J’ai testé avec plusieurs LLM locaux pour le découvrir.

cognee processing pdf with procelist

C’est une page de liste de prix PDF que j’ai essayé de traiter.

TL;DR

Cognee fonctionne probablement bien avec des LLMs intelligents dotés de centaines de milliards de paramètres, mais pour les configurations RAG auto-hébergées prévues pour extraire automatiquement des données à partir de PDF (comme des listes de prix), il a échoué sur mon matériel. Le framework dépend fortement des sorties structurées, ce qui rend difficile l’utilisation fiable par les petits modèles locaux.

Qu’est-ce que Cognee ?

Cognee est un framework open source en Python conçu pour construire des graphes de connaissances à partir de documents non structurés à l’aide de LLM. Contrairement aux systèmes RAG traditionnels qui ne segmentent et ne plongent simplement les documents, Cognee tente de créer une compréhension sémantique en extrayant des entités, des relations et des concepts dans une base de données graphique. Cette approche s’aligne avec des architectures RAG avancées comme GraphRAG, qui promet une récupération contextuelle améliorée.

Le framework prend en charge plusieurs backends :

  • Bases de données vectorielles : LanceDB (par défaut), avec un support pour d’autres magasins vectoriels
  • Bases de données graphiques : Kuzu (par défaut), permettant des requêtes complexes sur les relations
  • Fournisseurs de LLM : OpenAI, Anthropic, Ollama, et d’autres
  • Frameworks de sortie structurée : BAML et Instructor pour la génération contrainte

Pour les passionnés d’auto-hébergement, la compatibilité de Cognee avec Ollama la rend attrayante pour les déploiements locaux. Cependant, le diable est dans les détails - comme nous allons le voir, les exigences de sortie structurée créent des défis significatifs pour les petits modèles.

Pourquoi la sortie structurée compte

Cognee dépend fortement de la sortie structurée pour extraire des informations à partir de documents dans un format cohérent. Lors du traitement d’un document, le LLM doit renvoyer un JSON correctement formaté contenant des entités, des relations et des métadonnées. C’est là que beaucoup de petits modèles ont du mal.

Si vous travaillez avec une sortie structurée dans vos propres projets, comprendre ces contraintes est crucial. Les défis que j’ai rencontrés avec Cognee reflètent des problèmes plus larges dans l’écosystème des LLM lorsqu’on travaille avec des modèles locaux.

Configuration

Voici ma configuration de travail pour Cognee avec Ollama. Notez les paramètres clés qui permettent le fonctionnement local :

TELEMETRY_DISABLED=1

# STRUCTURED_OUTPUT_FRAMEWORK="instructor"
STRUCTURED_OUTPUT_FRAMEWORK="BAML"  

# Configuration du LLM 
LLM_API_KEY="ollama"  
LLM_MODEL="gpt-oss:20b"
LLM_PROVIDER="ollama"  
LLM_ENDPOINT="http://localhost:11434/v1"
# LLM_MAX_TOKENS="25000"


# Configuration d'embedding
EMBEDDING_PROVIDER="ollama"  
EMBEDDING_MODEL="avr/sfr-embedding-mistral:latest"  
EMBEDDING_ENDPOINT="http://localhost:11434/api/embeddings"  
EMBEDDING_DIMENSIONS=4096  
HUGGINGFACE_TOKENIZER="Salesforce/SFR-Embedding-Mistral"  

# Configuration BAML
BAML_LLM_PROVIDER="ollama"  
BAML_LLM_MODEL="gpt-oss:20b" 

BAML_LLM_ENDPOINT="http://localhost:1144/v1"


# Paramètres de base de données (par défaut)
DB_PROVIDER="sqlite"  
VECTOR_DB_PROVIDER="lancedb"  
GRAPH_DATABASE_PROVIDER="kuzu"

# Authentification
REQUIRE_AUTHENTICATION=False
ENABLE_BACKEND_ACCESS_CONTROL=False

Choix clés de configuration

Framework de sortie structurée : J’ai testé BAML, qui offre un meilleur contrôle sur les schémas de sortie par rapport à la simple incitation. BAML est conçu spécifiquement pour les sorties structurées des LLM, ce qui en fait une correspondance naturelle pour les tâches d’extraction de graphes de connaissances.

Fournisseur de LLM : L’utilisation de l’API compatible OpenAI d’Ollama (/v1) permet à Cognee de le traiter comme tout autre service OpenAI.

Modèle d’embedding : Le modèle SFR-Embedding-Mistral (4096 dimensions) fournit des embeddings de haute qualité. Pour plus d’informations sur le choix et les performances des modèles d’embedding, les modèles Qwen3 d’embedding offrent d’excellentes alternatives avec des capacités multilingues fortes.

Bases de données : SQLite pour les métadonnées, LanceDB pour les vecteurs, et Kuzu pour le graphe de connaissances permettent de garder tout local sans dépendances externes.

Installer Cognee

L’installation est simple en utilisant uv (ou pip). Je recommande d’utiliser uv pour une résolution plus rapide des dépendances :

uv venv && source .venv/bin/activate
uv pip install cognee[ollama]
uv pip install cognee[baml]
uv pip install cognee[instructor]

uv sync --extra scraping
uv run playwright install
sudo apt-get install libavif16

Les extra [ollama], [baml] et [instructor] installent les dépendances nécessaires pour le fonctionnement local des LLM et la sortie structurée. L’extra de scraping ajoute des capacités de scraping web, tandis que Playwright permet le traitement des pages rendues en JavaScript.

Exemple de code et d’utilisation

Voici le workflow de base pour traiter des documents avec Cognee. Tout d’abord, nous ajoutons des documents et construisons le graphe de connaissances :

msy-add.py :

import cognee
import asyncio

async def main():

    # Créer un espace vierge pour cognee -- réinitialiser les données et l'état du système
    await cognee.prune.prune_data()
    await cognee.prune.prune_system(metadata=True)
    
    # Ajouter du contenu d'exemple
    await cognee.add(
        "/home/rg/prj/prices/msy_parts_price_20251224.pdf",
        node_set=["price_list", "computer_parts", "2025-12-24", "aud"]
    )
    
    # Processer avec les LLM pour construire le graphe de connaissances
    await cognee.cognify()

if __name__ == '__main__':
    asyncio.run(main())

Le paramètre node_set fournit des balises sémantiques qui aident à catégoriser le document dans le graphe de connaissances. La méthode cognify() est là où le miracle (ou les problèmes) se produisent - elle envoie des morceaux de document aux LLM pour l’extraction d’entités et de relations.

msy-search.py :

import cognee
import asyncio

async def main():

    # Rechercher dans le graphe de connaissances
    results = await cognee.search(
        query_text="Quels sont les produits dans la liste de prix ?"
#       query_text="Quel est le prix moyen pour 32 Go de RAM (2x16 Go modules) ?"
    )
    
    # Imprimer
    for result in results:
        print(result)

if __name__ == '__main__':
    asyncio.run(main())

Contrairement à la recherche vectorielle traditionnelle dans les systèmes RAG, Cognee interroge le graphe de connaissances, théoriquement permettant une récupération plus sophistiquée basée sur les relations. Cela ressemble à la façon dont les architectures RAG avancées fonctionnent, mais nécessite que la construction initiale du graphe réussisse.

Résultats des tests : performance des LLM

J’ai testé Cognee avec un cas d’utilisation réel : l’extraction d’informations de produit à partir d’un PDF de liste de prix de pièces informatiques. Cela semblait être un scénario idéal - des données structurées sous forme de tableau. Voici ce qui s’est produit avec chaque modèle :

Modèles testés

1. gpt-oss:20b (20 milliards de paramètres)

  • Résultat : Échec avec des erreurs de codage des caractères
  • Problème : A renvoyé une sortie structurée malformée avec des codes de caractères incorrects
  • Note : Malgré avoir été conçu spécifiquement pour la compatibilité open source, il n’a pas réussi à maintenir un format JSON cohérent

2. qwen3:14b (14 milliards de paramètres)

  • Résultat : Échec de la production de sortie structurée
  • Problème : Le modèle générerait du texte mais pas dans le schéma JSON requis
  • Note : Les modèles Qwen performent généralement bien, mais cette tâche dépassait ses capacités de sortie structurée

3. deepseek-r1:14b (14 milliards de paramètres)

  • Résultat : Échec de la production de sortie structurée
  • Problème : Similaire à qwen3, n’a pas réussi à respecter les exigences du schéma BAML
  • Note : Les capacités de raisonnement n’ont pas aidé à respecter le format

4. devstral:24b (24 milliards de paramètres)

  • Résultat : Échec de la production de sortie structurée
  • Problème : Même avec plus de paramètres, n’a pas réussi à générer de manière cohérente du JSON valide
  • Note : Modèle spécialisé en codage a tout de même eu du mal à respecter le schéma strict

5. ministral-3:14b (14 milliards de paramètres)

  • Résultat : Échec de la production de sortie structurée
  • Problème : Le modèle plus petit de Mistral n’a pas réussi à gérer les exigences de sortie structurée

6. qwen3-vl:30b-a3b-instruct (30 milliards de paramètres)

  • Résultat : Échec de la production de sortie structurée
  • Problème : Les capacités visuelles n’ont pas aidé à l’extraction de tableaux PDF dans ce contexte

7. gpt-oss:120b (120 milliards de paramètres)

  • Résultat : N’a pas terminé le traitement après plus de 2 heures
  • Matériel : Configuration de GPU grand public
  • Problème : Le modèle était trop grand pour une utilisation pratique auto-hébergée, même s’il aurait pu fonctionner finalement

Principaux résultats

Limitation de la taille des morceaux : Cognee utilise des morceaux de 4k tokens lors du traitement des documents avec Ollama. Pour des documents complexes ou des modèles avec des fenêtres de contexte plus grandes, cela semble inutilement restrictif. Le framework ne fournit pas de moyen facile pour ajuster ce paramètre.

Exigences de sortie structurée : Le problème principal n’est pas l’intelligence du modèle mais le respect du format. Ces modèles peuvent comprendre le contenu, mais maintenir un schéma JSON cohérent tout au long du processus d’extraction prouve être difficile. Cela correspond aux défis plus larges de faire respecter les contraintes de sortie par les modèles locaux.

Considérations matérielles : Même si un modèle suffisamment grand pourrait fonctionner (comme gpt-oss:120b), les exigences matérielles rendent cela impraticable pour la plupart des scénarios d’auto-hébergement. Vous auriez besoin d’une mémoire GPU importante et d’une puissance de traitement considérable.

Comparaison avec les meilleures pratiques de sortie structurée

Cette expérience renforce les leçons apprises lors de la travail avec la sortie structurée auprès de différents fournisseurs de LLM. Les API commerciales d’OpenAI, Anthropic et Google disposent souvent de mécanismes intégrés pour imposer les schémas de sortie, tandis que les modèles locaux nécessitent des approches plus sophistiquées comme l’échantillonnage basé sur la grammaire ou plusieurs passes de validation.

Pour une analyse approfondie de choisir le bon LLM pour Cognee sur Ollama, y compris des comparaisons détaillées des différentes tailles de modèles et leurs caractéristiques de performance, des guides complets sont disponibles pour vous aider à prendre une décision éclairée.

Approches alternatives pour RAG auto-hébergé

Si vous êtes déterminé à vous auto-héberger et que vous avez besoin d’extraire des données structurées à partir de documents, envisagez ces alternatives :

1. RAG traditionnel avec une extraction plus simple

Au lieu de construire un graphe de connaissances complexe dès le début, utilisez un RAG traditionnel avec segmentation de documents et recherche vectorielle. Pour l’extraction de données structurées :

  • Parsez les tableaux directement en utilisant des bibliothèques comme pdfplumber ou tabula-py
  • Utilisez des prompts plus simples qui ne nécessitent pas de respect strict des schémas
  • Implémentez une validation post-traitement en Python plutôt que de compter sur le format de sortie du LLM

2. Modèles d’embedding spécialisés

La qualité de vos embeddings a un impact significatif sur les performances de récupération. Envisagez d’utiliser des modèles d’embedding performants qui fonctionnent bien localement. Les modèles d’embedding modernes comme ceux proposés par Qwen3 offrent un excellent support multilingue et peuvent considérablement améliorer la précision de votre système RAG.

3. Réordonnancement pour de meilleurs résultats

Même avec des architectures RAG plus simples, l’ajout d’une étape de réordonnancement peut considérablement améliorer les résultats. Après la récupération initiale par recherche vectorielle, un modèle de réordonnancement peut mieux évaluer la pertinence. Cette approche à deux étapes dépasse souvent les systèmes plus complexes à une seule étape, surtout lorsqu’on travaille avec un matériel limité.

4. Stratégies de recherche hybrides

Combiner la recherche vectorielle avec la recherche traditionnelle par mots-clés (BM25) donne souvent de meilleurs résultats que l’une ou l’autre seule. Beaucoup de bases de données vectorielles modernes prennent en charge la recherche hybride dès le départ.

5. Considérez des alternatives aux bases de données vectorielles

Si vous construisez un système RAG à partir de zéro, évaluez différentes bases de données vectorielles selon vos besoins. Les options varient de bases de données embarquées légères à des systèmes distribués conçus pour l’échelle de production.

Considérations sur le déploiement en conteneurs

Pour le déploiement en production auto-hébergé, le conteneurisation de votre configuration RAG simplifie le déploiement et l’échelle. Lors de l’exécution de Cognee ou de cadres similaires avec Ollama :

# Exécuter Ollama dans un conteneur
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

# Tirer vos modèles
docker exec -it ollama ollama pull gpt-oss:20b

# Configurer Cognee pour se connecter à l'extrémité du conteneur

Assurez-vous de configurer correctement le passage de GPU et les montages de volumes pour la persistance des modèles.

Leçons apprises

1. Adaptez les outils à l’équipement : Cognee est conçu pour les LLM à l’échelle cloud. Si vous vous auto-hébergez sur un matériel de consommation, des architectures plus simples peuvent être plus pratiques.

2. La sortie structurée est difficile : Obtenir une conformité cohérente des schémas à partir des LLM locaux reste un défi. Si votre application dépend crucialement de la sortie structurée, utilisez soit des API commerciales, soit implémentez une logique de validation et de réessai robuste.

3. Testez tôt : Avant de vous engager dans un framework, testez-le avec votre cas d’utilisation spécifique et votre matériel. Ce qui fonctionne dans les démos peut ne pas fonctionner à grande échelle ou avec vos documents.

4. Envisagez des approches hybrides : Utilisez des API commerciales pour les tâches d’extraction complexes et des modèles locaux pour les requêtes plus simples afin de trouver un équilibre entre coût et capacité.

Lectures recommandées

Sortie structurée avec des LLM

Comprendre la sortie structurée est crucial pour des cadres comme Cognee. Ces articles plongent profondément dans l’obtention de réponses cohérentes et conformes aux schémas à partir des LLM :

Architecture et mise en œuvre RAG

Pour des approches alternatives ou complémentaires à l’extraction de connaissances et à la récupération :

Embedding et Réordonnancement

Améliorer la qualité de la récupération grâce à de meilleurs embeddings et réordonnancement :

Outils et ressources

Ressources externes