La demostración que engañó a tu CEO no es el sistema que tendrías que enviar
El resumen reciente de HuggingFace sobre simulación para IA física admite silenciosamente lo que los ojos de tu CEO pierden: la transferencia sim-to-real aún requiere datos etiquetados masivos y ajuste específico del dominio. La brecha entre una simulación fotorrealista ejecutando Atlas o un cuadrúpedo y un sistema que sobrevive su primera tarea del mundo real es arquitectónica, no solo un problema de datos.
Ese carrete de Boston Dynamics—parkour impecable, agarre preciso, recuperación elegante—prepara a los líderes de ingeniería para hacer la pregunta equivocada. Lo ven y piensan: "Eso está cerca de ser enviable. Solo necesitamos un simulador mejor, quizás algo de ajuste fino." Lo que no están viendo son miles de horas de entrenamiento de políticas específicas del dominio, las restricciones de seguridad hechas a mano, la configuración de recompensas específica de la tarea. Más importante aún, no están viendo la brecha entre un bucle de razonamiento diseñado para lenguaje y un bucle de control que tiene que mover átomos.
La ilusión es que un simulador de última generación más un planificador LLM es igual a un agente encarnado enviable. No lo es. La cosa que no se portará desde tu pila de agentes de texto—la parte de la que estás más orgulloso—es exactamente la parte que falla más duramente cuando las consecuencias se vuelven físicas: tu bucle de razonamiento, tu arnés de evaluación, tus patrones de observabilidad. Esos fueron construidos sobre suposiciones que las tareas encarnadas violan violentamente.
Tu bucle de razonamiento asume que los reintentos son gratis — la física no está de acuerdo
El patrón ReAct y sus descendientes funcionan porque asumen llamadas de herramientas idempotentes y reversibles. Si una llamada a API falla o un plan LLM se va de lado, reintentas con temperature=0.2, ajustas el prompt, llamas a la herramienta de nuevo. El costo sube. La latencia sube. Eventualmente tienes éxito. Esto funciona para agentes de texto porque el razonamiento y la recuperación son ambos gratis.
En tareas encarnadas, un agarre fallido no es un timeout 429. Es una taza rota, una articulación atascada, una pila volcada. No hay reintento. Un segundo intento de la misma acción con temperatura más baja no arregla una carga caída—solo la deja caer de nuevo. El momento en que tus llamadas de herramientas se vuelven irreversibles, toda tu arquitectura de agentes necesita cambiar.
Por eso la "pregunta de agente vs. flujo de trabajo se vuelve a litigar el momento en que las acciones se vuelven irreversibles." En tareas digitales, puedes permitirte dejar que el LLM explore y reintente. En tareas físicas, no puedes. Necesitas patrones de intentos presupuestados: comprobaciones de precondiciones antes de cada acción, lógica de ramificación para abortar-versus-recuperar, límites duros en cuántas veces tocarás el mismo objeto. Tu bucle de planificación no puede ser especulativo más. Tiene que ser conservador.
Si envías sin rediseñar esto, enviarás un agente que suena confiado mientras destruye hardware.
Pisos de latencia: 200ms está bien para chat, fatal para un bucle de control
Un turno típico de planificador LLM en producción se ejecuta 400–1500ms en P50, peor en P99 cuando incluyes llamadas de herramientas y procesamiento de visión. Eso es aceptable para un agente de chat orientado al cliente. Es catastrófico para control encarnado.
Los bucles de control quieren 10–100Hz—eso es un presupuesto de 10–100ms incluyendo detección, planificación y actuación. Un enfoque LLM-en-el-bucle que toca los comandos del motor cada 500ms no está planificando manipulación de grano fino. Apenas está planificando en absoluto. Terminas con movimiento entrecortado e inseguro que falla en tareas ricas en contacto.
La solución es jerárquica: un planificador LLM lento que establece objetivos de alto nivel (p. ej., "recoge el objeto azul"), una política aprendida que se ejecuta a 10–50Hz, y un bucle PID rápido que ejecuta los servos a 100Hz+. Los LLMs de difusión y la decodificación especulativa ayudan con la latencia del planificador, pero no resuelven la actuación. El impuesto de tokenización de visión cuando añades fotogramas de cámara al planificador puede empujarte más allá de tu presupuesto de latencia antes de que hayas hecho ningún razonamiento en absoluto.
Si no escribes un presupuesto de latencia el primer día, descubrirás esta limitación cuando tu primera prueba real se atasque durante 2 segundos a mitad del alcance y el brazo se quede flácido.
Tu arnés de evaluación mide los fallos equivocados
Las evaluaciones de agentes de lenguaje (pass@k, precisión de LLM-como-juez en llamadas de herramientas) capturan el éxito de la tarea. Pierden completamente los modos de fallo que importan en sistemas encarnados: casi-fallos, trayectorias entrecortadas, estados inseguros, y la cola donde tu robot daña hardware.
La evaluación sim-to-real necesita cobertura distribucional: aleatorización de dominio a través de formas de objetos, materiales, condiciones de iluminación; dinámicas de contacto que coincidan con el simulador real; ruido de sensor que coincida con tu hardware real. Solo la tasa de éxito oculta el 2% de episodios donde el gripper se atasca y hace saltar un disyuntor. Necesitas invariantes por paso—límites de fuerza, límites de ángulo de articulación, geovallas—no solo comprobaciones de estado final. Una tarea puede ser "exitosa" y aún así doblar el robot de formas que acorten su vida útil.
Portar un arnés de evaluación estilo RAG a tareas encarnadas es una reescritura completa, no una refactorización. Tu evaluación RAG alcanza 0.9 de recuperación en el laboratorio y muere en producción por razones similares: estás midiendo la cosa equivocada. Para agentes físicos, el laboratorio *es* la simulación, y tu arnés de evaluación tiene que exponer dónde la sim diverge de la realidad.
Observabilidad construida para tokens se queda ciega en torque
Trazas de tokens, tramos de llamadas de herramientas, diffs de prompts—los patrones de observabilidad que usas para agentes de lenguaje—explican razonamiento pero no fallo. No te dicen por qué el robot dejó caer el objeto. Una política de agarre fallida se ve idéntica a un plan LLM malo en tu dashboard actual. Obtienes un tramo etiquetado "execute_grasp: failure", y no tienes idea de si el problema fue percepción, planificación, control o física.
Qué registrar en su lugar: marcas de tiempo de sensor (cuándo llegó el fotograma de cámara, qué tan fresco), comandos de actuador (punto de ajuste de posición, posición real, fuerza), confianza de política (¿es esta una acción de baja confianza?), deltas sim-versus-real (¿se comportó el objeto como se esperaba?). La depuración de reproducción para sistemas encarnados necesita el búfer de observación completo—no solo el rastro de razonamiento, sino cada fotograma de cada cámara, cada lectura de articulación, cada sensor de fuerza en la ventana alrededor del fallo.
La granularidad de cache-reason-log necesita extenderse a la percepción. ¿Por qué este fotograma fue clasificado como agarrable cuando en realidad es un reflejo? Esa no es una pregunta que tu observabilidad actual pueda responder. Un sistema de IA física en producción necesita registros de percepción por fotograma con puntuaciones de confianza, probabilidades de clase, y las características que desencadenaron la decisión. El incidente de las 2am donde todo se ve bien en tu dashboard pero el robot sigue fallando el mismo agarre te está esperando si no construyes esto ahora.
El patrón de observabilidad que tus agentes necesitan tiene que ser rediseñado desde cero para señales encarnadas.
Lo que realmente construiríamos primero si un cliente pidiera un piloto de IA física
Comienza con una tarea estrecha y reversible. No "recogida de contenedor completo"—algo como "coloca un cubo de espuma en una zona marcada" donde el fallo no destruye equipo y donde puedes ejecutar 100 pruebas al día sin supervisión. Escribe tu presupuesto de latencia en milisegundos antes de elegir un simulador. Comprométete con una pila jerárquica desde el primer día: no dejes que el LLM toque actuadores directamente.
Instrumenta el simulador con el esquema de observabilidad que planeas usar en producción. Si vas a registrar fuerza-torque y marcas de tiempo de fotograma en el mundo real, regístralos en sim. Ejecuta unos pocos cientos de pruebas y examina las brechas. Define tu taxonomía de fallos antes de medir tasas de éxito: qué se rompe, qué se recupera de forma segura, qué es irrecuperable. Esa categorización impulsa todo—precondiciones, lógica de reintento, restricciones de seguridad.
Presupuesta para una reescritura completa del arnés de evaluación. No portes tu suite de pruebas de agentes de texto. Aleatorización de dominio, simulación de contacto, ruido de sensor—si no estás midiendo estos en sim, no vas a saber cuándo estás listo para hardware. Los equipos que pierden más tiempo son los que enviaron una política basada en sim que funcionaba y asumieron que se transferiría.
Avanzando
Si estás definiendo el alcance de un piloto de IA física en los próximos dos trimestres, escribe tu presupuesto de latencia y taxonomía de fallos antes de elegir un simulador. Cuanto más rápidos se vuelven los simuladores, más urgente se vuelve esto—las demostraciones mejores hacen que los equipos se confíen demasiado pronto. Si quieres un segundo par de ojos en ese documento antes de comprometer tiempo de ingeniería, hablemos.