Dette indlæg er skrevet sammen med Stanislav Yeshchenko fra Q4 Inc.
Virksomheder henvender sig til Retrieval Augmented Generation (RAG) som en almindelig tilgang til at bygge Q&A chatbots. Vi ser fortsat nye udfordringer, der stammer fra arten af det udvalg af tilgængelige datasæt. Disse datasæt er ofte en blanding af numeriske og tekstdata, til tider strukturerede, ustrukturerede eller semistrukturerede.
Q4 Inc. behov for at løse nogle af disse udfordringer i en af deres mange AI use cases bygget på AWS. I dette indlæg diskuterer vi en Q&A bot use case, som Q4 har implementeret, de udfordringer, som numeriske og strukturerede datasæt præsenterede, og hvordan Q4 konkluderede, at brug af SQL kan være en levedygtig løsning. Til sidst ser vi nærmere på, hvordan Q4-holdet brugte Amazonas grundfjeld og SQLDatabaseChain til at implementere en RAG-baseret løsning med SQL-generering.
Brug case oversigt
Q4 Inc., med hovedkontor i Toronto, med kontorer i New York og London, er en førende platform for kapitalmarkedsadgang, der transformerer, hvordan udstedere, investorer og sælgere effektivt forbinder, kommunikerer og engagerer sig med hinanden. Q4 Platformen letter interaktioner på tværs af kapitalmarkederne gennem IR-websiteprodukter, virtuelle begivenhedsløsninger, engagementsanalyse, investor relations Customer Relationship Management (CRM), aktionær- og markedsanalyse, overvågning og ESG-værktøjer.
I nutidens hurtige og datadrevne finansielle landskab spiller Investor Relations Officers (IRO'er) en afgørende rolle i at fremme kommunikationen mellem en virksomhed og dens aktionærer, analytikere og investorer. Som en del af deres daglige opgaver analyserer IRO'er forskellige datasæt, herunder CRM, ejerskabsregistreringer og aktiemarkedsdata. Samlingen af disse data bruges til at generere finansielle rapporter, sætte mål for investorrelationer og styre kommunikationen med eksisterende og potentielle investorer.
For at imødekomme den voksende efterspørgsel efter effektiv og dynamisk datahentning havde Q4 til formål at skabe et chatbot Q&A-værktøj, der ville give en intuitiv og ligetil metode for IRO'er til at få adgang til den nødvendige information, de har brug for, i et brugervenligt format.
Slutmålet var at skabe en chatbot, der sømløst ville integrere offentligt tilgængelige data sammen med proprietære kundespecifikke Q4-data, samtidig med at det højeste niveau af sikkerhed og databeskyttelse bevares. Hvad angår ydeevne, var målet at opretholde en forespørgselssvartid på sekunder for at sikre en positiv oplevelse for slutbrugerne.
Finansielle markeder er en reguleret industri med høje indsatser involveret. Tilvejebringelse af ukorrekte eller forældede oplysninger kan påvirke investorernes og aktionærernes tillid ud over andre mulige databeskyttelsesrisici. For at forstå branchen og kravene, sætter Q4 databeskyttelse og svarnøjagtighed som sine vejledende principper i evalueringen af enhver løsning, før den kan bringes på markedet.
Som proof of concept besluttede Q4 at bruge et økonomisk ejerskabsdatasæt. Datasættet består af tidsseriedatapunkter, der repræsenterer antallet af ejede aktiver; transaktionshistorikken mellem investeringsinstitutioner, enkeltpersoner og offentlige virksomheder; og mange flere elementer.
Fordi Q4 ønskede at sikre, at det kunne opfylde alle de funktionelle og ikke-funktionelle krav, vi har diskuteret, skulle projektet også forblive kommercielt gennemførligt. Dette blev respekteret under hele processen med at beslutte om tilgang, arkitektur, valg af teknologi og løsningsspecifikke elementer.
Eksperimenter og udfordringer
Det var klart fra begyndelsen, at for at forstå et menneskeligt sprogspørgsmål og generere præcise svar, ville Q4 skulle bruge store sprogmodeller (LLM'er).
Følgende er nogle af de eksperimenter, der blev udført af teamet, sammen med de identificerede udfordringer og erfaringer:
- Fortræning – Q4 forstod kompleksiteten og udfordringerne, der følger med at fortræne en LLM ved hjælp af sit eget datasæt. Det blev hurtigt indlysende, at denne tilgang er ressourcekrævende med mange ikke-trivielle trin, såsom dataforbehandling, træning og evaluering. Ud over indsatsen ville det være uoverkommeligt. I betragtning af arten af tidsseriedatasættet indså Q4 også, at det løbende ville skulle udføre trinvis fortræning, efterhånden som nye data kom ind. Dette ville have krævet et dedikeret tværfagligt team med ekspertise inden for datavidenskab, maskinlæring og domæne viden.
- Finjustering – Finjustering af en præ-trænet fundamentmodel (FM) involverede brug af flere mærkede eksempler. Denne tilgang viste en vis indledende succes, men i mange tilfælde var modelhallucination en udfordring. Modellen kæmpede for at forstå nuancerede kontekstuelle signaler og returnerede forkerte resultater.
- RAG med semantisk søgning – Konventionel RAG med semantisk søgning var det sidste trin inden overgangen til SQL-generering. Holdet eksperimenterede med at bruge søgning, semantisk søgning og indlejringer til at udtrække kontekst. Under indlejringseksperimentet blev datasættet konverteret til indlejringer, gemt i en vektordatabase og derefter matchet med indlejringerne af spørgsmålet for at udtrække kontekst. Den hentede kontekst i et af de tre eksperimenter blev derefter brugt til at forstærke den oprindelige prompt som input til LLM. Denne tilgang fungerede godt for tekstbaseret indhold, hvor dataene består af naturligt sprog med ord, sætninger og afsnit. I betragtning af karakteren af Q4s datasæt, som for det meste er finansielle data bestående af tal, finansielle transaktioner, aktiekurser og datoer, var resultaterne i alle tre tilfælde suboptimale. Selv ved brug af indlejringer kæmpede de indlejringer, der blev genereret fra tal, med lighedsrangering og førte i mange tilfælde til at hente forkerte oplysninger.
Q4's konklusion: Generering af SQL er vejen frem
I betragtning af de udfordringer, man står over for ved brug af konventionel RAG-metode, begyndte teamet at overveje SQL-generering. Ideen var at bruge LLM til først at generere en SQL-sætning fra brugerspørgsmålet, præsenteret for LLM i naturligt sprog. Den genererede forespørgsel køres derefter mod databasen for at hente den relevante kontekst. Konteksten bruges endelig til at forstærke inputprompten til et opsummeringstrin.
Q4’s hypotese var, at for at få højere tilbagekaldelse for genfindingstrinnet, specifikt for det numeriske datasæt, skulle de først generere SQL fra brugerspørgsmålet. Dette mentes ikke kun at øge nøjagtigheden, men også holde konteksten inden for forretningsdomænet for et givet spørgsmål. Til generering af forespørgsler og for at generere nøjagtig SQL var Q4 nødt til at gøre LLM'en fuldt kontekstbevidst om deres datasætstruktur. Dette betød den nødvendige prompt for at inkludere databaseskemaet, et par eksempeldatarækker og menneskelæselige feltforklaringer for de felter, som ikke er lette at forstå.
Baseret på de indledende tests viste denne metode gode resultater. LLM udstyret med al den nødvendige information var i stand til at generere den korrekte SQL, som derefter blev kørt mod databasen for at hente den korrekte kontekst. Efter at have eksperimenteret med ideen besluttede Q4, at SQL-generering var vejen frem til at løse kontekstudtrækningsudfordringer for deres eget specifikke datasæt.
Lad os starte med at beskrive den overordnede løsningstilgang, opdele den til dens komponenter og derefter sætte brikkerne sammen.
Løsningsoversigt
LLM'er er store modeller med milliarder af parametre, der er fortrænede ved hjælp af meget store mængder data fra en række forskellige kilder. På grund af bredden af uddannelsesdatasættene forventes LLM'er at have generel viden inden for en række forskellige domæner. LLM'er er også kendt for deres ræsonnement evner, som varierer fra en model til en anden. Denne generelle adfærd kan optimeres til et specifikt domæne eller branche ved yderligere at optimere en fundamentmodel ved hjælp af yderligere domænespecifikke før-træningsdata eller ved at finjustere ved hjælp af mærkede data. Med den rigtige kontekst, metadata og instruktioner kan en velvalgt LLM til generelle formål producere SQL af god kvalitet, så længe den har adgang til den rigtige domænespecifikke kontekst.
I Q4’s use case starter vi med at oversætte kundespørgsmålet til SQL. Vi gør dette ved at kombinere brugerspørgsmålet, databaseskemaet, nogle eksempeldatabaserækker og detaljerede instruktioner som en prompt til LLM'en om at generere SQL. Når vi har SQL'en, kan vi køre et valideringstrin, hvis det skønnes nødvendigt. Når vi er tilfredse med kvaliteten af SQL'en, kører vi forespørgslen mod databasen for at hente den relevante kontekst, som vi har brug for til det følgende trin. Nu hvor vi har den relevante kontekst, kan vi sende brugerens originale spørgsmål, konteksten hentet og et sæt instruktioner tilbage til LLM for at producere et endeligt opsummeret svar. Målet med det sidste trin er at få LLM til at opsummere resultaterne og give et kontekstuelt og præcist svar, som derefter kan videregives til brugeren.
Valget af LLM, der bruges på alle trin af processen, har stor indflydelse på nøjagtigheden, omkostningerne og ydeevnen. At vælge en platform eller teknologi, der kan give dig fleksibiliteten til at skifte mellem LLM'er inden for samme use case (flere LLM-ture til forskellige opgaver), eller på tværs af forskellige use cases, kan være gavnligt til at optimere kvaliteten af output, latens og omkostninger . Vi behandler valget af LLM senere i dette indlæg.
Løsning byggeklodser
Nu hvor vi har fremhævet tilgangen på et højt niveau, lad os dykke ned i detaljerne, begyndende med løsningens byggesten.
Amazonas grundfjeld
Amazon Bedrock er en fuldt administreret tjeneste, der tilbyder et udvalg af højtydende FM'er fra førende virksomheder, herunder AI21 Labs, Anthropic, Cohere, Meta, Stability AI og Amazon. Amazon Bedrock tilbyder også et bredt sæt af værktøjer, der er nødvendige for at bygge generative AI-applikationer, forenkle udviklingsprocessen og opretholde privatliv og sikkerhed. Derudover kan du med Amazon Bedrock vælge mellem forskellige FM-muligheder, og du kan finjustere modellerne yderligere privat ved hjælp af dine egne data for at tilpasse modellernes svar med dine use case-krav. Amazon Bedrock er fuldstændig serverløs uden underliggende infrastruktur til at administrere udvidelse af adgang til tilgængelige modeller gennem en enkelt API. Endelig understøtter Amazon Bedrock adskillige sikkerheds- og privatlivskrav, herunder HIPAA-kvalificering og GDPR-overholdelse.
I Q4’s løsning bruger vi Amazon Bedrock som en serverløs, API-baseret, multi-fundament model byggesten. Fordi vi har til hensigt at foretage flere ture til LLM inden for samme use case, baseret på opgavetypen, kan vi vælge den model, der er mest optimal til en specifik opgave, det være sig SQL generering, validering eller opsummering.
Langkæde
Langkæde er en open source-integrations- og orkestreringsramme med et sæt præbyggede moduler (I/O, hentning, kæder og agenter), som du kan bruge til at integrere og orkestrere opgaver mellem FM'er, datakilder og værktøjer. Rammen letter opbygningen af generative AI-applikationer, der kræver orkestrering af flere trin for at producere det ønskede output uden at skulle skrive kode fra bunden. LangChain understøtter Amazon Bedrock som en multi-fundament model API.
Specifikt for Q4's use case, bruger vi LangChain til at koordinere og orkestrere opgaver i vores workflow, herunder tilslutning til datakilder og LLM'er. Denne tilgang har forenklet vores kode, fordi vi kan bruge de eksisterende LangChain-moduler.
SQLDatabaseChain
SQLDatabaseChain er en LangChain-kæde, der kan importeres fra langchain_experimental. SLDatabaseChain gør det nemt at oprette, implementere og køre SQL-forespørgsler ved hjælp af dens effektive tekst-til-SQL-konverteringer og implementeringer.
I vores use case bruger vi SQLDatabaseChain i SQL-genereringen, hvilket forenkler og orkestrerer interaktioner mellem databasen og LLM.
Datasættet
Vores strukturerede datasæt kan ligge i en SQL-database, datasø eller datavarehus, så længe vi har understøttelse af SQL. I vores løsning kan vi bruge enhver datasættype med SQL-understøttelse; dette bør abstraheres fra løsningen og bør ikke ændre løsningen på nogen måde.
Implementeringsdetaljer
Nu hvor vi har udforsket løsningstilgangen, løsningskomponenterne, valget af teknologi og værktøjer, kan vi sætte brikkerne sammen. Følgende diagram fremhæver end-to-end-løsningen.
Lad os gennemgå implementeringsdetaljerne og procesflowet.
Generer SQL-forespørgslen
For at forenkle kodning bruger vi eksisterende rammer. Vi bruger LangChain som en orkestreringsramme. Vi starter med input-fasen, hvor vi modtager brugerspørgsmålet i naturligt sprog.
I dette første trin tager vi dette input og genererer en tilsvarende SQL, som vi kan køre mod databasen til kontekstudtrækning. Til at generere SQL bruger vi SQLDatabaseChain, som er afhængig af Amazon Bedrock for at få adgang til vores ønskede LLM. Med Amazon Bedrock, ved hjælp af en enkelt API, får vi adgang til en række underliggende LLM'er og kan vælge den rigtige for hver LLM-rejse, vi foretager. Vi etablerer først en forbindelse til databasen og henter det påkrævede tabelskema sammen med nogle eksempelrækker fra de tabeller, vi agter at bruge.
I vores test fandt vi, at 2-5 rækker tabeldata var tilstrækkelige til at give nok information til modellen uden at tilføje for meget unødvendig overhead. Tre rækker var lige nok til at give kontekst, uden at overvælde modellen med for meget input. I vores use case startede vi med Anthropic Claude V2. Modellen er kendt for sine avancerede ræsonnementer og artikulere kontekstuelle svar, når den er forsynet med den rigtige kontekst og instruktioner. Som en del af instruktionerne kan vi inkludere flere afklarende detaljer til LLM. For eksempel kan vi beskrive den kolonne Comp_NAME
står for firmanavnet. Vi kan nu konstruere prompten ved at kombinere brugerspørgsmålet, som det er, databaseskemaet, tre eksempelrækker fra tabellen, vi har til hensigt at bruge, og et sæt instruktioner til at generere den nødvendige SQL i rent SQL-format uden kommentarer eller tilføjelser.
Alle input-elementer kombineret betragtes som modelinput-prompten. En velkonstrueret inputprompt, der er skræddersyet til modellens foretrukne syntaks, har stor indflydelse på både kvaliteten og ydeevnen af outputtet. Valget af model, der skal bruges til en specifik opgave, er også vigtigt, ikke kun fordi det påvirker outputkvaliteten, men også fordi det har konsekvenser for omkostninger og ydeevne.
Vi diskuterer modelvalg og hurtig konstruktion og optimering senere i dette indlæg, men det er værd at bemærke, at vi i forbindelse med forespørgselsgenereringsfasen bemærkede, at Claude Instant var i stand til at producere sammenlignelige resultater, især når brugerspørgsmålet er godt formuleret og ikke så sofistikeret. Claude V2 producerede dog bedre resultater selv med mere komplekse og indirekte brugerinput. Vi lærte, at selvom i nogle tilfælde Claude Instant kan give tilstrækkelig nøjagtighed til en bedre ventetid og pris, var vores case for generering af forespørgsler bedre egnet til Claude V2.
Bekræft SQL-forespørgslen
Vores næste trin er at verificere, at LLM har genereret den rigtige forespørgselssyntaks, og at forespørgslen giver kontekstuel mening i betragtning af databaseskemaerne og de angivne eksempelrækker. Til dette verifikationstrin kan vi vende tilbage til native forespørgselsvalidering inden for SQLDatabaseChain, eller vi kan køre en anden tur til LLM, inklusive forespørgslen genereret sammen med valideringsinstruktion.
Hvis vi bruger en LLM til valideringstrinnet, kan vi bruge den samme LLM som før (Claude V2) eller en mindre, mere performant LLM til en enklere opgave, såsom Claude Instant. Fordi vi bruger Amazon Bedrock, burde dette være en meget enkel justering. Ved hjælp af samme API kan vi ændre modelnavnet i vores API-kald, som tager sig af ændringen. Det er vigtigt at bemærke, at i de fleste tilfælde kan en mindre LLM give bedre effektivitet i både omkostninger og latenstid og bør overvejes - så længe du får den ønskede nøjagtighed. I vores tilfælde viste testning, at den genererede forespørgsel var konsekvent nøjagtig og med den rigtige syntaks. Da vi vidste det, var vi i stand til at springe dette valideringstrin over og spare på latenstid og omkostninger.
Kør SQL-forespørgslen
Nu hvor vi har den verificerede SQL-forespørgsel, kan vi køre SQL-forespørgslen mod databasen og hente den relevante kontekst. Dette burde være et ligetil skridt.
Vi tager den genererede kontekst, giver den til den LLM efter eget valg med det indledende brugerspørgsmål og nogle instruktioner og beder modellen om at generere et kontekstuelt og artikuleret resumé. Vi præsenterer derefter det genererede resumé for brugeren som et svar på det indledende spørgsmål, alt i overensstemmelse med konteksten udtrukket fra vores datasæt.
For den LLM, der er involveret i opsummeringstrinnet, kan vi bruge enten Titan Text Express eller Claude Instant. De ville begge præsentere gode muligheder for opsummeringsopgaven.
Applikationsintegration
Q&A chatbot-kapaciteten er en af Q4s AI-tjenester. For at sikre modularitet og skalerbarhed bygger Q4 AI-tjenester som mikrotjenester, der er tilgængelige for Q4-applikationer gennem API'er. Denne API-baserede tilgang muliggør problemfri integration med Q4-platformens økosystem og gør det lettere at eksponere AI-tjenesternes muligheder for hele suiten af platformsapplikationer.
Hovedformålet med AI-tjenesterne er at give ligetil muligheder for at hente data fra enhver offentlig eller proprietær datakilde ved hjælp af naturligt sprog som input. Derudover giver AI-tjenesterne yderligere abstraktionslag for at sikre, at funktionelle og ikke-funktionelle krav, såsom databeskyttelse og sikkerhed, er opfyldt. Følgende diagram viser integrationskonceptet.
Implementeringsudfordringer
Ud over de udfordringer, som karakteren af det strukturerede, numeriske datasæt, som vi diskuterede tidligere, præsenterede, stod Q4 over for en række andre implementeringsudfordringer, som skulle løses.
LLM valg og ydeevne
At vælge den rigtige LLM til opgaven er afgørende, fordi det direkte påvirker kvaliteten af output såvel som ydeevnen (retur-forsinkelse). Her er nogle faktorer, der spiller ind i LLM-udvælgelsesprocessen:
- Type LLM – Den måde, FM'erne er opbygget på, og de indledende data, modellen er blevet fortrænet på, bestemmer, hvilke typer opgaver LLM ville være god til, og hvor god den vil være. For eksempel ville en tekst LLM være god til tekstgenerering og opsummering, hvorimod en tekst-til-billede eller billede-til-tekst-model ville være mere gearet til billedanalyse og genereringsopgaver.
- LLM størrelse – FM-størrelser måles ved antallet af modelparametre, en bestemt model har, typisk i milliarder for moderne LLM'er. Typisk er det sådan, at jo større modellen er, desto dyrere er det i første omgang at træne eller efterfølgende finjustere. På den anden side, generelt, for den samme modelarkitektur, jo større modellen er, jo smartere forventer vi, at den er til at udføre den type opgave, den er gearet til.
- LLM ydeevne – Jo større modellen er, jo mere tid tager det typisk at generere output, forudsat at du bruger de samme beregnings- og I/O-parametre (prompt og outputstørrelse). For den samme modelstørrelse er ydeevnen desuden stærkt påvirket af, hvor optimeret din prompt er, størrelsen på I/O-tokens og promptens klarhed og syntaks. En velkonstrueret prompt sammen med en optimeret I/O-tokenstørrelse kan forbedre modellens responstid.
Når du optimerer din opgave, skal du derfor overveje følgende bedste praksis:
- Vælg en model, der passer til opgaven
- Vælg den mindste modelstørrelse, der kan give den nøjagtighed, du leder efter
- Optimer din promptstruktur og vær så specifik som muligt med instruktionerne på en måde, der er let at forstå for modellen
- Brug den mindste inputprompt, der kan give tilstrækkelig instruktion og kontekst til at producere det nøjagtighedsniveau, du leder efter
- Begræns outputstørrelsen til den mindste størrelse, der kan være meningsfuld for dig og tilfredsstille dine outputkrav
Under hensyntagen til modelvalg og ydeevneoptimeringsfaktorer gik vi i gang med at optimere vores SQL-genereringsbrug. Efter nogle tests bemærkede vi, at forudsat at vi har den rigtige kontekst og instruktioner, ville Claude Instant, med de samme prompte data, producere sammenlignelig kvalitet af SQL som Claude V2 til en meget bedre ydeevne og pris. Dette gælder, når brugerinput er mere direkte og enklere. For mere sofistikeret input var Claude V2 nødvendig for at producere den ønskede nøjagtighed.
Anvendelse af den samme logik på opsummeringsopgaven fik os til at konkludere, at brug af Claude Instant eller Titan Text Express ville give den nøjagtighed, der kræves på et meget bedre præstationspunkt, end hvis vi bruger en større model som Claude V2. Titan Text Expressed tilbød også bedre pris-ydelse, som vi diskuterede tidligere.
Orkestreringsudfordringen
Vi indså, at der er meget at orkestrere, før vi kan få et meningsfuldt outputsvar til brugerspørgsmålet. Som vist i løsningsoversigten involverede processen flere databaserejser og flere LLM-ture, der er flettet sammen. Hvis vi skulle bygge fra bunden, skulle vi have foretaget en betydelig investering i de udifferentierede tunge løft bare for at få basiskoden klar. Vi gik hurtigt over til at bruge LangChain som en orkestreringsramme, udnyttede kraften i open source-fællesskabet og genbruge eksisterende moduler uden at genopfinde hjulet.
SQL-udfordringen
Vi indså også, at generering af SQL ikke er så simpelt som kontekstudtrækningsmekanismer som semantisk søgning eller brug af indlejringer. Vi skal først få databaseskemaet og et par eksempelrækker til at inkludere i vores prompt til LLM. Der er også SQL-valideringsstadiet, hvor vi skulle interagere med både databasen og LLM. SQLDatabaseChain var det oplagte valg af værktøj. Fordi det er en del af LangChain, var det ligetil at tilpasse, og nu kan vi administrere SQL-generering og verifikation assisteret med kæden, hvilket minimerer den mængde arbejde, vi skulle udføre.
Performance udfordringer
Med brugen af Claude V2 og efter ordentlig prompt engineering (som vi diskuterer i næste afsnit), var vi i stand til at producere SQL af høj kvalitet. I betragtning af kvaliteten af den genererede SQL begyndte vi at se på, hvor meget værdi valideringsfasen faktisk tilføjer. Efter yderligere analyse af resultaterne blev det klart, at kvaliteten af den genererede SQL konsekvent var nøjagtig på en måde, der gjorde omkostningerne/fordele ved at tilføje et SQL-valideringstrin ugunstige. Vi endte med at eliminere SQL-valideringsstadiet uden at påvirke kvaliteten af vores output negativt og barberede SQL-valideringstiden rundt.
Ud over at optimere for en mere omkostnings- og ydeevneeffektiv LLM til opsummeringstrinnet, var vi i stand til at bruge Titan Text Express til at få bedre ydeevne og omkostningseffektivitet.
Yderligere ydeevneoptimering involverede finjustering af forespørgselsgenereringsprocessen ved hjælp af effektive hurtige ingeniørteknikker. I stedet for at give en overflod af tokens, var fokus på at levere den mindste mængde input-tokens, i den rigtige syntaks, som modellen er trænet til at forstå, og med det minimale, men optimale sæt instruktioner. Vi diskuterer dette mere i næste afsnit - det er et vigtigt emne, der ikke kun er relevant her, men også i andre brugssager.
Hurtig konstruktion og optimering
Du kan justere Claude på Amazon Bedrock til forskellige tilfælde af forretningsbrug, hvis de rigtige hurtige ingeniørteknikker anvendes. Claude fungerer hovedsageligt som en samtaleassistent, der bruger et menneske/assistent-format. Claude er uddannet til at udfylde tekst til assistentrollen. Med de ønskede instruktioner og prompte afslutninger kan vi optimere vores prompter for Claude ved hjælp af flere teknikker.
Vi starter med en korrekt formateret promptskabelon, der giver en gyldig afslutning, og derefter kan vi optimere svarene yderligere ved at eksperimentere med prompter med forskellige sæt input, der er repræsentative for data fra den virkelige verden. Det anbefales at få mange input, mens du udvikler en hurtig skabelon. Du kan også bruge separate sæt af prompte udviklingsdata og testdata.
En anden måde at optimere Claude-svaret på er at eksperimentere og iterere ved at tilføje regler, instruktioner og nyttige optimeringer. Fra disse optimeringer kan du se forskellige typer af færdiggørelser ved for eksempel at bede Claude om at nævne "Jeg ved det ikke" for at forhindre hallucinationer, tænke trin for trin, bruge prompt kæde, give plads til at "tænke", mens det genererer svar , og dobbelttjek for forståelse og nøjagtighed.
Lad os bruge vores forespørgselsgenereringsopgave og diskutere nogle af de teknikker, vi brugte til at optimere vores prompt. Der var et par kerneelementer, som gavnede vores indsats for generering af forespørgsler:
- Brug af den korrekte menneske/assistent-syntaks
- Brug af XML-tags (Claude respekterer og forstår XML-tags)
- Tilføjelse af klare instruktioner til modellen for at forhindre hallucinationer
Det følgende generiske eksempel viser, hvordan vi brugte menneske-/assistentsyntaksen, anvendte XML-tags og tilføjede instruktioner for at begrænse outputtet til SQL og instruere modellen til at sige "undskyld, jeg kan ikke hjælpe", hvis den ikke kan producere relevant SQL . XML-mærkerne blev brugt til at indramme instruktionerne, yderligere tip, databaseskema, yderligere tabelforklaringer og eksempelrækker.
Den endelige arbejdsløsning
Efter at vi havde løst alle de udfordringer, der blev identificeret under proof of concept, havde vi opfyldt alle løsningskravene. Q4 var tilfreds med kvaliteten af SQL genereret af LLM. Dette gælder for simple opgaver, der kun krævede en WHERE-klausul for at filtrere dataene, og også med mere komplekse opgaver, der krævede kontekstbaserede aggregeringer med GROUP BY og matematiske funktioner. End-to-end latens for den overordnede løsning kom inden for det, der blev defineret som acceptabelt for brugssagen - enkeltcifrede sekunder. Dette var alt sammen takket være valget af en optimal LLM på alle trin, korrekt prompt engineering, eliminering af SQL-verifikationstrinnet og brug af en effektiv LLM til opsummeringstrinnet (Titan Text Express eller Claude Instant).
Det er værd at bemærke, at brugen af Amazon Bedrock som en fuldt administreret tjeneste og muligheden for at få adgang til en suite af LLM'er gennem den samme API tillod eksperimentering og problemfri skift mellem LLM'er ved at ændre modelnavnet i API-kaldet. Med dette fleksibilitetsniveau var Q4 i stand til at vælge den mest effektive LLM for hvert LLM-opkald baseret på opgavens art, det være sig generering af forespørgsler, verifikation eller opsummering.
Konklusion
Der er ikke én løsning, der passer til alle use cases. I en RAG-tilgang afhænger kvaliteten af output i høj grad af at give den rigtige kontekst. Det er nøglen at udtrække den rigtige kontekst, og hvert datasæt er forskelligt med dets unikke egenskaber.
I dette indlæg demonstrerede vi, at for numeriske og strukturerede datasæt kan brug af SQL til at udtrække konteksten, der bruges til augmentation, føre til mere gunstige resultater. Vi demonstrerede også, at rammer som LangChain kan minimere kodningsindsatsen. Derudover diskuterede vi behovet for at kunne skifte mellem LLM'er inden for samme use case for at opnå den mest optimale nøjagtighed, ydeevne og omkostninger. Til sidst fremhævede vi, hvordan Amazon Bedrock, der er serverløs og med en række LLM'er under motorhjelmen, giver den nødvendige fleksibilitet til at bygge sikre, effektive og omkostningsoptimerede applikationer med den mindste mængde tunge løft.
Start din rejse mod at bygge generative AI-aktiverede applikationer ved at identificere et use case af værdi for din virksomhed. SQL-generering, som Q4-teamet lærte, kan være en game changer i at bygge smarte applikationer, der integreres med dine datalagre, hvilket frigør indtjeningspotentiale.
Om forfatterne
Tamer Soliman er Senior Solutions Architect hos AWS. Han hjælper kunder med Independent Software Vendor (ISV) med at innovere, bygge og skalere på AWS. Han har over to årtiers brancheerfaring inden for rådgivning, træning og professionel service. Han er en multipatentopfinder med tre tildelte patenter, og hans erfaring spænder over flere teknologidomæner, herunder telekommunikation, netværk, applikationsintegration, AI/ML og cloud-implementeringer. Han har specialiseret sig i AWS-netværk og har en dyb passion for machine leaning, AI og Generativ AI.
Mani Khanuja er en Tech Lead – Generative AI Specialists, forfatter til bogen – Applied Machine Learning and High Performance Computing på AWS, og medlem af bestyrelsen for Women in Manufacturing Education Foundation Board. Hun leder maskinlæringsprojekter (ML) inden for forskellige domæner såsom computervision, naturlig sprogbehandling og generativ AI. Hun hjælper kunder med at bygge, træne og implementere store maskinlæringsmodeller i stor skala. Hun taler i interne og eksterne konferencer såsom re:Invent, Women in Manufacturing West, YouTube-webinarer og GHC 23. I sin fritid kan hun godt lide at gå lange løbeture langs stranden.
Stanislav Yeshchenko er softwarearkitekt hos Q4 Inc.. Han har over ti års brancheerfaring inden for softwareudvikling og systemarkitektur. Hans forskelligartede baggrund, der spænder over roller som Technical Lead og Senior Full Stack Developer, driver hans bidrag til at fremme innovation af Q4-platformen. Stanislav er dedikeret til at drive teknisk innovation og forme strategiske løsninger på området.
- 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/how-q4-inc-used-amazon-bedrock-rag-and-sqldatabasechain-to-address-numerical-and-structured-dataset-challenges-building-their-qa-chatbot/
- :har
- :er
- :ikke
- :hvor
- $OP
- 100
- 118
- 125
- 15 %
- 23
- 7
- a
- evner
- evne
- I stand
- abstraktion
- overflod
- acceptabel
- adgang
- tilgængelig
- Konto
- nøjagtighed
- præcis
- opnå
- tværs
- handlinger
- faktisk
- tilpasse
- tilføjet
- tilføje
- Desuden
- Yderligere
- Derudover
- tilføjelser
- adresse
- rettet
- Justering
- fremskreden
- fremrykkende
- Fordel
- Efter
- mod
- midler
- aggregat
- AI
- AI-tjenester
- ai use cases
- AI / ML
- Rettet
- tilpasse
- justeret
- Alle
- tillade
- tilladt
- sammen
- også
- Skønt
- am
- Amazon
- Amazon Web Services
- beløb
- beløb
- an
- analyse
- Analytikere
- analytics
- analysere
- analysere
- ,
- En anden
- besvare
- svar
- Antropisk
- enhver
- noget
- api
- API'er
- anvendelig
- Anvendelse
- applikationer
- anvendt
- tilgang
- arkitektur
- ER
- AS
- spørg
- Aktiver
- Assistant
- bistået
- sortiment
- At
- forøge
- augmented
- forfatter
- til rådighed
- opmærksom på
- AWS
- tilbage
- baggrund
- baseret
- grundlæggende
- BE
- Beach
- blev
- fordi
- været
- før
- Begyndelse
- adfærd
- være
- troede
- gavnlig
- BEDSTE
- bedste praksis
- Bedre
- mellem
- milliarder
- Bloker
- Blocks
- board
- bestyrelse
- bog
- Bot
- både
- bredde
- Pause
- bred
- bygge
- Bygning
- bygger
- bygget
- virksomhed
- men
- by
- ringe
- kom
- CAN
- Kan få
- kapaciteter
- kapacitet
- kapital
- Kapitalmarkeder
- hvilken
- tilfælde
- tilfælde
- kæde
- kæder
- udfordre
- udfordringer
- udfordrer bygningen
- lave om
- Changer
- skiftende
- karakteristika
- chatbot
- chatbots
- valg
- Vælg
- vælge
- klarhed
- ren
- klar
- tættere
- Cloud
- kode
- Kodning
- Kolonne
- kombineret
- kombinerer
- Kom
- kommentarer
- kommercielt
- kommunikere
- Kommunikation
- samfund
- Virksomheder
- selskab
- sammenlignelig
- færdiggørelse
- komplekse
- kompleksitet
- Compliance
- komponenter
- forstå
- Compute
- computer
- Computer Vision
- computing
- Konceptet
- konkluderer
- indgået
- konklusion
- gennemført
- konferencer
- Tilslut
- Tilslutning
- tilslutning
- Overvej
- betragtes
- Overvejer
- konsekvent
- Bestående
- består
- konstruere
- rådgivning
- indhold
- sammenhæng
- kontekstuelle
- fortsæt
- kontinuerligt
- bidrag
- konventionelle
- konversation
- konverteringer
- konverteret
- koordinerende
- Core
- korrigere
- Koste
- kunne
- skabe
- kritisk
- CRM
- afgørende
- kunde
- Kunder
- dagligt
- data
- Data Lake
- datapunkter
- databeskyttelse
- Databeskyttelse og sikkerhed
- datalogi
- datastyret
- Database
- datasæt
- Datoer
- årti
- årtier
- besluttede
- Beslutter
- dedikeret
- anses
- definerede
- Efterspørgsel
- demonstreret
- demonstrerer
- afhænger
- indsætte
- implementeringer
- beskrive
- beskriver
- ønskes
- detaljeret
- detaljer
- bestemmer
- Udvikler
- udvikling
- Udvikling
- forskellige
- direkte
- direkte
- direktører
- diskutere
- drøftet
- dyk
- forskelligartede
- do
- domæne
- Domæner
- Dont
- dobbelttjek
- ned
- kørsel
- grund
- i løbet af
- dynamisk
- hver
- tidligere
- let
- økosystem
- Uddannelse
- Effektiv
- effektivitet
- effektiv
- effektivt
- indsats
- indsats
- enten
- elementer
- berettigelse
- eliminere
- smergel
- selvstændige
- muliggør
- ende
- ende til ende
- sluttede
- engagere
- engagement
- Engineering
- nok
- sikre
- udstyret
- Ækvivalent
- ESG
- især
- etablere
- evaluere
- evaluering
- Endog
- begivenheder
- Hver
- eksempel
- eksempler
- eksisterende
- forvente
- forventet
- dyrt
- erfaring
- eksperiment
- eksperimenter
- ekspert
- ekspertise
- udforsket
- Express
- udtrykt
- strækker
- ekstern
- ekstrakt
- udvinding
- konfronteret
- letter
- faktorer
- hurtig
- gunstig
- gennemførlig
- få
- felt
- Fields
- udfylde
- filtrere
- endelige
- Endelig
- finansielle
- finansielle data
- Fornavn
- Fleksibilitet
- flow
- Fokus
- følger
- efter
- Til
- format
- Videresend
- fremme
- fundet
- Foundation
- FRAME
- Framework
- rammer
- Gratis
- fra
- fuld
- Fuld stak
- fuldt ud
- funktionel
- funktioner
- yderligere
- spil
- game-changer
- GDPR
- GDPR overholdelse
- gearet
- Generelt
- generere
- genereret
- genererer
- generere
- generation
- generative
- Generativ AI
- få
- få
- Giv
- given
- giver
- Give
- Go
- mål
- Mål
- godt
- bevilget
- stor
- gruppe
- Dyrkning
- havde
- hånd
- Gem
- Have
- have
- he
- hovedsæde
- tunge
- tunge løft
- hjælpe
- hjælper
- hende
- link.
- Høj
- højtydende
- høj kvalitet
- højere
- højeste
- Fremhævet
- højdepunkter
- stærkt
- hints
- hans
- historie
- hætte
- Hvordan
- Men
- HTTPS
- menneskelig
- læsbar
- i
- idé
- identificeret
- identificere
- if
- billede
- KIMOs Succeshistorier
- påvirket
- påvirker
- Påvirkninger
- gennemføre
- implementering
- implementeringer
- implementeret
- implikationer
- vigtigt
- Forbedre
- in
- I andre
- Inc.
- omfatter
- Herunder
- Forøg
- inkremental
- uafhængig
- enkeltpersoner
- industrien
- oplysninger
- Infrastruktur
- initial
- i første omgang
- innovere
- Innovation
- indgang
- indgange
- øjeblikkelig
- institutioner
- anvisninger
- integrere
- integration
- hensigt
- interagere
- interaktioner
- interne
- sammenflettede
- ind
- intuitiv
- investering
- investor
- Investorer
- involverede
- udstedere
- ISV
- IT
- ITS
- rejse
- jpg
- lige
- Holde
- Nøgle
- Kendskab til
- viden
- kendt
- Labs
- sø
- landskab
- Sprog
- stor
- større
- Efternavn
- endelig
- Latency
- senere
- lag
- føre
- førende
- Leads
- lærte
- læring
- mindst
- Led
- Lessons
- Erfaringer
- Niveau
- løft
- ligesom
- synes godt om
- LLM
- logik
- London
- Lang
- Se
- leder
- Lot
- maskine
- machine learning
- lavet
- Main
- hovedsageligt
- Mainstream
- vedligeholde
- Vedligeholdelse
- lave
- maerker
- administrere
- lykkedes
- ledelse
- Produktion
- mange
- Marked
- Markedsanalyse
- Markedsdata
- Markeder
- matchede
- matematiske
- Kan..
- meningsfuld
- betød
- mekanismer
- Mød
- medlem
- mødte
- Meta
- Metadata
- metode
- Metode
- microservices
- mindste
- minimering
- blande
- ML
- model
- modeller
- Moderne
- Moduler
- mere
- mest
- for det meste
- flytning
- meget
- multi
- flere
- navn
- indfødte
- Natural
- Natural Language Processing
- Natur
- nødvendig
- Behov
- behov
- negativt
- netværk
- Ny
- New York
- næste
- ingen
- Bemærk
- bemærke
- nu
- nummer
- numre
- objektiv
- Obvious
- of
- off
- tilbydes
- Tilbud
- officerer
- kontorer
- tit
- on
- ONE
- kun
- åbent
- open source
- optimal
- optimering
- Optimer
- optimeret
- optimering
- Indstillinger
- or
- orkestrering
- orkestrering
- ordrer
- original
- Andet
- vores
- output
- i løbet af
- samlet
- oversigt
- overvældende
- egen
- ejede
- ejerskab
- parametre
- del
- særlig
- Bestået
- lidenskab
- patent
- Patenter
- sti
- Udfør
- ydeevne
- udfører
- pick
- stykker
- perron
- plato
- Platon Data Intelligence
- PlatoData
- Leg
- Punkt
- punkter
- positiv
- mulig
- Indlæg
- potentiale
- magt
- beføjelser
- praksis
- foretrækkes
- præsentere
- forelagt
- forhindre
- pris
- principper
- Beskyttelse af personlige oplysninger
- Privatliv og sikkerhed
- behandle
- forarbejdning
- producere
- produceret
- Produkter
- professionel
- dyb
- projekt
- projekter
- prompter
- bevis
- Bevis for koncept
- passende
- proprietære
- bevist
- give
- forudsat
- giver
- leverer
- offentlige
- offentlige virksomheder
- offentligt
- formål
- sætte
- Spørgsmål og svar
- kvalitet
- forespørgsler
- spørgsmål
- hurtigt
- citater
- Ranking
- hellere
- RE
- klar
- virkelige verden
- gik op for
- modtage
- anbefales
- optegnelser
- henvisninger
- reguleret
- relationer
- forhold
- relevant
- Rapporter
- repræsentativt
- repræsenterer
- repræsenterer
- kræver
- påkrævet
- Krav
- ressource
- respekteret
- henseender
- svar
- reaktioner
- begrænse
- Resultater
- indtægter
- tilbage
- gennemgå
- højre
- risici
- roller
- roller
- Værelse
- rundt
- regler
- Kør
- løber
- samme
- tilfreds
- Tilfreds med
- Gem
- siger
- Skalerbarhed
- Scale
- Videnskab
- ridse
- sømløs
- problemfrit
- Søg
- Anden
- sekunder
- Sektion
- sikker
- sikkerhed
- se
- valg
- Sælgere
- send
- senior
- forstand
- adskille
- Series
- Serverless
- tjeneste
- Tjenester
- sæt
- sæt
- flere
- forme
- aktionær
- Aktionærer
- hun
- bør
- viste
- vist
- Shows
- signifikant
- Simpelt
- enklere
- forenklet
- forenkle
- forenkle
- enkelt
- Størrelse
- størrelser
- mindre
- Smart
- smartere
- Software
- softwareudvikling
- løsninger
- Løsninger
- nogle
- sofistikeret
- Kilde
- Kilder
- spænding
- spændvidder
- Taler
- specialister
- specialiseret
- specifikke
- specifikt
- Stabilitet
- stable
- Stage
- stakes
- stå
- står
- starte
- påbegyndt
- Starter
- Statement
- forblive
- Trin
- Steps
- bestand
- aktiemarkedet
- opbevaret
- forhandler
- ligetil
- Strategisk
- struktur
- struktureret
- Efterfølgende
- succes
- Succesfuld
- sådan
- tilstrækkeligt
- egnede
- suite
- opsummere
- RESUMÉ
- support
- Understøtter
- overvågning
- Kontakt
- syntaks
- systemet
- bord
- skræddersyet
- Tag
- taget
- tager
- tager
- Opgaver
- opgaver
- hold
- tech
- Teknisk
- teknikker
- Teknologier
- telecom
- fortæller
- skabelon
- prøve
- Test
- tests
- tekst
- end
- Tak
- at
- Hovedstaden
- deres
- derefter
- Der.
- Disse
- de
- Tænker
- denne
- tre
- Gennem
- hele
- tid
- Tidsserier
- gange
- titan
- til
- nutidens
- sammen
- token
- Tokens
- også
- værktøj
- værktøjer
- emne
- toronto
- mod
- Tog
- uddannet
- Kurser
- transaktion
- Transaktioner
- omdanne
- tur
- sand
- Stol
- TUR
- to
- typen
- typer
- typisk
- ude af stand
- under
- underliggende
- forstå
- forståelse
- forstår
- forstået
- enestående
- oplåsning
- unødvendig
- us
- brug
- brug tilfælde
- anvendte
- Bruger
- brugervenlig
- ved brug af
- udnytter
- gyldig
- validering
- værdi
- række
- forskellige
- sælger
- Verifikation
- verificeres
- verificere
- meget
- levedygtig
- Specifikation
- Virtual
- vision
- gå
- ønskede
- var
- Vej..
- we
- web
- webservices
- Webinarer
- Hjemmeside
- GODT
- gik
- var
- Vest
- Hvad
- Hjul
- hvornår
- ud fra følgende betragtninger
- som
- mens
- vilje
- med
- inden for
- uden
- Dame
- ord
- Arbejde
- arbejdede
- workflow
- arbejder
- værd
- ville
- skriver
- skriv kode
- XML
- endnu
- york
- Du
- Din
- youtube
- zephyrnet