Információs él létrehozása az adatokhoz való társalgási hozzáféréssel

1. ábra: A Text2SQL folyamat ábrázolása

Ahogy világunk egyre globálisabbá és dinamikusabbá válik, a vállalkozások egyre inkább függenek az adatoktól ahhoz, hogy megalapozott, objektív és időszerű döntéseket hozzanak. Jelenleg azonban a szervezeti adatok teljes potenciáljának felszabadítása gyakran néhány adattudós és elemző kiváltsága. A legtöbb alkalmazott nem ismeri a hagyományos adattudományi eszközkészletet (SQL, Python, R stb.). A kívánt adatok eléréséhez egy további rétegen mennek keresztül, ahol az elemzők vagy BI-csapatok „lefordítják” az üzleti kérdések prózáját az adatok nyelvére. Ezen az úton nagy a súrlódás és a hatékonyság hiányának lehetősége – például előfordulhat, hogy az adatok késéssel érkeznek, vagy még akkor is, amikor a kérdés már elavulttá vált. Az információk elveszhetnek az út során, ha a követelményeket nem fordítják le pontosan analitikus lekérdezésekké. Ezen túlmenően a jó minőségű betekintések generálása iteratív megközelítést igényel, amelyet a hurok minden további lépése nem javasol. Másrészt ezek az ad-hoc interakciók megzavarják a drága adattal rendelkező tehetségeket, és elvonják a figyelmüket a stratégiaibb adatkezeléstől, amint azt egy adattudós „vallomásai” leírják:

Amikor a Square-en voltam, és a csapat kisebb volt, rettegett „analitikai ügyeleti” rotáció volt. Szigorúan heti rendszerességgel váltották egymást, és ha Ön megfordult, tudta, hogy nagyon kevés „valódi” munkát fog végezni azon a héten, és ideje nagy részét a különböző termék- és üzemeltetési csapatok ad hoc kérdéseivel tölti. cég (SQL majmolás, mi hívtuk). Az elemzőcsapatban éles verseny zajlott a menedzser szerepekért, és úgy gondolom, hogy ez teljes mértékben annak az eredménye, hogy a menedzsereket mentesítették e rotáció alól – egyetlen státuszdíj sem vetekedhet azzal, hogy nem végez ügyeleti munkát.[1]

Valóban, nem jó lenne közvetlenül az adataival beszélni, ahelyett, hogy többszörös interakción kellene keresztülmennie az adatkezelőkkel? Ezt a látásmódot olyan társalgási felületek ölelik fel, amelyek lehetővé teszik az emberek számára, hogy a nyelv, a legintuitívabb és leguniverzálisabb kommunikációs csatorna segítségével kommunikáljanak az adatokkal. Egy kérdés elemzése után egy algoritmus strukturált logikai formába kódolja azt a választott lekérdezési nyelven, például SQL-ben. Így a nem technikai felhasználók cseveghetnek az adataikkal, és gyorsan hozzájuthatnak konkrét, releváns és időszerű információkhoz anélkül, hogy egy BI-csapaton keresztül kitérőre kellene lépniük. Ebben a cikkben megvizsgáljuk a Text2SQL különböző megvalósítási szempontjait, és a nagy nyelvi modelleket (LLM) használó modern megközelítésekre összpontosítunk, amelyek jelenleg a legjobb teljesítményt nyújtják (vö. [2]; az alternatív megközelítések felméréséhez az LLM-eken kívül az olvasókra hivatkozunk [3]). A cikk a következő „mentális modell” szerint épül fel azon fő elemekből, amelyeket figyelembe kell venni egy mesterséges intelligencia-funkció tervezése és felépítése során:

Kezdjük szem előtt tartva a végét, és foglaljuk össze az értéket – miért építene be egy Text2SQL szolgáltatást az adat- vagy elemzési termékébe. A három fő előny a következő:

• Üzleti felhasználók közvetlenül és időben hozzáférhet a szervezeti adatokhoz.
• Ez enyhíti adattudósok és elemzők az üzleti felhasználók ad hoc kéréseinek terhétől, és lehetővé teszi számukra, hogy a fejlett adatszolgáltatási kihívásokra összpontosítsanak.
• Ez lehetővé teszi a üzleti hogy adatait gördülékenyebb és stratégiaibb módon hasznosítsák, és végül szilárd alapot képezzenek a döntéshozatalhoz.

Most pedig mik azok a termékforgatókönyvek, amelyekben fontolóra veheti a Text2SQL-t? A három fő beállítás a következő:

• Ön felajánlja a méretezhető adatok/BI termék és szeretnék lehetővé tenni, hogy több felhasználó hozzáférjen adataihoz nem technikai módon, ezzel is növelve a felhasználást és a felhasználói bázist. Például a ServiceNow rendelkezik integrált adatlekérdezéseket egy nagyobb társalgási kínálatbaés Atlan nemrégiben bejelentette a természetes nyelvű adatfeltárást.
• Valamit szeretne építeni az adatok/AI térben, hogy demokratizálja az adatokhoz való hozzáférést a vállalatoknál, ebben az esetben fontolóra veheti MVP Text2SQL-lel a középpontban. A szolgáltatók kedvelik AI2SQL és a Text2sql.ai már bejáratot csinálnak ezen a téren.
• Ön a egyedi BI rendszer és maximalizálni és demokratizálni kívánja felhasználását az egyes vállalatokban.

Amint azt a következő szakaszokban látni fogjuk, a Text2SQL nem triviális előzetes beállítást igényel. A ROI becsléséhez vegye figyelembe a támogatandó döntések természetét, valamint a rendelkezésre álló adatokat. A Text2SQL abszolút nyerő lehet olyan dinamikus környezetekben, ahol az adatok gyorsan változnak, és aktívan és gyakran használják a döntéshozatalban, mint például a befektetések, a marketing, a gyártás és az energiaipar. Ezekben a környezetekben a tudásmenedzsment hagyományos eszközei túl statikusak, és az adatokhoz és információkhoz való hozzáférés gördülékenyebb módjai segítik a vállalatokat versenyelőny létrehozásában. Az adatok tekintetében a Text2SQL biztosítja a legnagyobb értéket egy olyan adatbázissal, amely:

• Nagy és növekvő, hogy a Text2SQL idővel kibontakoztathassa értékét, miközben egyre több adatot használnak fel.
• Kiváló minőségű, hogy a Text2SQL algoritmusnak ne kelljen túlzott zajjal (inkonzisztenciák, üres értékek stb.) foglalkoznia az adatokban. Általában az alkalmazások által automatikusan generált adatok minősége és konzisztenciája jobb, mint az emberek által létrehozott és karbantartott adatoké.
• Szemantikailag érett szemben a nyerssel, hogy az emberek a mentális modelljükben létező központi fogalmak, kapcsolatok és metrikák alapján lekérdezhessék az adatokat. Vegye figyelembe, hogy a szemantikai érettséget egy további átalakítási lépéssel lehet elérni, amely a nyers adatokat fogalmi struktúrává alakítja (vö. „A prompt gazdagítása adatbázis-információkkal”).

A következőkben a Text2SQL szolgáltatás adataival, algoritmusaival, felhasználói élményével, valamint a vonatkozó nem funkcionális követelményeivel foglalkozunk. A cikk termékmenedzsereknek, UX-tervezőknek és azoknak az adattudósoknak és mérnököknek íródott, akik Text2SQL-útjuk elején járnak. Ezeknek az embereknek nemcsak útmutatást ad az induláshoz, hanem közös tudásalapot is a termék, a technológia és az üzlet közötti interfészekről szóló vitákhoz, beleértve a kapcsolódó kompromisszumokat is. Ha már haladóbb a megvalósításban, a végén található hivatkozások egy sor mélyreható felfedezést kínálnak.

Ha ez a mélyreható oktatási tartalom hasznos az Ön számára, megteheti iratkozzon fel AI kutatási levelezőlistánkra figyelmeztetni kell, ha új anyagot adunk ki. 

1. Adat

Minden gépi tanulási törekvés az adatokkal kezdődik, ezért kezdjük a betanítás és az előrejelzés során használt bemeneti és céladatok szerkezetének tisztázásával. A cikkben végig az 2. ábra Text1SQL folyamatát használjuk futó ábrázolásunkként, és sárgával emeljük ki a jelenleg figyelembe vett komponenseket és kapcsolatokat.

1.1 Az adatok formátuma és szerkezete

A nyers Text2SQL bemenet-kimenet pár általában egy természetes nyelvű kérdésből és a megfelelő SQL-lekérdezésből áll, például:

Kérdés: "Sorolja fel az egyes felhasználók nevét és követőinek számát."

SQL lekérdezés:

válasszon nevet, követőket a felhasználói_profilokból

A betanítási adattérben a kérdések és az SQL-lekérdezések közötti leképezés sok a sokhoz:

• Egy SQL-lekérdezés sokféle kérdésre leképezhető természetes nyelven; például a fenti lekérdezés szemantikája a következőképpen fejezhető ki: "mutasd meg a követők nevét és számát felhasználónként","hány követője van egy felhasználónak?Stb.
• Az SQL szintaxis rendkívül sokoldalú, és szinte minden kérdés többféleképpen is megjeleníthető az SQL-ben. A legegyszerűbb példa a WHERE záradékok különböző sorrendje. Fejlettebb állásponton mindenki, aki végzett SQL-lekérdezés-optimalizálást, tudja, hogy sok út vezet ugyanahhoz az eredményhez, és a szemantikailag egyenértékű lekérdezések szintaxisa teljesen eltérő lehet.

