¿RAG o grafo de conocimiento? 2,160 respuestas calificadas y el efecto del modelo

¿Por qué medir en absoluto?

Los debates sobre un asistente técnico corporativo suelen estancarse en el mismo punto. Un bando aboga por RAG, el otro por un grafo de conocimiento; ambos presentan argumentos válidos, pero ninguno aporta cifras. Un experimento controlado puede proporcionar algunas: dos enfoques, tres familias de modelos, tres repeticiones y 120 preguntas con respuestas de referencia, lo que genera 2,160 respuestas evaluadas. Cada respuesta fue puntuada mediante una métrica determinista y por un panel de tres jueces.

La tesis resulta menos satisfactoria de lo que cualquiera desearía. No hay un ganador absoluto, el signo del efecto cambia según el modelo, y la variable con el efecto más grande no es ninguna de las dos estrategias; se trata de qué modelo está detrás del sistema.

Para una lectura rápida:

• El grafo superó a RAG con significancia estadística solo en uno de los tres modelos.
• El jurado prefirió RAG en los tres casos.
• Cambiar el modelo mejoró la calidad más que cambiar la estrategia.
• El conjunto de datos es sintético y la clave de respuestas fue elaborada por el experimentador, lo que limita lo que se puede transferir.

Los límites vienen primero, porque determinan si merece la pena leer el resto.

Qué abarca y qué no abarca el estudio

Mide qué estrategia de recuperación genera respuestas más correctas, más completas y más rastreables sobre un ecosistema de microservicios, manteniendo constante el modelo generador en cada comparación.

No mide la utilidad práctica con desarrolladores reales, el costo de mantenimiento a lo largo del tiempo, la calidad desde la perspectiva de quienes conocen el dominio, ni el comportamiento con documentación real, con sus inconsistencias y lagunas.

Tampoco mide el límite del enfoque basado en grafos. El grafo aquí es deliberadamente simple, con vecindades de un salto y una coincidencia de entidades difusa. Un grafo que soporte consultas de múltiples saltos y agregación global podría responder a preguntas que este no puede abordar, por lo que parte de las desventajas del grafo en las tablas se deben a la implementación y no al paradigma.

El problema

Una empresa ha pasado a utilizar microservicios. Donde antes un único conjunto de código cabía en una sola estructura, ahora existen docenas de servicios, contratos, eventos y bases de datos. El conocimiento necesario está disperso en archivos README, un catálogo interno, un tablero de operaciones y tres personas que lo conocen de memoria. Las preguntas cotidianas son sencillas pero costosas: ¿qué aplicación almacena datos personales?, ¿de qué depende el servicio X?, ¿esto ya existe y se puede reutilizar? Hoy en día la solución es preguntarle a alguien o leer documentación que podría estar desactualizada, y el verdadero costo no es el tiempo de búsqueda sino una decisión técnica tomada con información obsoleta.

Un asistente conversacional podría resolver los problemas de acceso, siempre y cuando esté especializado en el área, y la literatura especializada propone dos enfoques posibles.

Recuperación no estructurada (RAG) divide la documentación, la indexa en un almacén vectorial, obtiene los fragmentos más similares a la pregunta y los incorpora al prompt. El término proviene de Lewis y sus colegas en 2020, y Gao y sus colegas realizan un estudio de los avances recientes. Es económico de mantener y absorbe los cambios sin necesidad de reentrenamiento, pero es deficiente cuando se requiere razonamiento sobre relaciones explícitas para obtener una respuesta.

Recuperación estructurada (un grafo de conocimiento) modela el ecosistema como nodos y aristas tipificados: servicio, equipo, evento, base de datos, dependencia. Las consultas son deterministas y rastreables, aunque modelar y gestionar el grafo es costoso. El estudio de Hogan y sus colegas sobre los grafos de conocimiento es la referencia estándar.

Los dos enfoques convergen en GraphRAG, y hacia allí apuntan los resultados de este experimento.

Diseño

La decisión más importante se tomó antes incluso de escribir cualquier código: solo la capa de conocimiento puede variar. Sin esa regla, se comparan dos implementaciones y no dos estrategias. Cualquier diferencia en el formato de la instrucción o del resultado contamina el resultado de maneras que no se pueden separar posteriormente, y por eso muchos benchmarks informales de RAG terminan midiendo la habilidad de quien escribió la instrucción.

Ambos enfoques devuelven exactamente el mismo contrato de respuesta: pregunta, enfoque, respuesta, fuentes, contexto recuperado, latencia y costo estimado. Eso permite que el código de evaluación, la API y la interfaz sean agnósticos al enfoque utilizado.

La prueba necesitaba un ecosistema realista, publicable y reproducible, y utilizar el real de un empleador estaba fuera de consideración. Por lo tanto, la configuración inventa CreditXPTO, una fintech de crédito personal que no existe:

Al ser sintético, esto conlleva tres ventajas: el contenido está controlado, se conoce la respuesta correcta para cada pregunta, y cualquiera puede volver a ejecutar el proceso sin necesidad de acceso a los sistemas internos. El precio que se paga es la validez externa, que representa la principal limitación y que se analiza al final.

El mismo conocimiento existe en ambas representaciones, y la equivalencia se garantiza mediante reglas de validación que se ejecutan en la integración continua: una referencia inválida hace que el conjunto de datos sea inválido. De lo contrario, una de las partes podría saber más que la otra sin que se note. Las 120 preguntas están clasificadas por categoría (factuales, explicativas, de impacto, relacionales, de descubrimiento, ambiguas), por nivel de dificultad y por tipo de conocimiento; cada una cuenta con una respuesta esperada y sus fuentes.

El lado RAG utiliza fragmentos de 512 tokens con una superposición de 50 tokens y un top-k de 5. Las embeddings provienen de BAAI/bge-small-en-v1.5 ejecutado localmente, con Qdrant como almacén vectorial. La recuperación densa sigue el esquema popularizado por Karpukhin y colaboradores (DPR); las embeddings de oraciones derivan de Sentence-BERT, y la familia BGE se describe en C-Pack.

El lado gráfico utiliza NetworkX en memoria, construido directamente a partir de los archivos de origen para que siempre coincida con los datos. La coincidencia de entidades es difusa, con un umbral de 70/100, y la recuperación se realiza en un vecindario de un solo salto.

Puntuación

La evaluación funciona en dos niveles. El nivel uno es heurístico: similitud léxica, presencia de entidades clave y cobertura de la fuente. Es económico, determinista y reproducible, pero también superficial, ya que castiga las paráfrasis. Ese es el defecto conocido de las métricas de superposición de n-gramas y la razón por la cual existen alternativas semánticas como BERTScore.

El nivel dos consiste en un panel de tres jueces basados en modelos de lenguaje grande, uno de cada familia de modelos, que califican la corrección, completitud, fundamentación y claridad del texto desde 0 hasta 3. El paradigma de los modelos de lenguaje grande como jueces fue consolidado por Zheng y sus colegas con MT-Bench.

Un detalle es importante: la métrica principal es interfamiliar. Para cada respuesta, se excluye al evaluador de la familia del propio generador del cálculo. Los modelos reconocen su propio texto y lo califican más alto, y Panickssery y colaboradores (2024) relacionan esta preferencia propia con dicho reconocimiento. La única forma de neutralizarlo es de manera estructural, nunca solicitando imparcialidad en la instrucción.

La significancia se obtiene mediante una prueba McNemar emparejada, ya que ambas estrategias responden a las mismas preguntas. Los intervalos se calculan con método bootstrap con 5,000 remuestreos, y la concordancia entre evaluadores se mide con el kappa de Cohen.

Resultados

La primera tabla muestra la precisión estricta, en la que solo cuentan las respuestas completamente correctas, con n = 360 por celda:

Importan dos lecturas.

En primer lugar, la señal cambia según el modelo. RAG gana con dos generadores, el grafo gana con el tercero, y solo esa última diferencia es significativa. Realizar el experimento con un único modelo, como lo hacen la mayoría de las pruebas de referencia, habría producido una conclusión errónea pero segura, acompañada de un intervalo de confianza. Nada en los resultados habría dado indicios de ello.

En segundo lugar, la brecha entre los modelos supera a la brecha entre los enfoques. Pasar de claude-sonnet-4-6 a gpt-5.5 ayuda más que cambiar de estrategia dentro de cualquiera de los modelos. Eso reduce la pregunta “¿RAG o grafo?” a una decisión de segundo orden, y es el hallazgo transversal del estudio.

Al repetir la prueba con la definición amplia, otorgando crédito total además de crédito parcial y penalizando únicamente los errores flagrantes, la situación se invierte. Ahora RAG gana de manera significativa frente a los dos primeros modelos, y la ventaja del grafo en el tercero deja de ser notable. La interpretación precisa es que la virtud de RAG no radica en acertar con más frecuencia, sino en cometer errores con menos gravedad. Cuando la recuperación de información es parcial, responde de manera incompleta. Cuando la coincidencia de entidades falla, el grafo responde incorrectamente pero con certeza. Para un asistente interno, esa distinción es fundamental: un desarrollador puede completar una respuesta incompleta, pero una respuesta errónea acompañada de una fuente citada puede llegar a una reunión.

A continuación se muestran los resultados del jurado:

El panel prefiere RAG en los tres modelos, incluido aquel en el que la heurística otorgó una ventaja significativa al grafo. Eso es un efecto instrumental y no una contradicción. En un caso concreto, una pregunta recibió una similitud léxica de 0.25 y fue clasificada como incorrecta por la heurística, sin embargo el panel le asignó 2.88 de 3 puntos. La respuesta era correcta, solo formulada con otras palabras. Las métricas de N-gramas miden el vocabulario, mientras que los jueces de LLM miden la corrección percibida, con sesgos. Ninguno por sí solo responde a la pregunta, y cuando discrepan, esa discrepancia indica hacia dónde dirigir la atención.

