Serie: Aprender a programar con IA

Construido para recibir dirección de ChatGPT, Claude y Gemini

Cualquier LLM en la nube dirigiendo el runtime a través de un solo servicio asistente.

Construido para recibir dirección de cualquier modelo Tokens de intención como entrada de control, en el paso de simulación, en cada fotograma ChatGPT Claude Gemini XRAssistantService protocolo de intención agnóstico al modelo Paso de simulación del runtime pipeline de voz · mirada · acciones se actúa sobre ello continuamente, en vuelo
No un chatbot pegado a la RA: el flujo de intención del modelo como entrada de control de primera clase.

La era de "este producto corre sobre el modelo de ese único proveedor" es breve. RakuAI está construido para que cualquier modelo (ChatGPT, Claude, Gemini o el tuyo) pueda dirigir una experiencia de RA en tiempo real. Trae el mejor modelo. El runtime está listo.

La mayoría de los motores de juego que hoy se integran con un LLM en la nube lo hacen de la manera que esperarías. Un modelo se atornilla al editor como un panel de chat. Escribes en el panel de chat. El panel escribe algún contenido o algún código. El runtime, que no tiene idea de que nada de esto ocurrió, ejecuta el artefacto resultante más tarde.

Eso no es lo que hace Raku. Raku se está construyendo para recibir dirección de un LLM en la nube como un asunto del runtime, no como una conveniencia de autoría. El trabajo de este fin de semana lo hizo explícito.

Qué se completó

Ciento dieciocho commits en el runtime este fin de semana. Las piezas principales:

  • Un XRAssistantService que conecta las respuestas del LLM en la nube al pipeline de voz como una función de runtime de primera clase
  • Renderizado foveado por seguimiento ocular con optimización de rendimiento multi-perfil
  • Un proveedor OpenXR XR_EXT_eye_gaze_interaction
  • Seguimiento de manos y reconocimiento de gestos para el runtime de XR
  • Seguimiento de cuerpo completo con un esqueleto de 71 articulaciones
  • Detección de fijación y temporizadores de permanencia en la infraestructura de seguimiento ocular
  • Passthrough de alta resolución, sensado de profundidad y estimación de iluminación
  • Un pipeline de renderizado descargado por Wi-Fi 7 con un servidor host y monitoreo de latencia
  • Un canal de deltas de baja latencia para sincronización de pose y estado en RA multijugador en tiempo real
  • Servicio de anclaje submilimétrico para Android XR
  • Puente de sensores ARCore para dispositivos Android sin la pila de Android XR
  • Un compositor de HUD multicapa y una API de superposición
  • Ejemplos de AR Surface Demo y Room Visualizer para comprensión de escena

Unas cuantas de estas merecen destacarse. El pipeline de renderizado descargado por Wi-Fi 7 es una. El XRAssistantService es la otra. Ambas tienen forma de cebo de asociación.

El XRAssistantService y para qué sirve en realidad

El XRAssistantService es la pieza de ingeniería más limpia con forma de cebo de asociación que hemos lanzado hasta la fecha. Su forma:

El runtime tiene un pipeline de voz. El usuario habla. La conversión de voz a texto corre localmente en el dispositivo con baja latencia. El texto se transmite al servicio asistente. El servicio asistente entrega el texto a un LLM en la nube. El LLM en la nube transmite de vuelta tokens que representan intención: qué debería hacer la experiencia de RA a continuación dado lo que dijo el usuario. El runtime analiza ese flujo y lo convierte en acciones de runtime en vuelo. La conversión de texto a voz para la respuesta también se transmite.

La pieza que quiero que los constructores y los laboratorios noten es que el LLM no se invoca una vez por turno del usuario. El pipeline de voz puede seguir transmitiendo tokens al modelo durante un turno (con el soporte de backend adecuado), y el modelo puede seguir produciendo intención sobre la que el runtime actúa continuamente. Eso es lo que realmente significa “recibir dirección de un LLM en la nube como un asunto del runtime.” No es un chatbot pegado a una experiencia de RA. Es el runtime tratando el flujo de intención del modelo como una entrada de control con la misma prioridad que la mirada del usuario.

La interfaz es agnóstica al modelo por diseño. ChatGPT puede dirigir esto. Claude puede dirigir esto. Gemini puede dirigir esto. Un modelo pequeño en el dispositivo puede dirigir esto. Cualquier cosa que produzca un flujo de tokens de intención que se ajuste al protocolo del servicio asistente puede dirigir esto. La pieza que construimos este fin de semana es la capa de integración entre cualquiera de esos modelos y el resto del runtime.

