Codifique propiedades de texto en varios idiomas en Amazon Neptune para entrenar modelos predictivos

Aprendizaje automático de Amazon Neptune es una capacidad de aprendizaje automático (ML) de Amazonas Neptuno que lo ayuda a hacer predicciones precisas y rápidas sobre los datos de su gráfico. Bajo el capó, Neptune ML utiliza Graph Neural Networks (GNN) para aprovechar simultáneamente la estructura del gráfico y las propiedades de nodo/borde para resolver la tarea en cuestión. Los métodos tradicionales solo usan propiedades y ninguna estructura gráfica (p. ej., XGBoost, Neural Networks), o solo una estructura gráfica y ninguna propiedad (p. ej., node2vec, Propagación de etiquetas). Para manipular mejor las propiedades del nodo/borde, los algoritmos de ML requieren que los datos sean datos numéricos con buen comportamiento, pero los datos sin procesar en una base de datos pueden tener otros tipos, como texto sin formato. Para hacer uso de estos otros tipos de datos, necesitamos pasos de procesamiento especializados que los conviertan de su tipo nativo en datos numéricos, y la calidad de los resultados de ML depende en gran medida de la calidad de estas transformaciones de datos. El texto sin procesar, como las oraciones, se encuentra entre los tipos más difíciles de transformar, pero el progreso reciente en el campo del Procesamiento del lenguaje natural (NLP) ha llevado a métodos sólidos que pueden manejar texto proveniente de varios idiomas y una amplia variedad de longitudes.

A partir de la versión 1.1.0.0, Neptune ML admite múltiples codificadores de texto (texto_rápido, texto_sbert, texto_palabra2vecy texto_tfidf), que brinda los beneficios de los avances recientes en NLP y permite la compatibilidad con propiedades de texto en varios idiomas, así como requisitos de inferencia adicionales sobre idiomas y longitud de texto. Por ejemplo, en un caso de uso de recomendación de trabajo, los puestos de trabajo en diferentes países se pueden describir en diferentes idiomas y la longitud de las descripciones de trabajo varía considerablemente. Además, Neptune ML admite una auto opción que elige automáticamente el mejor método de codificación en función de las características de la característica de texto en los datos.

En esta publicación, ilustramos el uso de cada codificador de texto, comparamos sus ventajas y desventajas y mostramos un ejemplo de cómo elegir los codificadores de texto correctos para una tarea de recomendación de trabajo.

¿Qué es un codificador de texto?

El objetivo de la codificación de texto es convertir las propiedades de borde/nodo basadas en texto en Neptune en vectores de tamaño fijo para usar en modelos de aprendizaje automático descendentes para tareas de clasificación de nodos o predicción de enlaces. La longitud de la función de texto puede variar mucho. Puede ser una palabra, una frase, una oración, un párrafo o incluso un documento con varias oraciones (el tamaño máximo de una sola propiedad es de 55 MB en Neptune). Además, las características del texto pueden estar en diferentes idiomas. También puede haber oraciones que contengan palabras en varios idiomas diferentes, que definimos como cambio de código.

A partir de la versión 1.1.0.0, Neptune ML le permite elegir entre varios codificadores de texto diferentes. Cada codificador funciona de manera ligeramente diferente, pero tiene el mismo objetivo de convertir un campo de valor de texto de Neptune en un vector de tamaño fijo que usamos para construir nuestro modelo GNN usando Neptune ML. Los nuevos codificadores son los siguientes:

• texto_rápido (nuevo) – Usos texto rápido codificación FastText es una biblioteca para el aprendizaje eficiente de la representación de texto. text_fasttext se recomienda para funciones que usan uno y solo uno de los cinco idiomas que admite fastText (inglés, chino, hindi, español y francés). los text_fasttext El método puede tomar opcionalmente el max_length campo, que especifica el número máximo de tokens en un valor de propiedad de texto que se codificará, después de lo cual se trunca la cadena. Puedes considerar una ficha como una palabra. Esto puede mejorar el rendimiento cuando los valores de propiedad de texto contienen cadenas largas, porque si max_length no se especifica, fastText codifica todos los tokens independientemente de la longitud de la cadena.
• texto_sbert (nuevo) – Utiliza la oración BERT (SBERTO) método de codificación. SBERT es un tipo de método de incrustación de oraciones que utiliza los modelos de aprendizaje de representación contextual, BERT-Networks. text_sbert se recomienda cuando el idioma no es compatible con text_fasttext. Neptune admite dos métodos SBERT: text_sbert128, que es el valor predeterminado si solo especifica text_sberty text_sbert512. La diferencia entre ellos es el número máximo de tokens en una propiedad de texto que se codifica. los text_sbert128 la codificación solo codifica los primeros 128 tokens, mientras que text_sbert512 codifica hasta 512 fichas. Como resultado, usando text_sbert512 puede requerir más tiempo de procesamiento que text_sbert128. Ambos métodos son más lentos que text_fasttext.
• texto_palabra2vec - Usos Palabra2Vec algoritmos publicados originalmente por Google para codificar texto. Word2Vec solo admite inglés.
• texto_tfidf – Utiliza un término frecuencia-documento de frecuencia inversa (TF-FDI) vectorizador para codificar texto. La codificación TF-IDF admite características estadísticas que las otras codificaciones no. Cuantifica la importancia o relevancia de las palabras en una propiedad de nodo entre todos los demás nodos.

