Creating An Information Edge With Conversational Access To Data

Republicat de Platon

Urmaritori: 0

IA conversațională pentru analiza datelor

Figura 1: Reprezentarea fluxului Text2SQL

Pe măsură ce lumea noastră devine din ce în ce mai globală și mai dinamică, companiile depind din ce în ce mai mult de date pentru a lua decizii informate, obiective și oportune. Cu toate acestea, de acum, dezlănțuirea întregului potențial al datelor organizaționale este adesea un privilegiu al unui număr mic de cercetători și analiști de date. Majoritatea angajaților nu stăpânesc setul de instrumente convențional pentru știința datelor (SQL, Python, R etc.). Pentru a accesa datele dorite, aceștia trec printr-un strat suplimentar în care analiștii sau echipele BI „traduc” proza întrebărilor de afaceri în limbajul datelor. Potențialul de frecare și ineficiență în această călătorie este mare - de exemplu, datele pot fi livrate cu întârzieri sau chiar atunci când întrebarea a devenit deja învechită. Informațiile se pot pierde pe parcurs atunci când cerințele nu sunt traduse cu acuratețe în interogări analitice. În plus, generarea de informații de înaltă calitate necesită o abordare iterativă care este descurajată cu fiecare pas suplimentar din buclă. Pe de altă parte, aceste interacțiuni ad-hoc creează perturbări pentru talentul de date scump și le distrage atenția de la munca mai strategică a datelor, așa cum este descris în aceste „confesiuni” ale unui cercetător de date:

Când eram la Square și echipa era mai mică, am avut o rotație de temut „analitică la gardă”. A fost rotit strict săptămânal și, dacă era rândul tău, știai că vei obține foarte puțină muncă „adevărată” în acea săptămână și că vei petrece cea mai mare parte a timpului răspunzând întrebări ad-hoc de la diferitele echipe de produse și operațiuni de la companie (SQL maimuță, am numit-o noi). A existat o competiție atrăgătoare pentru roluri de manager în echipa de analiză și cred că acesta a fost în întregime rezultatul excluderii managerilor de la această rotație - niciun premiu de statut nu ar putea rivaliza cu morcovul de a nu face munca de gardă.[1]

Într-adevăr, nu ar fi grozav să vorbești direct cu datele tale în loc să trebuiască să treci prin mai multe runde de interacțiune cu personalul tău de date? Această viziune este îmbrățișată de interfețele conversaționale care permit oamenilor să interacționeze cu datele folosind limbajul, cel mai intuitiv și universal canal de comunicare al nostru. După analizarea unei întrebări, un algoritm o codifică într-o formă logică structurată în limbajul de interogare ales, cum ar fi SQL. Astfel, utilizatorii non-tehnici pot discuta cu datele lor și pot pune rapid mâna pe informații specifice, relevante și în timp util, fără a face ocolire prin intermediul unei echipe BI. În acest articol, vom lua în considerare diferitele aspecte de implementare ale Text2SQL și ne vom concentra pe abordări moderne cu utilizarea modelelor de limbaj mari (LLM), care ating cele mai bune performanțe de acum (cf. [2]; pentru un sondaj asupra abordărilor alternative). dincolo de LLM, cititorii sunt referiți la [3]). Articolul este structurat în conformitate cu următorul „model mental” al principalelor elemente de luat în considerare atunci când planificați și construiți o caracteristică AI:

IA conversațională pentru analiza datelor — Figura 2: Modelul mental al unei caracteristici AI

Să începem cu sfârșitul în minte și să recapitulăm valoarea - de ce ați construi o caracteristică Text2SQL în produsul dvs. de date sau de analiză. Cele trei beneficii principale sunt:

Utilizatori de afaceri poate accesa datele organizaționale într-un mod direct și în timp util.
Acest lucru ușurează cercetători și analiști de date de povara solicitărilor ad-hoc din partea utilizatorilor de afaceri și le permite să se concentreze asupra provocărilor avansate de date.
Acest lucru permite afaceri pentru a-și valorifica datele într-un mod mai fluid și mai strategic, transformându-le în cele din urmă într-o bază solidă pentru luarea deciziilor.

