¿Sabías que los árboles de decisión pueden ayudarte a resolver problemas complejos?

En este artículo, te revelaremos cómo en Bluetab utilizamos esta poderosa herramienta de análisis de datos con el fin de impulsar a las decisiones de nuestros clientes en diversas industrias usando AWS.

Árboles de decisión: herramientas poderosas para la toma de decisiones

Los árboles de decisión son diagramas que representan las posibles opciones, resultados y consecuencias de una decisión. Se construyen a partir de nodos que contienen preguntas o condiciones, y ramas que conectan las respuestas o acciones. De esta forma, se puede visualizar el flujo lógico de la decisión y elegir la mejor alternativa.

En Bluetab, creemos en la toma de decisiones inteligentes basadas en datos. Para lograrlo, utilizamos herramientas poderosas como los árboles de decisión, que son valiosos en una variedad de sectores. A continuación, exploraremos cómo aplicamos los árboles de decisión y los beneficios que ofrecen a nuestros clientes en diferentes industrias.

Clasificación y regresión con árboles de decisión

Clasificación: los árboles de decisión de clasificación son excelentes para segmentar y categorizar datos. En el contexto empresarial, se utilizan para tomar decisiones sobre la asignación de recursos, la identificación de oportunidades de mercado y la personalización de ofertas. En el sector de la salud, los árboles de clasificación ayudan a diagnosticar enfermedades en función de síntomas y pruebas.

Regresión: los árboles de regresión se centran en predecir valores numéricos. Se utilizan para proyectar rendimientos financieros, tasas de crecimiento y otros valores cuantitativos. En el sector financiero, son esenciales para predecir el rendimiento de inversiones y carteras.

Caso práctico: Árboles de decisión en el sector de la salud

Sector de la salud: En el sector de la salud, utilizamos los árboles de decisión para diagnosticar enfermedades en función de síntomas y pruebas. Por ejemplo, si un paciente tiene fiebre, dolor de garganta y tos, el árbol de decisión nos indica que lo más probable es que tenga una infección respiratoria y nos recomienda el tratamiento adecuado.

Beneficios de los árboles de decisión en diferentes sectores

• Toma de decisiones personalizadas: los árboles de decisión permiten decisiones precisas y personalizadas en función de los datos y las necesidades de cada sector.
• Eficiencia operativa: al automatizar procesos repetitivos y mejorar la toma de decisiones, las empresas pueden optimizar sus operaciones.

Caso práctico: árboles de decisión en el sector bancario

Sector bancario: En el sector bancario, los árboles de decisión son vitales para la gestión de riesgos y la personalización de servicios. Los bancos utilizan estos árboles para segmentar a los clientes en grupos según su comportamiento financiero, lo que les permite ofrecer productos y servicios financieros a medida. También son esenciales en la evaluación crediticia, donde garantizan préstamos más seguros y tasas de interés adecuadas. Además, los árboles de decisión se aplican en la prevención de fraudes, donde detectan patrones sospechosos y protegen los activos de los clientes.

Beneficios en banca:

• Gestión de riesgos: los árboles de decisión ayudan a evaluar y gestionar los riesgos crediticios, lo que es esencial en la industria bancaria.
• Personalización de servicios: los clientes bancarios reciben ofertas personalizadas que se ajustan a sus necesidades financieras, lo que mejora su satisfacción y lealtad.
• Prevención de fraudes: la detección temprana de transacciones fraudulentas protege a los clientes y a los bancos.

Decisiones Inteligentes en AWS: implementación de árboles de decisión y migración de datos

Introducción: 

En un mundo empresarial en constante evolución, la toma de decisiones informadas es clave para el éxito. Exploraremos ahora cómo la implementación de árboles de decisión en AWS y la migración de datos desde SQL Server pueden empoderar a las organizaciones en diferentes sectores. Analizaremos la arquitectura de soluciones en AWS que permite esta implementación y migración, detallando cada paso del proceso.

Arquitectura en AWS para Implementar árboles de decisión:

• Ingesta de datos: comenzamos considerando la ingesta de datos desde diversas fuentes. AWS Glue se destaca como una solución versátil que puede conectarse a una amplia variedad de fuentes de datos.
• Almacenamiento de datos: una vez que los datos se han ingestado, se almacenan de manera centralizada en Amazon S3. Esto proporciona un lugar único para la administración y acceso eficiente a los datos.
• Procesamiento de datos y generación de árboles de decisión: utilizamos AWS Glue para transformar y preparar los datos para su análisis. En esta etapa, AWS Lambda y AWS SageMaker entran en juego para implementar algoritmos de árboles de decisión, brindando un enfoque avanzado de aprendizaje automático.
• Análisis y consultas: una vez que se han generado los árboles de decisión, AWS Athena permite realizar consultas SQL interactivas en los datos almacenados en S3. Esto facilita la exploración de datos y la toma de decisiones basadas en los resultados de los árboles.