A Text2SQL tanítási adatainak kézi gyűjtése különösen fárasztó. Ez nem csak az SQL-elsajátítást követeli meg az annotátortól, hanem több időt is igényel példánként, mint az általánosabb nyelvi feladatok, például a hangulatelemzés és a szövegosztályozás. A megfelelő számú képzési példa biztosítása érdekében adatbővítés használható – például LLM-ek használhatók parafrázisok generálására ugyanarra a kérdésre. [3] teljesebb áttekintést nyújt a Text2SQL adatkiegészítési technikákról.

1.2 A prompt gazdagítása adatbázis-információkkal

A Text2SQL egy algoritmus a strukturálatlan és strukturált adatok közötti interfészen. Az optimális teljesítmény érdekében mindkét típusú adatnak jelen kell lennie a képzés és az előrejelzés során. Konkrétan az algoritmusnak ismernie kell a lekérdezett adatbázist, és képesnek kell lennie a lekérdezést úgy megfogalmazni, hogy az az adatbázissal szemben végrehajtható legyen. Ez a tudás a következőket foglalhatja magában:

• Az adatbázis oszlopai és táblázatai
• Táblázatok közötti kapcsolatok (idegen kulcsok)
• Adatbázis tartalom

Az adatbázis-ismeretek beépítésére két lehetőség kínálkozik: egyrészt a betanítási adatok az adott adatbázishoz írt példákra korlátozhatók, ilyenkor a sémát közvetlenül az SQL lekérdezésből és annak a kérdésre való leképezéséből tanuljuk meg. Ez az egyadatbázis-beállítás lehetővé teszi az algoritmus optimalizálását egy egyedi adatbázishoz és/vagy vállalathoz. Ez azonban megöli a skálázhatósággal kapcsolatos ambíciókat, mivel a modellt minden egyes ügyfélhez vagy adatbázishoz finomhangolni kell. Alternatív megoldásként többadatbázisos beállítás esetén az adatbázisséma megadható a bemenet részeként, lehetővé téve az algoritmus számára, hogy „általánosítson” új, nem látott adatbázissémákat. Bár feltétlenül ezt a megközelítést kell követnie, ha a Text2SQL-t sok különböző adatbázison szeretné használni, ne feledje, hogy ez jelentős, gyors mérnöki erőfeszítést igényel. Bármilyen ésszerű üzleti adatbázis esetében a teljes információ feltüntetése a promptban rendkívül nem hatékony, és valószínűleg lehetetlen a prompt hosszának korlátai miatt. Így a gyors megfogalmazásért felelős funkciónak elég okosnak kell lennie ahhoz, hogy kiválassza az adatbázis információinak azt a részhalmazát, amely a leghasznosabb egy adott kérdésnél, és ezt a potenciálisan nem látott adatbázisok esetében is megteheti.

Végül az adatbázis-struktúra döntő szerepet játszik. Azokban a forgatókönyvekben, ahol kellőképpen uralja az adatbázist, megkönnyítheti modellje életét, ha hagyja, hogy tanuljon egy intuitív struktúrából. Alapszabály, hogy minél jobban tükrözi az adatbázisa, hogy az üzleti felhasználók hogyan beszélnek az üzletről, annál jobban és gyorsabban tanulhat belőle a modell. Ezért fontolja meg további átalakítások alkalmazását az adatokon, például normalizált vagy más módon szétszórt adatok összeállítását széles táblákba vagy adattárolókba, táblák és oszlopok egyértelmű és egyértelmű elnevezését stb. Minden üzleti tudás, amelyet előre kódolhat, csökkenti a valószínűségi tanulás terhe a modelleden, és segít jobb eredmények elérésében.

2. algoritmus

A Text2SQL egy típusa szemantikai elemzés — a szövegek logikai reprezentációkra való leképezését. Így az algoritmusnak nem csak a természetes nyelvet kell „tanulnia”, hanem a célreprezentációt is – esetünkben az SQL-t. Konkrétan a következő ismereteket kell megszereznie:

• SQL szintaxis és szemantika
• Adatbázis szerkezete
• Természetes nyelv megértése (NLU)
• Leképezés a természetes nyelv és az SQL lekérdezések között (szintaktikai, lexikai és szemantikai)

2.1 A bemenet nyelvi változékonyságának megoldása

A bemenetnél a Text2SQL fő kihívása a nyelv rugalmasságában rejlik: az Adatok formátuma és szerkezete című fejezetben leírtak szerint ugyanaz a kérdés sokféleképpen átfogalmazható. Ezenkívül a valós társalgási kontextusban számos olyan problémával kell megküzdenünk, mint például a helyesírási és nyelvtani hibák, a hiányos és kétértelmű bevitelek, a többnyelvű bevitelek stb.