Acum, care sunt scenariile de produs în care ați putea lua în considerare Text2SQL? Cele trei setări principale sunt:

Oferiți o date scalabile/produs BI și doresc să permită mai multor utilizatori să își acceseze datele într-un mod non-tehnic, crescând astfel atât utilizarea, cât și baza de utilizatori. De exemplu, ServiceNow are interogări de date integrate într-o ofertă conversațională mai mare, și Atlan a făcut recent a anunțat explorarea datelor în limbaj natural.
Căutați să construiți ceva în spațiul de date/AI pentru a democratiza accesul la date în companii, caz în care ați putea lua în considerare un MVP cu Text2SQL la bază. Furnizorilor ca AI2SQL și Text2sql.ai fac deja intrarea în acest spațiu.
Lucrezi la o sistem BI personalizat și doresc să maximizeze și să democratizeze utilizarea sa în cadrul companiei individuale.

După cum vom vedea în secțiunile următoare, Text2SQL necesită o configurare inițială non-trivială. Pentru a estima rentabilitatea investiției, luați în considerare natura deciziilor care urmează să fie susținute, precum și datele disponibile. Text2SQL poate fi un câștig absolut în mediile dinamice în care datele se schimbă rapid și sunt utilizate în mod activ și frecvent în luarea deciziilor, cum ar fi investițiile, marketingul, producția și industria energetică. În aceste medii, instrumentele tradiționale pentru managementul cunoștințelor sunt prea statice, iar modalitățile mai fluente de a accesa date și informații ajută companiile să genereze un avantaj competitiv. În ceea ce privește datele, Text2SQL oferă cea mai mare valoare cu o bază de date care este:

Mare și în creștere, astfel încât Text2SQL să își poată desfășura valoarea în timp, pe măsură ce tot mai multe date sunt valorificate.
Calitate superioară, astfel încât algoritmul Text2SQL să nu aibă de-a face cu zgomotul excesiv (incoerențe, valori goale etc.) în date. În general, datele care sunt generate automat de aplicații au o calitate și o consistență mai ridicate decât datele care sunt create și întreținute de oameni.
Matur semantic spre deosebire de brut, astfel încât oamenii să poată interoga datele bazate pe concepte centrale, relații și metrici care există în modelul lor mental. Rețineți că maturitatea semantică poate fi atinsă printr-un pas suplimentar de transformare care conformează datele brute într-o structură conceptuală (cf. secțiunea „Îmbogățirea promptului cu informații de bază de date”).

În cele ce urmează, ne vom aprofunda în datele, algoritmul, experiența utilizatorului, precum și cerințele nefuncționale relevante ale unei caracteristici Text2SQL. Articolul este scris pentru managerii de produs, designerii UX și acei oameni de știință de date și ingineri care sunt la începutul călătoriei lor Text2SQL. Pentru acești oameni, oferă nu numai un ghid pentru a începe, ci și un teren comun de cunoștințe pentru discuții despre interfețele dintre produs, tehnologie și afaceri, inclusiv compromisurile aferente. Dacă sunteți deja mai avansat în implementarea dvs., referințele de la sfârșit oferă o serie de scufundări profunde de explorat.

Dacă acest conținut educațional aprofundat vă este util, puteți abonați-vă la lista noastră de corespondență pentru cercetare AI pentru a fi avertizați atunci când lansăm material nou.

1. Date

Orice efort de învățare automată începe cu date, așa că vom începe prin a clarifica structura datelor de intrare și țintă care sunt utilizate în timpul antrenamentului și predicției. De-a lungul articolului, vom folosi fluxul Text2SQL din Figura 1 ca reprezentare curentă și vom evidenția în galben componentele și relațiile considerate în prezent.

1.1 Formatul și structura datelor

De obicei, o pereche de intrare-ieșire Text2SQL brută constă dintr-o întrebare în limbaj natural și interogarea SQL corespunzătoare, de exemplu:

Întrebare: "Listați numele și numărul de urmăritori pentru fiecare utilizator.”

Interogare SQL:

selectați numele, urmăritorii din user_profiles

În spațiul de date de antrenament, maparea între întrebări și interogări SQL este multi-la-multe:

O interogare SQL poate fi mapată la multe întrebări diferite în limbaj natural; de exemplu, semantica interogării de mai sus poate fi exprimată prin: „arată-mi numele și numărul de urmăritori per utilizator","câți urmăritori sunt pentru fiecare utilizator?"Etc.
Sintaxa SQL este extrem de versatilă și aproape fiecare întrebare poate fi reprezentată în SQL în mai multe moduri. Cel mai simplu exemplu sunt diferitele ordonări ale clauzelor WHERE. Într-o poziție mai avansată, toți cei care au făcut optimizarea interogărilor SQL vor ști că multe drumuri conduc la același rezultat, iar interogările echivalente din punct de vedere semantic ar putea avea o sintaxă complet diferită.

Colectarea manuală a datelor de antrenament pentru Text2SQL este deosebit de plictisitoare. Nu numai că necesită stăpânire SQL din partea adnotatorului, ci și mai mult timp pentru fiecare exemplu decât sarcini lingvistice mai generale, cum ar fi analiza sentimentelor și clasificarea textului. Pentru a asigura o cantitate suficientă de exemple de instruire, poate fi utilizată creșterea datelor - de exemplu, LLM-urile pot fi folosite pentru a genera parafraze pentru aceeași întrebare. [3] oferă un studiu mai complet al tehnicilor de creștere a datelor Text2SQL.

1.2 Îmbogățirea promptului cu informații de bază de date

Text2SQL este un algoritm la interfața dintre datele nestructurate și cele structurate. Pentru o performanță optimă, ambele tipuri de date trebuie să fie prezente în timpul antrenamentului și al predicției. Mai exact, algoritmul trebuie să știe despre baza de date interogată și să fie capabil să formuleze interogarea în așa fel încât să poată fi executată împotriva bazei de date. Aceste cunoștințe pot cuprinde:

Coloane și tabele ale bazei de date
Relații între tabele (chei externe)
Conținutul bazei de date

Există două opțiuni pentru încorporarea cunoștințelor bazei de date: pe de o parte, datele de instruire pot fi limitate la exemple scrise pentru baza de date specifică, caz în care schema este învățată direct din interogarea SQL și maparea acesteia la întrebare. Această setare pentru o singură bază de date permite optimizarea algoritmului pentru o bază de date individuală și/sau companie. Cu toate acestea, distruge orice ambiție de scalabilitate, deoarece modelul trebuie ajustat pentru fiecare client sau bază de date. Alternativ, într-o setare cu mai multe baze de date, schema bazei de date poate fi furnizată ca parte a intrării, permițând algoritmului să „generalice” la scheme de baze de date noi, nevăzute. Deși va trebui neapărat să optați pentru această abordare dacă doriți să utilizați Text2SQL pe multe baze de date diferite, rețineți că necesită un efort de inginerie promptă considerabil. Pentru orice bază de date de afaceri rezonabilă, inclusiv informațiile complete din prompt va fi extrem de ineficientă și cel mai probabil imposibilă din cauza limitărilor de lungime a promptului. Astfel, funcția responsabilă pentru formularea promptă ar trebui să fie suficient de inteligentă pentru a selecta un subset de informații de bază de date care este cel mai „util” pentru o anumită întrebare și pentru a face acest lucru pentru baze de date potențial nevăzute.

În cele din urmă, structura bazei de date joacă un rol crucial. În acele scenarii în care aveți suficient control asupra bazei de date, puteți face viața mai ușoară modelului dvs., lăsându-l să învețe dintr-o structură intuitivă. Ca regulă generală, cu cât baza de date reflectă mai mult modul în care utilizatorii de afaceri vorbesc despre afacere, cu atât mai bine și mai rapid modelul tău poate învăța din ea. Astfel, luați în considerare aplicarea unor transformări suplimentare datelor, cum ar fi asamblarea datelor normalizate sau dispersate în alt mod în tabele largi sau într-un seif de date, denumirea tabelelor și coloanelor într-un mod explicit și lipsit de ambiguitate etc. Toate cunoștințele de afaceri pe care le puteți codifica în avans vor reduce povara învățării probabilistice asupra modelului dvs. și vă ajută să obțineți rezultate mai bune.

2. Algoritmul

Text2SQL este un tip de analiza semantică — maparea textelor la reprezentări logice. Astfel, algoritmul nu trebuie doar să „învețe” limbajul natural, ci și reprezentarea țintă – în cazul nostru, SQL. Mai exact, trebuie să dobândească și următoarele biți de cunoștințe:

Sintaxă și semantică SQL
Structura bazei de date
Înțelegerea limbajului natural (NLU)
Maparea dintre limbajul natural și interogările SQL (sintactice, lexicale și semantice)

2.1 Rezolvarea variabilității lingvistice în input

La intrare, principala provocare a Text2SQL constă în flexibilitatea limbajului: așa cum este descris în secțiunea Formatul și structura datelor, aceeași întrebare poate fi parafrazată în multe moduri diferite. În plus, în contextul conversației din viața reală, trebuie să ne confruntăm cu o serie de probleme, cum ar fi greșelile de ortografie și gramaticale, intrări incomplete și ambigue, intrări multilingve etc.

LLM-urile precum modelele GPT, T5 și CodeX se apropie din ce în ce mai mult de rezolvarea acestei provocări. Învățând din cantități uriașe de text divers, ei învață să facă față unui număr mare de modele și nereguli lingvistice. În cele din urmă, ei devin capabili să generalizeze peste întrebări care sunt similare din punct de vedere semantic, în ciuda faptului că au forme de suprafață diferite. LLM-urile pot fi aplicate imediat (zero-shot) sau după reglare fină. Primul, deși convenabil, duce la o precizie mai scăzută. Acesta din urmă necesită mai multă abilitate și muncă, dar poate crește semnificativ precizia.

În ceea ce privește acuratețea, așa cum era de așteptat, cele mai performante modele sunt cele mai recente modele din familia GPT, inclusiv modelele CodeX. În aprilie 2023, GPT-4 a condus la o creștere dramatică a preciziei de peste 5% față de stadiul anterior al tehnicii și a atins o acuratețe de 85.3% (în metrica „execuție cu valori”).[4] În tabăra cu sursă deschisă, încercările inițiale de rezolvare a puzzle-ului Text2SQL s-au concentrat pe modele de codificare automată, cum ar fi BERT, care excelează la sarcinile NLU.[5, 6, 7] Cu toate acestea, în mijlocul hype-ului din jurul AI generativă, abordările recente se concentrează. pe modele autoregresive precum modelul T5. T5 este pregătit în prealabil folosind învățarea multi-task și astfel se adaptează cu ușurință la noile sarcini lingvistice, incl. diferite variante de parsare semantică. Cu toate acestea, modelele autoregresive au un defect intrinsec atunci când vine vorba de sarcinile de parsare semantică: au un spațiu de ieșire neconstrâns și nicio bară de protecție semantică care le-ar constrânge rezultatul, ceea ce înseamnă că pot deveni uimitor de creativi în comportamentul lor. Deși acestea sunt lucruri uimitoare pentru generarea de conținut în formă liberă, este o pacoste pentru sarcini precum Text2SQL, unde ne așteptăm la o ieșire țintă constrânsă și bine structurată.

2.2 Validarea și îmbunătățirea interogărilor

Pentru a limita rezultatul LLM, putem introduce mecanisme suplimentare pentru validarea și îmbunătățirea interogării. Acest lucru poate fi implementat ca un pas suplimentar de validare, așa cum este propus în sistemul PICARD.[8] PICARD folosește un parser SQL care poate verifica dacă o interogare SQL parțială poate duce la o interogare SQL validă după finalizare. La fiecare pas de generare de către LLM, jetoanele care ar invalida interogarea sunt respinse și sunt păstrate jetoanele valide cu cea mai mare probabilitate. Fiind deterministă, această abordare asigură o validitate SQL de 100% atâta timp cât parserul respectă regulile SQL corecte. De asemenea, decuplează validarea interogării de generație, permițând astfel menținerea ambelor componente independent una de alta și actualizarea și modificarea LLM.

