Skapa en informationskant med konversationsåtkomst till data

Återutgiven av Platon

anhängare: 0

konversations-AI för dataanalys

Figur 1: Representation av Text2SQL-flödet

När vår värld blir mer global och dynamisk blir företag mer och mer beroende av data för att kunna fatta informerade, objektiva och snabba beslut. Men från och med nu är det ofta ett privilegium för en handfull datavetare och analytiker att frigöra organisationsdatas fulla potential. De flesta anställda behärskar inte den konventionella verktygslådan för datavetenskap (SQL, Python, R etc.). För att komma åt önskad data går de via ett extra lager där analytiker eller BI-team "översätter" affärsfrågornas prosa till dataspråket. Potentialen för friktion och ineffektivitet på denna resa är stor - till exempel kan data levereras med förseningar eller till och med när frågan redan har blivit föråldrad. Information kan gå förlorad på vägen när kraven inte korrekt översätts till analytiska frågor. Att generera högkvalitativa insikter kräver dessutom ett iterativt tillvägagångssätt som avråds från varje ytterligare steg i slingan. Å andra sidan skapar dessa ad-hoc-interaktioner störningar för dyra datatalanger och distraherar dem från mer strategiskt dataarbete, som beskrivs i dessa "bekännelser" av en datavetare:

När jag var på Square och teamet var mindre hade vi en fruktad "analytics-jourrotation". Den roterades strikt varje vecka, och om det var din tur visste du att du skulle få väldigt lite "riktigt" arbete gjort den veckan och spendera det mesta av din tid med att ställa ad hoc-frågor från de olika produkt- och driftsteamen på företag (SQL monkeying, kallade vi det). Det var en hård konkurrens om chefsroller i analysteamet och jag tror att detta helt och hållet var resultatet av att chefer undantogs från denna rotation – inget statuspris kunde konkurrera med moroten att inte utföra jourarbete.[1]

Visst, skulle det inte vara coolt att prata direkt med din data istället för att behöva gå igenom flera omgångar av interaktion med din datapersonal? Denna vision omfattas av konversationsgränssnitt som tillåter människor att interagera med data med hjälp av språk, vår mest intuitiva och universella kommunikationskanal. Efter att ha analyserat en fråga kodar en algoritm den till en strukturerad logisk form i det valda frågespråket, till exempel SQL. Således kan icke-tekniska användare chatta med sin data och snabbt få tag på specifik, relevant och aktuell information, utan att ta en omväg via ett BI-team. I den här artikeln kommer vi att överväga de olika implementeringsaspekterna av Text2SQL och fokusera på moderna tillvägagångssätt med användning av stora språkmodeller (LLM), som uppnår den bästa prestandan för närvarande (jfr [2]; för en undersökning om alternativa tillvägagångssätt utöver LLM:er hänvisas läsarna till [3]). Artikeln är strukturerad enligt följande "mentala modell" av huvudelementen att tänka på när du planerar och bygger en AI-funktion:

konversations-AI för dataanalys — Figur 2: Mental modell av en AI-funktion

Låt oss börja med slutet i åtanke och sammanfatta värdet – varför du skulle bygga in en Text2SQL-funktion i din data- eller analysprodukt. De tre huvudsakliga fördelarna är:

Affärsanvändare kan komma åt organisationsdata på ett direkt och snabbt sätt.
Detta lindrar datavetare och analytiker från bördan av ad-hoc-förfrågningar från företagsanvändare och låter dem fokusera på avancerade datautmaningar.
Detta tillåter företag att dra nytta av sin data på ett mer flytande och strategiskt sätt, och slutligen förvandla det till en solid grund för beslutsfattande.

Nu, vilka är de produktscenarier där du kan överväga Text2SQL? De tre huvudinställningarna är:

Du erbjuder en skalbar data/BI-produkt och vill göra det möjligt för fler användare att komma åt sina data på ett icke-tekniskt sätt, och på så sätt öka både användningen och användarbasen. Som ett exempel har ServiceNow integrerade datafrågor i ett större samtalsutbudoch Atlan har nyligen tillkännagav datautforskning på naturliga språk.
Du funderar på att bygga något inom data/AI-utrymmet för att demokratisera dataåtkomst i företag, i vilket fall du potentiellt kan överväga en MVP med Text2SQL i kärnan. Leverantörer gillar AI2SQL och Text2sql.ai gör redan entré i detta utrymme.
Du arbetar på en anpassat BI-system och vill maximera och demokratisera dess användning i det enskilda företaget.

Som vi kommer att se i de följande avsnitten kräver Text2SQL en icke-trivial uppsättning i förväg. För att uppskatta avkastningen på investeringen, överväg karaktären av de beslut som ska stödjas samt på tillgänglig data. Text2SQL kan vara en absolut vinst i dynamiska miljöer där data förändras snabbt och används aktivt och ofta i beslutsfattande, såsom investeringar, marknadsföring, tillverkning och energiindustrin. I dessa miljöer är traditionella verktyg för kunskapshantering för statiska, och mer flytande sätt att komma åt data och information hjälper företag att skapa konkurrensfördelar. När det gäller data ger Text2SQL det största värdet med en databas som är:

Stor och växande, så att Text2SQL kan utveckla sitt värde över tid när mer och mer av data utnyttjas.
Högkvalitativ, så att Text2SQL-algoritmen inte behöver hantera överdrivet brus (inkonsekvenser, tomma värden etc.) i data. Generellt sett har data som genereras automatiskt av applikationer en högre kvalitet och konsistens än data som skapas och underhålls av människor.
Semantiskt mogen i motsats till rå, så att människor kan fråga data baserat på centrala begrepp, relationer och mått som finns i deras mentala modell. Observera att semantisk mognad kan uppnås genom ytterligare ett transformationssteg som anpassar rådata till en konceptuell struktur (jfr avsnittet "Berika prompten med databasinformation").

I det följande kommer vi att djupdyka i data, algoritm, användarupplevelse, såväl som relevanta icke-funktionella krav för en Text2SQL-funktion. Artikeln är skriven för produktchefer, UX-designers och de datavetare och ingenjörer som är i början av sin Text2SQL-resa. För dessa människor ger det inte bara en guide för att komma igång, utan också en gemensam kunskapsgrund för diskussioner kring gränssnitten mellan produkt, teknik och affärer, inklusive relaterade avvägningar. Om du redan är mer avancerad i din implementering ger referenserna i slutet en rad djupdykning att utforska.

Om detta fördjupade utbildningsinnehåll är användbart för dig kan du prenumerera på vår AI-forskningsmaillista att bli varnade när vi släpper nytt material.

1. Data

Varje strävan efter maskininlärning börjar med data, så vi börjar med att förtydliga strukturen för indata och måldata som används under träning och förutsägelse. Genom hela artikeln kommer vi att använda Text2SQL-flödet från figur 1 som vår löpande representation och markera de aktuella komponenterna och relationerna i gult.

1.1 Dataformat och struktur

Vanligtvis består ett rå Text2SQL input-out-par av en naturligt språkfråga och motsvarande SQL-fråga, till exempel:

Fråga: "Lista namn och antal följare för varje användare."

SQL-fråga:

välj namn, följare från user_profiles

I träningsdatautrymmet är mappningen mellan frågor och SQL-frågor många-till-många:

En SQL-fråga kan mappas till många olika frågor i naturligt språk; till exempel kan frågesemantiken ovan uttryckas med: "visa mig namn och antal följare per användare","hur många följare finns det för varje användare?" etc.
SQL-syntax är mycket mångsidig, och nästan varje fråga kan representeras i SQL på flera sätt. Det enklaste exemplet är olika ordningsföljder av WHERE-satser. På en mer avancerad hållning kommer alla som har gjort SQL-frågeoptimering att veta att många vägar leder till samma resultat, och semantiskt likvärdiga frågor kan ha en helt annan syntax.

Den manuella insamlingen av träningsdata för Text2SQL är särskilt tråkig. Det kräver inte bara SQL-behärskning från annotatorns sida, utan också mer tid per exempel än mer allmänna språkliga uppgifter som sentimentanalys och textklassificering. För att säkerställa en tillräcklig mängd träningsexempel kan dataförstärkning användas – till exempel kan LLM:er användas för att generera omskrivningar för samma fråga. [3] ger en mer komplett översikt över Text2SQL-tekniker för dataförstärkning.

