AI conversațional a parcurs un drum lung în ultimii ani, datorită dezvoltării rapide în IA generativă, în special îmbunătățirilor de performanță ale modelelor de limbaj mari (LLM) introduse prin tehnici de antrenament, cum ar fi reglarea fină a instrucțiunilor și învățarea de întărire din feedbackul uman. Când sunt solicitate corect, aceste modele pot purta conversații coerente fără date de antrenament specifice sarcinii. Cu toate acestea, ei nu pot generaliza bine la întrebările specifice întreprinderii, deoarece, pentru a genera un răspuns, se bazează pe datele publice la care au fost expuși în timpul pregătirii preliminare. Astfel de date le lipsesc adesea cunoștințele de specialitate conținute în documentele interne disponibile în afacerile moderne, care sunt de obicei necesare pentru a obține răspunsuri precise în domenii precum cercetarea farmaceutică, investigația financiară și asistența pentru clienți.
Pentru a crea asistenți AI care sunt capabili să aibă discuții bazate pe cunoștințele specializate ale întreprinderii, trebuie să conectăm aceste LLM-uri puternice, dar generice, la bazele de cunoștințe interne ale documentelor. Această metodă de îmbogățire a contextului de generare a LLM cu informații preluate din sursele interne de date se numește Retrieval Augmented Generation (RAG) și produce asistenți specifici domeniului și mai de încredere, după cum arată Generare de recuperare pentru sarcini NLP intensive. Un alt factor din spatele popularității RAG este ușurința sa de implementare și existența unor soluții mature de căutare vectorială, cum ar fi cele oferite de Amazon Kendra (A se vedea Amazon Kendra lansează Retrieval API) Şi Serviciul Amazon OpenSearch (A se vedea Căutare k-Nearest Neighbor (k-NN) în Amazon OpenSearch Service), printre alții.
Cu toate acestea, popularul model de design RAG cu căutare semantică nu poate răspunde la toate tipurile de întrebări care sunt posibile pe documente. Acest lucru este valabil mai ales pentru întrebările care necesită raționament analitic pe mai multe documente. De exemplu, imaginați-vă că planificați strategia de anul viitor a unei companii de investiții. Un pas esențial ar fi analizarea și compararea rezultatelor financiare și a riscurilor potențiale ale companiilor candidate. Această sarcină implică răspunsul la întrebări de raționament analitic. De exemplu, interogarea „Dă-mi primele 5 companii cu cele mai mari venituri din ultimii 2 ani și identifică-le principalele riscuri” necesită mai mulți pași de raționament, dintre care unii pot folosi căutarea semantică, în timp ce altele necesită capacități analitice.
În această postare, arătăm cum să proiectăm un asistent de documente inteligent capabil să răspundă la întrebări analitice și de raționament în mai mulți pași în trei părți. În partea 1, trecem în revistă modelul de proiectare RAG și limitările acestuia în ceea ce privește întrebările analitice. Apoi vă prezentăm o arhitectură mai versatilă care depășește aceste limitări. Partea 2 vă ajută să vă aprofundați în conducta de extracție a entităților folosită pentru a pregăti date structurate, care este un ingredient cheie pentru răspunsul la întrebări analitice. Partea 3 vă prezintă modul de utilizare Amazon Bedrock LLM-uri pentru a interoga acele date și a construi un agent LLM care îmbunătățește RAG cu capacități analitice, permițându-vă astfel să construiți asistenți inteligenți pentru documente care pot răspunde la întrebări complexe specifice domeniului în mai multe documente.
Partea 1: Limitări RAG și prezentare generală a soluției
În această secțiune, trecem în revistă modelul de proiectare RAG și discutăm limitările acestuia la întrebările analitice. De asemenea, prezentăm o arhitectură mai versatilă care depășește aceste limitări.
Prezentare generală a RAG
Soluțiile RAG sunt inspirate de învățarea reprezentării și căutare semantică idei care au fost adoptate treptat în probleme de clasare (de exemplu, recomandare și căutare) și sarcini de procesare a limbajului natural (NLP) începând cu 2010.
Abordarea populară folosită astăzi este formată din trei pași:
- O lucrare de procesare lot offline ingerează documente dintr-o bază de cunoștințe de intrare, le împarte în bucăți, creează o încorporare pentru fiecare bucată pentru a-și reprezenta semantica folosind un model de încorporare pre-antrenat, cum ar fi Amazon Titan modele de încorporare, apoi utilizează aceste înglobări ca intrare pentru a crea un index de căutare semantică.
- Când răspundeți la o întrebare nouă în timp real, întrebarea de intrare este convertită într-o încorporare, care este utilizată pentru a căuta și a extrage cele mai asemănătoare bucăți de documente folosind o metrică de similaritate, cum ar fi asemănarea cosinusului și un algoritm aproximativ de vecini cei mai apropiați. Precizia căutării poate fi îmbunătățită și prin filtrarea metadatelor.
- Un prompt este construit din concatenarea unui mesaj de sistem cu un context care este format din bucățile relevante de documente extrase în pasul 2 și întrebarea de intrare în sine. Acest prompt este apoi prezentat unui model LLM pentru a genera răspunsul final la întrebare din context.
Cu modelul de încorporare subiacent potrivit, capabil să producă reprezentări semantice precise ale fragmentelor de document de intrare și ale întrebărilor de intrare și un modul eficient de căutare semantică, această soluție este capabilă să răspundă la întrebări care necesită regăsirea informațiilor existente într-o bază de date de documente. De exemplu, dacă aveți un serviciu sau un produs, puteți începe prin a indexa secțiunea de întrebări frecvente sau documentația acestuia și puteți avea o IA conversațională inițială adaptată ofertei dvs. specifice.
Limitări ale RAG bazate pe căutare semantică
Deși RAG este o componentă esențială a asistenților AI moderni specifici domeniului și un punct de plecare rațional pentru construirea unei IA conversaționale în jurul unei baze de cunoștințe specializate, nu poate răspunde la întrebări care necesită scanare, comparare și raționament în toate documentele din baza de cunoștințe. simultan, mai ales când mărirea se bazează exclusiv pe căutare semantică.
Pentru a înțelege aceste limitări, să luăm din nou în considerare exemplul de decizie în care să investim pe baza rapoartelor financiare. Dacă ar fi să folosim RAG pentru a conversa cu aceste rapoarte, am putea pune întrebări precum „Care sunt riscurile cu care s-a confruntat compania X în 2022” sau „Care este venitul net al companiei Y în 2022?” Pentru fiecare dintre aceste întrebări, vectorul de încorporare corespunzător, care codifică semnificația semantică a întrebării, este utilizat pentru a regăsi cele mai sus-K bucăți similare din punct de vedere semantic de documente disponibile în indexul de căutare. Acest lucru se realizează de obicei prin folosirea unei soluții aproximative pentru cei mai apropiați vecini, cum ar fi FAISS, NMSLIB, pgvector sau altele, care se străduiesc să atingă un echilibru între viteza de recuperare și retragere pentru a obține performanțe în timp real, păstrând în același timp o precizie satisfăcătoare.
Cu toate acestea, abordarea anterioară nu poate răspunde cu exactitate la întrebările analitice din toate documentele, cum ar fi „Care sunt primele 5 companii cu cele mai mari venituri nete în 2022?”
Acest lucru se datorează faptului că regăsirea căutării semantice încearcă să găsească cele mai asemănătoare K bucăți de documente cu întrebarea de intrare. Dar, deoarece niciunul dintre documente nu conține rezumate cuprinzătoare ale veniturilor, va returna bucăți de documente care conțin doar mențiuni despre „venitul net” și eventual „2022”, fără a îndeplini condiția esențială de a se concentra pe companiile cu cele mai mari venituri. Dacă prezentăm aceste rezultate de regăsire unui LLM ca context pentru a răspunde la întrebarea de intrare, acesta poate formula un răspuns înșelător sau poate refuza să răspundă, deoarece lipsesc informațiile corecte necesare.
Aceste limitări vin prin proiectare, deoarece căutarea semantică nu efectuează o scanare completă a tuturor vectorilor de încorporare pentru a găsi documente relevante. În schimb, folosește metode aproximative ale celui mai apropiat vecin pentru a menține o viteză rezonabilă de recuperare. O strategie cheie pentru eficiență în aceste metode este segmentarea spațiului de încorporare în grupuri în timpul indexării. Acest lucru permite identificarea rapidă a grupurilor care pot conține înglobări relevante în timpul recuperării, fără a fi nevoie de comparații pe perechi. În plus, chiar și tehnicile tradiționale ale celor mai apropiati vecini, cum ar fi KNN, care scanează toate documentele, calculează doar valorile de bază ale distanței și nu sunt potrivite pentru comparațiile complexe necesare pentru raționamentul analitic. Prin urmare, RAG cu căutare semantică nu este adaptat pentru a răspunde la întrebări care implică raționament analitic în toate documentele.
Pentru a depăși aceste limitări, propunem o soluție care combină RAG cu extragerea de metadate și entități, interogare SQL și agenți LLM, așa cum este descris în secțiunile următoare.
Depășirea limitărilor RAG cu agenți metadate, SQL și LLM
Să examinăm mai profund o întrebare la care RAG eșuează, astfel încât să putem urmări raționamentul necesar pentru a răspunde eficient. Această analiză ar trebui să ne îndrepte către abordarea corectă care ar putea completa RAG în soluția generală.
Luați în considerare întrebarea: „Care sunt primele 5 companii cu cele mai mari venituri în 2022?”
Pentru a putea răspunde la această întrebare, ar trebui să:
- Identificați veniturile pentru fiecare companie.
- Filtrați în jos pentru a păstra veniturile din 2022 pentru fiecare dintre ele.
- Sortați veniturile în ordine descrescătoare.
- Împărțiți primele 5 venituri alături de numele companiilor.
De obicei, aceste operațiuni analitice sunt efectuate pe date structurate, folosind instrumente precum panda sau motoare SQL. Dacă am avea acces la un tabel SQL care conține coloanele company
, revenue
, și year
, am putea răspunde cu ușurință la întrebarea noastră rulând o interogare SQL, similar cu următorul exemplu:
SELECT company, revenue FROM table_name WHERE year = 2022 ORDER BY revenue DESC LIMIT 5;
Stocarea metadatelor structurate într-un tabel SQL care conține informații despre entitățile relevante vă permite să răspundeți la multe tipuri de întrebări analitice prin scrierea interogării SQL corecte. Acesta este motivul pentru care completăm RAG în soluția noastră cu un modul de interogare SQL în timp real împotriva unui tabel SQL, populat cu metadate extrase într-un proces offline.
Dar cum putem implementa și integra această abordare într-o IA conversațională bazată pe LLM?
Există trei pași pentru a putea adăuga raționament analitic SQL:
- Extragerea metadatelor – Extrageți metadatele din documente nestructurate într-un tabel SQL
- Text în SQL – Formulați cu precizie interogări SQL din întrebările introduse folosind un LLM
- Selectarea instrumentelor – Identificați dacă trebuie să răspundeți la o întrebare folosind RAG sau o interogare SQL
Pentru a implementa acești pași, recunoaștem mai întâi că extragerea informațiilor din documente nestructurate este o sarcină NLP tradițională pentru care LLM-urile arată promițătoare în obținerea unei acuratețe ridicate prin învățarea zero-shot sau puțin-shot. În al doilea rând, capacitatea acestor modele de a genera interogări SQL din limbaj natural a fost dovedită de ani de zile, așa cum se vede în Eliberare 2020 of Amazon QuickSight Q. În cele din urmă, selectarea automată a instrumentului potrivit pentru o anumită întrebare îmbunătățește experiența utilizatorului și permite răspunsul la întrebări complexe prin raționament în mai mulți pași. Pentru a implementa această caracteristică, vom analiza agenții LLM într-o secțiune ulterioară.
Pentru a rezuma, soluția pe care o propunem este compusă din următoarele componente de bază:
- Recuperarea căutării semantice pentru a spori contextul generației
- Extragerea și interogarea metadatelor structurate cu SQL
- Un agent capabil să folosească instrumentele potrivite pentru a răspunde la o întrebare
Prezentare generală a soluțiilor
Următoarea diagramă prezintă o arhitectură simplificată a soluției. Vă ajută să identificați și să înțelegeți rolul componentelor de bază și modul în care acestea interacționează pentru a implementa comportamentul complet al asistentului LLM. Numerotarea se aliniază cu ordinea operațiunilor la implementarea acestei soluții.
În practică, am implementat această soluție așa cum este subliniat în următoarea arhitectură detaliată.
Pentru această arhitectură, propunem o implementare pe GitHub, cu componente slab cuplate în care backend-ul (5), conductele de date (1, 2, 3) și front end (4) pot evolua separat. Aceasta este pentru a simplifica colaborarea între competențe atunci când personalizați și îmbunătățiți soluția pentru producție.
Implementați soluția
Pentru a instala această soluție în contul dvs. AWS, parcurgeți următorii pași:
- Clonați depozit pe GitHub.
- Instalați backend-ul Kit AWS Cloud Development (AWS CDK) aplicaţia:
- Deschideți
backend
dosar. - Alerga
npm install
pentru a instala dependențele. - Dacă nu ați folosit niciodată AWS CDK în contul curent și în regiune, rulați bootstrapping cu
npx cdk bootstrap
. - Alerga
npx cdk deploy
pentru a implementa stiva.
- Deschideți
- Opțional, rulați
streamlit-ui
după cum urmează:- Vă recomandăm să clonați acest depozit într-un Amazon SageMaker Studio mediu inconjurator. Pentru mai multe informații, consultați Accesați domeniul Amazon SageMaker folosind Configurare rapidă.
- În interiorul
frontend/streamlit-ui
folder, rulațibash run-streamlit-ui.sh
. - Alegeți linkul cu următorul format pentru a deschide demonstrația:
https://{domain_id}.studio.{region}.sagemaker.aws/jupyter/default/proxy/{port_number}/
.
- În cele din urmă, puteți rula Amazon SageMaker conductă definită în
data-pipelines/04-sagemaker-pipeline-for-documents-processing.ipynb
notebook pentru a procesa documentele PDF de intrare și a pregăti tabelul SQL și indexul de căutare semantică utilizat de asistentul LLM.
În restul acestei postări, ne concentrăm pe explicarea celor mai importante componente și alegeri de design, pentru a vă inspira, sperăm, atunci când vă proiectați propriul asistent AI pe o bază de cunoștințe internă. Presupunem că componentele 1 și 4 sunt ușor de înțeles și ne concentrăm pe componentele de bază 2, 3 și 5.
Partea 2: Conducta de extracție a entității
În această secțiune, ne aprofundăm în conducta de extracție a entităților folosită pentru a pregăti date structurate, care este un ingredient cheie pentru răspunsul la întrebări analitice.
Extragerea textului
Documentele sunt de obicei stocate în format PDF sau ca imagini scanate. Ele pot fi formate din scheme simple de paragraf sau tabele complexe și pot conține text digital sau scris de mână. Pentru a extrage informații corect, trebuie să transformăm aceste documente brute în text simplu, păstrând în același timp structura lor originală. Pentru a face acest lucru, puteți utiliza Text Amazon, care este un serviciu de învățare automată (ML) care oferă API-uri mature pentru extragerea de text, tabele și formulare din intrări digitale și scrise de mână.
În componenta 2, extragem text și tabele după cum urmează:
- Pentru fiecare document, apelăm Amazon Texttract pentru a extrage textul și tabelele.
- Folosim următoarele Script Python pentru a recrea tabele ca Pandas DataFrames.
- Consolidăm rezultatele într-un singur document și inserăm tabele ca reducere.
Acest proces este conturat de următoarea diagramă de flux și demonstrat în mod concret în notebooks/03-pdf-document-processing.ipynb
.
Extragerea și interogarea entităților folosind LLM-uri
Pentru a răspunde la întrebările analitice în mod eficient, trebuie să extrageți metadate și entități relevante din baza de cunoștințe a documentului dvs. într-un format de date structurate accesibil. Vă sugerăm să folosiți SQL pentru a stoca aceste informații și a prelua răspunsurile datorită popularității, ușurinței de utilizare și scalabilității. Această alegere beneficiază și de capacitatea modelelor de limbaj dovedite de a genera interogări SQL din limbaj natural.
În această secțiune, ne aprofundăm următoarele componente care permit întrebări analitice:
- Un proces lot care extrage date structurate din date nestructurate folosind LLM-uri
- Un modul în timp real care convertește întrebările din limbaj natural în interogări SQL și preia rezultatele dintr-o bază de date SQL
Puteți extrage metadatele relevante pentru a sprijini întrebările analitice, după cum urmează:
- Definiți o schemă JSON pentru informațiile pe care trebuie să le extrageți, care conține o descriere a fiecărui câmp și tipul său de date și include exemple de valori așteptate.
- Pentru fiecare document, solicitați un LLM cu schema JSON și solicitați-i să extragă datele relevante cu precizie.
- Când lungimea documentului depășește lungimea contextului și pentru a reduce costul de extracție cu LLM-uri, puteți utiliza căutarea semantică pentru a prelua și prezenta bucățile relevante de documente la LLM în timpul extracției.
- Analizați rezultatul JSON și validați extragerea LLM.
- Opțional, faceți copii de rezervă ale rezultatelor pe Amazon S3 ca fișiere CSV.
- Încărcați în baza de date SQL pentru interogări ulterioare.
Acest proces este gestionat de următoarea arhitectură, în care documentele în format text sunt încărcate cu un script Python care rulează într-un Procesare Amazon SageMaker sarcina de a efectua extractia.
Pentru fiecare grup de entități, construim în mod dinamic un prompt care include o descriere clară a sarcinii de extragere a informațiilor și include o schemă JSON care definește rezultatul așteptat și include fragmentele relevante de document ca context. Adăugăm, de asemenea, câteva exemple de intrare și de ieșire corectă pentru a îmbunătăți performanța extracției cu învățare cu câteva lovituri. Acest lucru este demonstrat în notebooks/05-entities-extraction-to-structured-metadata.ipynb
.
Partea 3: Creați un asistent de documente agentic cu Amazon Bedrock
În această secțiune, demonstrăm cum să utilizați Amazon Bedrock LLM-uri pentru a interoga date și a construi un agent LLM care îmbunătățește RAG cu capacități analitice, permițându-vă astfel să creați asistenți inteligenți pentru documente care pot răspunde la întrebări complexe specifice domeniului în mai multe documente. Vă puteți referi la Funcția Lambda pe GitHub pentru implementarea concretă a agentului și instrumentelor descrise în această parte.
Formulați interogări SQL și răspundeți la întrebări analitice
Acum că avem un depozit de metadate structurat cu entitățile relevante extrase și încărcate într-o bază de date SQL pe care o putem interoga, întrebarea care rămâne este cum să generăm interogarea SQL potrivită din întrebările de intrare în limbaj natural?
LLM-urile moderne sunt bune la generarea SQL. De exemplu, dacă solicitați de la Anthropic Claude LLM prin Amazon Bedrock pentru a genera o interogare SQL, veți vedea răspunsuri plauzibile. Cu toate acestea, trebuie să respectăm câteva reguli atunci când scriem promptul pentru a ajunge la interogări SQL mai precise. Aceste reguli sunt deosebit de importante pentru interogările complexe pentru a reduce halucinațiile și erorile de sintaxă:
- Descrieți sarcina cu acuratețe în cadrul promptului
- Includeți schema tabelelor SQL în prompt, descriind fiecare coloană a tabelului și specificând tipul acesteia de date
- Spuneți explicit LLM să folosească numai numele de coloane și tipurile de date existente
- Adăugați câteva rânduri din tabelele SQL
De asemenea, puteți postprocesa interogarea SQL generată folosind a Linter precum sqlfluff pentru a corecta formatarea sau un parser, cum ar fi sqlglot pentru a detecta erorile de sintaxă și a optimiza interogarea. Mai mult, atunci când performanța nu îndeplinește cerința, puteți oferi câteva exemple în cadrul promptului pentru a direcționa modelul cu învățare puține spre generarea de interogări SQL mai precise.
Din perspectiva implementării, folosim un AWS Lambdas funcția de a orchestra următorul proces:
- Apelați un model Anthropic Claude în Amazon Bedrock cu întrebarea de intrare pentru a obține interogarea SQL corespunzătoare. Aici, folosim SQLDatabase clasă de la LangChain pentru a adăuga descrieri de schemă ale tabelelor SQL relevante și pentru a utiliza un prompt personalizat.
- Analizați, validați și rulați interogarea SQL împotriva Ediție compatibilă cu Amazon Aurora PostgreSQL Bază de date.
Arhitectura acestei părți a soluției este evidențiată în diagrama următoare.
Considerații de securitate pentru a preveni atacurile cu injecție SQL
Pe măsură ce permitem asistentului AI să interogheze o bază de date SQL, trebuie să ne asigurăm că acest lucru nu introduce vulnerabilități de securitate. Pentru a realiza acest lucru, propunem următoarele măsuri de securitate pentru a preveni atacurile prin injecție SQL:
- Aplicați permisiunile IAM cu cel mai mic privilegiu – Limitați permisiunea funcției Lambda care rulează interogările SQL folosind un Gestionarea identității și accesului AWS (IAM) politica și rolul care urmează principiul cel mai mic privilegiu. În acest caz, acordăm acces numai în citire.
- Limitați accesul la date – Oferiți acces doar la minimumul de tabele și coloane pentru a preveni atacurile de divulgare a informațiilor.
- Adăugați un strat de moderare – Introduceți un strat de moderare care detectează din timp încercările prompte de injectare și împiedică propagarea acestora în restul sistemului. Poate lua forma unor filtre bazate pe reguli, potrivire a similitudinii cu o bază de date de exemple cunoscute de injecție promptă sau un clasificator ML.
Recuperarea căutării semantice pentru a spori contextul generației
Soluția pe care o propunem folosește RAG cu căutare semantică în componenta 3. Puteți implementa acest modul folosind baze de cunoștințe pentru Amazon Bedrock. În plus, există o varietate de alte opțiuni pentru implementarea RAG, cum ar fi API-ul Amazon Kendra Retrieval, Baza de date vectorială Amazon OpenSearch, și Amazon Aurora PostgreSQL cu pgvector, printre alții. Pachetul open source aws-genai-llm-chatbot demonstrează cum să utilizați multe dintre aceste opțiuni de căutare vectorială pentru a implementa un chatbot alimentat de LLM.
În această soluție, deoarece avem nevoie atât de interogare SQL, cât și de căutare vectorială, am decis să folosim Amazon Aurora PostgreSQL cu pgvector extensie, care acceptă ambele funcții. Prin urmare, implementăm componenta RAG de căutare semantică cu următoarea arhitectură.
Procesul de răspuns la întrebări folosind arhitectura precedentă se realizează în două etape principale.
Mai întâi, un proces offline în lot, rulat ca un job de procesare SageMaker, creează indexul de căutare semantică după cum urmează:
- Fie periodic, fie la primirea de noi documente, se execută o lucrare SageMaker.
- Încarcă documentele text din Amazon S3 și le împarte în bucăți suprapuse.
- Pentru fiecare bucată, folosește un model de încorporare Amazon Titan pentru a genera un vector de încorporare.
- Utilizează PGVector clasa de la LangChain pentru a ingera înglobările, cu bucățile de document și metadatele lor, în Amazon Aurora PostgreSQL și pentru a crea un index de căutare semantică pe toți vectorii de încorporare.
În al doilea rând, în timp real și pentru fiecare întrebare nouă, construim un răspuns după cum urmează:
- Întrebarea este primită de orchestratorul care rulează pe o funcție Lambda.
- Orchestratorul înglobează întrebarea cu același model de încorporare.
- Acesta preia cele mai relevante K fragmente de documente din indexul de căutare semantică PostgreSQL. Opțional, utilizează filtrarea metadatelor pentru a îmbunătăți precizia.
- Aceste bucăți sunt inserate dinamic într-un prompt LLM alături de întrebarea de intrare.
- Solicitarea este prezentată lui Anthropic Claude pe Amazon Bedrock, pentru a-l instrui să răspundă la întrebarea de intrare în funcție de contextul disponibil.
- În cele din urmă, răspunsul generat este trimis înapoi orchestratorului.
Un agent capabil să folosească instrumente pentru a raționa și a acționa
Până acum, în această postare, am discutat despre tratarea întrebărilor care necesită fie RAG, fie raționament analitic separat. Cu toate acestea, multe întrebări din lumea reală necesită ambele capacități, uneori în mai mulți pași de raționament, pentru a ajunge la un răspuns final. Pentru a susține aceste întrebări mai complexe, trebuie să introducem noțiunea de agent.
Agenți LLM, cum ar fi agenți pentru Amazon Bedrock, au apărut recent ca o soluție promițătoare capabilă să folosească LLM-urile pentru a raționa și adapta utilizând contextul actual și pentru a alege acțiuni adecvate dintr-o listă de opțiuni, care prezintă un cadru general de rezolvare a problemelor. După cum s-a discutat în Agenți autonomi LLM, există mai multe strategii de incitare și modele de proiectare pentru agenții LLM care sprijină raționamentul complex.
Un astfel de model de design este Reason and Act (ReAct), introdus în ReAct: Sinergizarea raționamentului și a acționării în modele de limbaj. În ReAct, agentul ia ca intrare un obiectiv care poate fi o întrebare, identifică informațiile care lipsesc pentru a-i răspunde și propune iterativ instrumentul potrivit pentru a culege informații pe baza descrierilor instrumentelor disponibile. După ce primește răspunsul de la un instrument dat, LLM reevaluează dacă are toate informațiile necesare pentru a răspunde pe deplin la întrebare. Dacă nu, face un alt pas de raționament și folosește același instrument sau un alt instrument pentru a aduna mai multe informații, până când un răspuns final este gata sau se atinge o limită.
Următoarea diagramă de secvență explică modul în care un agent ReAct lucrează pentru a răspunde la întrebarea „Dă-mi primele 5 companii cu cele mai mari venituri din ultimii 2 ani și identifică riscurile asociate cu cea mai mare.”
Detaliile implementării acestei abordări în Python sunt descrise în Agent LLM personalizat. În soluția noastră, agentul și instrumentele sunt implementate cu următoarea arhitectură parțială evidențiată.
Pentru a răspunde la o întrebare de intrare, folosim serviciile AWS după cum urmează:
- Un utilizator introduce întrebarea printr-o interfață de utilizare, care activează un API Gateway API Amazon.
- API Gateway trimite întrebarea unei funcții Lambda care implementează executorul agentului.
- Agentul apelează LLM cu un prompt care conține o descriere a instrumentelor disponibile, formatul instrucțiunii ReAct și întrebarea de intrare, apoi analizează următoarea acțiune de finalizat.
- Acțiunea conține ce instrument să apeleze și care este intrarea acțiunii.
- Dacă instrumentul de utilizat este SQL, executorul agentului apelează SQLQA pentru a converti întrebarea în SQL și a o rula. Apoi adaugă rezultatul la prompt și apelează din nou LLM pentru a vedea dacă poate răspunde la întrebarea inițială sau dacă sunt necesare mai multe acțiuni.
- În mod similar, dacă instrumentul de utilizat este căutarea semantică, atunci intrarea acțiunii este analizată și utilizată pentru a prelua din indexul de căutare semantică PostgreSQL. Acesta adaugă rezultatele la prompt și verifică dacă LLM este capabil să răspundă sau are nevoie de altă acțiune.
- După ce toate informațiile pentru a răspunde la o întrebare sunt disponibile, agentul LLM formulează un răspuns final și îl trimite înapoi utilizatorului.
Puteți extinde agentul cu instrumente suplimentare. În implementarea disponibilă pe GitHub, demonstrăm cum puteți adăuga un motor de căutare și un calculator ca instrumente suplimentare la motorul SQL și instrumentele de căutare semantică menționate mai sus. Pentru a stoca istoricul conversațiilor în curs, folosim un Amazon DynamoDB tabel.
Din experiența noastră de până acum, am văzut că următoarele sunt cheile unui agent de succes:
- Un LLM de bază capabil să raționeze cu formatul ReAct
- O descriere clară a instrumentelor disponibile, când să le folosiți și o descriere a argumentelor lor de intrare cu, eventual, un exemplu de intrare și rezultat așteptat
- O schiță clară a formatului ReAct pe care trebuie să-l urmeze LLM
- Instrumentele potrivite pentru rezolvarea problemei de afaceri puse la dispoziția agentului LLM pentru a le utiliza
- Analizarea corectă a rezultatelor din răspunsurile agentului LLM pe măsură ce motivează
Pentru a optimiza costurile, vă recomandăm păstrarea în cache a celor mai frecvente întrebări cu răspunsurile lor și actualizarea periodică a acestui cache pentru a reduce apelurile către LLM-ul de bază. De exemplu, puteți crea un index de căutare semantică cu cele mai frecvente întrebări, așa cum s-a explicat anterior, și puteți potrivi întrebarea noului utilizator cu indexul înainte de a apela LLM. Pentru a explora alte opțiuni de stocare în cache, consultați Integrari LLM Caching.
Suportă alte formate, cum ar fi fișiere video, imagine, audio și 3D
Puteți aplica aceeași soluție pentru diferite tipuri de informații, cum ar fi imagini, videoclipuri, audio și fișiere de design 3D, cum ar fi fișiere CAD sau rețea. Acest lucru implică utilizarea tehnicilor ML consacrate pentru a descrie conținutul fișierului în text, care poate fi apoi ingerat în soluția pe care am explorat-o mai devreme. Această abordare vă permite să conduceți conversații QA cu privire la aceste tipuri diverse de date. De exemplu, vă puteți extinde baza de date de documente creând descrieri textuale ale imaginilor, videoclipurilor sau conținutului audio. De asemenea, puteți îmbunătăți tabelul de metadate prin identificarea proprietăților prin clasificare sau detectarea obiectelor asupra elementelor din aceste formate. După ce aceste date extrase sunt indexate fie în depozitul de metadate, fie în indexul de căutare semantică pentru documente, arhitectura generală a sistemului propus rămâne în mare măsură consecventă.
Concluzie
În această postare, am arătat că utilizarea LLM-urilor cu modelul de proiectare RAG este necesară pentru construirea unui asistent AI specific domeniului, dar este insuficientă pentru a atinge nivelul necesar de fiabilitate pentru a genera valoare de afaceri. Din acest motiv, am propus extinderea modelului popular de proiectare RAG cu conceptele de agenți și instrumente, unde flexibilitatea instrumentelor ne permite să folosim atât tehnici tradiționale NLP, cât și capabilități LLM moderne pentru a permite un asistent AI cu mai multe opțiuni pentru a căuta informații și a asista. utilizatorilor în rezolvarea eficientă a problemelor de afaceri.
Soluția demonstrează procesul de proiectare către un asistent LLM capabil să răspundă la diferite tipuri de întrebări de recuperare, raționament analitic și raționament în mai mulți pași în toată baza de cunoștințe. De asemenea, am evidențiat importanța gândirii inverse față de tipurile de întrebări și sarcini cu care se așteaptă ca asistentul dvs. LLM să le ajute pe utilizatori. În acest caz, călătoria de proiectare ne-a condus la o arhitectură cu cele trei componente: căutare semantică, extragerea metadatelor și interogare SQL și agent și instrumente LLM, care considerăm că sunt destul de generice și flexibile pentru mai multe cazuri de utilizare. De asemenea, credem că, inspirându-vă din această soluție și scufundându-vă adânc în nevoile utilizatorilor dvs., veți putea extinde această soluție și mai mult către ceea ce funcționează cel mai bine pentru dvs.
Despre autori
Mohamed Ali Jamaoui este un arhitect senior de prototipare ML cu 10 ani de experiență în învățarea automată a producției. Îi place să rezolve problemele de afaceri cu învățarea automată și inginerie software și să îi ajute pe clienți să extragă valoare pentru afaceri cu ML. Ca parte a AWS EMEA Prototyping and Cloud Engineering, el îi ajută pe clienți să construiască soluții de afaceri care valorifică inovațiile în MLOP, NLP, CV și LLM.
Giuseppe Hannen este consultant asociat ProServe. Giuseppe își aplică abilitățile analitice în combinație cu AI&ML pentru a dezvolta soluții clare și eficiente pentru clienții săi. Îi place să vină cu soluții simple la probleme complicate, în special cele care implică cele mai recente dezvoltări tehnologice și cercetări.
Laurens ten Cate este Senior Data Scientist. Laurens lucrează cu clienții întreprinderi din EMEA, ajutându-i să-și accelereze rezultatele afacerii folosind tehnologiile AWS AI/ML. El este specializat în soluții NLP și se concentrează pe industria Lanțului de Aprovizionare și Logistică. În timpul liber îi place lectura și arta.
Irina Radu este manager de implicare pentru prototipuri, parte a AWS EMEA Prototyping and Cloud Engineering. Ea îi ajută pe clienți să obțină tot ce este mai bun din cea mai recentă tehnologie, să inoveze mai repede și să gândească mai mare.
- Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
- PlatoData.Network Vertical Generative Ai. Împuterniciți-vă. Accesați Aici.
- PlatoAiStream. Web3 Intelligence. Cunoștințe amplificate. Accesați Aici.
- PlatoESG. carbon, CleanTech, Energie, Mediu inconjurator, Solar, Managementul deșeurilor. Accesați Aici.
- PlatoHealth. Biotehnologie și Inteligență pentru studii clinice. Accesați Aici.
- Sursa: https://aws.amazon.com/blogs/machine-learning/boosting-rag-based-intelligent-document-assistants-using-entity-extraction-sql-querying-and-agents-with-amazon-bedrock/
- :are
- :este
- :nu
- :Unde
- $UP
- 1
- 10
- 100
- 2022
- 3d
- 7
- a
- capacitate
- Capabil
- Despre Noi
- accelera
- acces
- accesibil
- realizat
- Cont
- precizie
- precis
- precis
- Obține
- realizarea
- peste
- act
- actorie
- Acțiune
- acțiuni
- adapta
- adăuga
- În plus,
- Adaugă
- adoptată
- După
- din nou
- împotriva
- Agent
- agenţi
- AI
- Asistent AI
- AI / ML
- Algoritmul
- Se aliniază
- TOATE
- permite
- pe langa
- de asemenea
- Amazon
- Amazon SageMaker
- Text Amazon
- Amazon Web Services
- printre
- an
- analiză
- Analitic
- analiza
- și
- O alta
- răspunde
- răspunsuri
- Antropică
- Orice
- api
- API-uri
- se aplică
- Aplică
- abordare
- adecvat
- aproximativ
- arhitectură
- SUNT
- argumente
- în jurul
- Artă
- AS
- cere
- ajuta
- Asistent
- asistenți
- Avocat Colaborator
- asociate
- asuma
- At
- Atacuri
- Încercările
- audio
- spori
- augmented
- Auroră
- în mod automat
- autonom
- disponibil
- AWS
- înapoi
- Backend
- Sold
- de bază
- bazat
- de bază
- BE
- deoarece
- fost
- înainte
- comportament
- în spatele
- Crede
- Beneficiile
- CEL MAI BUN
- între
- Dincolo de
- mai mare
- stimularea
- atât
- construi
- Clădire
- afaceri
- întreprinderi
- dar
- by
- Cache
- CAD
- apel
- denumit
- apel
- apeluri
- CAN
- candidat
- capacități
- capabil
- transporta
- caz
- cazuri
- lanţ
- chatbot
- Verificări
- alegere
- alegeri
- Alege
- clasă
- clasificare
- clar
- Cloud
- COERENT
- colaborare
- Coloană
- Coloane
- combinaţie
- combină
- cum
- Comun
- Companii
- companie
- comparaţie
- compararea
- comparații
- Completa
- Completă
- complex
- complicat
- component
- componente
- compuse
- cuprinzător
- Calcula
- Concepte
- beton
- condiție
- Conduce
- Conectați
- Lua în considerare
- Considerații
- consistent
- consolida
- construi
- consultant
- conţine
- conținute
- conține
- conţinut
- context
- Conversație
- de conversaţie
- AI de conversație
- conversații
- converti
- convertit
- Nucleu
- corecta
- corect
- Corespunzător
- A costat
- Cheltuieli
- ar putea
- cuplat
- crea
- creează
- Crearea
- Curent
- personalizat
- client
- Relații Clienți
- clienţii care
- de date
- accesul la date
- om de știință de date
- Baza de date
- hotărât
- Decidând
- adânc
- Mai adânc
- definit
- defineste
- se îngropa
- Cerere
- Demo
- demonstra
- demonstrat
- demonstrează
- dependențe
- implementa
- descrie
- descris
- descriind
- descriere
- Amenajări
- modele de design
- proces de design
- proiect
- detaliat
- detalii
- detecta
- Detectare
- dezvolta
- Dezvoltare
- evoluții
- digital
- dezvăluire
- discuta
- discutat
- discuții
- distanţă
- scufunda
- diferit
- scufundare
- do
- document
- documentaţie
- documente
- face
- Nu
- domeniu
- domenii
- făcut
- jos
- şofer
- două
- în timpul
- dinamic
- fiecare
- Mai devreme
- Devreme
- uşura
- ușurință în utilizare
- cu ușurință
- Eficace
- în mod eficient
- eficiență
- eficient
- eficient
- oricare
- element
- Încorporarea
- EMEA
- a apărut
- angajarea
- permite
- permite
- permițând
- capăt
- angajament
- Motor
- Inginerie
- Motoare
- spori
- Îmbunătăţeşte
- suficient de
- îmbogățitor
- Afacere
- entități
- entitate
- Mediu inconjurator
- Erori
- mai ales
- esenţial
- stabilit
- Chiar
- evolua
- examina
- exemplu
- exemple
- existenţă
- existent
- Extinde
- de aşteptat
- experienţă
- a explicat
- explicând
- explică
- explora
- explorat
- expus
- extinde
- extindere
- extensie
- suplimentar
- extrage
- extracţie
- extracte
- cu care se confruntă
- eșuează
- FAQ
- departe
- mai repede
- Caracteristică
- DESCRIERE
- feedback-ul
- puțini
- camp
- Fișier
- Fişiere
- filtrare
- Filtre
- final
- În cele din urmă
- financiar
- Găsi
- First
- Flexibilitate
- flexibil
- debit
- Concentra
- concentrându-se
- următor
- urmează
- Pentru
- formă
- format
- format
- formulare
- Cadru
- Gratuit
- din
- faţă
- În față
- îndeplinirea
- Complet
- complet
- funcţie
- mai mult
- poartă
- aduna
- General
- genera
- generată
- generator
- generaţie
- generativ
- AI generativă
- obține
- obtinerea
- GitHub
- dat
- scop
- bine
- treptat
- acordarea
- grup
- Grupului
- HAD
- Avea
- având în
- he
- ajutor
- ajutor
- ajută
- aici
- Înalt
- cea mai mare
- Evidențiat
- lui
- istorie
- In speranta
- Cum
- Cum Pentru a
- Totuși
- HTML
- HTTPS
- uman
- idei
- identifică
- identifica
- identificarea
- Identitate
- if
- imagine
- imagini
- imagina
- punerea în aplicare a
- implementarea
- implementat
- Punere în aplicare a
- importanță
- important
- îmbunătăţi
- îmbunătățit
- îmbunătățiri
- îmbunătățirea
- in
- include
- index
- indexate
- industrie
- informații
- extragerea informațiilor
- inițială
- inova
- inovații
- intrare
- intrări
- Inspiraţie
- inspira
- inspirat
- instala
- instanță
- in schimb
- integra
- Inteligent
- interacţiona
- intern
- în
- introduce
- introdus
- Investi
- investigaţie
- investiţie
- implica
- IT
- ESTE
- în sine
- Loc de munca
- călătorie
- jpg
- JSON
- A pastra
- Cheie
- chei
- cunoştinţe
- cunoscut
- limbă
- mare
- în mare măsură
- Nume
- mai tarziu
- Ultimele
- lansează
- strat
- învăţare
- cel mai puțin
- Led
- Lungime
- Nivel
- Pârghie
- ca
- LIMITĂ
- limitări
- LINK
- Listă
- LLM
- loturile
- logistică
- industria logistică
- Lung
- iubeste
- maşină
- masina de învățare
- făcut
- Principal
- menține
- Mentine
- face
- gestionate
- manager
- multe
- Meci
- potrivire
- matur
- Mai..
- me
- sens
- măsuri
- Întâlni
- menționează
- pur și simplu
- ochiurilor de plasă
- mesaj
- Metadata
- metodă
- Metode
- metric
- Metrici
- minim
- derutant
- dispărut
- ML
- MLOps
- model
- Modele
- moderare
- Modern
- Module
- mai mult
- În plus
- cele mai multe
- multiplu
- trebuie sa
- nume
- Natural
- Procesarea limbajului natural
- necesar
- Nevoie
- necesar
- nevoilor
- vecini
- net
- venit net
- nu
- Nou
- următor
- nlp
- Nici unul
- caiet
- noțiune
- obiect
- Detectarea obiectelor
- of
- oferit
- oferind
- Offline
- de multe ori
- on
- ONE
- în curs de desfășurare
- afară
- deschide
- open-source
- Operațiuni
- Optimizați
- Opţiuni
- or
- comandă
- original
- Altele
- Altele
- al nostru
- afară
- rezultate
- schiță
- a subliniat
- producție
- iesiri
- peste
- global
- Învinge
- propriu
- pachet
- panda
- parte
- piese
- Model
- modele
- Efectua
- performanță
- permisiune
- perspectivă
- Farmaceutic
- piese
- conducte
- Simplu
- planificare
- Plato
- Informații despre date Platon
- PlatoData
- plauzibil
- Punct
- Politica
- Popular
- popularitate
- populat
- posibil
- eventual
- Post
- postgresql
- potenţial
- potenţial
- alimentat
- puternic
- practică
- Precizie
- Pregăti
- prezenta
- prezentat
- cadouri
- păstrarea
- împiedica
- previne
- în prealabil
- privilegiu
- de rezolvare a problemelor
- probleme
- proces
- prelucrare
- produce
- producând
- Produs
- producere
- promisiune
- promițător
- proprietăţi
- propune
- propus
- propune
- prototipuri
- dovedit
- furniza
- furnizează
- public
- Piton
- Q & A
- interogări
- întrebare
- Întrebări
- Rapid
- repede
- Clasat
- rapid
- Crud
- ajunge
- atins
- Reacţiona
- Citind
- gata
- real
- lumea reală
- în timp real
- motiv
- rezonabil
- primit
- primire
- recent
- recent
- recunoaște
- recomanda
- Recomandare
- reduce
- trimite
- regiune
- încredere
- se bazează
- rămășițe
- Rapoarte
- depozit
- reprezenta
- solicita
- necesita
- necesar
- cerință
- Necesită
- cercetare
- răspuns
- răspunsuri
- REST
- rezultat
- REZULTATE
- reveni
- venituri
- venituri
- revizuiască
- dreapta
- Riscurile
- Rol
- norme
- Alerga
- funcţionare
- ruleaza
- sagemaker
- acelaşi
- scalabilitate
- scanare
- scanare
- Om de stiinta
- scenariu
- Caută
- motor de cautare
- Al doilea
- Secțiune
- secțiuni
- securitate
- Măsuri de securitate
- vedea
- Căuta
- văzut
- selectarea
- selecţie
- semantică
- trimite
- senior
- trimis
- Secvenţă
- serviciu
- Servicii
- ea
- să
- Arăta
- a arătat
- indicat
- asemănător
- simplu
- simplificată
- simplifica
- simultan
- întrucât
- singur
- aptitudini
- So
- până acum
- Software
- Inginerie software
- Numai
- soluţie
- soluţii
- Rezolvarea
- unele
- uneori
- Sursă
- Surse
- Spaţiu
- de specialitate
- specializată
- specific
- viteză
- șpalturi
- stivui
- Stadiile
- Începe
- Pornire
- conduce
- Pas
- paşi
- stoca
- stocate
- simplu
- strategii
- Strategie
- grevă
- lupta
- structura
- structurat
- studio
- de succes
- astfel de
- sugera
- potrivit
- rezuma
- livra
- lanțului de aprovizionare
- a sustine
- Sprijină
- sigur
- sintaxă
- sistem
- tabel
- adaptate
- Lua
- ia
- Sarcină
- sarcini
- tech
- tehnici de
- tehnologic
- Tehnologii
- spune
- zece
- a) Sport and Nutrition Awareness Day in Manasia Around XNUMX people from the rural commune Manasia have participated in a sports and healthy nutrition oriented activity in one of the community’s sports ready yards. This activity was meant to gather, mainly, middle-aged people from a Romanian rural community and teach them about the benefits that sports have on both their mental and physical health and on how sporting activities can be used to bring people from a community closer together. Three trainers were made available for this event, so that the participants would get the best possible experience physically and so that they could have the best access possible to correct information and good sports/nutrition practices. b) Sports Awareness Day in Poiana Țapului A group of young participants have taken part in sporting activities meant to teach them about sporting conduct, fairplay, and safe physical activities. The day culminated with a football match.
- textual
- mulțumesc
- acea
- informațiile
- lor
- Lor
- apoi
- Acolo.
- astfel
- prin urmare
- Acestea
- ei
- crede
- Gândire
- acest
- aceste
- trei
- Prin
- timp
- gigant
- la
- astăzi
- instrument
- Unelte
- top
- top 5
- spre
- față de
- Urmă
- tradiţional
- Pregătire
- Transforma
- tratare
- adevărat
- demn de încredere
- Două
- tip
- Tipuri
- tipic
- ui
- care stau la baza
- înţelege
- până la
- actualizarea
- pe
- us
- utilizare
- utilizat
- Utilizator
- Experiența de utilizare
- utilizatorii
- utilizări
- folosind
- VALIDA
- valoare
- Valori
- varietate
- diverse
- multilateral
- Video
- Video
- Vulnerabilitățile
- plimbări
- Cale..
- we
- web
- servicii web
- BINE
- au fost
- Ce
- cand
- întrucât
- dacă
- care
- în timp ce
- de ce
- Wikipedia
- voi
- cu
- în
- fără
- fabrică
- ar
- scris
- X
- an
- ani
- Tu
- Ta
- zephyrnet