¿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

Un RAG, acrónimo de «Retrieval Augmented Generation», representa una estrategia innovadora dentro del procesamiento de lenguaje natural. Se integra con los Grandes Modelos de Lenguaje (LLM, por sus siglas en inglés), tales como los que usa ChatGPT internamente (GPT-3.5-turbo o GPT-4), con el objetivo de mejorar la calidad de la respuesta y reducir ciertos comportamientos no deseados, como las alucinaciones.

Estos sistemas combinan los conceptos de vectorización y búsqueda semántica, junto con los LLMs para retroalimentar su conocimiento con información externa que no se incluyó durante su fase de entrenamiento y que, por lo tanto, desconocen.

Existen ciertos puntos a favor de utilizar RAGs:

• Permiten reducir el nivel de alucinaciones que presentan los modelos. A menudo, los LLM responden con información incorrecta (o inventada), aunque semánticamente su respuesta tenga sentido. A esto se le denomina alucinación. Uno de los objetivos principales del RAG es intentar reducir al máximo este tipo de situaciones, especialmente cuando se pregunta por cosas concretas. Esto es de alta utilidad si se quiere utilizar un LLM de forma productiva.
• Utilizando un RAG, ya no es necesario reentrenar el LLM. Este proceso puede llegar a ser costoso económicamente, dado que necesitaría GPUs para su entrenamiento, además de la complejidad que puede conllevar ese entrenamiento.
• Son sistemas económicos, rápidos (utilizan información indexada) y además, no dependen del modelo que se está utilizando (en cualquier momento podemos cambiarlo por de GPT-3.5 a Llama-2-70B).

En contra:

• Se va a necesitar ayuda de código, matemáticas y no va a ser tan sencillo como lanzar un simple prompt modificado.
• En la evaluación de los RAGs (veremos más adelante en el artículo) vamos a necesitar modelos potentes como GPT-4.

Ejemplo de caso de uso

Existen varios ejemplos donde los RAGs están siendo utilizados. El ejemplo más típico es su uso con chatbots para consultar información muy específica del negocio.

• En call-centers, los agentes están empezando a utilizar un chatbot con información sobre tarifas para poder responder de forma rápida y eficaz a las llamadas que reciben.
• En chatbots, como asistentes de venta donde están ganando popularidad. Aquí, los RAGs ayudan a responder a comparativas entre productos o cuando se consulta de manera específica sobre un servicio, haciendo recomendaciones de productos similares.

Componentes de un RAG

Vamos a hablar en detalle sobre los distintos componentes que conforman un RAG para poder tener una idea aproximada, y luego vamos a hablar de cómo interaccionan entre sí estos elementos.

Base de conocimiento

Este elemento es un concepto un poco abierto pero también lógico: se refiere al conocimiento objetivo del cual sabemos que el LLM no es consciente y que tiene un alto riesgo de alucinación. Este conocimiento, en formato de texto, puede estar en muchos formatos: PDF, Excel, Word, etc… Los RAGs avanzados son capaces también de detectar conocimientos en imágenes y tablas.

En general, todo contenido va a ser en formato de texto y va a necesitar ser indexado. Como los textos humanos son muchas veces desestructurados, se recurre a la subdivisión de los textos con estrategias llamadas chunking.

Modelo de Embeddings

Un embedding es la representación vectorial generada por una red neuronal entrenada sobre un cuerpo de datos (texto, imágenes, sonido, etc.) que es capaz de resumir la información de un objeto de ese mismo tipo hacia un vector dentro de un espacio vectorial concreto.

Por ejemplo, en el caso de un texto que se refiere a “Me gustan los patitos de goma azules” y otro que dice “Adoro los patitos de goma amarillos”, al ser convertidos en vectores, estos estarán más próximos en distancia entre sí que un texto que se refiere a “Los automóviles del futuro son los coches eléctricos”.

Este componente es el que, posteriormente, nos permitirá indexar de forma correcta los distintos chunks de información de texto.

Base de datos vectorial

Es el lugar donde vamos a guardar y indexar la información vectorial de los chunks mediante los embeddings. Se trata de un componente muy importante y complejo donde, afortunadamente, ya existen varias soluciones open source muy válidas para poder desplegarlo de forma «fácil», como Milvus o Chroma.

LLM

Es lógico, puesto que el RAG es una solución que nos permite ayudar a responder de forma más veraz a estos LLMs. No tenemos por qué restringirnos a modelos muy grandes y eficientes (pero no económicos como GPT-4), sino que pueden ser modelos más pequeños y más «sencillos» en cuanto a la calidad de respuestas y número de parámetros.

A continuación podemos ver una imagen representativa del proceso de carga de información en la base de datos vectoriales.

Funcionamiento a Alto Nivel

Ahora que tenemos un poco más claras las piezas del rompecabezas, surgen algunas dudas:

• ¿Cómo interactúan estos componentes entre sí?
• ¿Por qué hace falta una base de datos vectorial?

Vamos a intentar esclarecer un poco el asunto.

La idea intuitiva del funcionamiento de un RAG es la siguiente:

1. El usuario hace una pregunta. Transformamos la pregunta a un vector con el mismo sistema de embedding que hemos utilizado para guardar los chunks. Esto nos va a permitir comparar nuestra pregunta con toda la información que tenemos indexada en nuestra base de datos vectorial.
2. Calculamos las distancias entre la pregunta y todos los vectores que tenemos en la base de datos. Seleccionamos, con una estrategia, algunos de los chunks y añadimos todas esas piezas de información dentro del prompt como contexto. La estrategia más sencilla es basarse en seleccionar un número (K) de vectores más próximos a la pregunta.
3. Se lo pasamos al LLM para que genere la respuesta en base a los contextos. Es decir, el prompt contiene instrucciones + pregunta + contexto devuelto por el sistema de Retrieval. Por este motivo, la parte de «Augmentation» en las siglas del RAG, dado que estamos haciendo prompt augmentation.
4. El LLM nos ha generado una respuesta en base a la pregunta que hacemos y el contexto que le hemos pasado. Esta será la respuesta que el usuario va a visualizar.

Es por eso que necesitamos un embedding y la base de datos vectorial. Ahí está un poco el truco. Si eres capaz de encontrar información muy parecida a tu pregunta en tu base de datos vectorial, entonces puedes detectar contenido que puede ser de utilidad para tu pregunta. Pero para todo ello, necesitamos un elemento que nos permita poder comparar textos de forma objetiva y esa información no podemos tenerla guardada de forma desestructurada si necesitamos hacer preguntas de forma frecuente.

También, que al final todo esto termina en el prompt, que nos permite que sea un flujo independiente del modelo de LLM que vayamos a usar.

Evaluación de los RAG

De igual manera que los modelos de estadística o ciencias de datos más clásicos, tenemos una necesidad de cuantificar cómo está funcionando un modelo antes de utilizarlo de manera productiva.

La estrategia más básica (por ejemplo, para medir la efectividad de una regresión lineal) consiste en dividir el conjunto de datos en distintas partes como train y test (80 y 20% respectivamente), entrenando el modelo en train y evaluando en test con métricas como el root-mean-square error, dado que el conjunto de test son datos que no ha visto el modelo. Sin embargo, un RAG no consta de entrenamiento sino de un sistema compuesto de distintos elementos donde una de sus partes es usar un modelo de generación de texto.

Más allá de esto, aquí ya no tenemos datos cuantitativos (es decir, números) y la naturaleza del dato consiste en texto generado que puede variar en función de la pregunta que le hagamos, el contexto detectado por el sistema de Retrieval y incluso el comportamiento no determinista que tienen los modelos de redes neuronales.

Una estrategia básica que podemos pensar es en ir analizando a mano qué tan bueno está funcionando nuestro sistema, en base a hacer preguntas y ver cómo están funcionando las respuestas y los contextos devueltos. Pero este enfoque se vuelve impracticable cuando queremos evaluar todas las posibilidades de preguntas en documentos muy grandes y de forma recurrente.

¿Entonces, cómo podemos hacer esta evaluación?

El truco: Aprovechando los propios LLMs. Con ellos podemos construir un conjunto de datos sintético con el que se haya simulado la misma acción de hacer preguntas a nuestro sistema, tal como si un humano lo hubiera hecho. Incluso le podemos añadir un nivel de fineza mayor: utilizar un modelo más inteligente que el anterior y que funcione como un crítico, que nos indique si lo que está sucediendo tiene sentido o no.

Ejemplo de conjunto de datos de evaluación

Aquí lo que tenemos son muestras de Pregunta-Respuesta de cómo hubiera funcionado nuestro sistema de RAG simulando las preguntas que le podría hacer un humano en comparativa al modelo que estamos evaluando. Para hacer esto, necesitamos dos modelos: el LLM que utilizaríamos en nuestro RAG, por ejemplo, GPT-3.5-turbo (Answer) y otro modelo con mejor funcionamiento para generar una “verdad” (Ground Truth), como GPT-4.

Es decir, en otras palabras, el ChatGPT 3.5 sería el sistema generador de preguntas y el ChatGPT 4 sería como la parte crítica.

Una vez generado nuestro conjunto de datos de evaluación, lo que nos queda es cuantificar numéricamente con algún tipo de métrica.

Métricas de Evaluación

La evaluación de las respuestas es algo nuevo pero ya existen proyectos de código abierto que logran cuantificar de forma efectiva la calidad de los RAGs. Estos sistemas de evaluación permiten medir la parte de «Retrieval» y «Generation» por separado.

