Self-Hosting Cognee: Kiezen voor LLM op Ollama

Cognee testen met lokale LLMs - reële resultaten

Inhoud

Cognee is een Python-framework voor het bouwen van kennisgrafieken uit documenten met behulp van LLMs. Werkt het echter met zelfgehoste modellen?

Ik heb het getest met meerdere lokale LLMs om dat te ontdekken.

cognee verwerkt pdf met procelist

Dat is een prijslijst PDF-pagina die ik heb geprobeerd te verwerken.

TL;DR

Cognee werkt waarschijnlijk goed met slimme LLMs met honderden miljarden parameters, maar voor zelfgehoste RAG-opstellingen die verwacht worden om automatisch gegevens te extraheren uit PDFs (zoals prijslijsten), is het mislukt om te leveren op mijn hardware. De zware afhankelijkheid van gestructureerde uitvoer maakt het lastig voor kleinere lokale modellen om betrouwbaar te presteren.

Wat is Cognee?

Cognee is een open-source Python-framework dat is ontworpen om kennisgrafieken te bouwen uit ongestructureerde documenten met behulp van LLMs. In tegenstelling tot traditionele RAG-systemen die gewoon documenten in stukken verdelen en embedden, probeert Cognee een semantische begrip te creëren door entiteiten, relaties en concepten te extraheren naar een grafiekdatabase. Dit benadering komt overeen met geavanceerde RAG-architecturen zoals GraphRAG, die betere contextuele opvraging belooft.

Het framework ondersteunt meerdere backends:

  • Vector databases: LanceDB (standaard), met ondersteuning voor andere vectoropslag
  • Grafiekdatabases: Kuzu (standaard), waarmee complexe relatiequeries mogelijk zijn
  • LLM providers: OpenAI, Anthropic, Ollama en anderen
  • Gestructureerde uitvoer frameworks: BAML en Instructor voor beperkte generatie

Voor enthousiastelingen van zelfgehosting maakt Cognee’s compatibiliteit met Ollama het aantrekkelijk voor lokale implementaties. De duivel zit echter in de details - zoals we zullen zien, creëren de eisen voor gestructureerde uitvoer grote uitdagingen voor kleinere modellen.

Waarom Gestructureerde Uitvoer Belangrijk Is

Cognee steunt zwaar op gestructureerde uitvoer om informatie uit documenten op een consistente manier te extraheren. Bij het verwerken van een document moet de LLM een goed opgemaakte JSON retourneren die entiteiten, relaties en metadata bevat. Dit is waar veel kleinere modellen moeite mee hebben.

Als je werkt met gestructureerde uitvoer in je eigen projecten, is het begrijpen van deze beperkingen cruciaal. De problemen die ik met Cognee heb ondervonden, spiegelen brede uitdagingen in het LLM-ecosysteem weer wanneer je werkt met lokale modellen.

Configuratie-instellingen

Hieronder vind je mijn werkende configuratie voor Cognee met Ollama. Merk op de belangrijke instellingen die lokale bedrijfsvoering mogelijk maken:

TELEMETRY_DISABLED=1

# STRUCTURED_OUTPUT_FRAMEWORK="instructor"
STRUCTURED_OUTPUT_FRAMEWORK="BAML"  

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


# Embedding-configuratie
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-configuratie
BAML_LLM_PROVIDER="ollama"  
BAML_LLM_MODEL="gpt-oss:20b" 

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


# Database-instellingen (standaard)
DB_PROVIDER="sqlite"  
VECTOR_DB_PROVIDER="lancedb"  
GRAPH_DATABASE_PROVIDER="kuzu"

# Aanmelding
REQUIRE_AUTHENTICATION=False
ENABLE_BACKEND_ACCESS_CONTROL=False

Belangrijke Configuratiekeuzes

Gestructureerde Uitvoer Framework: Ik heb BAML getest, wat betere controle over uitvoerschema’s biedt in vergelijking met basisprompting. BAML is specifiek ontworpen voor gestructureerde LLM-uitvoer, waardoor het een natuurlijke keuze is voor taken van kennisgrafiekenextrahering.

LLM-provider: Het gebruik van Ollama’s OpenAI-compatibele API-eindpunt (/v1) stelt Cognee in staat om het te behandelen als een ander OpenAI-stijl service.

Embeddingmodel: Het SFR-Embedding-Mistral-model (4096 dimensies) biedt hoge kwaliteit embeddings. Voor meer informatie over de keuze en prestaties van embeddingmodellen, bieden de Qwen3-embeddingmodellen uitstekende alternatieven met sterke multilingualiteit.

Databases: SQLite voor metadata, LanceDB voor vectoren en Kuzu voor de kennisgrafiek houden alles lokaal zonder externe afhankelijkheden.

Cognee Installeren

De installatie is eenvoudig met uv (of pip). Ik raad aan uv te gebruiken voor snellere afhankelijkheidsoplossing:

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

De [ollama], [baml] en [instructor] extra’s installeren de benodigde afhankelijkheden voor lokale LLM-bewerking en gestructureerde uitvoer. De scraping extra voegt web-scraperfunctionaliteit toe, terwijl Playwright JavaScript-gerenderde paginaverwerking mogelijk maakt.

