Een informatievoorsprong creëren met conversatietoegang tot gegevens

Heruitgegeven door Plato

volgers: 0

gespreks-AI voor data-analyse

Afbeelding 1: weergave van de Text2SQL-stroom

Naarmate onze wereld globaler en dynamischer wordt, zijn bedrijven steeds afhankelijker van gegevens om weloverwogen, objectieve en tijdige beslissingen te nemen. Vanaf nu is het echter vaak een voorrecht van een handvol datawetenschappers en analisten om het volledige potentieel van organisatiedata te ontketenen. De meeste medewerkers beheersen de conventionele data science-toolkit (SQL, Python, R etc.) niet. Om toegang te krijgen tot de gewenste gegevens, gaan ze via een extra laag waar analisten of BI-teams het proza van zakelijke vragen "vertalen" naar de taal van gegevens. Het potentieel voor wrijving en inefficiëntie op deze reis is groot - de gegevens kunnen bijvoorbeeld met vertraging worden geleverd of zelfs wanneer de vraag al achterhaald is. Er kan gaandeweg informatie verloren gaan als de vereisten niet nauwkeurig worden vertaald in analytische vragen. Bovendien vereist het genereren van hoogwaardige inzichten een iteratieve aanpak die bij elke volgende stap in de lus wordt afgeraden. Aan de andere kant zorgen deze ad-hoc interacties voor verstoringen voor duur datatalent en leiden ze af van meer strategisch datawerk, zoals beschreven in deze "bekentenissen" van een datawetenschapper:

Toen ik bij Square was en het team kleiner was, hadden we een gevreesde "analytics on-call"-rotatie. Het werd strikt wekelijks gerouleerd, en als jij aan de beurt was, wist je dat je die week heel weinig 'echt' werk zou verzetten en het grootste deel van je tijd zou besteden aan het beantwoorden van ad-hocvragen van de verschillende product- en operationele teams op de afdeling. bedrijf (SQL monkeying, noemden we het). Er was moordende concurrentie voor managerfuncties in het analyseteam en ik denk dat dit volledig het gevolg was van het feit dat managers werden vrijgesteld van deze roulatie - geen enkele statusprijs kon wedijveren met het niet doen van oproepwerk.[1]

Zou het niet cool zijn om rechtstreeks met uw gegevens te praten in plaats van meerdere interactierondes met uw gegevenspersoneel te moeten doorlopen? Deze visie wordt omarmd door conversatie-interfaces waarmee mensen kunnen communiceren met gegevens door middel van taal, ons meest intuïtieve en universele communicatiekanaal. Nadat een vraag is geparseerd, codeert een algoritme deze in een gestructureerde logische vorm in de gewenste querytaal, zoals SQL. Zo kunnen niet-technische gebruikers met hun data chatten en snel specifieke, relevante en actuele informatie in handen krijgen, zonder de omweg via een BI-team te maken. In dit artikel bekijken we de verschillende implementatieaspecten van Text2SQL en richten we ons op moderne benaderingen met het gebruik van Large Language Models (LLM's), die op dit moment de beste prestaties leveren (zie [2]; voor een overzicht van alternatieve benaderingen buiten LLM's wordt verwezen naar lezers [3]). Het artikel is gestructureerd volgens het volgende "mentale model" van de belangrijkste elementen waarmee rekening moet worden gehouden bij het plannen en bouwen van een AI-functie:

gespreks-AI voor data-analyse — Figuur 2: Mentaal model van een AI-functie

Laten we beginnen met het einde in gedachten en de waarde samenvatten: waarom u een Text2SQL-functie in uw gegevens- of analyseproduct zou inbouwen. De drie belangrijkste voordelen zijn:

Zakelijke gebruikers heeft direct en tijdig toegang tot organisatiegegevens.
Dit verlicht datawetenschappers en -analisten van de last van ad-hocverzoeken van zakelijke gebruikers en stelt hen in staat zich te concentreren op geavanceerde data-uitdagingen.
Hierdoor kan de bedrijfsdeskundigen om zijn gegevens op een meer vloeiende en strategische manier te benutten en er uiteindelijk een solide basis voor besluitvorming van te maken.

