En dyptgående analyse av Retrieval-Augmented Generation i LLM

Forestillingen er at du er en analytiker, og du har tilgang til et stort språkmodell. Du er spennende på mulighetene det bringer til arbeidsflyten din. Men så spør du det om de siste aksjeprisene eller den nåværende inflasjonsraten, og det slår deg med:

“Jeg er dessverre ikke i stand til å gi informasjon om sanntid eller etter kutt-av dato. Min siste treningsdata er bare opp til januar 2022.”

Store språkmodeller, for all deres språklige kraft, mangler evnen til å forstå ‘nå‘. Og i en rask verden er ‘nå‘ alt.

Forskning har vist at store forhånds-trente språkmodeller (LLM) også er lagre av faktisk kunnskap.

De har blitt trenet på så mye data at de har absorbert mange fakta og tall. Når de finjusteres, kan de oppnå bemerkelsesverdige resultater på en rekke NLP-oppdrag.

Men her er fangen: deres evne til å få tilgang til og manipulere denne lagrede kunnskapen er, av og til, ikke perfekt. Spesielt når oppgaven er kunnskapsintensiv, kan disse modellene ligge bak mer spesialiserte arkitekturer. Det er som å ha en bibliotek med alle bøkene i verden, men ingen katalog for å finne det du trenger.

OpenAI’s ChatGPT Får en Browsing-oppgradering

OpenAI’s nylige annonsering om ChatGPT’s browsing-funksjon er et betydelig skritt i retning av Retrieval-Augmented Generation (RAG). Med ChatGPT nå i stand til å søke på internettet etter nåværende og autoritative informasjon, speiler det RAG-tilnærmingen til å dynamisk hente data fra eksterne kilder for å gi berikede svar.

https://twitter.com/OpenAI/status/1707077710047216095

Aktuelt tilgjengelig for Plus- og Bedriftsbrukere, planlegger OpenAI å rulle ut denne funksjonen til alle brukere snart. Brukere kan aktivere dette ved å velge ‘Browse with Bing’ under GPT-4-opsjonen.

Chatgpt Ny ‘Bing’ Browsing-funksjon

 Prompt Engineering er Effektivt, men Utilstrekkelig

Promptene tjener som inngangen til LLM’s kunnskap. De guider modellen og gir en retning for svaret. Men å lage en effektiv prompt er ikke den fullstendige løsningen for å få det du vil ha fra en LLM. Likevel, la oss gå gjennom noen gode praksis å vurdere når du skriver en prompt:

1. Klarhet: En godt definert prompt eliminerer tvetydighet. Den bør være rett frem, sikre at modellen forstår brukerens intensjon. Denne klarheten oversettes ofte til mer kohesive og relevante svar.
2. Kontekst: Spesielt for omfattende inndata, kan plasseringen av instruksjonen påvirke utdata. For eksempel kan flytting av instruksjonen til slutten av en lang prompt ofte gi bedre resultater.
3. Presisjon i Instruksjon: Kraften i spørsmålet, ofte overført gjennom “hvem, hva, hvor, når, hvorfor, hvordan”-rammeverket, kan guide modellen mot et mer fokusert svar. I tillegg kan spesifisering av ønsket utdataformat eller størrelse kan videre finjustere modellens utdata.
4. Håndtering av Usikkerhet: Det er essensielt å guide modellen på hvordan den skal svare når den er usikker. For eksempel, å instruere modellen til å svare med “Jeg vet ikke” når den er usikker, kan forhindre den fra å generere uriktige eller “hallusinerte” svar.
5. Steg-for-Steg Tenkning: For komplekse instruksjoner, å guide modellen til å tenke systematisk eller bryte oppgaven ned i underoppgaver, kan føre til mer omfattende og nøyaktige utdata.

I forbindelse med viktigheten av prompter i å guide ChatGPT, kan en omfattende artikkel finnes i en artikkel på Unite.ai.

Utfordringer i Generative AI-modeller