1.2 Att berika prompten med databasinformation

Text2SQL är en algoritm i gränssnittet mellan ostrukturerad och strukturerad data. För optimal prestanda måste båda typerna av data finnas med under träning och förutsägelse. Specifikt måste algoritmen känna till den efterfrågade databasen och kunna formulera frågan på ett sådant sätt att den kan exekveras mot databasen. Denna kunskap kan omfatta:

Kolumner och tabeller i databasen
Relationer mellan tabeller (främmande nycklar)
Databasinnehåll

Det finns två alternativ för att införliva databaskunskap: å ena sidan kan träningsdata begränsas till exempel skrivna för den specifika databasen, i vilket fall schemat lärs in direkt från SQL-frågan och dess mappning till frågan. Denna endatabasinställning gör det möjligt att optimera algoritmen för en enskild databas och/eller företag. Det tar dock bort alla ambitioner om skalbarhet, eftersom modellen behöver finjusteras för varje enskild kund eller databas. Alternativt, i en multi-databasinställning, kan databasschemat tillhandahållas som en del av inmatningen, vilket gör att algoritmen kan "generalisera" till nya, osynliga databasscheman. Även om du absolut måste välja detta tillvägagångssätt om du vill använda Text2SQL på många olika databaser, kom ihåg att det kräver avsevärda snabba ingenjörsinsatser. För alla rimliga företagsdatabaser, inklusive den fullständiga informationen i prompten kommer det att vara extremt ineffektivt och troligen omöjligt på grund av snabba längdbegränsningar. Således bör funktionen som ansvarar för snabb formulering vara smart nog att välja en delmängd av databasinformation som är mest "användbar" för en given fråga, och att göra detta för potentiellt osynliga databaser.

Slutligen spelar databasstrukturen en avgörande roll. I de scenarier där du har tillräckligt med kontroll över databasen kan du göra din modell enklare genom att låta den lära sig av en intuitiv struktur. Som en tumregel gäller att ju mer din databas speglar hur affärsanvändare pratar om verksamheten, desto bättre och snabbare kan din modell lära sig av det. Överväg därför att tillämpa ytterligare transformationer på data, såsom att sammanställa normaliserade eller på annat sätt spridda data till breda tabeller eller ett datavalv, namnge tabeller och kolumner på ett explicit och entydigt sätt etc. All affärskunskap som du kan koda i förväg kommer att minska bördan av probabilistisk inlärning på din modell och hjälpa dig att uppnå bättre resultat.

2. algoritm

Text2SQL är en typ av semantisk analys — Kartläggning av texter till logiska representationer. Algoritmen måste alltså inte bara "lära sig" naturligt språk, utan också målrepresentationen - i vårt fall SQL. Specifikt måste den förvärva och följande kunskaper:

SQL-syntax och semantik
Databasstruktur
Naturligt språkförståelse (NLU)
Mappning mellan naturligt språk och SQL-frågor (syntaktisk, lexikal och semantisk)

2.1 Lösning av språklig variation i inmatningen

Vid ingången ligger huvudutmaningen med Text2SQL i språkets flexibilitet: som beskrivs i avsnittet Dataformat och struktur kan samma fråga parafraseras på många olika sätt. Dessutom, i det verkliga konversationssammanhanget, måste vi hantera ett antal frågor som stavnings- och grammatikfel, ofullständiga och tvetydiga inmatningar, flerspråkiga inmatningar etc.

LLMs som GPT-modellerna, T5 och CodeX kommer närmare och närmare att lösa denna utmaning. Genom att lära sig av enorma mängder olika texter lär de sig att hantera ett stort antal språkliga mönster och oegentligheter. I slutändan blir de i stånd att generalisera över frågor som är semantiskt lika trots att de har olika ytformer. LLM:er kan appliceras direkt (zero-shot) eller efter finjustering. Det förra, även om det är bekvämt, leder till lägre noggrannhet. Det senare kräver mer skicklighet och arbete, men kan avsevärt öka noggrannheten.

