La segunda pintura representa una habitación en Roma. Hay libros, dibujos, esculturas y una guitarra. Las composiciones son distintas, pero ambas obras comparten una etiqueta en el catálogo del museo: Guitarras.

Esa conexión permite iniciar un recorrido entre obras que difícilmente encontraríamos navegando únicamente por artista, época o movimiento artístico. Desde allí, podemos continuar hacia Allegory of Music, The Musician y otras piezas relacionadas, siguiendo las asociaciones recuperadas por un modelo multimodal.

Es una de las experiencias que construí en Painting Gaze, un prototipo de exploración artística desarrollado con 586 obras de la colección Open Access del Met.

La aplicación organiza las obras en un mapa interactivo. Podemos comenzar por retratos, música o escenas de madres con niños, seleccionar una pintura y descubrir otras relacionadas. Al abrir una obra, encontramos información del museo y, en determinados casos, un análisis de los rostros representados: posición de los ojos, puntos faciales, orientación de la cabeza y una estimación de la dirección de la mirada.

Las 586 obras distribuidas en un espacio tridimensional que permite seleccionar pinturas y explorar sus conexiones.

Me interesaba construir una experiencia que permitiera recorrer una colección siguiendo afinidades visuales y semánticas. Las fichas del museo proporcionan el contexto histórico, mientras que los modelos de machine learning proponen nuevas conexiones que el visitante puede explorar.

Hay una diferencia importante entre encontrar una conexión e interpretarla. En el ejemplo de Watteau y Alaux, la guitarra constituye una coincidencia documentada entre ambas obras. Sin embargo, no podemos afirmar que esa característica sea la única que explica la proximidad calculada por el modelo.

Construir esta experiencia también permitió investigar problemas de representación multimodal, recuperación aproximada, compresión vectorial y visión computacional.

Uno de los resultados fue especialmente interesante: pude reducir 76,8 veces el tamaño de los vectores utilizados para recuperar candidatos y conservar el 99,52 % de coincidencia con los vecinos exactos del top-10 después de aplicar reranking.

Para entender cómo llegué a ese resultado, conviene comenzar por la información que recibe el modelo.

Metodología

Representar una obra más allá de sus píxeles

Una fotografía de una pintura no contiene toda la información disponible sobre ella. El título, la atribución, el periodo, los materiales y los temas documentados aportan contexto que puede modificar las relaciones que recupera un modelo.

Para construir los embeddings utilicé EmbeddingGemma 2, proporcionando la imagen RGB original junto con información estructurada del catálogo en una entrada multimodal intercalada. El modelo procesa ambas modalidades conjuntamente, en lugar de combinar posteriormente embeddings visuales y textuales calculados por separado.

Los registros incluyen título, artista, fecha, técnica, tipo de objeto, cultura, nacionalidad, periodo y etiquetas temáticas. También incorporé descripciones breves cuando las páginas oficiales del museo ofrecían información suficiente.

De los 586 registros, 542 pudieron enriquecerse con textos documentados. Utilicé un servicio local de Qwen para elaborar los resúmenes a partir de esas fuentes, acompañado de controles sobre fechas, fragmentos recuperados y afirmaciones sin respaldo. Las 44 obras restantes conservaron sus metadatos originales.

Este proceso también exigió respetar las atribuciones del catálogo. Lady Guildford, por ejemplo, aparece como «Copy after Hans Holbein the Younger», sin fecha especificada. Eliminar esa calificación modificaría la información que el visitante consulta y que el modelo utiliza para construir su representación.

Al finalizar, cada obra quedó representada por un embedding normalizado de 768 dimensiones.

Comprimir sin perder el recorrido

Quería investigar cuánto podía reducir esa representación antes de alterar significativamente las relaciones entre obras.

Utilicé Matryoshka Representation Learning (MRL) para trabajar con las primeras 256 dimensiones del embedding, normalizadas nuevamente, y TurboQuant para comprimirlas utilizando un bit por coordenada.

El resultado fue una reducción de aproximadamente el 98,7 % en el espacio ocupado por estos vectores.

Sin embargo, la compresión también afectó la recuperación.

Evalué las relaciones haciendo que cada una de las 586 obras consultara las otras 585, tomando como referencia la búsqueda exacta con los embeddings completos de 768 dimensiones.

La configuración más comprimida conservaba menos del 70 % de coincidencia con los conjuntos de vecinos originales.

La siguiente prueba consistió en cambiar la forma en que utilizábamos esa representación.

En lugar de producir directamente el ranking final, el índice HNSW cuantizado de Qdrant recupera 80 candidatos. Posteriormente, una segunda representación con los vectores originales permite calcular las puntuaciones completas de 768 dimensiones y seleccionar las seis obras relacionadas.

Con este procedimiento, la coincidencia del top-10 aumentó al 99,52 % para MRL con TurboQuant de un bit.

En el grafo que utiliza la aplicación se preservaron 3.513 de las 3.516 conexiones dirigidas de la referencia exacta, equivalentes al 99,91 %.

La representación comprimida resulta suficiente para localizar casi todos los candidatos necesarios en esta colección. El reranking conserva acceso a los vectores completos, por lo que el ahorro en datos cuantizados no elimina el coste de mantener los originales.

También es importante delimitar el resultado: estamos midiendo coincidencia con una búsqueda vectorial exacta. La relevancia artística de las recomendaciones requeriría otra evaluación, con juicios independientes de las distancias calculadas por el modelo.

El mapa tridimensional y sus propias distorsiones

Para representar visualmente la colección utilicé UMAP, proyectando los embeddings originales en tres dimensiones.

Esta reducción permite convertir cientos de vectores en un espacio navegable, aunque modifica las relaciones de proximidad.

En las pruebas, la proyección conservó únicamente el 54,57 % de los conjuntos originales de los 15 vecinos más cercanos.

Por eso utilizo UMAP para posicionar las obras en el mapa, mientras que sus conexiones proceden de la recuperación vectorial y el reranking. La proximidad visual entre dos imágenes puede diferir de sus relaciones semánticas en el espacio original.

La interfaz utiliza imágenes monocromáticas organizadas en seis niveles tonales, pero EmbeddingGemma procesa siempre las imágenes originales en color. También conserva las proporciones de cada obra y carga imágenes de mayor resolución al seleccionarlas.

¿Hacia dónde miran los personajes de una pintura?

El otro componente experimental utiliza computer vision para analizar los rostros representados en las obras.

La línea de mirada visible combina la orientación de la cabeza con una heurística basada en el desplazamiento de las pupilas.

El sistema registró 1.652 detecciones en 573 de las 586 obras, una cobertura del 97,78 %. Sin embargo, los rostros estilizados, los perfiles, las figuras pequeñas y los elementos decorativos pueden producir resultados incorrectos.

La cobertura describe cuántas obras contienen detecciones. No mide precisión ni recall, y tampoco garantiza que todas correspondan a rostros humanos.

Las trece obras sin detecciones permanecen disponibles para inspección. La aplicación también presenta los ángulos y las líneas de mirada como estimaciones, con información adicional del procesamiento para quien quiera revisar los resultados.

Nuevas formas de experimentar un museo

El prototipo permite explorar una colección digital, pero me interesa especialmente lo que podríamos construir al trasladar estas interfaces a espacios culturales físicos.

Una primera posibilidad es incorporar instalaciones interactivas en museos y galerías. Una pantalla podría permitir a los visitantes seleccionar una obra de la sala y explorar relaciones con piezas que se encuentran en otras salas, depósitos o colecciones. De esta manera, el recorrido físico podría complementarse con uno semántico.

Las exposiciones temporales ofrecen otro contexto. Sus recorridos suelen responder a una selección curatorial definida, pero una interfaz de exploración permitiría descubrir conexiones adicionales entre las obras sin alterar la narrativa principal de la exposición.

También sería interesante experimentar con proyecciones de gran formato o superficies interactivas donde los visitantes puedan explorar composiciones, observar relaciones temáticas e inspeccionar estimaciones geométricas de los personajes representados.

