Tietoreunan luominen keskusteluyhteydellä dataan

Julkaissut Platon

seuraajia: 0

keskustelullinen tekoäly tietojen analysointiin

Kuva 1: Text2SQL-vuon esitys

Maailmamme muuttuessa globaalimmaksi ja dynaamisemmaksi, yritykset ovat yhä enemmän riippuvaisia tiedoista tehdäkseen tietoisia, objektiivisia ja oikea-aikaisia päätöksiä. Tästä lähtien organisaatiodatan täyden potentiaalin vapauttaminen on kuitenkin usein kourallisen datatieteilijöiden ja analyytikoiden etuoikeus. Useimmat työntekijät eivät hallitse tavanomaista datatieteen työkalupakkia (SQL, Python, R jne.). Päästäkseen haluttuun dataan ne menevät ylimääräisen kerroksen kautta, jossa analyytikot tai BI-tiimit "kääntävät" liiketoimintakysymysten proosan datan kielelle. Tällä matkalla kitkan ja tehottomuuden mahdollisuus on suuri – esimerkiksi tiedot voidaan toimittaa viiveellä tai jopa silloin, kun kysymys on jo vanhentunut. Tieto saattaa kadota matkan varrella, jos vaatimuksia ei käännetä tarkasti analyyttisiksi kyselyiksi. Lisäksi korkealaatuisten oivallusten luominen vaatii iteratiivista lähestymistapaa, jota ei suositella silmukan jokaisessa lisävaiheessa. Toisaalta nämä ad hoc -vuorovaikutukset häiritsevät kalliita datakykyjä ja häiritsevät heitä strategisemmasta datatyöstä, kuten näissä datatieteilijän "tunnustuksissa" kuvataan:

Kun olin Squarella ja tiimi oli pienempi, meillä oli pelätty "analytiikan päivystys" -kierto. Sitä vaihdettiin tiukasti viikoittain, ja jos tulit esiin, tiesit saavasi hyvin vähän "oikeaa" työtä tehtyä sillä viikolla ja vietät suurimman osan ajasta vastaamalla ad hoc -kysymyksiin eri tuote- ja toimintatiimeiltä. yritys (SQL-apina, me kutsuimme sitä). Analytiikkatiimin johtajarooleista käytiin kova kilpailu, ja uskon, että tämä johtui täysin siitä, että johtajat vapautettiin tästä vuorottelusta – mikään statuspalkinto ei voinut kilpailla päivystystyön tekemättä jättämisen kanssa.[1]

Eikö olisikin siistiä puhua suoraan tietojesi kanssa sen sijaan, että joutuisit käymään läpi useita vuorovaikutuskierroksia tietohenkilöstösi kanssa? Tätä visiota omaksuvat keskustelurajapinnat, joiden avulla ihmiset voivat olla vuorovaikutuksessa tiedon kanssa käyttämällä kieltä, joka on intuitiivisin ja yleismaailmallisin viestintäkanavamme. Kun kysymys on jäsennetty, algoritmi koodaa sen jäsenneltyyn loogiseen muotoon valitulla kyselykielellä, kuten SQL. Siten ei-tekniset käyttäjät voivat keskustella tietojensa kanssa ja saada nopeasti käsiinsä erityisiä, olennaisia ja ajankohtaisia tietoja ilman, että heidän tarvitsee tehdä kiertotietä BI-tiimin kautta. Tässä artikkelissa tarkastelemme Text2SQL:n eri toteutusnäkökohtia ja keskitymme nykyaikaisiin lähestymistapoihin, joissa käytetään suuria kielimalleja (LLM), jotka saavuttavat parhaan suorituskyvyn tällä hetkellä (vrt. [2]; vaihtoehtoisten lähestymistapojen kyselyyn LLM:iden lisäksi lukijoihin viitataan [3]). Artikkeli on rakennettu seuraavan "mentaalisen mallin" mukaan, joka sisältää pääelementtejä, jotka on otettava huomioon suunniteltaessa ja rakennettaessa tekoälyominaisuutta:

keskustelullinen tekoäly tietojen analysointiin — Kuva 2: Tekoälyominaisuuden henkinen malli

Aloitetaan lopusta ja kerrotaan arvo – miksi sinun pitäisi rakentaa Text2SQL-ominaisuus tieto- tai analytiikkatuotteeseesi. Kolme tärkeintä etua ovat:

Yrityskäyttäjät pääsevät käsiksi organisaatiotietoihin suoraan ja oikea-aikaisesti.
Tämä helpottaa datatieteilijät ja analyytikot yrityskäyttäjien ad hoc -pyyntöjen taakasta ja antaa heille mahdollisuuden keskittyä edistyneisiin datahaasteisiin.
Tämä sallii liiketoiminta hyödyntää tietojaan sulavammalla ja strategisemmalla tavalla ja tehdä niistä lopulta vankan perustan päätöksenteolle.