Tenga en cuenta que text_word2vec y text_tfidf anteriormente eran compatibles y los nuevos métodos text_fasttext y text_sbert se recomiendan sobre los métodos antiguos.

Comparación de diferentes codificadores de texto

La siguiente tabla muestra la comparación detallada de todas las opciones de codificación de texto admitidas (text_fasttext, text_sberty text_word2vec). text_tfidf no es un método de codificación basado en modelos, sino una medida basada en recuentos que evalúa qué tan relevante es un token (por ejemplo, una palabra) para las características del texto en otros nodos o bordes, por lo que no incluimos text_tfidf para comparacion. Recomendamos usar text_tfidf cuando desea cuantificar la importancia o relevancia de algunas palabras en una propiedad de nodo o borde entre todas las demás propiedades de nodo o borde).

Tenga en cuenta los siguientes consejos de uso:

• Para valores de propiedad de texto en inglés, chino, hindi, español y francés, text_fasttext es la codificación recomendada. Sin embargo, no puede manejar casos en los que la misma oración contiene palabras en más de un idioma. Para otros idiomas además de los cinco que fastText apoyos, uso text_sbert codificación
• Si tiene muchas cadenas de texto de valor de propiedad más largas que, por ejemplo, 120 tokens, use el max_length campo para limitar el número de tokens en cada cadena que text_fasttext codifica

Para resumir, dependiendo de su caso de uso, recomendamos el siguiente método de codificación:

• Si sus propiedades de texto están en uno de los cinco idiomas admitidos, le recomendamos que utilice text_fasttext debido a su rápida inferencia. text_fasttext son las opciones recomendadas y también puede usar text_sbert en las dos excepciones siguientes.
• Si sus propiedades de texto están en diferentes idiomas, le recomendamos que utilice text_sbert porque es el único método admitido que puede codificar propiedades de texto que contienen palabras en varios idiomas diferentes.
• Si sus propiedades de texto están en un idioma que no es uno de los cinco idiomas admitidos, le recomendamos que utilice text_sbert porque soporta más de 50 idiomas.
• Si la longitud promedio de sus propiedades de texto es mayor a 128, considere usar text_sbert512 or text_fasttext. Ambos métodos pueden codificar secuencias de texto más largas.
• Si sus propiedades de texto están solo en inglés, puede usar text_word2vec, pero recomendamos usar text_fasttext por su rápida inferencia.

Demostración de caso de uso: tarea de recomendación de trabajo

El objetivo de la tarea de recomendación de trabajo es predecir qué trabajos solicitarán los usuarios en función de sus solicitudes anteriores, la información demográfica y el historial laboral. Esta publicación utiliza un conjunto de datos Kaggle abierto. Construimos el conjunto de datos como un gráfico de tipo de tres nodos: trabajo, usuarioy ciudad.

Un trabajo se caracteriza por su título, descripción, requisitos, ciudad ubicada y estado. Un usuario se describe con las propiedades de especialización, tipo de título, número de historial laboral, número total de años de experiencia laboral y más. Para este caso de uso, el título del trabajo, la descripción del trabajo, los requisitos del trabajo y las especializaciones están todos en forma de texto.

En el conjunto de datos, los usuarios tienen las siguientes propiedades:

• Estado – Por ejemplo, CA o 广东省 (chino)
• Clasificacion Mayor – Por ejemplo, Gerencia de Recursos Humanos o Lic Cytura Fisica (Español)
• Tipo de estudios – Por ejemplo, Licenciatura, Maestría, Doctorado o Ninguno
• HistorialDeTrabajo – Por ejemplo, 0, 1, 16, etc.
• TotalAñosExperiencia – Por ejemplo, 0.0, 10.0 o NAN

Los trabajos tienen las siguientes propiedades:

• Título – Por ejemplo, Asistente Administrativo o Lic Cultura Física (Español).
• Descripción – Por ejemplo, “Este puesto de asistente administrativo es responsable de realizar una variedad de funciones de apoyo administrativo y de oficina en las áreas de comunicaciones…”. El número promedio de palabras en una descripción es de alrededor de 192.2.
• Requisitos – Por ejemplo, “REQUISITOS DEL TRABAJO: 1. Atención a los detalles; 2. Capacidad para trabajar en un entorno de ritmo rápido; 3. Facturación…”
• Estado: – Por ejemplo, CA, NY, etc.

