Ustvarjanje informacijskega roba s pogovornim dostopom do podatkov

Ponovno objavil Platon

Spremljevalci: 0

pogovorni AI za analizo podatkov

Slika 1: Predstavitev toka Text2SQL

Ker naš svet postaja bolj globalen in dinamičen, so podjetja vedno bolj odvisna od podatkov za sprejemanje informiranih, objektivnih in pravočasnih odločitev. Vendar pa je od zdaj sprostitev celotnega potenciala organizacijskih podatkov pogosto privilegij peščice podatkovnih znanstvenikov in analitikov. Večina zaposlenih ne obvlada običajnega kompleta orodij za podatkovno znanost (SQL, Python, R itd.). Za dostop do želenih podatkov gredo prek dodatnega sloja, kjer analitiki ali BI ekipe »prevedejo« prozo poslovnih vprašanj v jezik podatkov. Možnost trenja in neučinkovitosti na tem potovanju je velika – podatki so na primer lahko dostavljeni z zamudo ali celo, ko je vprašanje že zastarelo. Informacije se lahko med potjo izgubijo, če zahteve niso natančno prevedene v analitične poizvedbe. Poleg tega ustvarjanje visokokakovostnih vpogledov zahteva ponavljajoč se pristop, ki ga odsvetujemo z vsakim dodatnim korakom v zanki. Po drugi strani te ad-hoc interakcije ustvarjajo motnje za drage podatkovne talente in jih odvračajo od bolj strateškega dela s podatki, kot je opisano v teh "izpovedih" podatkovnega znanstvenika:

Ko sem bil v Squareu in je bila ekipa manjša, smo imeli strašno rotacijo »dežurnih analitikov«. Rotiralo se je strogo tedensko, in če ste bili na vrsti, ste vedeli, da boste tisti teden opravili zelo malo »pravega« dela in boste večino svojega časa porabili za ad hoc vprašanja različnih produktnih in operativnih skupin na podjetje (SQL monkeying, smo temu rekli). Za vodstvene vloge v skupini za analitiko je bila ostra konkurenca in mislim, da je bil to v celoti posledica tega, da so bili menedžerji izvzeti iz te rotacije – nobena statusna nagrada se ni mogla kosati s korenčkom neopravljanja dežurstva.[1]

Res, ali ne bi bilo kul govoriti neposredno z vašimi podatki, namesto da bi morali iti skozi več krogov interakcije z vašim podatkovnim osebjem? To vizijo zajemajo pogovorni vmesniki, ki ljudem omogočajo interakcijo s podatki z uporabo jezika, našega najbolj intuitivnega in univerzalnega komunikacijskega kanala. Po razčlenjevanju vprašanja ga algoritem kodira v strukturirano logično obliko v izbranem poizvedovalnem jeziku, kot je SQL. Tako lahko netehnični uporabniki klepetajo s svojimi podatki in hitro dobijo specifične, ustrezne in pravočasne informacije, ne da bi se obrnili prek skupine BI. V tem članku bomo preučili različne izvedbene vidike Text2SQL in se osredotočili na sodobne pristope z uporabo velikih jezikovnih modelov (LLM), ki dosegajo najboljšo učinkovitost do zdaj (prim. [2]; za pregled alternativnih pristopov poleg LLM-jev se sklicevajo na bralce [3]). Članek je strukturiran v skladu z naslednjim "mentalnim modelom" glavnih elementov, ki jih je treba upoštevati pri načrtovanju in gradnji funkcije AI:

pogovorni AI za analizo podatkov — Slika 2: Mentalni model funkcije AI

Začnimo s koncem v mislih in povzamemo vrednost – zakaj bi v svoj podatkovni ali analitični izdelek vgradili funkcijo Text2SQL. Tri glavne prednosti so:

Poslovni uporabniki lahko dostopa do organizacijskih podatkov na neposreden in pravočasen način.
To razbremeni podatkovni znanstveniki in analitiki od bremena ad-hoc zahtev poslovnih uporabnikov in jim omogoča, da se osredotočijo na napredne podatkovne izzive.
To omogoča poslovni da izkoristi svoje podatke na bolj tekoč in strateški način ter jih končno spremeni v trdno podlago za odločanje.