Mitkä ovat ne tuoteskenaariot, joissa voit harkita Text2SQL:ää? Kolme pääasetusta ovat:

Tarjoat a skaalautuva data/BI-tuote ja haluavat antaa useammalle käyttäjälle pääsyn tietoihinsa ei-teknisellä tavalla, mikä lisää sekä käyttöä että käyttäjäkuntaa. Esimerkiksi ServiceNow on integroi tietokyselyt laajempaan keskustelutarjontaanja Atlan on äskettäin ilmoitti luonnollisen kielen datan etsinnästä.
Aiot rakentaa jotain data-/AI-avaruuteen demokratisoidaksesi tietojen saatavuuden yrityksissä, jolloin voit mahdollisesti harkita MVP, jonka ytimessä on Text2SQL. Palveluntarjoajat pitävät AI2SQL ja Text2sql.ai ovat jo tekemässä sisäänkäyntiä tähän tilaan.
Työskentelet parissa a mukautettu BI-järjestelmä ja haluavat maksimoida ja demokratisoida sen käytön yksittäisessä yrityksessä.

Kuten seuraavissa osissa näemme, Text2SQL vaatii ei-triviaalin ennakkoasennuksen. ROI:n arvioimiseksi harkitse tuettavien päätösten luonnetta sekä saatavilla olevia tietoja. Text2SQL voi olla ehdoton voitto dynaamisissa ympäristöissä, joissa data muuttuu nopeasti ja sitä käytetään aktiivisesti ja usein päätöksenteossa, kuten investoinnissa, markkinoinnissa, valmistuksessa ja energiateollisuudessa. Näissä ympäristöissä perinteiset tiedonhallinnan työkalut ovat liian staattisia, ja sujuvammat tavat saada tietoa ja tietoa auttavat yrityksiä luomaan kilpailuetua. Tietojen suhteen Text2SQL tarjoaa suurimman arvon tietokannassa, joka on:

Iso ja kasvava, jotta Text2SQL voi paljastaa arvonsa ajan myötä, kun yhä enemmän dataa hyödynnetään.
Laadukas, jotta Text2SQL-algoritmin ei tarvitse käsitellä liiallista kohinaa (epäjohdonmukaisuudet, tyhjät arvot jne.) tiedoissa. Yleensä sovellusten automaattisesti luoma data on laadukkaampaa ja johdonmukaisempaa kuin ihmisten luoma ja ylläpitämä data.
Semanttisesti kypsä päinvastoin kuin raaka, jotta ihmiset voivat kysellä dataa henkisen mallinsa keskeisten käsitteiden, suhteiden ja mittareiden perusteella. Huomaa, että semanttinen kypsyys voidaan saavuttaa lisämuunnosvaiheella, joka mukauttaa raakadatan käsitteelliseksi rakenteeksi (vrt. osio "Kehotteen rikastaminen tietokantatiedoilla").

Seuraavassa sukeltamme syvällisesti Text2SQL-ominaisuuden tietoihin, algoritmeihin, käyttökokemukseen sekä asiaankuuluviin ei-toiminnallisiin vaatimuksiin. Artikkeli on kirjoitettu tuotepäälliköille, UX-suunnittelijoille ja niille datatieteilijöille ja insinööreille, jotka ovat Text2SQL-matkansa alussa. Näille ihmisille se tarjoaa paitsi oppaan alkuun pääsemiseen, myös yhteisen tietopohjan keskustelua varten tuotteen, teknologian ja liiketoiminnan rajapinnoista, mukaan lukien niihin liittyvät kompromissit. Jos olet jo edistyneempi toteuttamisessasi, lopussa olevat viitteet tarjoavat joukon syvällisiä sukelluksia tutkittavaksi.

Jos tästä perusteellisesta opetussisällöstä on hyötyä sinulle, voit tilaa AI-tutkimuksen postituslista hälytys, kun julkaisemme uutta materiaalia.

1. data

Kaikki koneoppimispyrkimykset alkavat tiedoista, joten aloitamme selventämällä koulutuksen ja ennustamisen aikana käytettävän syöttö- ja tavoitedatan rakennetta. Koko artikkelin ajan käytämme kuvan 2 Text1SQL-kulkua juoksevana esityksenä ja korostamme tällä hetkellä tarkasteltavat komponentit ja suhteet keltaisella.

1.1 Tietojen muoto ja rakenne

Tyypillisesti raaka Text2SQL-syöttö-tulospari koostuu luonnollisen kielen kysymyksestä ja vastaavasta SQL-kyselystä, esimerkiksi:

Kysymys: "Listaa kunkin käyttäjän nimi ja seuraajien lukumäärä."

SQL-kysely:

valitse nimi, seuraajat käyttäjäprofiileista

Harjoitteludata-avaruudessa kysymysten ja SQL-kyselyiden välinen kartoitus on monta-moneen:

SQL-kysely voidaan kartoittaa moniin erilaisiin kysymyksiin luonnollisella kielellä; esimerkiksi yllä oleva kyselyn semantiikka voidaan ilmaista seuraavasti: "näytä minulle seuraajien nimet ja määrät käyttäjää kohti","kuinka monta seuraajaa kullakin käyttäjällä on?" jne.
SQL-syntaksi on erittäin monipuolinen, ja lähes jokainen kysymys voidaan esittää SQL:ssä useilla tavoilla. Yksinkertaisin esimerkki ovat WHERE-lauseiden erilaiset järjestykset. Edistyneemmällä asenteella jokainen, joka on tehnyt SQL-kyselyn optimoinnin, tietää, että monet tiet johtavat samaan tulokseen ja semanttisesti vastaavilla kyselyillä voi olla täysin erilainen syntaksi.

Harjoitustietojen manuaalinen kerääminen Text2SQL:lle on erityisen työlästä. Se ei vaadi vain SQL-hallintaa annotaattorilta, vaan myös enemmän aikaa esimerkkiä kohden kuin yleisemmät kielelliset tehtävät, kuten tunteiden analysointi ja tekstin luokittelu. Jotta varmistetaan riittävä määrä koulutusesimerkkejä, voidaan käyttää tietojen lisäystä – esimerkiksi LLM:itä voidaan käyttää parafraasien luomiseen samalle kysymykselle. [3] tarjoaa kattavamman katsauksen Text2SQL-tietojen lisäystekniikoista.

1.2 Kehotteen rikastaminen tietokantatiedoilla

Text2SQL on algoritmi jäsentämättömän ja strukturoidun tiedon rajapinnassa. Parhaan suorituskyvyn saavuttamiseksi molempien tietojen on oltava läsnä harjoittelun ja ennustamisen aikana. Tarkemmin sanottuna algoritmin on tunnettava haettava tietokanta ja kyettävä muotoilemaan kysely siten, että se voidaan suorittaa tietokantaa vastaan. Tämä tieto voi sisältää:

Tietokannan sarakkeet ja taulukot
Taulukoiden väliset suhteet (vieraat avaimet)
Tietokannan sisältö

Tietokantatietojen sisällyttämiseen on kaksi vaihtoehtoa: toisaalta opetusdata voidaan rajoittaa tiettyä tietokantaa varten kirjoitettuihin esimerkkeihin, jolloin skeema opitaan suoraan SQL-kyselystä ja sen yhdistämisestä kysymykseen. Tämä yhden tietokannan asetus mahdollistaa yksittäisen tietokannan ja/tai yrityksen algoritmin optimoinnin. Se kuitenkin tappaa kaikki skaalautuvuustavoitteet, koska mallia on hienosäädettävä jokaista asiakasta tai tietokantaa varten. Vaihtoehtoisesti usean tietokannan asetuksissa tietokantaskeema voidaan tarjota osana syötettä, jolloin algoritmi voi "yleistää" uusiksi, näkymättömiksi tietokantaskeemoiksi. Vaikka sinun on ehdottomasti valittava tämä lähestymistapa, jos haluat käyttää Text2SQL:ää monissa erilaisissa tietokannoissa, muista, että se vaatii huomattavaa nopeaa suunnittelutyötä. Kaiken järkevän yritystietokannan osalta täydellisten tietojen sisällyttäminen kehotteeseen on erittäin tehotonta ja todennäköisesti mahdotonta kehotteen pituusrajoitusten vuoksi. Näin ollen nopeasta muotoilusta vastaavan toiminnon tulisi olla tarpeeksi älykäs valitsemaan tietokantatietojen osajoukko, joka on "hyödyllisin" tietylle kysymykselle, ja tehdä tämä mahdollisesti näkymättömille tietokannoille.

Lopuksi tietokannan rakenteella on ratkaiseva rooli. Niissä skenaarioissa, joissa sinulla on riittävästi hallintaa tietokannassa, voit helpottaa mallisi elämää antamalla sen oppia intuitiivisesta rakenteesta. Nyrkkisääntönä on, että mitä enemmän tietokanta heijastaa sitä, kuinka yrityskäyttäjät puhuvat yrityksestä, sitä paremmin ja nopeammin mallisi voi oppia siitä. Harkitse siis lisämuunnosten soveltamista tietoihin, kuten normalisoitujen tai muuten hajallaan olevien tietojen kokoamista leveiksi taulukoiksi tai tietovarastoon, taulukoiden ja sarakkeiden nimeämistä selkeällä ja yksiselitteisellä tavalla jne. Kaikki etukäteen koodattava liiketoimintatieto vähentää todennäköisyyspohjaisen oppimisen taakka mallillesi ja auttaa sinua saavuttamaan parempia tuloksia.

