No calor da mania inicial de ChatGPT, recibín un texto dun antigo compañeiro de traballo. Quería facerme unha idea. Sempre quen gozaba da chuvia de ideas, fixemos unha chamada e el comezou con "Lembras como sempre me pedías que puidese sacar datos para ti? E se puideses facelo ti mesmo?" E despois procédese a presentarme unha idea que miles (¿decenas de miles?) doutras persoas estaban pensando ao mesmo tempo: os LLM poderían usarse para o texto a SQL para axudar a xente menos técnica a responder as súas propias preguntas de datos.  Estaba enganchado coa idea, pero antes de mergullarse de cabeza, díxenlle a Lei (agora o meu CTO) que tiñamos que facer algunha validación. Contactamos con amigos e antigos compañeiros de traballo de varias industrias. Houbo un forte interese pola "analítica de autoservizo". Sabíamos que sería moito máis complicado do que parecía, pero a oportunidade parecía demasiado boa para deixar pasar. Entón Lei e eu deixamos The Shire e embarcamos na nosa viaxe para crear a nosa visión:  .   Fabi.ai  Esta publicación non trata sobre o noso produto en si (aínda que, se tes curiosidade, podes ler máis sobre como algunhas das ideas que aparecen a continuación informaron o noso traballo recente de produtos  ). Pola contra, quería compartir as aprendizaxes fundamentais que recompilamos ao traballar con LLM para a análise de datos ao longo da nosa viaxe.   aquí   Nota: esta viaxe carece lamentablemente de magos e batallas épicas na Terra Media. 🧙  Por que usar a IA para a análise de autoservizo?  Non nos demoraremos moito no "por que". Se estás lendo isto, é probable que te encantes nun dos dous grupos:  Vostede é alguén que desexa que dispoña de análises de autoservizo e non quere ter que esperar sempre no seu equipo de datos  Formas parte do equipo de datos e escoitaches sobre como a IA pode axudarche a resolver o teu problema de solicitudes ad hoc.  Ignorando a preocupación polo papel dos analistas de datos e dos científicos, a idea dunha IA omnisciente que poida responder a calquera pregunta sobre os datos dunha organización soa ben. Ou polo menos, parece ben para a organización e os seus líderes empresariais, cuxa creatividade para novas formas de facer preguntas non ten límites. Esta IA podería ser a solución para crear unha organización "dirixida por datos" onde todos os líderes se apoien en evidencias empíricas para tomar as súas decisións estratéxicas. E todo a unha fracción do custo que levaría normalmente. Por fin! As organizacións poden aproveitar ese "novo petróleo" do que levan escoitando desde 2010.  Pero se este é un problema tan valioso de resolver e a IA tense tan boa, por que ningún produto o   ata agora? resolveu  Por que a IA para a analítica de autoservizo fallou ata agora  As enquisas recentes da industria debuxan unha imaxe complexa da adopción da IA na empresa.  están probando axentes de IA. Non obstante, moitos preocúpanse pola fiabilidade e a seguridade. De feito, o 21% das organizacións non os usan en absoluto. Estas dúbidas séntense especialmente nos equipos de datos, onde a precisión e a fiabilidade son fundamentais para a nosa capacidade de traballar.   61 por cento das empresas  Os adoptantes da IA, especialmente na empresa, teñen un alto nivel cando se trata das expectativas da tecnoloxía. No contexto da análise de datos e do soño de autoservizo, esperamos que a nosa ferramenta de IA:  Proporciona información: as táboas e os gráficos son xeniais, pero son un subconxunto do que se pode chamar "insights". As insights son "Aha!" momentos que veñen de detectar cousas nos teus datos que van en contra da túa intuición e que doutro xeito non terían en conta. Ás veces, unha consulta SQL ou un pivote poden iluminar estes coñecementos, pero en xeral parece moito máis atopar unha agulla nun palleiro.  Traballa de forma fiable case o 100 % das veces: o único peor que non hai datos son os datos malos. Se non se pode confiar na IA ou alucina as respostas e os datos, isto significa unha mala noticia para todos. Isto significa que cando a IA ten datos, debería usalos correctamente. Pero cando carece de datos, debería evitar dar unha resposta (algo no que os LLM son notoriamente malos).  Sexa accesible a unha ampla gama de habilidades técnicas: a beleza dos LLM é que podes interactuar con eles como o farías cun compañeiro de traballo a través de Slack. Podes usar unha linguaxe vaga. É probable que a outra persoa ou cousa poida entender a túa solicitude no contexto empresarial. Pola contra, canto máis require un sistema usar termos exactos nunha forma exacta, menos accesible é. Este tipo de sistema require formación e reforzo, que todos sabemos, pode ser un reto.  Lamentablemente, a maioría das solucións actuais usan un marco de IA monolítico tradicional, que moitas veces non satisface as expectativas. Nos últimos anos, o equipo de Fabi.ai e eu traballamos moito neste tema. Construímos prototipos para a empresa e exploramos moitas opcións. Ao final, decatámonos de que nin a Xeración de Aumento de Recuperación (RAG) nin a posta a punto poderían solucionar este problema co marco monolítico actual.   Cando probamos este enfoque, quedaron claras algunhas cousas:  O RAG é fráxil. Demasiado pouco contexto e a IA non pode responder a unha pregunta e corre o risco de alucinar. Demasiado contexto e a IA confúndese e perde a súa precisión.  A IA dun disparo non te leva a ningún lado. A mellor IA do mundo nunca poderá extraer e analizar datos con precisión nun só tiro. Simplemente hai demasiados matices nos datos e na pregunta. Poñamos o exemplo máis sinxelo posible: tes un campo "Tipo de conta" que se enche nun 95 % con 10 valores distintos. Se lle pide á IA que filtre un conxunto de tipos de conta, é posible que non poida recoñecer que hai valores en branco, producindo así unha consulta SQL non válida. "Claro", podes dicir, "pero simplemente podemos calcular as estatísticas de cada campo e os valores de mostra e almacenalos na nosa tenda de vectores de contexto". Os tipos de problemas son case infinitos e todos únicos ao seu xeito.  Os datos da empresa son desordenados. Isto refírese aos dous primeiros puntos, pero merece a pena subliñalo. Aínda que sexa por un momento fugaz, unha organización pode ter algunhas táboas de ouro cunha capa semántica perfectamente definida, todo iso cae tan pronto como o líder de RevOps decide axustar o modelo de negocio. Gústame facer a analoxía dunha casa: en xeral podes manter unha casa bastante ordenada, pero sempre haberá que limpar ou arranxar   . algo  Text-to-SQL é demasiado limitante. Para a maioría das preguntas de análise de datos, escribir o SQL para extraer os datos é só o primeiro paso. Este é o paso que debes dar antes de que poidas comezar a facer preguntas máis interesantes. SQL simplemente non pode xestionar a análise complexa que os usuarios empresariais están a pedir. Os LLM e Python, por outra banda, son perfectamente axeitados para a tarefa. Estas ferramentas poden tomar a túa saída SQL e atopar esa agulla no palleiro. Tamén poden realizar análises de regresión para descubrir tendencias máis grandes.  Despois de analizar estes problemas, pensamos en como facer que a IA se adaptase mellor aos problemas. Foi entón cando os axentes de IA entraron en xogo e solidificaron este concepto para nós.  O futuro: axente mallas  No momento en que puxemos os ollos en marcos axentes, soubemos que cambiaría o xogo. De súpeto sentimos que podíamos deixar que a IA decida como responder ás preguntas. Podería funcionar a través de pasos e solucionar problemas por si só. Se a IA escribe unha consulta SQL que non ten valores nulos no campo "Tipo de conta", pode executar a consulta en seco, detectar o erro e solucionalo por si mesmo. Pero e se puidésemos dar un paso máis e deixar que a IA funcione principalmente en Python e aproveitar os LLM? Agora, a IA fai máis que extraer datos. Pode usar paquetes de Python ou LLM para atopar valores atípicos, tendencias ou coñecementos únicos, que normalmente terías que buscar manualmente.  Pero aínda tiñamos un problema: os datos desordenados da empresa. Criamos que as organizacións podían resolver isto utilizando prácticas sólidas de enxeñería de datos, como a  e unha capa semántica estrita. Non obstante, raramente atopamos organizacións que realmente fixesen isto na vida real. A maioría das organizacións usan follas de cálculo, táboas a medias e modelos de datos en constante cambio. A partir de aquí, xurdiu a idea de construír axentes de IA especializados que se poidan construír rapidamente para responder a un conxunto específico de preguntas.   arquitectura de medallón  A medida que as empresas crecen, manexan máis datos e teñen máis usuarios. A idea de malla de axente axuda a equilibrar a rápida toma de decisións co control necesario para o goberno. Os axentes especializados axudan a establecer límites e responsabilidades claras para cada IA. Tamén crean un xeito escalable para que os axentes se comuniquen. Ademais, poden axudar a xestionar os recursos de forma eficiente en equipos e empresas.  Axentes especializados en IA  A idea detrás dun axente especializado é que este axente só pode responder preguntas sobre un conxunto de datos moi ben definido. Por exemplo, podes crear e lanzar un axente de IA que responda preguntas sobre campañas de mercadotecnia. Ou podes crear outro para responder preguntas sobre o pipeline de mercadotecnia, etc.   , utilizando esta arquitectura. Os primeiros signos son moi prometedores. Cando os conxuntos de datos están coidadosamente seleccionados e no nivel de granularidade adecuado, estes axentes poden responder a un conxunto específico de preguntas de forma extremadamente fiable. O creador destes axentes pode compartilos con usuarios non técnicos e estar tranquilo sabendo que a IA non responderá preguntas que estean fóra do alcance.   Recentemente lanzamos Agent Analyst  Só hai un defecto: os usuarios deben saber a que axente acudir para que pregunta. É como ter que coñecer ao analista de mercadotecnia axeitado para facer unha pregunta en comparación con só facer unha pregunta xeral. Cunha pregunta xeral, alguén do equipo pode dirixila á persoa adecuada. Aquí é onde entra en xogo o concepto de "malla de axente".  Conectando axentes  Se un só axente pode responder de forma fiable preguntas específicas do dominio, entón por que non deixar que os axentes falen entre eles? Por que, por exemplo, o axente da campaña de mercadotecnia non pode simplemente preguntarlle directamente ao axente de canalización se pode responder unha pregunta máis facilmente? Cremos que debería ser capaz. De feito, pensamos que no futuro haberá redes de axentes con estrutura xerárquica. Podes imaxinar un "axente GTM" que chama ao "axente de mercadotecnia". Este axente chama entón ao "axente de pipeline" e ao "axente da campaña de marketing".  Esta idea é como unha idea máis xeral flotando arredor da IA coñecida como "  ." É un futuro no que os axentes de IA colaboran sen problemas entre varias organizacións. Fan isto ao tempo que garanten que a seguridade e a confianza sigan sendo fortes.    Internet dos axentes  Este enfoque de malla ofrece algunhas vantaxes clave sobre unha IA monolítica (nunha capa semántica prístina):  Observabilidade: dado que un único axente proporciona respostas baseadas en datos específicos, pode rastrexar cada resposta ata ese axente. Isto axuda a garantir a precisión mediante a auditoría. Para dar un exemplo concreto, aínda que demasiado simplista, imaxina que tes dúas mesas de eventos: unha para marketing e outra para produto. Se un usuario pregunta: "Que eventos xeraron máis ingresos?" a IA pode asumir que se refiren a eventos do produto. Aínda que sexa incorrecto, o usuario pode ver que axente respondeu e pode guiar a IA.  Mantebilidade: do mesmo xeito que un motor de coche, se pode atopar problemas facilmente e substituír rapidamente pezas, o coche faise máis fiable. Se un axente comeza a fallar debido a un cambio no modelo de datos, entón pódese detectar rapidamente e ese axente pódese actualizar.  Precisión: con cada axente operando dentro dos seus propios límites, non hai espazo para que saia dos carrís. Quizais non teña a resposta, pero non fará nada fantasioso.  Ao final, esta idea dunha malla non é nova. Isto reflicte o concepto dunha mestura de expertos que se demostrou que mellora a precisión dos LLM. Simplemente é tomar esa mesma idea e achegala aos axentes de IA.  Retos técnicos das mallas de axentes  En Fabi.ai, temos un longo camiño por percorrer mentres creamos unha malla de axente de analistas. Pero, xa superamos algúns dos grandes desafíos de infraestrutura técnica ao longo do camiño.  Os axentes analistas de datos de IA necesitan unha arquitectura única. Este deseño debe permitirlles usar Python ou LLMs para responder preguntas, manterse sincronizado coas fontes de datos e encaixar en plataformas colaborativas, mentres seguen sendo seguros e escalables. Cada axente debe operar no seu propio núcleo de Python, que debe ser xirado rapidamente cara arriba ou abaixo para reducir custos e manterse sincronizado cos datos de orixe.   As arquitecturas que non proporcionan núcleos individuais a cada axente poden correr nalgún dos seguintes riscos:  Conflito de estado para variables entre axentes de IA. Dous axentes separados poden xerar unha variable "foo" para responder a unha pregunta, provocando un choque. Podería haber outras formas de xerar identificadores únicos, pero estes aumentan as probabilidades de que a IA xere código non válido.  Riscos de seguridade provocados pola compartición de datos entre diferentes equipos ou mesmo organizacións diferentes.  Pescozos de botella de rendemento se un axente ocupa unha cantidade desproporcionada de recursos informáticos.  O desafío de construír este tipo de plataforma é tanto un desafío de IA como un desafío de DevOps.  Mirando cara ao futuro: incorporando axentes de IA especializados e gobernados nos datos  Como as empresas empresariais xestionan máis aplicacións de IA nas súas operacións, necesitan enfoques especializados e ben gobernados. O marco de malla de axentes usa axentes de datos de IA especializados como medio para escalar a IA na análise de datos. Este enfoque mantén intactos a seguridade, a fiabilidade e o rendemento.  Poderiamos esperar que a IA estivese en todas partes a estas alturas, respondendo á maioría das preguntas sobre datos. Pero, se miramos detidamente, o progreso en só dous anos desde o lanzamento de ChatGPT é impresionante. Aínda temos moito que aprender nesta viaxe. Non obstante, na miña opinión, os axentes e os marcos de malla de axentes serán clave para a IA empresarial.

This story contains new, firsthand information uncovered by the writer.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This post provides insights into new product. 

Este audio está producido na lingua orixinal da historia!

Suponse que Text-to-SQL era a aplicación Killer de AI. Non é.

About Author

COMENTARIOS

Etiquetas colgantes

ESTE ARTIGO FOI PRESENTADO EN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Product Management Community!

HackerNoon Decoded 2024: Celebrating Our Science Community!

HackerNoon Decoded 2024: Celebrating Our Startups Community!

HackerNoon Decoded 2024: Celebrating Our Media Community!

HackerNoon Decoded 2024: Celebrating Our Product Management Community!

HackerNoon Decoded 2024: Celebrating Our Science Community!

HackerNoon Decoded 2024: Celebrating Our Startups Community!

HackerNoon Decoded 2024: Celebrating Our Media Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps