Crear inteligencia empresarial basada en GenAI a partir de datos estructurados

Caso práctico

En las empresas, un flujo de datos típico tiene el siguiente aspecto:

Como ves, los datos de diferentes sistemas fuente se ingieren y compilan en una plataforma de datos central. A continuación, se procesan los datos para darles una forma adecuada. A continuación, los analistas trabajan en tareas analíticas (normalmente utilizando consultas SQL o scripts de Python) y crean cuadros de mando para generar perspectivas que serán consumidas por los usuarios empresariales.

Aunque hay espacio para mejorar en cada paso, nos gustaría compartir nuestro viaje en la generación y el consumo de análisis (paso 3 y paso 4 como se muestra en el diagrama anterior). Hemos pasado por varias iteraciones del flujo de datos analíticos.

Flujo de datos analíticos – Iteración 1

Anteriormente, para cada caso de uso empresarial creábamos tablas individuales que se utilizaban para proporcionar datos a los cuadros de mando individuales.

Con el paso del tiempo, descubrimos varios problemas con este enfoque:

• En primer lugar, a medida que aumentaba el número de cuadros de mando (a pesar de que todos ellos se encontraban en un repositorio central), a los usuarios les resultaba difícil localizar la información exacta que necesitaban en un plazo de tiempo limitado;
• En segundo lugar, a los usuarios les resultaba difícil correlacionar la información de los distintos cuadros de mando. Por ejemplo, teníamos un panel A que informaba sobre la campaña de marketing A y un panel B sobre la campaña B. Cuando un usuario empresarial se preguntaba «¿cuántos clientes no formaban parte de la campaña A pero ahora compran con nosotros a través de la campaña B?
• Los dos problemas anteriores condujeron a nuestro tercer problema: nuestros analistas de datos acabaron recibiendo un montón de peticiones ad hoc, lo que distrajo su atención de aquello en lo que se suponía que debían centrarse como parte del sprint.

Flujo de datos analíticos – Iteración 2

Para resolver estos problemas, ideamos la Iteración 2. Nos esforzamos por consolidar y crear un único punto de referencia, tanto para la capa de datos como para la de cuadros de mando.

En primer lugar, en lugar de crear tablas diferentes para casos de uso distintos, creamos un activo de datos unificado modelando los conjuntos de datos existentes de varios sistemas fuente. Esta capa de datos unificada sirve como un activo de datos de oro para el consumo descendente;

En segundo lugar, consolidamos los distintos cuadros de mando en un cuadro de mando de inteligencia global. Este cuadro de mandos está conectado a la capa de datos unificada y se diseñó de forma que pudiera responder al mayor número posible de preguntas de los usuarios empresariales.

Este enfoque es bastante eficaz, ya que reduce el número de solicitudes ad hoc y mejora la eficacia analítica. Cuando los usuarios tienen preguntas, podemos dirigirlos al cuadro de mandos de inteligencia integral para que encuentren sus respuestas.

Flujo de datos analíticos – Iteración 3 (en curso)

La iteración 2 ha sido todo un éxito. Sin embargo, a pesar de nuestros esfuerzos por reunir los requisitos de los usuarios, diseñar y perfeccionar el cuadro de mandos, inevitablemente habrá algunas preguntas de los usuarios que el cuadro de mandos no pueda resolver directamente.

En la última iteración 3, estamos estudiando una forma «más inteligente» de complementar la solución de la iteración 2.

El concepto es que cuando un usuario formule una pregunta, la solución pueda generar automáticamente perspectivas y análisis como respuestas, requiriendo un esfuerzo mínimo por parte de un analista humano.

En un último experimento, hemos probado a utilizar Snowflake Copilot y Snowflake Cortex Analyst para conseguirlo.

Presentación de Snowflake Copilot y Snowflake Cortex Analyst

Tanto Snowflake Copilot como Snowflake Cortex Analyst están potenciados por Snowflake Cortex AI.

