Generer verdi fra bedriftsdata: Beste praksis for Text2SQL og generativ AI | Amazon Web Services

Generativ AI har åpnet opp mye potensial innen AI. Vi ser mange bruksområder, inkludert tekstgenerering, kodegenerering, oppsummering, oversettelse, chatbots og mer. Et slikt område som utvikler seg er å bruke naturlig språkbehandling (NLP) for å låse opp nye muligheter for tilgang til data gjennom intuitive SQL-spørringer. I stedet for å forholde seg til kompleks teknisk kode, kan bedriftsbrukere og dataanalytikere stille spørsmål knyttet til data og innsikt i klartekst. Det primære målet er å automatisk generere SQL-spørringer fra naturlig språktekst. For å gjøre dette transformeres tekstinngangen til en strukturert representasjon, og fra denne representasjonen opprettes en SQL-spørring som kan brukes til å få tilgang til en database.

I dette innlegget gir vi en introduksjon til tekst til SQL (Text2SQL) og utforsker brukstilfeller, utfordringer, designmønstre og beste praksis. Konkret diskuterer vi følgende:

• Hvorfor trenger vi Text2SQL
• Nøkkelkomponenter for tekst til SQL
• Spør tekniske vurderinger for naturlig språk eller tekst til SQL
• Optimaliseringer og beste praksis
• Arkitektur mønstre

Hvorfor trenger vi Text2SQL?

I dag er en stor mengde data tilgjengelig i tradisjonell dataanalyse, datavarehus og databaser, som kanskje ikke er lett å spørre etter eller forstå for flertallet av organisasjonsmedlemmer. Det primære målet med Text2SQL er å gjøre spørringsdatabaser mer tilgjengelige for ikke-tekniske brukere, som kan gi spørringene sine på naturlig språk.

NLP SQL gjør det mulig for forretningsbrukere å analysere data og få svar ved å skrive eller snakke spørsmål på naturlig språk, for eksempel følgende:

• «Vis totalt salg for hvert produkt forrige måned»
• "Hvilke produkter genererte mer inntekter?"
• "Hvilken prosentandel av kundene er fra hver region?"

Amazonas grunnfjell er en fullstendig administrert tjeneste som tilbyr et utvalg av høyytende fundamentmodeller (FM-er) via en enkelt API, som gjør det enkelt å bygge og skalere Gen AI-applikasjoner. Den kan utnyttes til å generere SQL-spørringer basert på spørsmål som ligner på de som er oppført ovenfor og spørre organisasjonsstrukturerte data og generere naturlig språksvar fra spørringsresponsdataene.

Nøkkelkomponenter for tekst til SQL

Tekst-til-SQL-systemer involverer flere stadier for å konvertere naturlige språkspørringer til kjørbar SQL:

• Naturlig språkbehandling:
  • Analyser brukerens inndataspørring
  • Trekk ut nøkkelelementer og intensjoner
  • Konverter til et strukturert format
• SQL generering:
  • Kartlegg utpakkede detaljer til SQL-syntaks
  • Generer en gyldig SQL-spørring
• Databasespørring:
  • Kjør den AI-genererte SQL-spørringen på databasen
  • Hent resultater
  • Returner resultater til brukeren

En bemerkelsesverdig evne til Large Language Models (LLM) er generering av kode, inkludert Structured Query Language (SQL) for databaser. Disse LLM-ene kan utnyttes til å forstå spørsmålet om naturlig språk og generere en tilsvarende SQL-spørring som utdata. LLM-ene vil dra nytte av å ta i bruk kontekstlæring og finjusteringsinnstillinger etter hvert som mer data blir levert.

Følgende diagram illustrerer en grunnleggende Text2SQL-flyt.

Spør tekniske vurderinger for naturlig språk til SQL

Spørsmålet er avgjørende når du bruker LLM-er for å oversette naturlig språk til SQL-spørringer, og det er flere viktige hensyn for prompt engineering.

