Keskusteleva tekoäly on edennyt pitkälle viime vuosina generatiivisen tekoälyn nopean kehityksen ansiosta, erityisesti suurten kielimallien (LLM) suorituskyvyn parannusten ansiosta, jotka on otettu käyttöön koulutustekniikoilla, kuten ohjeiden hienosäädöllä ja ihmispalautteen perusteella tapahtuvalla oppimisella. Oikein kehotettaessa nämä mallit voivat käydä johdonmukaisia ​​keskusteluja ilman tehtäväkohtaisia ​​harjoitustietoja. He eivät kuitenkaan osaa yleistää hyvin yrityskohtaisiin kysymyksiin, koska he luottavat vastauksen saamiseksi julkisiin tietoihin, joille he ovat altistuneet esikoulutuksen aikana. Tällaisista tiedoista puuttuu usein nykyaikaisissa yrityksissä saatavilla oleviin sisäisiin asiakirjoihin sisältyvää erityistietoa, jota tyypillisesti tarvitaan tarkkojen vastausten saamiseksi esimerkiksi lääketutkimuksen, taloustutkimuksen ja asiakastuen aloilla.

Luodaksemme tekoälyassistentteja, jotka pystyvät keskustelemaan yrityskohtaisen tietämyksen pohjalta, meidän on yhdistettävä nämä tehokkaat mutta yleiset LLM:t asiakirjojen sisäisiin tietokantoihin. Tätä menetelmää LLM-sukupolven kontekstin rikastamiseksi sisäisistä tietolähteistäsi haetuilla tiedoilla kutsutaan Retrieval Augmented Generation (RAG), ja se tuottaa avustajia, jotka ovat toimialuekohtaisia ​​ja luotettavampia, kuten Retrieval-Augmented Generation for Information-Intensive NLP Tasks. Toinen RAG:n suosion taustalla oleva tekijä on sen helppokäyttöisyys ja kypsät vektorihakuratkaisut, kuten Amazon Kendra (Ks. Amazon Kendra julkaisee Retrieval API:n) Ja Amazon OpenSearch-palvelu (Ks. k-Lähimmän naapurin (k-NN) haku Amazon OpenSearch Servicessä), muiden joukossa.

Suosittu RAG-suunnittelumalli semanttisella haulla ei kuitenkaan pysty vastaamaan kaikkiin asiakirjoissa oleviin kysymyksiin. Tämä pätee erityisesti kysymyksiin, jotka vaativat useiden asiakirjojen analyyttistä päättelyä. Kuvittele esimerkiksi, että suunnittelet sijoitusyhtiön ensi vuoden strategiaa. Yksi olennainen askel olisi analysoida ja vertailla ehdokasyritysten taloudellisia tuloksia ja mahdollisia riskejä. Tämä tehtävä sisältää analyyttisiin päättelykysymyksiin vastaamisen. Esimerkiksi kysely "Anna minulle viisi parasta yritystä, joilla on suurimmat tulot viimeisen 5 vuoden aikana, ja tunnista niiden tärkeimmät riskit" vaatii useita vaiheita, joista osa voi käyttää semanttista hakua, kun taas toiset vaativat analyyttisiä ominaisuuksia.

Tässä viestissä näytämme, kuinka suunnitellaan älykäs asiakirja-avustaja, joka pystyy vastaamaan analyyttisiin ja monivaiheisiin päättelykysymyksiin kolmessa osassa. Osassa 1 tarkastelemme RAG-suunnittelumallia ja sen rajoituksia analyyttisissä kysymyksissä. Sitten esittelemme sinulle monipuolisemman arkkitehtuurin, joka voittaa nämä rajoitukset. Osa 2 auttaa sinua sukeltamaan syvemmälle entiteetin poimintaprosessiin, jota käytetään strukturoidun datan valmistukseen, mikä on analyyttisten kysymysten avaintekijä. Osa 3 opastaa sinua käyttämään Amazonin kallioperä LLM:t voivat tiedustella näitä tietoja ja rakentaa LLM-agentin, joka parantaa RAG:tä analyyttisilla ominaisuuksilla, jolloin voit rakentaa älykkäitä asiakirja-avustajia, jotka voivat vastata monimutkaisiin toimialuekohtaisiin kysymyksiin useissa asiakirjoissa.

Osa 1: RAG-rajoitukset ja ratkaisun yleiskatsaus

Tässä osiossa tarkastelemme RAG-suunnittelumallia ja keskustelemme sen rajoituksista analyyttisissa kysymyksissä. Esittelemme myös monipuolisemman arkkitehtuurin, joka voittaa nämä rajoitukset.

Yleiskatsaus RAG:sta

RAG-ratkaisut ovat saaneet inspiraationsa edustusoppiminen ja semanttinen haku ideoita, jotka on vähitellen otettu käyttöön rankingongelmissa (esim. suositus ja haku) ja luonnollisen kielen käsittelyssä (NLP) vuodesta 2010 lähtien.

Nykyään käytetty suosittu lähestymistapa koostuu kolmesta vaiheesta:

1. Offline-eräkäsittelytyö syöttää dokumentteja syötetietokannasta, jakaa ne osiin, luo jokaiselle osalle upotuksen edustamaan sen semantiikkaa käyttämällä esikoulutettua upotusmallia, kuten esim. Amazon Titan upotusmallit, käyttää näitä upotuksia syötteenä semanttisen hakuindeksin luomiseen.
   
2. Kun uuteen kysymykseen vastataan reaaliajassa, syöttökysymys muunnetaan upotukseksi, jonka avulla etsitään ja poimitaan eniten samankaltaisia ​​dokumentteja käyttämällä samankaltaisuusmetriikkaa, kuten kosinin samankaltaisuutta, ja likimääräistä lähimpien naapurien algoritmia. Haun tarkkuutta voidaan myös parantaa metatietojen suodatuksella.
   
3. Kehote muodostetaan ketjuttamalla järjestelmäviesti kontekstiin, joka muodostuu vaiheessa 2 poimituista asiakirjoista, ja itse syöttökysymyksestä. Tämä kehote esitetään sitten LLM-mallille lopullisen vastauksen luomiseksi kysymykseen kontekstista.
   

Oikealla taustalla olevalla upotusmallilla, joka pystyy tuottamaan tarkat semanttiset esitykset syöttöasiakirjapaloista ja syöttökysymyksistä sekä tehokkaalla semanttisella hakumoduulilla, tämä ratkaisu pystyy vastaamaan kysymyksiin, jotka edellyttävät olemassa olevan tiedon hakemista dokumenttitietokannasta. Jos sinulla on esimerkiksi palvelu tai tuote, voit aloittaa indeksoimalla sen UKK-osion tai dokumentaation ja saada alustavan keskustelun tekoälyn räätälöitynä tarjontaasi varten.

RAG:n rajoitukset perustuvat semanttiseen hakuun

Vaikka RAG on olennainen komponentti nykyaikaisissa toimialuekohtaisissa tekoälyassistenteissa ja järkevä lähtökohta keskustelupohjaisen tekoälyn rakentamiselle erikoistuneen tietopohjan ympärille, se ei voi vastata kysymyksiin, jotka vaativat skannausta, vertailua ja perusteluja kaikissa tietopohjasi asiakirjoissa. samanaikaisesti, varsinkin kun lisäys perustuu pelkästään semanttiseen hakuun.

Ymmärtääksemme nämä rajoitukset, tarkastellaanpa uudelleen esimerkkiä sijoitusten päättämisestä taloudellisten raporttien perusteella. Jos käyttäisimme RAG:ta keskustellaksemme näiden raporttien kanssa, voisimme esittää kysymyksiä, kuten "Mitä riskejä yritys X kohtasi vuonna 2022" tai "Mikä on yrityksen Y nettotulo vuonna 2022?" Jokaisessa näistä kysymyksistä vastaavaa upotusvektoria, joka koodaa kysymyksen semanttisen merkityksen, käytetään hakemaan hakuhakemistosta saatavilla olevien K-semanttisesti samankaltaisten asiakirjojen palasia. Tämä saavutetaan tyypillisesti käyttämällä likimääräistä lähimpien naapureiden ratkaisua, kuten FAISS, NMSLIB, pgvector tai muut, jotka pyrkivät löytämään tasapainon hakunopeuden ja palauttamisen välillä saavuttaakseen reaaliaikaisen suorituskyvyn säilyttäen samalla tyydyttävän tarkkuuden.

Edellinen lähestymistapa ei kuitenkaan pysty vastaamaan tarkasti analyyttisiin kysymyksiin kaikissa asiakirjoissa, kuten "Mitkä ovat viisi parasta yritystä, joilla on suurimmat nettotulot vuonna 5?"

Tämä johtuu siitä, että semanttinen haku yrittää löytää K eniten samankaltaista asiakirjapalaa syötekysymykseen. Mutta koska mikään asiakirjoista ei sisällä kattavia yhteenvetoja tuloista, se palauttaa osia asiakirjoista, jotka sisältävät vain mainintoja "nettotuloista" ja mahdollisesti "vuodesta 2022", ilman että se täytä olennaista ehtoa keskittyä eniten tuottaviin yrityksiin. Jos esitämme nämä hakutulokset LLM:lle kontekstina syötekysymykseen vastaamiseksi, se voi muotoilla harhaanjohtavan vastauksen tai kieltäytyä vastaamasta, koska vaaditut oikeat tiedot puuttuvat.

Nämä rajoitukset tulevat suunnittelusta, koska semanttinen haku ei suorita perusteellista skannausta kaikista upotusvektoreista löytääkseen asiaankuuluvia asiakirjoja. Sen sijaan se käyttää likimääräisiä lähimmän naapurin menetelmiä kohtuullisen hakunopeuden ylläpitämiseksi. Keskeinen tehokkuusstrategia näissä menetelmissä on upotustilan segmentointi ryhmiin indeksoinnin aikana. Tämä mahdollistaa nopean tunnistamisen, mitkä ryhmät voivat sisältää relevantteja upotuksia noudon aikana, ilman parivertailua. Lisäksi jopa perinteiset lähinaapurien tekniikat, kuten KNN, jotka skannaavat kaikki asiakirjat, laskevat vain perusetäisyysmittauksia eivätkä sovellu analyyttisen päättelyn vaatimiin monimutkaisiin vertailuihin. Siksi semanttisella haulla varustettua RAG:ta ei ole räätälöity vastaamaan kysymyksiin, jotka edellyttävät analyyttistä päättelyä kaikissa asiakirjoissa.