O altă abordare este de a încorpora cunoștințele structurale și SQL direct în LLM. De exemplu, Graphix [9] folosește straturi conștiente de grafic pentru a injecta cunoștințe SQL structurate în modelul T5. Datorită naturii probabilistice a acestei abordări, influențează sistemul către interogări corecte, dar nu oferă o garanție pentru succes.

În cele din urmă, LLM poate fi folosit ca un agent în mai mulți pași care poate verifica și îmbunătăți în mod autonom interogarea.[10] Folosind mai mulți pași într-un prompt lanț de gândire, agentul poate fi însărcinat să reflecteze asupra corectitudinii propriilor interogări și să îmbunătățească orice defecțiuni. Dacă interogarea validată încă nu poate fi executată, urmărirea excepției SQL poate fi transmisă agentului ca feedback suplimentar pentru îmbunătățire.

Dincolo de aceste metode automate care se întâmplă în backend, este posibil și implicarea utilizatorului în timpul procesului de verificare a interogărilor. Vom descrie acest lucru mai detaliat în secțiunea despre Experiența utilizatorului.

2.3 Evaluare

Pentru a evalua algoritmul nostru Text2SQL, trebuie să generăm un set de date de testare (validare), să rulăm algoritmul nostru pe el și să aplicăm metrici de evaluare relevante pentru rezultat. Un set de date naiv împărțit în date de instruire, dezvoltare și validare s-ar baza pe perechi întrebare-interogare și ar duce la rezultate suboptime. Interogările de validare ar putea fi dezvăluite modelului în timpul antrenamentului și pot duce la o viziune prea optimistă asupra abilităților sale de generalizare. A împărțire bazată pe interogări, unde setul de date este împărțit în așa fel încât nicio interogare să nu apară atât în timpul antrenamentului, cât și în timpul validării, oferă rezultate mai veridice.

În ceea ce privește valorile de evaluare, ceea ce ne pasă în Text2SQL este să nu generăm interogări care sunt complet identice cu standardul de aur. Acest „potrivire exactă a șirurilor” metoda este prea strictă și va genera multe negative false, deoarece diferite interogări SQL pot duce la același set de date returnat. În schimb, vrem să atingem un nivel ridicat acuratețea semantică și evaluați dacă interogările prezise și „standardul de aur” vor returna întotdeauna aceleași seturi de date. Există trei valori de evaluare care aproximează acest obiectiv:

Precizia potrivirii setate exacte: interogările SQL generate și țintă sunt împărțite în constituenții lor, iar seturile rezultate sunt comparate pentru identitate.[11] Deficiența aici este că ține cont doar de variațiile de ordine în interogarea SQL, dar nu și de diferențele sintactice mai pronunțate între interogările echivalente semantic.
Acuratețea execuției: seturile de date rezultate din interogările SQL generate și țintă sunt comparate pentru identitate. Cu mult noroc, interogările cu semantică diferită pot trece în continuare acest test pe o anumită instanță de bază de date. De exemplu, presupunând o bază de date în care toți utilizatorii au peste 30 de ani, următoarele două interogări ar returna rezultate identice, deși au o semantică diferită:
selectați * de la utilizator
selectați * de la utilizatorul la care vârsta > 30
Precizia suitei de testare: acuratețea suitei de testare este o versiune mai avansată și mai puțin permisivă a preciziei de execuție. Pentru fiecare interogare, se generează un set („suită de teste”) de baze de date care sunt foarte diferențiate în raport cu variabilele, condițiile și valorile din interogare. Apoi, acuratețea execuției este testată pe fiecare dintre aceste baze de date. Deși necesită efort suplimentar pentru a proiecta generarea suitei de testare, această măsurătoare reduce, de asemenea, în mod semnificativ riscul de fals pozitive în evaluare..[12]

