Oprettelse af en informationskant med samtaleadgang til data

Genudgivet af Platon

Abonnenter: 0

konversations-AI til dataanalyse

Figur 1: Repræsentation af Text2SQL-flowet

Efterhånden som vores verden bliver mere global og dynamisk, er virksomheder mere og mere afhængige af data for at træffe informerede, objektive og rettidige beslutninger. Men fra nu af er det ofte et privilegium for en håndfuld dataforskere og analytikere at frigøre det fulde potentiale af organisatoriske data. De fleste medarbejdere mestrer ikke det konventionelle datavidenskabelige værktøjssæt (SQL, Python, R osv.). For at få adgang til de ønskede data går de via et ekstra lag, hvor analytikere eller BI-teams "oversætter" prosaen i forretningsspørgsmål til datasproget. Potentialet for friktion og ineffektivitet på denne rejse er stort - for eksempel kan dataene blive leveret med forsinkelser, eller endda når spørgsmålet allerede er blevet forældet. Information kan gå tabt undervejs, når kravene ikke er nøjagtigt oversat til analytiske forespørgsler. Desuden kræver det at generere indsigt af høj kvalitet en iterativ tilgang, som frarådes med hvert ekstra trin i løkken. På den anden side skaber disse ad hoc-interaktioner forstyrrelser for dyre datatalenter og distraherer dem fra mere strategisk dataarbejde, som beskrevet i disse "tilståelser" fra en dataforsker:

Da jeg var på Square, og holdet var mindre, havde vi en frygtet "analytics on call"-rotation. Det blev strengt roteret på en ugentlig basis, og hvis det var din tur op, vidste du, at du ville få meget lidt "rigtigt" arbejde udført den uge og bruge det meste af din tid på at stille ad hoc spørgsmål fra de forskellige produkt- og driftsteams på virksomhed (SQL monkeying, kaldte vi det). Der var hård konkurrence om lederroller på analytics-teamet, og jeg tror, at dette udelukkende var resultatet af, at ledere blev undtaget fra denne rotation – ingen statuspræmie kunne måle sig med guleroden ved ikke at udføre vagtarbejde.[1]

Ja, ville det ikke være fedt at tale direkte til dine data i stedet for at skulle igennem flere omgange med interaktion med dit datapersonale? Denne vision er omfavnet af samtalegrænseflader, som tillader mennesker at interagere med data ved hjælp af sprog, vores mest intuitive og universelle kommunikationskanal. Efter at have parset et spørgsmål, koder en algoritme det til en struktureret logisk form i det valgte forespørgselssprog, såsom SQL. Dermed kan ikke-tekniske brugere chatte med deres data og hurtigt få fingrene i specifik, relevant og rettidig information, uden at tage omvejen via et BI-team. I denne artikel vil vi overveje de forskellige implementeringsaspekter af Text2SQL og fokusere på moderne tilgange med brug af store sprogmodeller (LLM'er), som opnår den bedste ydeevne lige nu (jf. [2]; for en undersøgelse over alternative tilgange ud over LLM'er henvises der til læsere [3]). Artiklen er struktureret i henhold til følgende "mentale model" af de vigtigste elementer, der skal overvejes, når du planlægger og bygger en AI-funktion:

konversations-AI til dataanalyse — Figur 2: Mental model af en AI-funktion

Lad os starte med slutningen i tankerne og opsummere værdien - hvorfor du ville bygge en Text2SQL-funktion ind i dit data- eller analyseprodukt. De tre hovedfordele er:

Forretningsbrugere kan få adgang til organisatoriske data på en direkte og rettidig måde.
Dette lindrer data scientists og analytikere fra byrden af ad hoc-anmodninger fra erhvervsbrugere og giver dem mulighed for at fokusere på avancerede dataudfordringer.
Dette tillader virksomhed at udnytte sine data på en mere flydende og strategisk måde, og endelig gøre dem til et solidt grundlag for beslutningstagning.

Nu, hvad er de produktscenarier, hvor du kan overveje Text2SQL? De tre hovedindstillinger er:

Du tilbyder en skalerbare data/BI-produkt og ønsker at gøre det muligt for flere brugere at få adgang til deres data på en ikke-teknisk måde og dermed øge både brugen og brugerbasen. Som et eksempel har ServiceNow integreret dataforespørgsler i et større samtaletilbudog Atlan har for nylig annonceret dataudforskning på naturligt sprog.
Du ønsker at bygge noget i data/AI-området for at demokratisere dataadgang i virksomheder, i hvilket tilfælde du potentielt kunne overveje en MVP med Text2SQL i kernen. Udbydere kan lide AI2SQL , Text2sql.ai gør allerede en entré i dette rum.
Du arbejder på en tilpasset BI-system og ønsker at maksimere og demokratisere dens anvendelse i den enkelte virksomhed.

Som vi vil se i de følgende afsnit, kræver Text2SQL en ikke-triviel forhåndsopsætning. For at estimere ROI skal du overveje arten af de beslutninger, der skal understøttes, samt på de tilgængelige data. Text2SQL kan være en absolut gevinst i dynamiske miljøer, hvor data ændrer sig hurtigt og bruges aktivt og hyppigt i beslutningstagning, såsom investering, marketing, fremstilling og energiindustrien. I disse miljøer er traditionelle værktøjer til videnstyring for statiske, og mere flydende måder at få adgang til data og information på hjælper virksomheder med at skabe en konkurrencefordel. Med hensyn til data, giver Text2SQL den største værdi med en database, der er:

Stor og voksende, så Text2SQL kan udfolde sin værdi over tid, efterhånden som mere og mere af dataene bliver udnyttet.
Høj kvalitet, så Text2SQL-algoritmen ikke skal håndtere overdreven støj (inkonsistens, tomme værdier osv.) i dataene. Generelt har data, der automatisk genereres af applikationer, en højere kvalitet og konsistens end data, der er skabt og vedligeholdt af mennesker.
Semantisk moden i modsætning til rå, så mennesker kan forespørge dataene baseret på centrale begreber, relationer og målinger, der findes i deres mentale model. Bemærk, at semantisk modenhed kan opnås ved et ekstra transformationstrin, som tilpasser rådata til en konceptuel struktur (jf. afsnittet "Berigelse af prompten med databaseinformation").

I det følgende vil vi dykke dybt ned i data, algoritme, brugeroplevelse samt de relevante ikke-funktionelle krav til en Text2SQL-funktion. Artiklen er skrevet til produktchefer, UX-designere og de dataforskere og ingeniører, der er i begyndelsen af deres Text2SQL-rejse. For disse mennesker giver det ikke kun en guide til at komme i gang, men også et fælles grundlag for viden for diskussioner omkring grænsefladerne mellem produkt, teknologi og forretning, inklusive de relaterede afvejninger. Hvis du allerede er mere avanceret i din implementering, giver referencerne i slutningen en række dybe dyk at udforske.

Hvis dette dybdegående undervisningsindhold er nyttigt for dig, kan du abonner på vores AI-forskningsmailingliste for at blive advaret, når vi udgiver nyt materiale.

1. Data

Enhver bestræbelse på maskinlæring starter med data, så vi vil starte med at afklare strukturen af input- og måldata, der bruges under træning og forudsigelse. Igennem artiklen vil vi bruge Text2SQL-flowet fra figur 1 som vores løbende repræsentation og fremhæve de aktuelt betragtede komponenter og relationer med gult.

1.1 Dataformat og struktur

Typisk består et rå Text2SQL input-output-par af et naturligt sprogspørgsmål og den tilsvarende SQL-forespørgsel, for eksempel:

Spørgsmål: "Angiv navn og antal følgere for hver bruger."

SQL forespørgsel:

vælg navn, følgere fra brugerprofiler

I træningsdatarummet er kortlægningen mellem spørgsmål og SQL-forespørgsler mange-til-mange:

En SQL-forespørgsel kan tilknyttes mange forskellige spørgsmål i naturligt sprog; for eksempel kan ovenstående forespørgselssemantik udtrykkes ved: "vis mig navnene og antallet af følgere pr. bruger","hvor mange følgere er der for hver bruger?" etc.
SQL-syntaks er meget alsidig, og næsten alle spørgsmål kan repræsenteres i SQL på flere måder. Det enkleste eksempel er forskellige rækkefølger af WHERE-sætninger. På en mere avanceret holdning vil alle, der har udført SQL-forespørgselsoptimering, vide, at mange veje fører til det samme resultat, og semantisk ækvivalente forespørgsler kan have en helt anden syntaks.