Migración de datos desde SQL Server a AWS:

• Ingesta de datos: cuando se trata de la migración de datos desde SQL Server de Microsoft, AWS Database Migration Service (DMS) es una herramienta valiosa. Facilita la migración de bases de datos completas o datos específicos de SQL Server a bases de datos compatibles con AWS, como Amazon RDS o Amazon Redshift.

Arquitectura de solución en AWS utilizando AWS S3, Glue, Lambda, SageMaker, S3 y Athena:

• Ingesta de datos: utilizamos AWS Database Migration Service (DMS) para transferir datos desde la fuente de datos SQL Server a una base de datos compatible con AWS.
• Transformación de datos: AWS Glue se encarga de transformar y preparar los datos recién migrados para su análisis.
• Generación de árboles de decisión: implementamos algoritmos de árboles de decisión utilizando AWS Lambda o AWS SageMaker para llevar a cabo análisis avanzados.
• Almacenamiento de datos: los datos procesados y los resultados de los árboles de decisión se almacenan en Amazon S3.
• Consultas y análisis: utilizamos AWS Athena para realizar consultas SQL interactivas en los datos almacenados en S3 y tomar decisiones basadas en los resultados.

Para la implementación de un arbol de clasificación vamos a utilizar los siguientes servicios: Amazon S3, Aws Glue Crawler, Aws Glue Job, IAM , Cloud Watch. 

Se seleccionan como mínimo estos servicios para poder mostrar los beneficios de este modelo.

Creacion del bucket en Amazon S3

Buscaremos ‘S3’ en la barra de busqueda y seleccionaremos el nombre del servicio para visualizar lo siguiente:

Daremos clic en ‘Crear Bucket’ y visualizaremos la siguiente pantalla:

Debemos colocar un nombre que se asocie a nuestro flujo de trabajo y seleccionar tambien la región como minimo.

Colocaran siguiente y podran observan una vista previa del bucket, luego dar en clic en crear bucket:

Para nuestro ejemplo práctico estamos seleccionando un csv publico llamado Iris. 

El conjunto de datos Iris contiene medidas de 150 flores (setosa, versicolor, virginica) con 4 características, usado comúnmente para clasificación.

Lógicamente para un modelo de ML deberiamos brindar una data ya transformada y trabajada con el propósito de tener las caracteristias y hacer las predicciones necesarias.

Daras clic en cargar y seleccionaras el csv:

Finalmente visualizaremos la carga con éxito y ya seremos capaces de obtener esta información desde otro servicios en AWS.

Creación del servicio AWS Glue Crawler

AWS Glue Crawler es una herramienta que descubre y cataloga automáticamente datos almacenados en diversos formatos y ubicaciones, facilitando la preparación y análisis de datos en AWS.

Buscaremos el servicio AWS Glue en la barra de busqueda, nos desplazaremos en la sección lateral izquierdo y daremos clic en Crawlers:

Daremos un nombre a nuestro Crawler y una descripción a elección personal, luego daremos clic en Next:

En el dropdown list de data source elegiremos el servicio de S3.

Luego colocaras Browse S3 y podras seleccionar el bucket creado previamente, deberías ser capaz de visualizar lo siguiente:

En la siguiente seccion podrás seleccionar algun rol si tienes configurado previamente, para este ejemplo crearemos un nuevol, le pondremos un nombre asociado a nuestro proceso.

Luego veremos la selección de nuestra base de datos Catalogo , sin embargo tendremos que crearlo de la siguiente manera dando clic en Add Database:

Ingresamores el nombre de la base de datos asociada a nuestro ejemplo:

Luego podremos agregar un prefijo de forma opcional cuando disponibilice los datos en el catalogo de AWS Glue, podría estar vacio también si no lo necesita. Seleccionaremos ejecución a demanda para nuestro caso.

Finalmente en la siguiente pestaña podremos visualizar creado nuestro crawler y le daremos clic en ‘Run crawler’. Deberiamos ver lo siguiente:

Creacion del Job en AWS Glue