3. Experiența utilizatorului

Starea actuală a tehnologiei Text2SQL nu permite o integrare completă fără probleme în sistemele de producție - în schimb, este necesar să se gestioneze în mod activ așteptările și comportamentul utilizatorului, care ar trebui să fie întotdeauna conștient de faptul că acesta interacționează cu un sistem AI.

3.1 Managementul eșecului

Text2SQL poate eșua în două moduri, care trebuie prinse în moduri diferite:

erori SQL: interogarea generată nu este validă — fie SQL-ul este invalid, fie nu poate fi executat împotriva bazei de date specifice din cauza unor defecte lexicale sau semantice. În acest caz, niciun rezultat nu poate fi returnat utilizatorului.
Erori semantice: interogarea generată este validă, dar nu reflectă semantica întrebării, ducând astfel la un set de date returnat greșit.

Al doilea mod este deosebit de complicat, deoarece riscul de „eșecuri silențioase” – erori care nu sunt detectate de utilizator – este mare. Utilizatorul prototip nu va avea nici timpul și nici abilitățile tehnice pentru a verifica corectitudinea interogării și/sau a datelor rezultate. Atunci când datele sunt folosite pentru luarea deciziilor în lumea reală, acest tip de eșec poate avea consecințe devastatoare. Pentru a evita acest lucru, este esențial să educați utilizatorii și să stabiliți balustrade la nivel de afaceri care limitează impactul potențial, cum ar fi verificări suplimentare de date pentru decizii cu un impact mai mare. Pe de altă parte, putem folosi și interfața cu utilizatorul pentru a gestiona interacțiunea om-mașină și pentru a ajuta utilizatorul să detecteze și să îmbunătățească cererile problematice.

3.2 Interacțiunea om-mașină

Utilizatorii se pot implica în sistemul dumneavoastră AI cu diferite grade de intensitate. Mai multă interacțiune per solicitare poate duce la rezultate mai bune, dar încetinește și fluiditatea experienței utilizatorului. Pe lângă impactul negativ potențial al interogărilor și rezultatelor eronate, luați în considerare, de asemenea, cât de motivați vor fi utilizatorii dvs. să ofere feedback înainte și înapoi pentru a obține rezultate mai precise și, de asemenea, pentru a ajuta la îmbunătățirea produsului pe termen lung.

Cea mai simplă și mai puțin captivantă modalitate este de a lucra cu scoruri de încredere. În timp ce calculul naiv al încrederii ca medie a probabilităților jetoanelor generate este prea simplist, pot fi utilizate metode mai avansate, cum ar fi feedback-ul verbalizat. [13] Încrederea poate fi afișată în interfață și evidențiată cu o alertă explicită în cazul în care este periculos de scăzută. În acest fel, responsabilitatea unei urmăriri adecvate în „lumea reală” – fie că este vorba despre o respingere, acceptare sau o verificare suplimentară a datelor – aterizează pe umerii utilizatorului dumneavoastră. Deși acesta este un pariu sigur pentru dvs. ca furnizor, transferul acestei lucrări către utilizator poate reduce și valoarea produsului dvs.

O a doua posibilitate este angajarea utilizatorului într-un dialog de clarificare în cazul interogărilor cu încredere scăzută, ambigue sau suspecte. De exemplu, sistemul dvs. ar putea sugera corecții ortografice sau gramaticale la intrare și poate cere să dezambiguizeze anumite cuvinte sau structuri gramaticale. De asemenea, ar putea permite utilizatorului să solicite în mod proactiv corecții în interogare:[14]

UTILIZATOR: Arată-mi sarcinile lui John în acest sprint.

ASISTENT: Ți-ar plăcea să vezi sarcinile create de John sau cele la care lucrează?

UTILIZATOR: sarcinile create de John

ASISTENT: Ok, iată ID-urile sarcinilor:

UTILIZATOR: Mulțumesc, aș dori, de asemenea, să văd mai multe informații despre sarcini. Vă rugăm să sortați și după urgență.