Estas aplicaciones todavía requieren validación. El prototipo demuestra que podemos integrar recuperación multimodal, contexto documental y análisis visual en una experiencia navegable. Sin embargo, no hemos medido su efecto sobre la atención, el aprendizaje o la satisfacción de los visitantes.

Ese sería el siguiente paso.

Podríamos comparar recorridos tradicionales con experiencias de exploración multimodal, observar qué obras despiertan interés, qué conexiones se consideran relevantes y si los visitantes descubren piezas que normalmente habrían ignorado.

También necesitaríamos incorporar el criterio curatorial. Un score vectorial puede proponer asociaciones útiles, pero no determina por sí mismo su significado histórico o artístico.

El 8 de septiembre, Jacob Coxon anunció que dejaba Anthropic después de haber trabajado durante tres años en preentrenamiento entre OpenAI y Anthropic. Acusó a ambas compañías de avanzar hacia sistemas de superinteligencia capaces de mejorarse a sí mismos mientras “apostaban con nuestras vidas”. Su publicación superó rápidamente los cien millones de visualizaciones.

Horas después, Evan Hubinger, responsable de investigación de alineamiento en Anthropic, respaldó buena parte de esa preocupación y puso una cifra sobre la mesa: en su estimación personal, existe más de un 10% de probabilidad de que la IA mate a todos los humanos durante la próxima década.

El 9 de septiembre, Bernie Sanders respondió directamente a Coxon y anunció que impulsaría legislación para prohibir la superinteligencia y pausar el desarrollo avanzado de IA. Otros legisladores estadounidenses se sumaron a la discusión.

El 10, el senador republicano Josh Hawley abrió una investigación sobre OpenAI por el incidente de Hugging Face y señaló expresamente que también investigaría el riesgo existencial asociado a sus sistemas.

El 11, más de 70 parlamentarios y miembros de la Cámara de los Lores pidieron al primer ministro británico apoyar una prohibición de desarrollar superinteligencia artificial y promover un acuerdo internacional para impedirla. Ese mismo día, Nate Soares, presidente de MIRI y coautor de If Anyone Builds It, Everyone Dies, apareció durante casi dos horas con Tucker Carlson defendiendo una de las versiones más duras del argumento de extinción.

El 12 llegó el movimiento más relevante para esta discusión. Dario Amodei publicó We Must Pace the Frontier. Propuso evaluadores externos con acceso equivalente al de empleados, coordinación entre los principales laboratorios de frontera de países democráticos y, eventualmente, acuerdos internacionales. Sam Altman respaldó la propuesta y dijo que OpenAI adoptaría también evaluadores con acceso similar. Elon Musk respondió: “Dario is right”.

El 13, la discusión llegó al presidente de Estados Unidos. Donald Trump rechazó los llamados a desacelerar, atribuyó parte de las advertencias a “negative forces” y llevó la conversación directamente a China: “whoever wins with AI wins”.

Toda esta secuencia ocurrió en menos de una semana.

No creo que la inteligencia artificial vaya a destruir a la humanidad. Después de siglos sobreviviendo a guerras, pandemias y otros eventos extremos, me cuesta aceptar la extinción por IA como el escenario probable desde el que debamos pensar el futuro. Eso no significa negar riesgos serios en ciberseguridad, fraude, vigilancia, armas, concentración económica o uso por actores estatales.

Sí me interesa la velocidad con la que una determinada percepción del riesgo pasó de una publicación en X a los medios, al Congreso, a propuestas internacionales y finalmente a una discusión abierta entre los principales laboratorios de frontera y el presidente de Estados Unidos.

Esta secuencia no demuestra coordinación entre las partes. Tampoco necesitamos asumirla para analizar lo que está ocurriendo. Actores con incentivos diferentes pueden terminar empujando la misma narrativa porque esa narrativa mejora sus posiciones de maneras distintas.

Detrás de la conversación sobre seguridad hay competencia entre empresas, rivalidad entre Estados Unidos y China, cantidades extraordinarias de capital, modelos con pesos abiertos que reducen barreras de entrada y un grupo pequeño de compañías que concentra buena parte de la capacidad de cómputo, el talento y los modelos más avanzados.

Por eso prefiero mirar los incentivos.

