Experimentando con GPT4o en un proyecto de Machine Learning. Una de mis estrategias

Recientemente, he estado explorando el uso del último modelo de OpenAI, GPT4o, en un proyecto¹ que he diseñado específicamente como un campo de pruebas. Este proyecto, basado en el conocido conjunto de datos MNIST, me ha permitido evaluar cómo este modelo de lenguaje puede actuar como un asistente eficaz en el análisis y la visualización de datos.

A lo largo de este artículo, compartiré el enfoque iterativo y las consideraciones más relevantes que surgieron durante este experimento, mostrando tanto los puntos fuertes como las áreas de mejora del modelo o del propio análisis.

Probando el enfoque iterativo

El enfoque iterativo, conocido por distintos nombres y distintos métodos, se basa en tomar una tarea muy amplia o compleja, y descomponerla en pasos accionables, retocando las consultas que le hacemos al modelo para conseguir resultados más precisos y alineados con lo que buscamos. En este proyecto, la tarea a realizar era un análisis exploratorio de los datos (EDA), una buena oportunidad para probar este enfoque. Esta tarea puede extenderse bastante, abarcando análisis y subanálisis, lo que la hace ideal para probar esto.

A continuación, profundizo en los pasos que he seguido en este proyecto en particular para darle un enfoque iterativo, así como las consideraciones de cada paso para conseguir que sea efectivo y valioso para nuestro trabajo.

Empezar pensando por tu cuenta (Brainstorming inicial sin influencia del modelo)

Para este proyecto en particular, el brainstorming se basaba en definir una estructura de pasos a seguir durante el EDA. He observado que algunas personas prefieren generar una consulta rápida y simple para el modelo desde el principio para obtener ideas y comenzar a iterar. Sin embargo, considero que esto puede ser un error.

Aunque es útil empezar a iterar con el modelo lo antes posible, siempre prefiero que la primera fase del brainstorming salga de mis propios conocimientos e ideas. No se trata de una defensa de “lo humano” vs “lo artificial”, sino de controlar el proceso. En este primer paso, decidimos quién será el guía del pensamiento, el que marcará las pautas. Si dejamos que el modelo tome la primera palabra, en cierto modo serán sus parámetros los que dirijan el proyecto.

Nuestros pensamientos están constantemente influenciados por estímulos internos y externos. Si consultamos al modelo antes de formarnos una opinión, nuestras ideas estarán condicionadas por su respuesta. Aunque generemos nuevas ideas a partir de lo que nos diga, estas tenderán a alinearse con las rutas que él propone.

Otro beneficio de este enfoque es que requiere esfuerzo cognitivo. Generar ideas por nuestra cuenta mantiene una carga cognitiva activa en la tarea, lo que involucra más a nuestro cerebro en el proceso, en lugar de simplemente consumir información pasivamente. Esto no solo promueve la creatividad, sino que también mejora la generación de ideas y la calidad de las mismas una vez involucramos al modelo.

Además, he comprobado que este enfoque mejora las respuestas del modelo. Al proporcionarle ideas generadas por nosotros, el modelo tiene un material nuevo y específico que no está presente en sus parámetros iniciales. Esto permite que el modelo construya sobre nuestras ideas, produciendo respuestas más personalizadas y en armonía con nuestro enfoque.

Invitar al modelo a pensar contigo (Segundo Brainstorming con revisión del modelo)

En este paso, es momento de involucrar al modelo en la generación de ideas. Le pasamos las ideas más interesantes de nuestro brainstorming inicial, para que nos ayude a refinarlas o genere nuevas ideas a partir de ellas.

En realidad, se pueden encadenar estos dos pasos en múltiples ciclos, generando ideas nuevas a partir de las ideas del modelo y añadiéndole esas nuevas ideas para generar más ideas. Esto dependerá del gusto del usuario y del tipo de proyecto que se tenga entre manos. La clave en esto, es conseguir un equilibrio entre el tiempo invertido en las distintas fases y el valor obtenido de cada una de ellas.

Estructurar los pasos generales a seguir

Una vez completada la fase de generación de ideas, buscamos crear una estructura inicial, formada por los pasos clave que se quieran tomar en el proceso.

El objetivo aquí es tener una estructura clara, lo más simple posible, que incluya sólo los pasos más relevantes. El proceso tomado, consiste en seleccionar todas las ideas y rutas generadas en el paso anterior, y saleccionar lo más interesante y valioso a explorar.

Como comenté previamente, a mí me gusta hacer esto primero por mi cuenta, para ver qué ideas son las que considero más interesantes para explorar. Luego le pido al modelo, que ya tiene todo el contexto de la tarea a partir del brainstorming, que seleccione una estructura, especificando la importancia de cada paso. Finalmente, comparo ambas estructuras y decido con qué me quedo y qué descarto.

Crear un prompt a partir de la estructura

El siguiente paso es crear nuestra “consulta base” para el modelo, en la que seremos lo más específicos posibles, porque a partir de esto, el modelo va a estructurar el resto de sus respuestas en el seguimiento de los distintos pasos del proyecto.