Prompt-engineering innebærer finjustering av direktivene gitt til din modell for å forbedre ytelsen. Det er en meget kostnadseffektiv måte å øke din Generative AI-applikasjons nøyaktighet, og krever bare mindre kodejusteringer. Mens prompt-engineering kan betydelig forbedre utdata, er det avgjørende å forstå de innebygde begrensningene i store språkmodeller (LLM). To primære utfordringer er hallusinasjoner og kunnskaps-avkutt.

• Hallusinasjoner: Dette refererer til tilfeller hvor modellen trygt returnerer et feil eller fabrikkert svar. Selv om avanserte LLM har innebygde mekanismer for å gjenkjenne og unngå slike utdata.

Hallusinasjoner i LLM

• Kunnskaps-avkutt: Hver LLM-modell har en trenings-slutt-dato, etter hvilken den er uvitende om hendelser eller utviklinger. Denne begrensningen betyr at modellens kunnskap er frosset ved trenings-slutt-datoen. For eksempel ville en modell trenet opp til 2022 ikke vite hendelsene i 2023.

Kunnskaps-avkutt i LLM

Retrieval-augmentert generering (RAG) tilbyr en løsning på disse utfordringene. Den lar modellene få tilgang til eksterne informasjon, og mildner problemene med hallusinasjoner ved å gi tilgang til proprietær eller domenespesifikk data. For kunnskaps-avkutt kan RAG få tilgang til nåværende informasjon utenfor modellens treningsdato, og sikre at utdata er oppdatert.

Det lar også LLM trekke inn data fra forskjellige eksterne kilder i sanntid. Dette kan være kunnskapsbaserte databaser eller hele internettets omfang.

Innledning til Retrieval-Augmented Generation

Retrieval-augmentert generering (RAG) er et rammeverk, snarere enn en spesifikk teknologi, som muliggjør at store språkmodeller kan trekke på data de ikke ble trenet på. Det finnes flere måter å implementere RAG på, og det beste valget avhenger av den spesifikke oppgaven og datans natur.

RAG-rammeverket opererer på en strukturert måte:

Prompt Inndata

Prosessene begynner med en brukers inndata eller prompt. Dette kan være et spørsmål eller en uttalelse som søker spesifik informasjon.

Retrieval fra Eksterne Kilder

I stedet for å generere et svar direkte basert på sin treningsdata, søker modellen, med hjelp av en retriever-komponent, gjennom eksterne datakilder. Disse kildene kan variere fra kunnskapsbaserte databaser til internett-tilgjengelige data.

Forståelse av Retrieval

I essensen speiler retrieval en søkeoperasjon. Det handler om å trekke ut den mest pertinente informasjonen i respons til en brukers inndata. Denne prosessen kan deles inn i to stadier:

1. Indexering: Dette er uten tvil den mest utfordrende delen av hele RAG-reisen. Indexeringsprosessen kan bredt deles inn i to faser: Lasting og Splitting. I verktøy som LangChain, kalles disse prosessene “loaders” og “splitters“. Loaders henter innhold fra forskjellige kilder, enten det er nettsider eller PDF-filer. Når innholdet er hentet, splitter splittene dette innholdet i små, optimerte biter for innlejring og søk.
2. Spørring: Dette er handlingen å trekke ut de mest relevante kunnskapsfragmenter basert på et søkeord.

Mens det finnes mange måter å nærme seg retrieval på, fra enkel tekst-matching til å bruke søkemotorer som Google (GOOGL ), moderne Retrieval-Augmented Generation (RAG)-systemer avhenger av semantisk søk. I hjertet av semantisk søk ligger konseptet om innlejring.

Innlejring er sentral for hvordan store språkmodeller (LLM) forstår språk. Når mennesker prøver å forklare hvordan de trekker mening fra ord, sirkler forklaringen ofte tilbake til innebygd forståelse. Dypt inne i vår kognitive struktur, gjenkjenner vi at “barn” og “unge” er synonyme, eller at “rød” og “grønn” begge betegner farger.