Wat zijn nu de productscenario's waarin u Text2SQL zou kunnen overwegen? De drie belangrijkste instellingen zijn:

U biedt een schaalbaar data/BI-product en willen meer gebruikers toegang geven tot hun gegevens op een niet-technische manier, waardoor zowel het gebruik als het gebruikersbestand groeit. Als voorbeeld heeft ServiceNow geïntegreerde gegevensquery's in een groter gespreksaanbod en Atlan heeft recent kondigde dataverkenning in natuurlijke taal aan.
U wilt iets bouwen in de data/AI-ruimte om gegevenstoegang in bedrijven te democratiseren, in welk geval u mogelijk een MVP met Text2SQL als kern. Aanbieders zoals AI2SQL en Tekst2sql.ai doen al hun intrede in deze ruimte.
Je werkt aan een aangepast BI-systeem en het gebruik ervan in het individuele bedrijf willen maximaliseren en democratiseren.

Zoals we in de volgende secties zullen zien, vereist Text2SQL een niet-triviale setup vooraf. Om de ROI te schatten, moet u rekening houden met de aard van de beslissingen die moeten worden ondersteund en met de beschikbare gegevens. Text2SQL kan een absolute overwinning zijn in dynamische omgevingen waar gegevens snel veranderen en actief en vaak worden gebruikt bij besluitvorming, zoals investeringen, marketing, productie en de energie-industrie. In deze omgevingen zijn traditionele tools voor kennisbeheer te statisch, en vlottere manieren om toegang te krijgen tot gegevens en informatie helpen bedrijven een concurrentievoordeel te behalen. Wat de gegevens betreft, biedt Text2SQL de grootste waarde met een database die:

Groot en groeiend, zodat Text2SQL zijn waarde in de loop van de tijd kan ontvouwen naarmate meer en meer van de gegevens worden gebruikt.
Hoge kwaliteit, zodat het Text2SQL-algoritme niet te maken heeft met overmatige ruis (inconsistenties, lege waarden etc.) in de data. Over het algemeen hebben gegevens die automatisch worden gegenereerd door applicaties een hogere kwaliteit en consistentie dan gegevens die door mensen worden gemaakt en onderhouden.
Semantisch volwassen in tegenstelling tot onbewerkt, zodat mensen de gegevens kunnen opvragen op basis van centrale concepten, relaties en statistieken die in hun mentale model bestaan. Merk op dat semantische volwassenheid kan worden bereikt door een extra transformatiestap die onbewerkte gegevens conformeert aan een conceptuele structuur (zie sectie "De prompt verrijken met database-informatie").

Hierna gaan we dieper in op de gegevens, het algoritme, de gebruikerservaring en de relevante niet-functionele vereisten van een Text2SQL-functie. Het artikel is geschreven voor productmanagers, UX-ontwerpers en die datawetenschappers en ingenieurs die aan het begin staan van hun Text2SQL-reis. Voor deze mensen biedt het niet alleen een leidraad om aan de slag te gaan, maar ook een gemeenschappelijke kennisbasis voor discussies over de raakvlakken tussen product, technologie en bedrijf, inclusief de bijbehorende afwegingen. Als u al verder gevorderd bent in uw implementatie, bieden de referenties aan het einde een reeks diepe duiken om te verkennen.

Als deze diepgaande educatieve inhoud nuttig voor je is, kan dat abonneer u op onze AI-research mailinglijst om gewaarschuwd te worden wanneer we nieuw materiaal uitbrengen.

1. Gegevens

Elke machine learning-inspanning begint met gegevens, dus we beginnen met het verduidelijken van de structuur van de invoer- en doelgegevens die worden gebruikt tijdens training en voorspelling. In het hele artikel zullen we de Text2SQL-stroom uit figuur 1 gebruiken als onze lopende weergave, en de momenteel beschouwde componenten en relaties in geel markeren.

1.1 Formaat en structuur van de gegevens

Een onbewerkt Text2SQL-invoer-uitvoerpaar bestaat doorgaans uit een vraag in natuurlijke taal en de bijbehorende SQL-query, bijvoorbeeld:

Vraag"Maak een lijst van de naam en het aantal volgers voor elke gebruiker.”