Voorbeeldcode en Gebruik

Hieronder vind je de basisworkflow voor het verwerken van documenten met Cognee. Eerst voegen we documenten toe en bouwen we de kennisgrafiek op:

msy-add.py:

import cognee
import asyncio

async def main():

    # Maak een lege plek voor Cognee aan - reset gegevens en systeemstatus
    await cognee.prune.prune_data()
    await cognee.prune.prune_system(metadata=True)
    
    # Voeg voorbeeldinhoud toe
    await cognee.add(
        "/home/rg/prj/prices/msy_parts_price_20251224.pdf",
        node_set=["price_list", "computer_parts", "2025-12-24", "aud"]
    )
    
    # Verwerk met LLMs om de kennisgrafiek op te bouwen
    await cognee.cognify()

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

Het node_set-parameter geeft semantische tags die helpen bij het categoriseren van het document in de kennisgrafiek. De cognify()-methode is waar de magie (of problemen) gebeurt - het stuurt documentstukken naar de LLM voor entiteiten- en relatiesextrahering.

msy-search.py:

import cognee
import asyncio

async def main():

    # Zoek in de kennisgrafiek
    results = await cognee.search(
        query_text="Welke producten staan in de prijslijst?"
#       query_text="Wat is de gemiddelde prijs voor 32GB RAM (2x16GB modules)?"
    )
    
    # Print
    for result in results:
        print(result)

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

In tegenstelling tot traditionele vectorzoekopdrachten in RAG-systemen, vraagt Cognee de kennisgrafiek, wat theoretisch meer geavanceerde relatiegebaseerde opvraging mogelijk maakt. Dit is vergelijkbaar met hoe geavanceerde RAG-architecturen werken, maar vereist dat de initiële grafiekconstructie succesvol is.

Testresultaten: LLMs-prestaties

Ik heb Cognee getest met een reële toepassing: het extraheren van productinformatie uit een computeronderdelen prijslijst PDF. Dit leek een ideaal scenario - gestructureerde data in een tabulaire vorm. Hier is wat er met elk model is gebeurd:

Geteste Modellen

1. gpt-oss:20b (20 miljard parameters)

  • Resultaat: Mislukt met tekencoderingsfouten
  • Probleem: Retourneerde ongeldige gestructureerde uitvoer met verkeerde tekencodes
  • Opmerking: Hoewel het specifiek is ontworpen voor open-source compatibiliteit, kon het geen consistente JSON-formaat behouden

2. qwen3:14b (14 miljard parameters)

  • Resultaat: Mislukt om gestructureerde uitvoer te produceren
  • Probleem: Model zou tekst genereren, maar niet in het vereiste JSON-schema
  • Opmerking: Qwen-modellen presteren meestal goed, maar deze taak overschreed hun gestructureerde uitvoer mogelijkheden

3. deepseek-r1:14b (14 miljard parameters)

  • Resultaat: Mislukt om gestructureerde uitvoer te produceren
  • Probleem: Gelijkaardig aan qwen3, kon niet voldoen aan de BAML-schema vereisten
  • Opmerking: De redeneerkracht hielp niet met format conformiteit

4. devstral:24b (24 miljard parameters)

  • Resultaat: Mislukt om gestructureerde uitvoer te produceren
  • Probleem: Zelfs met meer parameters, kon het niet consistent geldige JSON genereren
  • Opmerking: Gespecialiseerd code model had nog steeds moeite met strikte schema conformiteit

5. ministral-3:14b (14 miljard parameters)

  • Resultaat: Mislukt om gestructureerde uitvoer te produceren
  • Probleem: Mistral’s kleinere model kon de gestructureerde uitvoer eisen niet aanpakken

6. qwen3-vl:30b-a3b-instruct (30 miljard parameters)

  • Resultaat: Mislukt om gestructureerde uitvoer te produceren
  • Probleem: Visuele vaardigheden hielpen niet bij het extraheren van PDF-tabellen in dit geval

7. gpt-oss:120b (120 miljard parameters)

  • Resultaat: Verwerking is niet voltooid na 2+ uur
  • Hardware: Verbruikers GPU-setup
  • Probleem: Model was te groot voor praktische zelfgehoste gebruik, zelfs als het uiteindelijk zou werken

Belangrijke bevindingen

Stukgroottebeperking: Cognee gebruikt 4k tokenstukken bij het verwerken van documenten met Ollama. Voor complexe documenten of modellen met grotere contextvensters lijkt dit onnodig restrictief. Het framework biedt geen eenvoudige manier om dit parameter aan te passen.

Gestructureerde uitvoer vereisten: Het kernprobleem is niet model intelligentie, maar formaat conformiteit. Deze modellen kunnen de inhoud begrijpen, maar het behouden van consistente JSON-schema’s tijdens het extraheringsproces blijft lastig. Dit komt overeen met brede uitdagingen om lokale modellen te laten respecteren van uitvoerbeperkingen.