Augmentering av Prompten

Den hentede informasjonen kombineres deretter med den opprinnelige prompten, og skaper en augmentert eller utvidet prompt. Denne augmenterte prompten gir modellen ekstra kontekst, som er spesielt verdifull hvis data er domenespesifikk eller ikke en del av modellens opprinnelige treningskorpus.

Generering av Fullføringen

Med den augmenterte prompten i hånden, genererer modellen deretter en fullføring eller respons. Denne responsen er ikke bare basert på modellens treningsdata, men er også informert av sanntidsdata hentet.

Retrieval-Augmented Generation

Arkitektur av den Første RAG LLM

Forskningsartikkelen av Meta publisert i 2020 “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” gir en dyptgående analyse av denne teknikken. Retrieval-Augmented Generation-modellen utvider den tradisjonelle genereringsprosessen med en ekstern søke-mekanisme. Dette lar modellen trekke relevante informasjon fra store datamengder, og forbedrer evnen til å generere kontekstuelt nøyaktige svar.

Her er hvordan det fungerer:

1. Parametrisk Minne: Dette er din tradisjonelle språkmodell, som en seq2seq-modell. Den har blitt trenet på store mengder data og vet mye.
2. Ikke-Parametrisk Minne: Tenk på dette som en søkemotor. Det er et tett vektor-indeks av, for eksempel, Wikipedia, som kan aksesseres ved hjelp av en neural retriever.

Når disse to kombineres, skaper de en nøyaktig modell. RAG-modellen søker først etter relevante informasjon fra sitt ikke-parametriske minne, og deretter bruker det sin parametriske kunnskap til å gi et kohesivt svar.

Original RAG Model By Meta

1. To-Trinns Prosess:

RAG LLM opererer i en to-trinns prosess:

• Retrieval: Modellen søker først etter relevante dokumenter eller passasjer fra en stor datamengde. Dette gjøres ved hjelp av en tett søke-mekanisme, som bruker innlejring til å representere både spørringen og dokumentene. Innlejringene brukes deretter til å beregne likhetspoeng, og de topp-rangerte dokumentene hentes.
• Generering: Med de topp-k relevante dokumentene i hånden, kanaleres de deretter inn i en sekvens-til-sekvens generator sammen med den opprinnelige spørringen. Denne generatoren skaper deretter det endelige utdata, og trekker kontekst fra både spørringen og de hentede dokumentene.

2. Tett Søk:

Tradisjonelle søke-systemer avhenger ofte av sparse representasjoner som TF-IDF. RAG LLM bruker imidlertid tette representasjoner, hvor både spørringen og dokumentene innlejres i kontinuerlige vektor-rom. Dette lar for mer nyanserte likhets-sammenligninger, og fanger semantiske relasjoner utover bare nøkkelord-matching.

3. Sekvens-til-Sekvens Generering:

De hentede dokumentene fungerer som en utvidet kontekst for genereringsmodellen. Denne modellen, ofte basert på arkitekturer som Transformers, genererer deretter det endelige utdata, og sikrer at det er kohesivt og kontekstuelt relevant.

Dokument Søk

Dokument Indexering og Søk

For effektiv informasjonssøk, spesielt fra store dokumenter, lagres data ofte i en vektor-database. Hver del av data eller dokument indexeres basert på en innlejring-vektor, som fanger den semantiske essensen av innholdet. Effektiv indexering sikrer rask henting av relevante informasjon basert på inndata-prompten.

VEktor-Databaser

Kilde: Redis

VEktor-databaser, noen ganger kalt vektor-lagring, er spesialiserte databaser som er dyktige til å lagre og hente vektor-data. I området AI og datavitenskap, er vektorer essensielt lister av tall som symboliserer punkter i et multi-dimensjonalt rom. I motsetning til tradisjonelle databaser, som er mer tilpasset tabell-formet data, skinner vektor-databaser i å håndtere data som naturlig passer en vektor-format, som innlejring fra AI-modeller.

