Criando uma vantagem de informação com acesso conversacional aos dados

Republicado por Platão

seguidores: 0

IA conversacional para análise de dados

Figura 1: Representação do fluxo Text2SQL

À medida que nosso mundo se torna mais global e dinâmico, as empresas dependem cada vez mais de dados para tomar decisões informadas, objetivas e oportunas. No entanto, a partir de agora, liberar todo o potencial dos dados organizacionais costuma ser um privilégio de um punhado de cientistas e analistas de dados. A maioria dos funcionários não domina o kit de ferramentas convencional de ciência de dados (SQL, Python, R etc.). Para acessar os dados desejados, eles passam por uma camada adicional onde analistas ou equipes de BI “traduzem” a prosa das questões de negócios para a linguagem dos dados. O potencial de atrito e ineficiência nessa jornada é alto — por exemplo, os dados podem ser entregues com atrasos ou mesmo quando a pergunta já se tornou obsoleta. As informações podem se perder ao longo do caminho quando os requisitos não são traduzidos com precisão em consultas analíticas. Além disso, gerar insights de alta qualidade requer uma abordagem iterativa que é desencorajada a cada passo adicional no loop. Por outro lado, essas interações ad hoc criam disrupção para talentos de dados caros e os distraem do trabalho de dados mais estratégico, conforme descrito nestas “confissões” de um cientista de dados:

Quando eu estava na Square e a equipe era menor, tínhamos uma temida rotação de “analítica de plantão”. Era estritamente alternado semanalmente e, se fosse sua vez, você sabia que faria muito pouco trabalho “real” naquela semana e passaria a maior parte do tempo respondendo a perguntas ad hoc das várias equipes de produtos e operações no empresa (SQL monkeying, nós o chamávamos). Houve uma competição acirrada por funções de gerente na equipe de análise e acho que isso foi inteiramente o resultado de gerentes serem isentos dessa rotação - nenhum prêmio de status poderia rivalizar com a cenoura de não fazer trabalho de plantão.[1]

Na verdade, não seria legal falar diretamente com seus dados em vez de ter que passar por várias rodadas de interação com sua equipe de dados? Essa visão é abraçada por interfaces de conversação que permitem que humanos interajam com dados usando a linguagem, nosso canal de comunicação mais intuitivo e universal. Depois de analisar uma pergunta, um algoritmo a codifica em uma forma lógica estruturada na linguagem de consulta de sua escolha, como SQL. Assim, os usuários não técnicos podem conversar com seus dados e obter rapidamente informações específicas, relevantes e oportunas, sem fazer o desvio por meio de uma equipe de BI. Neste artigo, vamos considerar os diferentes aspectos de implementação do Text2SQL e focar em abordagens modernas com o uso de Large Language Models (LLMs), que alcançam o melhor desempenho até o momento (cf. [2]; para uma pesquisa sobre abordagens alternativas além dos LLMs, os leitores são referidos [3]). O artigo está estruturado de acordo com o seguinte “modelo mental” dos principais elementos a serem considerados ao planejar e construir um recurso de IA:

IA conversacional para análise de dados — Figura 2: Modelo mental de um recurso de IA

Vamos começar com o objetivo em mente e recapitular o valor — por que você criaria um recurso Text2SQL em seu produto de análise ou dados. Os três principais benefícios são:

Usuários de negócios podem acessar dados organizacionais de maneira direta e oportuna.
Isso alivia cientistas e analistas de dados da carga de solicitações ad hoc de usuários corporativos e permite que eles se concentrem nos desafios de dados avançados.
Isso permite que negócio alavancar seus dados de forma mais fluida e estratégica, transformando-os finalmente em uma base sólida para a tomada de decisões.

Agora, quais são os cenários de produto nos quais você pode considerar o Text2SQL? As três configurações principais são:

Você está oferecendo um dados escalonáveis/produto de BI e deseja permitir que mais usuários acessem seus dados de maneira não técnica, aumentando assim o uso e a base de usuários. Por exemplo, a ServiceNow tem consultas de dados integradas em uma oferta de conversação maior e Atlan tem recentemente anunciou a exploração de dados em linguagem natural.
Você está procurando construir algo no espaço de dados/IA para democratizar o acesso a dados nas empresas, caso em que você poderia considerar um MVP com Text2SQL no núcleo. Provedores como AI2SQL e Text2sql.ai já estão a fazer uma entrada neste espaço.
Você está trabalhando em um sistema de BI personalizado e querem maximizar e democratizar seu uso na empresa individual.

