Un engine de grafo de conocimiento es un sistema que procesa automáticamente documentos PDF, extrae entidades y relaciones, y construye una estructura consultable por cualquier LLM con preguntas naturales. Herramientas como RAGFlow, Neo4j LLM Graph Builder y Docling permiten implementarlo sin código complejo, transformando pilas de PDFs en bases de conocimiento navegables donde cada entidad se conecta por relaciones significativas.
En 30 segundos
- Un grafo de conocimiento estructura PDFs como nodos (entidades) conectados por relaciones, permitiendo consultas complejas con múltiples saltos entre documentos
- RAGFlow (Infiniflow) y Neo4j LLM Graph Builder son los engines open source más usados en 2026, ambos con soporte para Docling como parser primario
- Diferente a RAG: RAG busca por similitud semántica en chunks, los grafos descubren y explotan relaciones explícitas entre entidades en documentos diferentes
- Docling (IBM Research) y MinerU especializados en parsing de PDFs complejos con tablas, fórmulas matemáticas y documentos en chino/japonés
- Caso de uso real: consultar base de 500 PDFs de procedimientos internos con preguntas naturales sin leer cada documento manualmente
¿Qué es un Engine de Grafo de Conocimiento y por qué importa?
Ponele que tenés 300 PDFs de documentación técnica interna en tu empresa. El director te dice: “necesito saber dónde usamos la API X, qué sistemas dependen de ella, quiénes la mantienen y qué pasó la última vez que fallá”. Con un buscador normal probablemente ves 50 resultados sin contexto. Con un grafo de conocimiento, ves exactamente: API X conectada a Sistema Y, que depende de Componente Z, mantenido por el equipo de Backend, con 3 incidentes históricos.
Un engine de grafo de conocimiento es la capa que convierte PDFs desordenados en una red estructurada de entidades conectadas. Cada entidad es un nodo: personas, productos, procesos, tecnologías. Cada relación es un vínculo: “mantiene”, “depende de”, “reemplazó a”, “se integra con”. La magia ocurre cuando le das a un LLM acceso a ese grafo y le preguntás algo. El modelo no busca por similitud, sino que sigue relaciones explícitas.
El valor está acá: no necesitás un ingeniero leyendo documentos para construir el mapa mental. El sistema lo extrae automáticamente. Y el LLM accede a una estructura que tiene contexto real, no solo fragmentos de texto que suenan parecidos.
Cómo funciona la extracción automática de PDFs a grafo de conocimiento
El pipeline tiene siete pasos. Cargás el PDF, el parser extrae texto y estructura (tablas, imágenes, metadata), lo splitea en chunks manejables, vectoriza cada chunk para embeddings, ejecuta un LLM que identifica entidades del dominio (personas, productos, conceptos), luego identifica relaciones entre esas entidades, y finalmente construye el grafo insertando nodos y aristas en una base de datos tipo Neo4j.
El cuello de botella siempre fue el step 2 (parsing). Un PDF escaneado, con imágenes, tablas fragmentadas, múltiples idiomas, te dejaba un desastre. Acá entra Docling de IBM o MinerU: entienden layout, pueden hacer OCR cuando necesitan, preservan la estructura de tablas y ecuaciones.
Una vez que tenés texto limpio, vectorización es trivial: usás embeddings de Claude, Gemini, GPT, o modelos open como Sentence Transformers. El LLM de extracción es donde decidís: ¿GPT-4o para máxima precisión? ¿Gemini 2.0 con mejor costo? ¿Claude 3.5 Sonnet si querés que sea robusto con múltiples idiomas? Cada LLM extrae entidades y relaciones con instrucciones en el prompt.
Finalmente, construís el grafo. Algunos sistemas usan Neo4j (la opción estándar), otros GraphQL, algunos SQLite con JSON nested. La elección cambia según si necesitás consultas complejas o simplicidad de setup.
Herramientas open source principales en 2026
En este momento hay cuatro players serios en el ecosistema de engines open source:
| Engine | Licencia | Parser integrado | Base de datos | Complejidad setup | Soporte multiidioma |
|---|---|---|---|---|---|
| RAGFlow (Infiniflow) | Apache 2.0 | Docling + MinerU | Neo4j, Postgres, Milvus | Media (Docker) | Sí, 8+ idiomas |
| Neo4j LLM Graph Builder | Comunidad + Enterprise | LangChain (configurable) | Neo4j nativo | Baja (API) | Sí |
| Docling (IBM) | MIT | Nativo (mejor en tablas) | Ninguno (parser solo) | Baja (Python) | CJK optimizado |
| MinerU | Apache 2.0 | Nativo (mejor en científicos) | Ninguno (parser solo) | Baja (Python) | Chino, japonés |
RAGFlow es el caballo más redondo. Te levantás un docker-compose, subís PDFs por UI web, seleccionás el parser (Docling para genéricos, MinerU para científicos), configurás qué LLM usar, y te genera el grafo automático. Soporta múltiples bases de datos, así que no quedás atrapado en una sola. La comunidad crece: GitHub lleva ~10k stars en 2026.
Neo4j LLM Graph Builder es más modular. Usás LangChain para armar tu pipeline de parsing (que puede ser Docling, PyPDF, o lo que quieras), ejecutás extracción con un LLM, y Neo4j inserta directamente. Bueno si ya tenés experiencia con Neo4j o si querés full control sobre cada paso. La versión comunitaria es gratis, Enterprise suma features como RBAC y escalado.
Docling (solo parser, no engine completo) es lo mejor si necesitás extraer PDF → Markdown limpio → después vos procesás. Está optimizado para tablas complejas y documentos con múltiples idiomas. Dos horas de setup, máximo.
MinerU ganó terreno para papers académicos, documentos en chino/japonés y layout científico complejo. Si tu corpus es documentación interna en español, Docling te alcanza. Si incluye papers, MinerU suma valor.
RAG vs Knowledge Graphs: cuándo usar cada uno
RAG (Retrieval Augmented Generation) funciona así: dividís los PDFs en chunks, los vectorizás, guardás en una base de embeddings, y cuando hacés una pregunta buscás los chunks más similares semánticamente y le pasás al LLM. Es rápido, simple, funciona bien para FAQ o manuales donde la respuesta está contenida en un solo lugar.
Knowledge Graphs es diferente: extraés la estructura explícita (relaciones), y el LLM navega el grafo para responder. “¿Quién mantiene la API X?” es trivial: seguís la arista “mantiene” desde API X hasta una persona. “¿Qué sistemas se rompen si API X falla?” es un salto: API X → [es usada por] → Sistema Y → [depende de] → Sistema Z.
RAG gana en:
- Búsqueda por similitud semántica (encontrar contenido relacionado por tema, no por estructura)
- Documentos grandes donde la respuesta cruza múltiples párrafos del mismo PDF
- Setup rápido: embeddings + vector DB, listo
- Bajo overhead computacional
Knowledge Graphs gana en:
- Descubrimiento de relaciones complejas entre documentos diferentes
- Queries que requieren múltiples saltos (A conecta con B, B conecta con C, responde sobre C)
- Auditoría y trazabilidad (seguir cadena de dependencias)
- Datos altamente estructurados (org charts, linajes de procesos, integraciones)
Ahora bien, no son mutuamente excluyentes. GraphRAG es el nombre para sistemas híbridos: construís el grafo, pero también vectorizás cada nodo, y el LLM hace búsqueda tanto por relación como por similitud. Es lo mejor de los dos mundos si tenés budget para mantenerlo.
Guía práctica: implementar con RAGFlow o Neo4j
Opción 1: RAGFlow (5 pasos, ~30 minutos)
Cloná el repo, levantás Docker, entras a la UI web. Menú superior, subís PDFs (drag-and-drop). Sistema detecta automáticamente idioma y tipo de documento. Clickeás “Start parsing”, seleccionás Docling (default) o MinerU si tenés papers. Luego eliges qué LLM: en config.py indicás OPENROUTER_API_KEY o tu API key de Claude/Gemini. RAGFlow consume el LLM para extracción (lee los PDF, identifica entidades, las conecta), y después construye el grafo en Neo4j o Postgres. Consultás desde la UI o por API.
Opción 2: Neo4j LLM Graph Builder (10 pasos, ~45 minutos, más control)
Instalás neo4j-python-driver y langchain. Importás Docling. Escribís 30 líneas de código:
from docling.document_converter import DocumentConverter
from langchain.llms import ChatOpenAI
from neo4j_graph_builder import GraphBuilder converter = DocumentConverter()
doc = converter.convert("documento.pdf")
text = doc.export_to_markdown() llm = ChatOpenAI(model="gpt-4o")
extractor = GraphBuilder(llm=llm)
graph_data = extractor.extract_entities_and_relations(text) neo4j_driver.insert_graph(graph_data)
Eso es pseudocódigo (la API exacta varía), pero el flujo es ese: Docling → extracción → Neo4j. Podés correr en local (Neo4j en Docker), cargar PDFs en batch, consultar después con Cypher.
Casos de uso reales: dónde aporta valor
Una empresa de seguros tiene 2000 PDFs de pólizas, exclusiones, cobertura especial, rulings legales, jurisprudencia. Cuando llama un cliente, el agente necesita saber: “¿esta situación está cubierta por qué póliza?” (complejo, requiere navegar múltiples referencias cruzadas). Con un grafo: Evento → [cubierto por] → Póliza A → [con exclusión] → Cláusula X → [jurisprudencia asociada] → Ruling Y. El LLM devuelve la cadena de razonamiento completa.
Un estudio de abogados con 5000 sentencias y leyes. La pregunta “¿en qué casos se ha interpretado que incumplir X es causa de resolución?” es imposible responderse leyendo; el grafo mapea Ley X → [interpretada en] → Sentencia Y → [afectó a] → Tipo de contrato Z.
Documentación técnica interna en una empresa cloud: servicios, APIs, dependencias, historiales de fallos. “¿si el servicio de auth cae, qué más falla?” → Auth → [usado por] → API Gateway, Dashboard, CLI → [que a su vez usan] → Billing, Logging, etc. Sin un grafo, es investigación manual. Con grafo, navegás en tiempo real.
Compliance y regulación: empresa farmacéutica con reglamentaciones, guías de procedimiento, cambios regulatorios. “¿cuál es el protocolo actual para este escenario clínico?” requiere cruzar regulación, guía interna, updates recientes. El grafo conecta todo.
Limitaciones, errores comunes y cómo evitarlos
Primer error: asumir que el LLM extrae entidades y relaciones perfecto. No es así. Según Neo4j, la extracción de relaciones tiene una tasa de omisión del 20-30% incluso con GPT-4o. Mitigation: ejecutá el pipeline en test con un corpus pequeño (50 documentos), validá manualmente algunas extracciones, ajustá el prompt si ves patrones de error.
Segundo: OCR fallido. Un PDF escaneado con baja resolución, rotado, o en colores extremos, el parser (incluso Docling) puede cometer errores. Solución: pre-procesa PDFs con herramientas como pdf2image + tesseract (si es documento escaneado), o verifica que tus PDFs sean digitales nativos (text-based, no imágenes).
Tercero: tablas fragmentadas. Un PDF con tabla grande que se parte entre páginas, Docling intenta reconstruir pero a veces falla. Ojo acá: si tu grafo conecta entidades de una tabla corrupta, la relación es falsa. Solución: validación manual de muestras, o usa MinerU para tablas complejas.
Cuarto: alucinación del LLM. Le pedís que extraiga “personas”, y ve “John” en el texto pero como verbo (“john down the system”), lo clasifica como persona. Mitigation: prompt engineering claro (define qué es una persona en TU dominio), provide examples en el prompt, usa chain-of-thought.
Quinto: el grafo crece sin límite y después es lento. Si cargás 10000 PDFs sin límite de entidades, terminás con un grafo de 500k nodos. Neo4j es escalable, pero las consultas se vuelven lentas. Solución: deduplica entidades (dos formas de escribir lo mismo son el mismo nodo), establece umbrales de confianza en relaciones (“si el LLM detectó la relación con <80% confidence, no la inserto").
Errores comunes durante la implementación
No validar el parsing antes de la extracción
Cargás 500 PDFs, ejecutás la extracción, esperas horas, y recién al final ves que el texto extraído es basura porque el parser no funcionó bien. Mejor: prueba el parser con 5 PDFs representativos, valida que el output en Markdown sea correcto, después escala.
Usar un LLM barato para extracción y uno caro para consulta
Docling da buen texto, pero si después usás GPT-3.5 para extraer entidades (barato), la extracción es floja. Después en producción usás GPT-4o (caro) para consultar, pero el grafo está incompleto. El budget de LLM lo gastás en la extracción, no después. Usá un buen modelo en extracción.
No deduplicar entidades
El LLM ve “Claude 3.5 Sonnet”, “claude-3-5-sonnet”, “Claude 3.5”, y crea 3 nodos diferentes para el mismo modelo. El grafo está fragmentado. Solución: deduplica post-extraction usando embeddings (si dos entidades tienen embedding muy similar, mergealas).
No establecer thresholds de confianza
El LLM extrae todas las relaciones que ve, sin confianza. La relación entre “Tema A” y “Tema B” que el modelo vio con 40% confianza, la inserta igual. Después el grafo tiene ruido. Mejor: solo inserta relaciones con >70% confianza (el modelo te lo dice si le pedís un score).
Preguntas Frecuentes
¿Cuál es la diferencia entre RAG y un knowledge graph?
RAG busca fragmentos de texto por similitud semántica. Knowledge graphs navegan por relaciones explícitas. RAG contesta: “¿qué dice el documento sobre X?” Grafos contestan: “¿cómo se conecta X con Y?” La mayoría de casos usan RAG. Grafos ganan cuando necesitás descubrimiento de relaciones complejas entre documentos.
¿Puedo usar Claude o Gemini para la extracción?
Sí. Claude 3.5 Sonnet es particularmente bueno en extracción de entidades porque entiende bien el contexto largo. Llamás a Claude API con el texto del PDF y un prompt que defina qué entidades y relaciones extraer. Gemini 2.0 también funciona. Cost varía: Claude ~USD 0,003 por página, Gemini ~USD 0,0005. Para 1000 PDFs de 10 páginas cada una, Claude te cuesta ~USD 30, Gemini ~USD 5. Elegí según presupuesto y necesidad de calidad.
¿Debo usar Neo4j o puedo guardar el grafo en otra base de datos?
Neo4j es el estándar porque está optimizado para queries complejas. Pero puedes guardar en PostgreSQL con JSON, MongoDB, o incluso una DB relacional normal si el grafo es simple. Neo4j es mejor si haces consultas tipo “dame el camino más corto entre A y B” o “dame todos los nodos a N saltos de distancia”. PostgreSQL funciona si solo necesitás “dame las relaciones de A”.
¿Cuánto cuesta levantar esto en producción?
Setup inicial: gratis si usás open source (RAGFlow, Neo4j Community, Docling). Server donde corre (AWS t3.large, ~USD 50/mes). LLM para extracción (Claude ~USD 30-100/mes según volumen). LLM para consulta (puede estar incluido en tu app). Si escalas a 10k documentos: Neo4j Enterprise ($25k+/año), infraestructura más grande. Pero para 1k documentos en intranet, USD 100-200/mes total es realista.
¿Qué pasa si actualizo un PDF? ¿Se actualiza el grafo automáticamente?
No automáticamente. Necesitás detectar que el PDF cambió (hash, fecha de modificación), volver a parserlo, re-extraer entidades, y hacer merge inteligente en Neo4j (eliminar entidades viejas, agregar nuevas, actualizar relaciones). RAGFlow tiene un workflow para esto. Si usás Neo4j manual, implementalo con un job que corra periódicamente (cada noche, por ejemplo).
Conclusión
Los engines de grafo de conocimiento dejan de ser un capricho académico y se vuelven herramienta práctica en 2026. Si tu empresa tiene pilas de documentos que los equipos consultan sin orden, un grafo te ahorra trabajo manual y devuelve respuestas que un RAG simple no puede. (Spoiler: la mayoría de lugares necesita ambos, RAG + grafo en híbrido.)
RAGFlow es el punto de entrada más bajo: docker-compose, UI web, soporte para Docling/MinerU, listo. Si ya usás Neo4j, LLM Graph Builder integra. Si tenés PDFs complejos (tablas, múltiples idiomas, científicos), Docling o MinerU primero. El tiempo de implementación es realista: una semana de experimentación, dos semanas de integración en producción.
El factor crítico es la calidad de la extracción. Un buen prompt, un LLM capaz (Claude 3.5, GPT-4o, Gemini 2.0), y validación manual en 50 documentos te evitan un grafo roto después.
Fuentes
- RAGFlow – Motor RAG open source con soporte integrado para Docling y MinerU
- Neo4j LLM Graph Builder – Extracción de grafos con LangChain integrado
- Docling – Parser de IBM optimizado para tablas y documentos complejos
- MinerU – Especialista en PDFs científicos y multiidioma
- Neo4j Blog – Construcción de knowledge graphs desde texto no estructurado