Se suponía que Text-to-SQL sería la aplicación estrella de la IA, pero no lo es.

En el calor de la locura inicial de ChatGPT, recibí un mensaje de texto de un ex compañero de trabajo. Quería comentarme una idea. Como siempre le gusta intercambiar ideas, nos pusimos en contacto por teléfono y empezó diciendo: “¿Recuerdas cómo solías pedirme que extrajera datos para ti? ¿Qué pasaría si pudieras hacerlo tú mismo?”. Y luego procedió a presentarme una idea que miles (¿decenas de miles?) de otras personas estaban pensando al mismo tiempo: los LLM se podrían usar para convertir texto a SQL para ayudar a las personas menos técnicas a responder sus propias preguntas sobre datos.

Me enganché con la idea, pero antes de lanzarme de cabeza, le dije a Lei (ahora mi CTO) que teníamos que hacer una validación. Nos pusimos en contacto con amigos y antiguos compañeros de trabajo de varias industrias. Había un gran interés en el "análisis de autoservicio" real. Sabíamos que sería mucho más complicado de lo que parecía, pero la oportunidad parecía demasiado buena como para dejarla pasar. Así que Lei y yo dejamos The Shire y nos embarcamos en nuestro viaje para crear nuestra visión: Fabi.ai .

Esta publicación no trata sobre nuestro producto en sí (aunque, si tiene curiosidad, puede leer más sobre cómo algunas de las ideas a continuación informaron nuestro trabajo reciente con el producto). aquí ). En cambio, quería compartir los principales aprendizajes que hemos recopilado al trabajar con LLM para el análisis de datos a lo largo de nuestro recorrido.

Nota: Este viaje carece lamentablemente de magos y batallas épicas en la Tierra Media. 🧙

¿Por qué utilizar IA para el análisis de autoservicio?

No nos extenderemos demasiado en el "por qué". Si estás leyendo esto, es probable que pertenezcas a uno de estos dos grupos:

1. Eres alguien que desea tener análisis de autoservicio disponibles y no quiere tener que esperar siempre a su equipo de datos.
2. Estás en el equipo de datos y has estado escuchando acerca de cómo la IA te ayudará a resolver tu problema de solicitudes ad hoc.

Dejando de lado la preocupación por el papel de los analistas y científicos de datos, la idea de una IA omnisciente que pueda responder a cualquier pregunta sobre los datos de una organización suena bien. O al menos, suena bien para la organización y sus líderes empresariales, cuya creatividad para encontrar nuevas formas de hacer preguntas no tiene límites. Esta IA podría ser la solución para crear una organización “impulsada por los datos” en la que cada líder se apoye en evidencia empírica para tomar sus decisiones estratégicas. Y todo a una fracción del costo que normalmente costaría. ¡Por fin! Las organizaciones pueden sacar provecho de ese “nuevo petróleo” del que han oído hablar desde 2010.

Pero si este es un problema tan valioso para resolver y la IA se ha vuelto tan buena, ¿por qué ningún producto lo ha resuelto hasta ahora?

Por qué la IA para el análisis de autoservicio ha fracasado hasta ahora

Las encuestas recientes de la industria muestran un panorama complejo de la adopción de IA en la empresa. 61 por ciento de las empresas Están probando agentes de IA. Sin embargo, a muchos les preocupa la confiabilidad y la seguridad. De hecho, el 21 % de las organizaciones no los usa en absoluto. Estas dudas se sienten con especial fuerza en los equipos de datos, donde la precisión y la confiabilidad son fundamentales para nuestra capacidad de hacer el trabajo.

Los usuarios de IA, especialmente en el ámbito empresarial, tienen expectativas muy altas en lo que respecta a la tecnología. En el contexto del análisis de datos y el sueño del autoservicio, esperamos que nuestras herramientas de IA:

1. Proporciona información: las tablas y los gráficos son geniales, pero son un subconjunto de lo que podríamos llamar "información". La información es un momento revelador que surge al detectar cosas en los datos que van en contra de nuestra intuición y que de otro modo no habríamos considerado. A veces, una consulta SQL o un pivote pueden arrojar luz sobre estas ideas, pero, por lo general, parece mucho más como encontrar una aguja en un pajar.
2. Funcionan de manera confiable casi el 100 % del tiempo: lo único peor que no tener datos es que estos sean incorrectos. Si no se puede confiar en la IA o esta alucina respuestas y datos, eso significa malas noticias para todos. Esto significa que cuando la IA tiene datos, debe usarlos correctamente. Pero cuando carece de datos, debe evitar dar una respuesta (algo en lo que los LLM son notoriamente malos).
3. Ser accesible a una amplia gama de habilidades técnicas: la belleza de los LLM es que puedes interactuar con ellos como lo harías con un compañero de trabajo a través de Slack. Puedes usar un lenguaje vago. La otra persona o cosa probablemente pueda entender tu solicitud en el contexto empresarial. Por el contrario, cuanto más requiera un sistema el uso de términos exactos en una forma exacta, menos accesible será. Este tipo de sistema requiere capacitación y refuerzo, lo que todos sabemos que puede ser un desafío.