Como veremos nas seções a seguir, o Text2SQL requer uma configuração inicial não trivial. Para estimar o ROI, considere a natureza das decisões que serão suportadas, bem como os dados disponíveis. O Text2SQL pode ser uma vitória absoluta em ambientes dinâmicos onde os dados mudam rapidamente e são usados de forma ativa e frequente na tomada de decisões, como investimentos, marketing, manufatura e indústria de energia. Nesses ambientes, as ferramentas tradicionais de gestão do conhecimento são muito estáticas e formas mais fluídas de acessar dados e informações ajudam as empresas a gerar vantagem competitiva. Em termos de dados, o Text2SQL fornece o maior valor com um banco de dados que é:

Grande e crescente, para que o Text2SQL possa desdobrar seu valor ao longo do tempo à medida que mais e mais dados são aproveitados.
Alta qualidade, para que o algoritmo Text2SQL não tenha que lidar com ruído excessivo (inconsistências, valores vazios etc.) nos dados. Em geral, os dados gerados automaticamente por aplicativos têm maior qualidade e consistência do que os dados criados e mantidos por humanos.
Semanticamente maduro em vez de bruto, para que os humanos possam consultar os dados com base em conceitos centrais, relacionamentos e métricas que existem em seu modelo mental. Observe que a maturidade semântica pode ser alcançada por uma etapa de transformação adicional que conforma os dados brutos em uma estrutura conceitual (consulte a seção “Enriquecendo o prompt com informações do banco de dados”).

A seguir, vamos aprofundar os dados, algoritmo, experiência do usuário, bem como os requisitos não funcionais relevantes de um recurso Text2SQL. O artigo foi escrito para gerentes de produto, designers de UX e cientistas e engenheiros de dados que estão no início de sua jornada Text2SQL. Para essas pessoas, ele fornece não apenas um guia para começar, mas também uma base comum de conhecimento para discussões sobre as interfaces entre produto, tecnologia e negócios, incluindo as compensações relacionadas. Se você já está mais avançado em sua implementação, as referências no final fornecem uma variedade de mergulhos profundos para explorar.

Se este conteúdo educacional aprofundado for útil para você, você pode assine nossa lista de discussão sobre pesquisa em IA para ser alertado quando lançarmos novo material.

1. Dados

Qualquer empreendimento de aprendizado de máquina começa com dados, portanto, começaremos esclarecendo a estrutura dos dados de entrada e de destino que são usados durante o treinamento e a previsão. Ao longo do artigo, usaremos o fluxo Text2SQL da Figura 1 como nossa representação em execução e destacaremos os componentes e relacionamentos atualmente considerados em amarelo.

1.1 Formato e estrutura dos dados

Normalmente, um par de entrada-saída Text2SQL bruto consiste em uma pergunta de linguagem natural e a consulta SQL correspondente, por exemplo:

Questão"Liste o nome e o número de seguidores de cada usuário.”

Consulta SQL:

selecione nome, seguidores de user_profiles

No espaço de dados de treinamento, o mapeamento entre perguntas e consultas SQL é de muitos para muitos:

Uma consulta SQL pode ser mapeada para muitas perguntas diferentes em linguagem natural; por exemplo, a semântica de consulta acima pode ser expressa por: “mostre-me os nomes e números de seguidores por usuário","quantos seguidores existem para cada usuário?”Etc.
A sintaxe SQL é altamente versátil e quase todas as perguntas podem ser representadas em SQL de várias maneiras. O exemplo mais simples são diferentes ordenações de cláusulas WHERE. Em uma postura mais avançada, todos que fizeram otimização de consulta SQL saberão que muitos caminhos levam ao mesmo resultado, e consultas semanticamente equivalentes podem ter sintaxe completamente diferente.