SQL-query:

selecteer naam, volgers van user_profiles

In de trainingsgegevensruimte is de koppeling tussen vragen en SQL-query's veel-op-veel:

Een SQL-query kan in natuurlijke taal aan veel verschillende vragen worden toegewezen; de bovenstaande query-semantiek kan bijvoorbeeld worden uitgedrukt door: "laat me de namen en aantallen volgers per gebruiker zien","hoeveel volgers zijn er voor elke gebruiker?" enz.
SQL-syntaxis is zeer veelzijdig en bijna elke vraag kan op meerdere manieren in SQL worden weergegeven. Het eenvoudigste voorbeeld zijn verschillende volgordes van WHERE-clausules. Op een meer geavanceerd standpunt zal iedereen die SQL-query-optimalisatie heeft gedaan, weten dat veel wegen naar hetzelfde resultaat leiden en dat semantisch equivalente query's een compleet andere syntaxis kunnen hebben.

Vooral het handmatig verzamelen van trainingsgegevens voor Text2SQL is vervelend. Het vereist niet alleen SQL-beheersing van de kant van de annotator, maar ook meer tijd per voorbeeld dan meer algemene taalkundige taken zoals sentimentanalyse en tekstclassificatie. Om ervoor te zorgen dat er voldoende trainingsvoorbeelden zijn, kan gegevensaugmentatie worden gebruikt. LLM's kunnen bijvoorbeeld worden gebruikt om parafrases voor dezelfde vraag te genereren. [3] biedt een vollediger overzicht van Text2SQL-technieken voor gegevensvergroting.

1.2 De prompt verrijken met database-informatie

Text2SQL is een algoritme op het raakvlak tussen ongestructureerde en gestructureerde data. Voor optimale prestaties moeten beide soorten gegevens aanwezig zijn tijdens training en voorspelling. Concreet moet het algoritme op de hoogte zijn van de bevraagde database en in staat zijn om de query zo te formuleren dat deze kan worden uitgevoerd tegen de database. Deze kennis kan omvatten:

Kolommen en tabellen van de database
Relaties tussen tabellen (vreemde sleutels)
Database-inhoud

Er zijn twee opties om databasekennis op te nemen: aan de ene kant kunnen de trainingsgegevens worden beperkt tot voorbeelden die voor de specifieke database zijn geschreven, in welk geval het schema rechtstreeks wordt geleerd uit de SQL-query en de toewijzing ervan aan de vraag. Met deze instelling voor één database kan het algoritme voor een individuele database en/of bedrijf worden geoptimaliseerd. Het vernietigt echter alle ambities voor schaalbaarheid, aangezien het model voor elke klant of database nauwkeurig moet worden afgesteld. In een omgeving met meerdere databases kan het databaseschema ook worden geleverd als onderdeel van de invoer, waardoor het algoritme kan "generaliseren" naar nieuwe, ongeziene databaseschema's. Hoewel u absoluut voor deze aanpak moet kiezen als u Text2SQL op veel verschillende databases wilt gebruiken, moet u er rekening mee houden dat dit een aanzienlijke snelle engineering-inspanning vereist. Voor elke redelijke zakelijke database zal het opnemen van de volledige informatie in de prompt uiterst inefficiënt en hoogstwaarschijnlijk onmogelijk zijn vanwege beperkingen in de lengte van de prompt. De functie die verantwoordelijk is voor het formuleren van prompts moet dus slim genoeg zijn om een subset van database-informatie te selecteren die het meest "nuttig" is voor een bepaalde vraag, en om dit te doen voor potentieel ongeziene databases.

Ten slotte speelt de databasestructuur een cruciale rol. In die scenario's waarin u voldoende controle over de database heeft, kunt u het leven van uw model gemakkelijker maken door het te laten leren van een intuïtieve structuur. Als vuistregel geldt: hoe meer uw database weergeeft hoe zakelijke gebruikers over het bedrijf praten, hoe beter en sneller uw model ervan kan leren. Overweeg daarom aanvullende transformaties toe te passen op de gegevens, zoals het samenvoegen van genormaliseerde of anderszins verspreide gegevens in brede tabellen of een gegevenskluis, het op een expliciete en ondubbelzinnige manier benoemen van tabellen en kolommen enz. Alle zakelijke kennis die u vooraf kunt coderen, vermindert de last van probabilistisch leren op uw model en u helpen betere resultaten te behalen.