Si estás en uno de esos laboratorios y estás leyendo esto: esta es la integración sobre la que queremos hablar contigo. No queremos una asociación especial donde tu modelo sea el único modelo con el que el motor puede hablar. Queremos que tu modelo sea el mejor modelo con el que el motor puede hablar, porque la integración es abierta y la experiencia que produzca tu modelo será mejor que la experiencia que produzca el modelo de cualquier otro.

El pipeline de renderizado descargado por Wi-Fi 7

Esta es la otra pieza con forma de asociación. Las gafas de RA tienen una envolvente térmica. La envolvente térmica es pequeña. La envolvente de cómputo dentro de esa envolvente térmica es más pequeña de lo que algunas experiencias quieren renderizar. La respuesta tradicional es comprometer la experiencia. La respuesta de Wi-Fi 7 es renderizar parte del fotograma en una caja de cómputo enlazada (un teléfono, un beltpack, un escritorio en la misma habitación) y transmitir el resultado.

Este fin de semana el pipeline de renderizado descargado se completó de principio a fin. El servidor host corre en cualquier lugar. El runtime en las gafas habla con el host por Wi-Fi 7. La latencia de fotogramas se monitorea y el runtime puede degradarse con elegancia al renderizado local cuando el enlace falla, lo cual hará.

Por qué esto importa para los socios: significa que un socio de hardware no tiene que poner una GPU de clase escritorio en las gafas para lanzar una experiencia de clase escritorio. El cómputo puede estar donde el cómputo sea más barato. El enlace es lo que importa. Estamos construyendo el runtime alrededor del enlace.

El andamiaje de OpenXR

Un buen número de los commits de este fin de semana estuvieron al servicio de la conformidad con OpenXR. XR_EXT_eye_gaze_interaction. Seguimiento de manos. Patrones de proveedor para ARKit y ARCore. La razón por la que OpenXR importa en este código es que es la capa en la que queremos que este motor sea portable entre socios de hardware. Si un socio de hardware lanza un runtime conforme con OpenXR, este motor puede lanzarse sobre él. Las interfaces que estamos construyendo este mes están deliberadamente del lado de los estándares en lugar del lado específico de proveedor, porque así es como el motor se mantiene neutral.

Honestos sobre lo que no está terminado

Unas cuantas cosas se completaron este fin de semana como trabajo en curso. El PR de seguimiento de manos en concreto todavía está conectado de forma incompleta. Hay un error de enlazado de PoseStabilizer que estamos arreglando en un seguimiento posterior. El seguimiento ocular tiene detección de fijación pero la integración del temporizador de permanencia con la capa de aplicación no está terminada. El seguimiento de cuerpo completo está incluido pero las piezas de reconocimiento de gestos todavía necesitan más muestras.

Quiero ser claro sobre esto porque el patrón del trabajo de desarrollo impulsado por agentes es que mucho trabajo en curso se completa en la misma semana, y el trabajo en curso se nombra explícitamente en los títulos de los PRs. Si lees el registro de commits de este fin de semana y ves “[WIP]” en algunos lugares, es a propósito. Los entregables completos se juntan en las próximas dos semanas.

Lo que quiero que los socios y constructores se lleven de esto

Si eres un laboratorio de IA construyendo el próximo modelo importante y te importa un runtime de RA que trate la salida de tu modelo como una entrada de control en el paso de simulación, habla conmigo. La capa de integración del XRAssistantService se está lanzando en este motor en noviembre de 2025 y será una interfaz estable para conectarse antes de fin de año.

Si eres un socio de hardware construyendo gafas de RA con Wi-Fi 7 integrado y una historia de cómputo externo, el pipeline de renderizado descargado es exactamente la carga de trabajo para la que se construyó tu hardware. El runtime está listo para ello.

Si eres un desarrollador pensando en qué tipos de experiencias te permitirá construir este motor, la respuesta empieza a ser visible en el registro de commits. Las experiencias de RA dirigidas por voz que responden al usuario a mitad de frase son alcanzables. La RA multijugador en tiempo real con anclaje submilimétrico es alcanzable. El cómputo que necesitas para cualquiera de las dos vive en las gafas o en el enlace, dependiendo de lo que necesite tu experiencia.

Ciento dieciocho commits, gran fin de semana. El motor se ve diferente el domingo por la noche de como se veía cuando se abrió el portátil el sábado.

Tu modelo pertenece al paso de simulación

El XRAssistantService de RakuAI es una interfaz agnóstica al modelo para transmitir intención a una experiencia de RA en vivo. Si construyes modelos de frontera, esta es la integración sobre la que queremos hablar contigo.

← Todas las entradas