A coleta manual de dados de treinamento para Text2SQL é particularmente tediosa. Ele não apenas requer domínio de SQL por parte do anotador, mas também mais tempo por exemplo do que tarefas linguísticas mais gerais, como análise de sentimento e classificação de texto. Para garantir uma quantidade suficiente de exemplos de treinamento, o aumento de dados pode ser usado — por exemplo, LLMs podem ser usados para gerar paráfrases para a mesma pergunta. [3] fornece uma pesquisa mais completa das técnicas de aumento de dados Text2SQL.

1.2 Enriquecendo o prompt com informações do banco de dados

Text2SQL é um algoritmo na interface entre dados não estruturados e estruturados. Para um desempenho ideal, ambos os tipos de dados precisam estar presentes durante o treinamento e a previsão. Especificamente, o algoritmo deve conhecer o banco de dados consultado e ser capaz de formular a consulta de forma que possa ser executada no banco de dados. Este conhecimento pode abranger:

Colunas e tabelas do banco de dados
Relações entre tabelas (chaves estrangeiras)
conteúdo do banco de dados

Existem duas opções para incorporar o conhecimento do banco de dados: por um lado, os dados de treinamento podem ser restritos a exemplos escritos para o banco de dados específico, caso em que o esquema é aprendido diretamente da consulta SQL e seu mapeamento para a pergunta. Esta configuração de banco de dados único permite otimizar o algoritmo para um banco de dados individual e/ou empresa. No entanto, elimina qualquer ambição de escalabilidade, pois o modelo precisa ser ajustado para cada cliente ou banco de dados. Como alternativa, em uma configuração de vários bancos de dados, o esquema do banco de dados pode ser fornecido como parte da entrada, permitindo que o algoritmo “generalize” para novos esquemas de banco de dados não vistos. Embora seja absolutamente necessário optar por essa abordagem se quiser usar o Text2SQL em muitos bancos de dados diferentes, lembre-se de que isso requer um esforço de engenharia imediato considerável. Para qualquer banco de dados de negócios razoável, incluir as informações completas no prompt será extremamente ineficiente e provavelmente impossível devido às limitações de tamanho do prompt. Assim, a função responsável pela formulação imediata deve ser inteligente o suficiente para selecionar um subconjunto de informações do banco de dados que seja mais “útil” para uma determinada questão e fazer isso para bancos de dados potencialmente não vistos.

Finalmente, a estrutura do banco de dados desempenha um papel crucial. Nos cenários em que você tem controle suficiente sobre o banco de dados, pode facilitar a vida do seu modelo permitindo que ele aprenda a partir de uma estrutura intuitiva. Como regra geral, quanto mais seu banco de dados refletir como os usuários de negócios falam sobre o negócio, melhor e mais rápido seu modelo poderá aprender com ele. Portanto, considere aplicar transformações adicionais aos dados, como reunir dados normalizados ou dispersos em tabelas amplas ou um cofre de dados, nomear tabelas e colunas de maneira explícita e inequívoca, etc. Todo o conhecimento de negócios que você pode codificar antecipadamente reduzirá o peso do aprendizado probabilístico em seu modelo e ajudá-lo a obter melhores resultados.

2. Algoritmo

Text2SQL é um tipo de análise semântica — o mapeamento de textos para representações lógicas. Assim, o algoritmo não precisa apenas “aprender” a linguagem natural, mas também a representação de destino — no nosso caso, SQL. Especificamente, ele tem que adquirir e os seguintes bits de conhecimento:

Sintaxe e semântica SQL
Estrutura de banco de dados
Compreensão da linguagem natural (NLU)
Mapeamento entre linguagem natural e consultas SQL (sintática, lexical e semântica)

2.1 Resolvendo a variabilidade linguística na entrada

Na entrada, o principal desafio do Text2SQL está na flexibilidade da linguagem: conforme descrito na seção Formato e estrutura dos dados, uma mesma pergunta pode ser parafraseada de várias maneiras diferentes. Além disso, no contexto de conversação da vida real, temos que lidar com vários problemas, como erros de ortografia e gramática, entradas incompletas e ambíguas, entradas multilíngues, etc.