Az olyan LLM-ek, mint a GPT modellek, a T5 és a CodeX egyre közelebb kerülnek ennek a kihívásnak a megoldásához. Hatalmas mennyiségű, változatos szövegből tanulva megtanulják kezelni a sok nyelvi mintát és szabálytalanságot. Végül képesek lesznek általánosítani olyan kérdések felett, amelyek szemantikailag hasonlóak, annak ellenére, hogy eltérő felületi formáik vannak. Az LLM-ek a dobozból kiindulva (zero-shot) vagy finomhangolás után alkalmazhatók. Az előbbi, bár kényelmes, alacsonyabb pontosságot eredményez. Ez utóbbi több szakértelmet és munkát igényel, de jelentősen növelheti a pontosságot.

A pontosság tekintetében a várakozásoknak megfelelően a legjobban teljesítő modellek a GPT család legújabb modelljei, beleértve a CodeX modelleket is. 2023 áprilisában a GPT-4 a pontosság drámai, több mint 5%-os növekedését eredményezte az előző csúcstechnológiához képest, és 85.3%-os pontosságot ért el (a „végrehajtás értékekkel”).[4] A nyílt forráskódú táborban a Text2SQL rejtvény megoldására tett kezdeti kísérletek az olyan automatikus kódolási modellekre összpontosultak, mint például a BERT, amelyek kiválóan teljesítenek az NLU-feladatokban. autoregresszív modelleken, például a T5 modellen. A T6 többfeladatos tanulással előképzett, így könnyen alkalmazkodik az új nyelvi feladatokhoz, beleértve a nyelvi feladatokat is. a szemantikai elemzés különböző változatai. Az autoregresszív modelleknek azonban van egy belső hibájuk a szemantikai elemzési feladatoknál: korlátlan kimeneti terük van, és nincsenek szemantikai védőkorlátok, amelyek korlátoznák a kimenetüket, ami azt jelenti, hogy elképesztően kreatívak lehetnek a viselkedésükben. Bár ez elképesztő dolog a szabad formátumú tartalom előállításához, kellemetlenséget okoz az olyan feladatoknál, mint a Text7SQL, ahol korlátozott, jól strukturált célkimenetre számítunk.

2.2 Lekérdezés ellenőrzése és javítása

Az LLM kimenet korlátozása érdekében további mechanizmusokat vezethetünk be a lekérdezés érvényesítésére és javítására. Ez a PICARD rendszerben javasolt kiegészítő validációs lépésként is megvalósítható.[8] A PICARD SQL-elemzőt használ, amely ellenőrizni tudja, hogy egy részleges SQL-lekérdezés eredményeként érvényes SQL-lekérdezéshez vezethet-e a befejezés után. Az LLM minden egyes generálási lépésében a lekérdezést érvénytelenítő tokeneket elutasítja, és a legnagyobb valószínűségű érvényes tokeneket megtartja. Mivel determinisztikus, ez a megközelítés 100%-os SQL érvényességet biztosít mindaddig, amíg az elemző betartja a helyes SQL-szabályokat. Ezenkívül leválasztja a lekérdezés érvényesítését a generálásról, így lehetővé teszi mindkét összetevő egymástól függetlenül történő karbantartását, valamint az LLM frissítését és módosítását.

Egy másik megközelítés a strukturális és SQL ismeretek közvetlen beépítése az LLM-be. Például a Graphix [9] gráf-tudatos rétegeket használ a strukturált SQL tudás beillesztésére a T5 modellbe. Ennek a megközelítésnek a valószínűségi jellege miatt a rendszert a helyes lekérdezések felé torzítja, de nem ad garanciát a sikerre.

Végül az LLM többlépcsős ügynökként is használható, amely képes önállóan ellenőrizni és javítani a lekérdezést.[10] A gondolatlánc-prompt több lépésének használatával az ügynök megbízható saját lekérdezései helyességének mérlegelésével és az esetleges hibák javításával. Ha az érvényesített lekérdezés továbbra sem hajtható végre, az SQL-kivétel-visszakövetés további visszajelzésként továbbítható az ügynöknek a fejlesztés érdekében.

A háttérben előforduló automatizált módszereken túl lehetőség van a felhasználó bevonására is a lekérdezés ellenőrzési folyamatába. Ezt részletesebben a Felhasználói élmény részben ismertetjük.

2.3 Értékelés