Effektiv rask prosjektering er nøkkelen til å utvikle naturlig språk til SQL-systemer. Klare, enkle spørsmål gir bedre instruksjoner for språkmodellen. Ved å gi kontekst at brukeren ber om en SQL-spørring sammen med relevante databaseskjemadetaljer, kan modellen oversette intensjonen nøyaktig. Inkludering av noen få kommenterte eksempler på spørsmål om naturlig språk og tilsvarende SQL-spørringer hjelper modellen til å produsere syntakskompatibel utdata. I tillegg forbedrer kartleggingsnøyaktigheten ytterligere ved å inkludere Retrieval Augmented Generation (RAG), der modellen henter lignende eksempler under prosessering. Godt utformede ledetekster som gir modellen tilstrekkelig instruksjon, kontekst, eksempler og utvidelse av gjenfinning er avgjørende for pålitelig oversettelse av naturlig språk til SQL-spørringer.

Følgende er et eksempel på en grunnlinjemelding med koderepresentasjon av databasen fra whitepaper Forbedring av få-shot tekst-til-SQL-funksjoner for store språkmodeller: En studie om raske 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 illustrert i dette eksemplet, gir promptbasert få-skuddslæring modellen en håndfull kommenterte eksempler i selve ledeteksten. Dette demonstrerer målkartleggingen mellom naturlig språk og SQL for modellen. Vanligvis vil ledeteksten inneholde rundt 2–3 par som viser et naturlig språkspørring og tilsvarende SQL-setning. Disse få eksemplene veileder modellen for å generere syntakskompatible SQL-spørringer fra naturlig språk uten å kreve omfattende opplæringsdata.

Finjustering vs. prompt engineering

Når vi bygger naturlig språk til SQL-systemer, kommer vi ofte inn i diskusjonen om finjustering av modellen er riktig teknikk eller om effektiv prompt engineering er veien å gå. Begge tilnærmingene kan vurderes og velges basert på det riktige settet med krav:

• • Finjustering – Grunnlinjemodellen er forhåndstrent på et stort generelt tekstkorpus og kan deretter brukes instruksjonsbasert finjustering, som bruker merkede eksempler for å forbedre ytelsen til en forhåndsopplært grunnmodell på tekst-SQL. Dette tilpasser modellen til måloppgaven. Finjustering trener modellen direkte på sluttoppgaven, men krever mange tekst-SQL-eksempler. Du kan bruke overvåket finjustering basert på din LLM for å forbedre effektiviteten til tekst-til-SQL. For dette kan du bruke flere datasett som Spider, WikiSQL, JAGE, BIRD-SQLeller CoSQL.
  • Rask prosjektering – Modellen er opplært til å fullføre meldinger designet for å spørre mål-SQL-syntaksen. Når du genererer SQL fra naturlig språk ved hjelp av LLM-er, er det viktig å gi klare instruksjoner i ledeteksten for å kontrollere modellens utdata. I ledeteksten for å kommentere forskjellige komponenter som å peke på kolonner, skjema og instruer deretter hvilken type SQL du skal lage. Disse fungerer som instruksjoner som forteller modellen hvordan SQL-utdata skal formateres. Følgende ledetekst viser et eksempel der du peker på tabellkolonner og instruerer å opprette en MySQL-spørring:

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 tilnærming for tekst-til-SQL-modeller er å først starte med en baseline LLM uten noen oppgavespesifikk finjustering. Godt utformede ledetekster kan deretter brukes til å tilpasse og drive basismodellen til å håndtere tekst-til-SQL-kartlegging. Denne raske konstruksjonen lar deg utvikle evnen uten å måtte finjustere. Hvis prompt engineering på basismodellen ikke oppnår tilstrekkelig nøyaktighet, kan finjustering på et lite sett med tekst-SQL-eksempler utforskes sammen med ytterligere prompt engineering.

Kombinasjonen av finjustering og prompt engineering kan være nødvendig hvis rask engineering på den rå forhåndstrente modellen alene ikke oppfyller kravene. Det er imidlertid best å i utgangspunktet forsøke prompt engineering uten finjustering, fordi dette tillater rask iterasjon uten datainnsamling. Hvis dette ikke gir tilstrekkelig ytelse, er finjustering sammen med rask utvikling et levedyktig neste skritt. Denne overordnede tilnærmingen maksimerer effektiviteten samtidig som den tillater tilpasning hvis rent promptbaserte metoder er utilstrekkelige.

