Aprendizaje profundo – una serie de preguntas ingenuas sobre caffe

Estoy tratando de entender los conceptos básicos de caffe, en particular para usar con python.

Tengo entendido que la definición del modelo (por ejemplo, una architecture de neural network dada) debe incluirse en el archivo '.prototxt' .

Y que cuando entrena el modelo en los datos usando '.prototxt' , guarda los parámetros de peso / modelo en un archivo '.caffemodel'

Además, existe una diferencia entre el archivo '.prototxt' utilizado para la capacitación (que incluye la tasa de aprendizaje y los parámetros de regularización) y el que se usa para la prueba / implementación, que no los incluye.

Preguntas:

  1. ¿Es correcto que el '.prototxt' es la base para el entrenamiento y que el '.caffemodel' es el resultado del entrenamiento (pesos), utilizando el '.prototxt' en los datos del entrenamiento?
  2. ¿Es correcto que exista un '.prototxt' para el entrenamiento y otro para las pruebas, y que solo haya pequeñas diferencias (velocidad de aprendizaje y factores de regularización en el entrenamiento), pero que la architecture nn (suponiendo que use redes neuronales) sea la misma? ?

Disculpas por estas preguntas básicas y posiblemente por suposiciones muy incorrectas, estoy haciendo una investigación en línea y las líneas anteriores resumen mi comprensión hasta la fecha.

Veamos uno de los ejemplos proporcionados con BVLC / caffe: bvlc_reference_caffenet .
Notarás que en realidad hay 3 archivos '.prototxt' :

  • train_val.prototxt : este archivo describe la architecture de red para la fase de entrenamiento.
  • depoly.prototxt : este archivo describe la architecture de red para el tiempo de prueba (“implementación”).
  • solver.prototxt : este archivo es muy pequeño y contiene “parámetros meta” para el entrenamiento. Por ejemplo, la política de tasas de aprendizaje , la regularización , etc.

La architecture de red representada por train_val.prototxt y deploy.prototxt debe ser mayormente similar. Hay algunas diferencias principales entre los dos:

  • Datos de entrada: durante el entrenamiento uno usualmente usa un conjunto predefinido de entradas para el entrenamiento / validación. Por lo tanto, train_val generalmente contiene una capa de entrada explícita, por ejemplo, la capa "HDF5Data" o una capa "Data" . Por otro lado, la deploy por lo general no sabe de antemano qué entradas obtendrá, solo contiene una statement:

     input: "data" input_shape { dim: 10 dim: 3 dim: 227 dim: 227 } 

    Eso declara qué entrada espera la red y cuáles deberían ser sus dimensiones.
    Alternativamente, uno puede poner una capa de "Input" :

     layer { name: "input" type: "Input" top: "data" input_param { shape { dim: 10 dim: 3 dim: 227 dim: 227 } } } 
  • Etiquetas de entrada: durante el entrenamiento, suministramos a la red los resultados esperados de la “verdad fundamental”; obviamente, esta información no está disponible durante el deploy .
  • Capas de pérdida: durante el entrenamiento se debe definir una capa de pérdida. Esta capa le dice al solucionador en qué dirección debe ajustar los parámetros en cada iteración. Esta pérdida compara la predicción actual de la red con la “verdad fundamental” esperada. El gradiente de la pérdida se propaga hacia atrás al rest de la red y esto es lo que impulsa el proceso de aprendizaje. Durante el deploy no hay pérdida y no hay propagación hacia atrás.

En caffe, usted suministra un train_val.prototxt describe la red, los conjuntos de datos train / val y la pérdida. Además, proporciona un solver.prototxt describe los parámetros meta para el entrenamiento. La salida del proceso de entrenamiento es un archivo binario .caffemodel que contiene los parámetros entrenados de la red.
Una vez que se entrenó a la red, puede usar deploy.prototxt con los parámetros de .caffemodel para predecir salidas para entradas nuevas e invisibles.

Sí, pero hay diferentes tipos de archivos .prototxt, por ejemplo

https://github.com/BVLC/caffe/blob/master/examples/mnist/lenet_train_test.prototxt

Esto es para la red de entrenamiento y pruebas.

para la línea de comandos, ypu puede usar un archivo de resolución que también es un archivo .prototxt, por ejemplo

https://github.com/BVLC/caffe/blob/master/examples/mnist/lenet_solver.prototxt