2. Algoritmi

Text2SQL on eräänlainen semanttinen jäsennys — tekstien yhdistäminen loogisiin esityksiin. Siten algoritmin ei tarvitse "opetella" vain luonnollista kieltä, vaan myös kohdeesitystä - meidän tapauksessamme SQL:ää. Erityisesti sen on hankittava seuraavat tiedot:

SQL-syntaksi ja semantiikka
Tietokannan rakenne
Luonnollisen kielen ymmärtäminen (NLU)
Mappaus luonnollisen kielen ja SQL-kyselyjen välillä (syntaktinen, leksikaalinen ja semanttinen)

2.1 Syötteen kielellisen vaihtelun ratkaiseminen

Syöttössä Text2SQL:n suurin haaste on kielen joustavuus: kuten kohdassa Tiedon muoto ja rakenne on kuvattu, sama kysymys voidaan muotoilla monella eri tavalla. Lisäksi tosielämän keskustelukontekstissa meidän on käsiteltävä useita ongelmia, kuten kirjoitus- ja kielioppivirheitä, epätäydellisiä ja moniselitteisiä syötteitä, monikielisiä syötteitä jne.

LLM:t, kuten GPT-mallit, T5 ja CodeX, ovat tulossa yhä lähemmäs tämän haasteen ratkaisemista. Oppiessaan valtavasta määrästä monipuolista tekstiä he oppivat käsittelemään monia kielellisiä malleja ja epäsäännöllisyyksiä. Lopulta he pystyvät yleistämään kysymyksiä, jotka ovat semanttisesti samanlaisia huolimatta erilaisista pintamuodoista. LLM:itä voidaan käyttää heti (nolla-shot) tai hienosäädön jälkeen. Edellinen, vaikka se on kätevä, johtaa alhaisempaan tarkkuuteen. Jälkimmäinen vaatii enemmän taitoa ja työtä, mutta voi parantaa merkittävästi tarkkuutta.

Tarkkuuden suhteen, kuten odotettiin, parhaiten suoriutuvat mallit ovat GPT-perheen uusimmat mallit CodeX-mallit mukaan lukien. Huhtikuussa 2023 GPT-4 johti dramaattiseen, yli 5 %:n tarkkuuteen verrattuna aiempaan huipputekniikkaan ja saavutti 85.3 %:n tarkkuuden (mittarissa "suoritus arvojen kanssa").[4] Avoimen lähdekoodin leirissä ensimmäiset yritykset ratkaista Text2SQL-pulma keskittyivät automaattisiin koodausmalleihin, kuten BERT, jotka ovat loistavia NLU-tehtävissä.[5, 6, 7] Kuitenkin generatiivisen tekoälyn ympärillä olevan hypetyksen keskellä viimeaikaiset lähestymistavat keskittyvät. autoregressiivisissä malleissa, kuten T5-mallissa. T5 on esikoulutettu monitehtäväoppimisen avulla ja mukautuu siten helposti uusiin kielellisiin tehtäviin, mm. semanttisen jäsentämisen eri muunnelmia. Autoregressiivisillä malleilla on kuitenkin luontainen puute semanttisten jäsennystehtävien suhteen: niillä on rajoittamaton tulostustila eikä semanttisia suojakaiteita, jotka rajoittaisivat niiden tulosta, mikä tarkoittaa, että ne voivat käyttäytyä hämmästyttävän luovasti. Vaikka tämä on hämmästyttävää tavaraa vapaamuotoisen sisällön luomiseen, se on haitaksi sellaisille tehtäville kuin Text2SQL, joissa odotamme rajoitettua, hyvin jäsenneltyä kohdetulostusta.

2.2 Kyselyn validointi ja parantaminen

LLM-tulostuksen rajoittamiseksi voimme ottaa käyttöön lisämekanismeja kyselyn vahvistamiseksi ja parantamiseksi. Tämä voidaan toteuttaa ylimääräisenä validointivaiheena, kuten PICARD-järjestelmässä ehdotetaan.[8] PICARD käyttää SQL-jäsentäjää, joka voi tarkistaa, voiko osittainen SQL-kysely johtaa kelvolliseen SQL-kyselyyn valmistumisen jälkeen. Jokaisessa LLM:n sukupolven vaiheessa tunnukset, jotka mitätöivät kyselyn, hylätään ja suurimman todennäköisyyden kelvolliset tunnukset säilytetään. Koska tämä lähestymistapa on deterministinen, se varmistaa 100 %:n SQL-kelpoisuuden niin kauan kuin jäsentäjä noudattaa oikeita SQL-sääntöjä. Se myös erottaa kyselyn vahvistuksen luomisesta, mikä mahdollistaa molempien komponenttien ylläpidon toisistaan riippumatta ja LLM:n päivittämisen ja muokkaamisen.