Esta consulta puede ser muy amplia, pero aquí comparto algunas cosas que me han venido bien en este caso:

• Definir la estructura de pasos que vamos a seguir durante el proyecto, explicando brevemente en qué consiste cada uno de los pasos para evitar ambigüedades con los titulares.
• Definir el tipo de asistencia que buscamos de parte del modelo, especificando su tono, el nivel de su lenguaje y otras cosas que nos interesen. Algo que ayuda es visualizar a nuestro compañero de trabajo ideal, y detallar las características que definen a ese compañero. ¿Cómo habla? ¿Qué lenguaje utiliza? ¿Tiene un rol más de profesor (respuestas claras y explicativas con ejemplos) o de compañero a nuestro nivel (respuestas más generales y amplias para que exploremos por nuestra cuenta)? ¿Nos hace preguntas o sólo nos cuenta cosas?
• Definir limitaciones que debe tener en cuenta en el proceso, es decir, volvemos a visualizar a nuestro compañero de trabajo ideal y hacemos una lista de todo lo que no queremos que haga; darnos introducciones o conclusiones, extenderse demasiado en sus respuestas, ser demasiado técnico, etc.
• Detallar cualquier contexto que le sea de utilidad, sobre nosotros, nuestro flujo de trabajo, el entorno de trabajo, herramientas usadas y demás. Básicamente, pensar que este compañero ha llegado nuevo y tenemos que comentarle, antes de que vea nada, el punto en el que estamos, las herramientas que estamos usando y cualquier detalle relevante para la tarea en cuestión.

El prompt no tiene que ser perfecto, de hecho, seguramente no lo sea, es normal que pasemos cosas por alto o seamos ambiguos en los prompts iniciales. Pero aquí es donde entra el proceso iterativo; a medida que vamos viendo lo que el modelo nos responde, podemos ir ajustando para enfocar su asistencia al resultado que buscamos.

Por esto mismo, aquí sí aplica lo que hablamos antes; es mucho más importante que creemos cuanto antes la consulta inicial y la probemos, antes de pasarnos de perfeccionistas intentando cubrir todos los matices posibles con nuestra consulta.

De hecho, si no tienes del todo claro qué poner, es mejor poner lo importante para evitar ruido. A medida que el modelo responda, te darás cuenta de lo que te gusta y lo que no te gusta de sus respuestas, o si le falta información clave para entender el proyecto o la tarea.

Aquí muestro un ejemplo de consulta que usé en este proyecto:

__CONSULTA__
Profundiza en el análisis exploratorio de los datos para mi proyecto, siguiendo el plan que hemos estructurado previamente.

__CONTEXTO__
- Debes considerar la etapa actual del proyecto, la estructura y el formato de mis datos. A partir de esto profundizaremos en el análisis.

Estructura de los pasos profundizar:

---
- Paso 1; Distribución de clases: Crearemos un gráfico de barras para visualizar distribución de imágenes de cada clase, comparando las distribuciones del conjunto de entrenamiento y de prueba.

- Paso 2; Valores de pixeles: Visualizar historigramas de valores de pixeles para cada clase, visualizando distribución de intensidades de pixeles para la identificación de anomalías o patrones.

- Paso 3; Promedio y desviación estándar: Calcularemos y visualizaremos las imágenes promedio y la desviación estándar para cada clase, con el objetivo de compararlas posteriormente entre sí.

- Paso 4; Correlación de píxeles: Crearemos mapas de calor para visualizar la correlación de píxeles entre distintas imágenes.

- Paso 5; Análisis estadístico: Calcularemos las estadísticas descriptivas (media, mediana y desviación estándar) de los valores de los pixeles y las compararemos entre sí.

- Paso 6; Análisis de Similitud: Utilizaremos técnicas de clustering para agrupar imágenes similares y visualizar los datos. Usaremos PCA para la reducción de dimensionalidad.

- Paso 7; Análisis de Similitud 2: Repetiremos el paso previo, pero esta vez usando la técnica t-SNE, y compararemos ambos métodos.
---

- Para cada uno de los pasos debes incluir las siguientes áreas áreas:
	- Importancia del paso para el análisis.
	- Ejemplo de código necesario para el paso, bien estructurado y comentado.
	- 3 ideas de posibles sub-análisis para profundizar en el paso.

- Cuando completes el paso esperarás que te comparta los resultados para analizarlos.
- Cuando te comparta los resultados, discutiremos los puntos interesantes del paso y responderás mis preguntas hasta que te especifique que continuemos con el siguiente paso.

 __ESTILO__
- Mantén tu respuesta limpia y bien estructurada en formato markdown, con cabeceros bien diferenciados.
- Usa un formato de bullet list para presentar tus ideas de forma clara y concisa. 

__LIMITACIONES__
- Mantén tus respuestas breves, extiéndete lo justo para comunicar las ideas clave de forma efectiva.
- No incluyas introducciones, conclusiones ni otro tipo de aclaraciones, debes centrarte en los pasos.
- IMPORTANTE: Debes centrarte en un paso por respuesta, discutiremos ese paso y nos enfocaremos en ese hasta que yo te diga que continuemos con el siguiente.