Den manuelle indsamling af træningsdata til Text2SQL er særlig kedelig. Det kræver ikke kun SQL-beherskelse fra annotatorens side, men også mere tid pr. eksempel end mere generelle sproglige opgaver såsom sentimentanalyse og tekstklassificering. For at sikre en tilstrækkelig mængde træningseksempler kan dataforøgelse bruges - for eksempel kan LLM'er bruges til at generere parafraser for det samme spørgsmål. [3] giver en mere komplet undersøgelse af Text2SQL-dataforøgelsesteknikker.

1.2 Berigelse af prompten med databaseoplysninger

Text2SQL er en algoritme i grænsefladen mellem ustrukturerede og strukturerede data. For optimal ydeevne skal begge typer data være til stede under træning og forudsigelse. Konkret skal algoritmen kende til den forespurgte database og være i stand til at formulere forespørgslen på en sådan måde, at den kan udføres mod databasen. Denne viden kan omfatte:

Kolonner og tabeller i databasen
Relationer mellem tabeller (fremmednøgler)
Database indhold

Der er to muligheder for at inkorporere databaseviden: På den ene side kan træningsdataene begrænses til eksempler skrevet til den specifikke database, i hvilket tilfælde skemaet læres direkte fra SQL-forespørgslen og dens tilknytning til spørgsmålet. Denne enkeltdatabaseindstilling gør det muligt at optimere algoritmen for en individuel database og/eller virksomhed. Det dræber dog enhver ambition om skalerbarhed, da modellen skal finjusteres til hver enkelt kunde eller database. Alternativt kan databaseskemaet i en multidatabaseindstilling leveres som en del af inputtet, hvilket gør det muligt for algoritmen at "generalisere" til nye, usete databaseskemaer. Selvom du absolut bliver nødt til at gå efter denne tilgang, hvis du vil bruge Text2SQL på mange forskellige databaser, skal du huske på, at det kræver en betydelig hurtig ingeniørindsats. For enhver rimelig virksomhedsdatabase vil inklusive den fulde information i prompten være ekstremt ineffektiv og højst sandsynligt umulig på grund af promptlængdebegrænsninger. Den funktion, der er ansvarlig for hurtig formulering, bør således være smart nok til at vælge en delmængde af databaseinformation, som er mest "nyttig" for et givet spørgsmål, og til at gøre dette for potentielt usete databaser.

Endelig spiller databasestrukturen en afgørende rolle. I de scenarier, hvor du har tilstrækkelig kontrol over databasen, kan du gøre din models liv lettere ved at lade den lære af en intuitiv struktur. Som en tommelfingerregel gælder det, at jo mere din database afspejler, hvordan forretningsbrugere taler om virksomheden, jo bedre og hurtigere kan din model lære af det. Overvej derfor at anvende yderligere transformationer til dataene, såsom at samle normaliserede eller på anden måde spredte data til brede tabeller eller en databoks, navngivning af tabeller og kolonner på en eksplicit og utvetydig måde osv. Al forretningsviden, som du kan kode på forhånd, vil reducere byrden af probabilistisk læring på din model og hjælpe dig med at opnå bedre resultater.

2. Algoritme

Text2SQL er en type semantisk parsing — kortlægning af tekster til logiske repræsentationer. Algoritmen skal således ikke kun "lære" naturligt sprog, men også målrepræsentationen - i vores tilfælde SQL. Specifikt skal det erhverve og følgende viden:

SQL-syntaks og semantik
Databasestruktur
Naturlig sprogforståelse (NLU)
Kortlægning mellem naturligt sprog og SQL-forespørgsler (syntaktisk, leksikalsk og semantisk)

2.1 Løsning af sproglig variabilitet i inputtet

Ved input ligger hovedudfordringen ved Text2SQL i sprogets fleksibilitet: som beskrevet i afsnittet Dataformat og struktur kan det samme spørgsmål omskrives på mange forskellige måder. Derudover er vi i den virkelige samtalekontekst nødt til at håndtere en række spørgsmål såsom stave- og grammatikfejl, ufuldstændige og tvetydige input, flersprogede input osv.

LLM'er såsom GPT-modellerne, T5 og CodeX kommer tættere og tættere på at løse denne udfordring. Ved at lære af enorme mængder forskelligartet tekst lærer de at håndtere en lang række sproglige mønstre og uregelmæssigheder. I sidste ende bliver de i stand til at generalisere over spørgsmål, som er semantisk ens på trods af, at de har forskellige overfladeformer. LLM'er kan anvendes ud af boksen (nul-skud) eller efter finjustering. Førstnævnte fører, selvom det er praktisk, til lavere nøjagtighed. Sidstnævnte kræver mere dygtighed og arbejde, men kan øge nøjagtigheden betydeligt.

