| Limitación del RAG básico | Cómo se manifiesta | Familia que la ataca |
|---|---|---|
| Chunks aislados, sin contexto | Respuestas incompletas o ambiguas: «el CEO», «la política», «el próximo trimestre» | Enriquecimiento |
| Chunks pequeños que pierden contexto | Respuestas fragmentadas | Enriquecimiento |
| Sin relaciones entre conceptos | No puede responder «¿cómo se relaciona X con Y?» | Estructural |
| No valida la calidad de lo recuperado | Usa chunks irrelevantes con total aplomo | Auto-correctivo |
| Una estrategia fija para todas las queries | Buena para unas, mala para otras | Enrutado |
El material abre con un ejemplo que vale como test de diagnóstico. Un chunk dice: «El CEO anunció que la política cambiaría el próximo trimestre». Recuperarlo es fácil; usarlo es imposible, porque no dice quién es el CEO, qué política ni cuándo es ese trimestre. Si tus fallos se parecen a ese, tu problema es de enriquecimiento y ninguna otra familia te va a ayudar.
Se cambia qué se guarda. El chunk deja de ser un fragmento suelto y pasa a llevar su contexto encima, o a poder recuperar el fragmento mayor del que salió.
Se añade una representación que el texto plano no tiene: entidades y las relaciones entre ellas. Permite responder preguntas cuya respuesta no está en ningún chunk, sino entre varios.
Se mete un evaluador dentro del flujo: antes de responder se comprueba si hacía falta buscar, si lo recuperado sirve y si la respuesta se apoya de verdad en ello.
La diferencia práctica entre las tres no está en lo que mejoran, sino en cuándo se paga:
| Técnica | Coste de indexación | Coste por consulta | Qué mejora |
|---|---|---|---|
| Contextual RAG | Alto: una llamada al LLM por chunk | Normal | Chunks que se sostienen solos |
| Graph RAG | Alto: extracción de entidades por documento | Medio | Razonamiento sobre relaciones |
| Parent-Child | Bajo | Bajo | Precisión al buscar, contexto al responder |
| Self-RAG | Normal | Alto: varias evaluaciones por consulta | Fiabilidad |
Esa tabla ordena las decisiones mejor que cualquier comparación de calidad. Las dos primeras se pagan una vez por documento —y otra vez cada vez que reindexes—; la última se paga en cada pregunta, para siempre. Y Parent-Child es barato por los dos lados, lo que lo convierte en el primero que hay que probar casi siempre.
Coge diez consultas que tu RAG haya respondido mal y clasifica cada fallo con la tabla de la sección 01: ¿faltaba contexto en el chunk?, ¿la respuesta estaba repartida entre varios documentos conectados?, ¿lo recuperado no venía a cuento?
El recuento te dice qué familia implementar, y —más importante— cuáles no. Si nueve de diez fallos son de contexto, montar un grafo de conocimiento es meses de trabajo para arreglar el décimo.