2. Algoritme

Text2SQL is een type van semantische ontleding — het in kaart brengen van teksten in logische representaties. Het algoritme moet dus niet alleen natuurlijke taal "leren", maar ook de doelrepresentatie - in ons geval SQL. Concreet moet het de volgende kennis verwerven:

SQL-syntaxis en semantiek
Databasestructuur
Natuurlijk taalbegrip (NLU)
Mapping tussen natuurlijke taal en SQL-query's (syntactisch, lexicaal en semantisch)

2.1 Oplossen van taalvariabiliteit in de invoer

Bij de invoer ligt de grootste uitdaging van Text2SQL in de flexibiliteit van taal: zoals beschreven in de sectie Formaat en structuur van de data, kan dezelfde vraag op veel verschillende manieren worden geparafraseerd. Bovendien hebben we in de echte conversatiecontext te maken met een aantal problemen, zoals spel- en grammaticafouten, onvolledige en dubbelzinnige invoer, meertalige invoer enz.

LLM's zoals de GPT-modellen, T5 en CodeX komen steeds dichter bij het oplossen van deze uitdaging. Door te leren van enorme hoeveelheden uiteenlopende teksten, leren ze omgaan met een groot aantal taalpatronen en onregelmatigheden. Uiteindelijk kunnen ze generaliseren over vragen die semantisch vergelijkbaar zijn ondanks verschillende oppervlaktevormen. LLM's kunnen out-of-the-box (zero-shot) of na fine-tuning worden toegepast. De eerste, hoewel handig, leidt tot een lagere nauwkeurigheid. Dit laatste vereist meer vaardigheid en werk, maar kan de nauwkeurigheid aanzienlijk verhogen.

In termen van nauwkeurigheid zijn, zoals verwacht, de best presterende modellen de nieuwste modellen van de GPT-familie, inclusief de CodeX-modellen. In april 2023 leidde GPT-4 tot een dramatische toename van de nauwkeurigheid van meer dan 5% ten opzichte van de vorige state-of-the-art en bereikte een nauwkeurigheid van 85.3% (op de maatstaf "uitvoering met waarden").[4] In het open-sourcekamp waren de eerste pogingen om de Text2SQL-puzzel op te lossen gericht op auto-coderingsmodellen zoals BERT, die uitblinken in NLU-taken. op autoregressieve modellen zoals het T5-model. T6 is vooraf getraind met behulp van multi-task learning en past zich dus gemakkelijk aan nieuwe taalkundige taken aan, incl. verschillende varianten van semantische parsing. Autoregressieve modellen hebben echter een intrinsieke fout als het gaat om semantische parseertaken: ze hebben een onbeperkte uitvoerruimte en geen semantische vangrails die hun uitvoer zouden beperken, wat betekent dat ze verbluffend creatief kunnen worden in hun gedrag. Hoewel dit verbazingwekkende dingen zijn voor het genereren van inhoud in vrije vorm, is het hinderlijk voor taken zoals Text7SQL, waarbij we een beperkte, goed gestructureerde doeluitvoer verwachten.

2.2 Query validatie en verbetering

Om de LLM-uitvoer te beperken, kunnen we aanvullende mechanismen introduceren voor het valideren en verbeteren van de query. Dit kan worden geïmplementeerd als een extra validatiestap, zoals voorgesteld in het PICARD-systeem.[8] PICARD gebruikt een SQL-parser die kan verifiëren of een gedeeltelijke SQL-query na voltooiing kan leiden tot een geldige SQL-query. Bij elke generatiestap door de LLM worden tokens die de query ongeldig zouden maken, afgewezen en worden de geldige tokens met de hoogste waarschijnlijkheid behouden. Deze benadering is deterministisch en garandeert 100% SQL-validiteit zolang de parser de juiste SQL-regels in acht neemt. Het ontkoppelt ook de queryvalidatie van het genereren, waardoor beide componenten onafhankelijk van elkaar kunnen worden onderhouden en de LLM kan worden geüpgraded en gewijzigd.