Med hensyn til nøjagtighed, som forventet, er de bedst ydende modeller de nyeste modeller af GPT-familien inklusive CodeX-modellerne. I april 2023 førte GPT-4 til en dramatisk stigning i nøjagtigheden på mere end 5 % i forhold til den tidligere state-of-the-art og opnåede en nøjagtighed på 85.3 % (på den metriske "udførelse med værdier").[4] I open source-lejren var de første forsøg på at løse Text2SQL-puslespillet fokuseret på auto-encoding-modeller såsom BERT, som udmærker sig ved NLU-opgaver.[5, 6, 7] Men midt i hypen omkring generativ AI, fokuserer de seneste tilgange på autoregressive modeller som T5-modellen. T5 er fortrænet ved hjælp af multi-task learning og tilpasser sig dermed nemt nye sproglige opgaver, inkl. forskellige varianter af semantisk parsing. Autoregressive modeller har dog en iboende fejl, når det kommer til semantiske parsingsopgaver: de har et ubegrænset outputrum og ingen semantiske autoværn, der ville begrænse deres output, hvilket betyder, at de kan blive forbløffende kreative i deres adfærd. Selvom dette er fantastiske ting til at generere indhold i frit format, er det en gene for opgaver som Text2SQL, hvor vi forventer et begrænset, velstruktureret måloutput.

2.2 Forespørgselsvalidering og forbedring

For at begrænse LLM-outputtet kan vi introducere yderligere mekanismer til validering og forbedring af forespørgslen. Dette kan implementeres som et ekstra valideringstrin, som foreslået i PICARD-systemet.[8] PICARD bruger en SQL-parser, der kan verificere, om en delvis SQL-forespørgsel kan føre til en gyldig SQL-forespørgsel efter afslutning. Ved hvert generationstrin af LLM afvises tokens, der ville ugyldiggøre forespørgslen, og de gyldige tokens med højest sandsynlighed beholdes. Da denne tilgang er deterministisk, sikrer den 100 % SQL-gyldighed, så længe parseren overholder de korrekte SQL-regler. Det afkobler også forespørgselsvalideringen fra generationen, hvilket gør det muligt at vedligeholde begge komponenter uafhængigt af hinanden og at opgradere og ændre LLM.

En anden tilgang er at inkorporere strukturel og SQL viden direkte i LLM. For eksempel bruger Graphix [9] graf-bevidste lag til at injicere struktureret SQL-viden i T5-modellen. På grund af den probabilistiske karakter af denne tilgang, skævvrider den systemet mod korrekte forespørgsler, men giver ikke en garanti for succes.

Endelig kan LLM bruges som en multi-trin agent, der selvstændigt kan kontrollere og forbedre forespørgslen.[10] Ved at bruge flere trin i en kæde-af-tanke-prompt kan agenten få til opgave at reflektere over rigtigheden af sine egne forespørgsler og forbedre eventuelle mangler. Hvis den validerede forespørgsel stadig ikke kan udføres, kan SQL-undtagelsessporingen sendes til agenten som en yderligere feedback til forbedring.

Ud over disse automatiserede metoder, som sker i backend, er det også muligt at involvere brugeren under forespørgselskontrolprocessen. Vi vil beskrive dette mere detaljeret i afsnittet om Brugeroplevelse.

2.3 Evaluering

For at evaluere vores Text2SQL-algoritme skal vi generere et test-(validerings-) datasæt, køre vores algoritme på det og anvende relevante evalueringsmetrikker på resultatet. Et naivt datasæt opdelt i trænings-, udviklings- og valideringsdata ville være baseret på spørgsmål-forespørgsels-par og føre til suboptimale resultater. Valideringsforespørgsler kan blive afsløret for modellen under træning og føre til et alt for optimistisk syn på dens generaliseringsevner. EN forespørgselsbaseret opdeling, hvor datasættet er opdelt på en sådan måde, at der ikke vises nogen forespørgsel både under træning og under validering, giver mere sandfærdige resultater.

