Generering af værdi fra virksomhedsdata: bedste praksis for Text2SQL og generativ AI | Amazon Web Services

Generativ AI har åbnet en masse potentiale inden for AI. Vi ser adskillige anvendelser, herunder tekstgenerering, kodegenerering, opsummering, oversættelse, chatbots og mere. Et sådant område, der udvikler sig, er at bruge naturlig sprogbehandling (NLP) til at låse op for nye muligheder for at få adgang til data gennem intuitive SQL-forespørgsler. I stedet for at beskæftige sig med kompleks teknisk kode, kan forretningsbrugere og dataanalytikere stille spørgsmål relateret til data og indsigt i almindeligt sprog. Det primære mål er automatisk at generere SQL-forespørgsler fra naturlig sprogtekst. For at gøre dette transformeres tekstinputtet til en struktureret repræsentation, og ud fra denne repræsentation oprettes en SQL-forespørgsel, der kan bruges til at få adgang til en database.

I dette indlæg giver vi en introduktion til tekst til SQL (Text2SQL) og udforsker use cases, udfordringer, designmønstre og bedste praksis. Konkret diskuterer vi følgende:

• Hvorfor har vi brug for Text2SQL
• Nøglekomponenter til tekst til SQL
• Spørg tekniske overvejelser for naturligt sprog eller tekst til SQL
• Optimeringer og bedste praksis
• Arkitektur mønstre

Hvorfor har vi brug for Text2SQL?

I dag er en stor mængde data tilgængelig i traditionel dataanalyse, data warehousing og databaser, som måske ikke er let at forespørge på eller forstå for størstedelen af ​​organisationens medlemmer. Det primære mål med Text2SQL er at gøre forespørgselsdatabaser mere tilgængelige for ikke-tekniske brugere, som kan levere deres forespørgsler i naturligt sprog.

NLP SQL gør det muligt for forretningsbrugere at analysere data og få svar ved at skrive eller tale spørgsmål i naturligt sprog, såsom følgende:

• "Vis det samlede salg for hvert produkt sidste måned"
• "Hvilke produkter genererede mere omsætning?"
• "Hvilken procentdel af kunderne er fra hver region?"