När det gäller noggrannhet, som förväntat, är de bäst presterande modellerna de senaste modellerna i GPT-familjen inklusive CodeX-modellerna. I april 2023 ledde GPT-4 till en dramatisk noggrannhetsökning på mer än 5 % jämfört med tidigare toppmoderna och uppnådde en noggrannhet på 85.3 % (på det metriska "utförande med värden").[4] I öppen källkodslägret fokuserades de första försöken att lösa Text2SQL-pusslet på modeller för automatisk kodning som BERT, som utmärker sig i NLU-uppgifter.[5, 6, 7] Men mitt i hypen kring generativ AI fokuserar de senaste metoderna på autoregressiva modeller som T5-modellen. T5 är förtränad med hjälp av multi-task learning och anpassar sig därmed enkelt till nya språkliga uppgifter, inkl. olika varianter av semantisk analys. Men autoregressiva modeller har ett inneboende fel när det kommer till semantiska analyseringsuppgifter: de har ett obegränsat utdatautrymme och inga semantiska skyddsräcken som skulle begränsa deras utdata, vilket innebär att de kan bli fantastiskt kreativa i sitt beteende. Även om det här är fantastiska saker för att generera innehåll i fritt format, är det en olägenhet för uppgifter som Text2SQL där vi förväntar oss en begränsad, välstrukturerad målutdata.

2.2 Frågevalidering och förbättring

För att begränsa LLM-utdata kan vi introducera ytterligare mekanismer för att validera och förbättra frågan. Detta kan implementeras som ett extra valideringssteg, som föreslås i PICARD-systemet.[8] PICARD använder en SQL-tolkare som kan verifiera om en delvis SQL-fråga kan leda till en giltig SQL-fråga efter slutförandet. Vid varje genereringssteg av LLM avvisas tokens som skulle ogiltigförklara frågan, och de giltiga tokens med högst sannolikhet behålls. Eftersom det är deterministiskt säkerställer detta tillvägagångssätt 100 % SQL-giltighet så länge som parsern observerar korrekta SQL-regler. Den frikopplar också frågevalideringen från genereringen, vilket gör det möjligt att underhålla båda komponenterna oberoende av varandra och att uppgradera och modifiera LLM.

Ett annat tillvägagångssätt är att införliva struktur- och SQL-kunskap direkt i LLM. Till exempel använder Graphix [9] grafmedvetna lager för att injicera strukturerad SQL-kunskap i T5-modellen. På grund av den probabilistiska karaktären hos detta tillvägagångssätt, fördomar det systemet mot korrekta frågor, men ger ingen garanti för framgång.

Slutligen kan LLM användas som en agent i flera steg som självständigt kan kontrollera och förbättra frågan.[10] Genom att använda flera steg i en tankekedja kan agenten få i uppdrag att reflektera över riktigheten i sina egna frågor och förbättra eventuella brister. Om den validerade frågan fortfarande inte kan köras, kan SQL-undantagets spårning skickas till agenten som en ytterligare feedback för förbättring.

Utöver dessa automatiserade metoder som sker i backend, är det också möjligt att involvera användaren under frågekontrollprocessen. Vi kommer att beskriva detta mer i detalj i avsnittet om Användarupplevelse.

2.3 Utvärdering

För att utvärdera vår Text2SQL-algoritm måste vi generera en testdatauppsättning (validering), köra vår algoritm på den och tillämpa relevanta utvärderingsmått på resultatet. En naiv datauppsättning uppdelad i utbildnings-, utvecklings- och valideringsdata skulle baseras på fråge-förfråganspar och leda till suboptimala resultat. Valideringsfrågor kan avslöjas för modellen under träning och leda till en alltför optimistisk syn på dess generaliseringsförmåga. A frågebaserad uppdelning, där datauppsättningen är uppdelad på ett sådant sätt att ingen fråga visas både under träning och under validering, ger mer sanningsenliga resultat.