Med hensyn til evalueringsmetrikker er det, vi bekymrer os om i Text2SQL, ikke at generere forespørgsler, der er fuldstændig identiske med guldstandarden. Det her "præcis streng match" metoden er for streng og vil generere mange falske negativer, da forskellige SQL-forespørgsler kan føre til det samme returnerede datasæt. I stedet ønsker vi at opnå høj semantisk nøjagtighed og evaluere, om de forudsagte og "guldstandard"-forespørgsler altid ville returnere de samme datasæt. Der er tre evalueringsmetrics, der tilnærmer dette mål:

Præcis indstillet matchnøjagtighed: de genererede og mål-SQL-forespørgsler opdeles i deres bestanddele, og de resulterende sæt sammenlignes for identitet.[11] Manglen her er, at den kun tager højde for rækkefølgevariationer i SQL-forespørgslen, men ikke for mere udtalte syntaktiske forskelle mellem semantisk ækvivalente forespørgsler.
Udførelsesnøjagtighed: datasættene, der stammer fra de genererede og mål-SQL-forespørgsler, sammenlignes for identitet. Med held og lykke kan forespørgsler med forskellig semantik stadig bestå denne test på en specifik databaseinstans. For eksempel, hvis vi antager en database, hvor alle brugere er over 30 år, vil følgende to forespørgsler returnere identiske resultater på trods af at de har forskellig semantik:
vælg * fra bruger
vælg * fra bruger, hvor alder > 30 år
Test-suite nøjagtighed: test-suite nøjagtighed er en mere avanceret og mindre eftergivende version af udførelsesnøjagtighed. For hver forespørgsel genereres et sæt ("testsuite") af databaser, der er meget differentierede med hensyn til variabler, betingelser og værdier i forespørgslen. Derefter testes eksekveringsnøjagtigheden på hver af disse databaser. Selvom det kræver yderligere indsats for at konstruere testsuite-genereringen, reducerer denne metrisk også risikoen for falske positiver i evalueringen markant.[12]

3. Brugeroplevelse

Den nuværende state-of-the-art af Text2SQL tillader ikke en fuldstændig problemfri integration i produktionssystemer - i stedet er det nødvendigt aktivt at styre forventningerne og adfærden hos brugeren, som altid skal være opmærksom på, at hun interagerer med et AI-system.

3.1 Fejlhåndtering

Text2SQL kan fejle i to tilstande, som skal fanges på forskellige måder:

SQL fejl: den genererede forespørgsel er ikke gyldig - enten er SQL'en ugyldig, eller også kan den ikke udføres mod den specifikke database på grund af leksikalske eller semantiske fejl. I dette tilfælde kan intet resultat returneres til brugeren.
Semantiske fejl: den genererede forespørgsel er gyldig, men den afspejler ikke spørgsmålets semantik, hvilket fører til et forkert returneret datasæt.

Den anden tilstand er særlig vanskelig, da risikoen for "tavse fejl" - fejl, der ikke bliver opdaget af brugeren - er høj. Den prototypiske bruger har hverken tid eller tekniske færdigheder til at verificere rigtigheden af forespørgslen og/eller de resulterende data. Når data bruges til beslutningstagning i den virkelige verden, kan denne form for fejl have ødelæggende konsekvenser. For at undgå dette er det afgørende at uddanne brugerne og etablere sig autoværn på erhvervsniveau som begrænser den potentielle påvirkning, såsom yderligere datatjek for beslutninger med større effekt. På den anden side kan vi også bruge brugergrænsefladen til at styre menneske-maskine-interaktionen og hjælpe brugeren med at opdage og forbedre problematiske anmodninger.

3.2 Menneske-maskine interaktion

Brugere kan blive involveret i dit AI-system med forskellige grader af intensitet. Mere interaktion pr. anmodning kan føre til bedre resultater, men det forsinker også brugeroplevelsen. Udover den potentielle negative effekt af fejlagtige forespørgsler og resultater, skal du også overveje, hvor motiverede dine brugere vil være til at give tilbage-og-tilbage-feedback for at få mere præcise resultater og også hjælpe med at forbedre produktet på lang sigt.

