Knowledge Graph + RAG: La Diferencia entre Buscar y Entender
RAG básico se queda corto cuando el corpus tiene estructura relacional. Exploramos qué gana una organización al combinar búsqueda vectorial con un grafo de conocimiento.
La promesa de RAG (Retrieval-Augmented Generation) es simple: en lugar de confiar exclusivamente en lo que un modelo de lenguaje “recuerda” de su entrenamiento, se buscan documentos relevantes y se le entregan como contexto antes de que responda. La implementación básica — dividir documentos en fragmentos, convertirlos en vectores, buscar por similitud semántica — funciona. Pero tiene un techo que se alcanza más rápido de lo que la industria suele admitir.
Ese techo aparece cuando la pregunta del usuario requiere algo más que encontrar el párrafo correcto. Cuando la respuesta depende de relaciones entre conceptos que están distribuidos en múltiples documentos, o cuando la misma palabra significa cosas distintas en contextos diferentes, la búsqueda vectorial por sí sola devuelve fragmentos relevantes pero insuficientes. El modelo genera una respuesta plausible — que es exactamente lo peligroso, porque parece correcta sin serlo.
Anatomía del RAG básico y sus puntos de quiebre
El pipeline estándar de RAG sigue cuatro pasos: ingesta de documentos, chunking (fragmentación), embedding (vectorización) y retrieval (recuperación por similitud). Cada paso introduce decisiones que afectan la calidad de las respuestas.
Chunking: dividir un documento en fragmentos de 500-1000 tokens parece razonable, pero destruye la estructura del documento. Un manual de procedimientos donde el Capítulo 3 referencia explícitamente las definiciones del Capítulo 1 se convierte en fragmentos aislados que perdieron esa relación. Cuando el usuario pregunta “¿qué procedimiento aplica para X?”, el sistema puede recuperar el procedimiento pero no las definiciones que lo condicionan.
Embedding: los modelos de embedding capturan similitud semántica, no relaciones lógicas. “El director aprueba el presupuesto” y “El gerente ejecuta el presupuesto” son semánticamente similares, pero la relación jerárquica entre director y gerente — y la diferencia operativa entre aprobar y ejecutar — se pierde en un vector de 768 dimensiones.
Retrieval: la búsqueda por coseno devuelve los fragmentos más parecidos a la consulta, no los más útiles para responderla. En un corpus técnico donde un término tiene acepciones distintas en departamentos diferentes, la ambigüedad no se resuelve — se amplifica.
Lewis et al. (2020), en el paper original de RAG, documentaron mejoras significativas sobre modelos sin retrieval. Pero el benchmark fue sobre preguntas factuales directas (Natural Questions, TriviaQA) — escenarios donde la respuesta vive literalmente en un solo párrafo. Las preguntas que enfrentan las organizaciones rara vez son así.
¿Qué aporta un Knowledge Graph?
Un grafo de conocimiento (KG) complementa la búsqueda vectorial con estructura explícita. En lugar de solo almacenar fragmentos como puntos en un espacio vectorial, se modelan las entidades del corpus y las relaciones entre ellas.
En términos concretos, un KG sobre una biblioteca técnica de Data Science podría contener:
| Entidad | Tipo | Relaciones |
|---|---|---|
| Regresión Lineal | Concepto | es_tipo_de → Modelo Supervisado |
| Scikit-learn | Librería | implementa → Regresión Lineal |
| Overfitting | Problema | afecta_a → Regresión Lineal |
| Regularización L2 | Técnica | mitiga → Overfitting |
| ISLR Cap. 3 | Fuente | explica → Regresión Lineal |
Cuando un usuario pregunta “¿cómo evito overfitting en un modelo de regresión?”, un RAG básico buscaría fragmentos que contengan “overfitting” y “regresión” juntos. Si esos términos no coexisten en el mismo chunk, el sistema falla o devuelve resultados parciales.
Con un KG, el sistema puede hacer inferencia relacional: Regresión Lineal → afectada por → Overfitting → mitigado por → Regularización L2. Luego recupera los fragmentos que explican regularización L2, incluso si el usuario nunca mencionó ese término. El grafo proporciona el razonamiento intermedio que la búsqueda vectorial no puede hacer.
Query Understanding: antes de buscar, entender qué se pregunta
El otro componente que diferencia un sistema RAG maduro de uno básico es el procesamiento de la consulta antes de la búsqueda. En un pipeline estándar, la pregunta del usuario se vectoriza directamente y se compara contra el índice. Esto funciona cuando la pregunta está bien formulada, pero en contextos reales las consultas son ambiguas, incompletas o usan terminología inconsistente.
Un módulo de Query Understanding puede:
- Descomponer preguntas complejas: “¿Cuál es la diferencia entre bagging y boosting y cuándo uso cada uno?” se descompone en dos sub-consultas que se ejecutan por separado y se sintetizan después.
- Resolver ambigüedad terminológica: si el corpus contiene “modelo” como concepto estadístico y como artefacto de software, el contexto de la pregunta determina cuál interpretación usar.
- Expandir la consulta con sinónimos del dominio: “¿cómo limpiar datos?” puede expandirse a incluir “preprocesamiento”, “data cleaning”, “manejo de valores faltantes” — términos que un usuario novato no usaría pero que aparecen en el corpus técnico.
- Clasificar la intención: distinguir entre preguntas factuales (“¿qué es PCA?”), procedimentales (“¿cómo implemento PCA en Python?”) y comparativas (“¿PCA vs t-SNE para visualización?”) permite ajustar la estrategia de retrieval.
La arquitectura combinada: vectores + grafo + reranking
El patrón arquitectónico que demuestra mejores resultados en la práctica no reemplaza la búsqueda vectorial con un grafo — los combina.
El flujo es:
- Query Understanding analiza y descompone la consulta del usuario.
- Búsqueda híbrida ejecuta en paralelo: búsqueda vectorial sobre el índice de embeddings y traversal sobre el Knowledge Graph.
- Fusion combina ambos conjuntos de resultados, eliminando duplicados y ponderando por relevancia.
- Reranking aplica un modelo de reordenamiento (como BGE Reranker o Cohere Rerank) que evalúa la relevancia de cada fragmento en el contexto específico de la pregunta — no solo su similitud general.
- Generación con el contexto filtrado y ordenado, el LLM produce la respuesta.
El reranker merece atención especial. Los modelos de embedding optimizan para recall (recuperar todo lo que podría ser relevante). El reranker optimiza para precision (ordenar por relevancia real). En la práctica, esto significa que la búsqueda vectorial puede devolver 20 fragmentos candidatos, y el reranker selecciona los 3-5 que realmente contienen la información necesaria. Edge et al. (2024) documentaron mejoras de hasta 20% en la calidad de respuestas al agregar una capa de reranking sobre RAG básico.
Decisiones de infraestructura
| Componente | Opción ligera | Opción de producción |
|---|---|---|
| Vector Store | ChromaDB, FAISS | Milvus, Qdrant, Weaviate |
| Knowledge Graph | NetworkX en memoria | Neo4j, Amazon Neptune |
| Reranker | Sentence-transformers cross-encoder | BGE Reranker, Cohere Rerank |
| Embeddings | all-MiniLM-L6 | BGE-large, E5-large-v2 |
La elección depende del volumen del corpus y los requisitos de latencia. Para una biblioteca corporativa de 500-2000 documentos, las opciones ligeras son suficientes y eliminan la complejidad operativa de gestionar servicios adicionales.
Caso de uso: biblioteca técnica con estructura relacional
Considérese una biblioteca de Data Science con 40 libros que cubren desde estadística básica hasta machine learning avanzado. Un RAG básico sobre este corpus tiene problemas predecibles:
- Un libro de 2018 y uno de 2024 pueden contradecirse sobre las mejores prácticas de preprocesamiento. Sin metadatos temporales, el sistema no puede priorizar la fuente más reciente.
- El concepto de “modelo” aparece en contextos de regresión, clasificación, series de tiempo y deep learning. Sin desambiguación, la búsqueda devuelve fragmentos de todos estos contextos mezclados.
- Las relaciones entre conceptos (prerequisitos, generalizaciones, casos especiales) son centrales para el aprendizaje pero invisibles para la búsqueda vectorial.
Con un KG que modele la taxonomía de conceptos, las dependencias entre temas y los metadatos de cada fuente, el sistema puede:
- Responder “explícame regularización empezando por lo básico” navegando el grafo desde el nodo raíz (Regularización) hacia sus tipos (L1, L2, ElasticNet) y luego recuperando los fragmentos correspondientes en orden de complejidad creciente.
- Resolver “¿qué dice el libro más reciente sobre cross-validation?” filtrando por fecha de publicación antes de buscar.
- Conectar conceptos que el usuario no sabía que estaban relacionados: “si te interesa reducción de dimensionalidad, PCA es el punto de partida, pero t-SNE y UMAP son alternativas para visualización” — una respuesta que requiere traversal del grafo, no solo recuperación de fragmentos.
¿Por qué esto importa para organizaciones?
La diferencia entre “buscar” y “entender” no es académica. Tiene consecuencias operativas directas.
En gestión del conocimiento corporativo: los manuales de procedimientos, políticas y documentación técnica de una organización forman un corpus con estructura relacional densa. Un procedimiento referencia una política, que referencia un reglamento, que tiene excepciones documentadas en otro lugar. Un RAG básico sobre este corpus genera respuestas parciales o incorrectas con frecuencia suficiente para erosionar la confianza del usuario.
En capacitación técnica: cuando un sistema de aprendizaje puede navegar relaciones entre conceptos, la experiencia pasa de “buscador con respuestas largas” a algo más parecido a un tutor que entiende la estructura del conocimiento.
En due diligence y análisis regulatorio: en sectores donde la respuesta incorrecta tiene consecuencias legales o financieras, la diferencia entre recuperar el fragmento más similar y recuperar todos los fragmentos relevantes conectados no es una mejora incremental — es un requisito.
Conclusión
RAG fue un salto significativo sobre la generación pura de los LLMs. Pero tratarlo como una solución terminada es un error. La búsqueda vectorial resuelve el problema de encontrar información similar. No resuelve el problema de entender las relaciones entre piezas de información. Para organizaciones que necesitan respuestas confiables sobre corpus con estructura relacional — que son la mayoría de los corpus corporativos reales — agregar un Knowledge Graph y un pipeline de Query Understanding no es sobreingeniería. Es la diferencia entre un buscador glorificado y un sistema que realmente comprende el dominio.
Referencias
- Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems, 33.
- Edge, D. et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv preprint arXiv:2404.16130.
- Pan, S. et al. (2024). Unifying Large Language Models and Knowledge Graphs: A Roadmap. IEEE Transactions on Knowledge and Data Engineering.
- Ji, S. et al. (2022). A Survey on Knowledge Graphs: Representation, Acquisition, and Applications. IEEE Transactions on Neural Networks and Learning Systems, 33(2).
- Gao, Y. et al. (2024). Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv preprint arXiv:2312.10997.