Auto-hébergement de Cognee : Tests de performance des LLM

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

Sommaire

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

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

cognee processing pdf with procelist

Il s’agit d’une page PDF de liste de prix que j’ai tenté de traiter.

TL;DR

Cognee fonctionne probablement bien avec des LLMs intelligents ayant des centaines de milliards de paramètres, mais pour les configurations RAG auto-hébergées censées extraire automatiquement des données de PDF (comme des listes de prix), il a échoué sur mon matériel. La dépendance lourde du framework à la sortie structurée rend difficile la performance fiable des petits modèles locaux.

Qu’est-ce que Cognee ?

Cognee est un framework Python open-source conçu pour construire des graphes de connaissances à partir de documents non structurés en utilisant des LLMs. Contrairement aux systèmes RAG traditionnels qui se contentent de découper et d’embarquer des 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 sur les architectures RAG avancées comme GraphRAG, qui promet une meilleure récupération contextuelle.

Le framework prend en charge plusieurs backends :

  • Bases de données vectorielles : LanceDB (par défaut), avec prise en charge 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 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 en fait une option attrayante pour les déploiements locaux. Cependant, le diable se cache dans les détails - comme nous le verrons, les exigences de sortie structurée posent des défis significatifs pour les petits modèles.

Pourquoi la sortie structurée est importante

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

Si vous travaillez avec des sorties structurées 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 LLMs lorsqu’on travaille avec des modèles locaux.

Configuration de la 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"

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

# Embedding Configuration
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"

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

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

# Database Settings (defaults)
DB_PROVIDER="sqlite"
VECTOR_DB_PROVIDER="lancedb"
GRAPH_DATABASE_PROVIDER="kuzu"

# Auth
REQUIRE_AUTHENTICATION=False
ENABLE_BACKEND_ACCESS_CONTROL=False

Choix de configuration clés

Framework de sortie structurée : J’ai testé BAML, qui offre un meilleur contrôle sur les schémas de sortie par rapport à l’invitation de base. BAML est conçu spécifiquement pour les sorties structurées des LLMs, ce qui en fait un choix naturel pour les tâches d’extraction de graphes de connaissances.

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

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

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

Installer Cognee

L’installation est simple avec 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 extras [ollama], [baml] et [instructor] installent les dépendances nécessaires pour le fonctionnement local des LLMs et la sortie structurée. L’extra 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 flux de travail de base pour traiter des documents avec Cognee. D’abord, nous ajoutons des documents et construisons le graphe de connaissances :

msy-add.py :

import cognee
import asyncio

async def main():

    # Créer une ardoise propre 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"]
    )

    # Traiter avec les LLMs 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ù la magie (ou les problèmes) se produit - elle envoie des morceaux de document au 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 produits figurent dans la liste de prix ?"
#       query_text="Quel est le prix moyen pour 32GB de RAM (2x16GB 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, permettant théoriquement 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 LLMs

J’ai testé Cognee avec un cas d’utilisation du monde réel : l’extraction d’informations sur les produits à 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 dans un format tabulaire. Voici ce qui s’est passé avec chaque modèle :

Modèles testés

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

  • Résultat : Échec avec des erreurs d’encodage de caractères
  • Problème : A retourné une sortie structurée malformée avec des codes de caractères incorrects
  • Note : Malgré sa conception spécifique pour la compatibilité open-source, il n’a pas pu maintenir un formatage 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érait du texte mais pas dans le schéma JSON requis
  • Note : Les modèles Qwen fonctionnent 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, ne pouvait pas respecter les exigences du schéma BAML
  • Note : Les capacités de raisonnement n’ont pas aidé à la conformité de 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, ne pouvait pas générer de JSON valide de manière cohérente
  • Note : Modèle spécialisé en codage toujours en difficulté avec l’adhérence stricte au schéma

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

  • Résultat : Échec de la production de sortie structurée
  • Problème : Le petit modèle de Mistral ne pouvait pas 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 de vision 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 2+ heures
  • Matériel : Configuration GPU grand public
  • Problème : Le modèle était trop grand pour une utilisation auto-hébergée pratique, même s’il aurait pu fonctionner éventuellement

Principales conclusions

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

Exigences de sortie structurée : Le problème central n’est pas l’intelligence du modèle mais la conformité de format. Ces modèles peuvent comprendre le contenu, mais maintenir un schéma JSON cohérent tout au long du processus d’extraction s’avère difficile. Cela s’aligne sur les défis plus larges pour obtenir des modèles locaux afin de respecter les contraintes de sortie.

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

Comparaison avec les meilleures pratiques de sortie structurée

Cette expérience renforce les leçons tirées du travail avec des sorties structurées à travers différents fournisseurs de LLMs. Les API commerciales d’OpenAI, d’Anthropic et de Google ont souvent des mécanismes intégrés pour appliquer des 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 plus approfondie de choix du bon LLM pour Cognee sur Ollama, y compris des comparaisons détaillées de différentes tailles de modèles et de leurs caractéristiques de performance, il existe des guides complets disponibles qui peuvent vous aider à prendre une décision éclairée.

Approches Alternatives pour le RAG Auto-Hébergé

Si vous êtes déterminé à auto-héberger et avez besoin d’extraire des données structurées à partir de documents, voici quelques alternatives à considérer :

1. RAG Traditionnel avec Extraction Simplifiée

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

  • Analysez directement les tableaux à l’aide de bibliothèques comme pdfplumber ou tabula-py
  • Utilisez des invites plus simples qui n’exigent pas une adhérence stricte à un schéma
  • Mettez en œuvre une validation de post-traitement en Python plutôt que de compter sur le format de sortie de l’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 les offres de Qwen3 offrent un excellent support multilingue et peuvent considérablement améliorer la précision de votre système RAG.

3. Reranking pour de Meilleurs Résultats

Même avec des architectures RAG plus simples, l’ajout d’une étape de reranking peut considérablement améliorer les résultats. Après la récupération initiale par recherche vectorielle, un modèle de reranking peut mieux évaluer la pertinence. Cette approche en deux étapes surpasse souvent les systèmes plus complexes en une seule étape, surtout lorsque vous travaillez avec des matériels contraints.

4. Stratégies de Recherche Hybride

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

5. Considérez les Alternatives de Stockage Vectoriel

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

Considérations de Déploiement Docker

Pour l’auto-hébergement en production, la conteneurisation de votre configuration RAG simplifie le déploiement et la mise à 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

# Télécharger vos modèles
docker exec -it ollama ollama pull gpt-oss:20b

# Configurer Cognee pour se connecter au point de terminaison 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. Adapter les Outils au Matériel : Cognee est conçu pour des LLMs à l’échelle du cloud. Si vous auto-hébergez sur du matériel grand public, des architectures plus simples peuvent être plus pratiques.

2. La Sortie Structurée est Difficile : Obtenir une conformité de schéma cohérente à partir de LLMs locaux reste un défi. Si votre application dépend critique de la sortie structurée, utilisez soit des API commerciales, soit mettez en œuvre une validation et une logique de réessai robustes.

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

4. Envisagez les Approches Hybrides : Utilisez des API commerciales pour les tâches d’extraction complexes et des modèles locaux pour des requêtes plus simples afin d’équilibrer coût et capacité.

Lectures Associées

Sortie Structurée avec les LLMs

Comprendre la sortie structurée est crucial pour des cadres comme Cognee. Ces articles explorent en profondeur l’obtention de réponses cohérentes et conformes à un schéma à partir des LLMs :

Architecture et Mise en Œuvre RAG

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

Embedding et Reranking

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

Outils et Ressources

Ressources Externes