Den nemmeste og mindst engagerende måde er at arbejde med selvtillidsscore. Mens den naive beregning af tillid som et gennemsnit af sandsynligheden for de genererede tokens er alt for forenklet, kan mere avancerede metoder som verbaliseret feedback bruges. [13] Tilliden kan vises i grænsefladen og fremhæves med en eksplicit advarsel, hvis den er farligt lav. På denne måde lander ansvaret for en passende opfølgning i den "virkelige verden" - det være sig en afvisning, accept eller en ekstra kontrol af dataene - på din brugers skuldre. Selvom dette er et sikkert bud for dig som leverandør, kan overførsel af dette arbejde til brugeren også reducere værdien af dit produkt.

En anden mulighed er at engagere brugeren i en afklaringsdialog i tilfælde af lav tillid, tvetydige eller på anden måde mistænkelige forespørgsler. For eksempel kan dit system foreslå ortografiske eller grammatiske rettelser til input og bede om at tvetydige specifikke ord eller grammatiske strukturer. Det kan også give brugeren mulighed for proaktivt at bede om rettelser i forespørgslen:[14]

BRUGER: Vis mig Johns opgaver i denne sprint.

ASSISTENT: Kunne du tænke dig at se opgaver John har lavet, eller dem han arbejder på?

BRUGER: opgaver John lavede

ASSISTENT: Ok, her er opgave-id'erne:

BRUGER: Tak, jeg vil også gerne se mere information om opgaverne. Sorter venligst også efter hastende karakter.

ASSISTENT: Ja, her er opgaverne sammen med korte beskrivelser, medarbejdere og deadlines, sorteret efter deadline.

Endelig, for at lette forståelsen af forespørgsler for brugeren, kan dit system også give en eksplicit tekstlig omformulering af forespørgslen og bede brugeren om enten at bekræfte eller rette den.[15]

4. Ikke-funktionelle krav

I dette afsnit diskuterer vi de specifikke ikke-funktionelle krav til Text2SQL samt afvejningen mellem dem. Vi vil fokusere på de seks krav, der synes vigtigst for opgaven: nøjagtighed, skalerbarhed, hastighed, forklarlighed, privatliv og tilpasningsevne over tid.

4.1 Nøjagtighed

For Text2SQL er kravene til nøjagtighed høje. For det første anvendes Text2SQL typisk i en samtaleindstilling, hvor forudsigelser laves én efter én. Derfor hjælper "Loven om store tal", som typisk hjælper med at afbalancere fejlen i batchede forudsigelser, ikke. For det andet er syntaktisk og leksikalsk validitet en "hård" betingelse: Modellen skal generere en velformet SQL-forespørgsel, potentielt med kompleks syntaks og semantik, ellers kan anmodningen ikke udføres mod databasen. Og hvis dette går godt, og forespørgslen kan udføres, kan den stadig indeholde semantiske fejl og føre til et forkert returneret datasæt (jf. afsnit 3.1 Fejlhåndtering).

4.2 Skalerbarhed

De vigtigste skalerbarhedsovervejelser er, om du vil anvende Text2SQL på en eller flere databaser - og i sidstnævnte tilfælde, om sættet af databaser er kendt og lukket. Hvis ja, vil du have lettere ved, da du kan inkludere oplysningerne om disse databaser under træningen. Men i et scenarie med et skalerbart produkt - hvad enten det er en selvstændig Text2SQL-applikation eller en integration i et eksisterende dataprodukt - skal din algoritme klare ethvert nyt databaseskema på farten. Dette scenarie giver dig heller ikke mulighed for at transformere databasestrukturen for at gøre den mere intuitiv til læring (link!). Alt dette fører til en tung afvejning med nøjagtighed, hvilket også kan forklare, hvorfor nuværende Text2SQL-udbydere, der tilbyder ad-hoc-forespørgsler til nye databaser, endnu ikke har opnået en væsentlig markedspenetration.

4.3 Speed

Da Text2SQL-anmodninger typisk vil blive behandlet online i en samtale, er hastighedsaspektet vigtigt for brugernes tilfredshed. På den positive side er brugerne ofte opmærksomme på, at dataforespørgsler kan tage en vis tid og vise den nødvendige tålmodighed. Denne goodwill kan dog undermineres af chat-indstillingen, hvor brugere ubevidst forventer menneskelignende samtalehastighed. Brute-force optimeringsmetoder som at reducere størrelsen af modellen kan have en uacceptabel indvirkning på nøjagtigheden, så overvej inferensoptimering for at opfylde denne forventning.

4.4 Forklarlighed og gennemsigtighed