Een andere benadering is om structurele en SQL-kennis rechtstreeks in de LLM op te nemen. Graphix [9] gebruikt bijvoorbeeld graph-aware layers om gestructureerde SQL-kennis in het T5-model te injecteren. Vanwege de probabilistische aard van deze benadering, neigt het systeem naar correcte zoekopdrachten, maar biedt het geen garantie voor succes.

Ten slotte kan de LLM worden gebruikt als een meerstapsagent die de zoekopdracht autonoom kan controleren en verbeteren.[10] Met behulp van meerdere stappen in een gedachtegangprompt, kan de agent de opdracht krijgen om na te denken over de juistheid van zijn eigen vragen en eventuele gebreken te verbeteren. Als de gevalideerde query nog steeds niet kan worden uitgevoerd, kan de SQL-uitzonderingstraceback worden doorgegeven aan de agent als aanvullende feedback voor verbetering.

Naast deze geautomatiseerde methoden die in de backend plaatsvinden, is het ook mogelijk om de gebruiker te betrekken bij het querycontroleproces. We zullen dit in meer detail beschrijven in het gedeelte over gebruikerservaring.

2.3 Evaluatie

Om ons Text2SQL-algoritme te evalueren, moeten we een test (validatie) dataset genereren, ons algoritme daarop uitvoeren en relevante evaluatiestatistieken toepassen op het resultaat. Een naïeve dataset opgesplitst in trainings-, ontwikkelings- en validatiegegevens zou gebaseerd zijn op vraag-query-paren en zou leiden tot suboptimale resultaten. Validatievragen kunnen tijdens de training aan het model worden onthuld en leiden tot een te optimistische kijk op de generalisatievaardigheden. A op query's gebaseerde splitsing, waarbij de dataset zo is opgesplitst dat er geen query verschijnt, zowel tijdens de training als tijdens de validatie, levert meer waarheidsgetrouwe resultaten op.

In termen van evaluatiestatistieken, waar we in Text2SQL om geven, is niet het genereren van zoekopdrachten die volledig identiek zijn aan de gouden standaard. Dit "exacte tekenreeks komt overeen" methode is te strikt en zal veel fout-negatieven genereren, aangezien verschillende SQL-query's tot dezelfde geretourneerde dataset kunnen leiden. In plaats daarvan willen we hoog scoren semantische nauwkeurigheid en evalueren of de voorspelde en de 'gouden standaard'-query's altijd dezelfde datasets zouden opleveren. Er zijn drie evaluatiestatistieken die dit doel benaderen:

Exact ingestelde overeenkomstnauwkeurigheid: de gegenereerde en doel-SQL-query's worden opgesplitst in hun bestanddelen en de resulterende sets worden vergeleken op identiteit.[11] De tekortkoming hier is dat het alleen rekening houdt met volgordevariaties in de SQL-query, maar niet met meer uitgesproken syntactische verschillen tussen semantisch equivalente query's.
Nauwkeurigheid van uitvoering: de datasets die het resultaat zijn van de gegenereerde en doel-SQL-query's worden vergeleken op identiteit. Met een beetje geluk kunnen query's met verschillende semantiek deze test nog steeds doorstaan op een specifieke database-instantie. Als we bijvoorbeeld uitgaan van een database waarin alle gebruikers ouder zijn dan 30 jaar, zouden de volgende twee query's identieke resultaten opleveren ondanks verschillende semantiek:
selecteer * van gebruiker
selecteer * van gebruiker waar leeftijd > 30
Nauwkeurigheid van de testreeks: nauwkeurigheid van de testsuite is een geavanceerdere en minder tolerante versie van uitvoeringsnauwkeurigheid. Voor elke query wordt een set ("testsuite") van databases gegenereerd die sterk gedifferentieerd zijn met betrekking tot de variabelen, voorwaarden en waarden in de query. Vervolgens wordt de uitvoeringsnauwkeurigheid getest op elk van deze databases. Hoewel het extra inspanning vereist om de testsuite-generatie te ontwikkelen, vermindert deze statistiek ook aanzienlijk het risico op valse positieven in de evaluatie.[12]

