Hoja de ruta¶
Propósito de este documento¶
Este documento enumera las directrices generales que los colaboradores principales están interesados en ver desarrolladas en scikit-learn. El hecho de que un elemento se liste aquí no es de ninguna manera una promesa de que va a suceder, ya que los recursos son limitados. Más bien, es una indicación de que la ayuda es bienvenida en este tema.
Declaración de objetivos: Scikit-learn en 2018¶
Once años después de la creación de Scikit-learn, mucho ha cambiado en el mundo del aprendizaje automático. Los cambios clave incluyen:
Herramientas computacionales: La explotación de GPUs, marcos de programación distribuidos como Scala/Spark, etc.
Bibliotecas Python de alto nivel para experimentación, procesamiento y gestión de datos: cuaderno de Jupyter, Cython, Pandas, Dask, Numba…
Cambios en el enfoque de la investigación en aprendizaje automático: aplicaciones de inteligencia artificial (donde la estructura de entrada es clave) con aprendizaje profundo, aprendizaje de representación, aprendizaje de refuerzo, transferencia de dominio, etc.
Un cambio más sutil en la última década es eso, debido a los intereses cambiantes en ML, Los estudiantes de doctorado en aprendizaje automático son más propensos a contribuir a Pyantch, Dask, etc. que a Scikit-learn, por lo que nuestro fondo de colaboradores es muy diferente al de hace una década.
Scikit-learn sigue siendo muy popular en la práctica para probar las técnicas canónicas de aprendizaje automático, en particular para aplicaciones en la ciencia experimental y en la ciencia de datos. Mucho de lo que proporcionamos está ya muy desarrollado. Pero su mantenimiento puede ser costoso y, por tanto, no podemos incluir nuevas implementaciones arbitrarias. Sin embargo, Scikit-learn también es esencial en la definición de un marco API para el desarrollo de componentes de aprendizaje automático interoperables externos a la biblioteca principal.
Por lo tanto, nuestros principales objetivos en esta ocasión son:
seguir manteniendo una colección de herramientas canónicas de alta calidad y bien documentadas para el tratamiento de datos y el aprendizaje automático dentro del ámbito actual (es decir, datos rectangulares en gran medida invariables al orden de las columnas y filas; predicción de objetivos con estructura simple)
mejorar la facilidad de desarrollo y publicación de componentes externos para los usuarios
mejorar la interoperabilidad con herramientas modernas de ciencia de datos (por ejemplo, Pandas, Dask) e infraestructuras (por ejemplo, procesamiento distribuido)
Muchos de los objetivos más precisos pueden encontrarse en la etiqueta API en el gestor de incidencias.
Objetivos arquitectónicos / generales¶
La lista está numerada no como indicación del orden de prioridad, sino para facilitar la referencia a puntos concretos. Por favor, añada nuevas entradas sólo al final. Tenga en cuenta que las entradas tachadas ya están hechas, y que intentamos mantener el documento actualizado mientras trabajamos en estos temas.
Mejora del manejo de Pandas DataFrames
Mejora el manejo de características categóricas
Los modelos basados en el árbol deben ser capaces de manejar características continuas y categóricas #12866 y #15550.
En cargadores de conjuntos de datos #13902Como transformadores genéricos para ser utilizados con ColumnTransforms (por ejemplo, codificación ordinal supervisada por correlación con la variable objetivo) #5853, #11805
Manejo de mezclas de variables categóricas y continuas
Mejora de la gestión de los datos que faltan
Más documentos didácticos
Más y más opciones se han añadido a scikit-learn. Como resultado, la documentación está abarrotada, lo que hace que sea difícil para los principiantes obtener una visión general. Se podría trabajar en la priorización de la información.
Pasar alrededor de la información que no es (X, y): Propiedades de muestra
Pasar información que no es (X, y): Propiedades de las características
Lo ideal es que los nombres o descripciones de las características estén disponibles para ajustarse a, por ejemplo. #6425 #6424
La gestión de cada característica (por ejemplo, «¿se trata de un texto nominal / ordinal / en inglés?») tampoco debería proporcionarse a los constructores de estimadores, idealmente, sino que debería estar disponible como metadatos junto a X. #8480
Pasar alrededor de la información que no es (X, y): Propiedades de objetivo
Hacer más fácil para usuarios externos escribir componentes compatibles con Scikit-learn
Soporta el remuestreo y la reducción de la muestra
Mejores interfaces para el desarrollo interactivo
Herramientas mejoradas para el diagnóstico de modelos e inferencia básica
Mejores herramientas para seleccionar hiperparámetros con estimadores transductivos
La búsqueda en cuadrícula y la validación cruzada no son aplicables a la mayoría de las tareas de conglomerados. La selección basada en la estabilidad es más pertinente.
Mejor soporte para construcción manual y automática de pipelines
Una forma más fácil de construir pipelines complejos y espacios de búsqueda válidos #7608 #5082 #8243
¿proporcionar rangos de búsqueda para los estimadores comunes?
cf. searchgrid
Mejora del seguimiento del ajuste
Paralelismo distribuido
Acepta los datos que cumplen con
__array_function__
Un paso adelante para sacar más provecho del núcleo
Dask permite una fácil ejecución fuera del núcleo. Aunque el modelo Dask probablemente no pueda adaptarse a todos los algoritmos de aprendizaje automático, la mayor parte del aprendizaje automático se realiza sobre datos más pequeños que el ETL, por lo que quizá podamos adaptarnos a una escala muy grande mientras soportamos solo una fracción de los patrones.
Soporte para trabajar con modelos previamente entrenados
Serialización de algunos estimadores compatible con las versiones anteriores
Actualmente la serialización (con pickle) se interrumpe entre versiones. Aunque no podamos evitar otras limitaciones de pickle en cuanto a seguridad, etc., sería estupendo ofrecer seguridad entre versiones desde la versión 1.0. Nota: Gael y Olivier piensan que esto puede causar una pesada carga de mantenimiento y que deberíamos gestionar las compensaciones. Una posible alternativa se presenta en el siguiente punto.
Documentación y herramientas para la gestión del ciclo de vida del modelo
Documentar las buenas prácticas para el despliegue y el ciclo de vida del modelo: antes de desplegar un modelo: fijar las versiones del código (numpy, scipy, scikit-learn, repo de código personalizado), el script de entrenamiento y un alias sobre cómo recuperar los datos históricos de entrenamiento + fijar una copia de un pequeño conjunto de validación + fijar las predicciones (probabilidades predichas para los clasificadores) en ese conjunto de validación.
Documento y herramientas para facilitar la gestión de la actualización de las versiones de scikit-learn:
Prueba a cargar el pickle anterior, si funciona, fija la predicción del conjunto de validación para detectar que el modelo serializado sigue comportándose igual;
Si joblib.load / pickle.load no funcionan, utiliza el script de entrenamiento de control de versiones + el conjunto de entrenamiento histórico para volver a entrenar el modelo y usa la predicción del conjunto de validación para afirmar que es posible recuperar el rendimiento de la predicción anterior: si no es el caso, probablemente hay un error en scikit-learn que debe ser reportado.
Todo en Scikit-learn debe probablemente ajustarse a nuestro contrato de API. Todavía estamos tomando decisiones sobre algunas de estas cuestiones relacionadas.
(Opcional) Mejorar el conjunto de tests comunes de scikit-learn para asegurarse de que (al menos para los modelos de uso frecuente) tienen predicciones estables a través de las versiones (para ser discutido);
Ampliar la documentación para mencionar cómo desplegar los modelos en entornos sin Python, por ejemplo ONNX. y utilizar las mejores prácticas anteriores para evaluar la consistencia predictiva entre las funciones de predicción de scikit-learn y ONNX en el conjunto de validación.
Documentar las buenas prácticas para detectar la derivación de la distribución temporal para el modelo desplegado y las buenas prácticas para el reentrenamiento en datos actuales sin causar regresiones catastróficas en el rendimiento predictivo.
Objetivos específicos de los subpaquetes¶
una implementación de apilamiento, #11047
variantes de kmeans para distancias no euclidianas, si podemos demostrar que éstas tienen beneficios más allá de conglomeración jerárquica.
la puntuación multimétrica es lenta #9326tal vez queremos ser capaces de recuperar más de múltiples métricas
el manejo de los estados aleatorios en los separadores de validación cruzada es un diseño pobre y contradice la validación de parámetros similares en los estimadores, #15177
explotar los algoritmos de warm-starting y path para que se pueda acceder a las ventajas de los objetos
EstimatorCVa través deGridSearchCVy utilizarlos en Pipelines. :issue:`1626La validación cruzada debería poder ser sustituida por estimaciones OOB siempre que se utilice un iterador de validación cruzada.
Deben evitarse los cálculos redundantes en las pipelines (relacionado con el punto anterior) cf daskml
Posibilidad de sustituir una implementación de vecinos más cercanos personalizada/aproximada/precalculada por la nuestra en todos/la mayoría de los contextos en los que se utilizan los vecinos más cercanos para el aprendizaje. #10463
Problemas de rendimiento con
Pipeline.memoryver «Todo en Scikit-learn debe ajustarse a nuestro contrato de API» arriba