Kakšni so scenariji izdelkov, v katerih bi lahko razmislili o Text2SQL? Tri glavne nastavitve so:

Ponujate a razširljivi podatki/izdelek BI in želijo več uporabnikom omogočiti dostop do njihovih podatkov na netehničen način, s čimer bi povečali tako uporabo kot bazo uporabnikov. Kot primer ima ServiceNow integrirane podatkovne poizvedbe v večjo pogovorno ponudboin Atlan pred kratkim napovedano raziskovanje podatkov v naravnem jeziku.
Želite zgraditi nekaj v prostoru podatkov/AI za demokratizacijo dostopa do podatkov v podjetjih, v tem primeru bi lahko razmislili o MVP z Text2SQL v jedru. Ponudniki kot AI2SQL in Text2sql.ai že vstopajo v ta prostor.
Delate na a BI sistem po meri in želijo povečati in demokratizirati njegovo uporabo v posameznem podjetju.

Kot bomo videli v naslednjih razdelkih, Text2SQL zahteva netrivialno vnaprejšnjo nastavitev. Za oceno donosnosti naložbe upoštevajte naravo odločitev, ki jih je treba podpreti, in razpoložljive podatke. Text2SQL je lahko absolutna zmaga v dinamičnih okoljih, kjer se podatki hitro spreminjajo in se aktivno in pogosto uporabljajo pri odločanju, kot so naložbe, trženje, proizvodnja in energetska industrija. V teh okoljih so tradicionalna orodja za upravljanje znanja preveč statična, bolj tekoči načini dostopa do podatkov in informacij pa pomagajo podjetjem pri ustvarjanju konkurenčne prednosti. Kar zadeva podatke, Text2SQL zagotavlja največjo vrednost z bazo podatkov, ki je:

Velik in rastoč, tako da lahko Text2SQL sčasoma razkrije svojo vrednost, ko se uporablja vse več podatkov.
Visoka kakovost, tako da se algoritmu Text2SQL ni treba ukvarjati s čezmernim šumom (nedoslednosti, prazne vrednosti itd.) v podatkih. Na splošno imajo podatki, ki jih samodejno ustvarijo aplikacije, višjo kakovost in doslednost kot podatki, ki jih ustvarijo in vzdržujejo ljudje.
Pomensko zrelo v nasprotju s surovimi, tako da lahko ljudje poizvedujejo po podatkih na podlagi osrednjih konceptov, odnosov in meritev, ki obstajajo v njihovem mentalnem modelu. Upoštevajte, da je semantično zrelost mogoče doseči z dodatnim korakom transformacije, ki prilagodi neobdelane podatke v konceptualno strukturo (prim. razdelek »Obogatitev poziva z informacijami o bazi podatkov«).

V nadaljevanju se bomo poglobili v podatke, algoritem, uporabniško izkušnjo in ustrezne nefunkcionalne zahteve funkcije Text2SQL. Članek je napisan za produktne vodje, UX oblikovalce ter tiste podatkovne znanstvenike in inženirje, ki so na začetku svoje poti Text2SQL. Za te ljudi ne ponuja le vodnika za začetek, temveč tudi skupno podlago znanja za razprave o vmesnikih med izdelkom, tehnologijo in poslom, vključno s povezanimi kompromisi. Če ste že bolj napredni pri izvajanju, reference na koncu ponujajo vrsto poglobljenih potopov za raziskovanje.

Če je ta poglobljena izobraževalna vsebina za vas koristna, lahko se naročite na naš seznam raziskav AI za raziskave na katerega bomo opozorili, ko bomo izdali novo gradivo.

1. Podatki

Vsako prizadevanje strojnega učenja se začne s podatki, zato bomo začeli z razjasnitvijo strukture vhodnih in ciljnih podatkov, ki se uporabljajo med usposabljanjem in napovedovanjem. V celotnem članku bomo uporabljali tok Text2SQL s slike 1 kot našo tekočo predstavitev in označevali trenutno obravnavane komponente in razmerja z rumeno.

1.1 Oblika in struktura podatkov

Običajno je neobdelani vhodno-izhodni par Text2SQL sestavljen iz vprašanja v naravnem jeziku in ustrezne poizvedbe SQL, na primer:

Vprašanje: "Navedite ime in število sledilcev za vsakega uporabnika.”

Poizvedba SQL:

izberite ime, sledilci iz uporabniških_profilov

V podatkovnem prostoru za usposabljanje je preslikava med vprašanji in poizvedbami SQL veliko proti mnogo:

Poizvedbo SQL je mogoče preslikati v veliko različnih vprašanj v naravnem jeziku; zgornjo semantiko poizvedbe lahko na primer izrazimo z: "pokaži mi imena in število sledilcev na uporabnika""koliko sledilcev ima vsak uporabnik?Itd.
Sintaksa SQL je zelo vsestranska in skoraj vsako vprašanje je mogoče predstaviti v SQL na več načinov. Najenostavnejši primer so različni vrstni redi stavkov WHERE. Če gledamo napredneje, bo vsakdo, ki je opravil optimizacijo poizvedb SQL, vedel, da številne poti vodijo do istega rezultata, semantično enakovredne poizvedbe pa imajo lahko popolnoma drugačno sintakso.

Ročno zbiranje podatkov o usposabljanju za Text2SQL je še posebej dolgočasno. Ne zahteva le obvladovanja SQL s strani označevalca, ampak tudi več časa na primer kot bolj splošne jezikovne naloge, kot sta analiza občutkov in klasifikacija besedila. Da bi zagotovili zadostno količino primerov usposabljanja, je mogoče uporabiti razširitev podatkov - na primer, LLM-je je mogoče uporabiti za ustvarjanje parafraz za isto vprašanje. [3] nudi popolnejši pregled tehnik povečanja podatkov Text2SQL.

1.2 Obogatitev poziva z informacijami o bazi podatkov

Text2SQL je algoritem na vmesniku med nestrukturiranimi in strukturiranimi podatki. Za optimalno delovanje morata biti med usposabljanjem in napovedovanjem prisotni obe vrsti podatkov. Natančneje, algoritem mora poznati podatkovno bazo, po kateri se izvaja poizvedba, in biti sposoben oblikovati poizvedbo na tak način, da jo je mogoče izvesti proti bazi podatkov. To znanje lahko zajema:

Stolpci in tabele baze podatkov
Relacije med tabelami (tuji ključi)
Vsebina baze podatkov

Obstajata dve možnosti za vključitev znanja o bazi podatkov: po eni strani se lahko podatki o usposabljanju omejijo na primere, napisane za specifično bazo podatkov, v tem primeru se shema nauči neposredno iz poizvedbe SQL in njene preslikave v vprašanje. Ta nastavitev za eno bazo podatkov omogoča optimizacijo algoritma za posamezno bazo podatkov in/ali podjetje. Vendar pa ubija vse ambicije glede razširljivosti, saj je treba model natančno prilagoditi za vsako posamezno stranko ali bazo podatkov. Druga možnost je, da se v nastavitvah z več zbirkami podatkov shema baze podatkov zagotovi kot del vnosa, kar algoritmu omogoča "posploševanje" na nove, še nevidene sheme baze podatkov. Čeprav se boste nujno morali odločiti za ta pristop, če želite uporabljati Text2SQL v številnih različnih bazah podatkov, ne pozabite, da zahteva precejšen hiter inženirski napor. Za vsako razumno poslovno zbirko podatkov bo vključitev vseh informacij v poziv izjemno neučinkovita in najverjetneje nemogoča zaradi omejitev dolžine poziva. Tako bi morala biti funkcija, ki je odgovorna za hitro formulacijo, dovolj pametna, da izbere podmnožico informacij o bazi podatkov, ki je najbolj »uporabna« za dano vprašanje, in to stori za potencialno nevidne baze podatkov.

Končno ima struktura baze podatkov ključno vlogo. V tistih scenarijih, kjer imate dovolj nadzora nad bazo podatkov, lahko svojemu modelu olajšate življenje tako, da mu dovolite, da se uči iz intuitivne strukture. Praviloma velja, da bolj ko vaša zbirka podatkov odraža, kako poslovni uporabniki govorijo o podjetju, bolje in hitreje se lahko vaš model iz nje uči. Zato razmislite o uporabi dodatnih transformacij za podatke, kot je sestavljanje normaliziranih ali drugače razpršenih podatkov v široke tabele ali podatkovni trezor, poimenovanje tabel in stolpcev na ekspliciten in nedvoumen način itd. Vse poslovno znanje, ki ga lahko kodirate vnaprej, bo zmanjšalo breme verjetnostnega učenja na vašem modelu in vam pomaga doseči boljše rezultate.

