Analizar una pelea de UFC sigue siendo, en gran parte, un trabajo manual. Un coach, un analista de transmisión o un oddsmaker revisan minutos y minutos de video para responder preguntas muy concretas: qué pasó, cómo terminó la pelea y qué patrones aparecen en el estilo de cada peleador.

No se trata de interpretar toda la pelea de golpe, sino de encontrar el momento correcto y explicar qué está ocurriendo ahí.

Bajo esa premisa nace Alcides: un agente de IA capaz de convertir el análisis de video en un flujo más rápido, local y accionable. El sistema funciona con un despliegue híbrido: una parte corre en mi DGX Spark (GB10) y otra en un servidor remoto de mayor capacidad. En conjunto, Alcides puede analizar peleas de UFC, reconstruir KOs y TKOs, detectar acciones específicas y generar replays narrados en 1080p con segmentación por peleador.

Cómo funciona Alcides

Alcides funciona con una lógica simple: primero encuentra el momento correcto y después lo analiza.

En lugar de pedirle al modelo que entienda toda la pelea de una sola vez, aunque también puede hacerlo, el agente divide el video en segmentos cortos y evalúa cada tramo con preguntas concretas: si ahí termina la pelea, si aparece una acción específica o si hay un patrón táctico relevante.

Cuando encuentra el fragmento correcto, Alcides activa el resto del flujo: extrae el clip, analiza lo que ocurre, identifica a cada peleador, genera una explicación y, cuando corresponde, produce un replay narrado en 1080p con segmentación visual.

La clave está en que el agente no solo responde preguntas. Coordina herramientas. Decide cuándo buscar, cuándo analizar, cuándo segmentar, cuándo narrar y cuándo devolver una respuesta final. Esa coordinación es lo que convierte a Alcides en un agente autónomo capaz de analizar distintas peleas de UFC.

Las maquinas detras de Alcides

Alcides funciona con una arquitectura híbrida. La parte visual corre localmente en mi DGX Spark, mientras que la planificación del agente se apoya en un modelo remoto de mayor capacidad. La DGX Spark concentra el procesamiento más pesado: video, clips, segmentación, overlays y renderizado de replays. Para este flujo, la memoria unificada CPU/GPU es clave, porque permite trabajar con video en 1080p y modelos de visión sin estar moviendo datos constantemente entre componentes separados.

El modelo de visión principal es Cosmos-Reason2-8B-NVFP4. Lo elegí porque está pensado para razonar sobre video, no solo sobre imágenes aisladas. En Alcides, Cosmos analiza fragmentos cortos de pelea y responde preguntas concretas sobre lo que ocurre en cada tramo: si hay un final, si aparece una acción específica o cómo se desarrolla una secuencia. Esa capacidad espacio-temporal lo hace más útil para este caso que un modelo de visión tradicional.

Para la segmentación uso SAM 3.1 Multiplex. Esta fue una decisión importante porque en UFC no basta con detectar “personas” en cada frame. Los peleadores se cruzan, se tapan, cambian de posición y la transmisión corta de cámara constantemente. SAM 3.1 permite seguir a cada peleador a partir de una descripción, como “peleador con short rojo” o “peleador con short blanco”, y mantener esa identidad a lo largo del clip. Eso hace posible generar replays donde cada atleta conserva su máscara visual de forma consistente.

La coordinación del agente corre con Llama 3.3 70B en un servidor remoto. Este modelo no ve directamente los frames de la pelea. Su trabajo es planificar, decidir qué herramienta ejecutar, interpretar resultados intermedios y construir una respuesta final coherente.

En resumen: Cosmos entiende el video, SAM 3.1 sigue a los peleadores y Llama coordina el agente. Esa separación permite que Alcides combine análisis visual local con razonamiento de alto nivel sin convertir todo el sistema en una infraestructura distribuida demasiado compleja.

Alcides en acción

Alcides cambia el punto de partida de todo análisis. No reemplaza al coach ni al analista; les entrega un primer borrador táctico con acciones detectadas, momentos reconstruidos y puntos concretos para revisar. El criterio final sigue siendo humano, pero ya no depende de pasar horas frente a un video antes de poder redactar un análisis.

En el modo broadcast, ese primer borrador se vuelve visual: Alcides toma un momento clave, segmenta a los peleadores y genera un replay narrado en 1080p.

UFC fue el primer caso porque las preguntas son concretas y el valor de acelerar la revisión inicial es alto. Pero la arquitectura se generaliza a cualquier dominio donde haya que encontrar eventos relevantes en uno o varios videos de distintas duraciones: retail, seguridad industrial, almacenes, manufactura, entre otros.

Aprendizajes

Lo que más me sorprendió fue que el stack de modelos no fue la parte más difícil. Cosmos, SAM 3.1 y Llama 3.3 70B cumplen bien su rol. El reto estuvo en conectarlos de forma consistente para que el agente pudiera ejecutar tareas distintas según la pregunta del usuario.

Operar en hardware propio también cambió el problema. Consumir un servicio externo es más simple; hacerlo localmente obliga a desplegar, optimizar y observar cada parte del pipeline.

La observabilidad terminó siendo clave para entender el flujo de decisiones del agente: qué herramienta eligió, qué información recibió, qué respuesta generó e incluso determinar en que momento el agente decidio no seguir el plan.

Alcides corre en una máquina que cabe dentro de una caja de zapatos. El video se mantiene local. El primer borrador llega lo suficientemente rápido como para que el analista no pierda el hilo esperando el resultado. Ese era el estándar que quería alcanzar.

No es una locura. El modelo es lo más visible, lo que más mejora y lo que parece explicar el comportamiento.

Modelos más pequeños pueden comportarse como agentes autónomos útiles, pero no por el modelo en sí, sino por la infraestructura que los rodea.

Más allá del modelo: el harness

Un agente es más que solo un modelo de lenguaje. Está definido por el entorno en el que ese modelo se ejecuta. A ese entorno le llamamos harness.

Este entorno está compuesto por varias capas que hacen posible que el agente opere más allá de una llamada:

1. Estado inicial

2. Gestión de estado

3. Memoria persistente

4. Acceso a herramientas

5. Aislamiento por sesión o usuario

6. Routing de inputs y outputs

7. Políticas de ejecución

8. Recuperación tras fallos

Estas capas no son inherentes al modelo de lenguaje. Tampoco pertenecen necesariamente al prompt. Sin embargo, son las que determinan cómo evoluciona el sistema a lo largo del tiempo.

Para este experimento utilizamos Hermes Agent, desarrollado por Nous Research, como base. No como sistema final, sino como punto de partida sobre el que añadiremos más capas.

El experimento

Utilizamos Hermes Agent como base por dos razones: facilidad de despliegue y soporte nativo para múltiples canales de comunicación (Discord, Slack, Signal, WeChat, Telegram, WhatsApp). Esto nos permitió centrarnos en la capa operativa sin tener que construir el gateway desde cero.

Desde el inicio, el problema no era desplegarlo, sino el control del entorno de ejecución. En particular:

• Aislamiento entre usuarios

• Aislamiento entre agentes

• Control explícito de estado

• Prevención de acceso cruzado a memoria o recursos

Para resolver estos puntos, decidí añadir capas adicionales orientadas a definir fronteras claras para los usuarios de prueba y sus agentes.

La primera decisión fue separar el ambiente de ejecución (usuario) del perfil de cada agente. A nivel de usuario definimos los recursos disponibles, los servicios accesibles, las configuraciones compartidas y la red interna. A nivel de agente definimos la identidad, configuración, memoria y políticas de comportamiento.

Esto permite desplegar múltiples usuarios y múltiples agentes de forma controlada, evitando interferencias y manteniendo el estado aislado.

La segunda decisión fue cómo permitir que los agentes mejoren y se adapten con el tiempo. Para esto utilizamos Honcho, que gestiona la memoria de corto y largo plazo de forma aislada por agente. Esto permite que el agente evolucione a medida que interactúa con el usuario.

Adicionalmente, introdujimos un proceso de introspección en background. En periodos de inactividad, el agente puede revisar interacciones pasadas y evaluar cómo podría haber respondido mejor. Este proceso no es continuo ni global, y se controla de forma explícita.