Amodei es bastante explícito sobre qué significa desacelerar. En su propuesta, “moderar la frontera” no implica detener el entrenamiento de modelos ni el progreso técnico. Significa dar más tiempo a medidas de seguridad, alineamiento y evaluaciones externas. También sostiene que una estrategia coordinada permitiría hacerlo sin sacrificar la ventaja comercial de los laboratorios líderes ni la posición de Estados Unidos.

Mi preocupación empieza ahí. Cuando quienes ya lideran la carrera participan también en la definición de las reglas, los evaluadores y los límites que deberá seguir el resto, reducir la velocidad puede consolidar las posiciones que ya existen.

Podemos imaginar un safety car en Fórmula 1. Todos reducen la velocidad, pero el que iba primero sigue primero.

Démosle la bienvenida a los participantes del juego

Los laboratorios de frontera ocupan la primera posición. Anthropic, OpenAI y el resto de compañías que compiten por los modelos más capaces pueden preocuparse sinceramente por la seguridad y, al mismo tiempo, competir por capital, capacidad de cómputo, talento, clientes, contratos públicos y posición de mercado. Ambos incentivos pueden coexistir.

Y hablamos de mucho capital. OpenAI cerró en marzo una ronda con US$122 mil millones comprometidos y describió el acceso sostenido a cómputo como una ventaja estratégica. Anthropic levantó US$65 mil millones en mayo y dijo que ese capital ayudaría, entre otras cosas, a “mantenerse en la frontera de investigación”.

Este tipo de acciones me resultan más interesantes que intentar decidir si las advertencias son sinceras. Si quienes nos dicen que la frontera se está volviendo peligrosamente poderosa siguen invirtiendo cantidades extraordinarias para permanecer en ella, quiero saber qué parte desean desacelerar y qué están dispuestos a sacrificar ellos.

Los gobiernos juegan otra partida. Estados Unidos quiere reducir riesgos, pero también conservar su ventaja sobre China. China tiene el incentivo contrario. Los evaluadores necesitan independencia, pero dependen del acceso que solo los propios laboratorios pueden conceder. Los modelos abiertos y los laboratorios más pequeños tienen menos cómputo, menos capital y mucha menos capacidad para participar en Washington o en la definición de estándares.

Ninguno necesita actuar de mala fe para que el resultado termine favoreciendo una mayor concentración.

¿Quién evalúa al evaluador?

METR aparece repetidamente en esta conversación y Amodei la menciona expresamente como ejemplo de organización que podría asumir el papel de evaluador externo con acceso interno.

METR afirma que no acepta pagos en efectivo ni donaciones de compañías de IA o de sus ejecutivos. Es una señal relevante, pero no agota la discusión sobre independencia. En su propio informe de riesgos reconoce que algunos miembros de su equipo tienen “vínculos sociales estrechos” con empleados de compañías de IA, que trabajan desde Constellation, un centro de investigación compartido con personal de esos laboratorios, y que el acceso a modelos no públicos y a tokens gratuitos crea un incentivo para mantener relaciones cordiales con las empresas evaluadas.

El mismo informe reconoce que METR inició ese ejercicio sin una política aplicable de conflictos de interés para su personal y que, por esa razón, no hubo un proceso formal de recusación o declaración. También señala que al menos seis personas involucradas directamente tenían relaciones personales cercanas con empleados de las compañías evaluadas.

Luego está la puerta giratoria. Beth Barnes, fundadora de METR, trabajó anteriormente en OpenAI. Joe Benton dejó el equipo de seguridad de Anthropic para incorporarse a METR y trabajar en evaluaciones externas. Josh Engels hizo un movimiento similar desde Google DeepMind.

Nada de esto sugiere o demuestra corrupción ni manipulación de resultados. El problema es institucional. Un árbitro puede ser honesto y seguir sin ser suficientemente independiente.

La independencia también depende de quién forma a sus investigadores, de qué compañías necesita acceso, de las relaciones profesionales que mantiene y de la diversidad de ideas dentro del sistema.

Si ese acceso solo existe dentro de un mismo círculo profesional e intelectual, la evaluación externa corre el riesgo de convertirse en revisión entre pares del mismo ecosistema.