3. Gebruikerservaring

De huidige state-of-the-art van Text2SQL staat geen volledig naadloze integratie in productiesystemen toe - in plaats daarvan is het noodzakelijk om actief de verwachtingen en het gedrag van de gebruiker te beheren, die zich er altijd van bewust moet zijn dat ze interactie heeft een AI-systeem.

3.1 Storingsbeheer

Text2SQL kan in twee modi falen, die op verschillende manieren moeten worden opgevangen:

SQL-fouten: de gegenereerde query is niet geldig — de SQL is ongeldig of kan niet worden uitgevoerd tegen de specifieke database vanwege lexicale of semantische fouten. In dit geval kan er geen resultaat worden geretourneerd aan de gebruiker.
Semantische fouten: de gegenereerde query is geldig maar weerspiegelt niet de semantiek van de vraag, wat leidt tot een verkeerd geretourneerde dataset.

De tweede modus is bijzonder lastig omdat het risico op "stille storingen" - fouten die onopgemerkt blijven door de gebruiker - groot is. De prototypische gebruiker heeft noch de tijd, noch de technische vaardigheid om de juistheid van de zoekopdracht en/of de resulterende gegevens te verifiëren. Wanneer gegevens worden gebruikt voor besluitvorming in de echte wereld, kan dit soort fouten verwoestende gevolgen hebben. Om dit te voorkomen, is het van cruciaal belang om gebruikers op te leiden en vast te stellen vangrails op zakelijk niveau die de potentiële impact beperken, zoals extra datachecks voor beslissingen met een grotere impact. Aan de andere kant kunnen we de gebruikersinterface ook gebruiken om de interactie tussen mens en machine te beheren en de gebruiker te helpen problematische verzoeken op te sporen en te verbeteren.

3.2 Mens-machine-interactie

Gebruikers kunnen met verschillende intensiteitsniveaus betrokken raken bij uw AI-systeem. Meer interactie per verzoek kan leiden tot betere resultaten, maar vertraagt ook de vloeiendheid van de gebruikerservaring. Naast de mogelijke negatieve impact van foutieve zoekopdrachten en resultaten, moet u ook overwegen hoe gemotiveerd uw gebruikers zullen zijn om heen en weer feedback te geven om nauwkeurigere resultaten te krijgen en ook om het product op de lange termijn te helpen verbeteren.

De gemakkelijkste en minst boeiende manier is om met betrouwbaarheidsscores te werken. Hoewel de naïeve berekening van vertrouwen als een gemiddelde van de kansen van de gegenereerde tokens overdreven simplistisch is, kunnen meer geavanceerde methoden zoals verbale feedback worden gebruikt. [13] Het vertrouwen kan worden weergegeven in de interface en worden gemarkeerd met een expliciete waarschuwing voor het geval het gevaarlijk laag is. Zo komt de verantwoordelijkheid voor een passende opvolging in de “echte wereld” – of het nu gaat om een afwijzing, acceptatie of een extra controle van de gegevens – op de schouders van uw gebruiker. Hoewel dit een veilige gok is voor u als leverancier, kan het overdragen van dit werk aan de gebruiker ook de waarde van uw product verminderen.

Een tweede mogelijkheid is om de gebruiker te betrekken bij een verduidelijkingsdialoog in het geval van onbetrouwbare, dubbelzinnige of anderszins verdachte vragen. Uw systeem kan bijvoorbeeld orthografische of grammaticale correcties aan de invoer voorstellen en vragen om specifieke woorden of grammaticale structuren ondubbelzinnig te maken. Het kan de gebruiker ook in staat stellen proactief om correcties in de zoekopdracht te vragen:[14]

GEBRUIKER: Toon me de taken van John in deze sprint.

ASSISTENT: Wil je de taken zien die John heeft gemaakt of waaraan hij werkt?

GEBRUIKER: taken die John heeft gemaakt

ASSISTENT: Oké, hier zijn de taak-ID's:

GEBRUIKER: Bedankt, ik zou ook graag meer informatie zien over de taken. Sorteer ook op urgentie.

ASSISTENT: Natuurlijk, hier zijn de taken samen met korte beschrijvingen, toegewezen personen en deadlines, gesorteerd op deadline.