La tercera decisión fue desacoplar las capacidades externas del agente. Servicios como búsqueda en internet, crawling o ejecución se tratan como infraestructura externa. El agente no contiene estas capacidades, solo define cómo utilizarlas. Esto permite modificar la infraestructura sin afectar directamente a los agentes.

La cuarta decisión fue que no todos los agentes deben comportarse igual. Esto va más allá del prompt. Definimos dos tipos de agentes: el agente general y el agente acompañante. Ambos comparten capacidades, pero difieren en comportamiento. El primero es reactivo. El segundo puede iniciar interacción bajo ciertas condiciones, por ejemplo para hacer seguimiento o retomar contexto previo.

Finalmente, como todo sistema, es necesario un módulo de observabilidad. Para esto registramos eventos como uso de herramientas, transiciones de estado, errores, sesiones, actividad de memoria, latencias y comportamiento por agente. Esto nos permite analizar el sistema y ajustar configuraciones de forma controlada.

Resultados

Esta vez el experimento contó con usuarios beta. Participaron más de 10 usuarios activos (en su mayoría perfiles no técnicos) a lo largo del mes de abril y más de 20 agentes operando en paralelo. En total, se generaron aproximadamente 360 millones de tokens (casi 220 millones de palabras) a través de OpenRouter. El modelo principal fue Nemotron 120B A12B; para tareas de visión utilizamos Gemma 4 26B A4B en todos los perfiles.

Más allá de los números, lo relevante fue la interacción entre los usuarios y sus agentes.

Varios usuarios comentaron que la experiencia se sentía distinta a usar ChatGPT, no tanto por la calidad de la respuesta, sino por el contexto de la conversación y el entendimiento que se construía a medida que interactuaban más. El agente recordaba, mantenía líneas de conversación y no requería repetir instrucciones constantemente.

También apareció algo inesperado: el canal importa. Poder interactuar a través de Discord cambió la forma de uso. Esto aumentó la frecuencia de interacción sin necesidad de “abrir” el agente explícitamente. Muchos usuarios mencionaron que tenerlo en aplicaciones que utilizan con frecuencia facilitaba la experiencia, algo que también se observó en otras plataformas de mensajería.

En tareas concretas, algunos usuarios lograron automatizar flujos pequeños que antes no resolvían bien con herramientas tradicionales. No por la capacidad del modelo en sí, sino por la combinación de memoria, herramientas y persistencia.

La funcionalidad de companion tuvo un comportamiento distinto al esperado. No se utilizó como un asistente utilitario, sino como un espacio de reflexión. Algunos usuarios lo integraron en procesos de journaling, aprovechando la memoria y la continuidad para dar seguimiento a ideas, decisiones y estado personal a lo largo de varios días. Otros destacaron la capacidad de hacer follow-up incluso sobre temas que habían conversado una semana antes.

Lo interesante de estos agentes no es solo su capacidad, sino su maleabilidad para adaptarse a distintas tareas y roles según el usuario.

Conclusiones

La principal conclusión de este experimento es que no necesitamos los modelos más grandes para tener agentes autónomos funcionales. Con la infraestructura adecuada, incluso un modelo más pequeño puede tener un desempeño comparable al de modelos significativamente mayores.

Esto no implica que no existan diferencias. En tareas específicas o en el uso de ciertas herramientas, los modelos más grandes siguen teniendo ventaja, en gran parte porque es más probable que hayan visto ese tipo de problemas durante su entrenamiento.

Sin embargo, al centrarnos en un usuario más estandarizado, en este caso perfiles no técnicos, estas diferencias resultan mucho menos perceptibles en el uso cotidiano.

Si te interesa probar este tipo de agentes o explorar cómo se comportan en tu propio flujo de trabajo, puedes comentar al final del post o escribirme directamente.

En el artículo anterior exploramos algunos de los modelos que hoy permiten construir múltiples sistemas de visión computacional capaces de detectar, segmentar y seguir objetos en videos. Si te lo perdiste y estás interesado en la tecnología que le da vida a este proyecto, no dudes en leerlo.