Lamentablemente, la mayoría de las soluciones actuales utilizan un marco de IA monolítico tradicional, que a menudo no cumple con las expectativas. En los últimos años, el equipo de Fabi.ai y yo trabajamos arduamente en este problema. Creamos prototipos para la empresa y exploramos muchas opciones. Al final, nos dimos cuenta de que ni la Generación de Aumentos de Recuperación (RAG) ni el ajuste fino podían solucionar este problema con el marco monolítico actual.

Cuando probamos este enfoque, nos quedaron claras algunas cosas:

• El RAG es frágil. Si hay muy poco contexto, la IA no puede responder a una pregunta y corre el riesgo de alucinar. Si hay demasiado contexto, la IA se confunde y pierde precisión.
• La IA de una sola vez no te lleva a ninguna parte. La mejor IA del mundo nunca podrá extraer y analizar datos con precisión de una sola vez. Simplemente hay demasiados matices en los datos y en las preguntas. Tomemos el ejemplo más simple posible: tienes un campo "Tipo de cuenta" que está poblado en un 95 % con 10 valores distintos. Si le pides a la IA que filtre un conjunto de tipos de cuenta, es posible que no reconozca que hay valores en blanco, lo que produce una consulta SQL no válida. "Seguro", podrías decir, "pero podemos simplemente calcular las estadísticas para cada campo y los valores de muestra y almacenarlos en nuestro almacén de vectores de contexto". Los tipos de problemas son casi infinitos y todos únicos a su manera.
• Los datos empresariales son desordenados. Esto se relaciona con los dos primeros puntos, pero vale la pena enfatizarlo. Incluso si por un momento fugaz, una organización puede tener algunas tablas de oro con una capa semántica perfectamente definida, todo se derrumba tan pronto como el líder de RevOps decide ajustar el modelo de negocios. Me gusta hacer una analogía con una casa: generalmente se puede mantener una casa bastante ordenada, pero siempre habrá algo que necesite ser limpiado o reparado.
• La conversión de texto a SQL es demasiado limitante. Para la mayoría de las preguntas de análisis de datos, escribir el SQL para extraer los datos es solo el primer paso. Este es el paso que debe dar antes de poder comenzar a hacer preguntas más interesantes. SQL simplemente no puede manejar el análisis complejo que solicitan los usuarios comerciales. Los LLM y Python, por otro lado, son perfectamente adecuados para la tarea. Estas herramientas pueden tomar su salida SQL y encontrar esa aguja en el pajar. También pueden ejecutar análisis de regresión para descubrir tendencias más amplias.

Después de analizar estas cuestiones, pensamos en cómo lograr que la IA se adapte mejor a los problemas. Fue entonces cuando los agentes de IA entraron en juego y consolidaron este concepto para nosotros.

El futuro: mallas de agentes

En el momento en que vimos los marcos de trabajo de Agentic, supimos que cambiarían las reglas del juego. De repente, sentimos que podíamos dejar que la IA decidiera cómo responder a las preguntas. Podría seguir unos pasos y resolver los problemas por sí sola. Si la IA escribe una consulta SQL que no tiene valores nulos en el campo "Tipo de cuenta", puede ejecutar la consulta en seco, detectar el error y solucionarlo por sí sola. Pero, ¿qué pasaría si pudiéramos llevar esto un paso más allá y dejar que la IA opere principalmente en Python y aproveche los LLM? Ahora, la IA hace más que extraer datos. Puede usar paquetes de Python o LLM para encontrar valores atípicos, tendencias o información única, que normalmente tendría que buscar manualmente.

Pero todavía teníamos un problema: los datos empresariales desordenados. Creíamos que las organizaciones podían resolverlo mediante prácticas sólidas de ingeniería de datos, como un arquitectura de medallón y una capa semántica estricta. Sin embargo, rara vez encontramos organizaciones que realmente hicieran esto en la vida real. La mayoría de las organizaciones utilizan hojas de cálculo, tablas a medio hacer y modelos de datos en constante cambio. A partir de aquí, se nos ocurrió la idea de crear agentes de IA especializados que se puedan crear rápidamente para responder un conjunto específico de preguntas.

A medida que las empresas crecen, manejan más datos y tienen más usuarios. La idea de la malla de agentes ayuda a equilibrar la toma de decisiones rápida con el control necesario para la gobernanza. Los agentes especializados ayudan a establecer límites y responsabilidades claros para cada IA. También crean una forma escalable para que los agentes se comuniquen. Además, pueden ayudar a administrar recursos de manera eficiente en todos los equipos y empresas.

Agentes de IA especializados

La idea detrás de un agente especializado es que este agente puede y solo responderá preguntas sobre un conjunto de datos muy definido. Por ejemplo, puede crear y lanzar un agente de IA que responda preguntas sobre campañas de marketing. O puede crear otro para responder preguntas sobre el flujo de marketing, y así sucesivamente.