Snowflake Copilot se encuentra dentro de la interfaz de usuario de Snowflake, Snowsight. Los usuarios pueden interactuar con Copilot en hojas de trabajo SQL y cuadernos Snowflake. Ayuda a los analistas de datos y a los desarrolladores de SQL a acelerar el desarrollo convirtiendo texto en SQL.

Snowflake Cortex Analyst es básicamente una versión API de Snowflake Copilot. Sirve como una API REST que puede utilizarse en cualquier aplicación. Cuando los usuarios interactúan con estas aplicaciones, pueden hacer preguntas y obtener las respuestas que necesitan.

Acceso a Snowflake Copilot y Cortex Analyst

En el momento de nuestro experimento, Snowflake Copilot estaba en fase de vista previa pública y disponible en las siguientes regiones:

• AWS EE.UU.-Este-1
• AWS us-oeste-2
• AWS eu-central-1

Snowflake Cortex Analyst estaba en vista previa privada en el momento del experimento. Para obtener acceso a las características y servicios, abrimos una cuenta Snowflake Innovation en la región US West para poder acceder a Snowflake Copilot. También contamos con la ayuda del equipo de Snowflake para habilitar Cortex Analyst en la misma cuenta de innovación.

Snowflake Cortex Analyst está en fase de vista previa pública en el momento de la publicación de este artículo. La disponibilidad por regiones puede consultarse aquí. Si no está disponible en su región de nube, no necesita necesariamente abrir una cuenta separada como nosotros. Puede seguir utilizando Cortex Analyst aprovechando la inferencia entre regiones.

Asistente LLM con Snowflake Copilot

Después de configurar la cuenta de innovación, probamos algunos experimentos con Snowflake Copilot para ver si podía satisfacer nuestra necesidad.

Para el experimento, dentro de la cuenta de innovación, tenemos un conjunto de datos de muestra existente:

INNOVATION_BDS_ENTERPRISE.PUBLISHED_DATA.RETAIL_TRANSACTION_DATASET.

Podemos utilizar Snowflake Copilot siguiendo estos pasos:

1.Crear una nueva hoja de cálculo o abrir una hoja de cálculo existente.

2. Seleccione «Preguntar a Copilot» en la esquina inferior derecha de la hoja de trabajo.

El panel Snowflake Copilot se abre a la derecha de la hoja de trabajo.

3. Ve al selector situado debajo del cuadro de mensajes de Snowflake Copilot, selecciona la base de datos y el esquema de nuestro conjunto de datos de muestra:

4. En el cuadro de mensaje, escribimos nuestra pregunta y, a continuación, seleccionamos el icono de enviar o pulsamos «Intro» para enviarla. Snowflake Copilot proporciona una respuesta en el panel.

5. Como la respuesta de Snowflake Copilot incluye sentencias SQL, seleccionamos «Añadir» para editar la consulta antes de ejecutarla. Esto añade la consulta a nuestra hoja de cálculo, que podemos seguir editando y ejecutando.

Snowflake Copilot ha funcionado muy bien, aunque vemos que hay margen para mejorar la solución:

1. Para interactuar con Copilot, el usuario necesita acceso a Snowsight UI. Los analistas de datos y los desarrolladores de SQL tendrán sin duda el acceso, pero muchos de nuestros usuarios empresariales no lo tienen;
2. Para utilizar Snowflake Copilot, tenemos que asegurarnos de que tenemos el conjunto de datos (al menos el esquema del conjunto de datos) ubicado dentro de la misma cuenta Snowflake. Pero en nuestro caso de uso real, nuestro conjunto de datos se encuentra en la cuenta de producción, que es independiente de esta cuenta de innovación;
3. Copilot está generando el SQL basado en el esquema de nuestro conjunto de datos. Nos dimos cuenta de que la consulta SQL generada no es 100% correcta, en parte porque no hemos proporcionado descripciones detalladas de tablas y columnas como parte del esquema Snowflake y DDL. Así, cuando Snowflake Copilot genera el SQL, no dispone de información suficiente para fundamentar la respuesta.

