Autohospedaje de Cognee: Elegir LLM en Ollama
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 descubrirlo.

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), fracasó en mi hardware. El marco depende en gran medida de la salida estructurada, lo que hace que sea difícil para los modelos locales más pequeños realizar una tarea con fiabilidad.
¿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 de RAG tradicionales que simplemente fragmentan y embebden documentos, Cognee intenta crear una comprensión semántica extrayendo entidades, relaciones y conceptos en una base de datos de grafos. 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 de grafos: 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 la autohospitalización, la compatibilidad de Cognee con Ollama la hace atractiva para despliegues locales. Sin embargo, el diablo está en los detalles - como veremos, los requisitos de salida estructurada crean desafíos significativos para los 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 enfrenté 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 del 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 incrustación
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 la base de datos (valores predeterminados)
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 convierte en una opción natural para tareas de extracción de grafos de conocimiento.
Proveedor de LLM: Usar el punto final del API de Ollama compatible con OpenAI (/v1) permite a Cognee tratarlo como cualquier otro servicio estilo OpenAI.
Modelo de incrustación: El modelo SFR-Embedding-Mistral (4096 dimensiones) proporciona incrustaciones de alta calidad. Para más información sobre la selección y el rendimiento de modelos de incrustación, los modelos de incrustación 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.
Instalar 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 de LLM local y la 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():
# Crear un estado limpio para cognee -- restablecer datos y estado del sistema
await cognee.prune.prune_data()
await cognee.prune.prune_system(metadata=True)
# Añadir 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"]
)
# Procesar 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 del documento al LLM para la extracción de entidades y relaciones.
msy-search.py:
import cognee
import asyncio
async def main():
# Buscar 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 32 GB de RAM (2 módulos de 16 GB)?"
)
# Imprimir
for result in results:
print(result)
if __name__ == '__main__':
asyncio.run(main())
A diferencia de la búsqueda de vectores en sistemas de RAG tradicionales, 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 productos de una lista de precios de componentes de computadora en formato PDF. Esto parecía un escenario ideal - datos estructurados en formato tabular. Aquí está 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 con códigos de caracteres incorrectos
- Nota: A pesar de estar diseñado específicamente para compatibilidad con código abierto, no pudo mantener un formato JSON coherente
2. qwen3:14b (14 mil millones de parámetros)
- Resultado: Falló en producir salida estructurada
- Problema: El modelo generaría texto, pero no en el esquema JSON requerido
- Nota: Los modelos Qwen suelen funcionar bien, pero esta tarea excedió sus capacidades de salida estructurada
3. deepseek-r1:14b (14 mil millones de parámetros)
- Resultado: Falló en producir salida estructurada
- Problema: Similar a qwen3, no pudo adherirse a los requisitos del esquema BAML
- Nota: Las capacidades de razonamiento no ayudaron con la conformidad al formato
4. devstral:24b (24 mil millones de parámetros)
- Resultado: Falló en producir salida estructurada
- Problema: Incluso con más parámetros, no pudo generar consistentemente JSON válido
- Nota: Modelo especializado en código aún tuvo dificultades para adherirse a esquemas estrictos
5. ministral-3:14b (14 mil millones de parámetros)
- Resultado: Falló en 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ó en producir salida estructurada
- Problema: Las capacidades visuales no ayudaron con la extracción de tablas de PDF en este contexto
7. gpt-oss:120b (120 mil millones de parámetros)
- Resultado: No completó el procesamiento después de más de 2 horas
- Hardware: Configuración de GPU para consumo
- Problema: El modelo era demasiado grande para un uso práctico autohospedado, incluso si podría haber funcionado eventualmente
Hallazgos clave
Límite de tamaño de fragmento: Cognee utiliza 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 manera fácil de ajustar este parámetro.
Requisitos de salida estructurada: El problema principal no es la inteligencia del modelo, sino la conformidad al 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 hacen que sea impráctico para la mayoría de los escenarios de autohospitalización. Necesitarías una gran cantidad de memoria de GPU y potencia de procesamiento.
Comparación con mejores prácticas de salida estructurada
Esta experiencia refuerza lecciones de trabajar con salida estructurada en diferentes proveedores de LLM. Las APIs comerciales de OpenAI, Anthropic y Google suelen tener mecanismos integrados para imponer 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 guías completas disponibles que pueden ayudarte a tomar una decisión informada.
Alternativas para RAG autohospedado
Si estás comprometido con la autohospitalización y necesitas extraer datos estructurados de documentos, considera estas alternativas:
1. RAG tradicional con extracción más sencilla
En lugar de construir un grafo de conocimiento complejo de antemano, usa un RAG tradicional con fragmentación 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 sencillos que no requieran cumplimiento estricto de esquema
- Implementa validación postprocesamiento en Python en lugar de depender de la forma de salida del LLM
2. Modelos de incrustación especializados
La calidad de tus incrustaciones impacta significativamente el rendimiento de la recuperación. Considera usar modelos de incrustación de alto rendimiento que funcionen bien localmente. Modelos modernos de incrustación como los de Qwen3 ofrecen excelente soporte multilingüe y pueden mejorar significativamente la precisión de tu sistema de RAG.
3. Reclasificación para mejores resultados
Incluso con arquitecturas de RAG más sencillas, 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 sistemas más complejos de una sola etapa, especialmente cuando se trabaja con hardware restringido.
4. Estrategias de búsqueda híbrida
Combinar búsqueda vectorial con búsqueda de palabras clave tradicional (BM25) suele dar mejores resultados que cualquiera de ellos 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 de RAG desde cero, evalúa diferentes bases de datos vectoriales según tus necesidades. Las opciones van desde bases de datos embebidas ligeras hasta sistemas distribuidos diseñados para escalabilidad en producción.
Consideraciones de despliegue en Docker
Para el despliegue en producción, contenerizar tu configuración de RAG simplifica el despliegue 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. Ajustar herramientas al hardware: Cognee está diseñado para LLMs de 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 una conformidad consistente con esquemas locales sigue siendo un desafío. Si tu aplicación depende críticamente de la salida estructurada, usa APIs comerciales o implementa lógica de validación y reintento robusta.
3. Prueba temprano: Antes de comprometerte con un marco, pruébalo con tu caso de uso específico y hardware. Lo que funciona en demos puede no funcionar a escala o con tus documentos.
4. Considera 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 coherentes y compatibles con esquemas 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 populares de LLM - 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 de conocimiento y recuperación:
- RAG avanzado: LongRAG, Self-RAG y GraphRAG
- Comparación de bases de datos vectoriales para RAG
- Construir servidores MCP en Python: Búsqueda web y raspado
Incrustación y reclasificación
Mejorar la calidad de recuperación mediante incrustaciones y reclasificación mejoradas:
- Modelos de incrustación y reclasificación de Qwen3 en Ollama: Rendimiento de vanguardia
- Reclasificación con modelos de incrustación
- Reclasificación de documentos de texto con Ollama y modelo de incrustación Qwen3 - en Go