I det ideelle tilfælde kan brugeren følge med i, hvordan forespørgslen blev genereret ud fra teksten, se kortlægningen mellem specifikke ord eller udtryk i spørgsmålet og SQL-forespørgslen osv. Dette giver mulighed for at verificere forespørgslen og foretage eventuelle justeringer, når de interagerer med systemet . Desuden kunne systemet også give en eksplicit tekstlig omformulering af forespørgslen og bede brugeren om enten at bekræfte eller rette den.

4.5 Privatliv

Text2SQL-funktionen kan isoleres fra udførelse af forespørgsler, så den returnerede databaseinformation kan holdes usynlig. Det kritiske spørgsmål er dog, hvor meget information om databasen, der er inkluderet i prompten. De tre muligheder (ved at sænke privatlivsniveauet) er:

Ingen oplysninger
Databaseskema
Database indhold

Privatliv afvejer med nøjagtighed - jo mindre begrænset du er i at inkludere nyttige oplysninger i prompten, jo bedre resultater.

4.6 Tilpasningsevne over tid

For at bruge Text2SQL på en holdbar måde, skal du tilpasse dig datadrift, altså den skiftende fordeling af de data, som modellen anvendes på. Lad os f.eks. antage, at de data, der bruges til indledende finjustering, afspejler brugernes simple forespørgselsadfærd, når de begynder at bruge BI-systemet. Som tiden går, bliver brugernes informationsbehov mere sofistikerede og kræver mere komplekse forespørgsler, som overvælder din naive model. Desuden kan målene eller strategien for en virksomhedsændring også drive og rette informationsbehovet mod andre områder af databasen. Endelig er en Text2SQL-specifik udfordring databasedrift. Efterhånden som virksomhedens database udvides, kommer nye, usete kolonner og tabeller ind i prompten. Selvom Text2SQL-algoritmer, der er designet til multi-database-applikation, kan håndtere dette problem godt, kan det påvirke nøjagtigheden af en enkelt-databasemodel betydeligt. Alle disse problemer løses bedst med et finjusterende datasæt, der afspejler brugernes aktuelle adfærd i den virkelige verden. Det er således afgørende at logge brugerspørgsmål og resultater, samt eventuel tilhørende feedback, der kan indsamles fra brugen. Derudover kan semantiske klyngealgoritmer, for eksempel ved hjælp af indlejringer eller emnemodellering, anvendes til at detektere underliggende langsigtede ændringer i brugeradfærd og bruge disse som en ekstra kilde til information til at perfektionere dit finjusteringsdatasæt

Konklusion

Lad os opsummere hovedpunkterne i artiklen:

Text2SQL giver mulighed for at implementere intuitiv og demokratisk dataadgang i en virksomhed og dermed maksimere værdien af de tilgængelige data.
Text2SQL-data består af spørgsmål ved input og SQL-forespørgsler ved output. Kortlægningen mellem spørgsmål og SQL-forespørgsler er mange-til-mange.
Det er vigtigt at give oplysninger om databasen som en del af prompten. Derudover kan databasestrukturen optimeres for at gøre det nemmere for algoritmen at lære og forstå den.
Med hensyn til input er hovedudfordringen den sproglige variabilitet af naturlige sprogspørgsmål, som kan gribes an ved hjælp af LLM'er, der var forudtrænede i en lang række forskellige tekststile
Outputtet af Text2SQL skal være en gyldig SQL-forespørgsel. Denne begrænsning kan inkorporeres ved at "injicere" SQL-viden i algoritmen; alternativt kan forespørgslen kontrolleres og forbedres i flere trin ved at bruge en iterativ tilgang.
På grund af den potentielt høje effekt af "tavse fejl", som returnerer forkerte data til beslutningstagning, er fejlhåndtering en primær bekymring i brugergrænsefladen.
På en "augmented" måde kan brugere være aktivt involveret i iterativ validering og forbedring af SQL-forespørgsler. Selvom dette gør applikationen mindre flydende, reducerer den også fejlfrekvensen, giver brugerne mulighed for at udforske data på en mere fleksibel måde og skaber værdifulde signaler til yderligere læring.
De vigtigste ikke-funktionelle krav, der skal tages i betragtning, er nøjagtighed, skalerbarhed, hastighed, forklarlighed, privatliv og tilpasningsevne over tid. De vigtigste afvejninger består mellem nøjagtighed på den ene side og skalerbarhed, hastighed og privatliv på den anden side.