A Text2SQL algoritmusunk kiértékeléséhez létre kell hoznunk egy teszt (ellenőrzési) adatkészletet, futtatnunk kell az algoritmusunkat, és az eredményre releváns értékelési mérőszámokat kell alkalmazni. A képzési, fejlesztési és validációs adatokra felosztott naiv adatkészlet kérdés-lekérdezés párokon alapulna, és szuboptimális eredményekhez vezetne. Az érvényesítési lekérdezések feltárulhatnak a modell számára a képzés során, és túlságosan optimista látásmódot eredményezhetnek az általánosítási készségekkel kapcsolatban. A lekérdezés alapú felosztás, ahol az adatkészlet úgy van felosztva, hogy nem jelenik meg lekérdezés sem a betanítás, sem az érvényesítés során, igazabb eredményeket ad.

Ami a kiértékelési mérőszámokat illeti, a Text2SQL-ben az a fontos, hogy ne generáljunk olyan lekérdezéseket, amelyek teljesen azonosak az aranyszabvánnyal. Ez „pontos szál egyezés” metódus túl szigorú, és sok hamis negatív eredményt generál, mivel a különböző SQL-lekérdezések ugyanahhoz a visszaadott adatkészlethez vezethetnek. Ehelyett szeretnénk magasat elérni szemantikai pontosság és értékelje, hogy az előre jelzett és az „arany standard” lekérdezések mindig ugyanazokat az adatkészleteket adják-e vissza. Három értékelési mérőszám közelíti meg ezt a célt:

• Pontosan beállított egyezési pontosság: a generált és a cél SQL lekérdezéseket összetevőikre bontják, és az eredményül kapott halmazokat összehasonlítják az azonosság szempontjából.[11] A hiányosság itt az, hogy csak az SQL-lekérdezés sorrendváltozatait veszi figyelembe, a szemantikailag egyenértékű lekérdezések közötti kifejezettebb szintaktikai különbségeket azonban nem.
• Végrehajtási pontosság: a generált és a cél SQL lekérdezésekből származó adatkészletek azonosság szempontjából összehasonlításra kerülnek. Jó szerencsével a különböző szemantikával rendelkező lekérdezések továbbra is átmennek ezen a teszten egy adott adatbázispéldányon. Például egy olyan adatbázist feltételezve, amelyben minden felhasználó 30 év feletti, a következő két lekérdezés azonos eredményeket adna, annak ellenére, hogy eltérő szemantikával rendelkezik:
  válassza ki a * felhasználót
  válasszon *-ot attól a felhasználótól, akinek életkora >30
• Tesztkészlet pontossága: a tesztcsomag pontossága a végrehajtási pontosság fejlettebb és kevésbé megengedő változata. Minden lekérdezéshez létrejön egy adatbáziskészlet („tesztcsomag”), amelyek a lekérdezés változói, feltételei és értékei tekintetében nagymértékben különböznek egymástól. Ezután mindegyik adatbázison teszteljük a végrehajtás pontosságát. Noha további erőfeszítéseket igényel a tesztkészlet generációjának tervezése, ez a mérőszám jelentősen csökkenti a hamis pozitív eredmények kockázatát is az értékelés során..[12]

3. Felhasználói élmény

A Text2SQL jelenlegi csúcstechnológiája nem teszi lehetővé a teljesen zökkenőmentes integrációt a termelési rendszerekbe – ehelyett aktívan kell kezelni a felhasználó elvárásait és viselkedését, akinek mindig tudatában kell lennie, hogy interakcióba lép egy AI rendszer.

3.1 Hibakezelés

A Text2SQL két módban hibásodhat meg, amelyeket különböző módon kell elkapni:

• SQL hibák: a generált lekérdezés nem érvényes — vagy az SQL érvénytelen, vagy lexikai vagy szemantikai hibák miatt nem hajtható végre az adott adatbázison. Ebben az esetben az eredmény nem adható vissza a felhasználónak.
• Szemantikai hibák: a generált lekérdezés érvényes, de nem tükrözi a kérdés szemantikáját, így hibásan visszaadott adatkészlethez vezet.

A második mód különösen trükkös, mivel a „csendes hibák” kockázata – olyan hibák, amelyeket a felhasználó nem észlel – magas. A prototipikus felhasználónak nem lesz sem ideje, sem technikai készsége a lekérdezés és/vagy a kapott adatok helyességének ellenőrzésére. Ha az adatokat a valós világban döntéshozatalhoz használják fel, az ilyen jellegű kudarcok pusztító következményekkel járhatnak. Ennek elkerülése érdekében rendkívül fontos a felhasználók oktatása és megalapozása védőkorlátok üzleti szinten amelyek korlátozzák a lehetséges hatást, mint például a nagyobb hatású döntések további adatellenőrzése. Másrészt a felhasználói felület segítségével kezelhetjük az ember-gép interakciót, és segíthetjük a felhasználót a problémás kérések észlelésében és javításában.

3.2 Ember-gép interakció

