Autogestión de Cognee: Pruebas de rendimiento de LLM
Pruebas de Cognee con LLMs locales - resultados reales
Cognee es un marco de Python para construir grafos de conocimiento a partir de documentos utilizando LLMs. ¿Pero funciona con modelos autohospedados?
Lo probé con varios LLMs locales para averiguarlo.

Esa es una página de lista de precios en formato PDF que he intentado procesar.
TL;DR
Cognee probablemente funciona bien con LLMs inteligentes con cientos de miles de millones de parámetros, pero para configuraciones de RAG autohospedadas que se espera que extraigan automáticamente datos de PDFs (como listas de precios), falló en mi hardware. La fuerte dependencia del marco en salida estructurada hace que sea difícil que los modelos locales más pequeños funcionen de manera confiable.
¿Qué es Cognee?
Cognee es un marco de código abierto de Python diseñado para construir grafos de conocimiento a partir de documentos no estructurados utilizando LLMs. A diferencia de los sistemas RAG tradicionales que simplemente recortan y embeben documentos, Cognee intenta crear una comprensión semántica extrayendo entidades, relaciones y conceptos en una base de datos gráfica. Este enfoque se alinea con arquitecturas avanzadas de RAG como GraphRAG, que promete una recuperación contextual mejorada.
El marco admite varios backends:
- Bases de datos vectoriales: LanceDB (por defecto), con soporte para otras bases de datos vectoriales
- Bases de datos gráficas: Kuzu (por defecto), permitiendo consultas complejas de relaciones
- Proveedores de LLM: OpenAI, Anthropic, Ollama y otros
- Marcos de salida estructurada: BAML e Instructor para generación restringida
Para entusiastas de autohospedaje, la compatibilidad de Cognee con Ollama lo hace atractivo para implementaciones locales. Sin embargo, el diablo está en los detalles - como veremos, los requisitos de salida estructurada crean desafíos significativos para modelos más pequeños.
¿Por qué importa la salida estructurada?
Cognee depende en gran medida de la salida estructurada para extraer información de documentos en un formato coherente. Al procesar un documento, el LLM debe devolver JSON correctamente formateado que contenga entidades, relaciones y metadatos. Es aquí donde muchos modelos más pequeños tienen dificultades.
Si estás trabajando con salida estructurada en tus propios proyectos, entender estas restricciones es crucial. Los desafíos que encontré con Cognee reflejan problemas más amplios en el ecosistema de LLM al trabajar con modelos locales.
Configuración
Aquí está mi configuración funcional para Cognee con Ollama. Tenga en cuenta las configuraciones clave que permiten la operación local:
TELEMETRY_DISABLED=1
# STRUCTURED_OUTPUT_FRAMEWORK="instructor"
STRUCTURED_OUTPUT_FRAMEWORK="BAML"
# Configuración de LLM
LLM_API_KEY="ollama"
LLM_MODEL="gpt-oss:20b"
LLM_PROVIDER="ollama"
LLM_ENDPOINT="http://localhost:11434/v1"
# LLM_MAX_TOKENS="25000"
# Configuración de embebidos
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"
# Configuración de BAML
BAML_LLM_PROVIDER="ollama"
BAML_LLM_MODEL="gpt-oss:20b"
BAML_LLM_ENDPOINT="http://localhost:11434/v1"
# Configuración de base de datos (valores por defecto)
DB_PROVIDER="sqlite"
VECTOR_DB_PROVIDER="lancedb"
GRAPH_DATABASE_PROVIDER="kuzu"
# Autenticación
REQUIRE_AUTHENTICATION=False
ENABLE_BACKEND_ACCESS_CONTROL=False
Elecciones clave de configuración
Marco de salida estructurada: Probé BAML, que ofrece un mejor control sobre los esquemas de salida en comparación con el prompting básico. BAML está diseñado específicamente para salidas estructuradas de LLM, lo que lo hace una opción natural para tareas de extracción de grafos de conocimiento.
Proveedor de LLM: Usar el punto final de API compatible con OpenAI de Ollama (/v1) permite que Cognee lo trate como cualquier otro servicio estilo OpenAI.
Modelo de embebidos: El modelo SFR-Embedding-Mistral (4096 dimensiones) proporciona embebidos de alta calidad. Para más información sobre la selección y el rendimiento de modelos de embebidos, los modelos de embebidos Qwen3 ofrecen excelentes alternativas con fuertes capacidades multilingües.
Bases de datos: SQLite para metadatos, LanceDB para vectores y Kuzu para el grafo de conocimiento mantienen todo local sin dependencias externas.
Instale Cognee
La instalación es sencilla usando uv (o pip). Recomiendo usar uv para una resolución más rápida de dependencias:
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
Los extras [ollama], [baml] y [instructor] instalan las dependencias necesarias para la operación local de LLM y salida estructurada. El extra de scraping agrega capacidades de raspado web, mientras que Playwright permite el procesamiento de páginas renderizadas con JavaScript.
Código de ejemplo y uso
Aquí está el flujo de trabajo básico para procesar documentos con Cognee. Primero, agregamos documentos y construimos el grafo de conocimiento:
msy-add.py:
import cognee
import asyncio
async def main():
# Crea un estado limpio para cognee -- reinicia datos y estado del sistema
await cognee.prune.prune_data()
await cognee.prune.prune_system(metadata=True)
# Agrega contenido de ejemplo
await cognee.add(
"/home/rg/prj/prices/msy_parts_price_20251224.pdf",
node_set=["price_list", "computer_parts", "2025-12-24", "aud"]
)
# Procesa con LLMs para construir el grafo de conocimiento
await cognee.cognify()
if __name__ == '__main__':
asyncio.run(main())
El parámetro node_set proporciona etiquetas semánticas que ayudan a categorizar el documento en el grafo de conocimiento. El método cognify() es donde ocurre la magia (o los problemas) - envía fragmentos de documentos a LLM para la extracción de entidades y relaciones.
msy-search.py:
import cognee
import asyncio
async def main():
# Busca en el grafo de conocimiento
results = await cognee.search(
query_text="¿Qué productos están en la lista de precios?"
# query_text="¿Cuál es el precio promedio para 32GB RAM (2x16GB módulos)?"
)
# Imprime
for result in results:
print(result)
if __name__ == '__main__':
asyncio.run(main())
A diferencia de la búsqueda vectorial tradicional en sistemas RAG, Cognee consulta el grafo de conocimiento, teóricamente permitiendo una recuperación más sofisticada basada en relaciones. Esto es similar a cómo funcionan las arquitecturas avanzadas de RAG, pero requiere que la construcción inicial del grafo tenga éxito.
Resultados de pruebas: rendimiento de LLMs
Probé Cognee con un caso de uso real: extraer información de producto de una lista de precios de componentes informáticos en formato PDF. Esto parecía un escenario ideal - datos estructurados en formato tabular. Aquí es lo que sucedió con cada modelo:
Modelos probados
1. gpt-oss:20b (20 mil millones de parámetros)
- Resultado: Falló con errores de codificación de caracteres
- Problema: Devolvió salida estructurada malformada con códigos de caracteres incorrectos
- Nota: A pesar de haber sido diseñado específicamente para la compatibilidad con código abierto, no pudo mantener un formato JSON consistente
2. qwen3:14b (14 mil millones de parámetros)
- Resultado: Falló al producir salida estructurada
- Problema: El modelo generaría texto pero no en el esquema JSON requerido
- Nota: Los modelos Qwen suelen rendir bien, pero esta tarea excedió sus capacidades de salida estructurada
3. deepseek-r1:14b (14 mil millones de parámetros)
- Resultado: Falló al producir salida estructurada
- Problema: Similar a qwen3, no pudo cumplir con los requisitos del esquema BAML
- Nota: Las capacidades de razonamiento no ayudaron con el cumplimiento del formato
4. devstral:24b (24 mil millones de parámetros)
- Resultado: Falló al producir salida estructurada
- Problema: Incluso con más parámetros, no pudo generar consistentemente JSON válido
- Nota: El modelo especializado en codificación aún tuvo dificultades para cumplir con los requisitos del esquema estricto
5. ministral-3:14b (14 mil millones de parámetros)
- Resultado: Falló al producir salida estructurada
- Problema: El modelo más pequeño de Mistral no podía manejar las demandas de salida estructurada
6. qwen3-vl:30b-a3b-instruct (30 mil millones de parámetros)
- Resultado: Falló al producir salida estructurada
- Problema: Las capacidades visuales no ayudaron con la extracción de tablas en PDF en este contexto
7. gpt-oss:120b (120 mil millones de parámetros)
- Resultado: No completó el procesamiento después de 2+ horas
- Hardware: Configuración de GPU para consumidor
- Problema: El modelo era demasiado grande para su uso práctico en autohospedaje, incluso si podría haber funcionado eventualmente
Hallazgos clave
Límite de tamaño de fragmento: Cognee usa fragmentos de 4k tokens al procesar documentos con Ollama. Para documentos complejos o modelos con ventanas de contexto más grandes, esto parece innecesariamente restrictivo. El marco no proporciona una forma fácil de ajustar este parámetro.
Requisitos de salida estructurada: El problema principal no es la inteligencia del modelo, sino el cumplimiento del formato. Estos modelos pueden entender el contenido, pero mantener un esquema JSON coherente durante el proceso de extracción resulta difícil. Esto se alinea con desafíos más amplios al obtener que los modelos locales respeten las restricciones de salida.
Consideraciones de hardware: Incluso cuando un modelo lo suficientemente grande podría funcionar (como gpt-oss:120b), los requisitos de hardware lo hacen impráctico para la mayoría de los escenarios de autohospedaje. Necesitarías una gran cantidad de memoria de GPU y potencia de procesamiento.
Comparación con mejores prácticas de salida estructurada
Esta experiencia reafirma lecciones aprendidas al trabajar con salida estructurada en diferentes proveedores de LLM. Las APIs comerciales de OpenAI, Anthropic y Google suelen tener mecanismos integrados para hacer cumplir los esquemas de salida, mientras que los modelos locales requieren enfoques más sofisticados como muestreo basado en gramática o múltiples pasos de validación.
Para un análisis más profundo de elegir el LLM adecuado para Cognee en Ollama, incluyendo comparaciones detalladas de diferentes tamaños de modelos y sus características de rendimiento, hay disponibles guías completas que pueden ayudarte a tomar una decisión informada.
Enfoques alternativos para RAG autohospedado
Si estás comprometido con autohospedaje y necesitas extraer datos estructurados de documentos, considera estas alternativas:
1. RAG tradicional con extracción más simple
En lugar de construir un grafo de conocimiento complejo desde el principio, usa RAG tradicional con recorte de documentos y búsqueda vectorial. Para la extracción de datos estructurados:
- Analiza tablas directamente usando bibliotecas como
pdfplumberotabula-py - Usa prompts más simples que no requieran cumplimiento estricto de esquema
- Implementa validación de postprocesamiento en Python en lugar de depender del formato de salida de LLM
2. Modelos de embebidos especializados
La calidad de tus embebidos impacta significativamente el rendimiento de recuperación. Considera usar modelos de embebidos de alta calidad que funcionen bien localmente. Modelos modernos de embebidos como los ofrecidos por Qwen3 proporcionan excelente soporte multilingüe y pueden mejorar drásticamente la precisión de tu sistema RAG.
3. Reclasificación para mejores resultados
Incluso con arquitecturas RAG más simples, agregar un paso de reclasificación puede mejorar significativamente los resultados. Después de la recuperación inicial mediante búsqueda vectorial, un modelo de reclasificación puede evaluar mejor la relevancia. Este enfoque de dos etapas suele superar a sistemas más complejos de una sola etapa, especialmente al trabajar con hardware restringido.
4. Estrategias de búsqueda híbrida
Combinar búsqueda vectorial con búsqueda tradicional de palabras clave (BM25) suele dar mejores resultados que cualquiera por separado. Muchas bases de datos vectoriales modernas admiten búsqueda híbrida de forma nativa.
5. Considerar alternativas a bases de datos vectoriales
Si estás construyendo un sistema RAG desde cero, evalúa diferentes bases de datos vectoriales según tus necesidades. Las opciones van desde bases de datos embebidas livianas hasta sistemas distribuidos diseñados para escalabilidad en producción.
Consideraciones de implementación en Docker
Para autohospedaje en producción, contenerizar tu configuración de RAG simplifica la implementación y la escalabilidad. Al ejecutar Cognee o marcos similares con Ollama:
# Ejecutar Ollama en un contenedor
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
# Descargar tus modelos
docker exec -it ollama ollama pull gpt-oss:20b
# Configurar Cognee para conectar al punto final del contenedor
Asegúrate de configurar correctamente el paso de GPU y los montajes de volúmenes para la persistencia de modelos.
Lecciones aprendidas
1. Ajuste de herramientas al hardware: Cognee está diseñado para LLMs a gran escala en la nube. Si estás autohospedando en hardware de consumo, arquitecturas más simples pueden ser más prácticas.
2. La salida estructurada es difícil: Obtener cumplimiento coherente de esquema de modelos locales sigue siendo un desafío. Si tu aplicación depende críticamente de salida estructurada, usa APIs comerciales o implementa lógica robusta de validación y reintento.
3. Prueba temprano: Antes de comprometerte con un marco, pruébalo con tu caso de uso y hardware específico. Lo que funciona en demos puede no funcionar a gran escala o con tus documentos.
4. Considere enfoques híbridos: Usa APIs comerciales para tareas complejas de extracción y modelos locales para consultas más simples para equilibrar costo y capacidad.
Lectura relacionada
Salida estructurada con LLMs
Entender la salida estructurada es crucial para marcos como Cognee. Estos artículos profundizan en obtener respuestas consistentes y compatibles con esquema de LLMs:
- Elegir el LLM adecuado para Cognee: Configuración local de Ollama
- LLMs con salida estructurada: Ollama, Qwen3 y Python o Go
- Salida estructurada en proveedores de LLM populares - OpenAI, Gemini, Anthropic, Mistral y AWS Bedrock
- Problemas de salida estructurada en Ollama GPT-OSS
Arquitectura e implementación de RAG
Para enfoques alternativos o complementarios a la extracción y recuperación de conocimiento:
- RAG avanzado: LongRAG, Self-RAG y GraphRAG
- Comparación de bases de datos vectoriales para RAG
- Construir servidores MCP en Python: Búsqueda en la web y raspado
Embebidos y reclasificación
Mejorar la calidad de recuperación mediante mejores embebidos y reclasificación:
- Modelos de embebidos y reclasificación de Qwen3 en Ollama: Rendimiento de vanguardia
- Reclasificación con modelos de embebidos
- Reclasificación de documentos de texto con Ollama y modelo de embebidos Qwen3 - en Go