Pero en el día a día los modelos no son el objetivo, sino lo que habilitan.

El verdadero reto nace cuando vamos más allá de los benchmarks y nos enfrentamos a nuevos contextos, donde las condiciones son mucho más complejas y menos controladas.

Surfing y bodyboarding son deportes profundamente visuales. Gran parte del análisis del rendimiento ocurre revisando videos de sesiones: trayectorias en la ola, selección de secciones, timing o ejecución de maniobras. Sin embargo, ese análisis sigue siendo principalmente manual.

En el video vemos a John John Florence (increíble surfer) en uno de los videos que analizaremos. Este tipo de material es el punto de partida del experimento. Más adelante veremos cómo transformamos un video de este estilo utilizando visión computacional.

El surf todavía carece de analítica real

En muchos deportes el análisis del rendimiento ya forma parte del entrenamiento diario. En fútbol se analizan mapas de calor y trayectorias de jugadores. En ciclismo se miden potencia, cadencia y eficiencia. Incluso en running cada sesión puede descomponerse en métricas detalladas.

Sin embargo, surfing y bodyboarding siguen dependiendo en gran medida de la observación directa y la revisión manual de videos. Atletas, entrenadores y aficionados revisan sesiones para entender decisiones como la selección de olas, la línea tomada en la pared o el timing de una maniobra.

Ese proceso funciona, pero tiene limitaciones claras. El análisis suele ser subjetivo, es difícil comparar sesiones a lo largo del tiempo y gran parte de la información presente en el video simplemente no se cuantifica.

Esto crea una brecha interesante.

Existe una enorme cantidad de videos de surf y bodyboard, pero todavía hay muy pocas herramientas que permitan transformarlo en datos para analizar el rendimiento de forma sistemática.

Caso de uso: Surfing

A partir de un video es posible comenzar a detectar y seguir a los riders a lo largo de una ola. Esto permite reconstruir trayectorias, analizar la duración del rider en la ola y observar cómo se mueve a lo largo de ella.

Aunque este es solo un primer experimento, incluso este nivel básico de análisis ya permite empezar a extraer información interesante de una sesión. Por ejemplo, cómo cambia la línea tomada en distintas olas o cuánto tiempo permanece un rider en la pared antes de salir de la sección.

En el video anterior vimos un ejemplo con John John Florence. El sistema detecta al surfista y lo sigue a lo largo de la ola, generando una representación simple pero útil de su trayectoria.

Este tipo de información puede ser el primer paso hacia herramientas que permitan analizar sesiones de surf de manera más sistemática.

Caso de uso: Bodyboarding

Aunque comparte el mismo entorno que el surf, la dinámica del movimiento es distinta. La postura del atleta, la forma en que se interactúa con la ola y el tipo de maniobras cambian considerablemente. Esto hace que el bodyboarding sea un buen segundo caso para probar la robustez del sistema.

En este ejemplo analizamos una sesión de Pierre Louis Costes, uno de los bodyboarders más reconocidos del circuito profesional.

Al igual que en el caso anterior, el sistema detecta al atleta y lo sigue a lo largo de la ola. A partir de esa información es posible reconstruir trayectorias dentro de la sección, observar cómo se posiciona en la pared de la ola y analizar la duración de cada ride.

Conclusión

Surfing y bodyboarding generan enormes cantidades de video, pero todavía existen pocas herramientas que permitan analizar ese material de forma sistemática. Esto abre una oportunidad interesante para explorar cómo la visión computacional puede transformar esas sesiones en datos y nuevas formas de analizar el rendimiento.

Este proyecto es un primer experimento en esa dirección. Incluso en esta etapa inicial ya es posible empezar a observar patrones, trayectorias y decisiones dentro de una ola desde una perspectiva distinta.

Si este experimento te resulta interesante o tienes ideas sobre cómo expandir el sistema, te invito a dejar tus comentarios. Y si te interesa explorar aplicaciones más allá de estos deportes o colaborar en el desarrollo del proyecto, no dudes en escribirme.

La comparación se organiza en tres niveles:

1. Diferencias en la arquitectura de cada modelo.

2. Implicancias en latencia y eficiencia.

3. Impacto en el ciclo de diseño y despliegue de modelos.

Estado actual

La deteccion de objetos en visión computacional (computer vision) ha evolucionado hacia tres lineas principales. Aunque todas buscan localizar y clasificar objetos en una imagen, difieren en cómo estructuran el problema. Para entender esas diferencias es útil definir tres conceptos:

1. Redundancia: Producir multiples predicciones para un mismo objeto. Por ejemplo, un unico auto puede aparecer marcado por varias cajas superpuestas.

2. Asignacion: El mecanismo que empareja las predicciones del modelo con los objetos reales durante el entrenamiento.

3. Postprocesamiento: Pasos adicionales aplicados despues de que la red genera sus salidas, como eliminar duplicados o ajustar resultados.

Con estos conceptos claros, podemos diferenciar las tres familias principales.

Modelos de prediccion densa: la familia YOLO

Los modelos YOLO (You Only Look Once) generan muchas predicciones en paralelo sobre distintas regiones de la imagen. La redundancia es intencional: el modelo produce multiples bounding boxes candidatas y luego filtra.

El filtrado se realiza mediante NMS (Non-Maximum Suppression), un algoritmo que elimina cajas superpuestas conservando la de mayor confianza segun un umbral de solapamiento medido con Intersection over Union (IoU). NMS es un paso de postprocesamiento externo al modelo.

Durante el entrenamiento, la asignacion es local: cada celda o anchor se asocia a un objeto cercano segun reglas geométricas.

En este enfoque:

• Se acepta redundancia.

• Se corrige mediante NMS.

• La asignacion es local.

Modelos basados en DETR

DETR (Detection Transformer) reformula el problema como prediccion de un conjunto (set prediction). En lugar de producir muchas predicciones y luego filtrarlas, intenta generar directamente un conjunto coherente de objetos.

La arquitectura utiliza un encoder-decoder Transformer. El decoder opera sobre un conjunto fijo de object queries aprendibles, donde cada query intenta representar un objeto.

Durante el entrenamiento se emplea Hungarian matching, un algoritmo de asignacion bipartita que empareja predicciones y objetos reales de forma uno a uno. Esto obliga al modelo a producir una unica prediccion por objeto.

Como consecuencia, en principio no requiere NMS como componente central.

En este enfoque:

• Se evita la redundancia desde el diseño.

• No depende de NMS.

• La asignacion es global y uno a uno.

Detectores open-vocabulary

Una tercera linea integra modelos vision-language. Estos incorporan un text encoder y combinan representaciones visuales y textuales mediante mecanismos de cross-attention.

La diferencia principal no es el manejo de duplicados, sino la ampliacion del espacio semantico: permiten detectar categorias fuera de un conjunto cerrado.

Esto implica:

• Procesamiento adicional en inferencia.

• Mayor costo computacional.

• Dependencia del preentrenamiento multimodal.

Diferencias entre arquitecturas

La diferencia principal entre las tres arquitecturas es cómo parametrizan el espacio de salida, es decir, la representación latente sobre la que se define el proceso de búsqueda de objetos.

Consideremos una imagen con tres objetos: un auto parcialmente tapado por otro objeto, un peatón pequeño al fondo y una bicicleta que se cruza visualmente con el auto. Es un caso típico: objetos de distinto tamaño, parcialmente visibles y con regiones que se superponen.

En una arquitectura tipo YOLO, distintas regiones de la imagen pueden activarse sobre el mismo objeto. El auto puede generar varias cajas candidatas porque varias celdas “ven” partes distintas del mismo objeto. El modelo no evita esa duplicación. Produce múltiples hipótesis y luego NMS decide cuál conservar según el solapamiento (IoU). La ambigüedad se resuelve después de predecir.

En DETR, la situación es distinta. El modelo dispone de un conjunto fijo de representaciones latentes (object queries). Cada una debe explicar, como máximo, un objeto. Durante entrenamiento, la asignación uno a uno obliga a que el auto sea representado por una única predicción. Si dos queries intentan representar el mismo objeto, una será penalizada. La ambigüedad se resuelve dentro del modelo, no en un paso externo.