LLMs como os modelos GPT, T5 e CodeX estão cada vez mais perto de resolver esse desafio. Aprendendo com grandes quantidades de textos diversos, eles aprendem a lidar com um grande número de padrões linguísticos e irregularidades. No final, eles se tornam capazes de generalizar sobre questões que são semanticamente semelhantes, apesar de terem diferentes formas de superfície. Os LLMs podem ser aplicados imediatamente (zero-shot) ou após o ajuste fino. O primeiro, embora conveniente, leva a uma menor precisão. Este último requer mais habilidade e trabalho, mas pode aumentar significativamente a precisão.

Em termos de precisão, como esperado, os modelos de melhor desempenho são os modelos mais recentes da família GPT, incluindo os modelos CodeX. Em abril de 2023, o GPT-4 levou a um aumento dramático de precisão de mais de 5% em relação ao estado da arte anterior e alcançou uma precisão de 85.3% (na métrica “execução com valores”).[4] No campo de código aberto, as tentativas iniciais de resolver o quebra-cabeça Text2SQL foram focadas em modelos de codificação automática, como BERT, que se destacam em tarefas NLU. [5, 6, 7] em modelos autorregressivos como o modelo T5. O T5 é pré-treinado usando aprendizagem multitarefa e, portanto, adapta-se facilmente a novas tarefas linguísticas, incl. diferentes variantes de análise semântica. No entanto, os modelos autorregressivos têm uma falha intrínseca quando se trata de tarefas de análise semântica: eles têm um espaço de saída irrestrito e nenhuma proteção semântica que restringiria sua saída, o que significa que eles podem ser incrivelmente criativos em seu comportamento. Embora isso seja incrível para gerar conteúdo de formato livre, é um incômodo para tarefas como Text2SQL, onde esperamos uma saída de destino bem estruturada e restrita.

2.2 Validação e melhoria da consulta

Para restringir a saída do LLM, podemos introduzir mecanismos adicionais para validar e melhorar a consulta. Isso pode ser implementado como uma etapa extra de validação, conforme proposto no sistema PICARD.[8] O PICARD usa um analisador SQL que pode verificar se uma consulta SQL parcial pode levar a uma consulta SQL válida após a conclusão. A cada etapa de geração pelo LLM, os tokens que invalidariam a consulta são rejeitados e os tokens válidos de maior probabilidade são mantidos. Sendo determinística, essa abordagem garante 100% de validade SQL, desde que o analisador observe as regras SQL corretas. Também dissocia a validação da consulta da geração, permitindo assim manter ambos os componentes independentemente um do outro e atualizar e modificar o LLM.

Outra abordagem é incorporar conhecimento estrutural e SQL diretamente no LLM. Por exemplo, Graphix [9] usa camadas com reconhecimento de gráfico para injetar conhecimento SQL estruturado no modelo T5. Devido à natureza probabilística dessa abordagem, ela direciona o sistema para consultas corretas, mas não oferece garantia de sucesso.

Por fim, o LLM pode ser usado como um agente de várias etapas que pode verificar e melhorar a consulta de forma autônoma.[10] Usando várias etapas em um prompt de cadeia de pensamento, o agente pode ser encarregado de refletir sobre a exatidão de suas próprias consultas e melhorar quaisquer falhas. Se a consulta validada ainda não puder ser executada, o rastreamento de exceção SQL pode ser passado para o agente como um feedback adicional para melhoria.

Além desses métodos automatizados que acontecem no back-end, também é possível envolver o usuário durante o processo de verificação da consulta. Descreveremos isso com mais detalhes na seção Experiência do usuário.

2.3 Avaliação

Para avaliar nosso algoritmo Text2SQL, precisamos gerar um conjunto de dados de teste (validação), executar nosso algoritmo nele e aplicar métricas de avaliação relevantes no resultado. Um conjunto de dados ingênuo dividido em dados de treinamento, desenvolvimento e validação seria baseado em pares de perguntas e consultas e levaria a resultados abaixo do ideal. As consultas de validação podem ser reveladas ao modelo durante o treinamento e levar a uma visão excessivamente otimista de suas habilidades de generalização. A divisão baseada em consulta, onde o conjunto de dados é dividido de forma que nenhuma consulta apareça durante o treinamento e durante a validação, fornece resultados mais verdadeiros.