Näiden rajoitusten voittamiseksi ehdotamme ratkaisua, joka yhdistää RAG:n metatietojen ja entiteettien purkamiseen, SQL-kyselyyn ja LLM-agenteihin, kuten seuraavissa osissa kuvataan.

RAG-rajoitusten ylittäminen metatietojen, SQL- ja LLM-agenttien avulla

Tutkitaan tarkemmin kysymystä, jossa RAG epäonnistuu, jotta voimme jäljittää perustelut, joita tarvitaan siihen tehokkaaseen vastaamiseen. Tämän analyysin pitäisi ohjata meidät oikeaan lähestymistapaan, joka voisi täydentää RAG:tä kokonaisratkaisussa.

Harkitse kysymystä: "Mitkä ovat viisi suurinta yritystä, joilla on suurin liikevaihto vuonna 5?"

Jotta voimme vastata tähän kysymykseen, meidän on:

1. Tunnista kunkin yrityksen tulot.
2. Suodata alas säilyttääksesi vuoden 2022 tulot jokaiselle niistä.
3. Lajittele tulot laskevaan järjestykseen.
4. Leikkaa viisi suurinta tuloa yritysten nimien rinnalla.

Tyypillisesti nämä analyyttiset toiminnot tehdään strukturoidulle datalle käyttämällä työkaluja, kuten panda- tai SQL-koneita. Jos meillä olisi pääsy sarakkeet sisältävään SQL-taulukkoon company, revenueja year, voisimme vastata kysymykseemme helposti suorittamalla SQL-kyselyn, joka on samanlainen kuin seuraava esimerkki:

SELECT company, revenue FROM table_name WHERE year = 2022 ORDER BY revenue DESC LIMIT 5;

Kun tallennat jäsennellyt metatiedot SQL-taulukkoon, joka sisältää tietoja oleellisista entiteeteista, voit vastata monenlaisiin analyyttisiin kysymyksiin kirjoittamalla oikean SQL-kyselyn. Tästä syystä täydennämme ratkaisussamme RAG:ta reaaliaikaisella SQL-kyselymoduulilla SQL-taulukkoa vasten, joka täyttää offline-prosessissa poimitut metatiedot.

Mutta kuinka voimme toteuttaa ja integroida tämän lähestymistavan LLM-pohjaiseen keskustelun tekoälyyn?

SQL-analyyttisen päättelyn lisäämiseen on kolme vaihetta:

• Metatietojen purkaminen – Pura metatiedot strukturoimattomista asiakirjoista SQL-taulukkoon
• Teksti SQL:ään – Muotoile SQL-kyselyitä syötekysymyksistä tarkasti käyttämällä LLM:ää
• Työkalun valinta – Tunnista, pitääkö kysymykseen vastata RAG:n vai SQL-kyselyn avulla

Näiden vaiheiden toteuttamiseksi ymmärrämme ensin, että tietojen poimiminen jäsentelemättömistä asiakirjoista on perinteinen NLP-tehtävä, jossa LLM:t osoittavat lupaavia saavuttaa korkean tarkkuuden nolla- tai muutaman otoksen oppimisen avulla. Toiseksi näiden mallien kyky luoda SQL-kyselyitä luonnollisesta kielestä on todistettu jo vuosia, kuten 2020 vapautetaan of Amazon QuickSight Q. Lopuksi oikean työkalun automaattinen valinta tiettyyn kysymykseen parantaa käyttökokemusta ja mahdollistaa monimutkaisiin kysymyksiin vastaamisen monivaiheisen päättelyn avulla. Tämän ominaisuuden toteuttamiseksi perehdymme LLM-agentteihin myöhemmässä osassa.

Yhteenvetona totean, että ehdottamamme ratkaisu koostuu seuraavista ydinkomponenteista:

• Semanttinen hakuhaku sukupolven kontekstin lisäämiseksi
• Strukturoitu metatietojen poiminta ja kyselyt SQL:llä
• Agentti, joka osaa käyttää oikeita työkaluja vastatakseen kysymykseen

Ratkaisun yleiskatsaus

Seuraava kaavio kuvaa ratkaisun yksinkertaistettua arkkitehtuuria. Se auttaa sinua tunnistamaan ja ymmärtämään ydinkomponenttien roolin ja niiden vuorovaikutuksen toteuttaakseen täyden LLM-avustajan käyttäytymisen. Numerointi on linjassa toimintojen järjestyksen kanssa tätä ratkaisua toteutettaessa.

Käytännössä toteutimme tämän ratkaisun seuraavassa yksityiskohtaisessa arkkitehtuurissa kuvatulla tavalla.

Tälle arkkitehtuurille ehdotamme toteutusta GitHub, jossa on löyhästi kytketyt komponentit, joissa taustaosa (5), dataliukuhihnat (1, 2, 3) ja etupää (4) voivat kehittyä erikseen. Tämä yksinkertaistaa osaamisalueiden välistä yhteistyötä, kun räätälöidään ja parannetaan ratkaisua tuotantoa varten.