A felhasználók különböző intenzitással vehetnek részt az AI-rendszerben. Kérelmenként több interakció jobb eredményekhez vezethet, de lassítja a felhasználói élmény gördülékenységét is. A hibás lekérdezések és eredmények lehetséges negatív hatásai mellett azt is mérlegelje, hogy felhasználói mennyire lesznek motiváltak arra, hogy oda-vissza visszajelzést adjanak a pontosabb eredmények elérése és a termék hosszú távú fejlesztése érdekében.

A legegyszerűbb és legkevésbé vonzó módszer az önbizalmi pontszámokkal való munka. Míg a megbízhatóság naiv számítása a generált tokenek valószínűségeinek átlagaként túlságosan leegyszerűsítő, fejlettebb módszerek, például a verbalizált visszacsatolás is használhatók. [13] A megbízhatóság megjeleníthető az interfészen, és kifejezett riasztással kiemelhető, ha veszélyesen alacsony. Így a „való világban” történő megfelelő nyomon követés felelőssége – legyen az elutasítás, elfogadás vagy az adatok további ellenőrzése – a felhasználó vállára hárul. Bár ez egy biztonságos fogadás Önnek, mint eladónak, ennek a munkának a felhasználóra való átadása a termék értékét is csökkentheti.

A második lehetőség az, hogy a felhasználót egy tisztázó párbeszédbe vonjuk be, ha alacsony megbízhatóságú, kétértelmű vagy más módon gyanús lekérdezések vannak. Például a rendszer javasolhat helyesírási vagy nyelvtani javításokat a bemeneten, és kérheti bizonyos szavak vagy nyelvtani szerkezetek egyértelművé tételét. Azt is lehetővé teheti a felhasználó számára, hogy proaktívan kérjen javításokat a lekérdezésben:[14]

FELHASZNÁLÓ: Mutasd meg John feladatait ebben a sprintben.

HELYETTES: Szeretné látni azokat a feladatokat, amelyeket John készített, vagy azokat, amelyeken dolgozik?

FELHASZNÁLÓ: feladatokat John készített

HELYETTES: Rendben, itt vannak a feladatazonosítók:

FELHASZNÁLÓ: Köszönöm, én is szeretnék bővebb információt látni a feladatokról. Kérem, sürgősség szerint is rendezze.

HELYETTES: Persze, itt vannak a feladatok rövid leírásokkal, megbízottakkal és határidőkkel, határidők szerint rendezve.

Végül, hogy a felhasználók könnyebben megértsék a lekérdezéseket, a rendszer a lekérdezés kifejezett szöveges újrafogalmazását is biztosíthatja, és megkérheti a felhasználót, hogy erősítse meg vagy javítsa ki azt.[15]

4. Nem funkcionális követelmények

Ebben a részben a Text2SQL speciális nem funkcionális követelményeit, valamint a köztük lévő kompromisszumokat tárgyaljuk. A feladat szempontjából legfontosabbnak tűnő hat követelményre összpontosítunk: pontosság, skálázhatóság, sebesség, magyarázhatóság, adatvédelem és időbeli alkalmazkodóképesség.

4.1 Pontosság

A Text2SQL esetében magasak a pontossági követelmények. Először is, a Text2SQL-t általában olyan beszélgetési beállításokban alkalmazzák, ahol az előrejelzések egyenként készülnek. Így a „nagy számok törvénye”, amely általában segít kiegyenlíteni a kötegelt előrejelzések hibáit, nem segít. Másodszor, a szintaktikai és lexikális érvényesség „kemény” feltétel: a modellnek jól formázott SQL-lekérdezést kell generálnia, potenciálisan összetett szintaxissal és szemantikával, különben a kérés nem hajtható végre az adatbázis ellen. És ha ez jól megy, és a lekérdezés végrehajtható, akkor is tartalmazhat szemantikai hibákat, és hibásan visszaadott adatkészlethez vezethet (vö. 3.1 Hibakezelés szakasz).

4.2 Méretezhetőség

A fő méretezhetőségi szempontok az, hogy a Text2SQL-t egy vagy több adatbázison kívánja-e alkalmazni – az utóbbi esetben pedig az, hogy az adatbáziskészlet ismert és zárt-e. Ha igen, akkor könnyebb dolgod lesz, mivel ezekre az adatbázisokra vonatkozó információkat felveheti a képzés során. Egy méretezhető termék forgatókönyve esetén azonban – legyen az egy önálló Text2SQL alkalmazás vagy egy meglévő adattermékbe integrálva – az algoritmusnak menet közben meg kell birkóznia bármilyen új adatbázissémával. Ez a forgatókönyv arra sem ad lehetőséget, hogy átalakítsa az adatbázis-struktúrát, hogy az intuitívabb legyen a tanuláshoz (link!). Mindez komoly kompromisszumhoz vezet a pontossággal, ami azt is megmagyarázhatja, hogy az új adatbázisok ad-hoc lekérdezését kínáló jelenlegi Text2SQL szolgáltatók miért nem értek el még jelentős piaci penetrációt.