När det gäller utvärderingsmått är det vi bryr oss om i Text2SQL inte att generera frågor som är helt identiska med guldstandarden. Detta "exakt strängmatchning" Metoden är för strikt och kommer att generera många falska negativ, eftersom olika SQL-frågor kan leda till samma returnerade dataset. Istället vill vi nå högt semantisk noggrannhet och utvärdera om de förutspådda frågorna och "guldstandard"-frågorna alltid skulle returnera samma datamängder. Det finns tre utvärderingsmått som approximerar detta mål:

Exakt inställd matchningsnoggrannhet: de genererade och mål-SQL-frågorna delas upp i sina beståndsdelar, och de resulterande uppsättningarna jämförs för identitet.[11] Bristen här är att den bara tar hänsyn till ordningsvariationer i SQL-frågan, men inte för mer uttalade syntaktiska skillnader mellan semantiskt ekvivalenta frågor.
Exekveringsnoggrannhet: datauppsättningarna som är resultatet av de genererade SQL-frågorna och mål-SQL-frågorna jämförs för identitet. Med lycka till kan frågor med olika semantik fortfarande klara detta test på en specifik databasinstans. Om man till exempel antar en databas där alla användare är över 30 år, skulle följande två frågor returnera identiska resultat trots olika semantik:
välj * från användare
välj * från användare där ålder > 30
Testsvits noggrannhet: testsvitsnoggrannhet är en mer avancerad och mindre tillåtande version av exekveringsnoggrannhet. För varje fråga genereras en uppsättning ("testsvit") av databaser som är mycket differentierade med avseende på variabler, villkor och värden i frågan. Därefter testas exekveringsnoggrannheten på var och en av dessa databaser. Även om det kräver ytterligare ansträngning för att konstruera testsvitsgenereringen, minskar detta mått också avsevärt risken för falska positiva resultat i utvärderingen.[12]

3. Användarupplevelse

Den nuvarande state-of-the-art av Text2SQL tillåter inte en helt sömlös integration i produktionssystem – istället är det nödvändigt att aktivt hantera förväntningarna och beteendet hos användaren, som alltid bör vara medveten om att hon interagerar med ett AI-system.

3.1 Felhantering

Text2SQL kan misslyckas i två lägen, som måste fångas på olika sätt:

SQL-fel: den genererade frågan är inte giltig — antingen är SQL-koden ogiltig eller så kan den inte köras mot den specifika databasen på grund av lexikaliska eller semantiska brister. I detta fall kan inget resultat returneras till användaren.
Semantiska fel: den genererade frågan är giltig men den återspeglar inte semantiken i frågan, vilket leder till en felaktig returnerad datauppsättning.

Det andra läget är särskilt knepigt eftersom risken för "tysta fel" - fel som inte upptäcks av användaren - är hög. Den prototypiska användaren har varken tid eller teknisk skicklighet att verifiera att frågan och/eller de resulterande uppgifterna är korrekta. När data används för beslutsfattande i den verkliga världen kan denna typ av misslyckande få förödande konsekvenser. För att undvika detta är det viktigt att utbilda användare och etablera sig skyddsräcken på affärsnivå som begränsar den potentiella effekten, till exempel ytterligare datakontroller för beslut med större effekt. Å andra sidan kan vi också använda användargränssnittet för att hantera människa-maskin-interaktionen och hjälpa användaren att upptäcka och förbättra problematiska förfrågningar.

3.2 Interaktion mellan människa och maskin

Användare kan engagera sig i ditt AI-system med olika grader av intensitet. Mer interaktion per begäran kan leda till bättre resultat, men det saktar också ner användarupplevelsens smidighet. Förutom den potentiella negativa effekten av felaktiga frågor och resultat, överväg också hur motiverade dina användare kommer att vara att ge tillbaka och tillbaka feedback för att få mer exakta resultat och även hjälpa till att förbättra produkten på lång sikt.