Amazonas grundfjeld er en fuldt administreret tjeneste, der tilbyder et udvalg af højtydende fundamentmodeller (FM'er) via en enkelt API, hvilket gør det nemt at bygge og skalere Gen AI-applikationer. Det kan udnyttes til at generere SQL-forespørgsler baseret på spørgsmål svarende til dem, der er anført ovenfor, og forespørge organisatoriske strukturerede data og generere naturlige sprogsvar fra forespørgselssvardataene.

Nøglekomponenter til tekst til SQL

Tekst-til-SQL-systemer involverer flere trin for at konvertere naturlige sprogforespørgsler til kørebar SQL:

• Naturlig sprogbehandling:
  • Analyser brugerens inputforespørgsel
  • Uddrag nøgleelementer og hensigt
  • Konverter til et struktureret format
• SQL-generering:
  • Kort udtrukne detaljer til SQL-syntaks
  • Generer en gyldig SQL-forespørgsel
• Databaseforespørgsel:
  • Kør den AI-genererede SQL-forespørgsel på databasen
  • Hent resultater
  • Returner resultater til brugeren

En bemærkelsesværdig egenskab ved Large Language Models (LLM'er) er generering af kode, inklusive Structured Query Language (SQL) til databaser. Disse LLM'er kan udnyttes til at forstå spørgsmålet om det naturlige sprog og generere en tilsvarende SQL-forespørgsel som output. LLM'erne vil drage fordel af at anvende kontekstindlæring og finjustering af indstillinger, efterhånden som flere data leveres.

Følgende diagram illustrerer et grundlæggende Text2SQL-flow.

Spørg tekniske overvejelser for naturligt sprog til SQL

Spørgsmålet er afgørende, når du bruger LLM'er til at oversætte naturligt sprog til SQL-forespørgsler, og der er flere vigtige overvejelser for prompt engineering.

Effektiv hurtig ingeniørarbejde er nøglen til at udvikle naturligt sprog til SQL-systemer. Klare, ligefremme prompter giver bedre instruktioner til sprogmodellen. Giver den kontekst, at brugeren anmoder om en SQL-forespørgsel sammen med relevante databaseskemadetaljer, gør det muligt for modellen at oversætte hensigten nøjagtigt. Inkludering af et par kommenterede eksempler på naturlige sprogprompter og tilsvarende SQL-forespørgsler hjælper med at guide modellen til at producere syntakskompatibelt output. Derudover forbedrer inkorporering af Retrieval Augmented Generation (RAG), hvor modellen henter lignende eksempler under behandlingen, kortlægningsnøjagtigheden yderligere. Veldesignede prompter, der giver modellen tilstrækkelig instruktion, kontekst, eksempler og genfindingsforøgelse, er afgørende for pålidelig oversættelse af naturligt sprog til SQL-forespørgsler.

Det følgende er et eksempel på en basislinjeprompt med koderepræsentation af databasen fra hvidbogen Forbedring af få-shot tekst-til-SQL-kapaciteter i store sprogmodeller: En undersøgelse af hurtige designstrategier.

/* Given the following database schema : */
CREATE TABLE IF NOT EXISTS " gymnast " ( " Gymnast_ID " int , " Floor_Exercise_Points " real , " Pommel_Horse_Points " real , " Rings_Points " real , " Vault_Points " real , " Parallel_Bars_Points " real , " Horizontal_Bar_Points " real , " Total_Points " real , PRIMARY KEY ( " Gymnast_ID " ) , FOREIGN KEY ( " Gymnast_ID " ) REFERENCES " people " ( " People_ID " ) ) ; CREATE TABLE IF NOT EXISTS " people " ( " People_ID " int , " Name " text , " Age " real , " Height " real , " Hometown " text , PRIMARY KEY ( " People_ID " ) ) ; /* Answer the following : Return the total points of the gymnast with the lowest age .
*/ select t1 . total_points from gymnast as t1 join people as t2 on t1 . gymnast_id = t2 .
people_id order by t2 . age asc limit 1

Som illustreret i dette eksempel giver prompt-baseret få-skuds-læring modellen med en håndfuld kommenterede eksempler i selve prompten. Dette demonstrerer målkortlægningen mellem naturligt sprog og SQL for modellen. Typisk vil prompten indeholde omkring 2-3 par, der viser en naturlig sprogforespørgsel og den tilsvarende SQL-sætning. Disse få eksempler guider modellen til at generere syntaks-kompatible SQL-forespørgsler fra naturligt sprog uden at kræve omfattende træningsdata.

Finjustering vs. prompt engineering

Når vi bygger naturligt sprog til SQL-systemer, kommer vi ofte ind i diskussionen om, hvorvidt finjustering af modellen er den rigtige teknik, eller om effektiv prompt engineering er vejen at gå. Begge tilgange kunne overvejes og vælges ud fra det rigtige sæt krav:

• • Finjustering – Grundlinjemodellen er fortrænet på et stort generelt tekstkorpus og kan derefter bruges instruktionsbaseret finjustering, som bruger mærkede eksempler til at forbedre ydeevnen af ​​en forudtrænet fundamentmodel på tekst-SQL. Dette tilpasser modellen til målopgaven. Finjustering træner modellen direkte på slutopgaven, men kræver mange tekst-SQL-eksempler. Du kan bruge overvåget finjustering baseret på din LLM for at forbedre effektiviteten af ​​tekst-til-SQL. Til dette kan du bruge flere datasæt som f.eks Spider, WikiSQL, JAGE, BIRD-SQL eller CoSQL.
  • Hurtig ingeniørarbejde – Modellen er trænet til at fuldføre prompter, der er designet til at anmode SQL-målsyntaksen. Når du genererer SQL fra naturligt sprog ved hjælp af LLM'er, er det vigtigt at give klare instruktioner i prompten for at kontrollere modellens output. I prompten for at annotere forskellige komponenter som at pege på kolonner, skema og derefter instruere hvilken type SQL der skal oprettes. Disse fungerer som instruktioner, der fortæller modellen, hvordan SQL-outputtet skal formateres. Følgende prompt viser et eksempel, hvor du peger på tabelkolonner og instruerer dig i at oprette en MySQL-forespørgsel:

Table offices, columns = [OfficeId, OfficeName]
Table employees, columns = [OfficeId, EmployeeId,EmployeeName]
Create a MySQL query for all employees in the Machine Learning Department

En effektiv tilgang til tekst-til-SQL-modeller er først at starte med en baseline LLM uden nogen opgavespecifik finjustering. Veludformede prompter kan derefter bruges til at tilpasse og drive basismodellen til at håndtere tekst-til-SQL-mapping. Denne hurtige konstruktion giver dig mulighed for at udvikle kapaciteten uden at skulle finjustere. Hvis prompt engineering på basismodellen ikke opnår tilstrækkelig nøjagtighed, kan finjustering på et lille sæt af tekst-SQL-eksempler derefter udforskes sammen med yderligere prompt engineering.

Kombinationen af ​​finjustering og hurtig ingeniørarbejde kan være påkrævet, hvis hurtig konstruktion på den rå præ-trænede model alene ikke opfylder kravene. Det er dog bedst at i første omgang forsøge sig med prompt engineering uden finjustering, fordi dette tillader hurtig iteration uden dataindsamling. Hvis dette ikke giver tilstrækkelig ydeevne, er finjustering sammen med hurtig konstruktion et levedygtigt næste skridt. Denne overordnede tilgang maksimerer effektiviteten, mens den stadig tillader tilpasning, hvis rent prompt-baserede metoder er utilstrækkelige.

Optimering og bedste praksis

Optimering og bedste praksis er afgørende for at øge effektiviteten og sikre, at ressourcer bruges optimalt, og at de rigtige resultater opnås på den bedst mulige måde. Teknikkerne hjælper med at forbedre ydeevnen, kontrollere omkostningerne og opnå et resultat af bedre kvalitet.

Når du udvikler tekst-til-SQL-systemer ved hjælp af LLM'er, kan optimeringsteknikker forbedre ydeevne og effektivitet. Følgende er nogle nøgleområder at overveje:

• Caching – For at forbedre latens, omkostningskontrol og standardisering kan du cache de parsede SQL og genkendte forespørgselsprompter fra tekst-til-SQL LLM. Dette undgår genbehandling af gentagne forespørgsler.
• Overvågning – Logfiler og metrikker omkring forespørgselsparsing, promptgenkendelse, SQL-generering og SQL-resultater bør indsamles for at overvåge tekst-til-SQL LLM-systemet. Dette giver synlighed for optimeringseksemplet ved at opdatere prompten eller gense finjusteringen med et opdateret datasæt.
• Materialiserede visninger vs. tabeller – Materialiserede visninger kan forenkle SQL-generering og forbedre ydeevnen for almindelige tekst-til-SQL-forespørgsler. At forespørge tabeller direkte kan resultere i kompleks SQL og også resultere i ydeevneproblemer, herunder konstant oprettelse af ydeevneteknikker som indekser. Derudover kan du undgå ydeevneproblemer, når den samme tabel bruges til andre anvendelsesområder på samme tid.
• Opdaterer data – Materialiserede visninger skal opdateres på en tidsplan for at holde data opdateret til tekst-til-SQL-forespørgsler. Du kan bruge batch- eller inkrementelle opdateringsmetoder til at balancere overhead.
• Centralt datakatalog – Oprettelse af et centraliseret datakatalog giver et enkelt glasvindue til en organisations datakilder og vil hjælpe LLM'er med at vælge passende tabeller og skemaer for at give mere præcise svar. Vektor indlejringer oprettet fra et centralt datakatalog kan leveres til en LLM sammen med information, der kræves for at generere relevante og præcise SQL-svar.

Ved at anvende bedste praksis for optimering som caching, overvågning, materialiserede visninger, planlagt opdatering og et centralt katalog kan du forbedre ydeevnen og effektiviteten af ​​tekst-til-SQL-systemer ved hjælp af LLM'er markant.

Arkitektur mønstre

Lad os se på nogle arkitekturmønstre, der kan implementeres for en tekst til SQL-arbejdsgang.

Hurtig ingeniørarbejde

Følgende diagram illustrerer arkitekturen til generering af forespørgsler med en LLM ved hjælp af prompt engineering.

I dette mønster opretter brugeren prompt-baseret få-skuds-læring, der giver modellen kommenterede eksempler i selve prompten, som inkluderer tabel- og skemadetaljerne og nogle eksempelforespørgsler med dens resultater. LLM'en bruger den angivne prompt til at returnere den AI-genererede SQL, som valideres og derefter køres mod databasen for at få resultaterne. Dette er det mest ligetil mønster at komme i gang med at bruge prompt engineering. Til dette kan du bruge Amazonas grundfjeld or fundament modeller in Amazon SageMaker JumpStart.

I dette mønster opretter brugeren en prompt-baseret læring, der giver modellen kommenterede eksempler i selve prompten, som inkluderer tabel- og skemadetaljerne og nogle eksempelforespørgsler med resultaterne. LLM'en bruger den angivne prompt til at returnere den AI-genererede SQL, som er valideret og kørt mod databasen for at få resultaterne. Dette er det mest ligetil mønster at komme i gang med at bruge prompt engineering. Til dette kan du bruge Amazonas grundfjeld som er en fuldt administreret tjeneste, der tilbyder et udvalg af højtydende fundamentmodeller (FM'er) fra førende AI-virksomheder via en enkelt API, sammen med et bredt sæt af muligheder, du har brug for til at bygge generative AI-applikationer med sikkerhed, privatliv og ansvarlig AI eller JumpStart Foundation-modeller som tilbyder state-of-the-art fundamentmodeller til brugssager såsom indholdsskrivning, kodegenerering, besvarelse af spørgsmål, copywriting, opsummering, klassificering, informationssøgning og mere

Hurtig ingeniørarbejde og finjustering

Følgende diagram illustrerer arkitekturen til generering af forespørgsler med en LLM ved hjælp af prompt engineering og finjustering.

Dette flow ligner det tidligere mønster, som for det meste er afhængigt af prompt engineering, men med en ekstra flow af finjustering på det domænespecifikke datasæt. Den finjusterede LLM bruges til at generere SQL-forespørgslerne med minimal in-context-værdi for prompten. Til dette kan du bruge SageMaker JumpStart til at finjustere en LLM på et domænespecifikt datasæt på samme måde, som du ville træne og implementere enhver model på Amazon SageMaker.

Hurtig ingeniørarbejde og RAG

Følgende diagram illustrerer arkitekturen til generering af forespørgsler med en LLM ved hjælp af prompt engineering og RAG.

I dette mønster bruger vi Retrieval Augmented Generation ved hjælp af vektorindlejringsbutikker, som Amazon Titan-indlejringer or Cohere Embed, On Amazonas grundfjeld fra et centralt datakatalog, f.eks AWS Lim Datakatalog, af databaser i en organisation. Vektorindlejringerne gemmes i vektordatabaser som f.eks Vector Engine til Amazon OpenSearch Serverless, Amazon Relational Database Service (Amazon RDS) til PostgreSQL med pgvektor forlængelse, eller Amazon Kendra. LLM'er bruger vektorindlejringerne til at vælge den rigtige database, tabeller og kolonner fra tabeller hurtigere, når de opretter SQL-forespørgsler. Brug af RAG er nyttigt, når data og relevant information, der skal hentes af LLM'er, er lagret i flere separate databasesystemer, og LLM'en skal være i stand til at søge eller forespørge data fra alle disse forskellige systemer. Det er her, at levering af vektorindlejringer af et centraliseret eller samlet datakatalog til LLM'erne resulterer i mere nøjagtig og omfattende information, som returneres af LLM'erne.

Konklusion

I dette indlæg diskuterede vi, hvordan vi kan generere værdi fra virksomhedsdata ved hjælp af naturligt sprog til SQL-generering. Vi undersøgte nøglekomponenter, optimering og bedste praksis. Vi lærte også arkitekturmønstre fra grundlæggende prompt engineering til finjustering og RAG. For at lære mere, se Amazonas grundfjeld til nemt at bygge og skalere generative AI-applikationer med fundamentmodeller

Om forfatterne

Randy DeFauw er Senior Principal Solutions Architect hos AWS. Han har en MSEE fra University of Michigan, hvor han arbejdede med computersyn til autonome køretøjer. Han har også en MBA fra Colorado State University. Randy har haft en række forskellige stillinger inden for teknologiområdet, lige fra softwareudvikling til produktstyring. In gik ind i Big Data-området i 2013 og fortsætter med at udforske dette område. Han arbejder aktivt på projekter i ML-området og har præsenteret på adskillige konferencer, herunder Strata og GlueCon.

Nitin Eusebius er Sr. Enterprise Solutions Architect hos AWS, erfaren i Software Engineering, Enterprise Architecture og AI/ML. Han er dybt passioneret omkring at udforske mulighederne for generativ AI. Han samarbejder med kunder for at hjælpe dem med at bygge veldesignede applikationer på AWS-platformen og er dedikeret til at løse teknologiske udfordringer og hjælpe med deres cloud-rejse.

Arghya Banerjee er Sr. Solutions Architect hos AWS i San Francisco Bay Area med fokus på at hjælpe kunder med at adoptere og bruge AWS Cloud. Arghya er fokuseret på Big Data, Data Lakes, Streaming, Batch Analytics og AI/ML tjenester og teknologier.

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk dig selv. Adgang her.
• PlatoAiStream. Web3 intelligens. Viden forstærket. Adgang her.
• PlatoESG. Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
• PlatoHealth. Bioteknologiske og kliniske forsøgs intelligens. Adgang her.
• Kilde: https://aws.amazon.com/blogs/machine-learning/generating-value-from-enterprise-data-best-practices-for-text2sql-and-generative-ai/