Optimalisering og beste praksis

Optimalisering og beste praksis er avgjørende for å øke effektiviteten og sikre at ressursene brukes optimalt og de riktige resultatene oppnås på best mulig måte. Teknikkene hjelper til med å forbedre ytelsen, kontrollere kostnader og oppnå et resultat av bedre kvalitet.

Når du utvikler tekst-til-SQL-systemer ved hjelp av LLM-er, kan optimaliseringsteknikker forbedre ytelsen og effektiviteten. Følgende er noen viktige områder å vurdere:

• caching – For å forbedre latens, kostnadskontroll og standardisering, kan du hurtigbufre den analyserte SQL-en og gjenkjente spørringsmeldingene fra tekst-til-SQL LLM. Dette unngår å behandle gjentatte spørringer på nytt.
• Overvåking – Logger og beregninger rundt spørringsanalyse, promptgjenkjenning, SQL-generering og SQL-resultater bør samles inn for å overvåke tekst-til-SQL LLM-systemet. Dette gir synlighet for optimaliseringseksemplet ved å oppdatere ledeteksten eller gå tilbake til finjusteringen med et oppdatert datasett.
• Materialiserte visninger vs. tabeller – Materialiserte visninger kan forenkle SQL-generering og forbedre ytelsen for vanlige tekst-til-SQL-spørringer. Å spørre tabeller direkte kan resultere i kompleks SQL og også føre til ytelsesproblemer, inkludert konstant oppretting av ytelsesteknikker som indekser. I tillegg kan du unngå ytelsesproblemer når samme tabell brukes til andre bruksområder samtidig.
• Oppdaterer data – Materialiserte visninger må oppdateres etter en tidsplan for å holde data oppdatert for tekst-til-SQL-spørringer. Du kan bruke batch- eller inkrementelle oppdateringsmetoder for å balansere overhead.
• Sentral datakatalog – Å lage en sentralisert datakatalog gir en enkelt glassrute til en organisasjons datakilder og vil hjelpe LLM-er å velge passende tabeller og skjemaer for å gi mer nøyaktige svar. Vektor embeddinger opprettet fra en sentral datakatalog kan leveres til en LLM sammen med informasjon som kreves for å generere relevante og presise SQL-svar.

Ved å bruke beste praksiser for optimalisering som hurtigbufring, overvåking, materialiserte visninger, planlagt oppdatering og en sentral katalog, kan du forbedre ytelsen og effektiviteten til tekst-til-SQL-systemer som bruker LLM-er betydelig.

Arkitektur mønstre

La oss se på noen arkitekturmønstre som kan implementeres for en tekst til SQL arbeidsflyt.

Rask prosjektering

Følgende diagram illustrerer arkitekturen for å generere spørringer med en LLM ved bruk av prompt engineering.

I dette mønsteret oppretter brukeren promptbasert få-skuddslæring som gir modellen kommenterte eksempler i selve ledeteksten, som inkluderer tabell- og skjemadetaljene og noen eksempelspørringer med resultatene. LLM bruker den oppgitte ledeteksten for å returnere den AI-genererte SQL-en, som valideres og deretter kjøres mot databasen for å få resultatene. Dette er det enkleste mønsteret for å komme i gang med prompt engineering. For dette kan du bruke Amazonas grunnfjell or grunnmodeller in Amazon SageMaker JumpStart.

I dette mønsteret oppretter brukeren en promptbasert læring som gir modellen kommenterte eksempler i selve ledeteksten, som inkluderer tabell- og skjemadetaljer og noen eksempelspørringer med resultatene. LLM bruker den oppgitte ledeteksten for å returnere den AI-genererte SQL-en som er validert og kjørt mot databasen for å få resultatene. Dette er det enkleste mønsteret for å komme i gang med prompt engineering. For dette kan du bruke Amazonas grunnfjell som er en fullt administrert tjeneste som tilbyr et utvalg av høyytende grunnmodeller (FM-er) fra ledende AI-selskaper via et enkelt API, sammen med et bredt sett med muligheter du trenger for å bygge generative AI-applikasjoner med sikkerhet, personvern og ansvarlig AI eller JumpStart Foundation-modeller som tilbyr toppmoderne grunnmodeller for brukstilfeller som innholdsskriving, kodegenerering, svar på spørsmål, copywriting, oppsummering, klassifisering, informasjonsinnhenting og mer