Ten slotte kan uw systeem, om het begrip van zoekopdrachten door de gebruiker te vergemakkelijken, ook een expliciete tekstuele herformulering van de zoekopdracht bieden en de gebruiker vragen deze te bevestigen of te corrigeren.[15]

4. Niet-functionele vereisten

In deze sectie bespreken we de specifieke niet-functionele vereisten voor Text2SQL, evenals de wisselwerking daartussen. We zullen ons concentreren op de zes vereisten die het belangrijkst lijken voor de taak: nauwkeurigheid, schaalbaarheid, snelheid, verklaarbaarheid, privacy en aanpassingsvermogen in de tijd.

4.1 Nauwkeurigheid

Voor Text2SQL zijn de eisen aan nauwkeurigheid hoog. Ten eerste wordt Text2SQL meestal toegepast in een conversatieomgeving waar voorspellingen één voor één worden gedaan. De "wet van de grote getallen", die typisch helpt om de fout in gegroepeerde voorspellingen te compenseren, helpt dus niet. Ten tweede is syntactische en lexicale validiteit een "harde" voorwaarde: het model moet een goed gevormde SQL-query genereren, mogelijk met complexe syntaxis en semantiek, anders kan het verzoek niet worden uitgevoerd tegen de database. En als dit goed gaat en de query kan worden uitgevoerd, kan deze nog steeds semantische fouten bevatten en leiden tot een verkeerd geretourneerde dataset (zie paragraaf 3.1 Storingsbeheer).

4.2 Schaalbaarheid

De belangrijkste schaalbaarheidsoverwegingen zijn of u Text2SQL op één of meerdere databases wilt toepassen - en in het laatste geval of de set databases bekend en gesloten is. Zo ja, dan zult u het gemakkelijker hebben omdat u de informatie over deze databases tijdens de training kunt opnemen. In een scenario van een schaalbaar product, of het nu gaat om een stand-alone Text2SQL-toepassing of een integratie in een bestaand dataproduct, moet uw algoritme elk nieuw databaseschema snel aankunnen. Dit scenario biedt u ook niet de mogelijkheid om de databasestructuur te transformeren om deze intuïtiever te maken voor leren (link!). Dit alles leidt tot een zware wisselwerking met nauwkeurigheid, wat ook zou kunnen verklaren waarom de huidige Text2SQL-providers die ad-hoc query's van nieuwe databases aanbieden, nog geen significante marktpenetratie hebben bereikt.

4.3 Speed

Aangezien Text2SQL-verzoeken doorgaans online in een gesprek worden verwerkt, is het snelheidsaspect belangrijk voor de tevredenheid van de gebruiker. Aan de positieve kant zijn gebruikers zich er vaak van bewust dat gegevensverzoeken een bepaalde tijd kunnen duren en tonen ze het nodige geduld. Deze goede wil kan echter worden ondermijnd door de chat-instelling, waarbij gebruikers onbewust een mensachtige gesprekssnelheid verwachten. Optimalisatiemethoden met brute kracht, zoals het verkleinen van het model, kunnen een onaanvaardbare invloed hebben op de nauwkeurigheid, dus overweeg optimalisatie van gevolgtrekkingen om aan deze verwachting te voldoen.

4.4 Uitlegbaarheid en transparantie

In het ideale geval kan de gebruiker volgen hoe de query uit de tekst is gegenereerd, de koppeling tussen specifieke woorden of uitdrukkingen in de vraag en de SQL-query enz. bekijken. Dit maakt het mogelijk om de query te verifiëren en eventuele aanpassingen te maken tijdens interactie met het systeem . Bovendien kan het systeem ook een expliciete tekstuele herformulering van de vraag geven en de gebruiker vragen deze te bevestigen of te corrigeren.

4.5 Privacy

De Text2SQL-functie kan worden geïsoleerd van de uitvoering van query's, zodat de geretourneerde database-informatie onzichtbaar kan worden gehouden. De cruciale vraag is echter hoeveel informatie over de database in de prompt is opgenomen. De drie opties (door het privacyniveau te verlagen) zijn:

Geen informatie
Databaseschema
Database-inhoud