Em termos de métricas de avaliação, o que nos preocupa no Text2SQL não é gerar consultas totalmente idênticas ao padrão ouro. Esse “correspondência de string exata” O método é muito rígido e gerará muitos falsos negativos, pois diferentes consultas SQL podem levar ao mesmo conjunto de dados retornado. Em vez disso, queremos alcançar alta precisão semântica e avaliar se as consultas preditas e “padrão-ouro” sempre retornariam os mesmos conjuntos de dados. Existem três métricas de avaliação que se aproximam desse objetivo:

Precisão de correspondência exata: as consultas SQL geradas e de destino são divididas em seus constituintes e os conjuntos resultantes são comparados quanto à identidade.[11] A desvantagem aqui é que ele considera apenas variações de ordem na consulta SQL, mas não diferenças sintáticas mais pronunciadas entre consultas semanticamente equivalentes.
Precisão de execução: os conjuntos de dados resultantes das consultas SQL geradas e de destino são comparados quanto à identidade. Com sorte, as consultas com semântica diferente ainda podem passar neste teste em uma instância de banco de dados específica. Por exemplo, assumindo um banco de dados em que todos os usuários tenham mais de 30 anos, as duas consultas a seguir retornariam resultados idênticos, apesar de terem semântica diferente:
selecione * do usuário
selecione * do usuário com idade > 30
Precisão do conjunto de testes: a precisão do conjunto de testes é uma versão mais avançada e menos permissiva da precisão da execução. Para cada consulta, é gerado um conjunto (“suíte de teste”) de bancos de dados altamente diferenciados em relação às variáveis, condições e valores da consulta. Em seguida, a precisão da execução é testada em cada um desses bancos de dados. Embora exija esforço adicional para projetar a geração do conjunto de testes, essa métrica também reduz significativamente o risco de falsos positivos na avaliação.[12]

3. Experiência do usuário

O atual estado-da-arte do Text2SQL não permite uma integração totalmente perfeita em sistemas de produção — ao contrário, é necessário gerenciar ativamente as expectativas e o comportamento do usuário, que deve estar sempre ciente de que está interagindo com um sistema de IA.

3.1 Gerenciamento de falhas

Text2SQL pode falhar em dois modos, que precisam ser capturados de maneiras diferentes:

Erros de SQL: a consulta gerada não é válida — o SQL é inválido ou não pode ser executado no banco de dados específico devido a falhas léxicas ou semânticas. Nesse caso, nenhum resultado pode ser retornado ao usuário.
erros semânticos: a consulta gerada é válida, mas não reflete a semântica da pergunta, levando a um conjunto de dados retornado errado.

O segundo modo é particularmente complicado, pois o risco de “falhas silenciosas” – erros que não são detectados pelo usuário – é alto. O usuário protótipo não terá tempo nem habilidade técnica para verificar a exatidão da consulta e/ou dos dados resultantes. Quando os dados são usados para a tomada de decisões no mundo real, esse tipo de falha pode ter consequências devastadoras. Para evitar isso, é fundamental educar os usuários e estabelecer guardrails em um nível de negócios que limitam o impacto potencial, como verificações de dados adicionais para decisões com maior impacto. Por outro lado, também podemos usar a interface do usuário para gerenciar a interação homem-máquina e ajudar o usuário a detectar e melhorar solicitações problemáticas.

3.2 Interação homem-máquina

Os usuários podem se envolver com seu sistema de IA com diferentes graus de intensidade. Mais interação por solicitação pode levar a melhores resultados, mas também diminui a fluidez da experiência do usuário. Além do potencial impacto negativo de consultas e resultados errôneos, considere também o quão motivados seus usuários estarão para fornecer feedback de ida e volta para obter resultados mais precisos e também ajudar a melhorar o produto a longo prazo.

A maneira mais fácil e menos envolvente é trabalhar com pontuações de confiança. Embora o cálculo ingênuo de confiança como uma média das probabilidades dos tokens gerados seja excessivamente simplista, métodos mais avançados, como feedback verbalizado, podem ser usados. [13] A confiança pode ser exibida na interface e destacada com um alerta explícito caso esteja perigosamente baixa. Dessa forma, a responsabilidade de um acompanhamento adequado no “mundo real” — seja uma rejeição, aceitação ou verificação adicional dos dados — recai sobre o seu usuário. Embora seja uma aposta segura para você como fornecedor, transferir esse trabalho para o usuário também pode reduzir o valor do seu produto.

