Conversational AI har kommet langt de siste årene takket være den raske utviklingen innen generativ AI, spesielt ytelsesforbedringene til store språkmodeller (LLMs) introdusert av treningsteknikker som instruksjonsfinjustering og forsterkningslæring fra menneskelig tilbakemelding. Når du blir bedt på riktig måte, kan disse modellene føre sammenhengende samtaler uten oppgavespesifikke treningsdata. Imidlertid kan de ikke generalisere godt til bedriftsspesifikke spørsmål fordi de, for å generere et svar, er avhengige av de offentlige dataene de ble utsatt for under føropplæringen. Slike data mangler ofte den spesialiserte kunnskapen i interne dokumenter som er tilgjengelige i moderne virksomheter, noe som vanligvis er nødvendig for å få nøyaktige svar på domener som farmasøytisk forskning, finansiell etterforskning og kundestøtte.
For å lage AI-assistenter som er i stand til å ha diskusjoner basert på spesialisert bedriftskunnskap, må vi koble disse kraftige, men generiske LLM-ene til interne kunnskapsbaser for dokumenter. Denne metoden for å berike LLM-generasjonskonteksten med informasjon hentet fra dine interne datakilder kalles Retrieval Augmented Generation (RAG), og produserer assistenter som er domenespesifikke og mer pålitelige, som vist av Gjenvinningsutvidet generasjon for kunnskapsintensive NLP-oppgaver. En annen driver bak RAGs popularitet er dens enkle implementering og eksistensen av modne vektorsøkeløsninger, slik som de som tilbys av Amazon Kendra (Se Amazon Kendra lanserer Retrieval API) Og Amazon OpenSearch-tjeneste (Se k-Nearest Neighbor (k-NN) søk i Amazon OpenSearch Service), blant andre.
Det populære RAG-designmønsteret med semantisk søk kan imidlertid ikke svare på alle typer spørsmål som er mulig på dokumenter. Dette gjelder spesielt for spørsmål som krever analytisk resonnement på tvers av flere dokumenter. Tenk deg for eksempel at du planlegger neste års strategi for et investeringsselskap. Et viktig skritt ville være å analysere og sammenligne de økonomiske resultatene og potensielle risikoene til kandidatselskaper. Denne oppgaven innebærer å svare på analytiske resonneringsspørsmål. For eksempel krever spørringen «Gi meg de 5 beste selskapene med høyest inntekt i løpet av de siste 2 årene og identifiser hovedrisikoene deres» flere trinn med resonnement, hvorav noen kan bruke semantisk søkeinnhenting, mens andre krever analytiske evner.
I dette innlegget viser vi hvordan du designer en intelligent dokumentassistent som er i stand til å svare på analytiske og flertrinns resonneringsspørsmål i tre deler. I del 1 gjennomgår vi RAG-designmønsteret og dets begrensninger på analytiske spørsmål. Deretter introduserer vi deg for en mer allsidig arkitektur som overvinner disse begrensningene. Del 2 hjelper deg å dykke dypere inn i enhetsutvinningsrørledningen som brukes til å forberede strukturerte data, som er en nøkkelingrediens for å besvare analytiske spørsmål. Del 3 viser deg hvordan du bruker Amazonas grunnfjell LLM-er for å spørre etter disse dataene og bygge en LLM-agent som forbedrer RAG med analytiske evner, og dermed lar deg bygge intelligente dokumentassistenter som kan svare på komplekse domenespesifikke spørsmål på tvers av flere dokumenter.
Del 1: RAG-begrensninger og løsningsoversikt
I denne delen gjennomgår vi RAG-designmønsteret og diskuterer dets begrensninger på analytiske spørsmål. Vi presenterer også en mer allsidig arkitektur som overvinner disse begrensningene.
Oversikt over RAG
RAG-løsninger er inspirert av representasjonslæring og semantisk søk ideer som gradvis har blitt tatt i bruk i rangeringsproblemer (for eksempel anbefaling og søk) og naturlig språkbehandling (NLP)-oppgaver siden 2010.
Den populære tilnærmingen som brukes i dag består av tre trinn:
- En offline batchbehandlingsjobb tar inn dokumenter fra en kunnskapsbase for input, deler dem opp i biter, oppretter en innebygging for hver del for å representere dens semantikk ved hjelp av en forhåndstrent innebyggingsmodell, som f.eks. Amazon Titan innbyggingsmodeller, bruker deretter disse innebyggingene som input for å lage en semantisk søkeindeks.
- Når du svarer på et nytt spørsmål i sanntid, konverteres inndataspørsmålet til en innebygging, som brukes til å søke etter og trekke ut de mest like bitene av dokumenter ved å bruke en likhetsmetrikk, for eksempel cosinus-likhet, og en omtrentlig algoritme for nærmeste naboer. Søkepresisjonen kan også forbedres med metadatafiltrering.
- En ledetekst er konstruert fra sammenkoblingen av en systemmelding med en kontekst som er dannet av de relevante delene av dokumenter hentet ut i trinn 2, og selve inndataspørsmålet. Denne ledeteksten blir deretter presentert for en LLM-modell for å generere det endelige svaret på spørsmålet fra konteksten.
Med den riktige underliggende innbyggingsmodellen, i stand til å produsere nøyaktige semantiske representasjoner av inndatadokumentbitene og inputspørsmålene, og en effektiv semantisk søkemodul, er denne løsningen i stand til å svare på spørsmål som krever å hente eksisterende informasjon i en database med dokumenter. Hvis du for eksempel har en tjeneste eller et produkt, kan du starte med å indeksere FAQ-delen eller dokumentasjonen og få en innledende samtale-AI skreddersydd til ditt spesifikke tilbud.
Begrensninger for RAG basert på semantisk søk
Selv om RAG er en viktig komponent i moderne domenespesifikke AI-assistenter og et fornuftig utgangspunkt for å bygge en samtale-AI rundt en spesialisert kunnskapsbase, kan den ikke svare på spørsmål som krever skanning, sammenligning og resonnement på tvers av alle dokumenter i kunnskapsbasen din. samtidig, spesielt når utvidelsen utelukkende er basert på semantisk søk.
For å forstå disse begrensningene, la oss igjen se på eksemplet med å bestemme hvor vi skal investere basert på økonomiske rapporter. Hvis vi skulle bruke RAG til å snakke med disse rapportene, kan vi stille spørsmål som "Hva er risikoene som stod overfor selskap X i 2022," eller "Hva er nettoinntektene til selskap Y i 2022?" For hvert av disse spørsmålene brukes den korresponderende innebyggingsvektoren, som koder for den semantiske betydningen av spørsmålet, for å hente de øverste K semantisk lignende delene av dokumenter tilgjengelig i søkeindeksen. Dette oppnås vanligvis ved å bruke en tilnærmet nærmeste naboløsning som f.eks FAISS, NMSLIB, pgvector eller andre, som streber etter å finne en balanse mellom gjenfinningshastighet og tilbakekalling for å oppnå sanntidsytelse og samtidig opprettholde tilfredsstillende nøyaktighet.
Den foregående tilnærmingen kan imidlertid ikke svare nøyaktig på analytiske spørsmål på tvers av alle dokumenter, for eksempel "Hva er de 5 beste selskapene med høyest nettoinntekt i 2022?"
Dette er fordi semantisk søkeinnhenting forsøker å finne de K mest like bitene av dokumenter til inndataspørsmålet. Men fordi ingen av dokumentene inneholder omfattende oppsummeringer av inntekter, vil det returnere biter av dokumenter som bare inneholder omtale av "nettoinntekter" og muligens "2022", uten å oppfylle den grunnleggende betingelsen om å fokusere på selskaper med høyest inntekt. Hvis vi presenterer disse innhentingsresultatene for en LLM som kontekst for å svare på input-spørsmålet, kan den formulere et misvisende svar eller nekte å svare, fordi den nødvendige korrekte informasjonen mangler.
Disse begrensningene kommer ved design fordi semantisk søk ikke gjennomfører en grundig skanning av alle innebygde vektorer for å finne relevante dokumenter. I stedet bruker den omtrentlige nærmeste nabometoder for å opprettholde rimelig gjenfinningshastighet. En nøkkelstrategi for effektivitet i disse metodene er å segmentere innebyggingsområdet i grupper under indeksering. Dette gjør det mulig raskt å identifisere hvilke grupper som kan inneholde relevante innebygginger under henting, uten behov for parvise sammenligninger. I tillegg, selv tradisjonelle nærmeste naboteknikker som KNN, som skanner alle dokumenter, beregner bare grunnleggende avstandsmålinger og er ikke egnet for de komplekse sammenligningene som trengs for analytisk resonnement. Derfor er ikke RAG med semantisk søk skreddersydd for å svare på spørsmål som involverer analytiske resonnementer på tvers av alle dokumenter.
For å overvinne disse begrensningene, foreslår vi en løsning som kombinerer RAG med metadata og enhetsutvinning, SQL-spørring og LLM-agenter, som beskrevet i de følgende avsnittene.
Overvinne RAG-begrensninger med metadata, SQL og LLM-agenter
La oss undersøke dypere et spørsmål som RAG mislykkes på, slik at vi kan spore tilbake resonnementet som kreves for å svare effektivt. Denne analysen bør peke oss mot den riktige tilnærmingen som kan utfylle RAG i den samlede løsningen.
Vurder spørsmålet: "Hva er de 5 beste selskapene med høyest inntekt i 2022?"
For å kunne svare på dette spørsmålet, må vi:
- Identifiser inntektene for hvert selskap.
- Filtrer ned for å beholde inntektene fra 2022 for hver av dem.
- Sorter inntektene i synkende rekkefølge.
- Del ut de 5 beste inntektene ved siden av firmanavnene.
Vanligvis gjøres disse analytiske operasjonene på strukturerte data, ved hjelp av verktøy som pandaer eller SQL-motorer. Hvis vi hadde tilgang til en SQL-tabell som inneholder kolonnene company
, revenue
og year
, kan vi enkelt svare på spørsmålet vårt ved å kjøre en SQL-spørring, som ligner på følgende eksempel:
SELECT company, revenue FROM table_name WHERE year = 2022 ORDER BY revenue DESC LIMIT 5;
Lagring av strukturerte metadata i en SQL-tabell som inneholder informasjon om relevante enheter, gjør at du kan svare på mange typer analytiske spørsmål ved å skrive riktig SQL-spørring. Dette er grunnen til at vi kompletterer RAG i løsningen vår med en sanntids SQL-spørringsmodul mot en SQL-tabell, fylt med metadata hentet ut i en offline prosess.
Men hvordan kan vi implementere og integrere denne tilnærmingen til en LLM-basert samtale-AI?
Det er tre trinn for å kunne legge til SQL analytisk resonnement:
- Metadatautvinning – Trekk ut metadata fra ustrukturerte dokumenter til en SQL-tabell
- Tekst til SQL – Formuler SQL-spørringer fra inndataspørsmål nøyaktig ved å bruke en LLM
- Verktøyvalg – Identifiser om et spørsmål må besvares ved hjelp av RAG eller en SQL-spørring
For å implementere disse trinnene, erkjenner vi først at informasjonsutvinning fra ustrukturerte dokumenter er en tradisjonell NLP-oppgave som LLM-er viser løfte om å oppnå høy nøyaktighet gjennom zero-shot eller få-shot læring. For det andre har disse modellenes evne til å generere SQL-spørringer fra naturlig språk blitt bevist i årevis, som vist i 2020 utgivelse of Amazon QuickSight Q. Til slutt, automatisk valg av riktig verktøy for et spesifikt spørsmål forbedrer brukeropplevelsen og gjør det mulig å svare på komplekse spørsmål gjennom flertrinns resonnement. For å implementere denne funksjonen fordyper vi oss i LLM-agenter i et senere avsnitt.
For å oppsummere er løsningen vi foreslår sammensatt av følgende kjernekomponenter:
- Semantisk søkeinnhenting for å øke generasjonskonteksten
- Strukturert metadatautvinning og spørring med SQL
- En agent som er i stand til å bruke de riktige verktøyene for å svare på et spørsmål
Løsningsoversikt
Følgende diagram viser en forenklet arkitektur av løsningen. Det hjelper deg med å identifisere og forstå rollen til kjernekomponentene og hvordan de samhandler for å implementere den fullstendige LLM-assistentatferden. Nummereringen stemmer overens med rekkefølgen av operasjoner når denne løsningen implementeres.
I praksis implementerte vi denne løsningen som beskrevet i følgende detaljerte arkitektur.
For denne arkitekturen foreslår vi en implementering på GitHub, med løst koblede komponenter hvor backend (5), datarørledninger (1, 2, 3) og frontend (4) kan utvikles separat. Dette for å forenkle samarbeidet på tvers av kompetanse ved tilpasning og forbedring av løsningen for produksjon.
Distribuere løsningen
For å installere denne løsningen i AWS-kontoen din, fullfør følgende trinn:
- Klone depot på GitHub.
- Installer backend AWS skyutviklingssett (AWS CDK) app:
- Åpne
backend
mappe. - Kjør
npm install
for å installere avhengighetene. - Hvis du aldri har brukt AWS CDK i gjeldende konto og region, kjør bootstrapping med
npx cdk bootstrap
. - Kjør
npx cdk deploy
å distribuere stabelen.
- Åpne
- Kjør eventuelt
streamlit-ui
som følger:- Vi anbefaler å klone dette depotet til en Amazon SageMaker Studio miljø. For mer informasjon, se Ombord på Amazon SageMaker Domain ved hjelp av hurtigoppsett.
- Inne i
frontend/streamlit-ui
mappe, kjørbash run-streamlit-ui.sh
. - Velg lenken med følgende format for å åpne demoen:
https://{domain_id}.studio.{region}.sagemaker.aws/jupyter/default/proxy/{port_number}/
.
- Til slutt kan du kjøre Amazon SageMaker rørledningen definert i
data-pipelines/04-sagemaker-pipeline-for-documents-processing.ipynb
notatbok for å behandle PDF-dokumentene og forberede SQL-tabellen og den semantiske søkeindeksen som brukes av LLM-assistenten.
I resten av dette innlegget fokuserer vi på å forklare de viktigste komponentene og designvalgene, for forhåpentligvis å inspirere deg når du designer din egen AI-assistent på en intern kunnskapsbase. Vi antar at komponent 1 og 4 er enkle å forstå, og fokuserer på kjernekomponentene 2, 3 og 5.
Del 2: Enhetsutvinningsrørledning
I denne delen dykker vi dypere inn i enhetsekstraksjonsrørledningen som brukes til å utarbeide strukturerte data, som er en nøkkelingrediens for å besvare analytiske spørsmål.
Tekstuttrekk
Dokumenter lagres vanligvis i PDF-format eller som skannede bilder. De kan være laget av enkle avsnittsoppsett eller komplekse tabeller, og inneholde digital eller håndskrevet tekst. For å trekke ut informasjon på riktig måte, må vi transformere disse rådokumentene til ren tekst, samtidig som den opprinnelige strukturen bevares. For å gjøre dette kan du bruke amazontekst, som er en maskinlæringstjeneste (ML) som gir modne API-er for tekst, tabeller og skjemautvinning fra digitale og håndskrevne inndata.
I komponent 2 trekker vi ut tekst og tabeller som følger:
- For hvert dokument kaller vi Amazon Textract for å trekke ut teksten og tabellene.
- Vi bruker følgende Python-manus for å gjenskape tabeller som pandas DataFrames.
- Vi konsoliderer resultatene i ett enkelt dokument og setter inn tabeller som markdown.
Denne prosessen er skissert av følgende flytdiagram og konkret demonstrert i notebooks/03-pdf-document-processing.ipynb
.
Enhetsutvinning og spørring ved hjelp av LLM-er
For å svare på analytiske spørsmål effektivt, må du trekke ut relevante metadata og enheter fra dokumentets kunnskapsbase til et tilgjengelig strukturert dataformat. Vi foreslår at du bruker SQL for å lagre denne informasjonen og hente svar på grunn av dens popularitet, brukervennlighet og skalerbarhet. Dette valget drar også nytte av de velprøvde språkmodellenes evne til å generere SQL-spørringer fra naturlig språk.
I denne delen dykker vi dypere inn i følgende komponenter som muliggjør analytiske spørsmål:
- En batchprosess som trekker ut strukturerte data fra ustrukturerte data ved hjelp av LLM-er
- En sanntidsmodul som konverterer naturlig språkspørsmål til SQL-spørringer og henter resultater fra en SQL-database
Du kan trekke ut de relevante metadataene for å støtte analytiske spørsmål som følger:
- Definer et JSON-skjema for informasjon du trenger å trekke ut, som inneholder en beskrivelse av hvert felt og dets datatype, og inkluderer eksempler på forventede verdier.
- For hvert dokument, spør en LLM med JSON-skjemaet og be den trekke ut de relevante dataene nøyaktig.
- Når dokumentlengden er utenfor kontekstlengden, og for å redusere utvinningskostnadene med LLM-er, kan du bruke semantisk søk for å hente og presentere de relevante delene av dokumenter til LLM under utvinning.
- Parse JSON-utdata og valider LLM-utvinningen.
- Alternativt kan du sikkerhetskopiere resultatene på Amazon S3 som CSV-filer.
- Last inn i SQL-databasen for senere spørring.
Denne prosessen administreres av følgende arkitektur, hvor dokumentene i tekstformat lastes med et Python-skript som kjører i en Amazon SageMaker-prosessering jobb med å utføre utvinningen.
For hver gruppe av enheter konstruerer vi dynamisk en ledetekst som inkluderer en klar beskrivelse av informasjonsutvinningsoppgaven, og inkluderer et JSON-skjema som definerer forventet utgang og inkluderer de relevante dokumentbitene som kontekst. Vi legger også til noen få eksempler på input og riktig utgang for å forbedre utvinningsytelsen med få-skuddslæring. Dette er demonstrert i notebooks/05-entities-extraction-to-structured-metadata.ipynb
.
Del 3: Bygg en agent dokumentassistent med Amazon Bedrock
I denne delen viser vi hvordan du bruker Amazon Bedrock LLM-er til å spørre etter data og bygge en LLM-agent som forbedrer RAG med analytiske evner, og dermed lar deg bygge intelligente dokumentassistenter som kan svare på komplekse domenespesifikke spørsmål på tvers av flere dokumenter. Du kan referere til Lambdafunksjon på GitHub for konkret implementering av agenten og verktøyene beskrevet i denne delen.
Formuler SQL-spørringer og svar på analytiske spørsmål
Nå som vi har et strukturert metadatalager med de relevante enhetene ekstrahert og lastet inn i en SQL-database som vi kan spørre etter, er spørsmålet som gjenstår hvordan man genererer den riktige SQL-spørringen fra inndataspørsmålene for naturlig språk?
Moderne LLM-er er flinke til å generere SQL. For eksempel, hvis du ber om fra den antropiske Claude LLM gjennom Amazonas grunnfjell for å generere en SQL-spørring, vil du se plausible svar. Vi må imidlertid overholde noen få regler når vi skriver forespørselen for å nå mer nøyaktige SQL-spørringer. Disse reglene er spesielt viktige for komplekse søk for å redusere hallusinasjons- og syntaksfeil:
- Beskriv oppgaven nøyaktig innenfor ledeteksten
- Inkluder skjemaet til SQL-tabellene i ledeteksten, mens du beskriver hver kolonne i tabellen og spesifiserer dens datatype
- Fortell LLM eksplisitt å bare bruke eksisterende kolonnenavn og datatyper
- Legg til noen rader med SQL-tabellene
Du kan også etterbehandle den genererte SQL-spørringen ved å bruke en lanterne slik som sqlfluff for å korrigere formatering, eller en parser som f.eks sqlglot for å oppdage syntaksfeil og optimalisere spørringen. I tillegg, når ytelsen ikke oppfyller kravet, kan du gi noen eksempler i ledeteksten for å styre modellen med få greps læring mot å generere mer nøyaktige SQL-spørringer.
Fra et implementeringsperspektiv bruker vi en AWS Lambda funksjon for å orkestrere følgende prosess:
- Ring en antropisk Claude-modell i Amazon Bedrock med inndataspørsmålet for å få den tilsvarende SQL-spørringen. Her bruker vi SQLDatabase klasse fra LangChain for å legge til skjemabeskrivelser av relevante SQL-tabeller, og bruke en tilpasset ledetekst.
- Parse, valider og kjør SQL-spørringen mot Amazon Aurora PostgreSQL-kompatibel utgave database.
Arkitekturen for denne delen av løsningen er fremhevet i følgende diagram.
Sikkerhetshensyn for å forhindre SQL-injeksjonsangrep
Ettersom vi lar AI-assistenten søke etter en SQL-database, må vi sørge for at dette ikke introduserer sikkerhetssårbarheter. For å oppnå dette foreslår vi følgende sikkerhetstiltak for å forhindre SQL-injeksjonsangrep:
- Bruk minst privilegerte IAM-tillatelser – Begrens tillatelsen til Lambda-funksjonen som kjører SQL-spørringene ved hjelp av en AWS identitets- og tilgangsadministrasjon (IAM) politikk og rolle som følger minste privilegium-prinsippet. I dette tilfellet gir vi skrivebeskyttet tilgang.
- Begrens datatilgang – Gi kun tilgang til et minimum av tabeller og kolonner for å forhindre angrep av informasjonsavsløring.
- Legg til et modereringslag – Introduser et modereringslag som oppdager umiddelbare injeksjonsforsøk tidlig og hindrer dem i å forplante seg til resten av systemet. Det kan ha form av regelbaserte filtre, likhetsmatching mot en database med kjente eksempler på hurtiginjeksjon, eller en ML-klassifisering.
Semantisk søkeinnhenting for å øke generasjonskonteksten
Løsningen vi foreslår bruker RAG med semantisk søk i komponent 3. Du kan implementere denne modulen vha kunnskapsbaser for Amazon Bedrock. I tillegg er det en rekke andre alternativer for å implementere RAG, for eksempel Amazon Kendra Retrieval API, Amazon OpenSearch vektordatabaseog Amazon Aurora PostgreSQL med pgvektor, blant andre. Åpen kildekode-pakken aws-genai-llm-chatbot viser hvordan du bruker mange av disse vektorsøkealternativene for å implementere en LLM-drevet chatbot.
I denne løsningen, fordi vi trenger både SQL-spørring og vektorsøk, bestemte vi oss for å bruke Amazon Aurora PostgreSQL med pgvektor utvidelse, som støtter begge funksjonene. Derfor implementerer vi RAG-komponenten semantisk søk med følgende arkitektur.
Prosessen med å besvare spørsmål ved å bruke den foregående arkitekturen gjøres i to hovedtrinn.
Først oppretter en offline-batch-prosess, kjørt som en SageMaker Processing-jobb, den semantiske søkeindeksen som følger:
- Enten med jevne mellomrom, eller ved mottak av nye dokumenter, kjøres en SageMaker-jobb.
- Den laster inn tekstdokumentene fra Amazon S3 og deler dem opp i overlappende biter.
- For hver del bruker den en Amazon Titan-innbyggingsmodell for å generere en innebyggingsvektor.
- Den bruker PGVector klasse fra LangChain for å innta innebyggingene, med deres dokumentbiter og metadata, inn i Amazon Aurora PostgreSQL og lage en semantisk søkeindeks på alle innebyggingsvektorene.
For det andre, i sanntid og for hvert nytt spørsmål, konstruerer vi et svar som følger:
- Spørsmålet mottas av orkestratoren som kjører på en Lambda-funksjon.
- Orkestratoren legger inn spørsmålet med samme innbyggingsmodell.
- Den henter de øverste K mest relevante dokumentbitene fra PostgreSQL semantiske søkeindeks. Den bruker valgfritt metadatafiltrering for å forbedre presisjonen.
- Disse delene settes inn dynamisk i en LLM-ledetekst ved siden av inndataspørsmålet.
- Spørsmålet presenteres for Anthropic Claude på Amazon Bedrock, for å instruere den til å svare på innspillsspørsmålet basert på tilgjengelig kontekst.
- Til slutt sendes det genererte svaret tilbake til orkestratoren.
En agent som er i stand til å bruke verktøy til å resonnere og handle
Så langt i dette innlegget har vi diskutert behandling av spørsmål som krever enten RAG eller analytisk resonnement separat. Imidlertid krever mange spørsmål fra den virkelige verden begge egenskapene, noen ganger over flere trinn med resonnement, for å komme frem til et endelig svar. For å støtte disse mer komplekse spørsmålene, må vi introdusere begrepet en agent.
LLM-agenter, for eksempel agenter for Amazon Bedrock, har nylig dukket opp som en lovende løsning som er i stand til å bruke LLM-er til å resonnere og tilpasse ved å bruke gjeldende kontekst og velge passende handlinger fra en liste med alternativer, som presenterer et generelt problemløsningsrammeverk. Som diskutert i LLM-drevne autonome agenter, er det flere spørsmålsstrategier og designmønstre for LLM-agenter som støtter komplekse resonnementer.
Et slikt designmønster er Reason and Act (ReAct), introdusert i ReAct: Synergi resonnement og handling i språkmodeller. I ReAct tar agenten som input et mål som kan være et spørsmål, identifiserer informasjonen som mangler for å svare på det, og foreslår iterativt det riktige verktøyet for å samle informasjon basert på de tilgjengelige verktøyenes beskrivelser. Etter å ha mottatt svaret fra et gitt verktøy, vurderer LLM på nytt om den har all informasjonen den trenger for å svare fullt ut på spørsmålet. Hvis ikke, gjør den et nytt trinn med resonnement og bruker det samme eller et annet verktøy for å samle inn mer informasjon, til et endelig svar er klart eller en grense er nådd.
Følgende sekvensdiagram forklarer hvordan en ReAct-agent jobber for å svare på spørsmålet "Gi meg de 5 beste selskapene med høyest inntekt de siste 2 årene og identifiser risikoene forbundet med det øverste."
Detaljene for å implementere denne tilnærmingen i Python er beskrevet i Egendefinert LLM-agent. I vår løsning er agenten og verktøyene implementert med følgende uthevede delarkitektur.
For å svare på et inndataspørsmål bruker vi AWS-tjenester som følger:
- En bruker legger inn spørsmålet sitt gjennom et brukergrensesnitt, som kaller et API på Amazon API-gateway.
- API Gateway sender spørsmålet til en Lambda-funksjon som implementerer agentutføreren.
- Agenten ringer LLM med en ledetekst som inneholder en beskrivelse av de tilgjengelige verktøyene, ReAct-instruksjonsformatet og inndataspørsmålet, og analyserer deretter neste handling som skal fullføres.
- Handlingen inneholder hvilket verktøy som skal ringes og hva handlingsinngangen er.
- Hvis verktøyet som skal brukes er SQL, kaller agentutøveren SQLQA for å konvertere spørsmålet til SQL og kjøre det. Deretter legger den resultatet til ledeteksten og ringer LLM igjen for å se om den kan svare på det opprinnelige spørsmålet eller om det er behov for flere handlinger.
- På samme måte, hvis verktøyet som skal brukes er semantisk søk, analyseres handlingsinndataene og brukes til å hente fra PostgreSQL semantisk søkeindeks. Den legger til resultatene i ledeteksten og sjekker om LLM er i stand til å svare eller trenger en annen handling.
- Etter at all informasjonen for å svare på et spørsmål er tilgjengelig, formulerer LLM-agenten et endelig svar og sender det tilbake til brukeren.
Du kan utvide agenten med flere verktøy. I implementeringen tilgjengelig på GitHub, viser vi hvordan du kan legge til en søkemotor og en kalkulator som ekstraverktøy til den nevnte SQL-motoren og semantiske søkeverktøy. For å lagre den pågående samtalehistorikken bruker vi en Amazon DynamoDB tabellen.
Fra vår erfaring så langt har vi sett at følgende er nøkkelen til en vellykket agent:
- En underliggende LLM som er i stand til å resonnere med ReAct-formatet
- En klar beskrivelse av de tilgjengelige verktøyene, når de skal brukes, og en beskrivelse av deres input-argumenter med, potensielt, et eksempel på input og forventet output
- En klar oversikt over ReAct-formatet som LLM må følge
- De riktige verktøyene for å løse forretningsspørsmålet som er gjort tilgjengelig for LLM-agenten å bruke
- Korrekt analysere utdataene fra LLM-agentsvarene etter hvert som den begrunner
For å optimalisere kostnadene anbefaler vi å bufre de vanligste spørsmålene med svarene og oppdatere denne hurtigbufferen med jevne mellomrom for å redusere anrop til den underliggende LLM. Du kan for eksempel lage en semantisk søkeindeks med de vanligste spørsmålene som forklart tidligere, og matche det nye brukerspørsmålet mot indeksen først før du ringer LLM. For å utforske andre hurtigbufringsalternativer, se LLM Caching-integrasjoner.
Støtter andre formater som video, bilde, lyd og 3D-filer
Du kan bruke den samme løsningen på ulike typer informasjon, for eksempel bilder, videoer, lyd og 3D-designfiler som CAD- eller mesh-filer. Dette innebærer å bruke etablerte ML-teknikker for å beskrive filinnholdet i tekst, som deretter kan tas inn i løsningen vi utforsket tidligere. Denne tilnærmingen lar deg gjennomføre QA-samtaler om disse forskjellige datatypene. Du kan for eksempel utvide dokumentdatabasen din ved å lage tekstlige beskrivelser av bilder, videoer eller lydinnhold. Du kan også forbedre metadatatabellen ved å identifisere egenskaper gjennom klassifisering eller objektgjenkjenning på elementer i disse formatene. Etter at disse utpakkede dataene er indeksert i enten metadatalageret eller den semantiske søkeindeksen for dokumenter, forblir den generelle arkitekturen til det foreslåtte systemet stort sett konsistent.
konklusjonen
I dette innlegget viste vi hvordan bruk av LLM-er med RAG-designmønsteret er nødvendig for å bygge en domenespesifikk AI-assistent, men er utilstrekkelig til å nå det nødvendige nivået av pålitelighet for å generere forretningsverdi. På grunn av dette foreslo vi å utvide det populære RAG-designmønsteret med konseptene agenter og verktøy, der fleksibiliteten til verktøy lar oss bruke både tradisjonelle NLP-teknikker og moderne LLM-funksjoner for å gi en AI-assistent flere muligheter til å søke informasjon og assistere brukere til å løse forretningsproblemer effektivt.
Løsningen demonstrerer designprosessen mot en LLM-assistent som er i stand til å svare på ulike typer gjenfinningsspørsmål, analytiske resonnementer og flertrinns resonnementspørsmål på tvers av hele kunnskapsbasen din. Vi fremhevet også viktigheten av å tenke bakover fra de typer spørsmål og oppgaver som din LLM-assistent forventes å hjelpe brukere med. I dette tilfellet førte designreisen oss til en arkitektur med de tre komponentene: semantisk søk, metadatautvinning og SQL-spørring, og LLM-agent og verktøy, som vi mener er generiske og fleksible nok for flere brukstilfeller. Vi tror også at ved å hente inspirasjon fra denne løsningen og dykke dypt inn i brukernes behov, vil du kunne utvide denne løsningen videre mot det som fungerer best for deg.
Om forfatterne
Mohamed Ali Jamaoui er en Senior ML Prototyping Architect med 10 års erfaring innen produksjonsmaskinlæring. Han liker å løse forretningsproblemer med maskinlæring og programvareutvikling, og hjelpe kunder med å hente ut forretningsverdi med ML. Som en del av AWS EMEA Prototyping and Cloud Engineering hjelper han kunder med å bygge forretningsløsninger som utnytter innovasjoner innen MLOP, NLP, CV og LLM.
Giuseppe Hannen er en ProServe Associate Consultant. Giuseppe bruker sine analytiske ferdigheter i kombinasjon med AI&ML for å utvikle klare og effektive løsninger for kundene sine. Han elsker å komme med enkle løsninger på kompliserte problemer, spesielt de som involverer den siste teknologiske utviklingen og forskningen.
Laurens ten Cate er senior dataforsker. Laurens jobber med bedriftskunder i EMEA og hjelper dem å akselerere forretningsresultatene sine ved å bruke AWS AI/ML-teknologier. Han spesialiserer seg på NLP-løsninger og fokuserer på Supply Chain & Logistics-industrien. På fritiden liker han lesing og kunst.
Irina Radu er en Prototyping Engagement Manager, en del av AWS EMEA Prototyping and Cloud Engineering. Hun hjelper kundene med å få det beste ut av den nyeste teknologien, innovere raskere og tenke større.
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
- PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
- PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
- PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
- kilde: https://aws.amazon.com/blogs/machine-learning/boosting-rag-based-intelligent-document-assistants-using-entity-extraction-sql-querying-and-agents-with-amazon-bedrock/
- : har
- :er
- :ikke
- :hvor
- $OPP
- 1
- 10
- 100
- 2022
- 3d
- 7
- a
- evne
- I stand
- Om oss
- akselerere
- adgang
- tilgjengelig
- oppnådd
- Logg inn
- nøyaktighet
- nøyaktig
- nøyaktig
- Oppnå
- oppnå
- tvers
- Handling
- skuespill
- Handling
- handlinger
- tilpasse
- legge til
- I tillegg
- Legger
- vedtatt
- Etter
- en gang til
- mot
- Agent
- agenter
- AI
- AI-assistent
- AI / ML
- algoritme
- Justerer
- Alle
- tillater
- sammen
- også
- Amazon
- Amazon SageMaker
- amazontekst
- Amazon Web Services
- blant
- an
- analyse
- Analytisk
- analysere
- og
- En annen
- besvare
- svar
- Antropisk
- noen
- api
- APIer
- gjelder
- Påfør
- tilnærming
- hensiktsmessig
- tilnærmet
- arkitektur
- ER
- argumenter
- rundt
- Kunst
- AS
- spør
- bistå
- Assistent
- assistenter
- Førsteamanuensis
- assosiert
- anta
- At
- Angrep
- forsøk
- lyd
- øke
- augmented
- Aurora
- automatisk
- autonom
- tilgjengelig
- AWS
- tilbake
- Backend
- Balansere
- basen
- basert
- grunnleggende
- BE
- fordi
- vært
- før du
- atferd
- bak
- tro
- Fordeler
- BEST
- mellom
- Beyond
- større
- øke
- både
- bygge
- Bygning
- virksomhet
- bedrifter
- men
- by
- Cache
- CAD
- ring
- som heter
- ringer
- Samtaler
- CAN
- kandidat
- evner
- stand
- bære
- saken
- saker
- kjede
- chatbot
- Sjekker
- valg
- valg
- Velg
- klasse
- klassifisering
- fjerne
- Cloud
- SAMMENHENGENDE
- samarbeid
- Kolonne
- kolonner
- kombinasjon
- skurtreskerne
- Kom
- Felles
- Selskaper
- Selskapet
- sammenligne
- sammenligne
- sammenligninger
- Kompletter
- fullføre
- komplekse
- komplisert
- komponent
- komponenter
- komponert
- omfattende
- Beregn
- konsepter
- betong
- tilstand
- Gjennomføre
- Koble
- Vurder
- betraktninger
- konsistent
- konsolidere
- konstruere
- konsulent
- inneholde
- inneholdt
- inneholder
- innhold
- kontekst
- Samtale
- conversational
- samtale AI
- samtaler
- konvertere
- konvertert
- Kjerne
- korrigere
- riktig
- Tilsvarende
- Kostnad
- Kostnader
- kunne
- kombinert
- skape
- skaper
- Opprette
- Gjeldende
- skikk
- kunde
- Kundeservice
- Kunder
- dato
- data tilgang
- dataforsker
- Database
- besluttet
- Avgjør
- dyp
- dypere
- definert
- definerer
- dybden
- Etterspørsel
- demo
- demonstrere
- demonstrert
- demonstrerer
- avhengig
- utplassere
- beskrive
- beskrevet
- beskrive
- beskrivelse
- utforming
- designmønstre
- design prosess
- utforme
- detaljert
- detaljer
- oppdage
- Gjenkjenning
- utvikle
- Utvikling
- utviklingen
- digitalt
- avsløring
- diskutere
- diskutert
- diskusjoner
- avstand
- dykk
- diverse
- dykking
- do
- dokument
- dokumentasjon
- dokumenter
- gjør
- ikke
- domene
- domener
- gjort
- ned
- sjåfør
- to
- under
- dynamisk
- hver enkelt
- Tidligere
- Tidlig
- lette
- brukervennlighet
- lett
- Effektiv
- effektivt
- effektivitet
- effektiv
- effektivt
- enten
- elementer
- embedding
- EMEA
- dukket
- ansette
- muliggjøre
- muliggjør
- muliggjør
- slutt
- engasjement
- Motor
- Ingeniørarbeid
- Motorer
- forbedre
- Forbedrer
- nok
- berikende
- Enterprise
- enheter
- enhet
- Miljø
- feil
- spesielt
- avgjørende
- etablert
- Selv
- utvikle seg
- undersøke
- eksempel
- eksempler
- eksistens
- eksisterende
- Expand
- forventet
- erfaring
- forklarte
- forklare
- forklarer
- utforske
- utforsket
- utsatt
- utvide
- strekker
- forlengelse
- ekstra
- trekke ut
- utdrag
- ekstrakter
- møtt
- mislykkes
- FAQ
- langt
- raskere
- Trekk
- Egenskaper
- tilbakemelding
- Noen få
- felt
- filet
- Filer
- filtrering
- filtre
- slutt~~POS=TRUNC
- Endelig
- finansiell
- Finn
- Først
- fleksibilitet
- fleksibel
- flyten
- Fokus
- fokusering
- etter
- følger
- Til
- skjema
- format
- dannet
- skjemaer
- Rammeverk
- Gratis
- fra
- foran
- Front end
- oppfylle
- fullt
- fullt
- funksjon
- videre
- gateway
- samle
- general
- generere
- generert
- genererer
- generasjonen
- generative
- Generativ AI
- få
- få
- GitHub
- gitt
- mål
- god
- gradvis
- innvilge
- Gruppe
- Gruppens
- HAD
- Ha
- å ha
- he
- hjelpe
- hjelpe
- hjelper
- her.
- Høy
- høyest
- Fremhevet
- hans
- historie
- forhåpentligvis
- Hvordan
- Hvordan
- Men
- HTML
- HTTPS
- menneskelig
- Ideer
- identifiserer
- identifisere
- identifisering
- Identitet
- if
- bilde
- bilder
- forestille
- iverksette
- gjennomføring
- implementert
- implementere
- betydning
- viktig
- forbedre
- forbedret
- forbedringer
- bedre
- in
- inkluderer
- indeks
- indeksert
- industri
- informasjon
- informasjonsutvinning
- innledende
- innovere
- innovasjoner
- inngang
- innganger
- inspirasjon
- inspirere
- inspirert
- installere
- f.eks
- i stedet
- integrere
- Intelligent
- samhandle
- intern
- inn
- introdusere
- introdusert
- Investere
- etterforskning
- investering
- involvere
- IT
- DET ER
- selv
- Jobb
- reise
- jpg
- JSON
- Hold
- nøkkel
- nøkler
- kunnskap
- kjent
- Språk
- stor
- i stor grad
- Siste
- seinere
- siste
- lanseringer
- lag
- læring
- minst
- Led
- Lengde
- Nivå
- Leverage
- i likhet med
- BEGRENSE
- begrensninger
- LINK
- Liste
- LLM
- laster
- logistikk
- logistikkindustri
- Lang
- elsker
- maskin
- maskinlæring
- laget
- Hoved
- vedlikeholde
- Vedlike
- gjøre
- fikk til
- leder
- mange
- Match
- matchende
- moden
- Kan..
- me
- betyr
- målinger
- Møt
- nevner
- bare
- mesh
- melding
- metadata
- metode
- metoder
- metrisk
- Metrics
- minimum
- villedende
- mangler
- ML
- MLOps
- modell
- modeller
- moderasjon
- Moderne
- Moduler
- mer
- Videre
- mest
- flere
- må
- navn
- Naturlig
- Natural Language Processing
- nødvendig
- Trenger
- nødvendig
- behov
- naboer
- nett
- nettoinntekt
- aldri
- Ny
- neste
- nlp
- none
- bærbare
- Forestilling
- objekt
- Objektdeteksjon
- of
- tilbudt
- tilby
- offline
- ofte
- on
- ONE
- pågående
- bare
- åpen
- åpen kildekode
- Drift
- Optimalisere
- alternativer
- or
- rekkefølge
- original
- Annen
- andre
- vår
- ut
- utfall
- omriss
- skissert
- produksjon
- utganger
- enn
- samlet
- Overcome
- egen
- pakke
- pandaer
- del
- deler
- Mønster
- mønstre
- Utfør
- ytelse
- tillatelse
- perspektiv
- Pharmaceutical
- stykker
- rørledning
- Plain
- planlegging
- plato
- Platon Data Intelligence
- PlatonData
- plausibel
- Point
- politikk
- Populær
- popularitet
- befolket
- mulig
- muligens
- Post
- postgresql
- potensiell
- potensielt
- powered
- kraftig
- praksis
- Precision
- Forbered
- presentere
- presentert
- gaver
- bevarer
- forebygge
- forhindrer
- tidligere
- privilegium
- problemløsning
- problemer
- prosess
- prosessering
- produserer
- produserende
- Produkt
- Produksjon
- løfte
- lovende
- egenskaper
- foreslå
- foreslått
- foreslår
- prototyping
- utprøvd
- gi
- gir
- offentlig
- Python
- Q & A
- spørsmål
- spørsmål
- spørsmål
- Rask
- raskt
- Ranking
- rask
- Raw
- å nå
- nådd
- Reager
- Lesning
- klar
- ekte
- virkelige verden
- sanntids
- grunnen til
- rimelig
- mottatt
- mottak
- nylig
- nylig
- gjenkjenne
- anbefaler
- Anbefaling
- redusere
- referere
- region
- relevant
- pålitelighet
- avhengige
- forblir
- Rapporter
- Repository
- representere
- anmode
- krever
- påkrevd
- behov
- Krever
- forskning
- svar
- svar
- REST
- resultere
- Resultater
- retur
- inntekter
- inntekter
- anmeldelse
- ikke sant
- risikoer
- Rolle
- regler
- Kjør
- rennende
- går
- sagemaker
- samme
- skalerbarhet
- skanne
- skanning
- Forsker
- script
- Søk
- søkemotor
- Sekund
- Seksjon
- seksjoner
- sikkerhet
- Sikkerhetstiltak
- se
- Søke
- sett
- velge
- utvalg
- semantikk
- sender
- senior
- sendt
- Sequence
- tjeneste
- Tjenester
- hun
- bør
- Vis
- viste
- vist
- lignende
- Enkelt
- forenklet
- forenkle
- samtidig
- siden
- enkelt
- ferdigheter
- So
- så langt
- Software
- software engineering
- utelukkende
- løsning
- Solutions
- løse
- noen
- noen ganger
- kilde
- Kilder
- Rom
- spesialisert
- spesialisert
- spesifikk
- fart
- spagaten
- stable
- stadier
- Begynn
- Start
- styre
- Trinn
- Steps
- oppbevare
- lagret
- rett fram
- strategier
- Strategi
- streik
- streber
- struktur
- strukturert
- studio
- vellykket
- slik
- foreslår
- egnet
- oppsummere
- levere
- forsyningskjeden
- støtte
- Støtter
- sikker
- syntaks
- system
- bord
- skreddersydd
- Ta
- tar
- Oppgave
- oppgaver
- tech
- teknikker
- teknologisk
- Technologies
- fortelle
- ti
- tekst
- tekstlig
- Takk
- Det
- De
- informasjonen
- deres
- Dem
- deretter
- Der.
- derved
- derfor
- Disse
- de
- tror
- tenker
- denne
- De
- tre
- Gjennom
- tid
- titan
- til
- i dag
- verktøy
- verktøy
- topp
- top 5
- mot
- mot
- Trace
- tradisjonelle
- Kurs
- Transform
- behandling
- sant
- troverdig
- to
- typen
- typer
- typisk
- ui
- underliggende
- forstå
- til
- oppdatering
- upon
- us
- bruke
- brukt
- Bruker
- Brukererfaring
- Brukere
- bruker
- ved hjelp av
- VALIDERE
- verdi
- Verdier
- variasjon
- ulike
- allsidig
- video
- videoer
- Sikkerhetsproblemer
- vandringer
- Vei..
- we
- web
- webtjenester
- VI VIL
- var
- Hva
- når
- mens
- om
- hvilken
- mens
- hvorfor
- Wikipedia
- vil
- med
- innenfor
- uten
- virker
- ville
- skriving
- X
- år
- år
- Du
- Din
- zephyrnet