Ota ratkaisu käyttöön

Asenna tämä ratkaisu AWS-tilillesi suorittamalla seuraavat vaiheet:

1. Kloonaa arkisto GitHubissa.
2. Asenna taustaosa AWS Cloud Development Kit (AWS CDK) sovelluksen:
   1. Avaa backend kansio.
   2. ajaa npm install asentaaksesi riippuvuuksia.
   3. Jos et ole koskaan käyttänyt AWS CDK:ta nykyisellä tilillä ja alueella, suorita bootstrapping with npx cdk bootstrap.
   4. ajaa npx cdk deploy sijoittaa pino.
3. Suorita vaihtoehtoisesti streamlit-ui seuraavasti:
   1. Suosittelemme tämän arkiston kloonaamista Amazon SageMaker Studio ympäristöön. Lisätietoja on kohdassa Ota käyttöön Amazon SageMaker -verkkotunnus pika-asetuksella.
   2. Sisällä frontend/streamlit-ui kansio, suorita bash run-streamlit-ui.sh.
   3. Avaa demo valitsemalla linkki seuraavassa muodossa: https://{domain_id}.studio.{region}.sagemaker.aws/jupyter/default/proxy/{port_number}/.
4. Lopuksi voit ajaa Amazon Sage Maker kohdassa määritelty putki data-pipelines/04-sagemaker-pipeline-for-documents-processing.ipynb muistikirja syötettyjen PDF-dokumenttien käsittelemiseksi ja SQL-taulukon ja LLM-avustajan käyttämän semanttisen hakuindeksin valmistelemiseksi.

Tämän postauksen loppuosassa keskitymme selittämään tärkeimmät komponentit ja suunnitteluvalinnat, jotta voimme toivottavasti inspiroida sinua suunnitteleessasi omaa tekoälyavustajaasi sisäisen tietopohjan pohjalta. Oletamme, että komponentit 1 ja 4 ovat yksinkertaisia ​​ymmärtää, ja keskitymme ydinkomponentteihin 2, 3 ja 5.

Osa 2: Kokonaisuuden erotusputki

Tässä osiossa sukeltamme syvemmälle entiteetin poimintaputkeen, jota käytetään strukturoidun tiedon valmistukseen, joka on keskeinen ainesosa analyyttisiin kysymyksiin vastaamisessa.

Tekstin poiminta

Asiakirjat tallennetaan yleensä PDF-muodossa tai skannattuina kuvina. Ne voidaan muodostaa yksinkertaisista kappaleasetteluista tai monimutkaisista taulukoista, ja ne voivat sisältää digitaalista tai käsinkirjoitettua tekstiä. Tietojen poimimiseksi oikein meidän on muutettava nämä raaka-asiakirjat tavalliseksi tekstiksi säilyttäen samalla niiden alkuperäinen rakenne. Voit tehdä tämän käyttämällä Amazonin teksti, joka on koneoppimispalvelu (ML), joka tarjoaa kypsät sovellusliittymät tekstille, taulukoille ja lomakkeiden poimimiselle digitaalisista ja käsinkirjoitetuista syötteistä.

Komponentissa 2 poimimme tekstiä ja taulukoita seuraavasti:

1. Jokaisen asiakirjan kohdalla soitamme Amazon Textractiin poimimaan tekstin ja taulukot.
2. Käytämme seuraavaa Python-skripti luodaksesi taulukoita uudelleen panda-tietokehyksenä.
3. Yhdistämme tulokset yhdeksi asiakirjaksi ja lisäämme taulukoita alaspäin.

Tämä prosessi on hahmoteltu seuraavassa vuokaaviossa ja se on konkreettisesti esitelty seuraavassa notebooks/03-pdf-document-processing.ipynb.

Kokonaisuuden purkaminen ja kyselyt LLM:ien avulla

Jotta voit vastata analyyttisiin kysymyksiin tehokkaasti, sinun on poimittava asiaankuuluvat metatiedot ja entiteetit asiakirjasi tietokannasta helposti käytettävissä olevaan strukturoituun tietomuotoon. Suosittelemme SQL:n käyttöä näiden tietojen tallentamiseen ja vastausten hakemiseen sen suosion, helppokäyttöisyyden ja skaalautuvuuden vuoksi. Tämä valinta hyötyy myös todistetusta kielimallien kyvystä luoda SQL-kyselyitä luonnollisesta kielestä.

Tässä osiossa sukeltamme syvemmälle seuraaviin osiin, jotka mahdollistavat analyyttisten kysymysten esittämisen:

• Eräprosessi, joka poimii jäsenneltyä dataa strukturoimattomasta tiedosta LLM:ien avulla
• Reaaliaikainen moduuli, joka muuntaa luonnollisen kielen kysymykset SQL-kyselyiksi ja hakee tulokset SQL-tietokannasta

Voit poimia asiaankuuluvat metatiedot analyyttisten kysymysten tueksi seuraavasti:

1. Määritä JSON-skeema tiedoille, jotka sinun on purettava. Se sisältää kuvauksen jokaisesta kentästä ja sen tietotyypistä sekä esimerkkejä odotetuista arvoista.
2. Pyydä kunkin asiakirjan LLM:ää JSON-skeemalla ja pyydä sitä poimimaan tarvittavat tiedot tarkasti.
3. Kun asiakirjan pituus ylittää kontekstin pituuden ja pienentääksesi LLM:iden purkamiskustannuksia, voit käyttää semanttista hakua hakeaksesi ja esittääksesi tarvittavat asiakirjapalat LLM:lle purkamisen aikana.
4. Jäsennä JSON-tulostus ja vahvista LLM-poiminta.
5. Vaihtoehtoisesti voit varmuuskopioida Amazon S3:n tulokset CSV-tiedostoina.
6. Lataa SQL-tietokantaan myöhempää kyselyä varten.

Tätä prosessia hallitsee seuraava arkkitehtuuri, jossa tekstimuodossa olevat asiakirjat ladataan Python-skriptillä, joka suoritetaan Amazon SageMaker -käsittely purkutyötä.

Luomme kullekin entiteettiryhmälle dynaamisesti kehotteen, joka sisältää selkeän kuvauksen tiedonpoimintatehtävästä ja sisältää JSON-skeeman, joka määrittää odotetun tulosteen ja sisältää asiaankuuluvat asiakirjapalat kontekstina. Lisäämme myös muutamia esimerkkejä syötteestä ja oikeasta lähdöstä parantaaksemme poimintakykyä muutaman otoksen oppimisella. Tämä on osoitettu mm notebooks/05-entities-extraction-to-structured-metadata.ipynb.

Osa 3: Rakenna agenttiasiakirja-avustaja Amazon Bedrockin avulla

Tässä osiossa esittelemme, kuinka Amazon Bedrock LLM:itä käytetään tietojen kyselyyn ja LLM-agentin rakentamiseen, joka parantaa RAG:ta analyyttisillä ominaisuuksilla, jolloin voit rakentaa älykkäitä asiakirja-avustajia, jotka voivat vastata monimutkaisiin toimialuekohtaisiin kysymyksiin useissa asiakirjoissa. Voit viitata Lambda-toiminto GitHubissa tässä osassa kuvatun agentin ja työkalujen konkreettiseen toteuttamiseen.

Muotoile SQL-kyselyitä ja vastaa analyyttisiin kysymyksiin

Nyt kun meillä on jäsennelty metatietovarasto, jossa asiaankuuluvat entiteetit on purettu ja ladattu SQL-tietokantaan, josta voimme tehdä kyselyitä, jää kysymys, kuinka luoda oikea SQL-kysely syötetyistä luonnollisen kielen kysymyksistä?

Nykyaikaiset LLM:t ovat hyviä luomaan SQL:ää. Esimerkiksi, jos pyydät Anthropic Claude LLM:ltä kautta Amazonin kallioperä SQL-kyselyn luomiseen näet uskottavia vastauksia. Meidän on kuitenkin noudatettava muutamia sääntöjä kirjoittaessamme kehotetta tarkempien SQL-kyselyiden saavuttamiseksi. Nämä säännöt ovat erityisen tärkeitä monimutkaisissa kyselyissä hallusinaatioiden ja syntaksivirheiden vähentämiseksi:

• Kuvaile tehtävä tarkasti kehotteessa
• Sisällytä SQL-taulukoiden skeemat kehotteeseen, kuvaile samalla taulukon jokainen sarake ja määritä sen tietotyyppi
• Kerro LLM:lle nimenomaisesti, että hän käyttää vain olemassa olevia sarakkeiden nimiä ja tietotyyppejä
• Lisää muutama rivi SQL-taulukoita

Voit myös jälkikäsitellä luodun SQL-kyselyn käyttämällä a Linter kuten sqlfluff muotoilun korjaamiseen tai jäsentimeen, kuten sqlglot tunnistaa syntaksivirheet ja optimoi kyselyn. Lisäksi, jos suorituskyky ei täytä vaatimuksia, voit antaa kehotteessa muutamia esimerkkejä ohjataksesi mallia muutaman kerran oppimalla luomaan tarkempia SQL-kyselyjä.

Toteutuksen näkökulmasta käytämme a AWS Lambda toiminto ohjaamaan seuraavan prosessin:

1. Soita Anthropic Claude -malli Amazon Bedrockissa syöttökysymyksellä saadaksesi vastaava SQL-kysely. Tässä käytämme SQL-tietokanta luokka LangChainista lisätäksesi asiaankuuluvien SQL-taulukoiden skeemakuvaukset ja käyttää mukautettua kehotetta.
2. Jäsennä, vahvista ja suorita SQL-kysely Amazon Aurora PostgreSQL-yhteensopiva versio tietokanta.

Ratkaisun tämän osan arkkitehtuuri on korostettu seuraavassa kaaviossa.

Turvallisuusnäkökohdat SQL-injektiohyökkäysten estämiseksi

Koska annamme tekoälyavustajan tehdä kyselyitä SQL-tietokannasta, meidän on varmistettava, että tämä ei aiheuta tietoturva-aukkoja. Tämän saavuttamiseksi ehdotamme seuraavia suojaustoimenpiteitä SQL-injektiohyökkäysten estämiseksi:

• Käytä vähiten IAM-oikeuksia – Rajoita sen Lambda-funktion käyttöoikeuksia, joka suorittaa SQL-kyselyt käyttämällä an AWS-henkilöllisyyden ja käyttöoikeuksien hallinta (IAM) politiikka ja rooli, joka seuraa vähiten etuoikeusperiaate. Tässä tapauksessa myönnämme vain luku -oikeuden.
• Rajoita tietojen käyttöä – Tarjoa pääsy vain vähimmäismäärään taulukoita ja sarakkeita tietojen paljastamishyökkäyksen estämiseksi.
• Lisää moderointitaso – Ota käyttöön moderointikerros, joka havaitsee nopeat injektioyritykset varhaisessa vaiheessa ja estää niitä leviämästä muuhun järjestelmään. Se voi olla sääntöpohjaisten suodattimien, samankaltaisuussovituksen ja tunnettujen pikainjektioesimerkkien tietokannan tai ML-luokittimen muodossa.

Semanttinen hakuhaku sukupolven kontekstin lisäämiseksi

Ehdottamamme ratkaisu käyttää RAG:ta semanttisella haulla komponentissa 3. Voit toteuttaa tämän moduulin käyttämällä Amazon Bedrockin tietokannat. Lisäksi RAG:n toteuttamiseen on monia muita vaihtoehtoja, kuten Amazon Kendra Retrieval API, Amazon OpenSearch vektoritietokantaja Amazon Aurora PostgreSQL pgvectorilla, muiden joukossa. Avoimen lähdekoodin paketti aws-genai-llm-chatbot osoittaa, kuinka monia näistä vektorihakuvaihtoehdoista voidaan käyttää LLM-käyttöisen chatbotin toteuttamiseen.

Koska tarvitsemme tässä ratkaisussa sekä SQL-kyselyn että vektorihaun, päätimme käyttää Amazon Aurora PostgreSQL:ää pgvector laajennus, joka tukee molempia ominaisuuksia. Siksi toteutamme semanttisen haun RAG-komponentin seuraavalla arkkitehtuurilla.

Kysymyksiin vastaaminen edellistä arkkitehtuuria käyttäen tapahtuu kahdessa päävaiheessa.

Ensinnäkin offline-eräprosessi, joka suoritetaan SageMaker Processing -työnä, luo semanttisen hakuindeksin seuraavasti:

1. Joko määräajoin tai uusien asiakirjojen vastaanottamisen yhteydessä suoritetaan SageMaker-työ.
2. Se lataa tekstiasiakirjat Amazon S3:sta ja jakaa ne päällekkäisiksi paloiksi.
3. Jokaiselle palalle se käyttää Amazon Titan -upotusmallia upotusvektorin luomiseen.
4. Se käyttää PGVector luokkaa LangChainista sulauttaakseen upotukset dokumenttilohkoineen ja metatiedoineen Amazon Aurora PostgreSQL:ään ja luodakseen semanttisen hakuindeksin kaikille upotusvektoreille.

Toiseksi, reaaliajassa ja jokaiselle uudelle kysymykselle rakennamme vastauksen seuraavasti:

1. Lambda-toiminnolla toimiva orkesteri vastaanottaa kysymyksen.
2. Orkesteri upottaa kysymyksen samalla upotusmallilla.
3. Se hakee tärkeimmän K tärkeimmän asiakirjan palaset PostgreSQL:n semanttisesta hakuhakemistosta. Se käyttää valinnaisesti metatietojen suodatusta tarkkuuden parantamiseksi.
4. Nämä palat lisätään dynaamisesti LLM-kehotteeseen syöttökysymyksen rinnalle.
5. Kehotetta esitetään Anthropic Claudelle Amazon Bedrockissa, jotta se neuvoo vastaamaan syöttökysymykseen käytettävissä olevan kontekstin perusteella.
6. Lopuksi luotu vastaus lähetetään takaisin orkestraattorille.

Agentti, joka pystyy käyttämään työkaluja järkeilyyn ja toimintaan

Toistaiseksi tässä viestissä olemme käsitelleet joko RAG:tä tai analyyttistä päättelyä vaativien kysymysten käsittelyä erikseen. Monet tosielämän kysymykset vaativat kuitenkin molempia kykyjä, joskus useiden päättelyvaiheiden kautta, lopullisen vastauksen saavuttamiseksi. Näiden monimutkaisempien kysymysten tukemiseksi meidän on otettava käyttöön agentin käsite.

LLM-agentit, kuten Amazon Bedrockin edustajat, ovat äskettäin nousseet lupaavaksi ratkaisuksi, joka pystyy käyttämään LLM:itä järkeilemään ja mukautumaan nykyiseen kontekstiin ja valitsemaan sopivat toimet vaihtoehtoluettelosta, joka tarjoaa yleisen ongelmanratkaisukehyksen. Kuten kohdassa on käsitelty LLM Powered Autonomous Agents, LLM-agenteille on olemassa useita kehotusstrategioita ja suunnittelumalleja, jotka tukevat monimutkaista päättelyä.