Lo que no podemos ver

La independencia del evaluador deja pendiente otro problema: qué evidencia puede observar. El incidente de OpenAI y Hugging Face es un buen ejemplo. Aproximadamente 1,200 agentes se comunicaron mediante un tablón no autorizado, más de 700 participaron en ataques contra Hugging Face y se intercambiaron más de 70,000 mensajes y archivos.

El contexto experimental cambia la lectura. OpenAI había lanzado decenas de miles de agentes sobre ExploitGym, una evaluación de ciberseguridad que les pedía explotar vulnerabilidades para recuperar una respuesta. Las salvaguardas habituales estaban reducidas, algunas tareas eran imposibles y varios agentes recibieron presupuestos de razonamiento muy superiores a los disponibles en productos públicos. Los agentes terminaron actuando fuera del alcance autorizado y atacando infraestructura de terceros, lo cual sigue siendo grave, pero no equivale a un sistema que un día decidió por cuenta propia salir a hackear Internet.

Para evaluar una afirmación de capacidad necesito algo más que el resultado final. Necesito conocer la instrucción inicial, las herramientas disponibles, la arquitectura de apoyo, los reintentos, el presupuesto de inferencia, cuántos agentes participaron, cuántos intentos fallaron, qué intervención humana existió y qué trazas quedaron fuera del análisis.

La escala tampoco es menor. Después del incidente, OpenAI dijo haber dedicado tres millones de horas de GPU a investigar lo ocurrido. Fortune consultó a especialistas en infraestructura que estimaron ese trabajo entre US$4 millones y US$15 millones en cómputo. Esa cifra corresponde a la investigación posterior, no al costo del experimento original, cuyo monto no fue publicado.

El propio METR reconoce límites parecidos en su informe de riesgos. Tuvo acceso a cadenas de razonamiento, pero solo acceso parcial a la arquitectura de apoyo y a ciertas excepciones de las salvaguardas. Además, las empresas podían decidir qué información no pública autorizaban para publicación, y el diseño piloto incluía una opción de salida silenciosa antes de publicar resultados.

Si experimentos de este tipo van a terminar justificando la implementación de nueva regulación, necesitamos poder reconstruir cómo se produjo la evidencia. Comprender exige experimentar, pero experimentar también exige inspeccionar las condiciones del experimento. Un resultado espectacular sin suficiente trazabilidad puede generar una narrativa totalmente desacoplada de la realidad.

El costo del safety car

Amodei propone que los laboratorios de frontera coordinen estándares y límites sobre el ritmo del progreso, con apoyo gubernamental y una exención limitada de las normas antimonopolio para determinadas conversaciones.

El Departamento de Justicia y la FTC ya han señalado que compartir información técnica de ciberseguridad entre competidores no constituye por sí mismo una infracción antimonopolio. Coordinar prácticas de seguridad tiene sentido. Coordinar el ritmo al que los principales competidores pueden desarrollar determinadas capacidades merece un análisis distinto.

La regulación también tiene costos fijos. Auditorías, evaluaciones, reportes, requisitos de cumplimiento y procesos de aprobación pueden ser asumibles para compañías que acaban de levantar decenas de miles de millones de dólares y convertirse en una barrera seria para quien intenta entrar.

Para mí, esa es una señal clara de posible captura regulatoria: reglas que parecen universales, pero cuyo costo relativo protege a los jugadores ya posicionados.

China también está sentada en la mesa

La geopolítica vuelve el problema todavía más difícil. Amodei lo reconoce de forma bastante directa: si Estados Unidos frena y China no, Estados Unidos puede perder su ventaja. Y si China sospecha que Estados Unidos seguirá avanzando puertas adentro, tampoco tiene razones para frenar.

Su propuesta combina la desaceleración con restricciones a chips, controles sobre la destilación de modelos y mayor protección de los pesos. El objetivo declarado es ampliar la ventaja estadounidense durante los próximos tres a cinco años antes de intentar acuerdos internacionales más ambiciosos.

Eso mezcla seguridad con estrategia geopolítica. Trump plantea el mismo dilema desde el lado contrario: desacelerar demasiado puede significar ceder terreno a China. Cualquier política seria sobre IA tendrá que convivir con esa realidad.

Miedo, capital y legitimidad

La narrativa de que la IA acabará con la humanidad puede enviar mensajes distintos a tres audiencias.

• Al capital le dice que estamos cerca de una tecnología extraordinariamente poderosa y que quedarse fuera puede ser costoso.

• Al gobierno le dice que esa tecnología es demasiado peligrosa para permitir un acceso amplio.

• Al público le dice que quienes construyen estos sistemas entienden el peligro mejor que nadie y deberían ocupar un lugar central en su control.

No necesito asumir que esos mensajes fueron diseñados de manera coordinada. Una narrativa puede ser sincera y estratégicamente útil al mismo tiempo.

En mi opinion, si un laboratorio considera que lo que construye representa una amenaza existencial, esperaría verlo renunciar a alguna ventaja: a) reducir la capacidad de cómputo, b) cancelar entrenamientos, c) retrasar deliberadamente capacidades o abrir suficiente evidencia para que un tercero realmente independiente pueda intentar refutar sus conclusiones.

¿Qué tendría que ver para cambiar de opinión?

No necesito pensar que la IA pondrá fin a la humanidad para creer que debe existir algún nivel de regulación, especialmente cuando experimentos extraordinarios se presentan como evidencia para orientar las políticas públicas. No vendamos aceite de serpiente como una poción que cura cualquier mal.

Necesito mejores mecanismos para distinguir riesgos reales de narrativas amplificadas por incentivos que no conocemos. Querría varios evaluadores técnicamente competentes, con posiciones distintas y capacidad para publicar sin depender de los jugadores principales. Organizaciones realmente autónomas, no solo independientes en el papel.

Querría experimentos reproducibles o, cuando eso sea imposible por razones de seguridad, suficiente trazabilidad para entender las instrucciones, la arquitectura de apoyo, la intervención humana y la selección de resultados. Querría reglas vinculadas a capacidades observables, no a si un modelo es abierto o cerrado. Y querría que el costo de cumplirlas fuera proporcional, para que la regulación no termine funcionando como barrera de entrada.

Sobre todo, querría un sistema que siga funcionando incluso cuando asumimos algo bastante normal: laboratorios, gobiernos, inversionistas y evaluadores responden también a sus propios incentivos.

La IA necesita reglas. Lo que no me convence es que quienes hoy lideran la carrera terminen diseñando esas reglas, aportando la evidencia y ayudando a elegir a los árbitros que decidirán quién puede seguir compitiendo.

Phonoskeleton usa machine learning para llevar esas relaciones a un espacio tridimensional, combinando embeddings, modelado secuencial y segmentación musical.

Un espacio común para las canciones

Phonoskeleton empieza en el multiverso. Cada punto representa una canción y su posición depende de cómo se relaciona con las demás.

Para construir ese mapa necesitaba una representación comparable entre canciones. Los embeddings que usamos dentro de cada tema no sirven aquí porque se entrenan de forma independiente y cada uno aprende su propio sistema de coordenadas.

Para resolverlo usamos MERT. El modelo convierte cada canción en un embedding de 768 dimensiones dentro de un espacio compartido. Luego calculamos las distancias entre canciones y usamos MDS (multidimensional scaling) para reducirlas a tres dimensiones.

Canciones con representaciones similares quedan cerca. A medida que aumenta la distancia entre sus embeddings, también se separan dentro del multiverso.

Desde aquí podemos elegir una canción y entrar en ella. Ahí cambia el problema: ya no queremos comparar canciones completas, sino representar cómo evoluciona una sola canción en el tiempo.

Leer una canción

Al seleccionar una canción entramos a su análisis. La trayectoria tridimensional ocupa el centro y alrededor aparecen las señales que ayudan a entenderla: secciones, recurrencia, tonalidad, tempo y tensión armónica.

La barra inferior muestra la estructura detectada. Cada bloque representa una sección y las repeticiones comparten la misma etiqueta. No intentamos decidir si una sección es verso, coro o puente. Nos interesa detectar cuándo una parte de la canción vuelve a aparecer.

