Real-time chunking: cómo trocear datos vivos para RAG sin perder contexto

El chunking en tiempo real no consiste en partir texto más rápido. Consiste en convertir flujos incompletos en memoria consultable sin romper orden, causa ni contexto.

Real-time chunking es una familia de técnicas para dividir una secuencia viva en unidades ejecutables o recuperables mientras el mundo sigue avanzando. En IA aplicada aparece en dos contextos distintos: sistemas RAG que trocean datos en streaming y modelos de robótica que generan chunks de acciones para actuar sin pausas.

La diferencia crítica está en el coste del error. Un chunk de texto mal cortado produce una respuesta pobre. Un chunk de acciones incompatible puede producir una trayectoria brusca, acelerar de forma insegura o fallar una manipulación física.

RTC en robótica: pensar mientras se mueve

Physical Intelligence presentó Real-Time Action Chunking como una estrategia para vision-language-action models. Estos modelos pueden generar secuencias de acciones, pero son pesados y tienen latencia. Si el robot espera a que termine cada inferencia antes de moverse, aparecen pausas. Si cambia ingenuamente de un chunk de acciones a otro mientras está en movimiento, puede haber discontinuidades peligrosas.

La idea central de RTC es ejecutar parte del chunk anterior mientras el modelo calcula el siguiente. Cuando el nuevo chunk llega, no puede ignorar lo ya comprometido: algunos timesteps ya ocurrieron y otros se solapan con acciones pendientes. RTC formula ese empalme como un problema de inpainting: congela el prefijo de acciones que ya están determinadas y rellena el resto de forma compatible con la trayectoria actual.

Ese detalle es importante porque muestra que real-time chunking no es solo batch size. Es consistencia entre chunks bajo latencia. En el artículo de Physical Intelligence, RTC permite ejecución en tiempo real con modelos VLA sin cambios de entrenamiento, y reportan robustez incluso con retrasos artificiales superiores a 300 ms en tareas de precisión como encender una cerilla o conectar un cable Ethernet.

La unidad correcta no siempre es texto

En real-time chunking, el chunk ideal no es necesariamente un bloque de 800 tokens. Puede ser un evento enriquecido, una ventana temporal, una transición de estado, una secuencia de logs, una jugada, una intervención de un usuario o una hipótesis provisional que luego se confirma o se corrige.

Arquitectura de referencia

Una arquitectura práctica empieza con ingestión. Aquí entran webhooks, colas, Kafka, sockets, transcripciones parciales, logs, eventos de producto o APIs externas. Cada entrada necesita un identificador de fuente y un reloj fiable. El timestamp no es decoración: es parte de la verdad que luego recuperará el modelo.

Después viene el buffer. El sistema acumula una ventana pequeña antes de decidir. Puede ser una ventana de tiempo, una ventana de tokens, una ventana por número de eventos o una ventana cerrada por señal externa. El objetivo es evitar chunks raquíticos que digan algo como 'falló otra vez' sin conservar qué falló, dónde y después de qué acción.

La tercera capa es segmentación. Aquí se decide si el buffer se cierra, se extiende, se fusiona con un chunk anterior o genera un chunk provisional. La cuarta capa es enriquecimiento: entidades, resumen local, etiquetas, enlaces a contexto padre y señales de recencia. La quinta capa es indexación incremental, normalmente híbrida: vectorial para similitud semántica, lexical para términos exactos y a veces grafo temporal para relaciones de estado.

Late chunking y contexto largo

Late chunking plantea otra idea: procesar un contexto amplio con un modelo de embeddings de contexto largo y partir después la representación. En vez de cortar primero y embeber fragmentos aislados, intenta que cada embedding de chunk arrastre información global del documento o secuencia.

En tiempo real estricto puede ser caro, pero en near-real-time es útil. Por ejemplo, una reunión puede procesarse por bloques de cinco minutos con late chunking, mientras se mantiene una memoria rápida por ventanas de 20 segundos. La capa rápida responde ahora; la capa tardía reindexa mejor cuando hay suficiente contexto.

Ranking temporal

La similitud semántica no basta. En tiempo real necesitas señales de recencia, estado y secuencia. Un chunk de ayer puede parecer semánticamente perfecto y estar completamente obsoleto. Un chunk de hace diez segundos puede ser menos parecido, pero contener la actualización que cambia la respuesta.

Evaluación: cómo saber si funciona

No evalúes chunks mirando si parecen bonitos. Evalúa si recuperan la evidencia correcta. Crea un conjunto de preguntas reales con respuesta esperada y referencias a eventos concretos. Mide recall de evidencia, precisión de contexto, latencia de disponibilidad, tasa de chunks obsoletos recuperados y coste por minuto procesado.

También mide daño por corte. Una métrica útil es contar cuántas respuestas fallidas recuperaron un chunk sobre el tema correcto pero sin la frase que contenía la respuesta. Ese patrón indica que el problema no es el embedding, sino la frontera del chunk.

Conclusión

Real-time chunking es una pieza de infraestructura para agentes que viven conectados al mundo. Su trabajo no es partir texto: es preservar significado bajo presión de tiempo. Cuando funciona, el modelo responde con información reciente y trazable. Cuando falla, el sistema parece inteligente pero contesta con fragmentos incompletos, duplicados o caducados.

La pregunta práctica no es 'cuántos tokens debe tener un chunk'. La pregunta es: cuál es la unidad mínima de evidencia que mi sistema puede recuperar sin mentir sobre cuándo ocurrió, de dónde salió y si todavía sigue siendo válida.