Yksi tällainen suunnittelumalli on Reason and Act (ReAct), joka esiteltiin vuonna ReAct: Synergisoiva päättely ja toiminta kielimalleissa. ReActissa agentti ottaa syötteeksi tavoitteen, joka voi olla kysymys, tunnistaa puuttuvat tiedot vastatakseen siihen ja ehdottaa iteratiivisesti oikeaa työkalua tiedon keräämiseen käytettävissä olevien työkalujen kuvausten perusteella. Saatuaan vastauksen tietystä työkalusta LLM arvioi uudelleen, onko sillä kaikki tiedot, joita se tarvitsee vastatakseen täydellisesti kysymykseen. Jos ei, se tekee toisen päättelyvaiheen ja käyttää samaa tai toista työkalua lisätietojen keräämiseen, kunnes lopullinen vastaus on valmis tai raja saavutetaan.

Seuraava järjestyskaavio selittää, kuinka ReAct-agentti työskentelee vastatakseen kysymykseen "Anna minulle viisi parasta yritystä, joilla on suurimmat tulot viimeisen 5 vuoden aikana, ja tunnista ylimpään yritykseen liittyvät riskit."

Yksityiskohdat tämän lähestymistavan toteuttamisesta Pythonissa on kuvattu julkaisussa Mukautettu LLM-agentti. Ratkaisussamme agentti ja työkalut on toteutettu seuraavalla korostetulla osittaisella arkkitehtuurilla.

Syötekysymykseen vastaamiseksi käytämme AWS-palveluita seuraavasti:

1. Käyttäjä syöttää kysymyksensä käyttöliittymän kautta, joka kutsuu API:n päälle Amazon API -yhdyskäytävä.
2. API-yhdyskäytävä lähettää kysymyksen Lambda-funktiolle, joka toteuttaa agenttisuorittimen.
3. Agentti kutsuu LLM:ää kehotteessa, joka sisältää kuvauksen käytettävissä olevista työkaluista, ReAct-käskymuodon ja syöttökysymyksen, ja jäsentää sitten seuraavan toiminnon suoritettavana.
4. Toiminto sisältää kutsuttavan työkalun ja toimintosyötteen.
5. Jos käytettävä työkalu on SQL, agentin suorittaja kutsuu SQLQA:ta, joka muuntaa kysymyksen SQL:ksi ja suorittaa sen. Sitten se lisää tuloksen kehotteeseen ja soittaa LLM:lle uudelleen nähdäkseen, voiko se vastata alkuperäiseen kysymykseen vai tarvitaanko lisätoimia.
6. Vastaavasti, jos käytettävä työkalu on semanttinen haku, toimintosyöte jäsennetään ja sitä käytetään PostgreSQL:n semanttisesta hakuhakemistosta. Se lisää tulokset kehotteeseen ja tarkistaa, pystyykö LLM vastaamaan tai tarvitseeko se muita toimia.
7. Kun kaikki kysymykseen vastaamiseen tarvittavat tiedot ovat saatavilla, LLM-agentti muotoilee lopullisen vastauksen ja lähettää sen takaisin käyttäjälle.

Voit laajentaa agenttia lisätyökaluilla. Toteutuksessa saatavilla GitHub, esittelemme, kuinka voit lisätä hakukoneen ja laskimen lisätyökaluina edellä mainittuun SQL-koneeseen ja semanttisiin hakutyökaluihin. Käynnissä olevan keskusteluhistorian tallentamiseen käytämme Amazon DynamoDB pöytä.

Tähänastisten kokemustemme perusteella olemme havainneet, että seuraavat ovat avaimia menestyvälle agentille:

• Taustalla oleva LLM, joka pystyy päättelemään ReAct-muodossa
• Selkeä kuvaus käytettävissä olevista työkaluista, milloin niitä tulee käyttää, ja kuvaus niiden syöttöargumenteista sekä mahdollisesti esimerkki syötteestä ja odotetusta tuloksesta
• Selkeä linjaus ReAct-muodosta, jota LLM:n on noudatettava
• Oikeat työkalut liiketoimintakysymyksen ratkaisemiseen ovat LLM-agentin käytettävissä
• LLM-agentin vastausten tulosten jäsentäminen oikein sen syiden mukaan

Kustannusten optimoimiseksi suosittelemme tallentamaan yleisimmät kysymykset ja niiden vastaukset välimuistiin ja päivittämään tämän välimuistin säännöllisesti, jotta puhelut taustalla olevalle LLM:lle vähenevät. Voit esimerkiksi luoda semanttisen hakuindeksin yleisimmistä kysymyksistä, kuten aiemmin on selitetty, ja kohdistaa uuden käyttäjän kysymyksen indeksiin ennen kuin soitat LLM:lle. Jos haluat tutustua muihin välimuistivaihtoehtoihin, katso LLM-välimuistiintegraatiot.

Tukee muita muotoja, kuten video-, kuva-, ääni- ja 3D-tiedostoja