Uma segunda possibilidade é envolver o usuário em um diálogo de esclarecimento no caso de consultas de baixa confiança, ambíguas ou suspeitas. Por exemplo, seu sistema pode sugerir correções ortográficas ou gramaticais para a entrada e pedir para desambiguar palavras específicas ou estruturas gramaticais. Também pode permitir que o usuário solicite proativamente correções na consulta:[14]

DO UTILIZADOR: Mostre-me as tarefas de John neste sprint.

ASSISTENTE: Você gostaria de ver as tarefas que John criou ou nas quais ele está trabalhando?

DO UTILIZADOR: tarefas que John criou

ASSISTENTE: Ok, aqui estão os IDs das tarefas:

DO UTILIZADOR: Obrigado, também gostaria de ver mais informações sobre as tarefas. Classifique também por urgência.

ASSISTENTE: Claro, aqui estão as tarefas junto com breves descrições, responsáveis e prazos, classificados por prazo.

Por fim, para facilitar o entendimento das consultas pelo usuário, seu sistema também pode fornecer uma reformulação textual explícita da consulta e solicitar ao usuário que confirme ou corrija.[15]

4. Requisitos não funcionais

Nesta seção, discutimos os requisitos não funcionais específicos para Text2SQL, bem como as compensações entre eles. Vamos nos concentrar nos seis requisitos que parecem mais importantes para a tarefa: precisão, escalabilidade, velocidade, explicabilidade, privacidade e adaptabilidade ao longo do tempo.

4.1 precisão

Para Text2SQL, os requisitos de precisão são altos. Primeiro, o Text2SQL é normalmente aplicado em uma configuração de conversa em que as previsões são feitas uma a uma. Assim, a “Lei dos grandes números”, que normalmente ajuda a equilibrar o erro nas previsões em lote, não ajuda. Em segundo lugar, a validade sintática e lexical é uma condição “difícil”: o modelo precisa gerar uma consulta SQL bem formada, potencialmente com sintaxe e semântica complexas, caso contrário, a solicitação não pode ser executada no banco de dados. E se tudo correr bem e a consulta puder ser executada, ela ainda pode conter erros semânticos e levar a um conjunto de dados retornado errado (consulte a seção 3.1 Gerenciamento de falhas).

Escalabilidade 4.2

As principais considerações de escalabilidade são se você deseja aplicar o Text2SQL em um ou vários bancos de dados — e, no último caso, se o conjunto de bancos de dados é conhecido e fechado. Se sim, você terá mais facilidade, pois poderá incluir as informações sobre esses bancos de dados durante o treinamento. No entanto, em um cenário de um produto escalável — seja um aplicativo Text2SQL independente ou uma integração em um produto de dados existente — seu algoritmo precisa lidar com qualquer novo esquema de banco de dados em tempo real. Este cenário também não oferece a oportunidade de transformar a estrutura do banco de dados para torná-lo mais intuitivo para o aprendizado (link!). Tudo isso leva a um grande compromisso com a precisão, o que também pode explicar por que os atuais provedores de Text2SQL que oferecem consultas ad hoc de novos bancos de dados ainda não atingiram uma penetração significativa no mercado.

Velocidade 4.3

Como as solicitações Text2SQL normalmente são processadas online em uma conversa, o aspecto da velocidade é importante para a satisfação do usuário. Do lado positivo, os usuários geralmente estão cientes do fato de que as solicitações de dados podem levar um certo tempo e mostrar a paciência necessária. No entanto, essa boa vontade pode ser prejudicada pela configuração do bate-papo, em que os usuários inconscientemente esperam uma velocidade de conversa semelhante à humana. Os métodos de otimização de força bruta, como reduzir o tamanho do modelo, podem ter um impacto inaceitável na precisão, portanto, considere a otimização de inferência para atender a essa expectativa.

4.4 Explicabilidade e transparência