2. algoritem

Text2SQL je vrsta pomensko razčlenjevanje — preslikavo besedil v logične predstavitve. Tako se mora algoritem ne samo "naučiti" naravnega jezika, ampak tudi ciljno predstavitev - v našem primeru SQL. Natančneje, pridobiti mora naslednje delce znanja:

Sintaksa in semantika SQL
Struktura baze podatkov
Razumevanje naravnega jezika (NLU)
Preslikava med naravnim jezikom in poizvedbami SQL (sintaktične, leksikalne in semantične)

2.1 Reševanje jezikovne variabilnosti vnosa

Pri vnosu je glavni izziv Text2SQL v prilagodljivosti jezika: kot je opisano v razdelku Oblika in struktura podatkov, je isto vprašanje mogoče parafrazirati na veliko različnih načinov. Poleg tega se moramo v pogovornem kontekstu v resničnem življenju soočiti s številnimi težavami, kot so črkovalne in slovnične napake, nepopolni in dvoumni vnosi, večjezični vnosi itd.

LLM-ji, kot so modeli GPT, T5 in CodeX, se vse bolj približujejo rešitvi tega izziva. Ob učenju iz ogromnih količin raznovrstnega besedila se naučijo spopadati z velikim številom jezikovnih vzorcev in nepravilnosti. Na koncu postanejo sposobni posploševati vprašanja, ki so si pomensko podobna, čeprav imajo različne površinske oblike. LLM-je je mogoče uporabiti takoj po namestitvi (zero-shot) ali po natančni nastavitvi. Prvo, čeprav je priročno, vodi do nižje natančnosti. Slednje zahteva več spretnosti in dela, vendar lahko bistveno poveča natančnost.

Kar zadeva natančnost, so po pričakovanjih najuspešnejši modeli najnovejši modeli družine GPT, vključno z modeli CodeX. Aprila 2023 je GPT-4 vodil do dramatičnega povečanja natančnosti za več kot 5 % v primerjavi s prejšnjim stanjem tehnike in dosegel natančnost 85.3 % (pri metriki »izvedba z vrednostmi«). [4] V odprtokodnem taboru so bili začetni poskusi reševanja uganke Text2SQL osredotočeni na modele samodejnega kodiranja, kot je BERT, ki blesti pri nalogah NLU.[5, 6, 7] Vendar pa se sredi navdušenja okoli generativne umetne inteligence osredotočajo novejši pristopi na avtoregresivnih modelih, kot je model T5. T5 je vnaprej usposobljen z uporabo večopravilnega učenja in se tako enostavno prilagaja novim jezikovnim nalogam, vklj. različne variante pomenskega razčlenjevanja. Vendar pa imajo avtoregresivni modeli notranjo napako, ko gre za naloge semantičnega razčlenjevanja: imajo neomejen izhodni prostor in nimajo semantičnih ograj, ki bi omejevale njihov izhod, kar pomeni, da so lahko pri svojem vedenju osupljivo ustvarjalni. Čeprav je to neverjetna stvar za ustvarjanje vsebine v prosti obliki, je moteča za naloge, kot je Text2SQL, kjer pričakujemo omejen, dobro strukturiran ciljni rezultat.

2.2 Preverjanje in izboljšanje poizvedbe

Za omejitev izhoda LLM lahko uvedemo dodatne mehanizme za preverjanje in izboljšanje poizvedbe. To je mogoče izvesti kot dodatni korak validacije, kot je predlagano v sistemu PICARD.[8] PICARD uporablja razčlenjevalnik SQL, ki lahko preveri, ali lahko delna poizvedba SQL vodi do veljavne poizvedbe SQL po zaključku. Pri vsakem koraku generiranja s strani LLM so žetoni, ki bi razveljavili poizvedbo, zavrnjeni, obdržijo pa se veljavni žetoni z največjo verjetnostjo. Ker je determinističen, ta pristop zagotavlja 100-odstotno veljavnost SQL, dokler razčlenjevalnik upošteva pravilna pravila SQL. Prav tako loči validacijo poizvedbe od generiranja, kar omogoča vzdrževanje obeh komponent neodvisno ena od druge ter nadgradnjo in spreminjanje LLM.

