¿Cuáles son los formatos estándar para compartir datos de aprendizaje automático?

TL; DR:
AFAIK, no existe un formato estándar para los conjuntos de datos de aprendizaje automático. CSV se usa en muchos casos, pero no es una solución perfecta.

Un formato para representar un conjunto de datos debe ser:

  1. Lo suficientemente rico como para representar características categóricas y numéricas.
  2. Lo suficientemente compacto como para no desperdiciar el almacenamiento de grandes conjuntos de datos.
  3. Ser legible por varias herramientas.
  4. No se puede cambiar arbitrariamente por estas herramientas.
  5. Ser local: partes de los datos se pueden transferir de forma independiente.
  6. Sea textual para habilitar el munging usando las herramientas del sistema / shell, y vea

La importancia de ser textual.

CSV (una fila por instancia, una columna por variable, columna de etiqueta opcional)
Responda todos los requisitos excepto el n. ° 4. Algunas alternativas son:

El formato de archivo de relación de atributos (ARFF) fue creado por Weka.
Tuve un momento difícil con ARFF en el pasado, pero otros trabajan con él sin quejarse.

Con respecto a la respuesta de @Justin Rising,
En http://www.win-vector.com/blog/2…, John Mount sugiere utilizar volcados de SQL, Json o “TSV fuerte” para la representación de datos, para evitar conversiones automáticas realizadas por Excel.

http://scikit-learn.org/stable/d… también menciona http://svmlight.joachims.org/ – otro formato.

Apache Mahout utiliza un formato de archivo de secuencia, que es binario, pero escala bien para Hadoop.

Relacionado pero diferente es el lenguaje de marcado de modelo predictivo (consulte también Representación de soluciones predictivas en PMML): este estándar representa el modelo de aprendizaje automático.

En los últimos años, el código de vectorización se ha combinado con el código de modelado y esto ha demostrado ser personalizado en la práctica. Al trabajar con los clientes de la empresa, vimos con qué frecuencia los ingenieros se atascaban al tener que volver a implementar cosas como TF-IDF, lo que impedía centrarse en la aplicación en cuestión.

En esa medida, desarrollamos Canova para enfocarnos en este problema explícito, así como en muchos otros problemas en el espacio de vectorización (los formatos son uno de ellos):

deeplearning4j / Canova

Algunos ejemplos de esto en la práctica serían:

  • Convierta el conjunto de datos UCI Iris basado en CSV en formato de texto vectorial abierto svmLight (con un lenguaje de transformación para expresar transformaciones por columna)
  • Convierta el conjunto de datos MNIST de archivos binarios sin formato al formato de texto svmLight

Tomamos la idea de los formatos de entrada y salida de MapReduce de Hadoop y los aplicamos a la arquitectura de Canova y la vectorización. En ese sentido, puede trabajar con cualquier conjunto de datos en Canova para el que tenga un formato de entrada (o puede escribir uno) y luego representar los vectores de salida en formato vectorial que tenga sentido para su herramienta de modelado (ARFF, svmLight, LibSVM, etc.) . De esta manera, hemos desacoplado el proceso de vectorización del proceso de modelado y tiene mucho sentido práctico para los flujos de trabajo de aprendizaje automático. Para conversiones de texto puro a vector, estamos implementando un conjunto de complementos del motor de vectorización (TF-IDF [ya en], word2vec, etc.) listos para usar. Hay soporte inicial para algunos formatos de imagen personalizados (MNIST) y la transformación CSV a vectores listos para usar. También hay fontanería en el proyecto para agregar audio y video en el corto plazo (Q3-2015). Otro aspecto de Canova es que nos hemos centrado en la experiencia de usuario (UX) de tal manera que se maneja toda la línea de comandos para que la gente vaya más rápido (aunque puede usarla desde la API, ala Hadoop).

Para resumir: Canova es la “piedra de rosetta” de la vectorización que desvincula el proceso de vectorización del proceso de modelado y es neutral en tiempo de ejecución (local, MR, etc.) y el conjunto de herramientas de aprendizaje automático (utilícelo con DL4J, Spark, etc.). Es de código abierto (ASF 2.0) y está alojado en Github. Canova puede convertir casi cualquier conjunto de datos que desee a cualquier otro formato que desee, lo que le permite concentrarse en tareas de ingeniería más urgentes.

El formato de entrada de Vowpal Wabbit [1] es similar al de svmlight (mencionado por Yuval) pero incluye soporte para pesos de importancia de muestra y espacios de nombres de características.

[1] https://github.com/JohnLangford/

El estándar de facto es un .csv, posiblemente comprimido. Todos los paquetes de software disponibles funcionan bien con ese formato, entonces, ¿por qué usar algo más?

Puede haber otros formatos para conjuntos de datos muy grandes. No estoy tan familiarizado con ese mundo.