Faitfulness Score

Mide la veracidad de nuestras respuestas dado un contexto. Es decir, con qué porcentaje lo que se pregunta es verdad en función del contexto conseguido a través de nuestro sistema.  Esta métrica sirve para intentar controlar las alucinaciones que pueden tener los LLMs. Un valor muy bajo en esta métrica implicaría que el modelo se está inventando cosas, aunque se le dé un contexto. Por lo tanto, es una métrica que debe estar lo más cercano a uno.

Answer Relevancy Score

Cuantifica la relevancia de la respuesta en base a la pregunta que se le hace a nuestro sistema. Si la respuesta no es relevante a lo que le preguntamos, no nos está respondiendo adecuadamente. Por lo tanto cuanto más alta sea esta métrica, mejor.

Context Precision Score

Evalua si todos los elementos de nuestros ground-truth ítems dentro de los contextos, son rankeados de forma prioritaria o no.

Context Recall Score

Cuantifica si el contexto devuelto se alinea con la respuesta anotada. En otras palabras, cómo de relevante es el contexto respecto a la pregunta que hacemos. Una valor bajo indicaría que el contexto devuelto es poco relevante y no nos ayuda a responder la pregunta.

El cómo todas estas métricas se están evaluando es un poco más complejo pero podemos encontrar ejemplos bien explicados en la documentación de RAGAS.

Ejemplo práctico utilizando LangChain, OpenAI y ChromaDB

Vamos a utilizar el framework de LangChain que nos permite construir un RAG de forma muy fácil.

El dataset que vamos a utilizar es un ensayo de Paul Graham, un dataset típico y pequeño en cuanto a tamaño.

La base de datos vectorial que vamos a utilizar va a ser Chroma, open-source y con plena integración con LangChain. El uso de esta va a ser completamente transparente, utilizando los parámetros por defecto.

NOTA: Cada llamada a un modelo asociado, tiene un coste monetario y conviene revisar el pricing de OpenAI. Nosotros vamos a trabajar con un dataset pequeño de 10 preguntas pero si se escalase, el coste podría incrementarse.

import os
from dotenv import load_dotenv  

load_dotenv() # Configurar OpenAI API Key

from langchain_community.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
from langchain.prompts import ChatPromptTemplate

embeddings = OpenAIEmbeddings(
    model="text-embedding-ada-002"
)

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size = 700,
    chunk_overlap = 50
)

loader = TextLoader('paul_graham/paul_graham_essay.txt')
text = loader.load()
documents = text_splitter.split_documents(text)
print(f'Número de chunks generados gracias al documento: {len(documents)}')

vector_store = Chroma.from_documents(documents, embeddings)
retriever = vector_store.as_retriever()

Número de chunks generados gracias al documento: 158

Dado que el texto del libro está en inglés, debemos de hacer nuestro template de prompt esté en inglés.

from langchain.prompts import ChatPromptTemplate

template = """Answer the question based only on the following context. If you cannot answer the question with the context, please respond with 'I don't know':

Context:
{context}

Question:
{question}
"""

prompt = ChatPromptTemplate.from_template(template)

Ahora vamos a definir nuestro RAG mediante LCEL. El modelo a utilizar que responderá a las preguntas de nuestro RAG va a ser GPT-3.5-turbo.  Importante es que el parámetro de la temperatura esté a 0 para que el modelo no sea creativo.

from operator import itemgetter

from langchain_openai import ChatOpenAI
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough 

primary_qa_llm = ChatOpenAI(model_name="gpt-3.5-turbo", temperature=0)

retrieval_augmented_qa_chain = (
    {"context": itemgetter("question") | retriever, "question": itemgetter("question")}
    | RunnablePassthrough.assign(context=itemgetter("context"))
    | {"response": prompt | primary_qa_llm, "context": itemgetter("context")}
)

.. y ahora es posible hacerle ya preguntas a nuestro sistema RAG.

question = "What was doing the author before collegue? "

result = retrieval_augmented_qa_chain.invoke({"question" : question}) 

print(f' Answer the question based: {result["response"].content}')

Answer the question based: The author was working on writing and programming before college.

También podemos investigar cuales han sido los contextos devueltos por nuestro retriever. Como hemos mencionado, la estrategia de Retrieval es la por defecto y nos devolverá los top 4 contextos para responder a una pregunta.

display(retriever.get_relevant_documents(question))

