Dette innlegget er skrevet sammen med Stanislav Yeshchenko fra Q4 Inc.
Bedrifter henvender seg til Retrieval Augmented Generation (RAG) som en vanlig tilnærming til å bygge spørsmål og svar chatbots. Vi fortsetter å se nye utfordringer som stammer fra arten av utvalget av tilgjengelige datasett. Disse datasettene er ofte en blanding av numeriske og tekstdata, til tider strukturerte, ustrukturerte eller semistrukturerte.
Q4 Inc. trengte for å løse noen av disse utfordringene i en av deres mange AI-brukstilfeller bygget på AWS. I dette innlegget diskuterer vi en Q&A bot-brukscase som Q4 har implementert, utfordringene som numeriske og strukturerte datasett presenterte, og hvordan Q4 konkluderte med at bruk av SQL kan være en levedyktig løsning. Til slutt ser vi nærmere på hvordan Q4-teamet brukte Amazonas grunnfjell og SQLDatabaseChain for å implementere en RAG-basert løsning med SQL-generering.
Bruk saksoversikt
Q4 Inc., med hovedkontor i Toronto, med kontorer i New York og London, er en ledende tilgangsplattform for kapitalmarkeder som forvandler hvordan utstedere, investorer og selgere effektivt kobler til, kommuniserer og engasjerer seg med hverandre. Q4-plattformen forenkler interaksjoner på tvers av kapitalmarkedene gjennom IR-nettsideprodukter, løsninger for virtuelle arrangementer, engasjementsanalyse, investorrelasjoner Customer Relationship Management (CRM), aksjonær- og markedsanalyse, overvåking og ESG-verktøy.
I dagens raske og datadrevne finansielle landskap, spiller Investor Relations Officers (IROs) en kritisk rolle i å fremme kommunikasjon mellom et selskap og dets aksjonærer, analytikere og investorer. Som en del av deres daglige oppgaver analyserer IRO ulike datasett, inkludert CRM, eierskapsregister og aksjemarkedsdata. Samlingen av disse dataene brukes til å generere økonomiske rapporter, sette mål for investorrelasjoner og administrere kommunikasjon med eksisterende og potensielle investorer.
For å møte den økende etterspørselen etter effektiv og dynamisk datainnhenting, hadde Q4 som mål å lage et chatbot Q&A-verktøy som ville gi en intuitiv og enkel metode for IROer for å få tilgang til den nødvendige informasjonen de trenger i et brukervennlig format.
Sluttmålet var å lage en chatbot som sømløst skulle integrere offentlig tilgjengelige data, sammen med proprietære kundespesifikke Q4-data, samtidig som det opprettholdes det høyeste nivået av sikkerhet og personvern. Når det gjelder ytelse, var målet å opprettholde en spørresvartid på sekunder for å sikre en positiv opplevelse for sluttbrukerne.
Finansmarkedene er en regulert bransje med høye innsatser involvert. Å gi feil eller utdatert informasjon kan påvirke investorers og aksjonærers tillit, i tillegg til andre mulige datavernrisikoer. For å forstå bransjen og kravene, setter Q4 datapersonvern og responsnøyaktighet som sine veiledende prinsipper for å evaluere enhver løsning før den kan tas på markedet.
For proof of concept bestemte Q4 seg for å bruke et økonomisk eierskapsdatasett. Datasettet består av tidsseriedatapunkter som representerer antall eiendeler som eies; transaksjonshistorikken mellom investeringsinstitusjoner, enkeltpersoner og offentlige selskaper; og mange flere elementer.
Fordi Q4 ønsket å sikre at det kunne tilfredsstille alle funksjonelle og ikke-funksjonelle krav vi har diskutert, måtte prosjektet også forbli kommersielt gjennomførbart. Dette ble respektert gjennom hele prosessen med å bestemme seg for tilnærming, arkitektur, valg av teknologi og løsningsspesifikke elementer.
Eksperimentering og utfordringer
Det var klart fra begynnelsen at for å forstå et menneskelig språkspørsmål og generere nøyaktige svar, måtte Q4 bruke store språkmodeller (LLM).
Følgende er noen av eksperimentene som ble utført av teamet, sammen med utfordringene som ble identifisert og erfaringene:
- Førtrening – Q4 forsto kompleksiteten og utfordringene som følger med å forhåndstrene en LLM ved å bruke sitt eget datasett. Det ble raskt åpenbart at denne tilnærmingen er ressurskrevende med mange ikke-trivielle trinn, som forbehandling av data, opplæring og evaluering. I tillegg til innsatsen ville det være uoverkommelig. Tatt i betraktning arten av tidsseriedatasettet, innså Q4 også at det ville måtte utføre inkrementell forhåndstrening etter hvert som nye data kom inn. Dette ville ha krevd et dedikert tverrfaglig team med ekspertise innen datavitenskap, maskinlæring og domene kunnskap.
- Finjustering – Finjustering av en forhåndsopplært fundamentmodell (FM) innebar bruk av flere merkede eksempler. Denne tilnærmingen viste en viss suksess i starten, men i mange tilfeller var modellhallusinasjon en utfordring. Modellen slet med å forstå nyanserte kontekstuelle signaler og ga feil resultater.
- RAG med semantisk søk – Konvensjonell RAG med semantisk søk var det siste trinnet før overgangen til SQL-generering. Teamet eksperimenterte med å bruke søk, semantisk søk og innebygginger for å trekke ut kontekst. Under embedding-eksperimentet ble datasettet konvertert til embeddings, lagret i en vektordatabase og deretter matchet med embeddings av spørsmålet for å trekke ut kontekst. Den hentede konteksten i et av de tre eksperimentene ble deretter brukt til å forsterke den opprinnelige ledeteksten som et input til LLM. Denne tilnærmingen fungerte bra for tekstbasert innhold, der dataene består av naturlig språk med ord, setninger og avsnitt. Med tanke på karakteren av Q4s datasett, som for det meste er økonomiske data bestående av tall, finansielle transaksjoner, aksjekurser og datoer, var resultatene i alle tre tilfellene suboptimale. Selv ved bruk av embeddings, slet innbyggingene generert fra tall med likhetsrangering, og førte i mange tilfeller til å hente feil informasjon.
Q4s konklusjon: Generering av SQL er veien videre
Med tanke på utfordringene ved bruk av konvensjonell RAG-metodikk, begynte teamet å vurdere SQL-generering. Ideen var å bruke LLM til først å generere en SQL-setning fra brukerspørsmålet, presentert for LLM på naturlig språk. Den genererte spørringen kjøres deretter mot databasen for å hente den relevante konteksten. Konteksten brukes til slutt for å forsterke input-forespørselen for et oppsummeringstrinn.
Q4s hypotese var at for å få høyere tilbakekalling for gjenfinningstrinnet, spesifikt for det numeriske datasettet, måtte de først generere SQL fra brukerspørsmålet. Dette ble antatt å ikke bare øke nøyaktigheten, men også holde konteksten innenfor forretningsdomenet for et gitt spørsmål. For å generere spørringer, og for å generere nøyaktig SQL, trengte Q4 å gjøre LLM fullstendig kontekstbevisst om datasettstrukturen. Dette betydde spørsmålet som var nødvendig for å inkludere databaseskjemaet, noen få prøvedatarader og menneskelesbare feltforklaringer for feltene som ikke er enkle å forstå.
Basert på de første testene, viste denne metoden gode resultater. LLM utstyrt med all nødvendig informasjon var i stand til å generere riktig SQL, som deretter ble kjørt mot databasen for å hente riktig kontekst. Etter å ha eksperimentert med ideen, bestemte Q4 at SQL-generering var veien videre for å løse kontekstutvinningsutfordringer for deres eget spesifikke datasett.
La oss starte med å beskrive den overordnede løsningstilnærmingen, dele den ned til komponentene, og deretter sette delene sammen.
Løsningsoversikt
LLM-er er store modeller med milliarder av parametere som er forhåndsopplært ved å bruke svært store mengder data fra en rekke kilder. På grunn av bredden i opplæringsdatasettene forventes det at LLM-er har generell kunnskap innen en rekke domener. LLM-er er også kjent for sine resonneringsevner, som varierer fra modell til modell. Denne generelle oppførselen kan optimaliseres til et spesifikt domene eller bransje ved å optimalisere en grunnmodell ytterligere ved å bruke ytterligere domenespesifikke forhåndsopplæringsdata eller ved å finjustere ved å bruke merkede data. Gitt riktig kontekst, metadata og instruksjoner, kan en velvalgt generell LLM produsere SQL av god kvalitet så lenge den har tilgang til riktig domenespesifikk kontekst.
I Q4s use case starter vi med å oversette kundespørsmålet til SQL. Vi gjør dette ved å kombinere brukerspørsmålet, databaseskjemaet, noen eksempeldatabaserader og detaljerte instruksjoner som en melding til LLM om å generere SQL. Etter at vi har SQL, kan vi kjøre et valideringstrinn hvis det anses nødvendig. Når vi er fornøyd med kvaliteten på SQL-en, kjører vi spørringen mot databasen for å hente den relevante konteksten vi trenger for det følgende trinnet. Nå som vi har den relevante konteksten, kan vi sende brukerens opprinnelige spørsmål, konteksten hentet og et sett med instruksjoner tilbake til LLM for å produsere et endelig oppsummert svar. Målet med det siste trinnet er å få LLM til å oppsummere resultatene og gi et kontekstuelt og nøyaktig svar som deretter kan sendes videre til brukeren.
Valget av LLM som brukes på alle trinn i prosessen, påvirker nøyaktigheten, kostnadene og ytelsen i stor grad. Å velge en plattform eller teknologi som kan gi deg fleksibiliteten til å bytte mellom LLM-er innenfor samme brukstilfelle (flere LLM-turer for forskjellige oppgaver), eller på tvers av forskjellige brukstilfeller, kan være fordelaktig for å optimalisere kvaliteten på utdata, latens og kostnad . Vi tar for oss valg av LLM senere i dette innlegget.
Løsning byggeklosser
Nå som vi har fremhevet tilnærmingen på et høyt nivå, la oss dykke ned i detaljene, og starter med løsningens byggeklosser.
Amazonas grunnfjell
Amazon Bedrock er en fullt administrert tjeneste som tilbyr et utvalg av høyytende FM-er fra ledende selskaper, inkludert AI21 Labs, Anthropic, Cohere, Meta, Stability AI og Amazon. Amazon Bedrock tilbyr også et bredt sett med verktøy som trengs for å bygge generative AI-applikasjoner, forenkle utviklingsprosessen og opprettholde personvern og sikkerhet. I tillegg kan du med Amazon Bedrock velge mellom ulike FM-alternativer, og du kan finjustere modellene ytterligere privat ved å bruke dine egne data for å tilpasse modellens svar med kravene til brukstilfeller. Amazon Bedrock er helt serverløs uten underliggende infrastruktur for å administrere utvidet tilgang til tilgjengelige modeller gjennom ett enkelt API. Til slutt støtter Amazon Bedrock flere sikkerhets- og personvernkrav, inkludert HIPAA-kvalifisering og GDPR-overholdelse.
I Q4s løsning bruker vi Amazon Bedrock som en serverløs, API-basert, multi-fundamentell modellbyggestein. Fordi vi har til hensikt å foreta flere turer til LLM innenfor samme use case, basert på oppgavetypen, kan vi velge den modellen som er mest optimal for en spesifikk oppgave, enten det er SQL generering, validering eller oppsummering.
Langkjede
Langkjede er et integrerings- og orkestreringsrammeverk med åpen kildekode med et sett med forhåndsbygde moduler (I/O, gjenfinning, kjeder og agenter) som du kan bruke til å integrere og orkestrere oppgaver mellom FM-er, datakilder og verktøy. Rammeverket gjør det lettere å bygge generative AI-applikasjoner som krever orkestrering av flere trinn for å produsere ønsket utgang, uten å måtte skrive kode fra bunnen av. LangChain støtter Amazon Bedrock som en multi-fundament modell API.
Spesifikt for Q4s use case, bruker vi LangChain for å koordinere og orkestrere oppgaver i arbeidsflyten vår, inkludert kobling til datakilder og LLM-er. Denne tilnærmingen har forenklet koden vår fordi vi kan bruke de eksisterende LangChain-modulene.
SQLDatabaseChain
SQLDatabaseChain er en LangChain-kjede som kan importeres fra langchain_experimental. SLDatabaseChain gjør det enkelt å lage, implementere og kjøre SQL-spørringer ved å bruke effektive tekst-til-SQL-konverteringer og implementeringer.
I vårt brukstilfelle bruker vi SQLDatabaseChain i SQL-genereringen, og forenkler og orkestrerer interaksjoner mellom databasen og LLM.
Datasettet
Vårt strukturerte datasett kan ligge i en SQL-database, datainnsjø eller datavarehus så lenge vi har støtte for SQL. I vår løsning kan vi bruke hvilken som helst datasetttype med SQL-støtte; dette bør abstraheres fra løsningen og bør ikke endre løsningen på noen måte.
Gjennomføringsdetaljer
Nå som vi har utforsket løsningstilnærmingen, løsningskomponentene, valg av teknologi og verktøy, kan vi sette bitene sammen. Følgende diagram fremhever ende-til-ende-løsningen.
La oss gå gjennom implementeringsdetaljene og prosessflyten.
Generer SQL-spørringen
For å forenkle koding bruker vi eksisterende rammeverk. Vi bruker LangChain som et orkestreringsrammeverk. Vi starter med input-stadiet, hvor vi mottar brukerspørsmålet på naturlig språk.
I denne første fasen tar vi denne inngangen og genererer en tilsvarende SQL som vi kan kjøre mot databasen for kontekstekstraksjon. For å generere SQL bruker vi SQLDatabaseChain, som er avhengig av Amazon Bedrock for tilgang til ønsket LLM. Med Amazon Bedrock, ved å bruke et enkelt API, får vi tilgang til en rekke underliggende LLM-er og kan velge den rette for hver LLM-reise vi gjør. Vi etablerer først en tilkobling til databasen og henter det nødvendige tabellskjemaet sammen med noen eksempelrader fra tabellene vi har tenkt å bruke.
I vår testing fant vi at 2–5 rader med tabelldata var tilstrekkelig til å gi nok informasjon til modellen uten å legge til for mye unødvendig overhead. Tre rader var akkurat nok til å gi kontekst, uten å overvelde modellen med for mye input. I vårt brukstilfelle startet vi med Anthropic Claude V2. Modellen er kjent for sine avanserte resonnementer og artikulerte kontekstuelle svar når den er utstyrt med riktig kontekst og instruksjoner. Som en del av instruksjonene kan vi inkludere mer avklarende detaljer til LLM. For eksempel kan vi beskrive den kolonnen Comp_NAME
står for firmanavnet. Vi kan nå konstruere ledeteksten ved å kombinere brukerspørsmålet som det er, databaseskjemaet, tre eksempelrader fra tabellen vi har tenkt å bruke, og et sett med instruksjoner for å generere den nødvendige SQL-en i rent SQL-format uten kommentarer eller tillegg.
Alle inndataelementene kombinert betraktes som modellinndataprompten. En godt konstruert input-forespørsel som er skreddersydd for modellens foretrukne syntaks, påvirker i stor grad både kvaliteten og ytelsen til utdataene. Valget av modell som skal brukes for en spesifikk oppgave er også viktig, ikke bare fordi det påvirker utskriftskvaliteten, men også fordi det har kostnads- og ytelsesimplikasjoner.
Vi diskuterer modellvalg og rask utvikling og optimalisering senere i dette innlegget, men det er verdt å merke seg at for søkegenereringsstadiet la vi merke til at Claude Instant var i stand til å produsere sammenlignbare resultater, spesielt når brukerspørsmålet er godt formulert og ikke så sofistikert. Claude V2 ga imidlertid bedre resultater selv med mer komplekse og indirekte brukerinnspill. Vi lærte det selv om det i noen tilfeller Claude Instant kan gi tilstrekkelig nøyaktighet til en bedre ventetid og prispunkt, var vår sak for søkegenerering bedre egnet for Claude V2.
Bekreft SQL-spørringen
Vårt neste trinn er å bekrefte at LLM har generert riktig søkesyntaks og at spørringen gir kontekstuell mening med tanke på databaseskjemaene og eksempelradene som er gitt. For dette verifiseringstrinnet kan vi gå tilbake til native spørringsvalidering i SQLDatabaseChain, eller vi kan kjøre en ny tur til LLM inkludert spørringen generert sammen med valideringsinstruksjoner.
Hvis vi bruker en LLM for valideringstrinnet, kan vi bruke samme LLM som før (Claude V2) eller en mindre, mer presterende LLM for en enklere oppgave, for eksempel Claude Instant. Fordi vi bruker Amazon Bedrock, bør dette være en veldig enkel justering. Ved å bruke samme API kan vi endre modellnavnet i API-kallet vårt, som tar seg av endringen. Det er viktig å merke seg at i de fleste tilfeller kan en mindre LLM gi bedre effektivitet både når det gjelder kostnader og ventetid og bør vurderes – så lenge du får den nøyaktigheten du ønsker. I vårt tilfelle viste testing at søket som ble generert var konsekvent nøyaktig og med riktig syntaks. Når vi visste det, kunne vi hoppe over dette valideringstrinnet og spare på ventetid og kostnader.
Kjør SQL-spørringen
Nå som vi har den verifiserte SQL-spørringen, kan vi kjøre SQL-spørringen mot databasen og hente den relevante konteksten. Dette bør være et enkelt skritt.
Vi tar den genererte konteksten, gir den til LLM etter eget valg med det første brukerspørsmålet og noen instruksjoner, og ber modellen generere en kontekstuell og artikulert oppsummering. Vi presenterer deretter det genererte sammendraget for brukeren som et svar på det første spørsmålet, alt på linje med konteksten hentet fra datasettet vårt.
For LLM som er involvert i oppsummeringstrinnet, kan vi bruke enten Titan Text Express eller Claude Instant. De ville begge presentere gode alternativer for oppsummeringsoppgaven.
Søknadsintegrasjon
Spørsmål og svar chatbot-funksjonen er en av Q4s AI-tjenester. For å sikre modularitet og skalerbarhet bygger Q4 AI-tjenester som mikrotjenester som er tilgjengelige for Q4-applikasjoner gjennom APIer. Denne API-baserte tilnærmingen muliggjør sømløs integrasjon med Q4 Platform-økosystemet og gjør det lettere å eksponere AI-tjenestenes evner for hele pakken med plattformapplikasjoner.
Hovedmålet med AI-tjenestene er å gi enkle muligheter for å hente data fra enhver offentlig eller proprietær datakilde ved å bruke naturlig språk som input. I tillegg gir AI-tjenestene ytterligere lag med abstraksjon for å sikre at funksjonelle og ikke-funksjonelle krav, som for eksempel datavern og sikkerhet, oppfylles. Følgende diagram viser integrasjonskonseptet.
Implementeringsutfordringer
I tillegg til utfordringene som følger av arten til det strukturerte, numeriske datasettet som vi diskuterte tidligere, ble Q4 møtt med en rekke andre implementeringsutfordringer som måtte løses.
LLM valg og ytelse
Å velge riktig LLM for oppgaven er avgjørende fordi det direkte påvirker kvaliteten på utdata så vel som ytelsen (tur-retur latens). Her er noen faktorer som spiller inn i LLM-utvelgelsesprosessen:
- Type LLM – Måten FM-ene er bygd opp på og de første dataene modellen har blitt forhåndstrent på, bestemmer hvilke typer oppgaver LLM vil være god på og hvor god den vil være. For eksempel vil en tekst LLM være god på tekstgenerering og oppsummering, mens en tekst-til-bilde eller bilde-til-tekst-modell vil være mer rettet mot bildeanalyse og genereringsoppgaver.
- LLM størrelse – FM-størrelser måles ved antall modellparametere en bestemt modell har, typisk i milliarder for moderne LLM-er. Vanligvis er det slik at jo større modellen er, desto dyrere er det å trene eller etterpå finjustere. På den annen side, generelt, for den samme modellarkitekturen, jo større modellen er, jo smartere forventer vi at den skal være i å utføre den type oppgave den er rettet mot.
- LLM ytelse – Vanligvis, jo større modellen er, jo mer tid tar det å generere utdata, forutsatt at du bruker samme beregnings- og I/O-parametere (spørsmål og utdatastørrelse). I tillegg, for samme modellstørrelse, påvirkes ytelsen sterkt av hvor optimalisert forespørselen din er, størrelsen på I/O-tokenene og klarheten og syntaksen til forespørselen. En godt konstruert ledetekst, sammen med en optimalisert I/O-tokenstørrelse, kan forbedre modellens responstid.
Når du optimaliserer oppgaven din, bør du derfor vurdere følgende beste fremgangsmåter:
- Velg en modell som passer for oppgaven
- Velg den minste modellstørrelsen som kan gi nøyaktigheten du leter etter
- Optimaliser forespørselsstrukturen og vær så spesifikk som mulig med instruksjonene på en måte som er enkel å forstå for modellen
- Bruk den minste inndataprompten som kan gi nok instruksjoner og kontekst til å produsere nøyaktighetsnivået du leter etter
- Begrens utskriftsstørrelsen til den minste størrelsen som kan være meningsfull for deg og tilfredsstille utskriftskravene dine
Med tanke på modellvalg og ytelsesoptimaliseringsfaktorer, gikk vi i gang med å optimalisere vår SQL-generasjonsbruk. Etter litt testing la vi merke til at, forutsatt at vi har den rette konteksten og instruksjonene, ville Claude Instant, med de samme prompte dataene, produsere sammenlignbar kvalitet på SQL som Claude V2 til en mye bedre ytelse og pris. Dette gjelder når brukerinnspillet er mer direkte og enklere. For mer sofistikert input var Claude V2 nødvendig for å produsere ønsket nøyaktighet.
Å bruke den samme logikken på oppsummeringsoppgaven førte til at vi konkluderte med at bruk av Claude Instant eller Titan Text Express ville gi nøyaktigheten som kreves ved et mye bedre ytelsespunkt enn hvis vi bruker en større modell som Claude V2. Titan Text Expressed tilbød også bedre prisytelse, som vi diskuterte tidligere.
Orkestrasjonsutfordringen
Vi innså at det er mye som skal orkestreres før vi kan få et meningsfylt utdatasvar på brukerspørsmålet. Som vist i løsningsoversikten innebar prosessen flere databaseturer og flere LLM-turer som er sammenvevd. Hvis vi skulle bygge fra bunnen av, hadde vi måttet gjøre en betydelig investering i de udifferensierte tunge løftene bare for å få grunnkoden klar. Vi gikk raskt over til å bruke LangChain som et orkestreringsrammeverk, dra nytte av kraften i åpen kildekode-fellesskapet og gjenbruke eksisterende moduler uten å finne opp hjulet på nytt.
SQL-utfordringen
Vi innså også at å generere SQL ikke er så enkelt som kontekstutvinningsmekanismer som semantisk søk eller bruk av innebygging. Vi må først få databaseskjemaet og noen få eksempelrader som skal inkluderes i forespørselen vår til LLM. Det er også SQL-valideringsstadiet, hvor vi trengte å samhandle med både databasen og LLM. SQLDatabaseChain var det åpenbare valget av verktøy. Fordi det er en del av LangChain, var det enkelt å tilpasse, og nå kan vi administrere SQL-generering og verifisering assistert med kjeden, og minimere mengden arbeid vi trengte å gjøre.
Ytelsesutfordringer
Med bruk av Claude V2, og etter skikkelig prompt engineering (som vi diskuterer i neste avsnitt), var vi i stand til å produsere høykvalitets SQL. Med tanke på kvaliteten på den genererte SQL-en, begynte vi å se på hvor mye verdi valideringsstadiet faktisk tilfører. Etter å ha analysert resultatene videre, ble det klart at kvaliteten på den genererte SQL-en var konsekvent nøyaktig på en måte som gjorde kostnaden/nytten ved å legge til et SQL-valideringstrinn ugunstig. Vi endte opp med å eliminere SQL-valideringsstadiet uten å påvirke kvaliteten på produksjonen negativt og barberte av SQL-valideringens tur-retur-tid.
I tillegg til å optimalisere for en mer kostnads- og ytelseseffektiv LLM for oppsummeringstrinnet, var vi i stand til å bruke Titan Text Express for å få bedre ytelse og kostnadseffektivitet.
Ytterligere ytelsesoptimalisering innebar finjustering av spørringsgenereringsprosessen ved å bruke effektive, raske ingeniørteknikker. I stedet for å gi en overflod av tokens, var fokuset på å gi minst mulig input-tokens, i riktig syntaks som modellen er opplært til å forstå, og med det minimale, men likevel optimale settet med instruksjoner. Vi diskuterer dette mer i neste seksjon – det er et viktig emne som gjelder ikke bare her, men også i andre brukstilfeller.
Rask prosjektering og optimalisering
Du kan justere Claude på Amazon Bedrock for ulike tilfeller av forretningsbruk hvis de riktige tekniske teknikkene brukes. Claude fungerer hovedsakelig som en samtaleassistent som bruker et menneske/assistent-format. Claude er opplært til å fylle ut tekst til assistentrollen. Gitt instruksjonene og fullføringene som ønskes, kan vi optimalisere instruksjonene våre for Claude ved å bruke flere teknikker.
Vi starter med en riktig formatert forespørselsmal som gir en gyldig fullføring, deretter kan vi optimalisere svarene ytterligere ved å eksperimentere med forespørsel med ulike sett med inndata som er representative for virkelige data. Det anbefales å få mange innspill mens du utvikler en spørremal. Du kan også bruke separate sett med prompte utviklingsdata og testdata.
En annen måte å optimalisere Claude-responsen på er å eksperimentere og iterere ved å legge til regler, instruksjoner og nyttige optimaliseringer. Fra disse optimaliseringene kan du se ulike typer fullføringer ved for eksempel å be Claude nevne "jeg vet ikke" for å forhindre hallusinasjoner, tenke trinn for trinn, bruke umiddelbar kjetting, gi rom til å "tenke" når det genererer svar , og dobbeltsjekke for forståelse og nøyaktighet.
La oss bruke vår oppgavegenereringsoppgave og diskutere noen av teknikkene vi brukte for å optimalisere forespørselen vår. Det var noen få kjerneelementer som var til fordel for vår søkegenereringsinnsats:
- Bruke riktig menneske/assistent-syntaks
- Bruke XML-koder (Claude respekterer og forstår XML-koder)
- Legger til klare instruksjoner for modellen for å forhindre hallusinasjoner
Følgende generiske eksempel viser hvordan vi brukte menneske/assistent-syntaksen, brukte XML-tagger og la til instruksjoner for å begrense utdata til SQL og instruere modellen til å si "beklager, jeg kan ikke hjelpe" hvis den ikke kan produsere relevant SQL . XML-kodene ble brukt til å ramme instruksjonene, flere hint, databaseskjema, ytterligere tabellforklaringer og eksempelrader.
Den endelige fungerende løsningen
Etter at vi hadde tatt tak i alle utfordringene som ble identifisert under proof of concept, hadde vi oppfylt alle løsningskravene. Q4 var fornøyd med kvaliteten på SQL generert av LLM. Dette gjelder for enkle oppgaver som bare krevde en WHERE-klausul for å filtrere dataene, og også med mer komplekse oppgaver som krevde kontekstbaserte aggregeringer med GROUP BY og matematiske funksjoner. Ende-til-ende-latensen for den samlede løsningen kom innenfor det som ble definert som akseptabelt for brukstilfellet – ensifrede sekunder. Alt dette var takket være valget av en optimal LLM på alle trinn, riktig prompt engineering, eliminering av SQL-verifiseringstrinnet og bruk av en effektiv LLM for oppsummeringstrinnet (Titan Text Express eller Claude Instant).
Det er verdt å merke seg at bruk av Amazon Bedrock som en fullstendig administrert tjeneste og muligheten til å ha tilgang til en pakke med LLM-er gjennom samme API tillot eksperimentering og sømløs veksling mellom LLM-er ved å endre modellnavnet i API-kallet. Med dette fleksibilitetsnivået var Q4 i stand til å velge den mest effektive LLM for hvert LLM-anrop basert på oppgavens art, enten det er generering av spørringer, verifisering eller oppsummering.
konklusjonen
Det finnes ingen én løsning som passer alle brukstilfeller. I en RAG-tilnærming avhenger kvaliteten på produksjonen sterkt av å gi den rette konteksten. Å trekke ut riktig kontekst er nøkkelen, og hvert datasett er forskjellig med sine unike egenskaper.
I dette innlegget demonstrerte vi at for numeriske og strukturerte datasett kan bruk av SQL for å trekke ut konteksten som brukes til utvidelse føre til mer gunstige resultater. Vi demonstrerte også at rammeverk som LangChain kan minimere kodeinnsatsen. I tillegg diskuterte vi behovet for å kunne bytte mellom LLM-er innenfor samme brukstilfelle for å oppnå den mest optimale nøyaktigheten, ytelsen og kostnadene. Til slutt fremhevet vi hvordan Amazon Bedrock, som er serverløs og med en rekke LLM-er under panseret, gir den fleksibiliteten som trengs for å bygge sikre, ytende og kostnadsoptimaliserte applikasjoner med minst mulig tunge løft.
Start reisen mot å bygge generative AI-aktiverte applikasjoner ved å identifisere et brukstilfelle av verdi for virksomheten din. SQL-generering, som Q4-teamet lærte, kan være en game changer i å bygge smarte applikasjoner som integreres med datalagrene dine, og låser opp inntektspotensialet.
Om forfatterne
Tamer Soliman er Senior Solutions Architect hos AWS. Han hjelper Independent Software Vendor-kunder (ISV) med å innovere, bygge og skalere på AWS. Han har over to tiår med bransjeerfaring innen rådgivning, opplæring og profesjonelle tjenester. Han er en multipatentoppfinner med tre tildelte patenter, og hans erfaring spenner over flere teknologidomener, inkludert telekom, nettverk, applikasjonsintegrasjon, AI/ML og skyimplementeringer. Han spesialiserer seg på AWS-nettverk og har en dyp lidenskap for maskinstiling, AI og Generativ AI.
Mani Khanuja er en Tech Lead – Generative AI Specialists, forfatter av boken – Applied Machine Learning and High Performance Computing på AWS, og medlem av styret for Women in Manufacturing Education Foundation Board. Hun leder maskinlæringsprosjekter (ML) innen ulike domener som datasyn, naturlig språkbehandling og generativ AI. Hun hjelper kunder med å bygge, trene og distribuere store maskinlæringsmodeller i stor skala. Hun snakker på interne og eksterne konferanser som re:Invent, Women in Manufacturing West, YouTube webinarer og GHC 23. På fritiden liker hun å gå lange løpeturer langs stranden.
Stanislav Jesjtsjenko er programvarearkitekt hos Q4 Inc.. Han har over et tiår med bransjeerfaring innen programvareutvikling og systemarkitektur. Hans mangfoldige bakgrunn spenner over roller som teknisk leder og senior fullstackutvikler, driver hans bidrag til å fremme innovasjon av Q4-plattformen. Stanislav er dedikert til å drive teknisk innovasjon og forme strategiske løsninger på feltet.
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
- PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
- PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
- PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
- kilde: https://aws.amazon.com/blogs/machine-learning/how-q4-inc-used-amazon-bedrock-rag-and-sqldatabasechain-to-address-numerical-and-structured-dataset-challenges-building-their-qa-chatbot/
- : har
- :er
- :ikke
- :hvor
- $OPP
- 100
- 118
- 125
- 15%
- 23
- 7
- a
- evner
- evne
- I stand
- abstraksjon
- overflod
- akseptabelt
- adgang
- tilgjengelig
- Logg inn
- nøyaktighet
- nøyaktig
- Oppnå
- tvers
- handlinger
- faktisk
- tilpasse
- la til
- legge
- tillegg
- Ytterligere
- I tillegg
- tilleggene
- adresse
- adressert
- Justering
- avansert
- Advancing
- Fordel
- Etter
- mot
- agenter
- aggregat
- AI
- AI-tjenester
- ai brukstilfeller
- AI / ML
- sikte
- justere
- justert
- Alle
- tillate
- tillatt
- langs
- også
- Selv
- am
- Amazon
- Amazon Web Services
- beløp
- beløp
- an
- analyse
- analytikere
- analytics
- analysere
- analyserer
- og
- En annen
- besvare
- svar
- Antropisk
- noen
- hva som helst
- api
- APIer
- aktuelt
- Søknad
- søknader
- anvendt
- tilnærming
- arkitektur
- ER
- AS
- spør
- Eiendeler
- Assistent
- assistert
- sortiment
- At
- øke
- augmented
- forfatter
- tilgjengelig
- klar
- AWS
- tilbake
- bakgrunn
- basert
- grunnleggende
- BE
- Strand
- ble
- fordi
- vært
- før du
- Begynnelsen
- atferd
- være
- antatt
- gunstig
- BEST
- beste praksis
- Bedre
- mellom
- milliarder
- Blokker
- Blocks
- borde
- styret
- bok
- Bot
- både
- bredde
- Break
- bred
- bygge
- Bygning
- bygger
- bygget
- virksomhet
- men
- by
- ring
- kom
- CAN
- Kan få
- evner
- evne
- hovedstad
- Kapitalmarkeder
- hvilken
- saken
- saker
- kjede
- kjeder
- utfordre
- utfordringer
- utfordrer byggingen
- endring
- Veksler
- endring
- egenskaper
- chatbot
- chatbots
- valg
- Velg
- velge
- klarhet
- ren
- fjerne
- nærmere
- Cloud
- kode
- Koding
- Kolonne
- kombinert
- kombinere
- Kom
- kommentarer
- kommersielt
- kommunisere
- Kommunikasjon
- samfunnet
- Selskaper
- Selskapet
- sammenlign
- ferdigstillelse
- komplekse
- kompleksitet
- samsvar
- komponenter
- fatte
- Beregn
- datamaskin
- Datamaskin syn
- databehandling
- konsept
- konkluderer
- konkluderte
- konklusjon
- gjennomført
- konferanser
- Koble
- Tilkobling
- tilkobling
- Vurder
- ansett
- vurderer
- konsekvent
- Består
- består
- konstruere
- konsulent
- innhold
- kontekst
- kontekstuelle
- fortsette
- kontinuerlig
- bidragene
- konvensjonell
- conversational
- konverteringer
- konvertert
- koordinerende
- Kjerne
- korrigere
- Kostnad
- kunne
- skape
- kritisk
- CRM
- avgjørende
- kunde
- Kunder
- daglig
- dato
- Data Lake
- datapunkter
- personvern
- Datas personvern og sikkerhet
- datavitenskap
- data-drevet
- Database
- datasett
- datoer
- tiår
- tiår
- besluttet
- Avgjør
- dedikert
- anses
- definert
- Etterspørsel
- demonstrert
- demonstrerer
- avhenger
- utplassere
- distribusjoner
- beskrive
- beskrive
- ønsket
- detaljert
- detaljer
- bestemmes
- Utvikler
- utvikle
- Utvikling
- forskjellig
- direkte
- direkte
- Styremedlemmer
- diskutere
- diskutert
- dykk
- diverse
- do
- domene
- domener
- ikke
- dobbeltsjekking
- ned
- kjøring
- to
- under
- dynamisk
- hver enkelt
- Tidligere
- lett
- økosystem
- Kunnskap
- Effektiv
- effektivitet
- effektiv
- effektivt
- innsats
- innsats
- enten
- elementer
- valgbarhet
- eliminere
- Emery
- ansatt
- muliggjør
- slutt
- ende til ende
- endte
- engasjere
- engasjement
- Ingeniørarbeid
- nok
- sikre
- utstyrt
- Tilsvarende
- IT G
- spesielt
- etablere
- evaluere
- evaluering
- Selv
- hendelser
- Hver
- eksempel
- eksempler
- eksisterende
- forvente
- forventet
- dyrt
- erfaring
- eksperiment
- eksperimenter
- Expert
- ekspertise
- utforsket
- ekspress
- uttrykte
- strekker
- utvendig
- trekke ut
- utdrag
- møtt
- forenkler
- faktorer
- Fartsfylt
- gunstig
- gjennomførbart
- Noen få
- felt
- Felt
- fyll
- filtrere
- slutt~~POS=TRUNC
- Endelig
- finansiell
- Økonomiske data
- Først
- fleksibilitet
- flyten
- Fokus
- følge
- etter
- Til
- format
- Forward
- fostre
- funnet
- Fundament
- RAMME
- Rammeverk
- rammer
- Gratis
- fra
- fullt
- Full stabel
- fullt
- funksjonelle
- funksjoner
- videre
- spill
- game-changer
- GDPR
- GDPR-samsvar
- rettet
- general
- generere
- generert
- genererer
- genererer
- generasjonen
- generative
- Generativ AI
- få
- få
- Gi
- gitt
- gir
- Giving
- Go
- mål
- Mål
- god
- innvilget
- flott
- Gruppe
- Økende
- HAD
- hånd
- lykkelig
- Ha
- å ha
- he
- hovedkontor
- tung
- tung løfting
- hjelpe
- hjelper
- her
- her.
- Høy
- høytytende
- høykvalitets
- høyere
- høyest
- Fremhevet
- striper
- svært
- hint
- hans
- historie
- panser
- Hvordan
- Men
- HTTPS
- menneskelig
- lesbar
- i
- Tanken
- identifisert
- identifisering
- if
- bilde
- Påvirkning
- påvirket
- slag
- Konsekvenser
- iverksette
- gjennomføring
- implementeringer
- implementert
- implikasjoner
- viktig
- forbedre
- in
- I andre
- Inc.
- inkludere
- Inkludert
- Øke
- inkrementell
- uavhengig
- individer
- industri
- informasjon
- Infrastruktur
- innledende
- i utgangspunktet
- innovere
- Innovasjon
- inngang
- innganger
- instant
- institusjoner
- instruksjoner
- integrere
- integrering
- hensikt
- samhandle
- interaksjoner
- intern
- sammenflettet
- inn
- intuitiv
- investering
- investor
- Investorer
- involvert
- utstedere
- isv
- IT
- DET ER
- reise
- jpg
- bare
- Hold
- nøkkel
- Knowing
- kunnskap
- kjent
- Labs
- innsjø
- landskap
- Språk
- stor
- større
- Siste
- til slutt
- Ventetid
- seinere
- lag
- føre
- ledende
- Fører
- lært
- læring
- minst
- Led
- Lessons
- Lessons Learned
- Nivå
- løfte
- i likhet med
- liker
- LLM
- logikk
- London
- Lang
- Se
- ser
- Lot
- maskin
- maskinlæring
- laget
- Hoved
- hovedsakelig
- Mainstream
- vedlikeholde
- Vedlike
- gjøre
- GJØR AT
- administrer
- fikk til
- ledelse
- produksjon
- mange
- marked
- Markedsanalyse
- Market data
- Markets
- matchet
- matematiske
- Kan..
- meningsfylt
- ment
- mekanismer
- Møt
- medlem
- møtte
- Meta
- metadata
- metode
- metodikk
- microservices
- minimal
- minimere
- bland
- ML
- modell
- modeller
- Moderne
- Moduler
- mer
- mest
- for det meste
- flytting
- mye
- multi
- flere
- navn
- innfødt
- Naturlig
- Natural Language Processing
- Natur
- nødvendig
- Trenger
- nødvendig
- negativt
- nettverk
- Ny
- New York
- neste
- Nei.
- note
- merke seg
- nå
- Antall
- tall
- Målet
- Åpenbare
- of
- off
- tilbudt
- Tilbud
- offiserer
- kontorer
- ofte
- on
- ONE
- bare
- åpen
- åpen kildekode
- optimal
- optimalisering
- Optimalisere
- optimalisert
- optimalisere
- alternativer
- or
- orkestrere
- orkestre
- rekkefølge
- original
- Annen
- vår
- produksjon
- enn
- samlet
- oversikt
- overveldende
- egen
- eide
- eierskap
- parametere
- del
- Spesielt
- bestått
- lidenskap
- patent
- Patenter
- banen
- Utfør
- ytelse
- utfører
- plukke
- stykker
- plattform
- plato
- Platon Data Intelligence
- PlatonData
- Spille
- Point
- poeng
- positiv
- mulig
- Post
- potensiell
- makt
- krefter
- praksis
- trekkes
- presentere
- presentert
- forebygge
- pris
- prinsipper
- privatliv
- Personvern og sikkerhet
- prosess
- prosessering
- produsere
- produsert
- Produkter
- profesjonell
- dyp
- prosjekt
- prosjekter
- ledetekster
- bevis
- proof of concept
- ordentlig
- proprietær
- beviste
- gi
- forutsatt
- gir
- gi
- offentlig
- offentlige selskaper
- offentlig
- formål
- sette
- Q & A
- kvalitet
- spørsmål
- spørsmål
- raskt
- sitater
- Ranking
- heller
- RE
- klar
- virkelige verden
- realisert
- motta
- anbefales
- poster
- refererer
- regulert
- relasjoner
- forholdet
- relevant
- Rapporter
- representant
- representerer
- representerer
- krever
- påkrevd
- Krav
- ressurs
- respektert
- henseender
- svar
- svar
- begrense
- Resultater
- inntekter
- tilbake
- gjennomgå
- ikke sant
- risikoer
- Rolle
- roller
- rom
- runde
- regler
- Kjør
- går
- samme
- fornøyd
- fornøyd med
- Spar
- sier
- skalerbarhet
- Skala
- Vitenskap
- skraper
- sømløs
- sømløst
- Søk
- Sekund
- sekunder
- Seksjon
- sikre
- sikkerhet
- se
- utvalg
- selgere
- send
- senior
- forstand
- separat
- Serien
- server~~POS=TRUNC
- tjeneste
- Tjenester
- sett
- sett
- flere
- forme
- aksjonær
- aksjonærer
- hun
- bør
- viste
- vist
- Viser
- signifikant
- Enkelt
- enklere
- forenklet
- forenkle
- forenkle
- enkelt
- Størrelse
- størrelser
- mindre
- Smart
- smartere
- Software
- programvareutvikling
- løsning
- Solutions
- noen
- sofistikert
- kilde
- Kilder
- Spenning
- spenn
- Snakker
- spesialister
- spesialisert
- spesifikk
- spesielt
- Stabilitet
- stable
- Scene
- innsatser
- stå
- står
- Begynn
- startet
- Start
- Uttalelse
- opphold
- Trinn
- Steps
- lager
- aksjemarked
- lagret
- butikker
- rett fram
- Strategisk
- struktur
- strukturert
- I ettertid
- suksess
- vellykket
- slik
- tilstrekkelig
- egnet
- suite
- oppsummere
- SAMMENDRAG
- støtte
- Støtter
- overvåking
- Bytte om
- syntaks
- system
- bord
- skreddersydd
- Ta
- tatt
- tar
- ta
- Oppgave
- oppgaver
- lag
- tech
- Teknisk
- teknikker
- Teknologi
- telekom
- fortelle
- mal
- test
- Testing
- tester
- tekst
- enn
- Takk
- Det
- De
- Hovedstaden
- deres
- deretter
- Der.
- Disse
- de
- tenker
- denne
- tre
- Gjennom
- hele
- tid
- Tidsserier
- ganger
- titan
- til
- dagens
- sammen
- token
- tokens
- også
- verktøy
- verktøy
- Tema
- toronto
- mot
- Tog
- trent
- Kurs
- Transaksjonen
- Transaksjoner
- transformere
- tur
- sant
- Stol
- SVING
- to
- typen
- typer
- typisk
- ute av stand
- etter
- underliggende
- forstå
- forståelse
- forstår
- forstås
- unik
- opplåsing
- unødvendig
- us
- bruke
- bruk sak
- brukt
- Bruker
- brukervennlig
- ved hjelp av
- bruker
- gyldig
- validering
- verdi
- variasjon
- ulike
- leverandør
- Verifisering
- verifisert
- verifisere
- veldig
- levedyktig
- Se
- virtuelle
- syn
- gå
- ønsket
- var
- Vei..
- we
- web
- webtjenester
- Webinarer
- Nettsted
- VI VIL
- gikk
- var
- Vest
- Hva
- Hjul
- når
- mens
- hvilken
- mens
- vil
- med
- innenfor
- uten
- Dame
- ord
- Arbeid
- arbeidet
- arbeidsflyt
- arbeid
- verdt
- ville
- skrive
- skriv kode
- XML
- ennå
- york
- Du
- Din
- youtube
- zephyrnet