Drugi pristop je vključitev strukturnega znanja in znanja SQL neposredno v LLM. Graphix [9] na primer uporablja plasti, ki se zavedajo grafov, da vnese strukturirano znanje SQL v model T5. Zaradi verjetnostne narave tega pristopa nagiba sistem k pravilnim poizvedbam, vendar ne daje jamstva za uspeh.

Končno se LLM lahko uporablja kot večstopenjski agent, ki lahko samostojno preveri in izboljša poizvedbo.[10] Z uporabo več korakov v pozivu za zaporedje misli se lahko agentu naroči, da razmisli o pravilnosti lastnih poizvedb in izboljša morebitne pomanjkljivosti. Če potrjene poizvedbe še vedno ni mogoče izvesti, se lahko povratno sledenje izjeme SQL posreduje posredniku kot dodatna povratna informacija za izboljšanje.

Poleg teh avtomatiziranih metod, ki se izvajajo v ozadju, je možno tudi vključiti uporabnika med postopkom preverjanja poizvedbe. To bomo podrobneje opisali v poglavju Uporabniška izkušnja.

2.3 Vrednotenje

Za ovrednotenje našega algoritma Text2SQL moramo ustvariti testni (validacijski) nabor podatkov, zagnati naš algoritem na njem in za rezultat uporabiti ustrezne metrike vrednotenja. Naivni nabor podatkov, razdeljen na podatke za usposabljanje, razvoj in validacijo, bi temeljil na parih vprašanje-poizvedba in vodil do neoptimalnih rezultatov. Poizvedbe za preverjanje veljavnosti se lahko modelu razkrijejo med usposabljanjem in vodijo do preveč optimističnega pogleda na njegove sposobnosti posploševanja. A razdelitev na podlagi poizvedbe, kjer je nabor podatkov razdeljen na tak način, da se nobena poizvedba ne prikaže tako med usposabljanjem kot med preverjanjem, zagotavlja bolj resnične rezultate.

Kar zadeva metriko ocenjevanja, tisto, kar nas zanima v Text2SQL, ni ustvarjanje poizvedb, ki so popolnoma enake zlatemu standardu. to »natančno ujemanje niza« metoda je prestroga in bo ustvarila veliko napačno negativnih rezultatov, saj lahko različne poizvedbe SQL vodijo do istega vrnjenega nabora podatkov. Namesto tega želimo doseči visoko pomenska natančnost in oceniti, ali bodo predvidene poizvedbe in poizvedbe »zlati standard« vedno vrnile iste nize podatkov. Obstajajo tri metrike vrednotenja, ki se približajo temu cilju:

Natančna natančnost ujemanja: ustvarjene in ciljne poizvedbe SQL so razdeljene na svoje sestavne dele, dobljeni nizi pa se primerjajo glede identitete.[11] Pomanjkljivost pri tem je, da upošteva le variacije vrstnega reda v poizvedbi SQL, ne pa tudi izrazitejših sintaktičnih razlik med pomensko enakovrednimi poizvedbami.
Natančnost izvedbe: nabori podatkov, ki izhajajo iz ustvarjenih in ciljnih poizvedb SQL, se primerjajo glede identitete. Z veliko sreče lahko poizvedbe z drugačno semantiko še vedno prestanejo ta preizkus na določenem primerku zbirke podatkov. Če na primer predpostavimo zbirko podatkov, kjer so vsi uporabniki starejši od 30 let, bi naslednji dve poizvedbi vrnili enake rezultate kljub različni semantiki:
izberite * od uporabnika
izberite * pri uporabniku, starejšem od 30 let
Natančnost testne zbirke: natančnost testne zbirke je naprednejša in manj permisivna različica natančnosti izvajanja. Za vsako poizvedbo se ustvari nabor ("testna zbirka") baz podatkov, ki so zelo različne glede na spremenljivke, pogoje in vrednosti v poizvedbi. Nato se na vsaki od teh baz podatkov testira natančnost izvajanja. Ta metrika sicer zahteva dodatne napore za načrtovanje generiranja testne zbirke, hkrati pa bistveno zmanjša tveganje lažno pozitivnih rezultatov pri vrednotenju..[12]