El tipo de nodo ciudad como Washington DC y Orlando FL solo tiene el identificador para cada nodo. En la siguiente sección, analizamos las características de diferentes funciones de texto e ilustramos cómo seleccionar los codificadores de texto adecuados para diferentes propiedades de texto.

Cómo seleccionar diferentes codificadores de texto

Para nuestro ejemplo, el Clasificacion Mayor y Título Las propiedades están en varios idiomas y tienen secuencias de texto cortas, por lo que text_sbert es recomendado. El código de muestra para el parámetros de exportación es como sigue. Para el text_sbert tipo, no hay otros campos de parámetros. Aquí elegimos text_sbert128 que no sea text_sbert512, porque la longitud del texto es relativamente más corta que 128.

"additionalParams": {
    "neptune_ml": {
        "version": "v2.0",
        "targets": [ ... ],
        "features": [
            {
                "node": "user",
                "property": "Major",
                "type": "text_sbert128"
            },
            {
                "node": "job",
                "property": "Title",
                "type": "text_sbert128",
            }, ...
        ], ...
    }
}

El Descripción y Requisitos las propiedades suelen estar en largas secuencias de texto. La longitud promedio de una descripción es de alrededor de 192 palabras, que es más larga que la longitud máxima de entrada de text_sbert (128). Nosotros podemos usar text_sbert512, pero puede resultar en una inferencia más lenta. Además, el texto está en un solo idioma (inglés). Por lo tanto, recomendamos text_fasttext con el en valor del lenguaje debido a su inferencia rápida y longitud de entrada no limitada. El código de muestra para el parámetros de exportación es como sigue. los text_fasttext la codificación se puede personalizar usando idioma y longitud máxima. language Se requiere un valor, pero max_length es opcional.

"additionalParams": {
    "neptune_ml": {
        "version": "v2.0",
        "targets": [ ... ],
        "features": [
            {
                "node": "job",
                "property": "Description",
                "type": "text_fasttext",
                "language": "en",
                "max_length": 256
            },
            {
                "node": "job",
                "property": "Requirements",
                "type": "text_fasttext",
                "language": "en"
            }, ...
        ], ...
    }
}

Se pueden encontrar más detalles de los casos de uso de recomendación de trabajo en el Tutorial del cuaderno Neptune.

Para fines de demostración, seleccionamos un usuario, es decir, el usuario 443931, que posee una Maestría en 'Administración y Recursos Humanos'. El usuario se ha postulado para cinco trabajos diferentes, titulados como "Gerente de recursos humanos (HR)", "Generalista de recursos humanos", "Gerente de recursos humanos", "Administrador de recursos humanos" y "Especialista sénior de nómina". Para evaluar el desempeño de la tarea de recomendación, eliminamos el 50% de los trabajos de aplicación (los bordes) del usuario (aquí eliminamos "Administrador de recursos humanos" y "Gerente de recursos humanos (HR)) e intentamos predecir la parte superior 10 trabajos a los que es más probable que solicite este usuario.

Después de codificar las características del trabajo y las características del usuario, realizamos una tarea de predicción de enlaces entrenando un modelo de red convolucional de gráficos relacionales (RGCN). El entrenamiento de un modelo de Neptune ML requiere tres pasos: procesamiento de datos, entrenamiento del modelo y creación de puntos finales. Después de que se haya creado el punto final de inferencia, podemos hacer recomendaciones para el usuario 443931. De los 10 trabajos principales previstos para el usuario 443931 (es decir, "Generalista de recursos humanos", "Gerente de recursos humanos (HR)", "Especialista sénior de nómina", Administrador de recursos”, “Analista de recursos humanos”, et al.), observamos que los dos trabajos eliminados se encuentran entre las 10 predicciones.

Conclusión

En esta publicación, mostramos el uso de los codificadores de texto recientemente admitidos en Neptune ML. Estos codificadores de texto son fáciles de usar y pueden admitir varios requisitos. En resumen,

• text_fasttext se recomienda para funciones que utilizan uno y solo uno de los cinco idiomas que admite text_fasttext.
• Se recomienda text_sbert para el texto que text_fasttext no admite.
• text_word2vec solo admite inglés y se puede reemplazar por text_fasttext en cualquier escenario.

Para obtener más detalles sobre la solución, consulte el Repositorio GitHub. Recomendamos utilizar los codificadores de texto en los datos de su gráfico para cumplir con sus requisitos. Simplemente puede elegir un nombre de codificador y establecer algunos atributos de codificador, mientras mantiene el modelo GNN sin cambios.

Sobre los autores

jiani zhang es científico aplicado de AWS AI Research and Education (AIRE). Trabaja en la resolución de aplicaciones del mundo real utilizando algoritmos de aprendizaje automático, especialmente problemas relacionados con lenguaje natural y gráficos.