No caso ideal, o usuário pode acompanhar como a consulta foi gerada a partir do texto, ver o mapeamento entre palavras ou expressões específicas na questão e a consulta SQL etc. Isso permite verificar a consulta e fazer eventuais ajustes ao interagir com o sistema . Além disso, o sistema também poderia fornecer uma reformulação textual explícita da consulta e pedir ao usuário para confirmá-la ou corrigi-la.

Privacidade 4.5

A função Text2SQL pode ser isolada da execução da consulta, para que as informações do banco de dados retornadas possam ser mantidas invisíveis. No entanto, a questão crítica é quanta informação sobre o banco de dados está incluída no prompt. As três opções (diminuindo o nível de privacidade) são:

Nenhuma informação
Esquema do banco de dados
conteúdo do banco de dados

Privacidade compensa com precisão - quanto menos limitado você estiver em incluir informações úteis no prompt, melhores serão os resultados.

4.6 Adaptabilidade ao longo do tempo

Para usar o Text2SQL de forma durável, você precisa se adaptar ao desvio de dados, ou seja, a mudança na distribuição dos dados aos quais o modelo é aplicado. Por exemplo, vamos supor que os dados usados para o ajuste fino inicial reflitam o comportamento de consulta simples dos usuários quando eles começam a usar o sistema de BI. Com o passar do tempo, as necessidades de informação dos usuários tornam-se mais sofisticadas e exigem consultas mais complexas, que sobrecarregam seu modelo ingênuo. Além disso, os objetivos ou a estratégia de mudança de uma empresa também podem desviar e direcionar as necessidades de informação para outras áreas do banco de dados. Por fim, um desafio específico do Text2SQL é o desvio do banco de dados. À medida que o banco de dados da empresa é estendido, novas colunas e tabelas inéditas aparecem no prompt. Embora os algoritmos Text2SQL projetados para aplicativos de vários bancos de dados possam lidar bem com esse problema, eles podem afetar significativamente a precisão de um modelo de banco de dados único. Todos esses problemas são melhor resolvidos com um conjunto de dados de ajuste fino que reflete o comportamento atual e real dos usuários. Portanto, é crucial registrar as perguntas e os resultados do usuário, bem como qualquer feedback associado que possa ser coletado do uso. Além disso, algoritmos de agrupamento semântico, por exemplo, usando incorporações ou modelagem de tópicos, podem ser aplicados para detectar mudanças subjacentes de longo prazo no comportamento do usuário e usá-los como uma fonte adicional de informações para aperfeiçoar seu conjunto de dados de ajuste fino

Conclusão

Vamos resumir os pontos principais do artigo:

O Text2SQL permite implementar um acesso intuitivo e democrático aos dados de uma empresa, maximizando assim o valor dos dados disponíveis.
Os dados Text2SQL consistem em perguntas na entrada e consultas SQL na saída. O mapeamento entre perguntas e consultas SQL é de muitos para muitos.
É importante fornecer informações sobre o banco de dados como parte do prompt. Além disso, a estrutura do banco de dados pode ser otimizada para facilitar o aprendizado e a compreensão do algoritmo.
Na entrada, o principal desafio é a variabilidade linguística de questões de linguagem natural, que podem ser abordadas usando LLMs que foram pré-treinados em uma ampla variedade de estilos de texto diferentes
A saída de Text2SQL deve ser uma consulta SQL válida. Essa restrição pode ser incorporada “injetando” conhecimento SQL no algoritmo; alternativamente, usando uma abordagem iterativa, a consulta pode ser verificada e aprimorada em várias etapas.
Devido ao impacto potencialmente alto de “falhas silenciosas” que retornam dados errados para a tomada de decisões, o gerenciamento de falhas é uma preocupação primária na interface do usuário.
De forma “aumentada”, os usuários podem se envolver ativamente na validação iterativa e na melhoria das consultas SQL. Embora isso torne o aplicativo menos fluido, também reduz as taxas de falha, permite que os usuários explorem os dados de maneira mais flexível e crie sinais valiosos para aprendizado adicional.
Os principais requisitos não funcionais a serem considerados são precisão, escalabilidade, velocidade, explicabilidade, privacidade e adaptabilidade ao longo do tempo. As principais compensações consistem entre precisão, por um lado, e escalabilidade, velocidade e privacidade, por outro lado.