RF-DETR mantiene la formulación de DETR como predicción de un conjunto con asignación uno a uno. La diferencia es que no entrena una única arquitectura fija.

Se entrena una superred con pesos compartidos que contiene múltiples subconfiguraciones. Después del entrenamiento, se puede seleccionar una configuración más pequeña o más grande sin reentrenar desde cero.

Conclusiones e implicaciones

El objetivo de este artículo no es comparar cuál modelo obtiene mejor resultado en un benchmark específico, sino entender cómo cada arquitectura define el problema y qué implica esa definición para nuestro sistema.

YOLO, DETR y RF-DETR son más que variaciones técnicas. Representan decisiones distintas sobre:

• Cómo se parametriza el espacio de salida.

• Dónde se controla la redundancia.

• En qué etapa se fijan las restricciones del sistema.

YOLO coloca parte de la coherencia en inferencia. DETR la internaliza en el aprendizaje. RF-DETR mantiene esa formulación, pero introduce flexibilidad en cómo se concreta la arquitectura entrenada.

El principal trade-off es estructura versus control.

Elegir un enfoque implica decidir:

• Si se prefiere una arquitectura fija y explícita.

• Si se prioriza coherencia estructural desde el entrenamiento.

• Si se necesita capacidad de adaptación posterior sin redefinir la lógica de predicción.

La elección debería basarse en lo que esperamos que el sistema haga y bajo qué restricciones debe operar.

En base a esta premisa nace Praephos, la evolución de The Data Chronicles. Cuando comencé a escribir en este blog, mi idea era muy sencilla: contar historias a través de datos, descomponer conceptos y estructurar ideas.

Sin embargo, entender desde fuera tiene un límite.

Un nuevo espacio

Entender los datos a través de historias, e incluso descubrirlas con datos, sigue siendo valioso. La claridad sigue siendo importante, pero la comprensión real exige algo más.

La sociedad no avanza solo porque consume información. Avanza cuando interviene en la realidad. Todos, en algún momento, consciente o inconscientemente, formulamos hipótesis, probamos caminos, definimos qué significa que algo funcione y evaluamos resultados. Cuando no funciona, ajustamos o aceptamos que no era la ruta adecuada.

Ese ciclo no es exclusivo de la ciencia. Es el núcleo del desarrollo intelectual.

Crecer implica exponerse al error

El aprendizaje real no ocurre cuando acumulamos conceptos. Ocurre cuando nuestras ideas encuentran cierta fricción.

En machine learning, un modelo mejora porque se enfrenta al error. Ajusta sus parámetros, corrige las desviaciones y vuelve a intentarlo. Sin medición no hay progreso.

Con nosotros pasa algo similar.

Crecer implica formular una idea propia y arriesgarse a que esté equivocada. Implica actuar, observar consecuencias y ajustar criterio. Sin exposición al error solo reforzamos intuiciones cómodas.

La diferencia entre consumo y desarrollo está ahí. Consumir es absorber información sin ninguna fricción. Desarrollar es intervenir y aceptar que no siempre saldrán las cosas como esperamos.

Praephos se posiciona en ese segundo terreno.

Una evolución necesaria

Praephos no es solo una evolución del blog. Es una consecuencia natural del punto al que llegó este proceso.

Si el análisis fue el primer paso, ahora el foco está en involucrarse directamente con las ideas. No basta con entender cómo funcionan las cosas en teoría. Es necesario trabajar con ellas, probarlas, medirlas y aceptar sus límites.

La inteligencia artificial no avanza por explicaciones elegantes, sino por iteración. Algo similar ocurre con el pensamiento cuando se toma en serio. La claridad importa, pero el criterio se forma cuando una idea se contrasta con la realidad.

Por eso el enfoque cambia.

Experimento, luego entiendo no es una frase suelta que se me ocurrió o ¿copié?. Es la dirección que quiero tomar a partir de ahora y, en cierta forma, una manera de cuestionar la forma en que consumimos contenido en la era digital.