ASISTENT: Sigur, aici sunt sarcinile împreună cu scurte descrieri, cesionari și termene limită, sortate după termen.

În cele din urmă, pentru a ușura înțelegerea interogărilor de către utilizator, sistemul dumneavoastră poate oferi, de asemenea, o reformulare textuală explicită a interogării și poate cere utilizatorului fie să o confirme, fie să o corecteze.[15]

4. Cerințe nefuncționale

În această secțiune, discutăm cerințele specifice nefuncționale pentru Text2SQL, precum și compromisurile dintre ele. Ne vom concentra pe cele șase cerințe care par cele mai importante pentru sarcină: acuratețe, scalabilitate, viteză, explicabilitate, confidențialitate și adaptabilitate în timp.

4.1 Precizie

Pentru Text2SQL, cerințele privind acuratețea sunt ridicate. În primul rând, Text2SQL este aplicat de obicei într-o setare de conversație în care predicțiile sunt făcute unul câte unul. Astfel, „Legea numerelor mari”, care de obicei ajută la echilibrarea erorii din predicțiile grupate, nu ajută. În al doilea rând, validitatea sintactică și lexicală este o condiție „grea”: modelul trebuie să genereze o interogare SQL bine formată, potențial cu sintaxă și semantică complexă, altfel cererea nu poate fi executată împotriva bazei de date. Și dacă acest lucru merge bine și interogarea poate fi executată, aceasta poate conține în continuare erori semantice și poate duce la un set de date returnat greșit (cf. secțiunea 3.1 Gestionarea erorilor).

4.2 Scalabilitate

Principalele considerații de scalabilitate sunt dacă doriți să aplicați Text2SQL pe una sau mai multe baze de date - și, în acest din urmă caz, dacă setul de baze de date este cunoscut și închis. Dacă da, veți avea un timp mai ușor, deoarece puteți include informații despre aceste baze de date în timpul antrenamentului. Cu toate acestea, într-un scenariu al unui produs scalabil – fie că este o aplicație de sine stătătoare Text2SQL sau o integrare într-un produs de date existent – algoritmul dumneavoastră trebuie să facă față oricărei noi scheme de bază de date din mers. De asemenea, acest scenariu nu vă oferă posibilitatea de a transforma structura bazei de date pentru a o face mai intuitivă pentru învățare (link!). Toate acestea duc la un compromis greu cu acuratețea, ceea ce ar putea explica și de ce furnizorii actuali de Text2SQL care oferă interogări ad-hoc a noilor baze de date nu au atins încă o penetrare semnificativă pe piață.

Viteza 4.3

Deoarece cererile Text2SQL vor fi de obicei procesate online într-o conversație, aspectul vitezei este important pentru satisfacția utilizatorului. Pe partea pozitivă, utilizatorii sunt adesea conștienți de faptul că solicitările de date pot dura un anumit timp și pot arăta răbdarea necesară. Cu toate acestea, această bunăvoință poate fi subminată de setarea de chat, unde utilizatorii se așteaptă subconștient la o viteză de conversație asemănătoare omului. Metodele de optimizare cu forță brută, cum ar fi reducerea dimensiunii modelului, ar putea avea un impact inacceptabil asupra preciziei, așa că luați în considerare optimizarea inferenței pentru a satisface această așteptare.

4.4 Explicabilitate și transparență

În cazul ideal, utilizatorul poate urmări modul în care a fost generată interogarea din text, poate vedea maparea dintre anumite cuvinte sau expresii din întrebare și interogarea SQL etc. Acest lucru permite să verifice interogarea și să facă orice ajustări atunci când interacționează cu sistemul . În plus, sistemul ar putea oferi și o reformulare textuală explicită a interogării și să solicite utilizatorului fie să o confirme, fie să o corecteze.

4.5 Confidențialitate

Funcția Text2SQL poate fi izolată de execuția interogării, astfel încât informațiile returnate ale bazei de date pot fi păstrate invizibile. Cu toate acestea, întrebarea critică este cât de multe informații despre baza de date sunt incluse în prompt. Cele trei opțiuni (prin scăderea nivelului de confidențialitate) sunt:

Nu există informații
Schema bazei de date
Conținutul bazei de date

Confidențialitatea se schimbă cu acuratețe - cu cât sunteți mai puțin constrâns în includerea informațiilor utile în prompt, cu atât rezultatele sunt mai bune.

4.6 Adaptabilitate în timp

Pentru a utiliza Text2SQL într-un mod durabil, trebuie să vă adaptați la deriva de date, adică la distribuția schimbătoare a datelor la care se aplică modelul. De exemplu, să presupunem că datele utilizate pentru reglarea fină inițială reflectă comportamentul simplu de interogare al utilizatorilor atunci când încep să utilizeze sistemul BI. Pe măsură ce trece timpul, nevoile de informații ale utilizatorilor devin mai sofisticate și necesită interogări mai complexe, care copleșesc modelul tău naiv. În plus, obiectivele sau strategia unei companii pot de asemenea să derive și să direcționeze nevoile de informații către alte zone ale bazei de date. În cele din urmă, o provocare specifică Text2SQL este derivarea bazei de date. Pe măsură ce baza de date a companiei este extinsă, coloane și tabele noi, nevăzute, își fac loc în prompt. În timp ce algoritmii Text2SQL care sunt proiectați pentru aplicații cu mai multe baze de date pot gestiona bine această problemă, poate avea un impact semnificativ asupra acurateței unui model cu o singură bază de date. Toate aceste probleme sunt rezolvate cel mai bine cu un set de date de reglare fină care reflectă comportamentul actual al utilizatorilor în lumea reală. Astfel, este crucial să înregistrați întrebările și rezultatele utilizatorilor, precum și orice feedback asociat care poate fi colectat din utilizare. În plus, algoritmii de grupare semantică, de exemplu folosind înglobări sau modelarea subiectelor, pot fi aplicați pentru a detecta modificările pe termen lung ale comportamentului utilizatorului și le pot folosi ca o sursă suplimentară de informații pentru perfecționarea setului de date de reglare fină.

Concluzie

Să rezumăm punctele cheie ale articolului:

Text2SQL permite implementarea unui acces intuitiv și democratic la date într-o afacere, maximizând astfel valoarea datelor disponibile.
Datele Text2SQL constau din întrebări la intrare și interogări SQL la ieșire. Maparea dintre întrebări și interogări SQL este multi-la-mulți.
Este important să furnizați informații despre baza de date ca parte a promptului. În plus, structura bazei de date poate fi optimizată pentru ca algoritmul să o învețe și să o înțeleagă mai ușor.
În ceea ce privește intrarea, principala provocare este variabilitatea lingvistică a întrebărilor în limbaj natural, care pot fi abordate folosind LLM-uri care au fost pre-instruite pe o mare varietate de stiluri de text diferite.
Ieșirea Text2SQL ar trebui să fie o interogare SQL validă. Această constrângere poate fi încorporată prin „injectarea” cunoştinţelor SQL în algoritm; alternativ, folosind o abordare iterativă, interogarea poate fi verificată și îmbunătățită în mai mulți pași.
Datorită impactului potențial mare al „eșecurilor silențioase” care returnează date greșite pentru luarea deciziilor, gestionarea eșecurilor este o preocupare principală în interfața cu utilizatorul.
Într-un mod „amplificat”, utilizatorii pot fi implicați activ în validarea iterativă și îmbunătățirea interogărilor SQL. Deși acest lucru face aplicația mai puțin fluidă, reduce și ratele de eșec, permite utilizatorilor să exploreze datele într-un mod mai flexibil și creează semnale valoroase pentru învățare ulterioară.
Cerințele majore nefuncționale de luat în considerare sunt acuratețea, scalabilitatea, viteza, explicabilitatea, confidențialitatea și adaptabilitatea în timp. Principalele compromisuri constau între acuratețe, pe de o parte, și scalabilitate, viteză și confidențialitate, pe de altă parte.