En esta publicación de blog, queremos brindar un vistazo detrás de las cortinas sobre cómo extraemos información con el procesamiento del lenguaje natural (NLP). Aprenderá cómo aplicar modelos Transformer de última generación para este problema y cómo pasar de una idea de modelo ML a la integración en la aplicación Digits.
La información se puede extraer de texto no estructurado a través de un proceso llamado Reconocimiento de entidad nombrada (NER). Este concepto de PNL ha existido durante muchos años y su objetivo es clasificar los tokens en categorías predefinidas, como fechas, personas, ubicaciones y entidades.
Por ejemplo, la siguiente transacción podría transformarse en el siguiente formato estructurado:
Habíamos visto resultados sobresalientes de las implementaciones de NER aplicadas a otras industrias y estábamos ansiosos por implementar nuestro propio modelo de NER relacionado con la banca. En lugar de adoptar un modelo NER previamente entrenado, imaginamos un modelo construido con un número mínimo de dependencias. Esa avenida nos permitiría actualizar continuamente el modelo mientras mantenemos el control de «todas las partes móviles». Teniendo esto en cuenta, descartamos las herramientas disponibles como la implementación de SpaCy NER o los modelos HuggingFace para NER. Terminamos construyendo nuestro modelo NER interno basado solo en TensorFlow 2.x y la biblioteca del ecosistema Texto de TensorFlow.
Cada proyecto de Machine Learning comienza con los datos, y este también lo hizo. Decidimos qué información relevante queríamos extraer (p. Ej., Ubicación, URL del sitio web, nombres de las partes, etc.) y, en ausencia de un conjunto de datos públicos existente, decidimos anotar los datos nosotros mismos.
Hay una serie de herramientas comerciales y de código abierto disponibles para la anotación de datos, que incluyen:
La herramienta óptima varía con cada proyecto y es una cuestión de costo, velocidad y UI útil. Para este proyecto, nuestro impulsor clave para nuestra selección de herramientas fue la calidad de la interfaz de usuario y la velocidad del procesamiento de la muestra, y elegimos doccano.
Luego, al menos un revisor humano evaluó cada transacción seleccionada, y esa persona marcaría las subcadenas relevantes como se muestra arriba. El producto final de este paso de procesamiento fue un conjunto de datos de transacciones anotadas junto con el carácter inicial y final de cada entidad dentro de la cadena.
Si bien los modelos NER también pueden basarse en métodos estadísticos, establecimos nuestros modelos NER en una arquitectura ML llamada Transformers. Esta decisión se basó en dos factores principales:
- Los transformadores proporcionan una mejora importante en la PNL en lo que respecta a la comprensión del lenguaje. En lugar de evaluar una oración token por token, la forma en que las redes recurrentes realizarían esta tarea, los transformadores utilizan un mecanismo de atención para evaluar las conexiones entre los tokens.
- Los transformadores permiten la evaluación de hasta 512 tokens simultáneamente (y algunos evalúan incluso más tokens).
La arquitectura del modelo inicial basada en la atención fue la Representación de codificador bidireccional de transformadores (BERT, para abreviar), publicado en 2019. En el artículo original de Google AI, el autor ya destacó las posibles aplicaciones de NER, lo que nos dio la confianza de que nuestro enfoque transformador podría funcionar.
Además, habíamos implementado previamente varias otras aplicaciones de aprendizaje profundo basadas en arquitecturas BERT y pudimos reutilizar nuestras bibliotecas compartidas existentes. Esto nos permitió desarrollar un prototipo en poco tiempo.
Los modelos BERT se pueden usar como modelos previamente entrenados, que inicialmente se entrenan en corpi multilingües en dos tareas generales: predecir tokens de máscara y predecir si la siguiente oración tiene una conexión con la anterior. Esta formación general crea una comprensión del lenguaje general dentro del modelo. Los modelos previamente entrenados son proporcionados por varias empresas, por ejemplo, por Google a través de TensorFlow Hub. los el modelo previamente entrenado se puede ajustar con precisión durante una fase de formación específica para una tarea. Esto requiere menos recursos computacionales que entrenar un modelo desde cero.
La arquitectura BERT puede calcular hasta 512 tokens simultáneamente. BERT requiere tokenización de WordPiece que divide palabras y oraciones en trozos frecuentes de palabras. La siguiente oración de ejemplo se convertiría en token de la siguiente manera:
Digits crea un motor en tiempo real
[b’dig’, b’##its’, b’builds’, b’a’, b’real’, b’-‘, b’time’, b’engine’]
Hay una variedad de modelos BERT previamente entrenados disponibles en línea, pero cada uno tiene un enfoque diferente. Algunos modelos son específicos del idioma (por ejemplo, CamemBERT para francés o Beto para español), y otros modelos se han reducido en su tamaño mediante la destilación o poda del modelo (por ejemplo, ALBERT o DistilBERT).
Nuestro modelo prototipo fue diseñado para clasificar la secuencia de tokens que representan la transacción en cuestión. Convertimos los datos anotados en una secuencia de etiquetas que coincidían con la cantidad de tokens generados a partir de las transacciones para el entrenamiento. Luego, entrenamos el modelo para clasificar cada etiqueta de token:
En la figura anterior, observa las fichas «O». Tales tokens representan tokens irrelevantes, y entrenamos al clasificador para que los detecte también.
El modelo prototipo nos ayudó a demostrar un ajuste comercial de la solución ML antes de participar en la integración completa del modelo. En Digits, desarrollamos nuestros prototipos en portátiles Jupyter respaldados por GPU. Tal proceso nos ayuda a iterar rápidamente. Luego, una vez que confirmamos un caso de uso comercial para el modelo, nos enfocamos en la integración del modelo y la automatización de las actualizaciones de la versión del modelo a través de nuestras canalizaciones MLOps.
En general, usamos TensorFlow Extended (TFX) para actualizar las versiones de nuestro modelo. En este paso, convertimos el código de la notebook en TensorFlow Ops, y aquí convertimos nuestros pasos de preprocesamiento de datos prototipo en TensorFlow Transform Ops. Este paso adicional nos permite luego entrenar nuestras versiones de modelo de manera efectiva, evitar sesgos de servicio de entrenamiento y, además, nos permite «hornear» nuestra lógica comercial interna en nuestros modelos de ML. Este último beneficio nos ayuda a reducir las dependencias entre nuestros modelos ML y nuestra canalización de datos o integraciones de back-end.
Estamos ejecutando nuestras canalizaciones TFX en las canalizaciones Vertex AI de Google Cloud. Este servicio administrado nos libera de mantener un clúster de Kubernetes para Kubeflow Pipelines (lo que hicimos antes de usar Vertex AI).
Nuestros modelos de producción se almacenan en depósitos de Google Cloud Storage y TFServing nos permite cargar versiones del modelo directamente desde el almacenamiento en la nube. Debido a la carga dinámica de las versiones del modelo, no necesitamos crear contenedores personalizados para nuestra configuración de servicio de modelos; podemos usar las imágenes prediseñadas del equipo de TensorFlow.
A continuación, se muestra una configuración mínima para la implementación de Kubernetes:
apiVersion: apps / v1 kind: Metadatos de implementación:… nombre: tensorflow-serve-deployment spec:… template:… spec: containers: – nombre: tensorflow-serve-container image: tensorflow / serve: 2.5.1 comando: – / usr / local / bin / tensorflow_model_server args: – –port = 8500 – –model_config_file = / serve / models / config / models.conf – –file_system_poll_wait_seconds = 120…
Tenga en cuenta el argumento adicional –file_system_poll_wait_seconds en la lista anterior. De forma predeterminada, TFServing comprobará el sistema de archivos en busca de nuevas versiones del modelo cada 2 segundos. Esto puede generar grandes costos de almacenamiento en la nube, ya que cada verificación desencadena una operación de lista y los costos de almacenamiento se facturan en función del volumen de red utilizado. Para la mayoría de las aplicaciones, está bien reducir la verificación del sistema de archivos a cada 2 minutos (establezca el valor en 120 segundos) o deshabilitarlo por completo (establezca el valor en 0).
Para facilitar el mantenimiento, mantenemos todas las configuraciones específicas del modelo en un ConfigMap específico. El archivo generado es luego consumido por TFServing en el arranque.
apiVersion: v1 kind: ConfigMap metadata: namespace: ml-deployments name:
Después de la implementación inicial, comenzamos a iterar para optimizar la arquitectura del modelo para obtener resultados de alto rendimiento y baja latencia. Esto significó optimizar nuestra configuración de implementación para arquitecturas similares a BERT y optimizar los modelos entrenados de BERT. Por ejemplo, optimizamos la integración entre nuestros trabajos de Dataflow de procesamiento de datos y nuestras implementaciones de ML, y compartimos nuestro enfoque en nuestra charla reciente en Apache Beam Summit 2021.
El modelo NER desplegado nos permite extraer multitud de información de texto no estructurado y ponerla a disposición a través de Digits Search.
A continuación, se muestran algunos ejemplos de nuestras extracciones de modelos NER:
El producto final
En Digits, un modelo ML nunca es en sí mismo el producto final. Nos esforzamos por deleitar a nuestros clientes con experiencias bien diseñadas que están estrechamente integradas con los modelos de ML, y solo entonces somos testigos del producto final. Entran en juego muchos factores adicionales:
Latencia frente a precisión
Un modelo preentrenado más reciente (por ejemplo, BART o T5) podría haber proporcionado una mayor precisión del modelo, pero también habría aumentado sustancialmente la latencia del modelo. Dado que procesamos millones de transacciones a diario, quedó claro que la latencia del modelo es fundamental para nosotros. Por lo tanto, dedicamos una cantidad significativa de tiempo a la optimización de nuestros modelos entrenados.
Diseño para escenarios de falsos positivos
Siempre habrá falsos positivos, independientemente de lo sorprendente que sea la precisión del modelo antes de la implementación del modelo. Esfuerzos de diseño de productos que se centran en comunicar los resultados predichos de ML a los usuarios finales es fundamental. En Digits, esto es especialmente importante porque no podemos arriesgar la confianza de los clientes en cómo Digits maneja sus datos financieros.
Automatización de implementaciones de modelos
La inversión en nuestra configuración de implementación de modelos automatizada nos ayudó a brindar soporte para la reversión de modelos. Todos los cambios en los modelos implementados están controlados por versiones., y las implementaciones se ejecutan automáticamente desde nuestro sistema CI / CD. Esto proporciona un flujo de trabajo de implementación consistente y transparente para nuestro equipo de ingeniería.
Diseñar una estrategia de control de versiones para el lanzamiento y la reversión
Para ayudar a la implementación fluida del modelo y un análisis cuantitativo holístico antes de la implementación, implementamos dos versiones del mismo modelo ML y usamos las etiquetas de versión de TFServing (por ejemplo, etiquetas de «lanzamiento» y «pre-lanzamiento») para diferenciarlas. Además, utilizamos una tabla de versión activa que permite reversiones de versiones, tan simples como actualizar un registro de base de datos.
Ayudar a los clientes, no alienarlos
Por último, pero no menos importante, el objetivo de nuestro Los modelos de ML siempre deben ser para ayudar a nuestros clientes en sus tareas en lugar de alienarlos. Eso significa que nuestro objetivo no es reemplazar a los humanos o sus funciones, sino ayudar a nuestros clientes con tareas engorrosas. En lugar de pedirle a la gente que extraiga información manualmente de cada transacción, ayudaremos a nuestros clientes completando previamente a los proveedores extraídos, pero ellos siempre mantendrán el control. Si cometemos un error, Digits facilita la sobrescritura de nuestras sugerencias. De hecho, aprenderemos de nuestros errores y actualizaremos nuestros modelos de ML en consecuencia.
Consulte estos excelentes recursos para obtener más información sobre los modelos NER y Transformer:
Sobre el Autor
Hannes Hapke es ingeniero de aprendizaje automático en Digits. Como experto en desarrolladores de Google, Hannes es coautor de dos publicaciones sobre aprendizaje automático: «PNL en acción» de Manning Publishing y «Building Machine Learning Pipelines» de O’Reilly Media. En Digits, se centra en la ingeniería de ML y aplica su experiencia en PNL para avanzar en la comprensión de las transacciones financieras.
Suscríbase al boletín gratuito insideBIGDATA.
Únase a nosotros en Twitter: @ InsideBigData1 – https://twitter.com/InsideBigData1