Para mejorar aún más la solución, experimentamos con Snowflake Cortex Analyst como se indica a continuación.

Asistente LLM con Snowflake Cortex Analyst

Diseño de soluciones

Recorreremos la solución paso a paso.

Requisitos previos

Pre-requisito 1: Habilitar Cortex Analyst Endpoint dentro de Innovation Account.
Como se mencionó anteriormente, tuvimos la ayuda del equipo de Snowflake para habilitar Cortex Analyst endpoint en nuestra Cuenta de Innovación.

Pre-requisito 2: Preparar la tabla dentro de otra cuenta de producción.
Nuestro conjunto de datos (una tabla Snowflake) utilizado para esta solución se encuentra en otra cuenta de producción.

Mientras que nuestros datos permanecen en la cuenta de producción en la región de Sydney, Australia, podemos acceder a las nuevas características en la cuenta de innovación en la región oeste de EE.UU..

A medida que Snowflake despliegue estas funciones en más regiones, las empresas podrán acceder a ellas desde las cuentas existentes.

Prerrequisito 3: Crea una tabla vacía en la cuenta de innovación para reflejar la tabla de la cuenta de producción.

Creamos una base de datos, un esquema y una tabla en la Cuenta de Innovación con los mismos nombres que los de la Cuenta de Producción, asegurándonos de que la tabla tiene exactamente el mismo esquema y las mismas columnas, y dejando esta tabla vacía.

Esta tabla vacía se utilizará para que Cortex Analyst genere la consulta SQL correcta. Pero no aplicaremos la consulta SQL devuelta a la tabla vacía de la Cuenta de Innovación, sino que aplicaremos la consulta SQL a nuestra tabla original de la Cuenta de Producción, escribiendo la lógica como parte de nuestra aplicación Streamlit.

Paso 1: Generar un modelo semántico para el conjunto de datos

Como primer paso de esta solución, necesitamos generar un modelo semántico para nuestro conjunto de datos en la cuenta de producción.

Para ello, utilizamos el generador de modelos semánticos proporcionado por Snowflake Labs. Este repositorio git proporciona instrucciones detalladas sobre cómo utilizarlo para generar un modelo semántico para nuestra tabla Snowflake. En el futuro, Snowflake también proporcionará una aplicación streamlit para que los clientes puedan hacer esto de una manera más fácil.

Para nuestro experimento, utilizando este repositorio git, podríamos generar el siguiente modelo semántico para un conjunto de datos de transacciones minoristas de muestra:

name: retail_transaction
tables:
  - name: RETAIL_TRANSACTION_DATASET
    description: '  ' # <FILL-OUT>
    base_table:
      database: INNOVATION_BDS_ENTERPRISE
      schema: PUBLISHED_DATA
      table: RETAIL_TRANSACTION_DATASET
    filters:
      - name: '  ' # <FILL-OUT>
        synonyms:
          - '  ' # <FILL-OUT>
        description: '  ' # <FILL-OUT>
        expr: '  ' # <FILL-OUT>
    dimensions:
      - name: PRODUCT_ID
        synonyms:
          - '  ' # <FILL-OUT>
        description: 'Unique identifier for each product.'
        expr: PRODUCT_ID
        data_type: TEXT
        sample_values:
          - C
          - A
          - D
          - B
      - name: PAYMENT_METHOD
        synonyms:
          - 'methods of payment'
        description: 'The method used by the customer to make the payment.'
        expr: PAYMENT_METHOD
        data_type: TEXT
        sample_values:
          - Cash
          - PayPal
          - Debit Card
          - Credit Card
      - name: STORE_LOCATION
        synonyms:
          - 'store address'
        description: 'The location where the transaction took place.'
        expr: STORE_LOCATION
        data_type: TEXT
        sample_values:
          - "176 Andrew Cliffs\nBaileyfort, HI 93354"
          - "11635 William Well Suite 809\nEast Kara, MT 19483"
          - "910 Mendez Ville Suite 909\nPort Lauraland, MO 99563"
          - "87522 Sharon Corners Suite 500\nLake Tammy, MO 76234"
          - "0070 Michelle Island Suite 143\nHoland, VA 80142"
          - "8492 Jonathan Drive\nNorth Robertshire, TN 67532"
          - "USNV Harrell\nFPO AA 62814"
          - "528 Justin Expressway Apt. 336\nCabreraborough, SD 17915"
          - "189 Wright Mews\nMartinfurt, MO 75932"
          - "388 Matthew Lane Apt. 592\nWest Andreachester, IN 96537"
      - name: STATE
        synonyms:
          - '  ' # <FILL-OUT>
        description: 'State of the store where the transaction took place. Derived from STORE_LOCATION.'
        expr: STATE
        data_type: TEXT
        sample_values:
          - HI
          - MT
          - MO
          - VA
          - TN
          - AA
          - WV
          - IN
          - AP
          - NE
      - name: POSTCODE
        synonyms:
          - 'zipcode'
        description: 'Postcode of the store where the transaction took place. Derived from STORE_LOCATION.'
        expr: POSTCODE
        data_type: TEXT
        sample_values:
          - '93354'
          - '19483'
          - '76234'
          - '80142'
          - '67532'
          - '62814'
          - '72610'
          - '17915'
          - '05999'
          - '21025'
      - name: PRODUCT_CATEGORY
        synonyms:
          - '  ' # <FILL-OUT>
        description: 'Category to which the product belongs.'
        expr: PRODUCT_CATEGORY
        data_type: TEXT
        sample_values:
          - Books
          - Home Decor
          - Electronics
          - Clothing
    time_dimensions:
      - name: TRANSACTION_TIMESTAMP
        synonyms:
          - 'transaction date'
          - 'transaction date time'
          - 'transaction date and time'
        description: 'Date and time when the transaction occurred.'
        expr: TRANSACTION_TIMESTAMP
        data_type: TIMESTAMP_NTZ
        sample_values:
          - '2023-12-26 12:32:00'
          - '2023-08-05 00:00:00'
          - '2024-03-11 18:51:00'
          - '2023-10-27 22:00:00'
          - '2023-12-22 11:38:00'
          - '2023-08-15 04:24:00'
          - '2023-12-26 05:32:00'
          - '2023-10-11 06:48:00'
          - '2024-02-27 11:13:00'
          - '2023-11-05 01:46:00'
    measures:
      - name: CUSTOMER_ID
        synonyms:
          - 'customer number'
        description: 'Unique identifier for each customer.'
        expr: CUSTOMER_ID
        data_type: NUMBER
        sample_values:
          - '109318'
          - '993229'
          - '579675'
          - '799826'
          - '121413'
          - '463050'
          - '888163'
          - '843385'
          - '839609'
          - '184135'
      - name: QUANTITY
        synonyms:
          - 'number of pieces'
        description: 'The number of units purchased for a particular product.'
        expr: QUANTITY
        data_type: NUMBER
        sample_values:
          - '7'
          - '4'
          - '8'
          - '5'
          - '3'
          - '6'
          - '2'
          - '1'
          - '9'
      - name: PRICE
        synonyms:
          - 'unit price'
        description: 'The unit price of the product.'
        expr: PRICE
        data_type: NUMBER
        sample_values:
          - '80.07984415'
          - '75.19522942'
          - '31.52881648'
          - '98.88021828'
          - '93.18851246'
          - '13.12193739'
          - '56.02516419'
          - '23.85798105'
          - '43.69259776'
          - '98.70968076'
      - name: DISCOUNT_APPLIED_PERCENTAGE
        synonyms:
          - 'discount'
          - 'discount percent'
          - 'discount percentage'
          - 'percentage of discount'
        description: 'Percentage of discount applied on the transaction'
        expr: DISCOUNT_APPLIED_PERCENTAGE
        data_type: NUMBER
        sample_values:
          - '18.677099500'
          - '14.121365020'
          - '15.943700660'
          - '6.686336780'
          - '4.030095691'
          - '10.888768360'
          - '16.295126710'
          - '6.344305684'
          - '18.703997250'
          - '7.640606649'
      - name: TOTAL_AMOUNT
        synonyms:
          - 'sales'
          - 'sales amount'
          - 'total sales'
          - 'total sales amount'
        description: 'Total amount paid for the transaction. Calculated by quantity * price * (1 - discount_applied_percentage/100)'
        expr: TOTAL_AMOUNT
        data_type: NUMBER
        sample_values:
          - '455.862763800'
          - '258.306546400'
          - '212.015650900'
          - '461.343769400'
          - '626.030483700'
          - '144.609223300'
          - '76.885907450'
          - '419.766052100'
          - '96.977924650'
          - '234.012017500'