Luego en la misma seccion lateral izquierda de AWS Glue buscaremos la seccion de ETL Job y crearemos un flujo con la interfaz grafica, haciendolo de esta manera podremos tener facilmente el código generado para tener acceso a nuestra fuente.

Luego de agregas nuestro objeto de catálogo y seleccionar lo que hemos creado previamente. Deberiamos visualizar el job de la siguiente manera:

Hasta aquí ya procederemos a colocar un nombre al job y agregar nuestro código. Haremos uso de las siguientes librerias:

`DecisionTreeClassifier` construye un modelo de árbol de decisión para clasificación.

`MulticlassClassificationEvaluator` evalúa su rendimiento multiclase. `CrossValidator` realiza validación cruzada, ajustando hiperparámetros con `ParamGridBuilder`.

Juntos, permiten la construcción, evaluación y ajuste eficaz de modelos de árboles de clasificación en PySpark MLlib.

A continuación, se muestra el código utilizado:

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
from pyspark.ml.feature import StringIndexer, VectorAssembler
from pyspark.ml.evaluation import MulticlassClassificationEvaluator
from pyspark.ml.tuning import CrossValidator, ParamGridBuilder
from pyspark.ml.classification import DecisionTreeClassifier
from pyspark.ml import Pipeline
from pyspark.sql.functions import col,udf
from pyspark.sql.window import Window
from pyspark.sql import functions as F
from awsglue.dynamicframe import DynamicFrame
from pyspark.sql.types import ArrayType, DoubleType

# Inicializar contexto de Spark y Glue
args = getResolvedOptions(sys.argv, ["JOB_NAME"])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args["JOB_NAME"], args)
# Nombre de la base de datos y tabla en el catálogo de AWS Glue
database_name = "db-decision-tree-iris"
input_table_name = "mliris_csv"
output_table_name = "mliris_results"
# Crear DynamicFrame desde el catálogo de Glue
input_dyf = glueContext.create_dynamic_frame.from_catalog(
    database=database_name,
    table_name=input_table_name,
)
# Convertir DynamicFrame a DataFrame
df = input_dyf.toDF()
# Añadir una columna de índice
df = df.withColumn("row_index", F.monotonically_increasing_id())
# Preprocessing: StringIndexer for categorical labels
stringIndexer  = StringIndexer(inputCol="species", outputCol="label")
# Preprocessing: VectorAssembler for feature columns
assembler = VectorAssembler(inputCols=["sepal_length", "sepal_width", "petal_length", "petal_width"], outputCol="features")
#data = assembler.transform(data)
# Split data into training and testing sets
train_data, test_data = df.randomSplit([0.8, 0.2], seed=42)
# Create a Decision Tree Classifier instance
dt = DecisionTreeClassifier(labelCol='label', featuresCol='features')
# Assemble all the steps (indexing, assembling, and model building) into a pipeline.
pipeline = Pipeline(stages=[stringIndexer, assembler, dt])
paramGrid = ParamGridBuilder() \
    .addGrid(dt.maxDepth,[3, 5, 7]) \
    .addGrid(dt.minInstancesPerNode, [1,3,5]) \
    .build()
crossval = CrossValidator(estimator=pipeline, estimatorParamMaps=paramGrid,
                      evaluator=MulticlassClassificationEvaluator(
                      labelCol='label', predictionCol='prediction', metricName='accuracy'),
                      numFolds=5)

cvModel = crossval.fit(train_data)
best_model = cvModel.bestModel
predictions = best_model.transform(test_data)
predictions.show(100,truncate=False)


# Evaluate the model performance
evaluator = MulticlassClassificationEvaluator(labelCol="label", predictionCol="prediction", metricName="accuracy")
accuracy = evaluator.evaluate(predictions)
print(f"Test Accuracy: {accuracy:.2f}")
precision = evaluator.evaluate(predictions, {evaluator.metricName: "weightedPrecision"})
print(f"Weighted Precision: {precision:.2f}")
recall = evaluator.evaluate(predictions, {evaluator.metricName: "weightedRecall"})
print(f"Weighted Recall: {recall:.2f}")
f1_score = evaluator.evaluate(predictions, {evaluator.metricName: "f1"})
print(f"F1 Score: {f1_score:.2f}")
# Acceder al modelo de árbol de decisión dentro del pipeline
tree_model = best_model.stages[-1]  # Suponiendo que el clasificador de árbol de decisión es el último paso en tu pipeline
# Obtener el resumen del modelo
print(tree_model._java_obj.toDebugString())
output_path = "s3://bucket-training-tree-decision/output/parquet_data/"
# Función UDF para convertir VectorUDT a lista
vector_to_list_udf = udf(lambda v: v.toArray().tolist(), returnType=ArrayType(DoubleType()))
# Convertir la columna probability a lista
df = predictions.withColumn("probability", vector_to_list_udf(col("probability")))
df = df.withColumn("rawPrediction", vector_to_list_udf(col("rawPrediction")))
df = df.withColumn("features", vector_to_list_udf(col("features")))
df_subset = df.select(*["sepal_length", "sepal_width", "petal_length", "petal_width", "species", "row_index", "label", "features", "prediction", "probability"])
# Escribir el DataFrame en formato Parquet en S3
df_subset.write.parquet(output_path, mode="overwrite")
# Finalizar trabajo
job.commit()