Recientemente lanzamos Agent Analyst , utilizando esta arquitectura. Los primeros indicios son muy prometedores. Cuando los conjuntos de datos se seleccionan cuidadosamente y tienen el nivel de granularidad adecuado, estos agentes pueden responder a un conjunto específico de preguntas de manera extremadamente confiable. El creador de estos agentes puede compartirlos con usuarios no técnicos y estar tranquilo sabiendo que la IA no responderá preguntas que estén fuera del alcance.

Hay un solo defecto: los usuarios necesitan saber a qué agente acudir para cada pregunta. Es como necesitar saber cuál es el analista de marketing adecuado al que hacerle una pregunta en lugar de simplemente hacer una pregunta general. Con una pregunta general, alguien del equipo puede dirigirla a la persona adecuada. Aquí es donde entra en juego el concepto de "malla de agentes".

Conectando agentes entre sí

Si un solo agente puede responder de forma fiable a preguntas específicas de un dominio, ¿por qué no dejar que los agentes hablen entre sí? ¿Por qué, por ejemplo, el agente de la campaña de marketing no puede preguntar directamente al agente del pipeline si puede responder una pregunta con más facilidad? Creemos que debería poder hacerlo. De hecho, creemos que en el futuro habrá redes de agentes con una estructura jerárquica. Podemos imaginar un "agente GTM" que llama al "agente de marketing". Este agente llama entonces tanto al "agente del pipeline" como al "agente de la campaña de marketing".

Esta idea es como una idea más general que circula alrededor de la IA conocida como " Internet de los agentes "Es un futuro en el que los agentes de IA colaboran sin problemas entre distintas organizaciones y al mismo tiempo garantizan que la seguridad y la confianza sigan siendo sólidas.

Este enfoque de malla ofrece algunas ventajas clave sobre una IA monolítica (en una capa semántica prístina):

• Observabilidad: dado que un solo agente proporciona respuestas basadas en datos específicos, puede rastrear cada respuesta hasta ese agente. Esto ayuda a garantizar la precisión mediante auditoría. Para dar un ejemplo concreto, aunque demasiado simplista, imagine que tiene dos tablas de eventos: una para marketing y otra para producto. Si un usuario pregunta: "¿Qué eventos han generado más ingresos?", la IA podría asumir que se refiere a eventos de producto. Incluso si es incorrecto, el usuario puede ver qué agente respondió y puede guiar a la IA.
• Mantenibilidad: al igual que en el motor de un automóvil, si se pueden encontrar problemas fácilmente y reemplazar piezas rápidamente, el automóvil se vuelve más confiable. Si un agente comienza a fallar debido a un cambio en el modelo de datos, se puede detectar rápidamente y actualizar ese agente.
• Precisión: cada agente opera dentro de sus propios límites, por lo que no hay margen para que se salga de control. Puede que no tenga la respuesta, pero no hará nada extravagante.

Al final, esta idea de una malla no es novedosa. Refleja el concepto de una combinación de expertos que ha demostrado mejorar la precisión de los LLM. Simplemente se trata de tomar esa misma idea y aplicarla a los agentes de IA.

Desafíos técnicos de las mallas de agentes

En Fabi.ai, tenemos un largo camino por recorrer en la creación de una red de agentes analistas, pero ya hemos superado algunos de los grandes desafíos de infraestructura técnica a lo largo del camino.

Los agentes de análisis de datos de IA necesitan una arquitectura única. Este diseño debe permitirles usar Python o LLM para responder preguntas, mantenerse sincronizados con las fuentes de datos y adaptarse a plataformas colaborativas, sin dejar de ser seguros y escalables. Cada agente debe operar en su propio núcleo de Python, que debe activarse o desactivarse rápidamente para reducir costos y mantenerse sincronizado con los datos de origen.

Las arquitecturas que no proporcionan núcleos individuales a cada agente pueden enfrentar uno de los siguientes riesgos:

• Conflicto de estado por variables entre agentes de IA. Dos agentes separados pueden generar una variable “foo” para responder una pregunta, lo que provoca un conflicto. Podría haber otras formas de generar identificadores únicos, pero estas aumentan las probabilidades de que la IA genere código no válido.
• Riesgos de seguridad provocados por el intercambio de datos entre diferentes equipos o incluso diferentes organizaciones.
• Se producen cuellos de botella en el rendimiento si un agente utiliza una cantidad desproporcionada de recursos informáticos.

El desafío de construir este tipo de plataforma es tanto un desafío de IA como de DevOps.

Mirando hacia el futuro: adopción de agentes de IA especializados y gobernados en los datos

A medida que las empresas gestionan más aplicaciones de IA en sus operaciones, necesitan enfoques especializados y bien gobernados. El marco de trabajo de malla de agentes utiliza agentes de datos de IA especializados como un medio para escalar la IA en el análisis de datos. Este enfoque mantiene intactos la seguridad, la confiabilidad y el rendimiento.

Podríamos haber esperado que la IA estuviera en todas partes a estas alturas, respondiendo a la mayoría de las preguntas sobre datos. Pero, si observamos con atención, el progreso en solo dos años desde que se lanzó ChatGPT es impresionante. Todavía tenemos mucho que aprender en este viaje. Sin embargo, en mi opinión, los agentes y los marcos de malla de agentes serán clave para la IA empresarial.