Toinen lähestymistapa on sisällyttää rakenne- ja SQL-tieto suoraan LLM:ään. Esimerkiksi Graphix [9] käyttää graafia tuntevia kerroksia strukturoidun SQL-tiedon lisäämiseen T5-malliin. Tämän lähestymistavan todennäköisyyden vuoksi se painottaa järjestelmää kohti oikeita kyselyjä, mutta ei takaa onnistumista.

Lopuksi LLM:ää voidaan käyttää monivaiheisena agenttina, joka voi itsenäisesti tarkistaa ja parantaa kyselyä.[10] Käyttämällä useita vaiheita ajatusketjun kehotteessa agentti voidaan antaa pohtimaan omien kyselyjensä oikeellisuutta ja parantamaan mahdollisia puutteita. Jos vahvistettua kyselyä ei vieläkään voida suorittaa, SQL-poikkeuksen jäljitys voidaan välittää agentille lisäpalautteena parannusta varten.

Näiden taustajärjestelmässä tapahtuvien automatisoitujen menetelmien lisäksi on myös mahdollista ottaa käyttäjä mukaan kyselyn tarkistusprosessiin. Kuvaamme tätä tarkemmin osiossa Käyttäjäkokemus.

2.3 Arviointi

Text2SQL-algoritmimme arvioimiseksi meidän on luotava testi- (validointi-) tietojoukko, suoritettava sille algoritmimme ja käytettävä tulokseen asiaankuuluvia arviointimittareita. Naivi tietojoukko, joka on jaettu koulutus-, kehitys- ja validointitietoihin, perustuisi kysymys-kysely-pareihin ja johtaisi alioptimaalisiin tuloksiin. Validointikyselyt saattavat paljastua mallille koulutuksen aikana ja johtaa liian optimistiseen näkemykseen sen yleistämistaidoista. A kyselypohjainen jako, jossa tietojoukko on jaettu siten, että kyselyä ei esiinny sekä harjoittelun että validoinnin aikana, tuottaa totuudenmukaisempia tuloksia.

Mitä tulee arviointimetriikkaan, välitämme siitä, että Text2SQL:ssä ei luoda kyselyitä, jotka ovat täysin identtisiä kultastandardin kanssa. Tämä "tarkka merkkijono" menetelmä on liian tiukka ja tuottaa monia vääriä negatiivisia, koska erilaiset SQL-kyselyt voivat johtaa samaan palautettavaan tietojoukkoon. Sen sijaan haluamme saavuttaa korkean semanttinen tarkkuus ja arvioi, palauttavatko ennustetut ja "kultastandardin" kyselyt aina samat tietojoukot. On kolme arviointimittaria, jotka vastaavat tätä tavoitetta:

Tarkka ottelutarkkuus: luodut ja kohde-SQL-kyselyt jaetaan osatekijöihin, ja tuloksena olevia joukkoja verrataan identiteetin suhteen.[11] Puute tässä on, että se ottaa huomioon vain SQL-kyselyn järjestysvaihtelut, mutta ei selvempiä syntaktisia eroja semanttisesti vastaavien kyselyjen välillä.
Suorituksen tarkkuus: luoduista ja kohde-SQL-kyselyistä saatuja tietojoukkoja verrataan identiteetin suhteen. Hyvällä tuurilla kyselyt, joilla on erilainen semantiikka, voivat silti läpäistä tämän testin tietyssä tietokantaesiintymässä. Jos esimerkiksi oletetaan, että tietokanta, jossa kaikki käyttäjät ovat yli 30-vuotiaita, seuraavat kaksi kyselyä palauttaisivat identtiset tulokset, vaikka niillä on eri semantiikka:
valitse * käyttäjältä
valitse * käyttäjältä, jonka ikä on > 30
Testisarjan tarkkuus: testisarjan tarkkuus on edistyneempi ja vähemmän salliva versio suoritustarkkuudesta. Jokaista kyselyä varten luodaan joukko ("testipaketti") tietokantoja, jotka eroavat suuresti kyselyn muuttujien, ehtojen ja arvojen suhteen. Sitten suoritustarkkuus testataan jokaisessa näistä tietokannoista. Vaikka testisarjan sukupolven suunnittelu vaatii lisäponnistuksia, tämä mittari vähentää merkittävästi myös väärien positiivisten tulosten riskiä arvioinnissa..[12]