Como se visualiza el estado del job se encuentra en ‘Succeeded’:

Configuración de políticas mediante S3 y IAM

A continuación, debemos también configurar las políticas de IAM para el acceso desde Glue hacia S3. Iremos a la sección de permisos en nuestro bucket:

Editaremos la política de la siguiente manera:

Luego en IAM a nuestro rol de machine que creamos en la sección de AWS Grawler, añadiremos el rol de s3Full Access. Seleccionamos nuestro rol:

Verificamos que tengamos nuestra relacion de confianza de la siguiente manera:

Luego añadiremos el permiso de AmazonS3FullAccess.

Finalmente al agregar el permiso deberiamos de ver nuestros permisos de la siguiente manera:

Ahora mediante CloudWatch podremos visualizar el log de nuestro job, verificar si se guardo correctamente nuestro modelo y tambien poder ver una previsualización de las reglas y predicciones.

Aquí podemos visualizar nuestros resultados e incluso la regla de clasificación:

Aquí se puede visualizar los valores de Accuracy , weighted precision y recall, y el F1 Score. A continuación, se explica el significado de cada métrica.

1. Test Accuracy (Exactitud de Prueba):
   • Significado: proporción de predicciones correctas respecto al total de predicciones en el conjunto de prueba.
   • Utilidad: mide la precisión general del modelo y es especialmente útil cuando las clases están balanceadas.
2. Weighted Recall (Recuperación Ponderada):
   • Significado: promedio ponderado de las tasas de verdaderos positivos para cada clase.
   • Utilidad: evalúa la capacidad del modelo para recuperar instancias de cada clase, considerando el desequilibrio en la distribución de las clases.
3. Weighted Precision (Precisión Ponderada):
   • Significado: promedio ponderado de las precisiones para cada clase.
   • Utilidad: indica la proporción de instancias correctamente clasificadas entre las que el modelo predijo como positivas, considerando el desequilibrio de clases
4. F1 Score:
   • Significado: media armónica de precisión y recuperación. Cuantifica la relación equilibrada entre la precisión y la capacidad de recuperación del modelo.
   • Utilidad: útil en problemas de clasificación desbalanceados, ya que considera tanto los falsos positivos como los falsos negativos, proporcionando una métrica global de rendimiento del modelo. Un F1 Score alto indica un equilibrio entre precisión y recuperación.

Finalmente se guardaron los resultados de nuestro modelo en nuestro bucket en un folder llamado output, deberia verse de la siguiente manera:

Conclusión

Esta arquitectura de solución en AWS permite a las organizaciones no solo implementar árboles de decisión eficaces sino también migrar datos desde sistemas heredados como SQL Server. Ambos procesos se combinan para empoderar a las organizaciones en la toma de decisiones informadas, mejorando la eficiencia operativa y maximizando las oportunidades de mercado. Como puedes ver, los árboles de decisión son una herramienta muy útil para tomar decisiones inteligentes basadas en datos.

En Bluetab, te ayudamos a implementarlos en tu organización para que puedas mejorar tu eficiencia operativa, personalizar tus ofertas y aprovechar las oportunidades de mercado. Si quieres saber más sobre cómo podemos ayudarte, no dudes en contactarnos.

Introducción

El objetivo principal de este artículo es presentar una solución para el análisis y la ingeniería de datos desde el punto de vista del personal de negocio, sin requerir unos conocimientos técnicos especializados. 

Las compañías disponen de una gran cantidad de procesos de ingeniería del dato para sacarle el mayor valor a su negocio, y en ocasiones, soluciones muy complejas para el caso de uso requerido. Desde aquí, proponemos simplificar la operativa para que un usuario de negocio, que anteriormente no podía llevar a cabo el desarrollo y la implementación de la parte técnica, ahora será autosuficiente, y podrá implementar sus propias soluciones técnicas con lenguaje natural.

