PTENES
← Volver a la Ruta 3 MÓDULO 3.3

🧠 Arquitecturas híbridas: LLM Planner + VLA Executor

Ninguna red única razona sobre tareas de varios minutos Y controla actuadores a 200 Hz. La solución es dividir: un cerebro lento que piensa, una política rápida que actúa y el vínculo entre ambos.

6
Temas
~45
Minutos
Avanzado
Nivel
Teoría
Tipo

Contenido detallado

LLM PLANNER "limpia la mesa" descompone una tarea larga en subtareas viables COLA DE SKILLS 1. tomar un vaso 2. ponerlo en el fregadero 3. limpiar la superficie VLA EXECUTOR política reactiva ~200 Hz ejecuta 1 skill a la vez control continuo retroalimentación de fallas → volver a planificar (closed-loop)
1

🏗️ Jerarquía de control: simbólico × reactivo

La robótica clásica siempre separó planificación (alto nivel, abstracto, lento) de control (bajo nivel, continuo, rápido). Las arquitecturas híbridas modernas reencarnan esta jerarquía con componentes aprendidos: un modelo de razonamiento en la parte superior y una política reactiva en la base. El motivo es fundamental: las escalas de tiempo son incompatibles.

💡 El conflicto entre escalas de tiempo

Razonar «cómo guardar los platos» lleva segundos de inferencia en un VLM grande. Controlar un dedo exige decisiones cada ~5 ms. Forzar a una sola red a hacer ambas cosas da como resultado algo demasiado lento para el lazo de control o demasiado torpe para la tarea. La jerarquía desacopla las frecuencias.

Jerarquía

Planificar vs. controlar.

Planificación simbólica

Abstracto, discreto.

Política reactiva

Continua, rápida.

Desacoplamiento

Frecuencias separadas.

2

🐢🐇 System 1 / System 2 (Helix, GR00T)

La instancia más avanzada de la jerarquía es el sistema dual, tomando prestada la metáfora de Kahneman. El System 2 (VLM lento) razona y emite un vector latente de intención; el System 1 (política rápida) se condiciona con ese latente para generar acciones de alta frecuencia. Helix y GR00T convergieron en este diseño, que funciona asíncrono: S1 no espera a S2 en cada paso.

# Inferência assíncrona dual-system
latent = None
loop_S2 (~8 Hz):   latent = VLM(image, instruction)   # raciocínio
loop_S1 (~200 Hz): action = policy(obs, latent)       # controle
                   robot.step(action)
# S1 reusa o último latent enquanto S2 ainda pensa

📊 ¿Por qué el espacio latente y no el texto?

  • Banda ancha — un vector continuo transmite más matices que una cadena de skill discreta.
  • Diferenciable — permite entrenar S1 y S2 de forma acoplada cuando se desea.
  • Rápido — no hay análisis del lenguaje en el lazo de control.

Sistema dual

S2 piensa, S1 actúa.

Condicionamiento latente

S1 condicionado en z.

Inferencia asíncrona

Ciclos independientes.

Kahneman

Pensar lento × rápido.

3

📋 LLM como planificador: SayCan, Code-as-Policies

Antes del latente continuo, la primera ola de modelos híbridos usó el LLM como planificador simbólico. SayCan (Google, 2022) combinó la probabilidad del LLM ("say") con la viabilidad de cada skill ("can") para elegir el siguiente paso. Code-as-Policies fue más allá: el LLM escribe código que llama a APIs de percepción y control, con ciclos, condicionales y composición.

# Code-as-Policies — LLM gera o plano como programa
# instrução: "empilhe os blocos por cor"
for color in detect_colors():
    blocks = get_objects(color=color)
    base = blocks[0]
    for b in blocks[1:]:
        pick(b); place_on(base); base = b
# loops + lógica que uma lista plana de skills não expressa

💡 SayCan en una frase

score(skill) = P_LLM(la skill es útil para la tarea) × P_affordance(el robot puede ejecutar ahora). El «say» por sí solo sueña planes imposibles; el «can» los ancla en la realidad física.

SayCan

Decir × poder.

Code-as-Policies

El LLM escribe código.

Descomposición de tareas

Dividir en subtareas.

Prompting

Sin entrenar una nueva política.

4

🎯 Affordances y grounding