Voit soveltaa samaa ratkaisua erityyppisiin tietoihin, kuten kuviin, videoihin, ääniin ja 3D-suunnittelutiedostoihin, kuten CAD- tai mesh-tiedostoihin. Tämä edellyttää vakiintuneiden ML-tekniikoiden käyttämistä tiedoston sisällön kuvaamiseen tekstinä, joka voidaan sitten sisällyttää aiemmin tutkimaanmme ratkaisuun. Tämän lähestymistavan avulla voit käydä laadunvarmistuskeskusteluja näistä erilaisista tietotyypeistä. Voit esimerkiksi laajentaa asiakirjatietokantaasi luomalla kuvien, videoiden tai äänisisällön tekstikuvauksia. Voit myös parantaa metatietotaulukkoa tunnistamalla ominaisuuksia luokittelun tai objektien tunnistuksen avulla näissä muodoissa oleville elementeille. Kun nämä poimitut tiedot on indeksoitu joko metatietosäilöön tai asiakirjojen semanttiseen hakuhakemistoon, ehdotetun järjestelmän yleinen arkkitehtuuri pysyy suurelta osin yhtenäisenä.

Yhteenveto

Tässä viestissä osoitimme, kuinka LLM:ien käyttö RAG-suunnittelumallin kanssa on välttämätöntä toimialuekohtaisen AI-avustajan rakentamiseksi, mutta se ei riitä saavuttamaan vaadittua luotettavuustasoa liikearvon tuottamiseksi. Tämän vuoksi ehdotimme suositun RAG-suunnittelumallin laajentamista agenttien ja työkalujen käsitteillä, joissa työkalujen joustavuus mahdollistaa sekä perinteisten NLP-tekniikoiden että nykyaikaisten LLM-ominaisuuksien käytön mahdollistaaksemme tekoälyassistentin, jolla on enemmän vaihtoehtoja etsiä tietoa ja auttaa. käyttäjiä ratkaisemaan liiketoimintaongelmia tehokkaasti.

Ratkaisu esittelee suunnitteluprosessin kohti LLM-assistenttia, joka pystyy vastaamaan erilaisiin haku-, analyyttisiin ja monivaiheisiin päättelykysymyksiin kaikissa tietopohjassasi. Korostimme myös taaksepäin ajattelun tärkeyttä niiden kysymysten ja tehtävien perusteella, joissa LLM-assistenttisi odotetaan auttavan käyttäjiä. Tässä tapauksessa suunnittelumatka johti meidät arkkitehtuuriin, jossa on kolme komponenttia: semanttinen haku, metatietojen poiminta ja SQL-kysely sekä LLM-agentti ja -työkalut, jotka ovat mielestämme riittävän yleisiä ja joustavia useisiin käyttötapauksiin. Uskomme myös, että saamalla inspiraatiota tästä ratkaisusta ja sukeltamalla syvälle käyttäjien tarpeisiin, voit laajentaa tätä ratkaisua edelleen kohti sinulle parhaiten sopivaa ratkaisua.

---

Tietoja kirjoittajista

Mohamed Ali Jamaoui on vanhempi ML-prototyyppiarkkitehti, jolla on 10 vuoden kokemus tuotannon koneoppimisesta. Hän nauttii liike-elämän ongelmien ratkaisemisesta koneoppimisen ja ohjelmistosuunnittelun avulla ja auttaa asiakkaita luomaan liiketoiminta-arvoa ML:n avulla. Osana AWS EMEA Prototyping and Cloud Engineeringiä hän auttaa asiakkaita rakentamaan liiketoimintaratkaisuja, jotka hyödyntävät innovaatioita MLOP:issa, NLP:ssä, CV:ssä ja LLM:issä.

Giuseppe Hannen on ProServe Associate Consultant. Giuseppe soveltaa analyyttisiä taitojaan yhdessä AI&ML:n kanssa kehittääkseen selkeitä ja tehokkaita ratkaisuja asiakkailleen. Hän rakastaa keksiä yksinkertaisia ​​ratkaisuja monimutkaisiin ongelmiin, erityisesti niihin, jotka liittyvät uusimpaan teknologiseen kehitykseen ja tutkimukseen.

Laurens kymmenen Cate on vanhempi datatieteilijä. Laurens työskentelee yritysasiakkaiden kanssa EMEA-alueella ja auttaa heitä nopeuttamaan liiketoimintaansa käyttämällä AWS AI/ML -teknologioita. Hän on erikoistunut NLP-ratkaisuihin ja keskittyy Supply Chain & Logistics -teollisuuteen. Vapaa-ajallaan hän pitää lukemisesta ja taiteesta.

Irina Radu on Prototyping Engagement Manager, osa AWS EMEA Prototyping and Cloud Engineeringiä. Hän auttaa asiakkaita saamaan parhaan hyödyn uusimmasta tekniikasta, innovoimaan nopeammin ja ajattelemaan laajemmin.

• SEO-pohjainen sisällön ja PR-jakelu. Vahvista jo tänään.
• PlatoData.Network Vertical Generatiivinen Ai. Vahvista itseäsi. Pääsy tästä.
• PlatoAiStream. Web3 Intelligence. Tietoa laajennettu. Pääsy tästä.
• PlatoESG. hiili, CleanTech, energia, ympäristö, Aurinko, Jätehuolto. Pääsy tästä.
• PlatonHealth. Biotekniikan ja kliinisten kokeiden älykkyys. Pääsy tästä.
• Lähde: https://aws.amazon.com/blogs/machine-learning/boosting-rag-based-intelligent-document-assistants-using-entity-extraction-sql-querying-and-agents-with-amazon-bedrock/