Para poder cumplir nuestro objetivo, vamos a hacer uso de distintos servicios de la plataforma Google Cloud para crear tanto la infraestructura necesaria como los distintos componentes tecnológicos para poder sacar todo el valor a la información empresarial.

Antes de comenzar

Antes de comenzar con el desarrollo del artículo, vamos a explicar algunos conceptos básicos sobre los servicios y sobre distintos frameworks de trabajo que vamos a utilizar para la implementación:

1. Cloud Storage[1]: Es un servicio de almacenamiento en la nube proporcionado por Google Cloud Platform (GCP) que permite a los usuarios almacenar y recuperar datos de manera segura y escalable.
2. BigQuery[2]: Es un servicio de análisis de datos totalmente administrado que permite realizar consultas SQL en conjuntos de datos masivos en GCP. Es especialmente eficaz para el análisis de datos a gran escala.
3. Terraform[3]: Es una herramienta de infraestructura como código (IaC) desarrollada por HashiCorp. Permite a los usuarios describir y gestionar la infraestructura utilizando archivos de configuración en el lenguaje HashiCorp Configuration Language (HCL). Con Terraform, puedes definir recursos y proveedores de manera declarativa, facilitando la creación y gestión de infraestructuras en plataformas como AWS, Azure y Google Cloud.
4. PySpark[4]: Es una interfaz de Python para Apache Spark, un marco de procesamiento distribuido de código abierto. PySpark facilita el desarrollo de aplicaciones de análisis de datos paralelas y distribuidas utilizando la potencia de Spark.
5. Dataproc[5]: Es un servicio de gestión de clústeres para Apache Spark y Hadoop en GCP que permite ejecutar eficientemente tareas de análisis y procesamiento de datos a gran escala. Dataproc admite la ejecución de código PySpark, facilitando la realización de operaciones distribuidas en grandes conjuntos de datos en la infraestructura de Google Cloud.

Qué es un LLM 

Un LLM (Large Language Model) es un tipo de algoritmo de inteligencia artificial (IA) que utiliza técnicas de deep learning y enormes conjuntos de datos para comprender, resumir, generar y predecir nuevos contenidos. Un ejemplo de LLM podría ser ChatGPT que hace uso del modelo GPT desarrollado por OpenAI. 

En nuestro caso, vamos a hacer uso del modelo Codey[6] (code-bison) que es un modelo implementado por Google que está optimizado para generar código ya que ha sido entrenado para esta especialización que se encuentra dentro del stack de VertexAI[7]

Y no solo es importante el modelo que vamos a utilizar, sino también el cómo lo vamos a utilizar. Con esto, me refiero a que es necesario comprender los parámetros de entrada que afectan directamente a las respuestas que nos dará nuestro modelo, en los que podemos destacar los siguientes:

• Temperatura (temperature): Este parámetro controla la aleatoriedad en las predicciones del modelo. Una temperatura baja, como 0.1, genera resultados más deterministas y enfocados, mientras que una temperatura alta, como 0.8, introduce más variabilidad y creatividad en las respuestas del modelo.

• Prefix (Prompt): El prompt es el texto de entrada que se proporciona al modelo para iniciar la generación de texto. La elección del prompt es crucial, ya que guía al modelo sobre la tarea específica que se espera realizar. La formulación del prompt puede influir en la calidad y relevancia de las respuestas del modelo, aunque hay que tener en cuenta la longitud para que cumpla con el  número máximo de tokens de entrada que es 6144.

• Tokens de salida (max_output_tokens): Este parámetro limita el número máximo de tokens que se generarán en la salida. Controlar este valor es útil para evitar respuestas excesivamente largas o para ajustar la longitud de la salida según los requisitos específicos de la aplicación.

• Recuento de candidatos (candidate_count): Este parámetro controla el número de respuestas candidatas que el modelo genera antes de seleccionar la mejor opción. Un valor más alto puede ser útil para explorar diversas respuestas potenciales, pero también aumentará el costo computacional.

Desarrollo del prompt

Una vez que hemos definido los parámetros y sabemos bien para qué sirve cada uno de ellos y comprendemos lo que es un prompt, vamos a enfocarnos en cómo utilizarlo e implementar uno que se pueda adaptar a nuestras necesidades.

Como se ha comentado anteriormente, el objetivo es generar tanto código Pyspark como terraform para poder realizar las tareas de creación de infraestructura y tratamiento del dato. Como son tareas totalmente distintas, como primera decisión importante para nuestro prompt se ha optado por dividirlo en dos partes específicas para que cada prompt esté entrenado con ejemplos para generar un lenguaje u otro.