3. Käyttäjäkokemus

Nykyinen Text2SQL:n huipputekniikka ei mahdollista täysin saumatonta integrointia tuotantojärjestelmiin – sen sijaan on välttämätöntä hallita aktiivisesti käyttäjän odotuksia ja käyttäytymistä, jonka tulee aina olla tietoinen siitä, että hän on vuorovaikutuksessa AI-järjestelmä.

3.1 Vianhallinta

Text2SQL voi epäonnistua kahdessa tilassa, jotka on pyydettävä eri tavoilla:

SQL-virheet: luotu kysely ei ole kelvollinen — joko SQL on virheellinen tai sitä ei voida suorittaa tietyssä tietokannassa leksikaalisten tai semanttisten virheiden vuoksi. Tässä tapauksessa tulosta ei voida palauttaa käyttäjälle.
Semantisia virheitä: luotu kysely on kelvollinen, mutta se ei heijasta kysymyksen semantiikkaa, mikä johtaa väärään palautettuun tietojoukkoon.

Toinen tila on erityisen hankala, koska "hiljaisten vikojen" riski - virheitä, joita käyttäjä ei huomaa - on suuri. Prototyyppikäyttäjällä ei ole aikaa eikä teknisiä taitoja tarkistaa kyselyn ja/tai tuloksena olevien tietojen oikeellisuutta. Kun dataa käytetään päätöksentekoon todellisessa maailmassa, tällaisella epäonnistumisella voi olla tuhoisia seurauksia. Tämän välttämiseksi on tärkeää kouluttaa käyttäjiä ja vakiinnuttaa suojakaiteet yritystasolla jotka rajoittavat mahdollista vaikutusta, kuten lisätietojen tarkistukset suuremman vaikutuksen omaaville päätöksille. Toisaalta voimme myös käyttää käyttöliittymää ihmisen ja koneen välisen vuorovaikutuksen hallintaan ja auttaa käyttäjää havaitsemaan ja parantamaan ongelmallisia pyyntöjä.

3.2 Ihmisen ja koneen välinen vuorovaikutus

Käyttäjät voivat osallistua tekoälyjärjestelmääsi eri intensiteetillä. Lisää vuorovaikutusta pyyntöä kohti voi johtaa parempiin tuloksiin, mutta se myös hidastaa käyttökokemuksen sujuvuutta. Virheellisten kyselyiden ja tulosten mahdollisen kielteisen vaikutuksen lisäksi harkitse myös, kuinka motivoituneita käyttäjäsi ovat antamaan edestakaisin palautetta saadakseen tarkempia tuloksia ja auttaakseen parantamaan tuotetta pitkällä aikavälillä.

Helpoin ja vähiten mukaansatempaava tapa on työskennellä luottamuspisteiden avulla. Vaikka luottamuksen naiivi laskenta luotujen merkkien todennäköisyyksien keskiarvona on liian yksinkertaista, voidaan käyttää kehittyneempiä menetelmiä, kuten sanallista palautetta. [13] Luottamus voidaan näyttää käyttöliittymässä ja korostaa selkeällä varoituksella, jos se on vaarallisen alhainen. Tällä tavalla vastuu asianmukaisesta seurannasta "todellisessa maailmassa" - oli se sitten tietojen hylkääminen, hyväksyminen tai lisätarkistus - laskeutuu käyttäjän harteille. Vaikka tämä on turvallinen veto sinulle myyjänä, tämän työn siirtäminen käyttäjälle voi myös vähentää tuotteesi arvoa.

Toinen mahdollisuus on saada käyttäjä selvennysdialogiin heikkoluottamuksellisissa, moniselitteisissä tai muuten epäilyttävissä olevissa kyselyissä. Järjestelmäsi saattaa esimerkiksi ehdottaa ortografisia tai kielioppikorjauksia syötteeseen ja pyytää erittelemään tiettyjä sanoja tai kielioppirakenteita. Sen avulla käyttäjä voi myös pyytää ennakoivasti korjauksia kyselyyn:[14]

KÄYTTÄJÄ: Näytä minulle Johnin tehtävät tässä sprintissä.

Avustaja: Haluaisitko nähdä tehtäviä, jotka John loi tai ne, joiden parissa hän työskentelee?

KÄYTTÄJÄ: Johannes loi tehtävät

Avustaja: Ok, tässä ovat tehtävätunnukset:

KÄYTTÄJÄ: Kiitos, haluaisin myös lisätietoa tehtävistä. Lajittele myös kiireellisyyden mukaan.

