Conversational AI er nået langt i de seneste år takket være den hurtige udvikling inden for generativ AI, især præstationsforbedringerne af store sprogmodeller (LLM'er), introduceret af træningsteknikker såsom instruktionsfinjustering og forstærkningslæring fra menneskelig feedback. Når de bliver spurgt korrekt, kan disse modeller føre sammenhængende samtaler uden nogen opgavespecifikke træningsdata. De kan dog ikke generalisere godt til virksomhedsspecifikke spørgsmål, fordi de for at generere et svar er afhængige af de offentlige data, de blev eksponeret for under forudgående træning. Sådanne data mangler ofte den specialiserede viden, der er indeholdt i interne dokumenter, der er tilgængelige i moderne virksomheder, hvilket typisk er nødvendigt for at få præcise svar inden for domæner såsom farmaceutisk forskning, finansiel undersøgelse og kundesupport.
For at skabe AI-assistenter, der er i stand til at føre diskussioner baseret på specialiseret virksomhedsviden, er vi nødt til at forbinde disse kraftfulde, men generiske LLM'er til interne vidensbaser af dokumenter. Denne metode til at berige LLM-genereringskonteksten med information hentet fra dine interne datakilder kaldes Retrieval Augmented Generation (RAG), og producerer assistenter, der er domænespecifikke og mere troværdige, som vist af Retrieval-Augmented Generation til viden-intensive NLP-opgaver. En anden drivkraft bag RAGs popularitet er dens lette implementering og eksistensen af modne vektorsøgningsløsninger, såsom dem, der tilbydes af Amazon Kendra (Se Amazon Kendra lancerer Retrieval API) og Amazon OpenSearch Service (Se k-Nearest Neighbor (k-NN) søgning i Amazon OpenSearch Service), blandt andre.
Det populære RAG-designmønster med semantisk søgning kan dog ikke besvare alle typer spørgsmål, der er mulige på dokumenter. Dette gælder især for spørgsmål, der kræver analytisk ræsonnement på tværs af flere dokumenter. Forestil dig for eksempel, at du planlægger næste års strategi for et investeringsselskab. Et væsentligt skridt ville være at analysere og sammenligne de økonomiske resultater og potentielle risici for kandidatvirksomheder. Denne opgave involverer besvarelse af analytiske ræsonnementspørgsmål. For eksempel kræver forespørgslen "Giv mig de 5 bedste virksomheder med den højeste omsætning i de sidste 2 år og identificer deres vigtigste risici" flere trin i ræsonnementet, hvoraf nogle kan bruge semantisk søgegenfinding, mens andre kræver analytiske evner.
I dette indlæg viser vi, hvordan man designer en intelligent dokumentassistent, der er i stand til at besvare analytiske og flertrins-ræsonneringsspørgsmål i tre dele. I del 1 gennemgår vi RAG-designmønsteret og dets begrænsninger for analytiske spørgsmål. Så introducerer vi dig til en mere alsidig arkitektur, der overvinder disse begrænsninger. Del 2 hjælper dig med at dykke dybere ned i enhedsekstraktionspipelinen, der bruges til at forberede strukturerede data, som er en nøgleingrediens til besvarelse af analytiske spørgsmål. Del 3 guider dig igennem, hvordan du bruger Amazonas grundfjeld LLM'er til at forespørge om disse data og bygge en LLM-agent, der forbedrer RAG med analytiske muligheder, og derved sætter dig i stand til at bygge intelligente dokumentassistenter, der kan besvare komplekse domænespecifikke spørgsmål på tværs af flere dokumenter.
Del 1: RAG-begrænsninger og løsningsoversigt
I dette afsnit gennemgår vi RAG-designmønsteret og diskuterer dets begrænsninger på analytiske spørgsmål. Vi præsenterer også en mere alsidig arkitektur, der overvinder disse begrænsninger.
Oversigt over RAG
RAG løsninger er inspireret af repræsentationslæring , semantisk søgning ideer, der gradvist er blevet overtaget i rangeringsproblemer (for eksempel anbefaling og søgning) og naturlig sprogbehandling (NLP) opgaver siden 2010.
Den populære tilgang, der bruges i dag, består af tre trin:
- Et offline batchbehandlingsjob indtager dokumenter fra en inputvidenbase, opdeler dem i bidder, opretter en indlejring for hver chunk for at repræsentere dens semantik ved hjælp af en forudtrænet indlejringsmodel, som f.eks. Amazon Titan indlejringsmodeller, bruger derefter disse indlejringer som input til at oprette et semantisk søgeindeks.
- Når der besvares et nyt spørgsmål i realtid, konverteres input-spørgsmålet til en indlejring, som bruges til at søge efter og udtrække de mest lignende bidder af dokumenter ved hjælp af en lighedsmetrik, såsom cosinus-lighed, og en tilnærmet nærmeste nabo-algoritme. Søgenøjagtigheden kan også forbedres med metadatafiltrering.
- En prompt er konstrueret ud fra sammenkædningen af en systemmeddelelse med en kontekst, der er dannet af de relevante bidder af dokumenter udtrukket i trin 2, og selve inputspørgsmålet. Denne prompt præsenteres derefter for en LLM-model for at generere det endelige svar på spørgsmålet fra konteksten.
Med den rigtige underliggende indlejringsmodel, der er i stand til at producere nøjagtige semantiske repræsentationer af inputdokumentklumperne og inputspørgsmålene, og et effektivt semantisk søgemodul, er denne løsning i stand til at besvare spørgsmål, der kræver at hente eksisterende information i en database med dokumenter. For eksempel, hvis du har en tjeneste eller et produkt, kan du starte med at indeksere dens FAQ-sektion eller dokumentation og få en indledende samtale-AI skræddersyet til dit specifikke tilbud.
Begrænsninger af RAG baseret på semantisk søgning
Selvom RAG er en væsentlig komponent i moderne domænespecifikke AI-assistenter og et fornuftigt udgangspunkt for at opbygge en samtale-AI omkring en specialiseret videnbase, kan den ikke besvare spørgsmål, der kræver scanning, sammenligning og ræsonnement på tværs af alle dokumenter i din videnbase samtidigt, især når forstærkningen udelukkende er baseret på semantisk søgning.
For at forstå disse begrænsninger, lad os igen overveje eksemplet med at beslutte, hvor vi skal investere baseret på finansielle rapporter. Hvis vi skulle bruge RAG til at tale med disse rapporter, kunne vi stille spørgsmål som "Hvad er de risici, som virksomhed X stod over for i 2022," eller "Hvad er nettoomsætningen for virksomhed Y i 2022?" For hvert af disse spørgsmål bruges den tilsvarende indlejringsvektor, som koder for den semantiske betydning af spørgsmålet, til at hente de top-K semantisk lignende bidder af dokumenter, der er tilgængelige i søgeindekset. Dette opnås typisk ved at anvende en tilnærmet nærmeste naboløsning som f.eks FAISS, NMSLIB, pgvector eller andre, som stræber efter at finde en balance mellem genfindingshastighed og tilbagekaldelse for at opnå realtidsydelse og samtidig opretholde tilfredsstillende nøjagtighed.
Den foregående tilgang kan dog ikke præcist besvare analytiske spørgsmål på tværs af alle dokumenter, såsom "Hvad er de 5 bedste virksomheder med den højeste nettoindtægt i 2022?"
Dette skyldes, at semantisk søgegenfinding forsøger at finde de K mest lignende bidder af dokumenter til inputspørgsmålet. Men fordi ingen af dokumenterne indeholder omfattende opsummeringer af indtægter, vil det returnere bidder af dokumenter, der blot indeholder omtaler af "nettoomsætning" og muligvis "2022", uden at opfylde den væsentlige betingelse om at fokusere på virksomheder med den højeste omsætning. Hvis vi præsenterer disse genfindingsresultater for en LLM som kontekst for at besvare inputspørgsmålet, kan den formulere et vildledende svar eller nægte at svare, fordi den nødvendige korrekte information mangler.
Disse begrænsninger kommer ved design, fordi semantisk søgning ikke udfører en grundig scanning af alle indlejringsvektorer for at finde relevante dokumenter. I stedet bruger den omtrentlige nærmeste nabo-metoder til at opretholde en rimelig genfindingshastighed. En nøglestrategi for effektivitet i disse metoder er at segmentere indlejringsrummet i grupper under indeksering. Dette giver mulighed for hurtigt at identificere, hvilke grupper der kan indeholde relevante indlejringer under hentning, uden behov for parvise sammenligninger. Derudover beregner selv traditionelle nærmeste naboteknikker som KNN, der scanner alle dokumenter, kun grundlæggende afstandsmålinger og er ikke egnede til de komplekse sammenligninger, der er nødvendige for analytisk ræsonnement. Derfor er RAG med semantisk søgning ikke skræddersyet til at besvare spørgsmål, der involverer analytisk ræsonnement på tværs af alle dokumenter.
For at overvinde disse begrænsninger foreslår vi en løsning, der kombinerer RAG med metadata og entitetsudtrækning, SQL-forespørgsler og LLM-agenter, som beskrevet i de følgende afsnit.
Overvinde RAG-begrænsninger med metadata, SQL og LLM-agenter
Lad os undersøge mere dybt et spørgsmål, hvor RAG fejler, så vi kan spore den begrundelse, der kræves for at besvare det effektivt. Denne analyse bør pege os mod den rigtige tilgang, der kunne supplere RAG i den samlede løsning.
Overvej spørgsmålet: "Hvad er de 5 bedste virksomheder med den højeste omsætning i 2022?"
For at kunne besvare dette spørgsmål skal vi:
- Identificer indtægterne for hver virksomhed.
- Filtrer ned for at beholde omsætningen i 2022 for hver af dem.
- Sorter indtægterne i faldende rækkefølge.
- Del de 5 største indtægter ud sammen med virksomhedsnavnene.
Typisk udføres disse analytiske operationer på strukturerede data ved hjælp af værktøjer som pandaer eller SQL-motorer. Hvis vi havde adgang til en SQL-tabel indeholdende kolonnerne company
, revenue
og year
, kunne vi nemt besvare vores spørgsmål ved at køre en SQL-forespørgsel, svarende til følgende eksempel:
SELECT company, revenue FROM table_name WHERE year = 2022 ORDER BY revenue DESC LIMIT 5;
Lagring af strukturerede metadata i en SQL-tabel, der indeholder oplysninger om relevante entiteter, gør dig i stand til at besvare mange typer analytiske spørgsmål ved at skrive den korrekte SQL-forespørgsel. Det er grunden til, at vi supplerer RAG i vores løsning med et SQL-forespørgselsmodul i realtid mod en SQL-tabel, udfyldt af metadata udtrukket i en offline proces.
Men hvordan kan vi implementere og integrere denne tilgang til en LLM-baseret samtale-AI?
Der er tre trin for at kunne tilføje SQL analytisk ræsonnement:
- Metadata udtræk – Udtræk metadata fra ustrukturerede dokumenter til en SQL-tabel
- Tekst til SQL – Formuler SQL-forespørgsler fra inputspørgsmål nøjagtigt ved hjælp af en LLM
- Valg af værktøj – Identificer, om et spørgsmål skal besvares ved hjælp af RAG eller en SQL-forespørgsel
For at implementere disse trin erkender vi først, at informationsudtrækning fra ustrukturerede dokumenter er en traditionel NLP-opgave, som LLM'er lover for at opnå høj nøjagtighed gennem nul- eller få-skuds-læring. For det andet er disse modellers evne til at generere SQL-forespørgsler fra naturligt sprog blevet bevist i årevis, som det ses i 2020 udgivelse of Amazon QuickSight Q. Endelig forbedrer automatisk valg af det rigtige værktøj til et specifikt spørgsmål brugeroplevelsen og gør det muligt at besvare komplekse spørgsmål gennem flertrins-ræsonnement. For at implementere denne funktion dykker vi ned i LLM-agenter i et senere afsnit.
For at opsummere er den løsning, vi foreslår, sammensat af følgende kernekomponenter:
- Semantisk søgehentning for at øge generationskonteksten
- Struktureret metadataudtræk og forespørgsel med SQL
- En agent, der er i stand til at bruge de rigtige værktøjer til at besvare et spørgsmål
Løsningsoversigt
Følgende diagram viser en forenklet arkitektur af løsningen. Det hjælper dig med at identificere og forstå kernekomponenternes rolle, og hvordan de interagerer for at implementere den fulde LLM-assistent-adfærd. Nummereringen stemmer overens med rækkefølgen af operationer, når denne løsning implementeres.
I praksis implementerede vi denne løsning som beskrevet i den følgende detaljerede arkitektur.
For denne arkitektur foreslår vi en implementering vedr GitHub, med løst koblede komponenter, hvor backend (5), datapipelines (1, 2, 3) og frontend (4) kan udvikle sig separat. Dette for at forenkle samarbejdet på tværs af kompetencer ved tilpasning og forbedring af løsningen til produktion.
Implementer løsningen
For at installere denne løsning på din AWS-konto skal du udføre følgende trin:
- Klon depot på GitHub.
- Installer backend AWS Cloud Development Kit (AWS CDK) app:
- Åbne
backend
mappe. - Kør
npm install
for at installere afhængighederne. - Hvis du aldrig har brugt AWS CDK i den aktuelle konto og region, så kør bootstrapping med
npx cdk bootstrap
. - Kør
npx cdk deploy
at implementere stakken.
- Åbne
- Kør eventuelt
streamlit-ui
som følger:- Vi anbefaler at klone dette lager til en Amazon SageMaker Studio miljø. For mere information, se Ombord på Amazon SageMaker Domain ved hjælp af hurtig opsætning.
- Inde
frontend/streamlit-ui
mappe, kørbash run-streamlit-ui.sh
. - Vælg linket med følgende format for at åbne demoen:
https://{domain_id}.studio.{region}.sagemaker.aws/jupyter/default/proxy/{port_number}/
.
- Endelig kan du køre Amazon SageMaker pipeline defineret i
data-pipelines/04-sagemaker-pipeline-for-documents-processing.ipynb
notesbog til at behandle input-PDF-dokumenter og forberede SQL-tabellen og det semantiske søgeindeks, der bruges af LLM-assistenten.
I resten af dette indlæg fokuserer vi på at forklare de vigtigste komponenter og designvalg, for forhåbentlig at inspirere dig, når du designer din egen AI-assistent på en intern videnbase. Vi antager, at komponenter 1 og 4 er ligetil at forstå, og fokuserer på kernekomponenterne 2, 3 og 5.
Del 2: Enhedsudvindingsrørledning
I dette afsnit dykker vi dybere ned i enhedsekstraktionspipelinen, der bruges til at forberede strukturerede data, som er en nøgleingrediens til analytisk besvarelse af spørgsmål.
Tekstudtræk
Dokumenter gemmes typisk i PDF-format eller som scannede billeder. De kan være dannet af simple afsnitslayouts eller komplekse tabeller og indeholde digital eller håndskrevet tekst. For at udtrække information korrekt, er vi nødt til at omdanne disse rå dokumenter til almindelig tekst, samtidig med at deres oprindelige struktur bevares. For at gøre dette kan du bruge amazontekst, som er en maskinlæringstjeneste (ML), der leverer modne API'er til tekst, tabeller og formularudtræk fra digitale og håndskrevne input.
I komponent 2 udtrækker vi tekst og tabeller som følger:
- For hvert dokument kalder vi Amazon Textract for at udtrække teksten og tabellerne.
- Vi bruger følgende Python script at genskabe tabeller som pandas DataFrames.
- Vi konsoliderer resultaterne i et enkelt dokument og indsætter tabeller som markdown.
Denne proces er skitseret af følgende flowdiagram og konkret demonstreret i notebooks/03-pdf-document-processing.ipynb
.
Enhedsudtrækning og forespørgsel ved hjælp af LLM'er
For at besvare analytiske spørgsmål effektivt skal du udtrække relevante metadata og enheder fra dit dokuments vidensbase til et tilgængeligt struktureret dataformat. Vi foreslår, at du bruger SQL til at gemme disse oplysninger og hente svar på grund af dens popularitet, brugervenlighed og skalerbarhed. Dette valg drager også fordel af de gennemprøvede sprogmodellers evne til at generere SQL-forespørgsler fra naturligt sprog.
I dette afsnit dykker vi dybere ned i følgende komponenter, der muliggør analytiske spørgsmål:
- En batchproces, der trækker strukturerede data ud af ustrukturerede data ved hjælp af LLM'er
- Et realtidsmodul, der konverterer naturlige sprogspørgsmål til SQL-forespørgsler og henter resultater fra en SQL-database
Du kan udtrække de relevante metadata for at understøtte analytiske spørgsmål som følger:
- Definer et JSON-skema for information, du skal udtrække, som indeholder en beskrivelse af hvert felt og dets datatype og inkluderer eksempler på de forventede værdier.
- For hvert dokument skal du spørge en LLM med JSON-skemaet og bede den om at udtrække de relevante data nøjagtigt.
- Når dokumentlængden er længere end kontekstlængden, og for at reducere ekstraktionsomkostningerne med LLM'er, kan du bruge semantisk søgning til at hente og præsentere de relevante bidder af dokumenter til LLM'en under udtrækning.
- Parse JSON-outputtet og valider LLM-udtrækningen.
- Sikkerhedskopier eventuelt resultaterne på Amazon S3 som CSV-filer.
- Indlæs i SQL-databasen til senere forespørgsler.
Denne proces styres af følgende arkitektur, hvor dokumenterne i tekstformat indlæses med et Python-script, der kører i en Amazon SageMaker-behandling arbejde med at udføre udvindingen.
For hver gruppe af entiteter konstruerer vi dynamisk en prompt, der inkluderer en klar beskrivelse af informationsudtrækningsopgaven og inkluderer et JSON-skema, der definerer det forventede output og inkluderer de relevante dokumentstykker som kontekst. Vi tilføjer også et par eksempler på input og korrekt output for at forbedre ekstraktionsydelsen med få-skuds-læring. Dette er demonstreret i notebooks/05-entities-extraction-to-structured-metadata.ipynb
.
Del 3: Byg en agent dokumentassistent med Amazon Bedrock
I dette afsnit demonstrerer vi, hvordan du bruger Amazon Bedrock LLM'er til at forespørge data og opbygge en LLM-agent, der forbedrer RAG med analytiske muligheder, og derved sætter dig i stand til at bygge intelligente dokumentassistenter, der kan besvare komplekse domænespecifikke spørgsmål på tværs af flere dokumenter. Du kan henvise til Lambda-funktion på GitHub til den konkrete implementering af agenten og værktøjerne beskrevet i denne del.
Formuler SQL-forespørgsler og besvar analytiske spørgsmål
Nu hvor vi har et struktureret metadatalager med de relevante entiteter udtrukket og indlæst i en SQL-database, som vi kan forespørge på, er spørgsmålet, der står tilbage, hvordan man genererer den rigtige SQL-forespørgsel ud fra input-spørgsmålene i det naturlige sprog?
Moderne LLM'er er gode til at generere SQL. For eksempel, hvis du anmoder den antropiske Claude LLM igennem Amazonas grundfjeld for at generere en SQL-forespørgsel, vil du se plausible svar. Vi skal dog overholde nogle få regler, når vi skriver prompten for at nå mere nøjagtige SQL-forespørgsler. Disse regler er især vigtige for komplekse forespørgsler for at reducere hallucinationer og syntaksfejl:
- Beskriv opgaven præcist i prompten
- Inkluder skemaet for SQL-tabellerne i prompten, mens du beskriver hver kolonne i tabellen og specificerer dens datatype
- Fortæl eksplicit, at LLM kun skal bruge eksisterende kolonnenavne og datatyper
- Tilføj et par rækker af SQL-tabellerne
Du kan også efterbehandle den genererede SQL-forespørgsel ved hjælp af en lanterne såsom sqlfluff for at rette formatering, eller en parser som f.eks sqlglot at opdage syntaksfejl og optimere forespørgslen. Når ydeevnen ikke opfylder kravet, kan du desuden give et par eksempler i prompten for at styre modellen med få-skuds læring mod at generere mere nøjagtige SQL-forespørgsler.
Fra et implementeringsperspektiv bruger vi en AWS Lambda funktion til at orkestrere følgende proces:
- Ring til en antropisk Claude-model i Amazon Bedrock med inputspørgsmålet for at få den tilsvarende SQL-forespørgsel. Her bruger vi SQLDatabase klasse fra LangChain for at tilføje skemabeskrivelser af relevante SQL-tabeller og bruge en brugerdefineret prompt.
- Parse, valider og kør SQL-forespørgslen mod Amazon Aurora PostgreSQL-kompatibel udgave databasen.
Arkitekturen for denne del af løsningen er fremhævet i det følgende diagram.
Sikkerhedsovervejelser for at forhindre SQL-injektionsangreb
Da vi gør det muligt for AI-assistenten at forespørge i en SQL-database, skal vi sørge for, at dette ikke introducerer sikkerhedssårbarheder. For at opnå dette foreslår vi følgende sikkerhedsforanstaltninger for at forhindre SQL-injektionsangreb:
- Anvend mindste privilegerede IAM-tilladelser – Begræns tilladelsen til Lambda-funktionen, der kører SQL-forespørgslerne ved hjælp af en AWS identitets- og adgangsstyring (IAM) politik og rolle, der følger mindste privilegium princippet. I dette tilfælde giver vi skrivebeskyttet adgang.
- Begræns dataadgang – Giv kun adgang til det absolutte minimum af tabeller og kolonner for at forhindre angreb på afsløring af oplysninger.
- Tilføj et moderationslag – Indfør et moderationslag, der registrerer hurtige injektionsforsøg tidligt og forhindrer dem i at forplante sig til resten af systemet. Det kan tage form af regelbaserede filtre, lighedsmatching mod en database med kendte promptindsprøjtningseksempler eller en ML-klassifikator.
Semantisk søgehentning for at øge generationskonteksten
Løsningen vi foreslår bruger RAG med semantisk søgning i komponent 3. Du kan implementere dette modul vha vidensbaser for Amazon Bedrock. Derudover er der en række andre muligheder for at implementere RAG, såsom Amazon Kendra Retrieval API, Amazon OpenSearch vektordatabaseog Amazon Aurora PostgreSQL med pgvektor, blandt andre. Open source-pakken aws-genai-llm-chatbot demonstrerer, hvordan man bruger mange af disse vektorsøgningsmuligheder til at implementere en LLM-drevet chatbot.
I denne løsning, fordi vi har brug for både SQL-forespørgsler og vektorsøgning, besluttede vi at bruge Amazon Aurora PostgreSQL med pgvektor udvidelse, som understøtter begge funktioner. Derfor implementerer vi RAG-komponenten semantisk søgning med følgende arkitektur.
Processen med at besvare spørgsmål ved hjælp af den foregående arkitektur udføres i to hovedfaser.
For det første opretter en offline-batch-proces, der køres som et SageMaker Processing-job, det semantiske søgeindeks som følger:
- Enten periodisk eller ved modtagelse af nye dokumenter køres et SageMaker-job.
- Den indlæser tekstdokumenterne fra Amazon S3 og opdeler dem i overlappende bidder.
- For hver chunk bruger den en Amazon Titan-indlejringsmodel til at generere en indlejringsvektor.
- Det bruger PGVector klasse fra LangChain for at indtage indlejringerne, med deres dokumentbidder og metadata, i Amazon Aurora PostgreSQL og oprette et semantisk søgeindeks på alle indlejringsvektorerne.
For det andet konstruerer vi i realtid og for hvert nyt spørgsmål et svar som følger:
- Spørgsmålet modtages af orkestratoren, der kører på en Lambda-funktion.
- Orkestratoren indlejrer spørgsmålet med den samme indlejringsmodel.
- Det henter de øverste K mest relevante dokumentstykker fra PostgreSQL semantiske søgeindeks. Den bruger valgfrit metadatafiltrering for at forbedre præcisionen.
- Disse bidder indsættes dynamisk i en LLM-prompt ved siden af inputspørgsmålet.
- Prompten præsenteres for Anthropic Claude på Amazon Bedrock for at instruere den i at besvare inputspørgsmålet baseret på den tilgængelige kontekst.
- Til sidst sendes det genererede svar tilbage til orkestratoren.
En agent, der er i stand til at bruge værktøjer til at ræsonnere og handle
Indtil videre i dette indlæg har vi diskuteret behandling af spørgsmål, der kræver enten RAG eller analytisk ræsonnement separat. Men mange spørgsmål fra den virkelige verden kræver begge muligheder, nogle gange over flere trin af ræsonnement, for at nå frem til et endeligt svar. For at understøtte disse mere komplekse spørgsmål er vi nødt til at introducere begrebet en agent.
LLM-agenter, såsom agenter for Amazon Bedrock, er for nylig dukket op som en lovende løsning, der er i stand til at bruge LLM'er til at ræsonnere og tilpasse ved hjælp af den aktuelle kontekst og til at vælge passende handlinger fra en liste af muligheder, som præsenterer en generel problemløsningsramme. Som diskuteret i LLM-drevne autonome agenter, er der flere promptstrategier og designmønstre for LLM-agenter, der understøtter komplekse ræsonnementer.
Et sådant designmønster er Reason and Act (ReAct), introduceret i ReAct: Synergi ræsonnement og handling i sprogmodeller. I ReAct tager agenten som input et mål, der kan være et spørgsmål, identificerer de informationer, der mangler for at besvare det, og foreslår iterativt det rigtige værktøj til at indsamle information baseret på de tilgængelige værktøjers beskrivelser. Efter at have modtaget svaret fra et givet værktøj, revurderer LLM, om den har alle de oplysninger, den har brug for for fuldt ud at besvare spørgsmålet. Hvis ikke, foretager den endnu et ræsonnement og bruger det samme eller et andet værktøj til at indsamle mere information, indtil et endeligt svar er klar, eller en grænse er nået.
Følgende sekvensdiagram forklarer, hvordan en ReAct-agent arbejder hen imod at besvare spørgsmålet "Giv mig de 5 bedste virksomheder med den højeste omsætning i de sidste 2 år, og identificer de risici, der er forbundet med den øverste."
Detaljerne for implementering af denne tilgang i Python er beskrevet i Tilpasset LLM-agent. I vores løsning er agenten og værktøjerne implementeret med følgende fremhævede delarkitektur.
For at besvare et inputspørgsmål bruger vi AWS-tjenester som følger:
- En bruger indtaster deres spørgsmål gennem en brugergrænseflade, som kalder en API på Amazon API Gateway.
- API Gateway sender spørgsmålet til en Lambda-funktion, der implementerer agent eksekveren.
- Agenten ringer til LLM med en prompt, der indeholder en beskrivelse af de tilgængelige værktøjer, ReAct-instruktionsformatet og inputspørgsmålet og analyserer derefter den næste handling, der skal fuldføres.
- Handlingen indeholder hvilket værktøj der skal kaldes, og hvad handlingsinputtet er.
- Hvis værktøjet, der skal bruges, er SQL, kalder agent-executoren SQLQA for at konvertere spørgsmålet til SQL og køre det. Derefter tilføjer den resultatet til prompten og ringer til LLM igen for at se, om den kan besvare det oprindelige spørgsmål, eller om der er behov for flere handlinger.
- På samme måde, hvis værktøjet, der skal bruges, er semantisk søgning, så analyseres handlingsinputtet og bruges til at hente fra PostgreSQL semantiske søgeindeks. Den føjer resultaterne til prompten og kontrollerer, om LLM er i stand til at svare eller har brug for en anden handling.
- Når alle oplysningerne til at besvare et spørgsmål er tilgængelige, formulerer LLM-agenten et endeligt svar og sender det tilbage til brugeren.
Du kan udvide agenten med yderligere værktøjer. I implementeringen tilgængelig på GitHub, demonstrerer vi, hvordan du kan tilføje en søgemaskine og en lommeregner som ekstra værktøjer til den førnævnte SQL-motor og semantiske søgeværktøjer. For at gemme den igangværende samtalehistorik bruger vi en Amazon DynamoDB tabel.
Fra vores hidtidige erfaring har vi set, at følgende er nøglerne til en succesfuld agent:
- En underliggende LLM, der er i stand til at ræsonnere med ReAct-formatet
- En klar beskrivelse af de tilgængelige værktøjer, hvornår de skal bruges, og en beskrivelse af deres input-argumenter med potentielt et eksempel på input og forventet output
- En klar oversigt over ReAct-formatet, som LLM skal følge
- De rigtige værktøjer til at løse forretningsspørgsmålet stillet til rådighed for LLM-agenten at bruge
- Korrekt parsing af output fra LLM-agentens svar, som det begrunder
For at optimere omkostningerne anbefaler vi at cache de mest almindelige spørgsmål med deres svar og opdatere denne cache med jævne mellemrum for at reducere opkald til den underliggende LLM. For eksempel kan du oprette et semantisk søgeindeks med de mest almindelige spørgsmål som forklaret tidligere, og matche det nye brugerspørgsmål med indekset først, før du kalder LLM. For at udforske andre cacheindstillinger, se LLM Caching integrationer.
Understøtter andre formater såsom video, billede, lyd og 3D-filer
Du kan anvende den samme løsning på forskellige typer information, såsom billeder, videoer, lyd og 3D-designfiler som CAD- eller mesh-filer. Dette indebærer at bruge etablerede ML-teknikker til at beskrive filindholdet i tekst, som derefter kan indsættes i den løsning, som vi udforskede tidligere. Denne tilgang giver dig mulighed for at gennemføre QA-samtaler om disse forskellige datatyper. For eksempel kan du udvide din dokumentdatabase ved at oprette tekstmæssige beskrivelser af billeder, videoer eller lydindhold. Du kan også forbedre metadatatabellen ved at identificere egenskaber gennem klassificering eller objektdetektion på elementer i disse formater. Efter at disse udtrukne data er indekseret i enten metadatalageret eller det semantiske søgeindeks for dokumenter, forbliver den overordnede arkitektur af det foreslåede system stort set konsistent.
Konklusion
I dette indlæg viste vi, hvordan brug af LLM'er med RAG-designmønsteret er nødvendigt for at bygge en domænespecifik AI-assistent, men er utilstrækkelig til at nå det nødvendige niveau af pålidelighed til at generere forretningsværdi. På grund af dette foreslog vi at udvide det populære RAG-designmønster med begreberne agenter og værktøjer, hvor fleksibiliteten af værktøjer giver os mulighed for at bruge både traditionelle NLP-teknikker og moderne LLM-kapaciteter for at give en AI-assistent flere muligheder for at søge information og assistere brugere til at løse forretningsproblemer effektivt.
Løsningen demonstrerer designprocessen hen imod en LLM-assistent, der er i stand til at besvare forskellige typer af hentning, analytiske ræsonnementer og flertrins-ræsonnementspørgsmål på tværs af hele din videnbase. Vi fremhævede også vigtigheden af at tænke bagud fra de typer spørgsmål og opgaver, som din LLM-assistent forventes at hjælpe brugerne med. I dette tilfælde førte designrejsen os til en arkitektur med de tre komponenter: semantisk søgning, metadataudtræk og SQL-forespørgsel og LLM-agent og værktøjer, som vi mener er generiske og fleksible nok til flere use cases. Vi tror også på, at ved at få inspiration fra denne løsning og dykke dybt ned i dine brugeres behov, vil du være i stand til at udvide denne løsning yderligere mod det, der fungerer bedst for dig.
Om forfatterne
Mohamed Ali Jamaoui er en Senior ML Prototyping Architect med 10 års erfaring i produktionsmaskinlæring. Han nyder at løse forretningsproblemer med maskinlæring og softwareudvikling og hjælpe kunder med at udvinde forretningsværdi med ML. Som en del af AWS EMEA Prototyping og Cloud Engineering hjælper han kunder med at bygge forretningsløsninger, der udnytter innovationer inden for MLOP'er, NLP, CV og LLM'er.
Giuseppe Hannen er ProServe Associate Consultant. Giuseppe anvender sine analytiske evner i kombination med AI&ML til at udvikle klare og effektive løsninger til sine kunder. Han elsker at komme med enkle løsninger på komplicerede problemer, især dem, der involverer den nyeste teknologiske udvikling og forskning.
Laurens ten Cate er Senior Data Scientist. Laurens arbejder med virksomhedskunder i EMEA og hjælper dem med at accelerere deres forretningsresultater ved hjælp af AWS AI/ML-teknologier. Han har specialiseret sig i NLP-løsninger og fokuserer på Supply Chain & Logistics-industrien. I sin fritid nyder han at læse og kunst.
Irina Radu er en Prototyping Engagement Manager, en del af AWS EMEA Prototyping and Cloud Engineering. Hun hjælper kunder med at få det bedste ud af den nyeste teknologi, innovere hurtigere og tænke større.
- SEO Powered Content & PR Distribution. Bliv forstærket i dag.
- PlatoData.Network Vertical Generative Ai. Styrk dig selv. Adgang her.
- PlatoAiStream. Web3 intelligens. Viden forstærket. Adgang her.
- PlatoESG. Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
- PlatoHealth. Bioteknologiske og kliniske forsøgs intelligens. Adgang 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
- $OP
- 1
- 10
- 100
- 2022
- 3d
- 7
- a
- evne
- I stand
- Om
- fremskynde
- adgang
- tilgængelig
- gennemført
- Konto
- nøjagtighed
- præcis
- præcist
- opnå
- opnå
- tværs
- Lov
- handler
- Handling
- aktioner
- tilpasse
- tilføje
- Derudover
- Tilføjer
- vedtaget
- Efter
- igen
- mod
- Agent
- midler
- AI
- AI assistent
- AI / ML
- algoritme
- Justerer
- Alle
- tillader
- langs med
- også
- Amazon
- Amazon SageMaker
- amazontekst
- Amazon Web Services
- blandt
- an
- analyse
- Analytisk
- analysere
- ,
- En anden
- besvare
- svar
- Antropisk
- enhver
- api
- API'er
- gælder
- Indløs
- tilgang
- passende
- omtrentlig
- arkitektur
- ER
- argumenter
- omkring
- Kunst
- AS
- spørg
- hjælpe
- Assistant
- assistenter
- Associate
- forbundet
- antage
- At
- Angreb
- Forsøg på
- lyd
- forøge
- augmented
- Aurora
- automatisk
- autonom
- til rådighed
- AWS
- tilbage
- Bagende
- Balance
- bund
- baseret
- grundlæggende
- BE
- fordi
- været
- før
- adfærd
- bag
- Tro
- fordele
- BEDSTE
- mellem
- Beyond
- større
- fremme
- både
- bygge
- Bygning
- virksomhed
- virksomheder
- men
- by
- Cache
- CAD
- ringe
- kaldet
- ringer
- Opkald
- CAN
- kandidat
- kapaciteter
- stand
- bære
- tilfælde
- tilfælde
- kæde
- chatbot
- Kontrol
- valg
- valg
- Vælg
- klasse
- klassificering
- klar
- Cloud
- SAMMENHÆNGENDE
- samarbejde
- Kolonne
- Kolonner
- kombination
- kombinerer
- Kom
- Fælles
- Virksomheder
- selskab
- sammenligne
- sammenligne
- sammenligninger
- komplement
- fuldføre
- komplekse
- kompliceret
- komponent
- komponenter
- sammensat
- omfattende
- Compute
- begreber
- beton
- betingelse
- Adfærd
- Tilslut
- Overvej
- overvejelser
- konsekvent
- konsolidere
- konstruere
- konsulent
- indeholder
- indeholdt
- indeholder
- indhold
- sammenhæng
- Samtale
- konversation
- samtale AI
- samtaler
- konvertere
- konverteret
- Core
- korrigere
- korrekt
- Tilsvarende
- Koste
- Omkostninger
- kunne
- koblede
- skabe
- skaber
- Oprettelse af
- Nuværende
- skik
- kunde
- Kunde support
- Kunder
- data
- dataadgang
- dataforsker
- Database
- besluttede
- Beslutter
- dyb
- dybere
- definerede
- definerer
- dykke
- Efterspørgsel
- demo
- demonstrere
- demonstreret
- demonstrerer
- afhængigheder
- indsætte
- beskrive
- beskrevet
- beskriver
- beskrivelse
- Design
- design mønstre
- designproces
- designe
- detaljeret
- detaljer
- opdage
- Detektion
- udvikle
- Udvikling
- udvikling
- digital
- videregivelse
- diskutere
- drøftet
- diskussioner
- afstand
- dyk
- forskelligartede
- dykning
- do
- dokumentet
- dokumentation
- dokumenter
- gør
- Er ikke
- domæne
- Domæner
- færdig
- ned
- driver
- grund
- i løbet af
- dynamisk
- hver
- tidligere
- Tidligt
- lette
- brugervenlighed
- nemt
- Effektiv
- effektivt
- effektivitet
- effektiv
- effektivt
- enten
- elementer
- indlejring
- EMEA
- opstået
- anvendelse
- muliggøre
- muliggør
- muliggør
- ende
- engagement
- Engine (Motor)
- Engineering
- Motorer
- forbedre
- Forbedrer
- nok
- berigende
- Enterprise
- enheder
- enhed
- Miljø
- fejl
- især
- væsentlig
- etableret
- Endog
- udvikle sig
- undersøge
- eksempel
- eksempler
- eksistens
- eksisterende
- Udvid
- forventet
- erfaring
- forklarede
- forklarer
- Forklarer
- udforske
- udforsket
- udsat
- udvide
- strækker
- udvidelse
- ekstra
- ekstrakt
- udvinding
- Uddrag
- konfronteret
- mislykkes
- FAQ
- langt
- hurtigere
- Feature
- Funktionalitet
- tilbagemeldinger
- få
- felt
- File (Felt)
- Filer
- filtrering
- Filtre
- endelige
- Endelig
- finansielle
- Finde
- Fornavn
- Fleksibilitet
- fleksibel
- flow
- Fokus
- fokusering
- efter
- følger
- Til
- formular
- format
- dannet
- formularer
- Framework
- Gratis
- fra
- forsiden
- forreste ende
- opfyldelse
- fuld
- fuldt ud
- funktion
- yderligere
- gateway
- samle
- Generelt
- generere
- genereret
- generere
- generation
- generative
- Generativ AI
- få
- få
- GitHub
- given
- mål
- godt
- gradvist
- indrømme
- gruppe
- Gruppens
- havde
- Have
- have
- he
- hjælpe
- hjælpe
- hjælper
- link.
- Høj
- højeste
- Fremhævet
- hans
- historie
- Forhåbentlig
- Hvordan
- How To
- Men
- HTML
- HTTPS
- menneskelig
- ideer
- identificerer
- identificere
- identificere
- Identity
- if
- billede
- billeder
- billede
- gennemføre
- implementering
- implementeret
- gennemføre
- betydning
- vigtigt
- Forbedre
- forbedret
- forbedringer
- forbedring
- in
- omfatter
- indeks
- indekseret
- industrien
- oplysninger
- informationsudtræk
- initial
- innovere
- innovationer
- indgang
- indgange
- Inspiration
- inspirere
- inspirerede
- installere
- instans
- i stedet
- integrere
- Intelligent
- interagere
- interne
- ind
- indføre
- introduceret
- Invest
- undersøgelse
- investering
- involvere
- IT
- ITS
- selv
- Job
- rejse
- jpg
- json
- Holde
- Nøgle
- nøgler
- viden
- kendt
- Sprog
- stor
- vid udstrækning
- Efternavn
- senere
- seneste
- lanceringer
- lag
- læring
- mindst
- Led
- Længde
- Niveau
- Leverage
- ligesom
- GRÆNSE
- begrænsninger
- LINK
- Liste
- LLM
- belastninger
- Logistik
- logistikbranchen
- Lang
- elsker
- maskine
- machine learning
- lavet
- Main
- vedligeholde
- Vedligeholdelse
- lave
- lykkedes
- leder
- mange
- Match
- matchende
- modne
- Kan..
- me
- betyder
- foranstaltninger
- Mød
- nævner
- blot
- mesh
- besked
- Metadata
- metode
- metoder
- metrisk
- Metrics
- minimum
- misvisende
- mangler
- ML
- MLOps
- model
- modeller
- mådehold
- Moderne
- Moduler
- mere
- Desuden
- mest
- flere
- skal
- navne
- Natural
- Natural Language Processing
- nødvendig
- Behov
- behov
- behov
- naboer
- netto
- nettoomsætning
- aldrig
- Ny
- næste
- NLP
- Ingen
- notesbog
- Begreb
- objekt
- Objektdetektion
- of
- tilbydes
- tilbyde
- offline
- tit
- on
- ONE
- igangværende
- kun
- åbent
- open source
- Produktion
- Optimer
- Indstillinger
- or
- ordrer
- original
- Andet
- Andre
- vores
- ud
- udfald
- skitse
- skitseret
- output
- udgange
- i løbet af
- samlet
- Overvind
- egen
- pakke
- pandaer
- del
- dele
- Mønster
- mønstre
- Udfør
- ydeevne
- tilladelse
- perspektiv
- Pharmaceutical
- stykker
- pipeline
- Almindeligt
- planlægning
- plato
- Platon Data Intelligence
- PlatoData
- plausibel
- Punkt
- politik
- Populær
- popularitet
- befolkede
- mulig
- eventuelt
- Indlæg
- postgresql
- potentiale
- potentielt
- strøm
- vigtigste
- praksis
- Precision
- Forbered
- præsentere
- forelagt
- gaver
- bevare
- forhindre
- forhindrer
- tidligere
- privilegium
- problemløsning
- problemer
- behandle
- forarbejdning
- producerer
- producerer
- Produkt
- produktion
- løfte
- lovende
- egenskaber
- foreslå
- foreslog
- foreslår
- prototyping
- gennemprøvet
- give
- giver
- offentlige
- Python
- Spørgsmål og svar
- forespørgsler
- spørgsmål
- Spørgsmål
- Hurtig
- hurtigt
- Ranking
- hurtige
- Raw
- nå
- nået
- Reagerer
- Læsning
- klar
- ægte
- virkelige verden
- realtid
- grund
- rimelige
- modtaget
- modtagende
- nylige
- for nylig
- genkende
- anbefaler
- Anbefaling
- reducere
- henvise
- region
- relevant
- pålidelighed
- stole
- resterne
- Rapporter
- Repository
- repræsentere
- anmode
- kræver
- påkrævet
- krav
- Kræver
- forskning
- svar
- reaktioner
- REST
- resultere
- Resultater
- afkast
- indtægter
- indtægter
- gennemgå
- højre
- risici
- roller
- regler
- Kør
- kører
- løber
- sagemaker
- samme
- Skalerbarhed
- scanne
- scanning
- Videnskabsmand
- script
- Søg
- søgemaskine
- Anden
- Sektion
- sektioner
- sikkerhed
- Sikkerhedsforanstaltninger
- se
- Søg
- set
- udvælgelse
- valg
- semantik
- sender
- senior
- sendt
- Sequence
- tjeneste
- Tjenester
- hun
- bør
- Vis
- viste
- vist
- lignende
- Simpelt
- forenklet
- forenkle
- samtidigt
- siden
- enkelt
- færdigheder
- So
- indtil nu
- Software
- software Engineering
- Alene
- løsninger
- Løsninger
- Løsning
- nogle
- sommetider
- Kilde
- Kilder
- Space
- specialiserede
- specialiseret
- specifikke
- hastighed
- splits
- stable
- etaper
- starte
- Starter
- styre
- Trin
- Steps
- butik
- opbevaret
- ligetil
- strategier
- Strategi
- strejke
- stræbe
- struktur
- struktureret
- Studio
- vellykket
- sådan
- tyder
- egnede
- opsummere
- forsyne
- forsyningskæde
- support
- Understøtter
- sikker
- syntaks
- systemet
- bord
- skræddersyet
- Tag
- tager
- Opgaver
- opgaver
- tech
- teknikker
- teknologisk
- Teknologier
- fortælle
- ti
- tekst
- tekstmæssige
- Tak
- at
- oplysninger
- deres
- Them
- derefter
- Der.
- derved
- derfor
- Disse
- de
- tror
- Tænker
- denne
- dem
- tre
- Gennem
- tid
- titan
- til
- i dag
- værktøj
- værktøjer
- top
- top 5
- mod
- mod
- Trace
- traditionelle
- Kurser
- Transform
- behandling
- sand
- troværdig
- to
- typen
- typer
- typisk
- ui
- underliggende
- forstå
- indtil
- opdatering
- på
- us
- brug
- anvendte
- Bruger
- Brugererfaring
- brugere
- bruger
- ved brug af
- VALIDATE
- værdi
- Værdier
- række
- forskellige
- alsidige
- video
- Videoer
- Sårbarheder
- gåture
- Vej..
- we
- web
- webservices
- GODT
- var
- Hvad
- hvornår
- ud fra følgende betragtninger
- hvorvidt
- som
- mens
- hvorfor
- Wikipedia
- vilje
- med
- inden for
- uden
- virker
- ville
- skrivning
- X
- år
- år
- Du
- Din
- zephyrnet