Un plan solo vale si es ejecutable. Affordance es la estimación de qué tan viable es una acción en el estado actual; grounding es el vínculo entre el lenguaje del planificador y las habilidades reales del robot. Sin esto, el LLM produce planes elocuentes e imposibles: pedirle que "agarre el vaso" cuando no hay ningún vaso a la vista.

✓ Hacer

  • ✓Usar una value function o detector como filtro de viabilidad.
  • ✓Grounding en percepción: ofrecer solo skills cuyos objetos existen en la escena.
  • ✓Restringir el vocabulario de skills a lo que domina el ejecutor.

✗ Evitar

  • ✗Confiar en el LLM puro para juzgar la viabilidad física.
  • ✗Planes abiertos sin anclarlos a los objetos/estado reales.
  • ✗Skills en el plan que el ejecutor nunca fue entrenado para realizar.

Affordance

Viabilidad de la acción.

Grounding

Lenguaje → skill real.

Value function

Filtro de viabilidad.

Viabilidad

El «can» de SayCan.

5

🔁 Memoria y feedback: volver a planificar tras un fallo

La ejecución a ciegas falla ante el primer imprevisto. Los sistemas robustos cierran el ciclo: detectan fallas, actualizan la memoria e vuelven a planificar. Técnicas como inner monologue retroalimentan al planificador con observaciones textuales («el vaso se resbaló»), que ajusta el plan. La robustez surge de la recuperación, no de una ejecución perfecta.

1

Detectar

Éxito/fallo por percepción (¿objeto en la mano? ¿superficie limpia?) o detector de éxito aprendido.

2

Retroalimentar (monólogo interno)

Convertir el resultado en feedback que el planificador consume en el siguiente paso.

3

Replanificar

Reescribir la cola de skills según el nuevo estado, en vez de seguir el plan original ya obsoleto.

⚡ Consejo práctico

No replantees en cada cuadro (es caro e inestable). Replantea en eventos: fin de una skill, fallo detectado o cambio importante en la escena. El resto del tiempo, deja que la política reactiva absorba por sí sola las pequeñas perturbaciones.

Closed-loop

Ciclo cerrado con feedback.

Monólogo interno

Comentarios textuales al planificador.

Replanificación

Reescribir el plan.

Memoria

Estado acumulado de la tarea.

6

⏳ Horizonte largo: composición de skills

El cuello de botella actual de la robótica generalista es el horizonte largo: tareas de varios minutos que encadenan decenas de skills. Incluso con un 95% de éxito por skill, 20 skills en serie dan ~36% de éxito total: el error compuesto que vimos en la Ruta 1 reaparece a escala de tarea. La híbrida lo aborda con replanificación y recuperación, pero la robustez de extremo a extremo sigue siendo una frontera abierta.

📊 Las matemáticas del error compuesto en tareas

  • 0.9520 ≈ 36% — éxito de la tarea con 20 skills al 95% cada una, sin recuperación.
  • 0.9920 ≈ 82% — por qué cada punto de success rate por skill importa enormemente.
  • Recuperación cambia el cálculo: replanificar convierte el fallo en un reintento, no en el fin de la tarea.

💡 Por qué la opción híbrida es la apuesta correcta aquí

Un VLA monolítico tiende a acumular drift en un horizonte largo. La jerarquía vuelve a inyectar estructura: el planificador mantiene el objetivo global mientras el ejecutor se ocupa de lo local, y el ciclo cerrado corrige las desviaciones antes de que se acumulen.

Long-horizon

Tareas de minutos.

Skill composition

Encadenar habilidades.

Error compuesto

Las fallas se multiplican.

Deriva

Desviación acumulada.

✅ Resumen del módulo

✓
Jerarquía de control — planificar y controlar tienen escalas de tiempo incompatibles; desacóplalas.
✓
Sistema dual — S2 lento emite latente, S1 rápido ejecuta, asíncrono (Helix, GR00T).
✓
Planificador LLM — SayCan y Code-as-Policies descomponen tareas largas sin entrenar una política nueva.
✓
Affordances + closed-loop — ancla los planes en la realidad y vuelve a planificar ante eventos de falla.
✓
Horizonte largo — el error acumulado es el cuello de botella; la recuperación es lo que vence a las matemáticas.

Próximo módulo

3.4 — Aplicaciones: manufactura, logística, salud, agro. Donde estas arquitecturas se convierten en valor de mercado.