Conversational AI har kommit långt de senaste åren tack vare den snabba utvecklingen inom generativ AI, särskilt prestationsförbättringarna av stora språkmodeller (LLM) introducerade genom träningstekniker som instruktionsfinjustering och förstärkningsinlärning från mänsklig feedback. När de uppmanas på rätt sätt kan dessa modeller bära sammanhängande konversationer utan uppgiftsspecifika träningsdata. De kan dock inte generalisera bra till företagsspecifika frågor eftersom de, för att generera ett svar, förlitar sig på den offentliga information de exponerades för under förutbildningen. Sådana data saknar ofta den specialiserade kunskap som finns i interna dokument som finns tillgängliga i moderna företag, vilket vanligtvis behövs för att få korrekta svar inom områden som läkemedelsforskning, finansiell utredning och kundsupport.
För att skapa AI-assistenter som kan föra diskussioner grundade på specialiserad företagskunskap måste vi koppla dessa kraftfulla men generiska LLM till interna kunskapsbaser för dokument. Denna metod för att berika LLM-genereringskontexten med information som hämtas från dina interna datakällor kallas Retrieval Augmented Generation (RAG), och producerar assistenter som är domänspecifika och mer pålitliga, vilket visas av Retrieval-Augmented Generation för kunskapsintensiva NLP-uppgifter. En annan drivkraft bakom RAG:s popularitet är dess enkla implementering och förekomsten av mogna vektorsökningslösningar, såsom de som erbjuds av Amazon Kendra (Se Amazon Kendra lanserar Retrieval API) Och Amazon OpenSearch Service (Se k-Nearest Neighbor (k-NN) sökning i Amazon OpenSearch Service), bland andra.
Det populära RAG-designmönstret med semantisk sökning kan dock inte svara på alla typer av frågor som är möjliga på dokument. Detta gäller särskilt för frågor som kräver analytiska resonemang över flera dokument. Föreställ dig till exempel att du planerar nästa års strategi för ett investeringsbolag. Ett viktigt steg skulle vara att analysera och jämföra kandidatföretagens ekonomiska resultat och potentiella risker. Denna uppgift innebär att besvara analytiska resonemangsfrågor. Till exempel kräver frågan "Ge mig de fem bästa företagen med de högsta intäkterna under de senaste 5 åren och identifiera deras huvudsakliga risker" flera steg av resonemang, av vilka några kan använda semantisk sökhämtning, medan andra kräver analytisk förmåga.
I det här inlägget visar vi hur man designar en intelligent dokumentassistent som kan svara på analytiska och flerstegsresonemangsfrågor i tre delar. I del 1 går vi igenom RAG-designmönstret och dess begränsningar i analytiska frågor. Sedan introducerar vi dig för en mer mångsidig arkitektur som övervinner dessa begränsningar. Del 2 hjälper dig att dyka djupare in i entitetsextraktionspipelinen som används för att förbereda strukturerad data, vilket är en nyckelingrediens för att svara på analytiska frågor. Del 3 går igenom hur du använder Amazonas berggrund LLM:er för att söka efter dessa data och bygga en LLM-agent som förbättrar RAG med analytiska möjligheter, vilket gör att du kan bygga intelligenta dokumentassistenter som kan svara på komplexa domänspecifika frågor över flera dokument.
Del 1: RAG-begränsningar och lösningsöversikt
I det här avsnittet granskar vi RAG-designmönstret och diskuterar dess begränsningar i analytiska frågor. Vi presenterar också en mer mångsidig arkitektur som övervinner dessa begränsningar.
Översikt över RAG
RAG-lösningar är inspirerade av representation lärande och semantisk sökning idéer som successivt har antagits i rankningsproblem (till exempel rekommendationer och sökning) och naturliga språkbehandlingsuppgifter (NLP) sedan 2010.
Det populära tillvägagångssättet som används idag består av tre steg:
- Ett offline-batch-bearbetningsjobb matar in dokument från en indatabas, delar upp dem i bitar, skapar en inbäddning för varje bit för att representera dess semantik med hjälp av en förtränad inbäddningsmodell, som t.ex. Amazon Titan inbäddningsmodeller, använder sedan dessa inbäddningar som indata för att skapa ett semantiskt sökindex.
- När man svarar på en ny fråga i realtid, konverteras inmatningsfrågan till en inbäddning, som används för att söka efter och extrahera de mest liknande bitarna av dokument med hjälp av ett likhetsmått, såsom cosinuslikhet, och en ungefärlig algoritm för närmaste grannar. Sökprecisionen kan också förbättras med metadatafiltrering.
- En prompt konstrueras från sammanlänkningen av ett systemmeddelande med ett sammanhang som är bildat av de relevanta bitarna av dokument som extraherats i steg 2, och själva inmatningsfrågan. Denna prompt presenteras sedan för en LLM-modell för att generera det slutliga svaret på frågan från sammanhanget.
Med rätt underliggande inbäddningsmodell, kapabel att producera korrekta semantiska representationer av indatadokumentbitarna och ingångsfrågorna, och en effektiv semantisk sökmodul, kan denna lösning svara på frågor som kräver att man hämtar befintlig information i en databas med dokument. Om du till exempel har en tjänst eller en produkt kan du börja med att indexera dess FAQ-sektion eller dokumentation och få en första konversations-AI som är skräddarsydd för ditt specifika erbjudande.
Begränsningar för RAG baserat på semantisk sökning
Även om RAG är en viktig komponent i moderna domänspecifika AI-assistenter och en vettig utgångspunkt för att bygga en konversations-AI kring en specialiserad kunskapsbas, kan den inte svara på frågor som kräver genomsökning, jämförelse och resonemang över alla dokument i din kunskapsbas samtidigt, särskilt när förstärkningen enbart baseras på semantisk sökning.
För att förstå dessa begränsningar, låt oss återigen överväga exemplet med att bestämma var vi ska investera baserat på finansiella rapporter. Om vi skulle använda RAG för att konversera med dessa rapporter skulle vi kunna ställa frågor som "Vilka är riskerna som företag X stod inför 2022" eller "Vilka är nettointäkterna för företag Y 2022?" För var och en av dessa frågor används motsvarande inbäddningsvektor, som kodar den semantiska betydelsen av frågan, för att hämta de top-K semantiskt liknande bitarna av dokument som finns tillgängliga i sökindexet. Detta åstadkoms vanligtvis genom att använda en ungefärlig lösning för närmaste grannar som t.ex FAISS, NMSLIB, pgvector eller andra, som strävar efter att hitta en balans mellan hämtningshastighet och återkallelse för att uppnå realtidsprestanda samtidigt som tillfredsställande noggrannhet bibehålls.
Det föregående tillvägagångssättet kan dock inte svara exakt på analytiska frågor i alla dokument, som "Vilka är de fem bästa företagen med de högsta nettointäkterna 5?"
Detta beror på att semantisk sökning försöker hitta de K mest liknande bitarna av dokument till inmatningsfrågan. Men eftersom inget av dokumenten innehåller heltäckande sammanfattningar av intäkter, kommer det att returnera bitar av dokument som bara innehåller omnämnanden om "nettointäkter" och möjligen "2022", utan att uppfylla det väsentliga villkoret att fokusera på företag med högst intäkter. Om vi presenterar dessa hämtningsresultat för en LLM som kontext för att svara på ingångsfrågan, kan den formulera ett missvisande svar eller vägra att svara, eftersom den nödvändiga korrekta informationen saknas.
Dessa begränsningar kommer genom design eftersom semantisk sökning inte genomför en grundlig genomsökning av alla inbäddningsvektorer för att hitta relevanta dokument. Istället använder den ungefärliga metoder för närmaste granne för att upprätthålla rimlig hämtningshastighet. En nyckelstrategi för effektivitet i dessa metoder är att segmentera inbäddningsutrymmet i grupper under indexering. Detta gör det möjligt att snabbt identifiera vilka grupper som kan innehålla relevanta inbäddningar under hämtning, utan behov av parvisa jämförelser. Dessutom, även traditionella närmaste grannar-tekniker som KNN, som skannar alla dokument, bara beräknar grundläggande avståndsmått och är inte lämpliga för de komplexa jämförelser som behövs för analytiska resonemang. Därför är RAG med semantisk sökning inte skräddarsydd för att svara på frågor som involverar analytiska resonemang över alla dokument.
För att övervinna dessa begränsningar föreslår vi en lösning som kombinerar RAG med metadata och entitetsextraktion, SQL-förfrågningar och LLM-agenter, som beskrivs i följande avsnitt.
Övervinner RAG-begränsningar med metadata, SQL och LLM-agenter
Låt oss undersöka djupare en fråga där RAG misslyckas, så att vi kan spåra det resonemang som krävs för att besvara den effektivt. Denna analys bör peka oss mot rätt tillvägagångssätt som skulle kunna komplettera RAG i den övergripande lösningen.
Tänk på frågan: "Vilka är de fem bästa företagen med högst intäkter 5?"
För att kunna svara på denna fråga skulle vi behöva:
- Identifiera intäkterna för varje företag.
- Filtrera ner för att behålla intäkterna från 2022 för var och en av dem.
- Sortera intäkterna i fallande ordning.
- Dela ut de fem bästa intäkterna tillsammans med företagsnamnen.
Vanligtvis görs dessa analytiska operationer på strukturerad data, med hjälp av verktyg som pandor eller SQL-motorer. Om vi hade tillgång till en SQL-tabell som innehåller kolumnerna company
, revenue
och year
, kan vi enkelt svara på vår fråga genom att köra en SQL-fråga, liknande följande exempel:
SELECT company, revenue FROM table_name WHERE year = 2022 ORDER BY revenue DESC LIMIT 5;
Att lagra strukturerad metadata i en SQL-tabell som innehåller information om relevanta enheter gör att du kan svara på många typer av analytiska frågor genom att skriva rätt SQL-fråga. Det är därför vi kompletterar RAG i vår lösning med en SQL-förfrågningsmodul i realtid mot en SQL-tabell, fylld av metadata extraherad i en offlineprocess.
Men hur kan vi implementera och integrera detta tillvägagångssätt till en LLM-baserad konversations-AI?
Det finns tre steg för att kunna lägga till SQL analytiska resonemang:
- Metadataextraktion – Extrahera metadata från ostrukturerade dokument till en SQL-tabell
- Text till SQL – Formulera SQL-frågor från indatafrågor korrekt med hjälp av en LLM
- Verktygsval – Identifiera om en fråga måste besvaras med RAG eller en SQL-fråga
För att implementera dessa steg inser vi först att informationsextraktion från ostrukturerade dokument är en traditionell NLP-uppgift för vilken LLM:er visar löfte om att uppnå hög noggrannhet genom noll- eller få-shot-inlärning. För det andra har dessa modellers förmåga att generera SQL-frågor från naturligt språk bevisats i flera år, vilket framgår av 2020 release of Amazon QuickSight Q. Slutligen, automatiskt val av rätt verktyg för en specifik fråga förbättrar användarupplevelsen och gör det möjligt att svara på komplexa frågor genom resonemang i flera steg. För att implementera den här funktionen fördjupar vi oss i LLM-agenter i ett senare avsnitt.
För att sammanfatta, den lösning vi föreslår består av följande kärnkomponenter:
- Semantisk sökhämtning för att öka generationskontexten
- Strukturerad metadataextraktion och sökning med SQL
- En agent som kan använda rätt verktyg för att svara på en fråga
Lösningsöversikt
Följande diagram visar en förenklad arkitektur av lösningen. Det hjälper dig att identifiera och förstå kärnkomponenternas roll och hur de interagerar för att implementera hela LLM-assistentens beteende. Numreringen överensstämmer med operationsordningen när denna lösning implementeras.
I praktiken implementerade vi denna lösning som beskrivs i följande detaljerade arkitektur.
För denna arkitektur föreslår vi en implementering på GitHub, med löst kopplade komponenter där backend (5), datapipelines (1, 2, 3) och frontend (4) kan utvecklas separat. Detta för att förenkla samarbetet över kompetenser vid anpassning och förbättring av lösningen för produktion.
Distribuera lösningen
För att installera den här lösningen i ditt AWS-konto, utför följande steg:
- Klona förvaret på GitHub.
- Installera backend AWS Cloud Development Kit (AWS CDK) app:
- Öppna
backend
mapp. - Körning
npm install
för att installera beroenden. - Om du aldrig har använt AWS CDK i det aktuella kontot och regionen, kör bootstrapping med
npx cdk bootstrap
. - Körning
npx cdk deploy
att distribuera stacken.
- Öppna
- Om du vill kan du köra
streamlit-ui
enligt följande:- Vi rekommenderar att du klona detta arkiv till en Amazon SageMaker Studio miljö. För mer information, se Ombord på Amazon SageMaker Domain med snabbinställning.
- Inuti
frontend/streamlit-ui
mapp, körbash run-streamlit-ui.sh
. - Välj länken med följande format för att öppna demon:
https://{domain_id}.studio.{region}.sagemaker.aws/jupyter/default/proxy/{port_number}/
.
- Äntligen kan du köra Amazon SageMaker pipeline definierad i
data-pipelines/04-sagemaker-pipeline-for-documents-processing.ipynb
anteckningsbok för att bearbeta ingående PDF-dokument och förbereda SQL-tabellen och det semantiska sökindexet som används av LLM-assistenten.
I resten av det här inlägget fokuserar vi på att förklara de viktigaste komponenterna och designvalen, för att förhoppningsvis inspirera dig när du designar din egen AI-assistent på en intern kunskapsbas. Vi antar att komponenterna 1 och 4 är enkla att förstå och fokuserar på kärnkomponenterna 2, 3 och 5.
Del 2: Entitetsutvinningspipeline
I det här avsnittet dyker vi djupare in i entitetsextraktionspipelinen som används för att förbereda strukturerad data, vilket är en nyckelingrediens för att svara på analytiska frågor.
Textextraktion
Dokument lagras vanligtvis i PDF-format eller som skannade bilder. De kan bestå av enkla styckelayouter eller komplexa tabeller och innehålla digital eller handskriven text. För att extrahera information korrekt måste vi omvandla dessa rådokument till vanlig text, samtidigt som deras ursprungliga struktur bevaras. För att göra detta kan du använda amazontext, som är en maskininlärningstjänst (ML) som tillhandahåller mogna API:er för text, tabeller och formulärextraktion från digitala och handskrivna indata.
I komponent 2 extraherar vi text och tabeller enligt följande:
- För varje dokument kallar vi Amazon Textract för att extrahera texten och tabellerna.
- Vi använder följande Python-manus för att återskapa tabeller som pandas DataFrames.
- Vi konsoliderar resultaten till ett enda dokument och infogar tabeller som markdown.
Denna process beskrivs av följande flödesdiagram och demonstreras konkret i notebooks/03-pdf-document-processing.ipynb
.
Entitetsextraktion och förfrågningar med hjälp av LLM
För att svara på analytiska frågor effektivt måste du extrahera relevant metadata och entiteter från ditt dokuments kunskapsbas till ett tillgängligt strukturerat dataformat. Vi föreslår att du använder SQL för att lagra denna information och hämta svar på grund av dess popularitet, användarvänlighet och skalbarhet. Detta val drar också nytta av de beprövade språkmodellernas förmåga att generera SQL-frågor från naturligt språk.
I det här avsnittet dyker vi djupare in i följande komponenter som möjliggör analytiska frågor:
- En batchprocess som extraherar strukturerad data ur ostrukturerad data med hjälp av LLM
- En realtidsmodul som konverterar naturliga språkfrågor till SQL-frågor och hämtar resultat från en SQL-databas
Du kan extrahera relevant metadata för att stödja analytiska frågor enligt följande:
- Definiera ett JSON-schema för information du behöver extrahera, som innehåller en beskrivning av varje fält och dess datatyp, och inkluderar exempel på förväntade värden.
- För varje dokument, fråga en LLM med JSON-schemat och be den att extrahera relevant data korrekt.
- När dokumentlängden är längre än kontextlängden, och för att minska extraheringskostnaden med LLM, kan du använda semantisk sökning för att hämta och presentera relevanta dokumentbitar för LLM under extrahering.
- Analysera JSON-utgången och validera LLM-extraktionen.
- Alternativt kan du säkerhetskopiera resultaten på Amazon S3 som CSV-filer.
- Ladda in i SQL-databasen för senare förfrågningar.
Denna process hanteras av följande arkitektur, där dokumenten i textformat laddas med ett Python-skript som körs i en Amazon SageMaker-bearbetning jobb att utföra utvinningen.
För varje grupp av enheter konstruerar vi dynamiskt en prompt som inkluderar en tydlig beskrivning av informationsextraktionsuppgiften och inkluderar ett JSON-schema som definierar förväntad utdata och inkluderar relevanta dokumentbitar som kontext. Vi lägger också till några exempel på input och korrekt utdata för att förbättra extraktionsprestandan med få-shot-inlärning. Detta demonstreras i notebooks/05-entities-extraction-to-structured-metadata.ipynb
.
Del 3: Bygg en agent dokumentassistent med Amazon Bedrock
I det här avsnittet visar vi hur du använder Amazon Bedrock LLM:er för att söka efter data och bygga en LLM-agent som förbättrar RAG med analytiska kapaciteter, vilket gör att du kan bygga intelligenta dokumentassistenter som kan svara på komplexa domänspecifika frågor över flera dokument. Du kan hänvisa till Lambdafunktion på GitHub för den konkreta implementeringen av agenten och verktygen som beskrivs i denna del.
Formulera SQL-frågor och svara på analytiska frågor
Nu när vi har ett strukturerat metadatalager med relevanta entiteter extraherade och inlästa i en SQL-databas som vi kan fråga, är frågan som återstår hur man genererar rätt SQL-fråga från de ingående naturliga språkfrågorna?
Moderna LLM:er är bra på att generera SQL. Till exempel, om du begär från den antropiska Claude LLM genom Amazonas berggrund för att generera en SQL-fråga kommer du att se rimliga svar. Vi måste dock följa några regler när vi skriver prompten för att nå mer exakta SQL-frågor. Dessa regler är särskilt viktiga för komplexa frågor för att minska hallucinationer och syntaxfel:
- Beskriv uppgiften noggrant inom prompten
- Inkludera schemat för SQL-tabellerna i prompten, samtidigt som du beskriver varje kolumn i tabellen och anger dess datatyp
- Berätta uttryckligen för LLM att endast använda befintliga kolumnnamn och datatyper
- Lägg till några rader av SQL-tabellerna
Du kan också efterbehandla den genererade SQL-frågan med en lykta såsom sqlfluff för att korrigera formatering, eller en parser som t.ex sqlglot för att upptäcka syntaxfel och optimera frågan. Dessutom, när prestandan inte uppfyller kraven, kan du ge några exempel i prompten för att styra modellen med enkel inlärning mot att generera mer exakta SQL-frågor.
Ur ett implementeringsperspektiv använder vi en AWS Lambda funktion för att orkestrera följande process:
- Ring en antropisk Claude-modell i Amazon Bedrock med ingångsfrågan för att få motsvarande SQL-fråga. Här använder vi SQLDatabas klass från LangChain för att lägga till schemabeskrivningar av relevanta SQL-tabeller och använda en anpassad prompt.
- Analysera, validera och kör SQL-frågan mot Amazon Aurora PostgreSQL-kompatibel utgåva databas.
Arkitekturen för denna del av lösningen framhävs i följande diagram.
Säkerhetsaspekter för att förhindra SQL-injektionsattacker
Eftersom vi gör det möjligt för AI-assistenten att fråga efter en SQL-databas måste vi se till att detta inte leder till säkerhetsbrister. För att uppnå detta föreslår vi följande säkerhetsåtgärder för att förhindra SQL-injektionsattacker:
- Tillämpa IAM-behörigheter med minst privilegier – Begränsa behörigheten för Lambda-funktionen som kör SQL-frågorna med en AWS identitets- och åtkomsthantering (IAM) policy och roll som följer minsta privilegieprincipen. I det här fallet ger vi skrivskyddad åtkomst.
- Begränsa dataåtkomst – Ge endast åtkomst till det absoluta minimum av tabeller och kolumner för att förhindra informationsattacker.
- Lägg till ett modereringslager – Inför ett modereringslager som upptäcker snabba injektionsförsök tidigt och förhindrar dem från att spridas till resten av systemet. Det kan ta formen av regelbaserade filter, likhetsmatchning mot en databas med kända exempel på snabbinjektion eller en ML-klassificerare.
Semantisk sökhämtning för att öka generationskontexten
Lösningen vi föreslår använder RAG med semantisk sökning i komponent 3. Du kan implementera denna modul med hjälp av kunskapsbaser för Amazon Bedrock. Dessutom finns det en mängd andra alternativ för att implementera RAG, såsom Amazon Kendra Retrieval API, Amazon OpenSearch vektordatabasoch Amazon Aurora PostgreSQL med pgvektor, bland andra. Paketet med öppen källkod aws-genai-llm-chatbot visar hur man använder många av dessa vektorsökalternativ för att implementera en LLM-driven chatbot.
I den här lösningen, eftersom vi behöver både SQL-fråga och vektorsökning, bestämde vi oss för att använda Amazon Aurora PostgreSQL med pgvektor tillägg, som stöder båda funktionerna. Därför implementerar vi RAG-komponenten semantisk sökning med följande arkitektur.
Processen att besvara frågor med hjälp av den föregående arkitekturen görs i två huvudsteg.
Först skapar en offline-batchprocess, körd som ett SageMaker Processing-jobb, det semantiska sökindexet enligt följande:
- Antingen med jämna mellanrum, eller vid mottagande av nya dokument, körs ett SageMaker-jobb.
- Den laddar textdokumenten från Amazon S3 och delar upp dem i överlappande bitar.
- För varje bit använder den en Amazon Titan-inbäddningsmodell för att generera en inbäddningsvektor.
- Den använder PGVector klass från LangChain för att mata in inbäddningarna, med deras dokumentbitar och metadata, i Amazon Aurora PostgreSQL och skapa ett semantiskt sökindex på alla inbäddningsvektorer.
För det andra, i realtid och för varje ny fråga, konstruerar vi ett svar enligt följande:
- Frågan tas emot av orkestratorn som kör på en lambdafunktion.
- Orkestratören bäddar in frågan med samma inbäddningsmodell.
- Den hämtar de översta K mest relevanta dokumentbitarna från PostgreSQL semantiska sökindex. Den använder valfritt metadatafiltrering för att förbättra precisionen.
- Dessa bitar infogas dynamiskt i en LLM-prompt bredvid inmatningsfrågan.
- Uppmaningen presenteras för Anthropic Claude på Amazon Bedrock, för att instruera den att svara på ingångsfrågan baserat på det tillgängliga sammanhanget.
- Slutligen skickas det genererade svaret tillbaka till orkestratorn.
En agent som kan använda verktyg för att resonera och agera
Hittills i det här inlägget har vi diskuterat att behandla frågor som kräver antingen RAG eller analytiska resonemang separat. Men många frågor i den verkliga världen kräver båda funktionerna, ibland över flera steg av resonemang, för att nå ett slutgiltigt svar. För att stödja dessa mer komplexa frågor måste vi introducera begreppet en agent.
LLM-agenter, såsom agenter för Amazon Bedrock, har nyligen dykt upp som en lovande lösning som kan använda LLM:er för att resonera och anpassa med det aktuella sammanhanget och för att välja lämpliga åtgärder från en lista med alternativ, som presenterar en generell problemlösningsram. Som diskuterats i LLM-drivna autonoma agenter, det finns flera uppmaningsstrategier och designmönster för LLM-agenter som stöder komplexa resonemang.
Ett sådant designmönster är Reason and Act (ReAct), introducerat i ReAct: Synergisera resonemang och agerande i språkmodeller. I ReAct tar agenten som input ett mål som kan vara en fråga, identifierar de delar av information som saknas för att besvara det och föreslår iterativt rätt verktyg för att samla information baserat på de tillgängliga verktygens beskrivningar. Efter att ha mottagit svaret från ett visst verktyg, bedömer LLM om den har all information den behöver för att fullständigt svara på frågan. Om inte, gör den ytterligare ett steg av resonemang och använder samma eller ett annat verktyg för att samla in mer information, tills ett slutgiltigt svar är klart eller en gräns nås.
Följande sekvensdiagram förklarar hur en ReAct-agent arbetar för att svara på frågan "Ge mig de 5 bästa företagen med högst intäkter under de senaste 2 åren och identifiera riskerna förknippade med det översta."
Detaljerna för att implementera denna metod i Python beskrivs i Anpassad LLM-agent. I vår lösning implementeras agenten och verktygen med följande markerade delarkitektur.
För att svara på en ingångsfråga använder vi AWS-tjänster enligt följande:
- En användare matar in sin fråga via ett användargränssnitt som anropar ett API Amazon API Gateway.
- API Gateway skickar frågan till en Lambda-funktion som implementerar agentexekutorn.
- Agenten anropar LLM med en prompt som innehåller en beskrivning av tillgängliga verktyg, ReAct-instruktionsformatet och inmatningsfrågan och analyserar sedan nästa åtgärd som ska slutföras.
- Åtgärden innehåller vilket verktyg som ska anropas och vad åtgärdsinmatningen är.
- Om verktyget som ska användas är SQL, anropar agentexekutorn SQLQA för att konvertera frågan till SQL och köra den. Sedan lägger den till resultatet i prompten och ringer upp LLM igen för att se om den kan svara på den ursprungliga frågan eller om fler åtgärder behövs.
- På liknande sätt, om verktyget som ska användas är semantisk sökning, analyseras åtgärdsinmatningen och används för att hämta från PostgreSQL semantiska sökindex. Den lägger till resultaten i prompten och kontrollerar om LLM kan svara eller behöver en annan åtgärd.
- När all information för att svara på en fråga är tillgänglig, formulerar LLM-agenten ett slutgiltigt svar och skickar tillbaka det till användaren.
Du kan utöka agenten med ytterligare verktyg. I genomförandet tillgänglig på GitHub, visar vi hur du kan lägga till en sökmotor och en kalkylator som extra verktyg till den tidigare nämnda SQL-motorn och semantiska sökverktygen. För att lagra den pågående konversationshistoriken använder vi en Amazon DynamoDB tabell.
Av vår erfarenhet hittills har vi sett att följande är nycklarna till en framgångsrik agent:
- En underliggande LLM som kan resonera med ReAct-formatet
- En tydlig beskrivning av de tillgängliga verktygen, när de ska användas och en beskrivning av deras input-argument med, potentiellt, ett exempel på input och förväntad output
- En tydlig översikt över ReAct-formatet som LLM måste följa
- Rätt verktyg för att lösa affärsfrågan görs tillgängliga för LLM-agenten att använda
- Korrekt analysera utdata från LLM-agentsvaren som den resonerar
För att optimera kostnaderna rekommenderar vi att cachelagrar de vanligaste frågorna med deras svar och uppdaterar denna cache med jämna mellanrum för att minska antalet samtal till den underliggande LLM. Du kan till exempel skapa ett semantiskt sökindex med de vanligaste frågorna som förklarats tidigare, och matcha den nya användarfrågan mot indexet innan du anropar LLM. För att utforska andra cachningsalternativ, se LLM Caching integrationer.
Stöder andra format som video, bild, ljud och 3D-filer
Du kan tillämpa samma lösning på olika typer av information, såsom bilder, videor, ljud och 3D-designfiler som CAD- eller mesh-filer. Detta innebär att man använder etablerade ML-tekniker för att beskriva filinnehållet i text, som sedan kan matas in i lösningen som vi utforskade tidigare. Detta tillvägagångssätt gör att du kan föra QA-konversationer om dessa olika datatyper. Du kan till exempel utöka din dokumentdatabas genom att skapa textbeskrivningar av bilder, videor eller ljudinnehåll. Du kan också förbättra metadatatabellen genom att identifiera egenskaper genom klassificering eller objektdetektering på element i dessa format. Efter att denna extraherade data har indexerats i antingen metadatalagret eller det semantiska sökindexet för dokument, förblir den övergripande arkitekturen för det föreslagna systemet i stort sett konsekvent.
Slutsats
I det här inlägget visade vi hur det är nödvändigt att använda LLM med RAG-designmönstret för att bygga en domänspecifik AI-assistent, men det är otillräckligt för att nå den erforderliga tillförlitlighetsnivån för att skapa affärsvärde. På grund av detta föreslog vi att utöka det populära RAG-designmönstret med begreppen agenter och verktyg, där flexibiliteten hos verktyg gör att vi kan använda både traditionella NLP-tekniker och moderna LLM-funktioner för att ge en AI-assistent fler alternativ att söka information och hjälpa till användare för att lösa affärsproblem effektivt.
Lösningen visar designprocessen mot en LLM-assistent som kan svara på olika typer av hämtning, analytiska resonemang och flerstegsresonemangsfrågor över hela din kunskapsbas. Vi lyfte också fram vikten av att tänka bakåt från de typer av frågor och uppgifter som din LLM-assistent förväntas hjälpa användare med. I det här fallet ledde designresan oss till en arkitektur med de tre komponenterna: semantisk sökning, extrahering av metadata och SQL-förfrågningar, och LLM-agent och verktyg, som vi tycker är generiska och flexibla nog för flera användningsfall. Vi tror också att genom att hämta inspiration från den här lösningen och dyka djupt in i dina användares behov, kommer du att kunna utöka denna lösning ytterligare mot det som fungerar bäst för dig.
Om författarna
Mohamed Ali Jamaoui är en Senior ML Prototyping Architect med 10 års erfarenhet av produktionsmaskininlärning. Han tycker om att lösa affärsproblem med maskininlärning och mjukvaruteknik och att hjälpa kunder att utvinna affärsvärde med ML. Som en del av AWS EMEA Prototyping and Cloud Engineering hjälper han kunder att bygga affärslösningar som utnyttjar innovationer inom MLOPs, NLP, CV och LLMs.
Giuseppe Hannen är en ProServe Associate Consultant. Giuseppe tillämpar sin analytiska förmåga i kombination med AI&ML för att utveckla tydliga och effektiva lösningar för sina kunder. Han älskar att komma med enkla lösningar på komplicerade problem, särskilt de som involverar den senaste tekniska utvecklingen och forskningen.
Laurens ten Cate är Senior Data Scientist. Laurens arbetar med företagskunder i EMEA och hjälper dem att påskynda sina affärsresultat med hjälp av AWS AI/ML-teknik. Han är specialiserad på NLP-lösningar och fokuserar på Supply Chain & Logistics-branschen. På fritiden tycker han om läsning och konst.
Irina Radu är en Prototyping Engagement Manager, en del av AWS EMEA Prototyping and Cloud Engineering. Hon hjälper kunder att få ut det bästa av den senaste tekniken, förnya snabbare och tänka större.
- SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
- PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
- PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
- Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
- PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
- Källa: https://aws.amazon.com/blogs/machine-learning/boosting-rag-based-intelligent-document-assistants-using-entity-extraction-sql-querying-and-agents-with-amazon-bedrock/
- : har
- :är
- :inte
- :var
- $UPP
- 1
- 10
- 100
- 2022
- 3d
- 7
- a
- förmåga
- Able
- Om Oss
- accelerera
- tillgång
- tillgänglig
- åstadkommit
- Konto
- noggrannhet
- exakt
- exakt
- Uppnå
- uppnå
- tvärs
- Agera
- verkande
- Handling
- åtgärder
- anpassa
- lägga till
- Dessutom
- Lägger
- antagen
- Efter
- igen
- mot
- Recensioner
- medel
- AI
- AI-assistent
- AI / ML
- algoritm
- Justerar
- Alla
- tillåter
- vid sidan av
- också
- amason
- Amazon SageMaker
- amazontext
- Amazon Web Services
- bland
- an
- analys
- Analytisk
- analysera
- och
- Annan
- svara
- svar
- Antropisk
- vilken som helst
- api
- API: er
- applicerar
- Ansök
- tillvägagångssätt
- lämpligt
- ungefärlig
- arkitektur
- ÄR
- argument
- runt
- Konst
- AS
- be
- bistå
- Assistent
- assistenter
- Associate
- associerad
- utgå ifrån
- At
- Attacker
- Försök
- audio
- förstärka
- augmented
- aurora
- automatiskt
- autonom
- tillgänglig
- AWS
- tillbaka
- backend
- Balansera
- bas
- baserat
- grundläggande
- BE
- därför att
- varit
- innan
- beteende
- bakom
- tro
- Fördelarna
- BÄST
- mellan
- Bortom
- större
- öka
- båda
- SLUTRESULTAT
- Byggnad
- företag
- företag
- men
- by
- Cache
- CAD
- Ring
- kallas
- anropande
- Samtal
- KAN
- kandidat
- kapacitet
- kapabel
- bära
- Vid
- fall
- kedja
- chatbot
- Kontroller
- val
- val
- Välja
- klass
- klassificering
- klar
- cloud
- SAMMANHÄNGANDE
- samverkan
- Kolumn
- Kolonner
- kombination
- kombinerar
- komma
- Gemensam
- Företag
- företag
- jämföra
- jämförande
- jämförelser
- Komplement
- fullborda
- komplex
- komplicerad
- komponent
- komponenter
- sammansatt
- omfattande
- Compute
- Begreppen
- betong
- tillstånd
- Genomför
- Kontakta
- Tänk
- överväganden
- konsekvent
- konsolidera
- konstruera
- konsult
- innehålla
- innehöll
- innehåller
- innehåll
- sammanhang
- Konversation
- konversera
- konversations AI
- konversationer
- konvertera
- konverterad
- Kärna
- korrekt
- korrekt
- Motsvarande
- Pris
- Kostar
- kunde
- kopplad
- skapa
- skapar
- Skapa
- Aktuella
- beställnings
- kund
- Helpdesk
- Kunder
- datum
- datatillgång
- datavetare
- Databas
- beslutade
- Avgörande
- djup
- djupare
- definierade
- definierar
- gräva
- Efterfrågan
- demo
- demonstrera
- demonstreras
- demonstrerar
- beroenden
- distribuera
- beskriva
- beskriven
- beskriver
- beskrivning
- Designa
- Design mönster
- designprocessen
- design
- detaljerad
- detaljer
- upptäcka
- Detektering
- utveckla
- Utveckling
- utvecklingen
- digital
- avslöjande
- diskutera
- diskuteras
- diskussioner
- avstånd
- Dyk
- flera
- dykning
- do
- dokumentera
- dokumentation
- dokument
- gör
- inte
- domän
- domäner
- gjort
- ner
- chaufför
- grund
- under
- dynamiskt
- varje
- Tidigare
- Tidig
- lätta
- enkel användning
- lätt
- Effektiv
- effektivt
- effektivitet
- effektiv
- effektivt
- antingen
- element
- inbäddning
- EMEA
- dykt
- utnyttjande
- möjliggöra
- möjliggör
- möjliggör
- änden
- ingrepp
- Motor
- Teknik
- Motorer
- förbättra
- Förbättrar
- tillräckligt
- berikande
- Företag
- enheter
- enhet
- Miljö
- fel
- speciellt
- väsentlig
- etablerade
- Även
- utvecklas
- undersöka
- exempel
- exempel
- Förekomsten
- befintliga
- Bygga ut
- förväntat
- erfarenhet
- förklarade
- förklara
- Förklarar
- utforska
- utforskas
- utsatta
- förlänga
- sträcker
- förlängning
- extra
- extrahera
- extraktion
- extrakt
- inför
- misslyckas
- FAQ
- långt
- snabbare
- Leverans
- Funktioner
- återkoppling
- få
- fält
- Fil
- Filer
- filtrering
- filter
- slutlig
- Slutligen
- finansiella
- hitta
- Förnamn
- Flexibilitet
- flexibel
- flöda
- Fokus
- fokusering
- efter
- följer
- För
- formen
- format
- bildad
- former
- Ramverk
- Fri
- från
- främre
- främre ände
- uppfylla
- full
- fullständigt
- fungera
- ytterligare
- nätbryggan
- samla
- Allmänt
- generera
- genereras
- generera
- generering
- generativ
- Generativ AI
- skaffa sig
- få
- GitHub
- ges
- Målet
- god
- gradvis
- bevilja
- Grupp
- Gruppens
- hade
- Har
- har
- he
- hjälpa
- hjälpa
- hjälper
- här.
- Hög
- högsta
- Markerad
- hans
- historia
- Förhoppningsvis
- Hur ser din drömresa ut
- How To
- Men
- html
- HTTPS
- humant
- idéer
- identifierar
- identifiera
- identifiera
- Identitet
- if
- bild
- bilder
- bild
- genomföra
- genomförande
- genomföras
- genomföra
- vikt
- med Esport
- förbättra
- förbättras
- förbättringar
- förbättra
- in
- innefattar
- index
- indexeras
- industrin
- informationen
- information utvinning
- inledande
- förnya
- innovationer
- ingång
- ingångar
- Inspiration
- inspirerar
- inspirerat
- installera
- exempel
- istället
- integrera
- Intelligent
- interagera
- inre
- in
- införa
- introducerade
- Invest
- Undersökningen
- investering
- engagera
- IT
- DESS
- sig
- Jobb
- resa
- jpg
- json
- Ha kvar
- Nyckel
- nycklar
- kunskap
- känd
- språk
- Large
- till stor del
- Efternamn
- senare
- senaste
- lanserar
- lager
- inlärning
- t minst
- Led
- Längd
- Nivå
- Hävstång
- tycka om
- BEGRÄNSA
- begränsningar
- LINK
- Lista
- LLM
- laster
- logistik
- logistikbranschen
- Lång
- älskar
- Maskinen
- maskininlärning
- gjord
- Huvudsida
- bibehålla
- upprätthålla
- göra
- förvaltade
- chef
- många
- Match
- matchande
- mogen
- Maj..
- me
- betyder
- åtgärder
- Möt
- nämner
- endast
- maska
- meddelande
- metadata
- metod
- metoder
- metriska
- Metrics
- minsta
- vilseledande
- saknas
- ML
- MLOps
- modell
- modeller
- måttfullhet
- Modern Konst
- Modulerna
- mer
- Dessutom
- mest
- multipel
- måste
- namn
- Natural
- Naturlig språkbehandling
- nödvändigt för
- Behöver
- behövs
- behov
- grannar
- netto
- nettointäkt
- aldrig
- Nya
- Nästa
- nlp
- Ingen
- anteckningsbok
- Begrepp
- objektet
- Objektdetektion
- of
- erbjuds
- erbjuda
- offline
- Ofta
- on
- ONE
- pågående
- endast
- öppet
- öppen källkod
- Verksamhet
- Optimera
- Tillbehör
- or
- beställa
- ursprungliga
- Övriga
- Övrigt
- vår
- ut
- utfall
- översikt
- skisse
- produktion
- utgångar
- över
- övergripande
- Övervinna
- egen
- paket
- pandor
- del
- reservdelar till din klassiker
- Mönster
- mönster
- Utföra
- prestanda
- tillstånd
- perspektiv
- Läkemedelsindustrin
- bitar
- rörledning
- Enkel
- planering
- plato
- Platon Data Intelligence
- PlatonData
- plausibel
- Punkt
- policy
- Populära
- popularitet
- befolkad
- möjlig
- eventuellt
- Inlägg
- PostgreSQL
- potentiell
- potentiellt
- drivs
- den mäktigaste
- praktiken
- Precision
- Förbered
- presentera
- presenteras
- presenterar
- konservering
- förhindra
- förhindrar
- tidigare
- privilegium
- problemlösning
- problem
- process
- bearbetning
- producerar
- producerande
- Produkt
- Produktion
- löfte
- lovande
- egenskaper
- föreslå
- föreslagen
- föreslår
- prototyping
- beprövade
- ge
- ger
- allmän
- Python
- Frågor och svar
- sökfrågor
- fråga
- frågor
- Snabbt
- snabbt
- Rankning
- snabb
- Raw
- nå
- kommit fram till
- Reagera
- Läsning
- redo
- verklig
- verkliga världen
- realtid
- Anledningen
- rimlig
- mottagna
- mottagande
- senaste
- nyligen
- känner igen
- rekommenderar
- Rekommendation
- minska
- hänvisa
- region
- relevanta
- tillförlitlighet
- förlita
- resterna
- Rapport
- Repository
- representerar
- begära
- kräver
- Obligatorisk
- krav
- Kräver
- forskning
- respons
- svar
- REST
- resultera
- Resultat
- avkastning
- intäkter
- intäkter
- översyn
- höger
- risker
- Roll
- regler
- Körning
- rinnande
- kör
- sagemaker
- Samma
- skalbarhet
- scanna
- scanning
- Forskare
- skript
- Sök
- sökmotor
- Andra
- §
- sektioner
- säkerhet
- Säkerhetsåtgärder
- se
- Seek
- sett
- väljer
- Val
- semantik
- sänder
- senior
- skickas
- Sekvens
- service
- Tjänster
- hon
- skall
- show
- visade
- visas
- liknande
- Enkelt
- förenklade
- förenkla
- samtidigt
- eftersom
- enda
- färdigheter
- So
- än så länge
- Mjukvara
- mjukvaruutveckling
- enbart
- lösning
- Lösningar
- Lösa
- några
- ibland
- Källa
- Källor
- Utrymme
- specialiserad
- specialiserat
- specifik
- fart
- Delar upp
- stapel
- stadier
- starta
- Starta
- styra
- Steg
- Steg
- lagra
- lagras
- okomplicerad
- strategier
- Strategi
- strejka
- strävar
- struktur
- strukturerade
- studio
- framgångsrik
- sådana
- föreslå
- lämplig
- sammanfatta
- leverera
- leveranskedjan
- stödja
- Stöder
- säker
- syntax
- system
- bord
- skräddarsydd
- Ta
- tar
- uppgift
- uppgifter
- tech
- tekniker
- teknisk
- Tekniken
- tala
- tio
- text
- text-
- Tack
- den där
- Smakämnen
- den information
- deras
- Dem
- sedan
- Där.
- vari
- därför
- Dessa
- de
- tror
- Tänkande
- detta
- de
- tre
- Genom
- tid
- titan
- till
- i dag
- verktyg
- verktyg
- topp
- topp 5
- mot
- mot
- Trace
- traditionell
- Utbildning
- Förvandla
- behandling
- sann
- trovärdig
- två
- Typ
- typer
- typiskt
- ui
- underliggande
- förstå
- tills
- uppdatering
- på
- us
- användning
- Begagnade
- Användare
- Användarupplevelse
- användare
- användningar
- med hjälp av
- BEKRÄFTA
- värde
- Värden
- mängd
- olika
- mångsidig
- Video
- Video
- sårbarheter
- promenader
- Sätt..
- we
- webb
- webbservice
- VÄL
- były
- Vad
- när
- medan
- om
- som
- medan
- varför
- wikipedia
- kommer
- med
- inom
- utan
- fungerar
- skulle
- skrivning
- X
- år
- år
- Om er
- Din
- zephyrnet