3. Uporabniška izkušnja

Trenutno stanje tehnike Text2SQL ne omogoča povsem brezhibne integracije v produkcijske sisteme, temveč je potrebno aktivno upravljanje s pričakovanji in obnašanjem uporabnika, ki se mora vedno zavedati, da je v interakciji z sistem AI.

3.1 Obvladovanje napak

Text2SQL lahko odpove v dveh načinih, ki ju je treba ujeti na različne načine:

Napake SQL: ustvarjena poizvedba ni veljavna — ali je SQL neveljaven ali pa ga zaradi leksikalnih ali semantičnih napak ni mogoče izvesti v določeni bazi podatkov. V tem primeru uporabniku ni mogoče vrniti nobenega rezultata.
Semantične napake: ustvarjena poizvedba je veljavna, vendar ne odraža semantike vprašanja, kar vodi do napačnega vrnjenega nabora podatkov.

Drugi način je še posebej težaven, saj je tveganje za "tihe napake" - napake, ki jih uporabnik ne zazna - visoko. Prototipni uporabnik ne bo imel niti časa niti tehničnega znanja, da bi preveril pravilnost poizvedbe in/ali pridobljenih podatkov. Ko se podatki uporabljajo za sprejemanje odločitev v resničnem svetu, ima lahko ta vrsta napake uničujoče posledice. Da bi se temu izognili, je ključnega pomena izobraževanje uporabnikov in vzpostavitev zaščitne ograje na poslovni ravni ki omejujejo potencialni vpliv, kot so dodatna preverjanja podatkov za odločitve z večjim vplivom. Po drugi strani pa lahko uporabniški vmesnik uporabljamo tudi za upravljanje interakcije človek-stroj in uporabniku pomagamo odkriti in izboljšati problematične zahteve.

3.2 Interakcija človek-stroj

Uporabniki se lahko vključijo v vaš sistem AI z različnimi stopnjami intenzivnosti. Več interakcije na zahtevo lahko vodi do boljših rezultatov, vendar tudi upočasni pretočnost uporabniške izkušnje. Poleg morebitnega negativnega vpliva napačnih poizvedb in rezultatov razmislite tudi o tem, kako motivirani bodo vaši uporabniki za zagotavljanje povratnih informacij naprej in nazaj, da bi dobili natančnejše rezultate in dolgoročno pomagali izboljšati izdelek.

Najlažji in najmanj zanimiv način je delo z rezultati zaupanja. Čeprav je naiven izračun zaupanja kot povprečja verjetnosti ustvarjenih žetonov preveč poenostavljen, je mogoče uporabiti naprednejše metode, kot je verbalizirana povratna informacija. [13] Zaupanje je mogoče prikazati v vmesniku in poudariti z izrecnim opozorilom, če je nevarno nizko. Tako odgovornost za ustrezno spremljanje v »resničnem svetu« – pa naj gre za zavrnitev, sprejem ali dodatno preverjanje podatkov – pristane na ramenih vašega uporabnika. Čeprav je to za vas kot prodajalca varna stava, lahko prenos tega dela na uporabnika tudi zmanjša vrednost vašega izdelka.

Druga možnost je vključitev uporabnika v dialog za pojasnjevanje v primeru poizvedb z nizko stopnjo zaupanja, dvoumnih ali kako drugače sumljivih poizvedb. Vaš sistem lahko na primer predlaga ortografske ali slovnične popravke vnosa in zahteva razločitev določenih besed ali slovničnih struktur. Uporabniku lahko tudi omogoči, da proaktivno zahteva popravke v poizvedbi: [14]

UPORABNIK: Pokaži mi Johnove naloge v tem sprintu.

POMOČNIK: Bi radi videli naloge, ki jih je ustvaril John, ali tiste, na katerih dela?

UPORABNIK: opravil, ki jih je ustvaril John