Rask prosjektering og finjustering

Følgende diagram illustrerer arkitekturen for å generere spørringer med en LLM ved bruk av prompt engineering og finjustering.

Denne flyten ligner det forrige mønsteret, som for det meste er avhengig av prompt engineering, men med en ekstra flyt av finjustering på det domenespesifikke datasettet. Den finjusterte LLM brukes til å generere SQL-spørringene med minimal verdi i konteksten for ledeteksten. For dette kan du bruke SageMaker JumpStart til å finjustere en LLM på et domenespesifikt datasett på samme måte som du vil trene og distribuere en hvilken som helst modell på Amazon SageMaker.

Rask prosjektering og RAG

Følgende diagram illustrerer arkitekturen for å generere spørringer med en LLM ved bruk av prompt engineering og RAG.

I dette mønsteret bruker vi Retrieval Augmented Generation ved hjelp av vektorinnbyggingsbutikker, som Amazon Titan-innbygginger or Cohere Embed, På Amazonas grunnfjell fra en sentral datakatalog, som AWS Lim Datakatalog, av databaser i en organisasjon. Vektorinnbyggingene er lagret i vektordatabaser som Vector Engine for Amazon OpenSearch Serverless, Amazon Relational Database Service (Amazon RDS) for PostgreSQL med pgvektor utvidelse, eller Amazon Kendra. LLM-er bruker vektorinnbyggingene til å velge riktig database, tabeller og kolonner fra tabeller raskere når de oppretter SQL-spørringer. Å bruke RAG er nyttig når data og relevant informasjon som må hentes av LLM-er lagres i flere separate databasesystemer og LLM-en må kunne søke etter eller spørre etter data fra alle disse forskjellige systemene. Det er her det å gi vektorinnbygging av en sentralisert eller enhetlig datakatalog til LLM-ene resulterer i mer nøyaktig og omfattende informasjon returnert av LLM-ene.

konklusjonen

I dette innlegget diskuterte vi hvordan vi kan generere verdi fra bedriftsdata ved å bruke naturlig språk til SQL-generering. Vi så på nøkkelkomponenter, optimalisering og beste praksis. Vi lærte også arkitekturmønstre fra grunnleggende prompt engineering til finjustering og RAG. For å lære mer, se Amazonas grunnfjell for enkelt å bygge og skalere generative AI-applikasjoner med grunnlagsmodeller

Om forfatterne

Randy DeFauw er Senior Principal Solutions Architect hos AWS. Han har en MSEE fra University of Michigan, hvor han jobbet med datasyn for autonome kjøretøy. Han har også en MBA fra Colorado State University. Randy har hatt en rekke stillinger innen teknologiområdet, alt fra programvareutvikling til produktadministrasjon. In gikk inn i Big Data-området i 2013 og fortsetter å utforske det området. Han jobber aktivt med prosjekter i ML-området og har presentert på en rekke konferanser inkludert Strata og GlueCon.

Nitin Eusebius er senior Enterprise Solutions Architect ved AWS, erfaren innen programvareteknikk, Enterprise Architecture og AI/ML. Han er dypt lidenskapelig opptatt av å utforske mulighetene til generativ AI. Han samarbeider med kunder for å hjelpe dem med å bygge godt utformede applikasjoner på AWS-plattformen, og er dedikert til å løse teknologiutfordringer og bistå med deres skyreise.

Arghya Banerjee er Sr. Solutions Architect ved AWS i San Francisco Bay-området med fokus på å hjelpe kunder med å ta i bruk og bruke AWS Cloud. Arghya er fokusert på Big Data, Data Lakes, Streaming, Batch Analytics og AI/ML tjenester og teknologier.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• kilde: https://aws.amazon.com/blogs/machine-learning/generating-value-from-enterprise-data-best-practices-for-text2sql-and-generative-ai/