Det enklaste och minst engagerande sättet är att arbeta med självförtroendepoäng. Medan den naiva beräkningen av förtroende som ett genomsnitt av sannolikheterna för de genererade tokens är alltför förenklad, kan mer avancerade metoder som verbaliserad feedback användas. [13] Förtroendet kan visas i gränssnittet och markeras med en explicit varning om det är farligt lågt. På så sätt hamnar ansvaret för en lämplig uppföljning i den "verkliga världen" - oavsett om det är ett avslag, godkännande eller en extra kontroll av data - på din användares axlar. Även om detta är ett säkert kort för dig som leverantör, kan överföring av detta arbete till användaren också minska värdet på din produkt.

En andra möjlighet är att engagera användaren i en förtydligande dialog vid lågt förtroende, tvetydiga eller på annat sätt misstänkta frågor. Ditt system kan till exempel föreslå ortografiska eller grammatiska korrigeringar av inmatningen och be att disambiguera specifika ord eller grammatiska strukturer. Det kan också tillåta användaren att proaktivt be om korrigeringar i frågan:[14]

ANVÄNDARE: Visa mig Johns uppgifter i den här spurten.

ASSISTENT: Vill du se uppgifter som John skapade, eller de han arbetar med?

ANVÄNDARE: uppgifter som John skapade

ASSISTENT: Ok, här är uppgifts-ID:n:

ANVÄNDARE: Tack, jag skulle också vilja se mer information om uppgifterna. Sortera också efter brådska.

ASSISTENT: Visst, här är uppgifterna tillsammans med korta beskrivningar, uppdragstagare och deadlines, sorterade efter deadline.

Slutligen, för att underlätta förståelsen av frågor för användaren, kan ditt system också tillhandahålla en explicit textomformulering av frågan och be användaren att antingen bekräfta eller korrigera den.[15]

4. Icke-funktionella krav

I det här avsnittet diskuterar vi de specifika icke-funktionella kraven för Text2SQL såväl som avvägningarna mellan dem. Vi kommer att fokusera på de sex krav som verkar viktigast för uppgiften: noggrannhet, skalbarhet, snabbhet, förklarabarhet, integritet och anpassningsförmåga över tid.

4.1 Noggrannhet

För Text2SQL är kraven på noggrannhet höga. För det första används Text2SQL vanligtvis i en konversationsmiljö där förutsägelser görs en i taget. Därför hjälper inte "lagen om stora siffror" som vanligtvis hjälper till att balansera felet i gruppförutsägelser. För det andra är syntaktisk och lexikal validitet ett "hårt" villkor: modellen måste generera en välformad SQL-fråga, potentiellt med komplex syntax och semantik, annars kan begäran inte exekveras mot databasen. Och om detta går bra och frågan kan exekveras, kan den fortfarande innehålla semantiska fel och leda till ett felaktigt returnerat dataset (jfr avsnitt 3.1 Felhantering).

4.2 Skalbarhet

De viktigaste skalbarhetsövervägandena är om du vill använda Text2SQL på en eller flera databaser - och i det senare fallet, om uppsättningen av databaser är känd och stängd. Om ja, kommer du att ha det lättare eftersom du kan inkludera informationen om dessa databaser under utbildningen. Men i ett scenario med en skalbar produkt - vare sig det är en fristående Text2SQL-applikation eller en integration i en befintlig dataprodukt - måste din algoritm klara alla nya databasscheman i farten. Det här scenariot ger dig inte heller möjlighet att transformera databasstrukturen för att göra den mer intuitiv för inlärning (länk!). Allt detta leder till en tung avvägning med noggrannhet, vilket också kan förklara varför nuvarande Text2SQL-leverantörer som erbjuder ad-hoc-sökning av nya databaser ännu inte har nått en betydande marknadspenetration.

4.3 Speed

Eftersom Text2SQL-förfrågningar vanligtvis kommer att behandlas online i en konversation, är hastighetsaspekten viktig för användarnas tillfredsställelse. På den positiva sidan är användare ofta medvetna om att dataförfrågningar kan ta en viss tid och visa det tålamod som krävs. Denna välvilja kan dock undergrävas av chattinställningarna, där användarna omedvetet förväntar sig en mänsklig konversationshastighet. Brute-force optimeringsmetoder som att minska storleken på modellen kan ha en oacceptabel inverkan på noggrannheten, så överväg slutledningsoptimering för att tillfredsställa denna förväntning.

4.4 Förklarlighet och transparens