Para cada uno de los prompt, se hace una introducción para especificar cuál va a ser el objetivo y qué peticiones se van a realizar, y después una serie de ejemplos en los que se le da un input en lenguaje natural simulando una petición, y posteriormente también se le da el output deseado para asignar el texto al código específico. El objetivo es generar un prompt estructurado que pueda ser procesado de manera eficiente por el modelo para que en los siguientes casos, pueda asociar los ejemplos que tiene disponibles con respuestas adecuadas.

Vamos a poner en práctica estos pequeños tips para ver una de las entradas al prompt de terraform:

Es importante implementar ejemplos lo más parecido posible a tu caso de uso para que las respuestas sean más precisas, y también que tenga bastantes ejemplos con variedad de peticiones para que sea más inteligente a la hora de devolver las respuestas. Una de las prácticas para que sea más interactiva la implementación del prompt, puede ser ir probando con distintas peticiones, y si no es capaz de hacer lo que se le ha pedido, se debería modificar las instrucciones.

Como hemos podido observar, el desarrollo del prompt sí necesitamos conocimientos técnicos para poder traducir las peticiones a código, por lo que esta tarea sí se debería de abordar por una persona técnica para posteriormente evadir a la persona de negocio. En otras palabras, necesitamos que una persona técnica genere la primera base de conocimiento para que luego las personas de negocio puedan hacer uso de este tipo de herramientas.

También se ha podido ver, que la generación de código en terraform es más compleja que la generación en Pyspark, por lo que se han requerido de más ejemplos de entrada en la realización del prompt de terraform para que se ajuste a nuestro caso de uso. Por ejemplo, hemos aplicado en los ejemplos que en terraform siempre cree un bucket temporal (temporary-files-dataproc) para que pueda ser utilizado por Dataproc.

Casos prácticos

Se han realizado tres ejemplos con peticiones distintas, requiriendo más o menos infraestructura y transformaciones para ver si nuestro prompt es lo suficientemente robusto. 

En el archivo ai_gen.py vemos el código necesario para hacer las peticiones y los tres ejemplos, en el que cabe destacar la configuración escogida para los parámetros del modelo:

• Se ha decidido darle valor 1 a candidate_count para que no tenga más que una respuesta final válida para devolver. Además que como se ha comentado, aumentar este número también lleva aumento de costes.
• El max_output_tokens se ha decidido 2048 que es el mayor número de tokens para este modelo, ya que si se necesita generar una respuesta con diversas transformaciones, no falle por esta limitación.
• La temperatura se ha variado entre el código terraform y Pyspark, para terraform se ha optado por 0 para que siempre dé la respuesta que se considera más cercana a nuestro prompt para que no genere más de lo estrictamente necesario para nuestro objetivo. En cambio para Pyspark se ha optado por 0.2 que es una temperatura baja para que no sea muy creativo, pero para que también pueda darnos diversas respuestas con cada llamada para también poder hacer pruebas de rendimiento entre ellas.

Vamos a realizar un ejemplo de petición que está disponible en el siguiente repositorio github, en el que está detallado en el README paso por paso para poder ejecutarlo tú mismo. La petición es la siguiente:

Ejecutamos  y vamos a analizar las salidas generadas en las carpetas generated/customers/python/etl.py y generated/terraform/main.tf.:

terraform {
 required_version = ">= 0.15"
 required_providers {
   google = "~> 5.0"
 }
}


resource "google_storage_bucket" "temporary_files" {
 project       = "my-cloud-project"
 name          = "temporary-files-dataproc"
 location      = "europe-southwest1"
 force_destroy = true
}


resource "google_storage_bucket" "sales_etl_bucket" {
 project       = "my-cloud-project"
 name          = "sales-etl-bucket"
 location      = "europe-southwest1"
 force_destroy = true
}


resource "google_storage_bucket_object" "sales_folder" {
 name    = "input/sales/"
 bucket  = google_storage_bucket.sales_etl_bucket.name
 content = " "
}


resource "google_storage_bucket_object" "customers_folder" {
 name    = "input/customers/"
 bucket  = google_storage_bucket.sales_etl_bucket.name
 content = " "
}


resource "google_bigquery_dataset" "raw_sales_data" {
 project       = "my-cloud-project"
 dataset_id    = "raw_sales_data"
 friendly_name = "Raw Sales Data"
 description   = "This dataset contains the raw sales data."
 location      = "europe-southwest1"
}


