Self-Hosting Cognee: LLM-prestandatest
Testa Cognee med lokala LLMs - verkliga resultat
Cognee är en Pythonramverk för att bygga kunskapsgrafik från dokument med hjälp av LLMs. Men fungerar det med självvärddade modeller?
Jag testade det med flera lokala LLMs för att hitta ut.

Det är en prislista PDF-sida som jag har försökt bearbeta.
TL;DR
Cognee fungerar sannolikt bra med smarta LLMs med hundratals miljarder parametrar, men för självvärdda RAG-konfigurationer som förväntas automatiskt extrahera data från PDF-filer (som prislistor), så misslyckades ramverket att leverera på min hårdvara. Ramverkets stora beroende på strukturerad utdata gör det svårt för mindre lokala modeller att utföra pålitligt.
Vad är Cognee?
Cognee är ett öppen källkod Pythonramverk som är designat för att bygga kunskapsgrafik från ostrukturerade dokument med hjälp av LLMs. Olika från traditionella RAG-system som enkelt delar upp och embedder dokument, försöker Cognee skapa en semantisk förståelse genom att extrahera entiteter, relationer och koncept till en grafdatabas. Detta tillvägagångssätt följer avancerade RAG-arkitekturer som GraphRAG, som lovar bättre kontextuell hämtning.
Ramverket stöder flera bakändor:
- Vektordatabaser: LanceDB (standard), med stöd för andra vektordatabaser
- Graf-databaser: Kuzu (standard), vilket möjliggör komplexa relationssökningar
- LLM-leverantörer: OpenAI, Anthropic, Ollama och andra
- Strukturerade utdataframverk: BAML och Instructor för begränsad generering
För entusiaster som vill självvärda, gör Cognees kompatibilitet med Ollama det attraktivt för lokala distributioner. Men, som vi kommer att se, skapar kraven på strukturerad utdata betydande utmaningar för mindre modeller.
Varför Strukturerad Utdata Är Viktig
Cognee bygger starkt på strukturerad utdata för att extrahera information från dokument i en konsekvent format. När en dokument bearbetas måste LLM returnera korrekt formaterad JSON som innehåller entiteter, relationer och metadata. Det är här många mindre modeller har svårt.
Om du arbetar med strukturerad utdata i dina egna projekt, är det viktigt att förstå dessa begränsningar. De utmaningar jag mötte med Cognee speglar bredare problem i LLM-ekosystemet när man arbetar med lokala modeller.
Konfigurationsinställningar
Här är min fungerande konfiguration för Cognee med Ollama. Observera de viktiga inställningarna som möjliggör lokal drift:
TELEMETRY_DISABLED=1
# STRUCTURED_OUTPUT_FRAMEWORK="instructor"
STRUCTURED_OUTPUT_FRAMEWORK="BAML"
# LLM-konfiguration
LLM_API_KEY="ollama"
LLM_MODEL="gpt-oss:20b"
LLM_PROVIDER="ollama"
LLM_ENDPOINT="http://localhost:11434/v1"
# LLM_MAX_TOKENS="25000"
# Embedding-konfiguration
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-konfiguration
BAML_LLM_PROVIDER="ollama"
BAML_LLM_MODEL="gpt-oss:20b"
BAML_LLM_ENDPOINT="http://localhost:11434/v1"
# Databasinställningar (standardvärden)
DB_PROVIDER="sqlite"
VECTOR_DB_PROVIDER="lancedb"
GRAPH_DATABASE_PROVIDER="kuzu"
# Autentisering
REQUIRE_AUTHENTICATION=False
ENABLE_BACKEND_ACCESS_CONTROL=False
Viktiga Konfigurationsval
Strukturerad Utdata Framverk: Jag testade BAML, vilket ger bättre kontroll över utdatastrukturer jämfört med grundläggande promptning. BAML är specifikt designat för strukturerade LLM-utdata, vilket gör det en naturlig val för kunskapsgrafikextraktion.
LLM-leverantör: Genom att använda Ollamas OpenAI-kompatibla API-slutpunkt (/v1) möjliggör Cognee att behandla det som någon annan OpenAI-stil tjänst.
Embeddingsmodell: SFR-Embedding-Mistral-modellen (4096 dimensioner) ger högkvalitativa embeddings. Mer om val av embeddingsmodeller och prestanda, erbjuder Qwen3 embeddingsmodeller utmärkta alternativ med starka mångspråkiga förmågor.
Databaser: SQLite för metadata, LanceDB för vektorer, och Kuzu för kunskapsgrafik håller allt lokalt utan externa beroenden.
Installera Cognee
Installationen är enkel genom uv (eller pip). Jag rekommenderar att använda uv för snabbare beroendehantering:
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] och [instructor] extra-installationerna installerar de nödvändiga beroendena för lokal LLM-drift och strukturerad utdata. Den extra installationen för skrapning lägger till webbskrapningsförmåga, medan Playwright möjliggör bearbetning av JavaScript-renderade sidor.
Exempelkod och Användning
Här är den grundläggande arbetsflöde för att bearbeta dokument med Cognee. Först lägger vi till dokument och bygger kunskapsgrafiken:
msy-add.py:
import cognee
import asyncio
async def main():
# Skapa en ren plattform för cognee -- återställ data och systemstatus
await cognee.prune.prune_data()
await cognee.prune.prune_system(metadata=True)
# Lägg till exempeldata
await cognee.add(
"/home/rg/prj/prices/msy_parts_price_20251224.pdf",
node_set=["price_list", "computer_parts", "2025-12-24", "aud"]
)
# Bearbeta med LLMs för att bygga kunskapsgrafiken
await cognee.cognify()
if __name__ == '__main__':
asyncio.run(main())
Parametern node_set ger semantiska taggar som hjälper till att kategorisera dokumentet i kunskapsgrafiken. Metoden cognify() är där magin (eller problemen) sker - den skickar dokumentdelar till LLM för extraktion av entiteter och relationer.
msy-search.py:
import cognee
import asyncio
async def main():
# Sök i kunskapsgrafiken
results = await cognee.search(
query_text="Vilka produkter finns i prislistan?"
# query_text="Vad är den genomsnittliga priset för 32GB RAM (2x16GB moduler)?"
)
# Skriv ut
for result in results:
print(result)
if __name__ == '__main__':
asyncio.run(main())
Olika från traditionell vektor sökning i RAG-system, söker Cognee i kunskapsgrafiken, vilket teoretiskt möjliggör mer avancerad relationssökning. Detta liknar hur avancerade RAG-arkitekturer fungerar, men kräver att den initiala grafkonstruktionen lyckas.
Testresultat: LLMs prestanda
Jag testade Cognee med ett verkligt användningsfall: extrahering av produktinformation från en datorkomponenter prislista PDF. Det här verkade som ett idealiskt scenario - strukturerad data i en tabellformat. Här är vad som hände med varje modell:
Modeller som Testades
1. gpt-oss:20b (20 miljarder parametrar)
- Resultat: Misslyckades med karaktärskodningsfel
- Problem: Returnerade felaktigt strukturerad utdata med felaktiga karaktärskoder
- Obs: Även om den är specifikt designad för öppen källkodskompatibilitet, kunde den inte upprätthålla konsekvent JSON-formatering
2. qwen3:14b (14 miljarder parametrar)
- Resultat: Misslyckades att producera strukturerad utdata
- Problem: Modellen skulle generera text men inte i den krävda JSON-schemat
- Obs: Qwen-modeller presterar vanligtvis bra, men denna uppgift översteg dess förmåga att hantera strukturerad utdata
3. deepseek-r1:14b (14 miljarder parametrar)
- Resultat: Misslyckades att producera strukturerad utdata
- Problem: Liknande qwen3, kunde inte följa BAML-schema kraven
- Obs: Den logiska förmågan hjälpte inte med formatkompatibilitet
4. devstral:24b (24 miljarder parametrar)
- Resultat: Misslyckades att producera strukturerad utdata
- Problem: Även med fler parametrar, kunde inte konsekvent generera giltig JSON
- Obs: Specialiserad kodmodell fortfarande kämpade med strikta schema krav
5. ministral-3:14b (14 miljarder parametrar)
- Resultat: Misslyckades att producera strukturerad utdata
- Problem: Mindre modell från Mistral kunde inte hantera kraven på strukturerad utdata
6. qwen3-vl:30b-a3b-instruct (30 miljarder parametrar)
- Resultat: Misslyckades att producera strukturerad utdata
- Problem: Visionförmågan hjälpte inte med PDF-tabellextraktion i detta sammanhang
7. gpt-oss:120b (120 miljarder parametrar)
- Resultat: Kunde inte slutföra bearbetningen efter över 2 timmar
- Hårdvara: Konsument GPU-konfiguration
- Problem: Modellen var för stor för praktisk självvärdd användning, även om den kanske skulle ha fungerat till slut
Viktiga Resultat
Delningsstorlek begränsning: Cognee använder 4k token delar när dokument bearbetas med Ollama. För komplexa dokument eller modeller med större kontextfönster verkar detta onödigt restriktivt. Ramverket tillhandahåller inte en enkel sätt att justera denna parameter.
Krav på strukturerad utdata: Det centrala problemet är inte modellens intelligens utan formatkompatibilitet. Dessa modeller kan förstå innehållet, men att upprätthålla konsekvent JSON-schema under extraktionsprocessen visar sig vara utmanande. Detta sammanfaller med bredare utmaningar i att få lokala modeller att följa utdatabegränsningar.
Hårdvarakonfiguration: Även när en tillräckligt stor modell kan fungera (som gpt-oss:120b), gör hårdvarakraven det orealistiskt för de flesta självvärdd scenarier. Du skulle behöva betydande GPU-minne och bearbetningskraft.
Jämförelse med bästa praxis för strukturerad utdata
Den här upplevelsen förstärker lektioner från att arbeta med strukturerad utdata över olika LLM-leverantörer. Kommerande API:er från OpenAI, Anthropic och Google har ofta inbyggda mekanismer för att tvinga utdataformat, medan lokala modeller kräver mer avancerade metoder som grammatisk sampling eller flera valideringspass.
För en djupare analys av välja rätt LLM för Cognee på Ollama, inklusive detaljerade jämförelser av olika modellstorlekar och deras prestandaegenskaper, finns omfattande guider tillgängliga som kan hjälpa dig att göra en informerad beslut.
Alternativa tillvägagångssätt för självvärdd RAG
Om du är engagerad i att självvärda och behöver extrahera strukturerad data från dokument, överväg dessa alternativ:
1. Traditionell RAG med enklare extraktion
I stället för att bygga en komplex kunskapsgrafik direkt, använd traditionell RAG med dokumentdelning och vektorsökning. För strukturerad dataextraktion:
- Parsa tabeller direkt med bibliotek som
pdfplumberellertabula-py - Använd enklare prompter som inte kräver strikt schema följsamhet
- Implementera postbearbetningsvalidering i Python istället för att förlita sig på LLM-utdataformat
2. Specialiserade embeddingsmodeller
Kvaliteten på dina embeddings påverkar starkt hämtningens prestanda. Överväg att använda högpresterande embeddingsmodeller som fungerar bra lokalt. Moderna embeddingsmodeller som Qwen3s erbjudanden ger utmärkta mångspråkiga stöd och kan dramatiskt förbättra din RAG-systems noggrannhet.
3. Återrankning för bättre resultat
Även med enklare RAG-arkitekturer kan en återrankningssteg starkt förbättra resultat. Efter initial vektorsökning hämtning kan en återrankningsmodell bättre bedöma relevans. Detta tvåstegsapproach ofta överträffar mer komplexa enskilda stegsystem, särskilt när man arbetar med begränsad hårdvara.
4. Hybrid sökstrategier
Att kombinera vektorsökning med traditionell ord sökning (BM25) ger ofta bättre resultat än något av dem ensamt. Många moderna vektordatabaser stöder hybrid sökning som standard.
5. Överväg alternativa vektordatabaser
Om du bygger ett RAG-system från grunden, utvärdera olika vektordatabaser utifrån dina behov. Alternativ omfattar från lättviktade inbyggda databaser till distribuerade system designade för produktionsnivå.
Dockerdistribution överväganden
För produktionsnivå självvärdd, förenklar containerisering av din RAG-konfiguration distribution och skalning. När du kör Cognee eller liknande ramverk med Ollama:
# Kör Ollama i en container
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
# Hämta dina modeller
docker exec -it ollama ollama pull gpt-oss:20b
# Konfigurera Cognee för att ansluta till container-slutpunkten
Se till att korrekt konfigurera GPU-överföring och volymmonteringar för modellpåminnelser.
Lärdomar
1. Matcha verktyg till hårdvara: Cognee är designat för molnskala LLMs. Om du självvärderar på konsumenthårdvara, kan enklare arkitekturer vara mer praktiska.
2. Strukturerad utdata är svårt: Att få konsekvent schema följsamhet från lokala LLMs är fortfarande utmanande. Om din tillämpning kritiskt beroende på strukturerad utdata, använd kommersiella API:er eller implementera robust validering och återförsök logik.
3. Testa tidigt: Innan du återkommer till ett ramverk, testa det med din specifika användningsscenario och hårdvara. Vad fungerar i demonstrationer kan inte fungera i större skala eller med dina dokument.
4. Överväg hybridtillvägagångssätt: Använd kommersiella API:er för komplexa extraktionsuppgifter och lokala modeller för enklare frågor för att balansera kostnad och förmåga.
Relaterad läsning
Strukturerad utdata med LLMs
Förståelse av strukturerad utdata är avgörande för ramverk som Cognee. Dessa artiklar går djupare in i att få konsekenta, schema-kompatibla svar från LLMs:
- Välja rätt LLM för Cognee: Lokal Ollama konfiguration
- LLMs med strukturerad utdata: Ollama, Qwen3 & Python eller Go
- Strukturerad utdata över populära LLM-leverantörer - OpenAI, Gemini, Anthropic, Mistral och AWS Bedrock
- Ollama GPT-OSS Strukturerad Utdata Problematik
RAG-arkitektur och implementering
För alternativa eller kompletterande tillvägagångssätt till kunskapsextraktion och hämtning:
- Avancerad RAG: LongRAG, Self-RAG och GraphRAG
- Vektordatabaser för RAG jämförelse
- Bygg MCP-servrar i Python: Webbsökning & Skrapning
Embedding och återrankning
Förbättra hämtningens kvalitet genom bättre embeddings och återrankning:
- Qwen3 Embedding & Återrankningsmodeller på Ollama: State-of-the-Art Prestanda
- Återrankning med embeddingsmodeller
- Återrankning av textdokument med Ollama och Qwen3 Embeddingmodell - i Go