La matriz de recurrencia (seccion en el panel derecho) permite verlo con más detalle. Cada eje representa el tiempo y cada celda mide la similitud entre dos momentos de la canción. Cuando una secuencia reaparece más adelante, aparecen patrones fuera de la diagonal principal.

Debajo está la curva de novedad. Los picos marcan cambios fuertes respecto al contexto reciente y sirven para revisar dónde deberían aparecer los límites entre secciones. También son útiles para detectar segmentaciones que no tienen mucho sentido al compararlas con la señal.

El resto de las mediciones completa la lectura. La tonalidad proviene de la información armónica, mientras que tempo y métrica dependen de la estimación conjunta de beats y downbeats. La tensión armónica sigue cuánto se aleja cada momento del centro tonal reciente.

Esta vista terminó siendo útil también para revisar el propio análisis. Cuando una sección, un retorno o una transición parecía incorrecta, podía contrastarla con las demás representaciones antes de cambiar el modelo.

Cómo aprende Phonoskeleton una canción

Cada canción se analiza por separado. Demucs divide primero el audio en voz, batería, bajo y resto. Después partimos esas señales en pequeñas ventanas y describimos cada una con 64 características acústicas y temporales.

Esas 64 dimensiones son difíciles de visualizar, así que entrenamos una red neuronal con arquitectura '64 → 256 → 256 → 3'. La salida son tres coordenadas para cada ventana, es decir, un punto en el espacio. Durante el entrenamiento le pedimos al modelo algo bastante intuitivo.

Al ordenar esos puntos según el tiempo aparece la trayectoria de la canción.

La trayectoria describe cambios relativamente locales. Para entender estructuras más largas necesitamos otra escala. Los beats y downbeats nos dicen dónde están los pulsos y compases, y All-In-One usa esa secuencia para detectar dónde empieza y termina cada sección y cuáles vuelven a aparecer.

Phonoskeleton combina así dos niveles de análisis. El embedding sigue cómo cambia el sonido momento a momento y la segmentación agrupa esos cambios en estructuras que duran varios compases. De esa combinación salen la trayectoria y las secciones que vemos en pantalla.

Qué permite hacer Phonoskeleton

Phonoskeleton puede usarse para explorar catálogos musicales sin depender solo de género, artista o etiquetas. El multiverso permite recorrer canciones según la similitud aprendida por el modelo y encontrar temas cercanos a una referencia.

La vista interna sirve para otro tipo de análisis. Productores, músicos o investigadores pueden comparar estructura, instrumentación y recurrencia sin revisar cada canción manualmente. Dos temas pueden aparecer cerca en el multiverso y organizarse de formas muy distintas una vez entramos en ellos.

También hay aplicaciones en búsqueda y recomendación musical. Podemos encontrar canciones parecidas en conjunto, pero también piezas que compartan una estructura, una progresión o ciertos patrones de instrumentación. La similitud puede definirse según qué aspecto de la música queremos comparar, en lugar de depender siempre de una única representación por canción.

La demo también deja una conclusión práctica. Comparar canciones completas y entender qué ocurre dentro de una canción requieren escalas distintas. Phonoskeleton permite moverse entre ambas dentro de la misma interfaz.

El flujo es bastante directo: subo un video, SAM propone etiquetas y máscaras, yo apruebo o corrijo esas propuestas, exporto la data en formato COCO/YOLO, entreno el student y uso ese modelo para anotar la siguiente tanda de videos.

En otras palabras, una pequeña fábrica de etiquetas: SAM propone, el humano (yo en este caso) corrige, el student aprende, y el proceso se repite con menos trabajo manual.

Cómo funciona el flywheel

Nuestra pequeña fábrica de etiquetas tiene tres actores principales: SAM, el humano, , y el alumno.

SAM funciona como profesor, o teacher model. Hace el primer pase sobre el video y propone etiquetas, máscaras o tracks. No necesito que sea perfecto. De hecho, si esperara perfección probablemente nunca construiría nada útil con esto. Lo que necesito es que produzca una primera versión razonable, algo suficientemente bueno como para que corregirlo sea más rápido que empezar desde cero.