Avustaja: Toki tässä on tehtävät sekä lyhyet kuvaukset, toimeksiannon saajat ja määräajat määräaikojen mukaan lajiteltuina.

Lopuksi, jotta käyttäjä ymmärtäisi kyselyt helpommin, järjestelmäsi voi myös tarjota kyselylle selkeän tekstimuotoilun ja pyytää käyttäjää joko vahvistamaan tai korjaamaan sen.[15]

4. Ei-toiminnalliset vaatimukset

Tässä osiossa käsittelemme Text2SQL:n erityisiä ei-toiminnallisia vaatimuksia sekä niiden välisiä kompromisseja. Keskitymme kuuteen vaatimukseen, jotka vaikuttavat tehtävän kannalta tärkeimmiltä: tarkkuus, skaalautuvuus, nopeus, selitettävyys, yksityisyys ja mukautuvuus ajan myötä.

4.1 Tarkkuus

Text2SQL:n tarkkuusvaatimukset ovat korkeat. Ensinnäkin Text2SQL:ää käytetään yleensä keskusteluasetuksissa, joissa ennusteet tehdään yksitellen. Siten "suurten lukujen laki", joka tyypillisesti auttaa tasapainottamaan virheitä eräennusteissa, ei auta. Toiseksi syntaktinen ja leksikaalinen validiteetti on "kova" ehto: mallin on generoitava hyvin muotoiltu SQL-kysely, mahdollisesti monimutkaisen syntaksin ja semantiikan kanssa, muuten pyyntöä ei voida suorittaa tietokantaa vastaan. Ja jos tämä menee hyvin ja kysely voidaan suorittaa, se voi silti sisältää semanttisia virheitä ja johtaa väärään palautettuun tietojoukkoon (ks. kohta 3.1 Vianhallinta).

4.2 Skaalautuvuus

Tärkeimmät skaalautuvuusnäkökohdat ovat, haluatko käyttää Text2SQL:ää yhdessä vai useassa tietokannassa – ja jälkimmäisessä tapauksessa, onko tietokantajoukko tunnettu ja suljettu. Jos kyllä, sinulla on helpompaa, koska voit sisällyttää tiedot näistä tietokannoista koulutuksen aikana. Skaalautuvan tuotteen skenaariossa – olipa kyseessä sitten itsenäinen Text2SQL-sovellus tai integrointi olemassa olevaan tietotuotteeseen – algoritmisi on kuitenkin selviydyttävä lennossa minkä tahansa uuden tietokantaskeeman kanssa. Tämä skenaario ei myöskään anna sinulle mahdollisuutta muuttaa tietokannan rakennetta intuitiivisemmaksi oppimisen kannalta (linkki!). Kaikki tämä johtaa raskaaseen kompromissiin tarkkuuden kanssa, mikä saattaa myös selittää, miksi nykyiset Text2SQL-palveluntarjoajat, jotka tarjoavat uusien tietokantojen ad hoc -kyselyitä, eivät ole vielä saavuttaneet merkittävää markkinaosuutta.

4.3 Nopeus

Koska Text2SQL-pyynnöt käsitellään yleensä verkossa keskustelun aikana, nopeusnäkökohta on tärkeä käyttäjätyytyväisyyden kannalta. Positiivista on se, että käyttäjät ovat usein tietoisia siitä, että tietopyynnöt voivat kestää tietyn ajan ja osoittavat vaadittua kärsivällisyyttä. Tätä liikearvoa voi kuitenkin heikentää chat-asetus, jossa käyttäjät odottavat alitajuisesti ihmismäistä keskustelunopeutta. Raakavoimaisilla optimointimenetelmillä, kuten mallin koon pienentämisellä, voi olla kohtuuton vaikutus tarkkuuteen, joten harkitse päätelmien optimointia tämän odotuksen täyttämiseksi.

4.4 Selittävyys ja läpinäkyvyys

Ihannetapauksessa käyttäjä voi seurata, kuinka kysely on luotu tekstistä, nähdä kysymyksessä olevien tiettyjen sanojen tai lausekkeiden ja SQL-kyselyn välisen vastaavuuden jne. Tämä mahdollistaa kyselyn tarkistamisen ja mahdollisten säätöjen tekemisen vuorovaikutuksessa järjestelmän kanssa. . Lisäksi järjestelmä voisi myös tarjota kyselylle selkeän tekstimuotoilun ja pyytää käyttäjää joko vahvistamaan tai korjaamaan sen.

4.5-tietosuoja

Text2SQL-funktio voidaan eristää kyselyn suorittamisesta, joten palautetut tietokantatiedot voidaan pitää näkymättöminä. Kriittinen kysymys on kuitenkin, kuinka paljon tietoa tietokannasta sisältyy kehotteeseen. Kolme vaihtoehtoa (alentamalla tietosuojatasoa) ovat:

Ei tietoja
Tietokantakaavio
Tietokannan sisältö

Tietosuoja vaihtuu tarkkuudella – mitä vähemmän rajoita sinua sisällyttämään kehotteeseen hyödyllistä tietoa, sitä parempia tuloksia saat.

4.6 Sopeutuvuus ajan myötä

Jotta Text2SQL:ää voidaan käyttää kestävästi, sinun on sopeuduttava datan ajautumiseen eli sen datan muuttuvaan jakautumiseen, johon mallia sovelletaan. Oletetaan esimerkiksi, että alkuperäiseen hienosäätöön käytetyt tiedot heijastavat käyttäjien yksinkertaista kyselykäyttäytymistä, kun he alkavat käyttää BI-järjestelmää. Ajan myötä käyttäjien tietotarpeet kehittyvät entistä kehittyneemmiksi ja vaativat monimutkaisempia kyselyitä, jotka ylittävät naiivin mallisi. Lisäksi yrityksen muutoksen tavoitteet tai strategia voivat myös ajautua ja ohjata tietotarpeita tietokannan muille alueille. Lopuksi Text2SQL-spesifinen haaste on tietokannan ajautuminen. Kun yritystietokantaa laajennetaan, kehotteeseen tulee uusia, näkymättömiä sarakkeita ja taulukoita. Vaikka usean tietokannan sovelluksille suunnitellut Text2SQL-algoritmit voivat käsitellä tätä ongelmaa hyvin, se voi vaikuttaa merkittävästi yhden tietokannan mallin tarkkuuteen. Kaikki nämä ongelmat ratkaistaan parhaiten hienosäädettävällä tietojoukolla, joka kuvastaa käyttäjien nykyistä, todellista käyttäytymistä. Siksi on erittäin tärkeää kirjata käyttäjien kysymykset ja tulokset sekä niihin liittyvä palaute, joka voidaan kerätä käytöstä. Lisäksi semanttisia klusterointialgoritmeja, esimerkiksi käyttämällä upotuksia tai aihemallinnusta, voidaan soveltaa havaitsemaan taustalla olevia pitkän aikavälin muutoksia käyttäjien käyttäytymisessä ja käyttää niitä lisätietolähteenä hienosäätävien tietojoukkojen parantamiseen.

Yhteenveto

Tehdään yhteenveto artikkelin pääkohdista:

Text2SQL mahdollistaa intuitiivisen ja demokraattisen tiedonsaannin käyttöönoton liiketoiminnassa, mikä maksimoi käytettävissä olevan tiedon arvon.
Text2SQL-data koostuu kysymyksistä sisääntulossa ja SQL-kyselyistä lähdössä. Kysymysten ja SQL-kyselyiden välinen kartoitus on useista moneen.
On tärkeää antaa tietoa tietokannasta osana kehotetta. Lisäksi tietokannan rakennetta voidaan optimoida, jotta algoritmin oppiminen ja ymmärtäminen olisi helpompaa.
Syöttössä suurin haaste on luonnollisen kielen kysymysten kielellinen vaihtelevuus, jota voidaan lähestyä moniin erilaisiin tekstityyleihin valmiiksi koulutetuilla LLM:illä.
Text2SQL:n lähdön tulee olla kelvollinen SQL-kysely. Tämä rajoitus voidaan sisällyttää "lisäämällä" SQL-tietoa algoritmiin; vaihtoehtoisesti iteratiivista lähestymistapaa käyttämällä kysely voidaan tarkistaa ja parantaa useissa vaiheissa.
Koska "hiljaiset epäonnistumiset" voivat olla suuret vaikutukset, jotka palauttavat väärää tietoa päätöksentekoon, vianhallinta on käyttöliittymän ensisijainen huolenaihe.
"Lisätyllä" tavalla käyttäjät voivat osallistua aktiivisesti SQL-kyselyiden iteratiiviseen validointiin ja parantamiseen. Vaikka tämä tekee sovelluksesta vähemmän sujuvaa, se myös vähentää epäonnistumisten määrää, antaa käyttäjille mahdollisuuden tutkia tietoja joustavammin ja luo arvokkaita signaaleja jatko-oppimista varten.
Tärkeimmät huomioon otettavat ei-toiminnalliset vaatimukset ovat tarkkuus, skaalautuvuus, nopeus, selitettävyys, yksityisyys ja mukautuvuus ajan myötä. Tärkeimmät kompromissit muodostuvat toisaalta tarkkuuden ja toisaalta skaalautuvuuden, nopeuden ja yksityisyyden välillä.