Privacy wordt afgewisseld met nauwkeurigheid - hoe minder beperkt u bent in het opnemen van nuttige informatie in de prompt, hoe beter de resultaten.

4.6 Aanpassingsvermogen in de tijd

Om Text2SQL op een duurzame manier te gebruiken, moet u zich aanpassen aan datadrift, dwz de veranderende verdeling van de gegevens waarop het model wordt toegepast. Laten we er bijvoorbeeld van uitgaan dat de gegevens die worden gebruikt voor de initiële fijnafstemming het eenvoudige zoekgedrag van gebruikers weerspiegelen wanneer ze het BI-systeem gaan gebruiken. Naarmate de tijd verstrijkt, worden de informatiebehoeften van gebruikers geavanceerder en vereisen ze complexere zoekopdrachten, die uw naïeve model overweldigen. Bovendien kunnen de doelen of de strategie van een bedrijfsverandering ook afdrijven en de informatiebehoefte naar andere delen van de database sturen. Ten slotte is een Text2SQL-specifieke uitdaging database drift. Naarmate de bedrijfsdatabase wordt uitgebreid, komen nieuwe, ongeziene kolommen en tabellen in de prompt terecht. Hoewel Text2SQL-algoritmen die zijn ontworpen voor toepassingen met meerdere databases dit probleem goed aankunnen, kan het de nauwkeurigheid van een model met één database aanzienlijk beïnvloeden. Al deze problemen kunnen het beste worden opgelost met een nauwkeurig afgestelde dataset die het huidige, reële gedrag van gebruikers weerspiegelt. Het is dus van cruciaal belang om vragen en resultaten van gebruikers te loggen, evenals alle bijbehorende feedback die kan worden verzameld over het gebruik. Daarnaast kunnen semantische clustering-algoritmen, bijvoorbeeld met behulp van inbedding of topic-modellering, worden toegepast om onderliggende langetermijnveranderingen in gebruikersgedrag te detecteren en deze te gebruiken als een aanvullende informatiebron voor het perfectioneren van uw dataset voor fijnafstemming

Conclusie

Laten we de belangrijkste punten van het artikel samenvatten:

Text2SQL maakt het mogelijk om intuïtieve en democratische gegevenstoegang in een bedrijf te implementeren, waardoor de waarde van de beschikbare gegevens wordt gemaximaliseerd.
Text2SQL-gegevens bestaan uit vragen aan de invoer en SQL-query's aan de uitvoer. De koppeling tussen vragen en SQL-query's is veel-op-veel.
Het is belangrijk om informatie over de database op te geven als onderdeel van de prompt. Bovendien kan de databasestructuur worden geoptimaliseerd om het voor het algoritme gemakkelijker te maken om het te leren en te begrijpen.
Wat de invoer betreft, is de grootste uitdaging de taalvariabiliteit van vragen in natuurlijke taal, die kunnen worden benaderd met behulp van LLM's die vooraf zijn getraind in een grote verscheidenheid aan verschillende tekststijlen
De uitvoer van Text2SQL moet een geldige SQL-query zijn. Deze beperking kan worden opgenomen door SQL-kennis in het algoritme te "injecteren"; als alternatief kan de query met behulp van een iteratieve benadering in meerdere stappen worden gecontroleerd en verbeterd.
Vanwege de potentieel grote impact van "stille storingen" die verkeerde gegevens retourneren voor besluitvorming, is storingsbeheer een primaire zorg in de gebruikersinterface.
Op een "augmented" manier kunnen gebruikers actief worden betrokken bij iteratieve validatie en verbetering van SQL-query's. Hoewel dit de applicatie minder vloeiend maakt, vermindert het ook het aantal mislukkingen, stelt het gebruikers in staat om gegevens op een flexibelere manier te verkennen en creëert het waardevolle signalen voor verder leren.
De belangrijkste niet-functionele vereisten waarmee rekening moet worden gehouden, zijn nauwkeurigheid, schaalbaarheid, snelheid, verklaarbaarheid, privacy en aanpassingsvermogen in de loop van de tijd. De belangrijkste compromissen zijn enerzijds nauwkeurigheid en anderzijds schaalbaarheid, snelheid en privacy.