POMOČNIK: Ok, tukaj so ID-ji nalog:

UPORABNIK: Hvala, rad bi tudi videl več informacij o nalogah. Razvrstite tudi po nujnosti.

POMOČNIK: Seveda, tukaj so naloge skupaj s kratkimi opisi, osebami in roki, razvrščene po rokih.

Končno, za lažje razumevanje poizvedb s strani uporabnika, lahko vaš sistem zagotovi tudi eksplicitno besedilno preoblikovanje poizvedbe in prosi uporabnika, da jo potrdi ali popravi.[15]

4. Nefunkcionalne zahteve

V tem razdelku razpravljamo o posebnih nefunkcionalnih zahtevah za Text2SQL kot tudi o kompromisih med njimi. Osredotočili se bomo na šest zahtev, ki se zdijo najpomembnejše za nalogo: točnost, razširljivost, hitrost, razložljivost, zasebnost in prilagodljivost skozi čas.

4.1 Natančnost

Za Text2SQL so zahteve glede natančnosti visoke. Prvič, Text2SQL se običajno uporablja v nastavitvi pogovora, kjer se predvidevanja izvajajo eno za drugo. Tako "zakon velikih števil", ki običajno pomaga uravnotežiti napako v skupinskih napovedih, ne pomaga. Drugič, skladenjska in leksikalna veljavnost je "težek" pogoj: model mora ustvariti dobro oblikovano poizvedbo SQL, ki ima lahko zapleteno sintakso in semantiko, sicer zahteve ni mogoče izvesti proti bazi podatkov. In če gre to dobro in je poizvedbo mogoče izvesti, lahko še vedno vsebuje semantične napake in vodi do napačnega vrnjenega nabora podatkov (glej razdelek 3.1 Upravljanje napak).

4.2 Razširljivost

Glavni premisleki glede razširljivosti so, ali želite uporabiti Text2SQL v eni ali več bazah podatkov – in v slednjem primeru, ali je niz baz podatkov znan in zaprt. Če da, vam bo lažje, saj lahko informacije o teh zbirkah podatkov vključite med usposabljanje. Vendar pa se mora v scenariju razširljivega izdelka – naj bo to samostojna aplikacija Text2SQL ali integracija v obstoječi podatkovni izdelek – vaš algoritem sproti spopadati s katero koli novo shemo baze podatkov. Ta scenarij vam prav tako ne daje možnosti za preoblikovanje strukture baze podatkov, da bi bila bolj intuitivna za učenje (povezava!). Vse to vodi do velikega kompromisa z natančnostjo, kar lahko tudi pojasni, zakaj trenutni ponudniki Text2SQL, ki ponujajo ad hoc poizvedovanje po novih bazah podatkov, še niso dosegli pomembnega prodora na trg.

Hitrost 4.3

Ker bodo zahteve Text2SQL običajno obdelane prek spleta v pogovoru, je vidik hitrosti pomemben za zadovoljstvo uporabnikov. Pozitivno je, da se uporabniki pogosto zavedajo, da lahko zahteve po podatkih trajajo nekaj časa, in pokažejo potrebno potrpežljivost. Vendar pa lahko to dobro voljo spodkoplje nastavitev klepeta, kjer uporabniki podzavestno pričakujejo človeško hitrost pogovora. Metode optimizacije na silo, kot je zmanjšanje velikosti modela, bi lahko imele nesprejemljiv vpliv na natančnost, zato razmislite o optimizaciji sklepanja, da bi zadovoljili to pričakovanje.

4.4 Razložljivost in preglednost

V idealnem primeru lahko uporabnik spremlja, kako je bila poizvedba ustvarjena iz besedila, vidi preslikavo med določenimi besedami ali izrazi v vprašanju in poizvedbo SQL itd. To omogoča preverjanje poizvedbe in morebitne prilagoditve pri interakciji s sistemom . Poleg tega lahko sistem zagotovi tudi eksplicitno besedilno preoblikovanje poizvedbe in od uporabnika zahteva, da jo potrdi ali popravi.

Zasebnost 4.5

Funkcijo Text2SQL je mogoče izolirati od izvajanja poizvedbe, tako da lahko vrnjene informacije o bazi podatkov ostanejo nevidne. Vendar pa je kritično vprašanje, koliko informacij o bazi podatkov je vključenih v poziv. Tri možnosti (z znižanjem ravni zasebnosti) so:

Ni podatka
Shema zbirke podatkov
Vsebina baze podatkov

Zasebnost je v nasprotju z natančnostjo – manj kot ste omejeni pri vključevanju koristnih informacij v poziv, boljši so rezultati.

4.6 Prilagodljivost skozi čas

Če želite uporabljati Text2SQL na trajen način, se morate prilagoditi premikanju podatkov, tj. spreminjajoči se porazdelitvi podatkov, za katere je uporabljen model. Na primer, predpostavimo, da podatki, uporabljeni za začetno natančno nastavitev, odražajo preprosto poizvedovalno vedenje uporabnikov, ko začnejo uporabljati sistem BI. S časom postajajo informacijske potrebe uporabnikov vse bolj sofisticirane in zahtevajo kompleksnejše poizvedbe, ki preobremenijo vaš naivni model. Poleg tega se lahko cilji ali strategija podjetja spremenijo in usmerijo potrebe po informacijah na druga področja baze podatkov. Nazadnje, izziv, specifičen za Text2SQL, je premikanje baze podatkov. Ko se baza podatkov podjetja razširi, se novi, nevidni stolpci in tabele prebijejo v poziv. Čeprav lahko algoritmi Text2SQL, ki so zasnovani za aplikacije z več zbirkami podatkov, dobro rešijo to težavo, lahko znatno vpliva na natančnost modela z eno bazo podatkov. Vse te težave je najbolje rešiti z naborom podatkov za natančno nastavitev, ki odraža trenutno vedenje uporabnikov v resničnem svetu. Zato je ključnega pomena, da zabeležite vprašanja in rezultate uporabnikov ter vse povezane povratne informacije, ki jih je mogoče zbrati pri uporabi. Poleg tega je mogoče uporabiti algoritme semantičnega združevanja v gruče, na primer z uporabo vdelav ali modeliranja tem, za odkrivanje temeljnih dolgoročnih sprememb v vedenju uporabnikov in jih uporabiti kot dodaten vir informacij za izpopolnjevanje vašega nabora podatkov za natančno nastavitev

zaključek

Povzemimo ključne točke članka:

Text2SQL omogoča implementacijo intuitivnega in demokratičnega dostopa do podatkov v podjetju, s čimer se poveča vrednost razpoložljivih podatkov.
Podatki Text2SQL so sestavljeni iz vprašanj na vhodu in poizvedb SQL na izhodu. Preslikava med vprašanji in poizvedbami SQL je veliko proti mnogo.
Pomembno je, da podate informacije o zbirki podatkov kot del poziva. Poleg tega je mogoče strukturo baze podatkov optimizirati, da se algoritem lažje nauči in razume.
Pri vnosu je glavni izziv jezikovna variabilnost vprašanj v naravnem jeziku, ki se ji lahko približajo z uporabo LLM-jev, ki so bili predhodno usposobljeni za široko paleto različnih slogov besedila.
Rezultat Text2SQL mora biti veljavna poizvedba SQL. To omejitev je mogoče vključiti z "vbrizgavanjem" znanja SQL v algoritem; alternativno pa je mogoče z uporabo iterativnega pristopa poizvedbo preveriti in izboljšati v več korakih.
Zaradi potencialno velikega vpliva "tihih napak", ki vrnejo napačne podatke za odločanje, je upravljanje napak glavna skrb v uporabniškem vmesniku.
Na "razširjen" način so lahko uporabniki aktivno vključeni v iterativno preverjanje in izboljšanje poizvedb SQL. Čeprav zaradi tega postane aplikacija manj tekoča, zmanjša tudi stopnje napak, uporabnikom omogoča bolj prilagodljivo raziskovanje podatkov in ustvarja dragocene signale za nadaljnje učenje.
Glavne nefunkcionalne zahteve, ki jih je treba upoštevati, so natančnost, razširljivost, hitrost, razložljivost, zasebnost in prilagodljivost skozi čas. Glavni kompromisi so med natančnostjo na eni strani ter razširljivostjo, hitrostjo in zasebnostjo na drugi strani.