I det ideala fallet kan användaren följa hur frågan genererades från texten, se mappningen mellan specifika ord eller uttryck i frågan och SQL-frågan etc. Detta gör det möjligt att verifiera frågan och göra eventuella justeringar vid interaktion med systemet . Dessutom kan systemet också tillhandahålla en explicit textomformulering av frågan och be användaren att antingen bekräfta eller korrigera den.

4.5 Sekretess

Text2SQL-funktionen kan isoleras från frågekörning, så att den returnerade databasinformationen kan hållas osynlig. Den kritiska frågan är dock hur mycket information om databasen som ingår i prompten. De tre alternativen (genom att minska integritetsnivån) är:

Ingen information
Databasschema
Databasinnehåll

Sekretess avviker med precision - ju mindre begränsad du är i att inkludera användbar information i prompten, desto bättre resultat.

4.6 Anpassningsförmåga över tid

För att använda Text2SQL på ett hållbart sätt behöver du anpassa dig till datadrift, det vill säga den förändrade distributionen av de data som modellen appliceras på. Låt oss till exempel anta att data som används för initial finjustering återspeglar användarnas enkla frågebeteende när de börjar använda BI-systemet. Allt eftersom tiden går blir användarnas informationsbehov mer sofistikerade och kräver mer komplexa frågor, vilket överväldigar din naiva modell. Dessutom kan målen eller strategin för en företagsförändring också driva och styra informationsbehoven mot andra delar av databasen. Slutligen är en Text2SQL-specifik utmaning databasdrift. När företagsdatabasen utökas kommer nya, osynliga kolumner och tabeller in i prompten. Även om Text2SQL-algoritmer som är designade för multi-databasapplikationer kan hantera detta problem bra, kan det avsevärt påverka noggrannheten hos en enkeldatabasmodell. Alla dessa problem löses bäst med en finjusterande datauppsättning som återspeglar användarnas nuvarande beteende i verkligheten. Därför är det avgörande att logga användarfrågor och resultat, såväl som all tillhörande feedback som kan samlas in från användning. Dessutom kan semantiska klustringsalgoritmer, till exempel genom att använda inbäddningar eller ämnesmodellering, användas för att upptäcka underliggande långsiktiga förändringar i användarbeteende och använda dessa som en ytterligare informationskälla för att perfekta din finjusteringsdatauppsättning

Slutsats

Låt oss sammanfatta de viktigaste punkterna i artikeln:

Text2SQL gör det möjligt att implementera intuitiv och demokratisk dataåtkomst i ett företag, vilket maximerar värdet av tillgänglig data.
Text2SQL-data består av frågor vid ingången och SQL-frågor vid utgången. Mappningen mellan frågor och SQL-frågor är många-till-många.
Det är viktigt att ge information om databasen som en del av uppmaningen. Dessutom kan databasstrukturen optimeras för att göra det lättare för algoritmen att lära sig och förstå den.
När det gäller input är den största utmaningen den språkliga variationen av naturliga språkfrågor, som kan närma sig med hjälp av LLM:er som förutbildats i en mängd olika textstilar
Utdata från Text2SQL bör vara en giltig SQL-fråga. Denna begränsning kan införlivas genom att "injicera" SQL-kunskap i algoritmen; alternativt, med en iterativ metod, kan frågan kontrolleras och förbättras i flera steg.
På grund av den potentiellt höga effekten av "tysta fel" som returnerar felaktiga data för beslutsfattande, är felhantering ett primärt problem i användargränssnittet.
På ett "förstärkt" sätt kan användare vara aktivt involverade i iterativ validering och förbättring av SQL-frågor. Även om detta gör applikationen mindre flytande, minskar den också felfrekvensen, tillåter användare att utforska data på ett mer flexibelt sätt och skapar värdefulla signaler för vidare lärande.
De viktigaste icke-funktionella kraven att överväga är noggrannhet, skalbarhet, hastighet, förklarabarhet, integritet och anpassningsförmåga över tid. De huvudsakliga avvägningarna består mellan noggrannhet å ena sidan och skalbarhet, hastighet och integritet å andra sidan.