RAG 2.0: grafos de conocimiento, vectores e híbrido

Actualizado: 2026-05-03

La conversación sobre RAG en 2025 es distinta de la de 2023. Hace dos años el tema era elegir la mejor base vectorial y decidir cuántos tokens caben en el contexto. Hoy el término RAG esconde sistemas híbridos que combinan varias fuentes de recuperación, grafos que capturan relaciones entre entidades y capas de reordenamiento que acercan la respuesta a lo que el usuario necesita. Este post recoge lo que he aprendido montando RAG 2.0 en varios proyectos durante los últimos meses, qué piezas aportan valor real y cuáles son moda sin sustancia.

Para el contexto del ecosistema de grafos de conocimiento que da sustrato a estas arquitecturas, el análisis de GraphRAG de Microsoft en empresa y el post sobre grafos de conocimiento que renacen con LLM cubren la historia técnica relevante. La evaluación continua de sistemas RAG se trata en RAG: evaluación continua. Los patrones de arquitectura que conectan con agentes se describen en wrappers de LLM en producto.

Puntos clave

• La búsqueda híbrida (vectorial + BM25 léxica) sube la calidad de los fragmentos recuperados entre un 15 y un 30% sobre vectorial pura.
• Los grafos de conocimiento aportan información estructural de relaciones que los embeddings no capturan bien; complementan, no reemplazan, a los vectores.
• Un reranker cross-encoder sobre los candidatos de la búsqueda híbrida añade 10-20% de precisión adicional en los top-5 fragmentos.
• La calidad del corpus sigue siendo la variable que más pesa; un RAG sofisticado sobre datos sucios rinde peor que uno simple sobre datos curados.
• Saltar a RAG 2.0 completo desde cero rara vez es rentable; mejor empezar simple y añadir capas cuando el fallo lo justifique.

Por qué el RAG original ya no basta

El RAG de primera generación se basaba en una idea simple: dividir los documentos en fragmentos, calcular embeddings, guardarlos en una base vectorial, buscar los fragmentos más similares a la pregunta y pasarlos al modelo para que generara la respuesta. Esta idea funciona bien cuando la pregunta se corresponde directamente con el texto: «cuál es la política de devoluciones», «qué dice el manual sobre calibración del sensor».

Falla cuando la pregunta requiere combinar información de varios fragmentos que no son individualmente similares. «Qué empleados colaboraron con el proveedor X en proyectos europeos» es una pregunta donde la respuesta no está en ningún fragmento concreto; está en la relación entre varios. La base vectorial devuelve fragmentos relevantes por similitud léxica pero no por relación estructural.

El otro fallo clásico es el de palabras clave específicas. Si alguien pregunta por un código de error concreto o un número de referencia, la búsqueda vectorial puede fallar porque los embeddings no capturan bien identificadores raros. La búsqueda léxica pura —la de toda la vida— funciona mejor en esos casos. El RAG de 2023 ignoraba esta realidad porque la novedad era lo vectorial.

Lo que añade la búsqueda híbrida

La primera mejora de RAG 2.0 es la búsqueda híbrida: combinar búsqueda vectorial con búsqueda léxica (BM25 clásico) y fusionar resultados con una función de ranking. En las pruebas, esta combinación simple sube la calidad de los fragmentos recuperados entre un 15 y un 30% respecto a vectorial pura, dependiendo del dominio.

El ajuste importante es la proporción. Dar el mismo peso a ambas fuentes suele funcionar peor que dar más peso a una según el tipo de pregunta:

• Para consultas con términos técnicos raros: más peso léxico.
• Para consultas conceptuales: más peso vectorial.

La fusión más robusta que he visto no suma ponderadamente los scores sino que combina rangos: usa el mejor rango del documento en cualquiera de las dos búsquedas, con una penalización por aparecer solo en una. Este enfoque evita el problema de las escalas de score distintas entre métodos.

Grafos de conocimiento como capa estructural

La segunda pieza de RAG 2.0 es el grafo de conocimiento. En lugar de tratar los documentos como texto plano, el sistema extrae entidades —personas, proyectos, conceptos— y relaciones entre ellas. El resultado es un grafo donde nodos son entidades y aristas son relaciones explícitas.

Cuando llega una pregunta que pide combinar información, el sistema puede navegar el grafo para encontrar entidades conectadas y usar esa información estructural junto con los fragmentos textuales. «Qué empleados colaboraron con el proveedor X en proyectos europeos» se convierte en una consulta de grafo que devuelve las entidades relevantes con sus relaciones, y el modelo genera la respuesta con ese contexto ya ordenado.