El humano está en el medio. En este caso, yo.

Mi trabajo no es dibujar cada objeto manualmente. Mi trabajo es mirar las propuestas de SAM y decidir: esto sirve, esto está mal, esto necesita corrección, esto no debería estar. Ese cambio parece pequeño, pero cambia bastante la economía de la anotación. Pasas de crear etiquetas desde cero a editar las etiquetas generadas por un modelo.

Luego viene el alumno, o student model.

El alumno no intenta ser más general que SAM. Esa no es la idea. SAM ya tiene el conocimiento amplio. El alumno aprende algo más específico: mi distribución. Mis videos, mis clases, mis ángulos de cámara, mis decisiones sobre qué cuenta como etiqueta válida y qué no.

Entonces el ciclo queda así:

1. SAM hace el primer pase.

2. El humano aprueba, corrige o rechaza.

3. Las anotaciones aprobadas se exportan como COCO o YOLO.

4. Entreno un student con esa data.

5. El student anota la siguiente tanda.

6. El humano vuelve a revisar.

Y otra vez.

Al inicio, SAM carga casi todo el peso porque todavía no hay dataset. Después de algunas rondas, el student empieza a hacerse útil en las partes repetibles. Probablemente se equivoca bastante al comienzo, sobre todo si la data es escasa. Pero ese también es el punto: sus errores vuelven al loop.

El modelo nunca deja mi sala

Una decisión de diseño fue que Annotator corra localmente. Los videos no se suben a ningún servicio externo, las máscaras se guardan en disco, la base vive en SQLite y los modelos corren en la GB10 (NVIDIA DGX Spark).

Esto suena cómodo hasta que recuerdas que ahora todos los problemas también son tuyos. Latencia, memoria, drivers, modelos cargados, tracking de video, exportaciones, entrenamiento del student. No hay una nube mágica absorbiendo el caos al otro lado.

La primera decisión fue no tratar a SAM como un servicio remoto y stateless. En Annotator, SAM vive dentro del backend. El modelo se carga una vez por sesión para evitar recargarlo cada vez que mandamos una imagen o video. De esta forma, las iteraciones posteriores son más baratas. Es una decisión pequeña, pero cambia la sensación de la app.

En video, el problema es distinto. Ya no estás peleando solo contra una imagen pesada, sino contra una secuencia de frames. SAM puede trackear objetos, pero cada frame ocupa un espacio en la memoria, y la GB10 tiene un pool grande compartido entre CPU y GPU, no una cantidad infinita.

Así que Annotator no procesa videos largos como si fueran una sola cosa. Extrae frames con un límite, muestra cuántos frames vas a generar antes de empezar, procesa tracking por chunks y libera memoria entre pasadas.

También puse límites explícitos de memoria. Un OOM local no es una excepción abstracta en algún servidor lejano. Es tu máquina congelándose, modo zombie, en tu sala mientras tú miras la pantalla con cara de “ah, claro”.

Después vino la parte más específica del modelo.

Gran parte del costo estaba en el vision encoder, no en el prompt. Probé varios caminos. Algunos dieron mejoras marginales. Otros fueron más educativos, como TensorRT corriendo rápido pero produciendo salidas que no coincidían bien con la implementación de PyTorch.

Lo que sí funcionó, utilizar torch.compile, y cambiar a FP8 las capas más pesadas del encoder visual, de forma iterativa, cuidando no colapsar la calidad del modelo. Con eso terminé con una mejora end-to-end de 1.47x sin pérdida medible de calidad.

Aprendizajes

El punto del flywheel es bastante simple: reducir costo manual y aumentar velocidad con cada vuelta.

SAM hace el primer pase. Yo corrijo. El student aprende de lo aprobado. Si el loop funciona, la siguiente tanda debería tomar menos tiempo que la anterior. No porque el sistema sea perfecto, sino porque cada ronda funciona mejor.

La otra parte es correr todo localmente. Me gusta tener los videos, las máscaras, la base y los modelos en mi máquina, pero eso también significa que siempre hay algo que optimizar: memoria, latencia, tracking, exports, training, estabilidad.

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.