Cómo medir la similitud entre videos: 6 técnicas probadas y lecciones prácticas

Introducción

Comparar visualmente dos videos —¿qué tan parecidos se ven?— suele sonar trivial hasta que lo intentan en producción. En una prueba práctica el autor puso un clip de referencia y ocho versiones parecidas (todos cascadas) y esperó un trabajo de tarde: elegir un método, calcular una métrica y listo. En cambio, encontró resultados contradictorios, modelos lentos o poco discriminativos, y la necesidad de priorizar precisión antes que velocidad.

Este artículo adapta esas pruebas y recoge las lecciones principales, con foco en decisiones prácticas para equipos en América Latina: rendimiento local vs. APIs pagas, latencia, costo y cómo evitar trampas de calibración.

Por qué es más difícil de lo que parece

Si se comparan píxeles, se cae en la trampa: lo que importa es el “significado” —el sujeto, la dirección de la luz, la intensidad del agua— no sólo diferencias numéricas planas. En la práctica hay tres familias de enfoques:

• Embeddings (vectores): modelos que convierten frames en representaciones semánticas; precisos pero consumen tiempo o créditos si son remotos.
• Huellas (fingerprints / perceptual hashes): códigos compactos por frame —rápidos y baratos— pero menos sensibles a matices.
• Modelos multimodales/LLM de visión: pueden ver secuencias completas y comentar, pero suelen ser los más caros y frágiles en producción.

La lección: no existe la solución perfecta; normalmente deben priorizarse dos de tres propiedades: precisión, velocidad o costo.

Las seis técnicas evaluadas

En la prueba original se compararon seis métodos con los mismos clips y las mismas reglas de entrada (seis frames por clip, espaciados uniformemente, 384×216). Tres corrieron localmente y tres implicaron llamadas a APIs pagas. A continuación se describen sus comportamientos observados:

1) GPT Vision (visión con LLM)

Qué hace: recibe unos frames y genera una evaluación cualitativa y una puntuación de similitud. Qué mostró: resultó excelente explicando por qué dos clips difieren (paleta, tono, ambiente), pero sus puntuaciones fueron inconsistentes: números agrupados y variabilidad entre ejecuciones. Bueno para explicabilidad, malo para clasificar varios casi-iguales.

2) Gemini Flash (visión sobre video entero)

Qué hace: procesa el video completo y juzga similitud considerando movimiento y ritmo. Qué mostró: la gran ventaja teórica es que ve la dinámica y el pacing. En la práctica fue el más lento y susceptible a fallas; durante la prueba algunas peticiones devolvieron errores 503 o 429, y una de las comparaciones ni siquiera obtuvo resultado. Por eso puede ser inapropiado para pipelines en vivo.

3) CLIP embeddings (vectores por frame)

Qué hace: genera vectores por frame, se promedian y se compara por coseno. Qué mostró: corrió localmente en menos de un segundo por comparación y ofreció puntuaciones estables, con buena capacidad de ranking. Las puntuaciones tienden a agruparse en rangos altos, lo que reduce su interpretabilidad absoluta, pero funcionan muy bien para ordenar pares similares.

4) Perceptual hash (huella perceptual)

Qué hace: calcula un hash de 64 bits por frame y compara códigos. Qué mostró: extremadamente rápido y económico. Detecta duplicados evidentes y cambios fuertes, pero falla al captar diferencias sutiles de color, exposición o movimiento.

5) CV multi-metric (señales clásicas de OpenCV)

Qué hace: combina métricas tradicionales (histogramas, bordes, flujo) y las mezcla en una puntuación. Qué mostró: razonablemente rápido y configurable localmente. Ofrece control fino sobre qué aspectos priorizar, pero requiere ingeniería y no aporta la comprensión semántica de embeddings.

6) Gemini Embedding 2 (vectores multimodales)

Qué hace: embeddings nativos multimodales que se comparan por coseno. Qué mostró: aporta representación potente pero depende de llamadas a API y costos; se comportó bien en precisión pero con la penalidad de latencia/costo.

Cómo se montó una evaluación justa

Para evitar tests fáciles que favorezcan métodos poco robustos, el experimento usó intencionalmente una referencia y ocho clips muy parecidos (todos cascadas tropicales). Cada método recibió los mismos seis frames a 384×216. No hubo etiquetas humanas; la “verdad” se approximó promediando las puntuaciones de cinco de los métodos para crear un consenso. No es perfecto, pero evita sesgar hacia una sola técnica.

Encontramientos clave y la trampa de la calibración

• Priorizar precisión primero: una respuesta rápida pero equivocada no sirve. En la evaluación, se descartaron métodos que no clasificaban correctamente antes de mirar tiempo o costo.
• Velocidad como desempate: una vez que la precisión fue comparable, se puso atención en latencia y costos operativos.
• Calibración engañosa: muchas técnicas devuelven números (por ejemplo 88%) que no son equivalentes entre métodos. No asuman que 88 de una técnica equivale a 88 de otra. Es mejor usar los métodos para ranking relativo o recalibrar el umbral con datos propios.
• Muestreo de frames: tomar seis frames uniformes por clip y reducir resolución demostró ser suficiente para discriminar en la mayoría de los casos, y ahorra CPU/memoria.

Recomendaciones prácticas para equipos en América Latina

• Si su prioridad es despliegue económico y latencia baja (medios locales, moderación en tiempo cercano), prefieran métodos locales: CLIP embeddings o mixes clásicos de OpenCV son buenos puntos de partida.
• Si necesitan explicabilidad (por ejemplo para editores o revisiones humanas), use GPT Vision para obtener razonamientos en texto, pero no confíen en sus números para clasificación fina sin validación adicional.
• Si el movimiento y la secuencia temporal son críticos (análisis de pacing, detección de pequeñas diferencias de acción), un modelo que procese el video entero aporta valor, pero tenga en cuenta latencia y robustez: en la prueba Gemini Flash fue fiable conceptualmente pero demasiado lento y propenso a errores para producción en vivo.
• Para equipos con presupuesto limitado: prioricen huellas y métricas clásicas para detección inicial y completen con embeddings sólo en casos donde se necesite mayor discriminación.

Cómo construir su propia prueba

1. Reúna pares desafiantes y no sólo ejemplos obvios. 2. Use muestreo uniforme de frames (ej. 6 frames por clip a 384×216). 3. Compare métodos por ranking (no por valores absolutos). 4. Cree una etiqueta de consenso si no tiene anotadores humanos. 5. Mida latencia y tasa de fallos además de precisión.

Conclusión

No existe una “mejor” técnica universal: la elección depende de qué valoran más —precisión en casos sutiles, velocidad, costo, o explicabilidad— y del contexto operativo. En la prueba, algunos métodos fueron rápidos y estables (CLIP y enfoques locales), otros ofrecieron explicaciones útiles (GPT Vision) y otros vieron movimiento completo pero mostraron problemas de latencia y errores (Gemini Flash). El autor del experimento integró una de las técnicas en producción después de estas pruebas, enfatizando que la decisión práctica debe venir de un benchmark propio que refleje los contenidos y restricciones reales de cada equipo.

Para equipos latinoamericanos, la recomendación práctica es empezar con soluciones locales y baratas para filtrar y usar embeddings o LLMs multimodales sólo donde el caso de uso justifique el costo y la latencia.