Hardwareoverwegingen: Zelfs wanneer een voldoende grote model zou werken (zoals gpt-oss:120b), maken de hardwarevereisten het onpraktisch voor de meeste zelfgehoste scenario’s. Je zou aanzienlijke GPU-geheugen en verwerkingsefficiëntie nodig hebben.

Vergelijking met Best Practices voor Gestructureerde Uitvoer

Deze ervaring versterkt lessen uit het werken met gestructureerde uitvoer bij verschillende LLM-providers. Commerciële APIs van OpenAI, Anthropic en Google hebben vaak ingebouwde mechanismen om uitvoerschema’s te dwingen, terwijl lokale modellen complexere aanpakken vereisen zoals grammabase sampling of meervoudige validatiepassen.

Voor een diepgaande analyse van het kiezen van het juiste LLM voor Cognee op Ollama, inclusief gedetailleerde vergelijkingen van verschillende modelgroottes en hun prestatiekenmerken, zijn er uitgebreide gidsen beschikbaar die je kunnen helpen een weloverwogen beslissing te nemen.

Alternatieve aanpakken voor zelfgehoste RAG

Als je vast bent op zelfgehosting en je moet gestructureerde data extraheren uit documenten, overweeg dan deze alternatieven:

1. Traditionele RAG met eenvoudiger extrahering

In plaats van een complexe kennisgrafiek op te bouwen, gebruik traditionele RAG met documentverdeling en vectorzoekopdrachten. Voor gestructureerde dataextrahering:

  • Pars tabellen direct met bibliotheken zoals pdfplumber of tabula-py
  • Gebruik eenvoudigere prompts die geen strikte schema conformiteit vereisen
  • Implementeer postverwerkingsvalidatie in Python in plaats van te vertrouwen op LLM-uitvoerformaat

2. Gespecialiseerde embeddingmodellen

De kwaliteit van je embeddings heeft een grote invloed op de zoekprestaties. Overweeg gebruik te maken van hoge prestaties embeddingmodellen die goed werken lokaal. Moderne embeddingmodellen zoals Qwen3’s aanbod bieden uitstekende multilinguale ondersteuning en kunnen je RAG-systeem nauwkeurigheid dramatisch verbeteren.

3. Herordenen voor betere resultaten

Zelfs met eenvoudigere RAG-architecturen kan het toevoegen van een herordeningsstap de resultaten aanzienlijk verbeteren. Na de initiële vectorzoekopdracht, kan een herordeningsmodel beter beoordelen van relevantie. Deze tweestapsaanpak heeft vaak betere prestaties dan complexere enkele-stapsystemen, vooral wanneer je werkt met beperkte hardware.

4. Hybride zoekstrategieën

Het combineren van vectorzoekopdrachten met traditionele trefwoordzoekopdrachten (BM25) levert vaak betere resultaten op dan elk van de twee afzonderlijk. Veel moderne vectoropslag bieden hybride zoekopdrachten standaard aan.

5. Overweeg alternatieven voor vectoropslag

Als je een RAG-systeem vanaf nul bouwt, beoordeel verschillende vectoropslag op basis van je behoeften. Opties variëren van lichte ingebouwde databases tot gedistribueerde systemen die zijn ontworpen voor productieschaal.

Docker-implementatieoverwegingen

Voor productie zelfgehosting vereenvoudigt het containeriseren van je RAG-opstelling implementatie en schaalbaarheid. Bij het uitvoeren van Cognee of vergelijkbare frameworks met Ollama:

# Voer Ollama uit in een container
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

# Trek je modellen op
docker exec -it ollama ollama pull gpt-oss:20b

# Configureer Cognee om te verbinden met het container-eindpunt

Zorg ervoor dat je GPU-passthrough en volume-aankoppelingen correct configureert voor modelduurzaamheid.

Lessen geleerd

1. Werktools aanpassen aan hardware: Cognee is ontworpen voor cloud-schaal LLMs. Als je zelfgehost bent op consumentenhardware, kunnen eenvoudigere architecturen praktischer zijn.

2. Gestructureerde uitvoer is lastig: Het behouden van consistente schema conformiteit van lokale LLMs blijft uitdagend. Als je toepassing kritisch afhankelijk is van gestructureerde uitvoer, gebruik dan commerciële APIs of implementeer robuuste validatie en herprobeerlogica.

3. Test vroeg: Voordat je je commiteert aan een framework, test het met je specifieke gebruikscase en hardware. Wat werkt in demo’s, werkt mogelijk niet op schaal of met je documenten.

4. Overweeg hybride aanpakken: Gebruik commerciële APIs voor complexe extraheringsopdrachten en lokale modellen voor eenvoudige vragen om kost en capaciteit te balanceren.

Gerelateerde lezing

Gestructureerde uitvoer met LLMs

Het begrijpen van gestructureerde uitvoer is cruciaal voor frameworks zoals Cognee. Deze artikelen gaan diep in op het krijgen van consistente, schema-compatibele antwoorden van LLMs:

RAG-architectuur en implementatie

Voor alternatieve of aanvullende aanpakken voor kennisextrahering en opvraging:

Embedding en herordenen

Verbetering van opvragingskwaliteit via betere embeddings en herordenen:

Tools en hulpbronnen

Externe bronnen