Noen bemerkelsesverdige vektor-databaser inkluderer Annoy, Faiss av Meta, Milvus, og Pinecone. Disse databasene er avgjørende i AI-applikasjoner, og hjelper med oppgaver som anbefalings-systemer til bilde-søk. Plattformer som AWS tilbyr også tjenester tilpasset vektor-database-behov, som Amazon (AMZN ) OpenSearch Service og Amazon RDS for PostgreSQL. Disse tjenestene er optimert for bestemte brukstilfeller, og sikrer effektiv indexering og søk.

Chunking for Relevans

Gitt at mange dokumenter kan være omfattende, brukes en teknikk kalt “chunking” ofte. Dette innebærer å bryte ned store dokumenter i mindre, semantisk kohesive biter. Disse bitene indexeres og hentes deretter etter behov, og sikrer at de mest relevante delene av et dokument brukes til prompt-forbedring.

Kontekst-Vindu-Overveielser

Hver LLM opererer innenfor et kontekst-vindu, som essensielt er den maksimale mengden informasjon det kan betrakte på en gang. Hvis eksterne datakilder gir informasjon som overstiger dette vinduet, må det brytes ned i mindre biter som passer innenfor modellens kontekst-vindu.

Fordelene med å Bruke Retrieval-Augmented Generation

1. Forbedret Nøyaktighet: Ved å utnytte eksterne datakilder, kan RAG LLM generere svar som ikke bare er basert på sin treningsdata, men også informert av de mest relevante og oppdaterte informasjonene tilgjengelige i søke-korpuset.
2. Overvinning av Kunnskaps-Gap: RAG løser effektivt de innebygde kunnskaps-begrensningene i LLM, enten det skyldes modellens trenings-avkutt eller fravær av domene-spesifikk data i trenings-korpuset.
3. Flaksibilitet: RAG kan integreres med forskjellige eksterne datakilder, fra proprietære databaser innen en organisasjon til offentlig tilgjengelige internett-data. Dette gjør det tilpasset en rekke applikasjoner og industrier.
4. Redusert Hallusinasjon: En av utfordringene med LLM er muligheten for “hallusinasjoner” eller generering av faktisk uriktige eller fabrikkerte informasjon. Ved å gi sanntids-data-kontekst, kan RAG betydelig redusere sjansen for slike utdata.
5. Skalabilitet: En av de primære fordelene med RAG LLM er dens evne til å skaleres. Ved å skille søk- og genererings-prosessene, kan modellen effektivt håndtere store datamengder, og gjør det egnet for virkelige applikasjoner hvor data er overveldende.

Utfordringer og Overveielser

• Regnskapsmessig Overhead: To-trinns prosessen kan være regnskapsmessig intensiv, spesielt når det handler om store datamengder.
• Data-Avhengighet: Kvaliteten på de hentede dokumentene har direkte innvirkning på genererings-kvaliteten. Derfor er det avgjørende å ha en omfattende og godt kuratert søke-korpus.

Konklusjon

Ved å integrere søk- og genererings-prosesser, tilbyr Retrieval-Augmented Generation en robust løsning på kunnskaps-intensivt oppgaver, og sikrer utdata som er både informert og kontekstuelt relevante.

Det virkelige løftet i RAG ligger i dens potensielle virkelige applikasjoner. For sektorer som helse, hvor tidlig og nøyaktig informasjon kan være avgjørende, tilbyr RAG evnen til å trekke ut og generere innsikt fra store medisinske litteratur samtidig. I finans-verden, hvor markedene utvikler seg fra minutt til minutt, kan RAG gi sanntids-data-drevne innsikt, og hjelpe til informert beslutning. Videre, i akademiske og forsknings-miljøer, kan forskere utnytte RAG til å søke gjennom store informasjons-repositorier, og gjøre litteratur-gjennomgang og data-analyse mer effektivt.