El panel merece una advertencia honesta: la concordancia entre los jueces fue solo moderada, con un kappa de Cohen entre 0.09 y 0.56. Un panel de jueces de LLM no es una regla de precisión. Es una segunda opinión estructurada, y existen marcos como RAGAS precisamente porque evaluar la generación mejorada por recuperación de información sigue siendo un problema sin resolver.

En cuanto a la latencia, RAG fue de 12 a 20% más rápido en los tres modelos. El contexto del gráfico es más compacto, pero la consulta requiere un paso adicional. El costo varía según el modelo: el gráfico resulta más económico con dos generadores y más caro con uno. La combinación de tokens de entrada y salida difiere lo suficiente entre los proveedores como para cambiar su signo. Se trata de una observación, no de una conclusión, ya que la composición de tokens no se probó formalmente.

Cómo falla cada enfoque

Esta es la parte más útil, y no aparece en ninguna tabla.

El grafo falla estructuralmente. Al preguntar qué base de datos utiliza un servicio, devolvió el identificador del nodo y no del motor, ya que el atributo no estaba modelado. Al preguntar cuántos equipos utilizan una tecnología determinada, el vecindario de un solo salto recuperó dos servicios y respondió con seguridad que eran dos. Y si la coincidencia difusa elige la entidad incorrecta, todo el contexto resulta erróneo sin que haya señal alguna que lo indique.

RAG falla por incompletitud. Identifica correctamente que un servicio utiliza Redis, pero limita la respuesta al servicio recuperado cuando la pregunta busca una visión general.

Ambos métodos están equivocados, pero de maneras diferentes. Los defectos son complementarios, y esa es precisamente la razón por la cual la dirección obvia es híbrida, con enrutamiento según el tipo de pregunta.

Recomendaciones

• Elige primero el modelo. Es la variable con el efecto más grande. Tratarlo como un detalle de implementación mientras se pasan semanas ajustando el tamaño de los fragmentos optimiza un parámetro de segundo orden.
• Comienza con RAG. Tiene un umbral más alto y un mantenimiento más económico, y su modo de fallo es tolerable.
• Añade estructura de forma selectiva, para las dependencias, la propiedad y el consumo de eventos. No intentes modelar todo el ecosistema antes de entregar nada.
• No confíes en una sola métrica. Utiliza una heurística determinística y un conjunto de indicadores de diferentes categorías. Cuando difieren, significa que ha surgido un caso interesante y no un error.
• Utiliza una prueba emparejada. Ambas estrategias responden a las mismas preguntas, y comparar las medias sin McNemar genera una confianza que los datos no respaldan.

Limitaciones

• El conjunto de datos es sintético y la clave de respuestas fue creada por el propio experimentador. Ningún usuario real lo validó. Esto permite controlar y reproducir los resultados, pero a costa de la validez externa.
• La implementación del gráfico es deliberadamente simple, por lo que algunas de sus debilidades en la agregación podrían deberse a la implementación misma y no al paradigma utilizado.
• No se midieron la utilidad práctica ni la mantenibilidad. Estos aspectos formaban parte de los objetivos y permanecieron de naturaleza cualitativa.
• La heurística no fue validada frente al juicio humano. El panel aborda este problema sin resolverlo completamente.
• Once de las 2,160 respuestas (0.51%) se debieron a errores en la red del proveedor y no a errores del sistema.

Conclusión

La esperanza era terminar con “usar un gráfico” o “usar RAG”. Lo que se obtuvo fue que ninguna de esas respuestas existe hasta que se decide cuál modelo utilizar, y que la variable tratada como de fondo era la que tenía más influencia. Eso es menos satisfactorio pero más útil. También se aplica más allá de este caso: un punto de referencia con una variable oculta no comete errores evidentes, sino que los presenta mediante un intervalo de confianza. Antes de elegir una arquitectura entre varias opciones, pregúntese qué se mantuvo constante en el experimento y si realmente debería haberlo sido.

Leer más

• RAG avanzado en producción: arquitectura, herramientas y compromisos — Un recorrido por el RAG en entornos de producción: ingestión, análisis, fragmentación, embeddings, almacenes vectoriales, recuperación híbrida, reclasificación, evaluación y seguridad, junto con los compromisos de cada uno de ellos.
• GraphRAG vs Vector RAG: ¿Por qué la búsqueda vectorial falla a escala? — El Vector RAG tiene dificultades con la isolación de fragmentos, el razonamiento entre documentos y la escalabilidad. Vea cómo GraphRAG crea comunidades y resúmenes para solucionarlo, y cuándo elegir cada uno.

ROE frente a TechRAG: GraphRAG en Docker y Qdrant o en SQLite y LanceDB — Dos enfoques sobre la misma tesis de GraphRAG: Qdrant, MongoDB y un modelo de 120 mil millones frente a LanceDB, SQLite y qwen2.5 de 7 mil millones, con comparación de la lógica de recuperación y conclusiones extraídas.