Algunos consejos para la estructura de las consultas:

• Mantener la __CONSULTA__ simple y directa, para comunicar brevemente al modelo lo que buscamos, de modo que filtremos su enfoque.
• Estructurar el __CONTEXTO__ en bloques bien diferenciados y ordenados, para facilitar la compresión del mismo, usando listas y otros marcadores o divisores.
• Ser muy específico y claro en las __LIMITACIONES__. Si tenemos muchas limitaciones es interesante que prioricemos, señalizando al modelo las importantes, porque algunas pueden entrar en conflicto y el modelo debe decidir cuál priorizar.
• Otro punto interesante con las __LIMITACIONES__ es mantenerlas flexibles, es decir, en lugar de eliminar características, por ejemplo: “No uses un tono formal”, es más interesante usar una frase que module la formalidad del texto, como si fuera un regulador, y probar a aumentar y disminuir el nivel de formalidad. Podemos poner algo del estilo “Usa un nivel 4 de formalidad, siendo 1 una charla callejera con amigos, y 10 un documento legal.”

Este es un ejemplo para que se vea el potencial del último punto:

__CONSULTA__
Explícame en menos de 100 palabras el proceso de la fotosíntesis.

__CONTEXTO__
- Debes explicarme este proceso 10 veces, con 10 niveles de formalidad distintos.
- El nivel 1 de formalidad corresponde a una conversación callejera con amigos. El nivel 10 de formalidad corresponde a un documento legal.
- Formatea tu respuesta en una lista de puntos.
- Para cada nivel, debes incluir una etiqueta, especificando a qué equivale. Por ejemplo: Nivel 1 (Formalidad nivel conversación callejera).

Ejemplo output del modelo como respuesta a la petición anterior

Gracias a este enfoque regulador, podemos jugar con estos números y añadirlos a los distintos parámetros del modelo según los necesitemos.

Paso a paso: Especificar iteratividad

Debemos especificar al modelo que recorra los pasos de manera iterativa, enfocándose en uno por respuesta. En cada una de estas respuestas hará pausas para discutir el paso y analizar los resultados, para retocar tanto la consulta inicial como la estructura del análisis. También cabe la posibilidad de profundizar en sub-análisis potencialmente interesantes.

Aquí es donde se da toda la magia del proceso, y es donde tenemos que dar feedback al modelo, especificándole que nos gusta y qué no nos gusta de sus respuestas, para adaptarlo lo mejor posible a lo que buscamos.

En el proceso, he encontrado un par de limitaciones interesantes:

El modelo tiene prisa por volver a la estructura de pasos inicial

A veces, puede darse que estemos discutiendo un paso, y el modelo concluya que ya nos ha quedado claro, y empiece a generar el siguiente paso de la estructura inicial. Para evitar esto, suelo incluirle como regla que no continúe con el análisis o con la ruta de pasos hasta que no le escriba específicamente la palabra “Continúa”, o algo similar, así hago que esta palabra funcione como disparador para volver a la estructura base.

El modelo se apega a las estructuras con facilidad

Es común que, al solicitar una estructura específica al modelo, este tienda a usarla constantemente o a incluir detalles de dicha estructura en sus respuestas subsecuentes. Por ejemplo, si en el formato inicial se le indica: “Para cada paso, debes generar un informe en formato markdown, dividido en cabeceros de nivel 2, el contenido debe tener formato de lista”, es muy probable que el modelo siga utilizando esta estructura incluso fuera de los pasos, como al responder preguntas sobre conceptos que no terminamos de comprender. Incluso si se le especifica que no lo haga, es probable que queden “residuos” de ese formato inicial en sus respuestas, como una mayor tendencia a usar listas (aunque esto ya lo hace de manera predeterminada). Hasta ahora, lo que mejor me ha funcionado es ser lo más claro posible con la estructura solicitada y los casos de uso específicos, y sobreescribir estructuras cuando sea necesario, por ejemplo, indicándole: “Si te hago alguna pregunta, debes responder de manera lo más breve posible.”

Conclusiones

Realmente no he encontrado demasiada diferencia práctica entre otros LLM de niveles similares y GPT4o en este tipo de procesos. Considero que el verdadero potencial a la hora de usarlos está más en el uso de una buena estrategia, tener claros estos conceptos, y el funcionamiento del modelo, es decir, la forma en la que mejor nos entiende y podemos llegar a comunicarle lo que queremos que haga.

La incorporación de LLM no solo enriquece el proceso analítico y de generación de ideas, sino que también mejora nuestras habilidades comunicativas y nos obliga a definir con mayor precisión nuestros objetivos. Este experimento ha demostrado que, con una estrategia adecuada, los modelos de lenguaje como GPT4o pueden ser aliados poderosos en nuestros proyectos. Definitivamente, vale la pena incluirlos en nuestras herramientas de trabajo diarias.

1. Repositorio del proyecto en Github ↩