Self-hosting Cognee: LLM-prestatietests

Cognee testen met lokale LLMs - echte resultaten

Inhoud

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

Ik heb het getest met meerdere lokale LLMs om dit 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 uit PDFs te extraheren (zoals prijslijsten), is het mislukt 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 alleen documenten in stukjes en embedden, probeert Cognee een semantische begrip te creëren door entiteiten, relaties en concepten te extraheren in een graf database. Dit benadering komt overeen met geavanceerde RAG-architecturen zoals GraphRAG, die belooft betere contextuele opvraging te bieden.

Het framework ondersteunt meerdere backends:

  • Vector databases: LanceDB (standaard), met ondersteuning voor andere vectoropslag
  • Graf databases: 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 die zelf hosten, maakt Cognees 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 aanzienlijke 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 correct opgemaakte JSON teruggeven met entiteiten, relaties en metadata. 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 uitdagingen die ik met Cognee ondervond, spiegelen brede problemen in de LLM-ecosysteem weer wanneer je werkt met lokale modellen.

Configuratie-instellingen

Hieronder staat mijn werkende configuratie voor Cognee met Ollama. Let op de belangrijke instellingen die lokale werking 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"

# Authenticatie
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 basisprompten. 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 als een andere OpenAI-stijl service te behandelen.

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

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

Cognee Installeren

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

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 webkrabbelcapaciteiten toe, terwijl Playwright JavaScript-gerenderde paginaverwerking mogelijk maakt.

Voorbeeldcode en Gebruik

Hieronder staat het basiswerkflow voor het verwerken van documenten met Cognee. Eerst voegen we documenten toe en bouwen we het kennisgrafiek op:

msy-add.py:

import cognee
import asyncio

async def main():

    # Maak een lege start voor cognee -- 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 het kennisgrafiek op te bouwen
    await cognee.cognify()

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

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

msy-search.py:

import cognee
import asyncio

async def main():

    # Zoek in het kennisgrafiek
    results = await cognee.search(
        query_text="Welke producten bevinden zich 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 het kennisgrafiek, wat theoretisch complexere relatiegebaseerde opvraging mogelijk maakt. Dit is vergelijkbaar met hoe geavanceerde RAG-architecturen werken, maar vereist dat de initiële grafiekconstructie succesvol is.

Testresultaten: LLM-prestaties

Ik heb Cognee getest met een echte 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: Gaf vervormde gestructureerde uitvoer met onjuiste tekencodes
  • Opmerking: Hoewel het specifiek is ontworpen voor open-source compatibiliteit, kon het consistent 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 uitvoercapaciteiten

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

  • Resultaat: Mislukt om gestructureerde uitvoer te produceren
  • Probleem: Gelijkaardig aan qwen3, kon de BAML-schema-eisen niet naleven
  • Opmerking: De redeneercapaciteiten hielpen niet met formaatcompliancy

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 codemodel had nog steeds moeite met strikte schema naleving

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

  • Resultaat: Mislukt om gestructureerde uitvoer te produceren
  • Probleem: Kleinere Mistral-model kon de gestructureerde uitvoereisen niet aan

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

  • Resultaat: Mislukt om gestructureerde uitvoer te produceren
  • Probleem: Visuele capaciteiten hielpen niet met PDF-tabel extrahering in deze context

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

Belangrijkste bevindingen

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

Eisen voor gestructureerde uitvoer: Het kernprobleem is niet model intelligentie, maar formaatcompliancy. Deze modellen kunnen de inhoud begrijpen, maar het behouden van consistente JSON-schema’s tijdens de extraheringsproces blijft lastig. Dit komt overeen met bredere uitdagingen in het krijgen van lokale modellen om uitvoerbeperkingen te respecteren.

Hardwareoverwegingen: Zelfs als 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 verwerkingskracht nodig hebben.

Vergelijking met Beste Praktijken voor Gestructureerde Uitvoer

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

Voor een dieper analyse van het kiezen van de 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 benaderingen voor zelfgehoste RAG

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

1. Traditionele RAG met eenvoudige extrahering

In plaats van een complex kennisgrafiek op te bouwen, gebruik traditionele RAG met documentstukjes en vectorzoekopdrachten. Voor gestructureerde data extrahering:

  • Parse tabellen direct met bibliotheken zoals pdfplumber of tabula-py
  • Gebruik eenvoudigere prompts die geen strikte schema naleving vereisen
  • Implementeer post-verwerking validatie in Python in plaats van te vertrouwen op LLM-uitvoerformaat

2. Gespecialiseerde embeddingmodellen

De kwaliteit van je embeddings heeft een grote invloed op zoekprestaties. Overweeg gebruik te maken van hoge prestaties embeddingmodellen die goed werken lokaal. Moderne embeddingmodellen zoals Qwen3 bieden uitstekende multitaalondersteuning en kunnen je RAG-systeem nauwkeurigheid aanzienlijk verbeteren.

3. Herordenen voor betere resultaten

Zelfs met eenvoudigere RAG-architecturen kan het toevoegen van een herordentingsstap aanzienlijk resultaten verbeteren. Na de initiële vectorzoekopdracht, kan een herordentingsmodel beter beoordelen van relevantie. Deze tweestapsaanpak werkt vaak beter dan complexere enkele stapsystemen, vooral bij beperkte hardware.

4. Hybride zoekstrategieën

Het combineren van vectorzoekopdrachten met traditionele trefwoordzoekopdrachten (BM25) levert vaak betere resultaten dan alleen een van de twee. Veel moderne vectoropslagbibliotheken ondersteunen hybride zoekopdrachten standaard.

5. Overweeg alternatieve vectoropslag

Als je een RAG-systeem bouwt vanaf nul, beoordeel verschillende vectoropslagopties 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 containeriseren van je RAG-opstelling implementatie en schaalbaarheid. Bij het uitvoeren van Cognee of vergelijkbare frameworks met Ollama:

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

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

# Stel Cognee in om verbinding te maken met het container-eindpunt

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

Les geleerd

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

2. Gestructureerde uitvoer is moeilijk: Het verkrijgen van consistente schema naleving 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 vastlegt aan een framework, test het met je specifieke gebruiksscenario en hardware. Wat werkt in demos, werkt mogelijk niet op schaal of met je documenten.

4. Overweeg hybride benaderingen: Gebruik commerciële APIs voor complexe extraheringsopdrachten en lokale modellen voor eenvoudige vragen om kosten 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 verkrijgen van consistente, schema-compatibele antwoorden van LLMs:

RAG-architectuur en implementatie

Voor alternatieve of aanvullende benaderingen van kennisextrahering en opvraging:

Embedding en herordenen

Verbetering van opvragingskwaliteit via betere embeddings en herordenen:

Tools en bronnen

Externe bronnen