resource "google_bigquery_table" "customer_table" {
 project              = "my-cloud-project"
 dataset_id           = google_bigquery_dataset.raw_sales_data.dataset_id
 deletion_protection  = false
 table_id             = "customer_table"
 schema               = <<EOF
[
 {
   "name": "customer_id",
   "type": "INT64",
   "mode": "REQUIRED",
   "description": "The customer ID."
 },
 {
   "name": "name",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The customer's name."
 },
 {
   "name": "email",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The customer's email address."
 }
]
EOF
}


resource "google_bigquery_table" "sales_table" {
 project              = "my-cloud-project"
 dataset_id           = google_bigquery_dataset.raw_sales_data.dataset_id
 deletion_protection  = false
 table_id             = "sales_table"
 schema               = <<EOF
[
 {
   "name": "order_id",
   "type": "INT64",
   "mode": "REQUIRED",
   "description": "The order ID."
 },
 {
   "name": "product",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The product name."
 },
 {
   "name": "price",
   "type": "FLOAT64",
   "mode": "NULLABLE",
   "description": "The product price."
 },
 {
   "name": "amount",
   "type": "INT64",
   "mode": "NULLABLE",
   "description": "The product amount."
 },
 {
   "name": "customer_id",
   "type": "INT64",
   "mode": "REQUIRED",
   "description": "The customer ID."
 }
]
EOF
}


resource "google_bigquery_dataset" "master_sales_data" {
 project       = "my-cloud-project"
 dataset_id    = "master_sales_data"
 friendly_name = "Master Sales Data"
 description   = "This dataset contains the master sales data."
 location      = "europe-southwest1"
}


resource "google_bigquery_table" "bigtable_info" {
 project              = "my-cloud-project"
 dataset_id           = google_bigquery_dataset.master_sales_data.dataset_id
 deletion_protection  = false
 table_id             = "bigtable_info"
 schema               = <<EOF
[
 {
   "name": "customer_id",
   "type": "INT64",
   "mode": "REQUIRED",
   "description": "The customer ID."
 },
 {
   "name": "name",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The customer's name."
 },
 {
   "name": "email",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The customer's email address."
 },
 {
   "name": "order_id",
   "type": "INT64",
   "mode": "REQUIRED",
   "description": "The order ID."
 },
 {
   "name": "product",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The product name."
 },
 {
   "name": "price",
   "type": "FLOAT64",
   "mode": "NULLABLE",
   "description": "The product price."
 },
 {
   "name": "amount",
   "type": "INT64",
   "mode": "NULLABLE",
   "description": "The product amount."
 }
]
EOF
}

Vemos que va a añadir un bucket con dos carpetas para poder subir los datos a la carpeta correspondiente dependiendo si es sales o customer. También ha creado dos datasets, uno para la capa de raw para tener los datos según nos han venido de origen con las tablas de customers y sales, y el segundo dataset para la tabla final que almacenará el resultado de juntar la información de ambas tablas.

Vamos a revisar el código pyspark:

from pyspark.sql import SparkSession
from pyspark.sql import functions as F


# Configure Spark session
spark = SparkSession.builder.appName("SalesETL").getOrCreate()


# Define file paths
sales_path = "gs://sales-etl-bucket/input/sales/*.csv"
customers_path = "gs://sales-etl-bucket/input/customers/*.csv"


# Read CSV files into DataFrames
sales_df = spark.read.csv(sales_path, header=True, inferSchema=True)
customers_df = spark.read.csv(customers_path, header=True, inferSchema=True)


# Write tables to BigQuery
sales_df.write.format("bigquery") \
   .option("temporaryGcsBucket", "temporary-files-dataproc") \
   .option("table",  "raw_sales_data.sales_table") \
   .mode("overwrite") \
   .save()
customers_df.write.format("bigquery") \
   .option("temporaryGcsBucket", "temporary-files-dataproc") \
   .option("table",  "raw_sales_data.customer_table") \
   .mode("overwrite") \
   .save()


# Join sales and customers tables
bigtable_info_df = sales_df.join(customers_df, on="customer_id", how="inner")


# Write joined table to BigQuery
bigtable_info_df.write.format("bigquery") \
   .option("temporaryGcsBucket", "temporary-files-dataproc") \
   .option("table",  "master_sales_data.bigtable_info") \
   .mode("overwrite") \
   .save()


# Stop the Spark session
spark.stop()

Se puede observar que el código generado realiza la lectura por cada una de las carpetas e inserta cada dato en su tabla correspondiente. 