Paso 2: Cargar el modelo semántico en el escenario

Una vez que tenemos nuestro modelo semántico, el siguiente paso es subirlo a un escenario dentro de la Cuenta de Innovación donde se encuentra el Analista Cortex.

Creamos una base de datos llamada semantic_model, un esquema llamado definition y un stage llamado my_stage bajo el esquema.

Nota: el rol de Snowflake que utilizamos en nuestra aplicación Streamlit (ver paso a continuación) debe ser capaz de acceder a la base de datos, el esquema y el escenario que hemos creado en este paso.

Paso 3: Crear una aplicación Streamlit

Este paso consiste en crear una aplicación Streamlit para que los usuarios interactúen con ella.

Snowflake ofrecía 2 opciones:

• Opción 1: Crear una aplicación Streamlit independiente
• Opción 2: Crear una aplicación Streamlit en Snowflake

En este caso elegimos la opción 1 porque nuestro conjunto de datos se encuentra en una cuenta independiente. Después de obtener la consulta SQL de Cortex Analyst dentro de la cuenta de innovación, nos gustaría aplicar la consulta al conjunto de datos en nuestra cuenta de producción. Con una aplicación Streamlit independiente, nos resulta más fácil construir la aplicación a través de las cuentas.

Creamos la aplicación Streamlit consultando la documentación de Snowflake aquí.

Paso 4: Interactuar con la aplicación Streamlit

Cuando un usuario hace una pregunta:

1. La aplicación Streamlit enviará la pregunta a Cortex API.
2. Entre bastidores, Cortex API llamará a un servicio de consulta para crear una consulta de usuario basada en la pregunta y, a continuación, enviará la consulta de usuario junto con sus conocimientos sobre la tabla (incluidos los DDL de la tabla y el modelo semántico YAML como se ha mencionado anteriormente en los pasos 1 y 2) a Azure OpenAI GPT4.
3. GPT4 generará entonces una respuesta que incluirá (1) una consulta SQL para responder a la pregunta del usuario, y (2) una explicación basada en texto sobre la consulta. La respuesta viajará de vuelta al usuario a lo largo del proceso.

De este modo, la aplicación Streamlit convierte con éxito el lenguaje natural humano en SQL, respuestas de texto y gráficos.

A continuación se muestran demostraciones de cómo funciona la aplicación Streamlit con el conjunto de datos de transacciones minoristas de muestra:

¿Te ha gustado esta historia?

Harsu Singh, Mohsen Razlighi y Selina Li pertenecen al equipo de Insights, Data and Analytics de Officeworks y se encargan del desarrollo de productos de datos.
No dudes en ponerte en contacto o comentar a continuación si tienes alguna pregunta o consejo sobre la solución que se comparte en el artículo.