display(retriever.get_relevant_documents(question))
[Document(page_content="What I Worked On\n\nFebruary 2021\n\nBefore college the two main things I worked on, outside of school, were writing and programming. I didn't write essays. I wrote what beginning writers were supposed to write then, and probably still are: short stories. My stories were awful. They had hardly any plot, just characters with strong feelings, which I imagined made them deep.", metadata={'source': 'paul_graham/paul_graham_essay.txt'}),
 Document(page_content="Over the next several years I wrote lots of essays about all kinds of different topics. O'Reilly reprinted a collection of them as a book, called Hackers & Painters after one of the essays in it. I also worked on spam filters, and did some more painting. I used to have dinners for a group of friends every thursday night, which taught me how to cook for groups. And I bought another building in Cambridge, a former candy factory (and later, twas said, porn studio), to use as an office.", metadata={'source': 'paul_graham/paul_graham_essay.txt'}),
 Document(page_content="In the print era, the channel for publishing essays had been vanishingly small. Except for a few officially anointed thinkers who went to the right parties in New York, the only people allowed to publish essays were specialists writing about their specialties. There were so many essays that had never been written, because there had been no way to publish them. Now they could be, and I was going to write them. [12]\n\nI've worked on several different things, but to the extent there was a turning point where I figured out what to work on, it was when I started publishing essays online. From then on I knew that whatever else I did, I'd always write essays too.", metadata={'source': 'paul_graham/paul_graham_essay.txt'}),
 Document(page_content="Wow, I thought, there's an audience. If I write something and put it on the web, anyone can read it. That may seem obvious now, but it was surprising then. In the print era there was a narrow channel to readers, guarded by fierce monsters known as editors. The only way to get an audience for anything you wrote was to get it published as a book, or in a newspaper or magazine. Now anyone could publish anything.", metadata={'source': 'paul_graham/paul_graham_essay.txt'})]

Evaluando nuestro RAG

Ahora que ya tenemos nuestro RAG montado gracias a LangChain, nos falta evaluarlo. 

Parece que tanto LangChain como LlamaIndex empiezan a tener maneras de evaluar de forma fácil los RAGs sin moverse del framework. Sin embargo, por ahora, la mejor opción es utilizar RAGAS, una librería que ya habíamos mencionado y está específicamente diseñada con ese propósito. Internamente, va a utilizar GPT-4 como modelo crítico, tal y como hemos mencionado anteriormente.

from ragas.testset.generator import TestsetGenerator
from ragas.testset.evolutions import simple, reasoning, multi_context
text = loader.load()
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size = 1000,
    chunk_overlap = 200
)
documents = text_splitter.split_documents(text)

generator = TestsetGenerator.with_openai()
testset = generator.generate_with_langchain_docs(
    documents, 
    test_size=10, 
    distributions={simple: 0.5, reasoning: 0.25, multi_context: 0.25}
)
test_df = testset.to_pandas()
display(test_df)

test_questions = test_df["question"].values.tolist()
test_groundtruths = test_df["ground_truth"].values.tolist()
answers = []
contexts = []
for question in test_questions:
  response = retrieval_augmented_qa_chain.invoke({"question" : question})
  answers.append(response["response"].content)
  contexts.append([context.page_content for context in response["context"]])

from datasets import Dataset # HuggingFace
response_dataset = Dataset.from_dict({
    "question" : test_questions,
    "answer" : answers,
    "contexts" : contexts,
    "ground_truth" : test_groundtruths
})
from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_recall,
    context_precision,
)

metrics = [
    faithfulness,
    answer_relevancy,
    context_recall,
    context_precision,
]

results = evaluate(response_dataset, metrics)
results_df = results.to_pandas().dropna()

Visualizamos las distribuciones estadísticas que salen:

results_df.plot.hist(subplots=True,bins=20)

Podemos observar que el sistema no es perfecto aunque hemos generado solamente 10 preguntas (haría falta generar muchas más) y también se puede observar que en una de ellas, la pipeline del RAG ha fallado en crear el ground truth.

Aun así podríamos sacar algunas conclusiones:

• algunas veces no es capaz de dar respuestas muy veraces (faithfulness)
• la relevancia de la respuesta es variable pero consistentmente buena (answer_relevancy)
• el context recall es perfecto pero el context precision ya no tanto

Ahora aquí nos podemos plantear probar con distintos elementos:

• cambiar el embedding utilizado por uno que podemos encontrar en HuggingFace MTEB Leaderboard.
• mejorar el sistema de retrieval con estrategias diferentes a la por defecto
• evaluar con otros LLMs

Con estas posibilidades, es viable analizar cada una de esas estrategias anteriores y escoger la que mejor se ajuste a nuestros datos o criterios monetarios.

Conclusiones

En este artículos hemos visto en qué consiste un RAG y cómo podemos evaluar un workflow completo. Todo esta materia está en auge ahora mismo dado que es una de las alternativas más eficaces y económicas para evitar el fine-tuning de los LLMs. 

Es posible que se encuentren nuevas métricas, nuevos frameworks, que hagan la evaluación de estos más sencilla y eficaz; pero en los próximos artículos no solo vamos a poder ver su evolución, sino también cómo llevar a production una arquitectura basada en RAGs.