4.3 sebesség

Mivel a Text2SQL kéréseket általában online dolgozzák fel egy beszélgetés során, a sebesség szempontja fontos a felhasználói elégedettség szempontjából. Pozitívum, hogy a felhasználók gyakran tisztában vannak azzal a ténnyel, hogy az adatkérések eltarthatnak egy bizonyos ideig, és meg kell mutatni a szükséges türelmet. Ezt a jóindulatot azonban alááshatja a chat beállítás, ahol a felhasználók tudat alatt emberszerű beszélgetési sebességet várnak el. A brute-force optimalizálási módszerek, például a modell méretének csökkentése elfogadhatatlan hatással lehet a pontosságra, ezért fontolja meg a következtetések optimalizálását, hogy megfeleljen ennek az elvárásnak.

4.4 Magyarázhatóság és átláthatóság

Ideális esetben a felhasználó nyomon követheti, hogyan jött létre a lekérdezés a szövegből, láthatja a leképezést a kérdésben és az SQL-lekérdezésben szereplő adott szavak vagy kifejezések között stb. Ez lehetővé teszi a lekérdezés ellenőrzését és a rendszerrel való interakció során a módosítások elvégzését. . Emellett a rendszer a lekérdezés kifejezett szöveges újrafogalmazását is biztosíthatja, és megkérheti a felhasználót, hogy erősítse meg vagy javítsa ki.

4.5 adatvédelem

A Text2SQL függvény elkülöníthető a lekérdezés végrehajtásától, így a visszaadott adatbázis információ láthatatlan marad. A kritikus kérdés azonban az, hogy a prompt mennyi információt tartalmaz az adatbázisról. A három lehetőség (az adatvédelmi szint csökkentésével) a következő:

• Nincs információ
• Adatbázis séma
• Adatbázis tartalom

Az adatvédelem a pontossággal megegyezik – minél kevésbé korlátozza Önt abban, hogy hasznos információkat jelenítsen meg a promptban, annál jobb az eredmény.

4.6 Időbeli alkalmazkodóképesség

A Text2SQL tartós használatához alkalmazkodni kell az adatsodródáshoz, vagyis azoknak az adatoknak a változó eloszlásához, amelyekre a modell vonatkozik. Tegyük fel például, hogy a kezdeti finomhangoláshoz használt adatok a felhasználók egyszerű lekérdezési viselkedését tükrözik, amikor elkezdik használni a BI-rendszert. Az idő múlásával a felhasználók információigénye kifinomultabbá válik, és összetettebb lekérdezéseket tesz szükségessé, ami túlterheli az Ön naiv modelljét. Emellett a vállalatváltás céljai vagy stratégiája is sodródhat, és az információs igényeket az adatbázis más területei felé terelheti. Végül egy Text2SQL-specifikus kihívás az adatbázis-sodródás. Ahogy a vállalati adatbázis bővül, új, nem látott oszlopok és táblázatok kerülnek a promptba. Míg a több adatbázisos alkalmazásokhoz tervezett Text2SQL algoritmusok jól kezelik ezt a problémát, ez jelentősen befolyásolhatja az egyadatbázisos modellek pontosságát. Mindezeket a problémákat a legjobban egy finomhangoló adatkészlettel lehet megoldani, amely tükrözi a felhasználók jelenlegi, valós viselkedését. Ezért kulcsfontosságú a felhasználói kérdések és eredmények, valamint a használat során összegyűjthető visszajelzések naplózása. Ezenkívül a szemantikus klaszterezési algoritmusok, például beágyazások vagy témamodellezés használatával, alkalmazhatók a felhasználói viselkedésben bekövetkező hosszú távú változások észlelésére, és ezek további információforrásként használhatók fel a finomhangolású adatkészlet tökéletesítéséhez.

Következtetés

Foglaljuk össze a cikk főbb pontjait:

• A Text2SQL lehetővé teszi az intuitív és demokratikus adathozzáférés megvalósítását egy vállalkozásban, így maximalizálva a rendelkezésre álló adatok értékét.
• A Text2SQL adatok a bemeneten lévő kérdésekből, a kimeneten pedig az SQL lekérdezésekből állnak. A kérdések és az SQL-lekérdezések közötti leképezés sok a sokhoz.
• Fontos, hogy a prompt részeként információkat adjon meg az adatbázisról. Ezenkívül az adatbázis szerkezete optimalizálható, hogy megkönnyítse az algoritmus megtanulását és megértését.
• A bevitelnél a fő kihívást a természetes nyelvű kérdések nyelvi változatossága jelenti, amelyeket a legkülönfélébb szövegstílusokra előképzett LLM-ek segítségével lehet megközelíteni.
• A Text2SQL kimenetének érvényes SQL-lekérdezésnek kell lennie. Ezt a megkötést úgy lehet beépíteni, hogy SQL tudást „injektálunk” az algoritmusba; alternatív megoldásként egy iteratív megközelítéssel a lekérdezés több lépésben ellenőrizhető és javítható.
• A „néma hibák” potenciálisan nagy hatása miatt, amelyek rossz adatokat adnak vissza a döntéshozatalhoz, a hibakezelés elsődleges szempont a felhasználói felületen.
• „Kibővített” módon a felhasználók aktívan részt vehetnek az SQL-lekérdezések iteratív érvényesítésében és fejlesztésében. Ez ugyan kevésbé gördülékenyebbé teszi az alkalmazást, de csökkenti a meghibásodási arányt is, lehetővé teszi a felhasználók számára az adatok rugalmasabb feltárását, és értékes jelzéseket ad a további tanuláshoz.
• A főbb nem funkcionális követelmények, amelyeket figyelembe kell venni, a pontosság, méretezhetőség, sebesség, magyarázhatóság, adatvédelem és időbeli alkalmazkodóképesség. A fő kompromisszum egyrészt a pontosság, másrészt a skálázhatóság, a sebesség és a magánélet között van.

Referenciák

[1] Ken Van Haren. 2023. Az SQL elemző lecserélése 26 rekurzív GPT prompttal

[2] Nitarshan Rajkumar et al. 2022. A nagy nyelvi modellek szövegből SQL-be ​​való képességeinek értékelése

[3] Naihao Deng et al. 2023. Legutóbbi fejlődés a szövegből SQL-be: Felmérés arról, hogy mi van és mire számítunk

[4] Mohammadreza Pourreza et al. 2023. DIN-SQL: Szövegből SQL-be ​​bontott kontextus tanulás önjavítással

[5] Victor Zhong et al. 2021. Földelt adaptáció a nullapontos végrehajtható szemantikai elemzéshez

[6] Xi Victoria Lin et al. 2020. Szöveges és táblázatos adatok áthidalása a tartományok közötti szöveg-SQL szemantikai elemzéshez

[7] Tong Guo et al. 2019. Továbbfejlesztett tartalom BERT-alapú szöveg-SQL-generálás

[8] Torsten Scholak et al. 2021. PICARD: Növekményes elemzés a nyelvi modellekből származó kényszerű autoregresszív dekódoláshoz

[9] Jinyang Li et al. 2023. Graphix-T5: Előképzett transzformátorok keverése grafikus rétegekkel a szöveg-SQL elemzéshez

[10] LangChain. 2023. LLM-ek és SQL

[11] Tao Yu et al. 2018. Spider: Nagyszabású, emberi címkével ellátott adatkészlet összetett és tartományok közötti szemantikai elemzéshez és szöveg-SQL feladathoz

[12] Ruiqi Zhong et al. 2020. Szemantikus kiértékelés szöveg-SQL-re desztillált tesztcsomagokkal

[13] Katherine Tian et al. 2023. Csak kérjen kalibrálást: Stratégiák kalibrált bizalmi pontszámok kiváltására nyelvi modellekből, emberi visszajelzésekkel finomítva

[14] Braden Hancock et al. 2019. Tanulj a párbeszédből a bevezetés után: tápláld magad, Chatbot!

[15] Ahmed Elgohary et al. 2020. Beszéljen elemzőjével: Interaktív szöveg-SQL-be ​​váltás természetes nyelvű visszajelzéssel

[16] Janna Lipenkova. 2022. Beszélj hozzám! Text2SQL beszélgetések a vállalati adatokkal, beszélgetés a New York Natural Language Processing meetupon.

Minden kép a szerzőtől származik.

Ezt a cikket eredetileg közzétették Az adattudomány felé és a szerző engedélyével újra közzétesszük a TOPBOTS-nál.

Tetszett ez a cikk? Iratkozzon fel további AI-kutatási frissítésekért.

Értesíteni fogunk, ha több ehhez hasonló összefoglaló cikket adunk ki.

Összefüggő

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• PlatoData.Network Vertical Generative Ai. Erősítse meg magát. Hozzáférés itt.
• PlatoAiStream. Web3 Intelligence. Felerősített tudás. Hozzáférés itt.
• PlatoESG. Autóipar / elektromos járművek, Carbon, CleanTech, Energia, Környezet, Nap, Hulladékgazdálkodás. Hozzáférés itt.
• BlockOffsets. A környezetvédelmi ellentételezési tulajdon korszerűsítése. Hozzáférés itt.
• Forrás: https://www.topbots.com/conversational-ai-for-data-analysis/