Para poder asegurarnos de que el ejemplo está bien realizado, podemos seguir los pasos del README en el repositorio GitHub[8] para aplicar los cambios en el código terraform, subir los ficheros de ejemplo que tenemos en la carpeta example_data y a ejecutar un Batch en Dataproc. 

Finalmente, vemos si la información que se ha almacenado en BigQuery es correcta:

• Tabla customer:

• Tabla sales:

• Tabla final:

De esta forma, hemos conseguido de a través de lenguaje natural, tener un proceso funcional totalmente operativo. Hay otro ejemplo que se puede ejecutar, aunque también animo a hacer más ejemplos, o incluso mejorar el prompt, para poder meterle ejemplos más complejos, y también adaptarlo a tu caso de uso.

Conclusiones y Recomendaciones

Al ser ejemplos muy concretos sobre unas tecnologías tan concretas, cuando se hace un cambio en el prompt en cualquier ejemplo puede afectar a los resultados, o también, modificar alguna palabra de la petición de entrada. Esto se traduce en que el prompt no es lo suficientemente robusto como para poder asimilar distintas expresiones sin afectar al código generado. Para poder tener un prompt y un sistema productivo, se necesita más entrenamiento y distinta variedad tanto de soluciones, peticiones, expresiones,. … Con todo ello, finalmente podremos tener una primera versión que poder presentar a nuestro usuario de negocio para que sea autónomo.

Especificar el máximo detalle posible a un LLM es crucial para obtener resultados precisos y contextuales. Aquí hay varios consejos que debemos tener en cuenta para poder tener un resultado adecuado:

• Claridad y Concisión:
  • Sé claro y conciso en tu prompt, evitando oraciones largas y complicadas.
  • Define claramente el problema o la tarea que deseas que el modelo aborde.
• Especificidad:
  • Proporciona detalles específicos sobre lo que estás buscando. Cuanto más preciso seas, mejores resultados obtendrás.
• Variabilidad y Diversidad:
  • Considera incluir diferentes tipos de ejemplos o casos para evaluar la capacidad del modelo para manejar la variabilidad.
• Feedback Iterativo:
  • Si es posible, realiza iteraciones en tu prompt basándote en los resultados obtenidos y el feedback del modelo.
• Prueba y Ajuste:
  • Antes de usar el prompt de manera extensa, realiza pruebas con ejemplos y ajusta según sea necesario para obtener resultados deseados.

Perspectivas Futuras

En el ámbito de LLM, las líneas futuras de desarrollo se centran en mejorar la eficiencia y la accesibilidad de la implementación de modelos de lenguaje. Aquí se detallan algunas mejoras clave que podrían potenciar significativamente la experiencia del usuario y la eficacia del sistema:

1. Uso de distintos modelos de LLM:

La inclusión de una función que permita a los usuarios comparar los resultados generados por diferentes modelos sería esencial. Esta característica proporcionaría a los usuarios información valiosa sobre el rendimiento relativo de los modelos disponibles, ayudándoles a seleccionar el modelo más adecuado para sus necesidades específicas en términos de precisión, velocidad y recursos requeridos.

2. Capacidad de retroalimentación del usuario:

Implementar un sistema de retroalimentación que permita a los usuarios calificar y proporcionar comentarios sobre las respuestas generadas podría ser útil para mejorar continuamente la calidad del modelo. Esta información podría utilizarse para ajustar y refinar el modelo a lo largo del tiempo, adaptándose a las preferencias y necesidades cambiantes de los usuarios.

3. RAG (Retrieval-augmented generation)

RAG (Retrieval-augmented generation) es un enfoque que combina la generación de texto y la recuperación de información para mejorar las respuestas de los modelos de lenguaje. Implica el uso de mecanismos de recuperación para obtener información relevante de una base de datos o corpus textual, que luego se integra en el proceso de generación de texto para mejorar la calidad y la coherencia de las respuestas generadas.

Enlaces de interés

Cloud Storage[1]: https://cloud.google.com/storage/docs

BigQuery[2]: https://cloud.google.com/bigquery/docs

Terraform[3]: https://developer.hashicorp.com/terraform/docs

PySpark[4]: https://spark.apache.org/docs/latest/api/python/index.html

Dataproc[5]: https://cloud.google.com/dataproc/docs

Codey[6]: https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/code-generation

VertexAI[7]: https://cloud.google.com/vertex-ai/docs

GitHub[8]: https://github.com/alfonsozamorac/etl-genai