El grafo no reemplaza los embeddings, los complementa. Los embeddings siguen siendo la forma de encontrar texto semánticamente parecido; el grafo aporta la información de relaciones que los embeddings no capturan bien.

Construir el grafo sin matar el proyecto

El problema práctico de los grafos es que construirlos a partir de texto no estructurado es caro. La extracción automática con modelos de lenguaje funciona pero deja errores: entidades duplicadas con nombres ligeramente distintos, relaciones espureas, omisiones. Si el grafo tiene demasiado ruido, la ganancia de usarlo se pierde rápidamente.

Lo que funciona es un enfoque escalonado:

1. Primera pasada: extracción automática con un modelo eficaz y un esquema acotado de tipos de entidad y de relación.
2. Segunda pasada: normalización de entidades por similitud y reglas simples de canonicalización.
3. Tercera pasada: revisión humana de las relaciones de alta cardinalidad antes de aprobar el grafo para uso. Saltar esta fase paga caro en forma de respuestas incorrectas con apariencia de seguridad.

La alternativa cuando el dominio ya tiene una taxonomía formal —productos catalogados, empleados en un directorio, proyectos en un sistema de gestión— es usar esa taxonomía como columna vertebral del grafo y enriquecerla con relaciones extraídas del texto. Partir de estructura existente siempre es más barato que construirla desde cero.

Reranking, la capa que no se ve

La tercera pieza de RAG 2.0 es el reranking: un modelo que toma los fragmentos recuperados por la búsqueda híbrida y los reordena según su relevancia para la consulta concreta. El reranker no indexa nada; opera solo sobre los candidatos que ya han salido de la fase de recuperación.

Los modelos de reranking actuales son cross-encoders especializados. Miran la pregunta y cada candidato conjuntamente, lo que les da mejor sensibilidad que los encoders que procesan cada uno por separado. El coste es mayor por candidato, pero como solo se ejecutan sobre los top 50 o 100, el impacto es asumible.

Añadir un reranker sube la precisión de los top-5 fragmentos entre un 10 y un 20% adicional sobre la búsqueda híbrida. En RAG 2.0 es una pieza casi obligada si el caso de uso es serio.

Las trampas de la evaluación

Diseñar un RAG 2.0 sin evaluación rigurosa es apagar el panel de vuelo y navegar por intuición:

• Usar el propio modelo generador como juez produce optimismo sistemático. Los jueces deben ser independientes.
• Medir solo en consultas tipo es insuficiente. Los sistemas que dan respuesta perfecta a las 20 consultas del equipo de producto pueden dar respuesta mediocre a las 2.000 consultas que realmente hacen los usuarios.
• Ignorar los casos en los que el sistema debería decir que no sabe. Un RAG que inventa con seguridad cuando la información no está en el corpus es peor que uno que responde poco pero bien.

Lo que no ha cambiado

Hay cosas que no han cambiado entre 2023 y 2025:

• La calidad del corpus sigue siendo la variable que más pesa: datos limpios, con metadatos correctos, con actualizaciones frecuentes. Un RAG de arquitectura sofisticada sobre datos sucios rinde peor que un RAG simple sobre datos curados.
• El chunking sigue siendo más arte que ciencia: fragmentos de tamaño fijo funcionan decentemente pero no son óptimos en documentos con estructura interna fuerte.
• El coste de mantenimiento no ha bajado: reindexar corpus grandes cuando los documentos cambian sigue siendo caro. RAG 2.0 no es plug and play; es un sistema vivo que hay que cuidar.

Cómo pensar la decisión

Mi recomendación para quien empieza un proyecto RAG en 2025 es escalar la arquitectura al problema:

• Si la pregunta del caso de uso se corresponde con texto directamente: vectorial puro con buen corpus puede bastar.
• Si hay mezcla de preguntas conceptuales y de identificador: añadir búsqueda léxica es fácil y rentable.
• Si las preguntas requieren combinar información estructural: merece la pena plantear grafo.

Saltar a RAG 2.0 completo desde cero es tentador pero rara vez rentable. La complejidad crece rápido, los bugs se multiplican y la capacidad de diagnosticar por qué una respuesta es mala se reduce. Mejor empezar simple, medir qué tipo de preguntas falla, y añadir la capa correspondiente cuando el fallo lo justifique.