El enrutamiento precede a la recuperación, no a la dimensión del embedding

El sondeo de junio de 2026 de KDnuggets sobre los fallos de la generación aumentada por recuperación reporta una empresa manufacturera global que presupuestó 400.000 USD para su sistema RAG, gastó 1,2 millones de USD en el primer año y terminó con un 23% de precisión en consultas de documentación técnica antes de cancelar el proyecto. El diagnóstico del artículo es estructural, no de ajuste: irrelevancia en la recuperación, envenenamiento del contexto y un conflicto de tamaño de fragmento que ninguna dimensión de embedding resuelve. Su prescripción son cuatro arquitecturas elegidas por tipo de consulta, con la frase decisiva: «el cambio clave es hacer explícito el enrutamiento. Cada consulta se clasifica antes de que se ejecute cualquier recuperación». (Nate Rosidi, KDnuggets, «Your RAG Pipeline Is Probably Useless. Here's a Better Alternative», publicado 2026-06-29, consultado 2026-08-23, https://www.kdnuggets.com/your-rag-pipeline-is-probably-useless-heres-a-better-alternative). El Honest Architect lee el texto como Theorem 3 aplicado a la recuperación: una propiedad (relevancia factual) se garantiza exactamente cuando su mecanismo (enrutamiento explícito antes de la recuperación) está implementado y midiendo — y añadir dimensiones de embedding a un diseño que carece de ese mecanismo hace el fallo más caro, no menos.

[UNIQUE INSIGHT]: La trampa de la sobreingeniería es Theorem 3 en miniatura. No se puede garantizar la relevancia factual añadiendo más de un mecanismo (embeddings de mayor dimensión, más reranking, recuperación en varios pasos) que no implementa la relevancia. La relevancia es una propiedad de enrutamiento — ¿pertenece esta consulta a este corpus, esta versión, este documento? — no una propiedad de similitud. Escalar el mecanismo equivocado acumula el coste sin producir la propiedad.

Conclusiones clave

• La irrelevancia en la recuperación es un fallo de mecanismo ausente. Theorem 3: la propiedad relevancia-factual se garantiza enrutando la consulta al corpus, versión y tipo de documento correctos antes de la recuperación, no por similitud vectorial. El artículo: una consulta sobre permiso parental devuelve la política de 2022, la de 2024 y un post cultural, todos altos en distancia de embedding, ninguno responde. Production ✅ para el diagnóstico.
• El envenenamiento del contexto es un fallo de mecanismo ausente. Theorem 3: la propiedad contradicción-expuesta se garantiza con enrutamiento de versiones más detección de contradicciones, no mezclando fragmentos. El artículo: cuando el recuperador devuelve versiones contradictorias, el modelo «elige una, mezcla ambas o presenta una síntesis segura» y «ni el usuario ni el modelo lo saben». Production ✅ para el diagnóstico.
• El conflicto de tamaño de fragmento es estructural, no ajustable. El recall necesita fragmentos de 100–256 tokens; la coherencia necesita 1024 o más. Ninguna dimensión de embedding resuelve un equilibrio donde las dos propiedades tiran del parámetro en direcciones opuestas. Production ✅ para la afirmación estructural.
• La sobreingeniería agrava el fallo. El artículo: una tasa de fracaso del 72% en el primer año para RAG empresarial en 2025, un desbordamiento de presupuesto de 400.000 a 1,2 millones de USD, 23% de precisión, 75.000 USD al mes en costes de base de datos vectorial al sexto mes en una empresa sanitaria. Añadir complejidad a un diseño de recuperación roto «aumenta los costes de cómputo y retrasa la pregunta más útil, que es si la arquitectura de recuperación era la correcta». Partial ⚠️ (cifras citadas de sondeos, no verificadas independientemente por Everythink).
• El enrutamiento precede a la recuperación. Self-Route (EMNLP 2024) clasifica si una consulta necesita contexto completo o recuperación enfocada antes de que se ejecute; mejoras de precisión del 15 al 30% reportadas para búsqueda híbrida y reranking. Theorem 3: la propiedad estrategia-correcta-por-consulta se garantiza clasificando antes de recuperar, no comprometiéndose con una estrategia al construir. Production ✅ para la forma; Partial ⚠️ para los porcentajes específicos.
• «The space is the router» es el mecanismo de enrutamiento aguas arriba que a RAG le falta. La topología network→community→room de Everythink enruta una pregunta al contexto correcto antes de que algo responda — la misma forma que Self-Route, un dominio aguas arriba. Partial ⚠️ (misma forma — enrutar-antes-de-responder — dominios separados).
• Alcance: civil/defensivo. La arquitectura de recuperación es infraestructura civil. No se promete ningún resultado de token, wallet ni community-credit; esos son Roadmap 🔵, revisión Howey pendiente. Everythink es una plataforma de pronóstico, no un proveedor de RAG; los paralelismos transversales son ilustraciones Partial ⚠️, no respaldos de KDnuggets, StrataScratch, Microsoft GraphRAG ni ninguna herramienta específica.

Cuando RAG falla: la propiedad no está garantizada

El artículo abre con el fallo que las demos ocultan. Un usuario pregunta por el permiso parental. El recuperador devuelve la versión de 2022, la de 2024 y un post cultural. Cada fragmento puntúa alto en distancia de embedding porque comparte vocabulario con la consulta. Ninguno responde la pregunta. El modelo no sabe que el contenido recuperado está desactualizado o fuera de tema; mezcla los fragmentos en una respuesta segura, detallada y factualmente errónea. El artículo llama a esto «similitud tópica sin relevancia factual, y es el modo de fallo dominante en los sistemas RAG en producción».

El Honest Architect lee esto como Theorem 3. La propiedad es relevancia-factual. El mecanismo que implementa el sistema es similitud-vectorial, que garantiza la-pregunta-se-parece-a-la-respuesta, no relevancia-factual. Las dos coinciden cuando el corpus es pequeño, actual y de versión única — el caso de la demo. Divergen cuando el corpus contiene múltiples versiones, coincidencias de vocabulario fuera de tema y contradicciones. El sistema afirma relevancia recuperando fragmentos similares; el mecanismo no implementa relevancia, así que la propiedad no está garantizada. Production ✅ para el diagnóstico.

El fallo más sutil, el envenenamiento del contexto, tiene la misma forma. Las bases de conocimiento empresariales guardan la misma política en múltiples versiones. El recuperador devuelve fragmentos de ambas. El modelo «no expone la contradicción. Elige una, mezcla ambas o presenta una síntesis segura. El lector obtiene una respuesta. La respuesta puede ser errónea. Ni el usuario ni el modelo lo saben». La propiedad es contradicción-expuesta. El mecanismo es mezclar-y-sintetizar. Ningún mecanismo detecta la contradicción, así que la propiedad no está garantizada. El sistema produce una respuesta; no produce una respuesta verificadamente correcta. Production ✅.

[PERSONAL EXPERIENCE]: Construyendo el HAI Engine desde 2016, aprendimos la misma lección en otro dominio. Un pronóstico no se hace relevante calculándolo sobre más datos; se hace relevante enrutando la pregunta a la sala correcta — la comunidad correcta, el contexto delimitado correcto — antes de que cualquier modelo se ejecute. Escalar el modelo sobre el contexto equivocado produce un pronóstico seguro, detallado y fuera de objetivo, igual que escalar embeddings sobre los fragmentos equivocados produce una respuesta segura, detallada y fuera de objetivo. El mecanismo que produce relevancia es el enrutamiento, no el volumen. Production ✅.

La trampa de la sobreingeniería es Theorem 3 en miniatura

La sección más útil del artículo es la que los ingenieros omiten. Cuando el RAG estándar rinde por debajo, la solución común es complicarlo más: embeddings de mayor dimensión, reranking más sofisticado, recuperación en varios pasos. El veredicto del artículo: «Esto agrava el problema».

Los datos son contundentes. Una empresa manufacturera global presupuestó 400.000 USD, gastó 1,2 millones en el primer año, terminó con un 23% de precisión y canceló el proyecto. Una empresa sanitaria alcanzó 75.000 USD al mes en costes de base de datos vectorial al sexto mes. El artículo cita una tasa de fracaso del 72% en el primer año para implementaciones RAG empresariales en 2025. El Honest Architect lee esto como el coste de escalar el mecanismo equivocado. Los embeddings de mayor dimensión implementan similitud más fina, no relevancia-factual. El reranking implementa reordenación, no contradicción-expuesta. La recuperación en varios pasos implementa recuperar-luego-recuperar-otra-vez, no enrutar-antes-de-recuperar. Cada uno añade cómputo a un diseño que sigue sin el mecanismo ausente, así que la propiedad sigue sin garantizarse mientras la factura crece. Partial ⚠️ en las cifras (citadas de sondeos, no verificadas independientemente por Everythink); Production ✅ en la forma — escalar un mecanismo que no implementa la propiedad no puede producir la propiedad.

Esto es Theorem 3 en miniatura. Una propiedad se garantiza exactamente cuando su mecanismo está implementado y midiendo. La relevancia es la propiedad. El enrutamiento antes de la recuperación es el mecanismo. La dimensión del embedding es otro mecanismo, que mide otra propiedad. No se puede comprar relevancia con dimensiones de embedding, igual que no se puede comprar resistencia al fuego con grosor de pintura. La frase del artículo — «aumenta los costes de cómputo y retrasa la pregunta más útil, que es si la arquitectura de recuperación era la correcta» — es la versión operativa del teorema. Production ✅.

El artículo también nombra un conflicto estructural que ningún ajuste resuelve: el recall necesita fragmentos pequeños (100–256 tokens), la coherencia necesita grandes (1024 o más), y cada diseñador de RAG elige uno y acepta el equilibrio. El Honest Architect lee esto como el límite del mecanismo fragmentar-embeber-recuperar — no un problema de ajuste sino de selección de mecanismo. Las cuatro alternativas no son parches sobre ese conflicto; son mecanismos distintos, cada uno garantizando una propiedad distinta para un tipo de consulta distinto. Production ✅ para el encuadre; los nombres de herramientas (Self-Route, GraphRAG) son Partial ⚠️ (reportados en investigación, no verificados independientemente por Everythink).

Las cuatro alternativas son enrutamiento según la situación

Contexto largo: omitir la recuperación cuando el corpus cabe

La primera alternativa del artículo es omitir la recuperación por completo. Si el corpus cabe en la ventana de contexto del modelo, cárguelo y deje que el modelo lea. Un benchmark (arXiv 2501.01880) halló que los LLM de contexto largo superaban consistentemente al RAG en tareas de QA cuando había cómputo disponible, con la recuperación basada en fragmentos quedando última. El equilibrio de coste es real: con 1M de tokens, la latencia es 30 a 60 veces más lenta que un pipeline RAG, a aproximadamente 1250 veces el coste por consulta; el cacheo de prompts puede hacer el contexto largo competitivo en coste para aplicaciones de alto tráfico. La regla de decisión: si el corpus cabe en la ventana y el volumen de consultas es moderado, el contexto largo es el punto de partida más limpio; añada recuperación solo cuando el corpus exceda la ventana, la latencia viole los SLO o el volumen cruce el punto de equilibrio. Theorem 3: la propiedad respuesta-de-contexto-completo se garantiza cargando todo el corpus, no recuperando fragmentos de él. La decisión de enrutamiento (¿cabe este corpus?) precede a la elección de arquitectura. Production ✅ para la forma; Partial ⚠️ para los multiplicadores de coste.

Compresión de memoria: resumir antes de recuperar

Cuando el corpus es demasiado grande para la ventana, la segunda alternativa del artículo es resumir antes de recuperar en lugar de extraer fragmentos crudos. La recuperación basada en resúmenes rinde de manera comparable a los métodos de contexto largo completo, mientras que la basada en fragmentos queda por detrás. Un resultado concreto: un enfoque RAG que preserva el orden usando 48K tokens bien elegidos superó a la recuperación de contexto completo a 117K tokens por 13 puntos F1, a un séptimo del presupuesto de tokens. Theorem 3: la propiedad contexto-relevante-en-presupuesto se garantiza comprimiendo a relevancia antes de inyectar, no recuperando fragmentos crudos y esperando que el modelo filtre. Un documento relevante bien comprimido vence a un volcado crudo de fragmentos tangencialmente relacionados. Production ✅ para la forma; Partial ⚠️ para la cifra de 13 puntos F1 (estudio único).

Recuperación estructurada: clasificar la consulta antes de que se ejecute la recuperación

La tercera alternativa del artículo es la que se mapea más directamente al mecanismo ausente. Cuando la recuperación es la arquitectura correcta, la solución es enrutar por tipo de consulta en lugar de aplicar mejores embeddings uniformemente. Self-Route, presentado en EMNLP 2024, deja que el modelo clasifique si una consulta necesita contexto completo o recuperación enfocada antes de ejecutarla. Las búsquedas factuales simples van a RAG enfocado. Las preguntas multihop complejas van a un contexto largo. El resultado: mejor precisión global a menor coste computacional. Los sistemas adaptativos que usan este enfoque híbrido han mostrado mejoras del 15 al 30% en precisión de recuperación mediante búsqueda híbrida y reranking. La frase decisiva del artículo: «El cambio clave es hacer explícito el enrutamiento. Cada consulta se clasifica antes de que se ejecute cualquier recuperación, y el sistema deja de tratar todas las consultas como problemas idénticos de embedding».

Theorem 3: la propiedad estrategia-correcta-por-consulta se garantiza con el mecanismo (clasificar la consulta, luego recuperar), no comprometiéndose con una estrategia al construir. La clasificación es la medición; el enrutamiento es el mecanismo. El sistema que clasifica antes de recuperar implementa la propiedad; el que recupera-y-luego-espera no. Production ✅ para la forma; Partial ⚠️ para los porcentajes específicos.

[ORIGINAL DATA]: El Honest Architect nota el paralelismo estructural entre el clasificar-antes-de-recuperar de Self-Route y el «the space is the router» de Everythink. Self-Route clasifica la consulta y luego enruta a una estrategia de recuperación. Everythink enruta la pregunta a una sala — network→community→room — antes de que cualquier modelo se ejecute. Ambos implementan la propiedad relevancia enrutando antes de responder, no emitiendo y filtrando. La diferencia es de dominio y alcance: Self-Route enruta dentro de un sistema de recuperación; «the space is the router» enruta a través de toda una red de contextos delimitados. Partial ⚠️ (misma forma — enrutar-antes-de-responder — dominios separados).

Basado en grafos: enrutar consultas relacionales a un grafo

La cuarta alternativa del artículo es para consultas que requieren entender relaciones a través de un conjunto de datos en lugar de recuperar un pasaje. Estas son las preguntas multihop: ¿qué decisiones revirtió la junta en Q3 y cuál fue la razón declarada cada vez? Ningún fragmento responde esto; la respuesta vive en las conexiones entre documentos. Microsoft Research introdujo GraphRAG en 2024: construya un grafo de conocimiento del corpus, recorra las relaciones de entidades en lugar de comparar vectores. El equilibrio es de coste — la extracción del grafo de conocimiento cuesta 3 a 5 veces más que el RAG de referencia y requiere ajuste específico del dominio — vale la pena para análisis temático y razonamiento multihop, no para búsquedas factuales de un solo pasaje. Theorem 3: la propiedad relaciones-entre-documentos se garantiza con entidades más relaciones tipadas, recorridas, no por similitud vectorial. Production ✅ para la forma; Partial ⚠️ para los multiplicadores de coste. Un tratamiento más profundo de las formas de mecanismo de GraphRAG aparece en nuestro texto anterior sobre hacer coincidir el mecanismo con el tipo de consulta.

The space is the router — el mecanismo que a RAG le falta

Las cuatro alternativas convergen en un mecanismo: enrute antes de recuperar. El contexto largo enruta por tamaño de corpus. La compresión de memoria enruta por presupuesto. La recuperación estructurada enruta por tipo de consulta. La basada en grafos enruta por estructura relacional. Cada una es una decisión de enrutamiento tomada antes de que el mecanismo de recuperación se ejecute, y cada una garantiza su propiedad porque el enrutamiento coincide con la forma real de la consulta.

El «the space is the router» de Everythink es el mismo mecanismo, un dominio aguas arriba. La topología network→community→room enruta una pregunta al contexto delimitado correcto antes de que algo responda. Una pregunta hecha en una sala sobre la lógica de reintentos de pagos ya está enrutada a la comunidad de pagos, la red de ingeniería, el alcance de documento relevante — antes de que cualquier Sister redacte, antes de que el Oracle fusione, antes de que cualquier recuperación se ejecute. El enrutamiento es estructural, no calculado en tiempo de consulta. La propiedad relevancia se garantiza por la topología, no emitiendo la pregunta a toda la red y filtrando las respuestas. Production ✅ para la forma (el HAI Engine ha ejecutado este enrutamiento en producción desde 2016); Partial ⚠️ para la afirmación transversal.

El Honest Architect no afirma que «the space is the router» sea un sistema de recuperación. Everythink es una plataforma de pronóstico, no un proveedor de RAG. La afirmación es estructural: el mecanismo ausente en los pipelines RAG fallidos es el enrutamiento explícito antes de la recuperación, y ese mecanismo tiene un análogo probado en producción en la topología de Everythink. El pipeline Sisters-to-Oracle es el análogo aguas abajo del map-reduce del artículo: cada Sister redacta en paralelo (la etapa map), el Oracle las fusiona en un Ensemble normalizado con entropía en cada fusión (la etapa reduce), y la propiedad pronóstico-calibrado se garantiza por el mecanismo, no por un modelo que produce todo el pronóstico. Partial ⚠️ (misma forma — redacción-en-paralelo-más-fusión-medida — dominios separados).

Preguntas frecuentes

¿RAG es inútil, como dice el titular?

No, y el artículo no argumenta eso. Argumenta que RAG es un valor por defecto razonable que falla de formas predecibles — irrelevancia en la recuperación, envenenamiento del contexto, el conflicto de tamaño de fragmento — y que la solución es enrutar por tipo de consulta, no sobreingeniar los embeddings. El mecanismo debe coincidir con la propiedad. Production ✅ para el diagnóstico; el encuadre de «inútil» es editorial.

¿Por qué añadir dimensiones de embedding no arregla la irrelevancia en la recuperación?

Porque las dimensiones de embedding implementan similitud, no relevancia. La irrelevancia en la recuperación es un fallo de enrutamiento ausente: la consulta devuelve coincidencias de vocabulario que no responden la pregunta. Escalar el mecanismo equivocado acumula el coste sin producir la propiedad. Theorem 3: la relevancia-factual se garantiza enrutando antes de recuperar, no con similitud más fina. Production ✅.

¿Cuál es el mecanismo de enrutamiento que a RAG le falta?

Clasificación explícita antes de la recuperación. Self-Route clasifica si una consulta necesita contexto completo o recuperación enfocada antes de que se ejecute cualquier recuperación. La propiedad estrategia-correcta-por-consulta se garantiza clasificando-luego-recuperando, no comprometiéndose con una estrategia al construir. Production ✅ para la forma.

¿Cómo se relaciona «the space is the router»?

Es la misma forma, un dominio aguas arriba. La topología network→community→room de Everythink enruta una pregunta al contexto delimitado correcto antes de que cualquier modelo se ejecute, igual que Self-Route enruta una consulta a la estrategia de recuperación correcta antes de que la recuperación se ejecute. Ambos implementan relevancia enrutando antes de responder. Partial ⚠️ (misma forma — enrutar-antes-de-responder — dominios separados). Everythink es una plataforma de pronóstico, no un proveedor de RAG.

¿Everythink respalda GraphRAG o alguna herramienta de recuperación?

No. Everythink es una plataforma de pronóstico. Las cifras del artículo son Partial ⚠️. Los paralelismos transversales son ilustraciones, no respaldos. El alcance es civil/defensivo. No se promete ningún resultado de token, wallet ni community-credit; esos son Roadmap 🔵, revisión Howey pendiente.

Sources

• Nate Rosidi, KDnuggets, «Your RAG Pipeline Is Probably Useless. Here's a Better Alternative», publicado 2026-06-29, consultado 2026-08-23, https://www.kdnuggets.com/your-rag-pipeline-is-probably-useless-heres-a-better-alternative

Si su equipo está listo para enrutar antes de recuperar — para clasificar la consulta antes de que cualquier embedding se ejecute, igual que the space is the router clasifica la pregunta antes de que cualquier Sister redacte — leed the 21 papers o reservad una demo. El HAI Engine ha ejecutado ese mecanismo de enrutamiento en producción desde 2016; las Sisters redactan en paralelo, el Oracle fusiona con entropía en cada ejecución, y Theorem 3 se cumple: la propiedad se garantiza exactamente cuando su mecanismo está implementado y midiendo.