AI-modeller og platforme
En dybdeindgang i Retrieval-Augmented Generation i LLM
Forestil dig, at du er en analytiker, og du har adgang til et stort sprogmodel. Du er begejstret for de muligheder, det bringer til din arbejdsproces. Men så spørger du det om de seneste aktiekurser eller den nuværende inflationsrate, og det rammer dig med:
“Undskyld, men jeg kan ikke give realtids- eller post-cutoff-data. Mit sidste træningsdata er kun op til januar 2022.”
Stort sprogmodel, for alt deres lingvistiske kraft, manglede evnen til at forstå ‘nu‘. Og i en hurtig verden er ‘nu‘ alt.
Forskning har vist, at store fortrænede sprogmodeller (LLM) også er lagre af faktuel viden.
De er blevet trænet på så meget data, at de har absorberet en masse fakta og tal. Når de er finjusteret, kan de opnå bemærkelsesværdige resultater på en række NLP-opgaver.
Men her er fælden: deres evne til at få adgang til og manipulere denne gemte viden er, på visse tidspunkter, ikke perfekt. Især når opgaven er viden-intensiv, kan disse modeller være langsomme i forhold til mere specialiserede arkitekturer. Det er som at have en bibliotek med alle bøger i verden, men ingen katalog til at finde, hvad du søger.
OpenAI’s ChatGPT får en browsing-opgradering
OpenAI’s seneste meddelelse om ChatGPT’s browsing-funktion er et betydeligt skridt i retning af Retrieval-Augmented Generation (RAG). Med ChatGPT, der nu kan gennemsøge internettet for aktuel og autoritativ information, spejler det RAG-tilgangen til dynamisk at hente data fra eksterne kilder for at give berigede svar.
https://twitter.com/OpenAI/status/1707077710047216095
Denne funktion er i øjeblikket kun tilgængelig for Plus- og Enterprise-brugere, men OpenAI planlægger at rulle den ud til alle brugere snart. Brugere kan aktivere denne funktion ved at vælge ‘Browse med Bing’ under GPT-4-indstillingen.
Prompt engineering er effektiv, men utilstrækkelig
Prompt’er fungerer som porten til LLM’s viden. De guider modellen og giver den en retning for svaret. Men at skabe en effektiv prompt er ikke den fuldstændige løsning for at få, hvad du vil have fra en LLM. Lad os alligevel gå igennem nogle gode praksis at overveje, når du skriver en prompt:
- Klarhed: En veldefineret prompt eliminerer tvetydighed. Den skal være ligetil, så modellen forstår brugerens intention. Denne klarhed oversætter ofte til mere sammenhængende og relevante svar.
- Kontekst: Især for omfattende input kan placeringen af instruktionen påvirke output. For eksempel kan flytning af instruktionen til slutningen af en lang prompt ofte give bedre resultater.
- Præcision i instruktion: Kraften af spørgsmålet, ofte formidlet gennem “hvem, hvad, hvor, hvornår, hvorfor, hvordan”-rammen, kan guide modellen mod et mere fokuseret svar. Desuden kan specificering af det ønskede output-format eller størrelse yderligere forfine modellens output.
- Håndtering af usikkerhed: Det er vigtigt at guide modellen på, hvordan den skal svare, når den er usikker. For eksempel kan instruktion om at svare med “Jeg ved ikke”, når den er usikker, forhindre den i at generere ukorrekte eller “hallucinerede” svar.
- Trin-for-trin-tænkning: For komplekse instruktioner kan guidning af modellen til at tænke systematisk eller opdeling af opgaven i underopgaver kan føre til mere omfattende og præcise output.
I forbindelse med prompt’ernes betydning i guidning af ChatGPT kan en omfattende artikel findes i en artikel på Unite.ai.
Udfordringer i Generative AI-modeller
Prompt engineering indebærer finjustering af direktiverne givet til din model for at forbedre dens præstation. Det er en meget omkostningseffektiv måde at forbedre Generative AI-applikationens nøjagtighed, da det kun kræver mindre kodejusteringer. Mens prompt engineering kan betydeligt forbedre output, er det vigtigt at forstå de indbyggede begrænsninger af store sprogmodeller (LLM). To primære udfordringer er hallucinationer og viden-afkortninger.
- Hallucinationer: Dette refererer til tilfælde, hvor modellen selvbevidst returnerer et forkert eller fabrikeret svar. Selvom avancerede LLM har indbyggede mekanismer til at genkende og undgå sådanne output, kan det stadig ske.
- VIDEN-afkortninger: Hvert LLM-model har en træningsafslutningsdato, efter hvilken det er uvidende om begivenheder eller udviklinger. Dette begrænsning betyder, at modellens viden er frosset på tidspunktet for dens sidste træningsdato. For eksempel ville en model trænet op til 2022 ikke kende til begivenhederne i 2023.
Retrieval-augmenteret generation (RAG) tilbyder en løsning på disse udfordringer. Det giver mulighed for modeller at få adgang til eksterne oplysninger, hvilket kan mindske hallucinationer ved at give adgang til proprietære eller domænespecifikke data. For viden-afkortninger kan RAG få adgang til aktuel information ud over modellens træningsdato, hvilket sikrer, at output er opdateret.
Det giver også mulighed for LLM at trække data fra forskellige eksterne kilder i realtid. Dette kan være videnbasen, databaser eller selv det store internettet.
Introduktion til Retrieval-Augmented Generation
Retrieval-augmenteret generation (RAG) er en ramme, snarere end en specifik teknologi, der giver store sprogmodeller mulighed for at få adgang til data, de ikke er trænet på. Der er flere måder at implementere RAG på, og den bedste løsning afhænger af din specifikke opgave og datans natur.
RAG-rammen fungerer på en struktureret måde:
Prompt Input
Processen begynder med en brugers input eller prompt. Dette kan være et spørgsmål eller en udtalelse, der søger specifik information.
Retrieval fra eksterne kilder
I stedet for at generere et svar direkte baseret på sin træning, søger modellen, med hjælp af en retriever-komponent, gennem eksterne datakilder. Disse kilder kan variere fra videnbasen, databaser og dokumentlager til internettilgængelige data.
Forståelse af retrieval
I sin kerne spejler retrieval en søgeoperation. Det handler om at trække det mest pertinente information i forhold til en brugers input. Denne proces kan deles op i to faser:
- Indexering: Det er uden tvivl den mest udfordrende del af hele RAG-rejsen, nemlig at indexere din videnbase. Indexeringsprocessen kan bredt deles op i to faser: Loading og Splitting. I værktøjer som LangChain kaldes disse processer “loadere” og “splitters“. Loadere henter indhold fra forskellige kilder, enten det er websteder eller PDF’er. Når det er hentet, splitter splitters derefter dette indhold op i små, bidende stykker, der optimeres til indlejring og søgning.
- Querying: Dette er handlingen af at trække de mest relevante videnfragmenter baseret på en søgeord.
Selvom der er mange måder at tilgå retrieval på, fra simpel tekstmatchning til brug af søgemaskiner som Google , moderne Retrieval-Augmented Generation (RAG)-systemer afhænger af semantisk søgning. I hjertet af semantisk søgning ligger begrebet om indlejring.
Indlejring er central for, hvordan store sprogmodeller (LLM) forstår sprog. Når mennesker forsøger at artikulere, hvordan de får mening fra ord, cirkler forklaringen ofte tilbage til indre forståelse. Dybt inde i vores kognitive strukturer erkender vi, at “barn” og “unge” er synonyme, eller at “rød” og “grøn” begge betegner farver.
Augmentering af prompt
Den hentede information kombineres derefter med den oprindelige prompt, hvilket skaber en augmenteret eller udvidet prompt. Denne augmenterede prompt giver modellen yderligere kontekst, hvilket er særlig værdifuldt, hvis data er domænespecifik eller ikke en del af modellens oprindelige træningskorpus.
Generering af afslutning
Med den augmenterede prompt i hånden genererer modellen derefter en afslutning eller svar. Dette svar er ikke kun baseret på modellens træning, men også informeret af den realtidsdata, der er hentet.
Arkitektur af den første RAG LLM
Forskningsartiklen af Meta udgivet i 2020 “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” giver en dybdegående indsigt i denne teknik. Retrieval-Augmented Generation-modellen udvider den traditionelle generationsproces med en ekstern søge- eller hentemekanisme. Dette giver modellen mulighed for at trække relevante oplysninger fra store datamængder, hvilket forbedrer dens evne til at generere kontekstligt præcise svar.
Her er, hvordan det fungerer:
- Parametrisk hukommelse: Dette er dit traditionelle sprogmodel, som en seq2seq-model. Det er blevet trænet på store mængder data og ved meget.
- Ikke-parametrisk hukommelse: Tænk på dette som en søgemaskine. Det er en tæt vektorindeks af, sagen, Wikipedia, som kan tilgås ved hjælp af en neural henter.
Når disse to kombineres, skaber de en præcis model. RAG-modellen henter først relevante oplysninger fra sin ikke-parametriske hukommelse og bruger derefter sin parametrisk viden til at give et sammenhængende svar.
1. To-trinsproces:
RAG LLM fungerer i en to-trinsproces:
- Henting: Modellen søger først efter relevante dokumenter eller passager fra en stor datamængde. Dette gøres ved hjælp af en tæt hentemekanisme, der anvender indlejring til at repræsentere både søgningen og dokumenterne. Indlejringerne anvendes derefter til at beregne ligningskorer, og de top-rangerede dokumenter hentes.
- Generation: Med de top-k relevante dokumenter i hånden kanaliseres de derefter til en sekvens-til-sekvens-generator sammen med den oprindelige søgning. Denne generator skaber derefter det endelige output, der trækker kontekst fra både søgningen og de hentede dokumenter.
2. Tæt henting:
Traditionelle hentningssystemer afhænger ofte af sparske repræsentationer som TF-IDF. RAG LLM anvender dog tætte repræsentationer, hvor både søgningen og dokumenterne indlejres i kontinuerte vektorrum. Dette giver mulighed for mere nuancerede ligningskomparationer, der fanger semantiske relationer ud over blot nøgleordsmatchning.
3. Sekvens-til-sekvens-generation:
De hentede dokumenter fungerer som en udvidet kontekst for generationsmodellen. Denne model, ofte baseret på arkitekturer som Transformers, genererer derefter det endelige output, sikrer, at det er sammenhængende og kontekstligt relevant.
Dokumentsøgning
Dokumentindexering og henting
For effektiv informationshenting, især fra store dokumenter, gemmes data ofte i en vektor-database. Hver data eller dokument indekseres baseret på en indlejring, der fanger den semantiske essens af indholdet. Effektiv indeksering sikrer hurtig henting af relevante oplysninger baseret på brugerens input.
VEKTOR-databaser

Kilde: Redis
VEKTOR-databaser, undertiden kaldet vektor-lagring, er specialiserede databaser, der er dygtige til at gemme og hente vektor-data. I området af AI og datalogi er vektorer essentiellement lister af tal, der repræsenterer punkter i et multi-dimensionelt rum. I modsætning til traditionelle databaser, der er mere tilpasset tabel-data, skinner vektor-databaser i håndtering af data, der naturligt passer en vektor-format, som indlejring fra AI-modeller.
Nogle bemærkelsesværdige vektor-databaser inkluderer Annoy, Faiss af Meta, Milvus og Pinecone. Disse databaser er afgørende i AI-applikationer, der hjælper med opgaver fra anbefalingssystemer til billedsøgning. Platforme som AWS tilbyder også tjenester tilpasset vektor-database-behov, som Amazon OpenSearch Service og Amazon RDS for PostgreSQL. Disse tjenester er optimeret til bestemte brugsområder, hvilket sikrer effektiv indeksering og søgning.
Chunking for relevans
Givet, at mange dokumenter kan være omfattende, anvendes en teknik kaldet “chunking” ofte. Dette indebærer at opdele store dokumenter i mindre, semantisk sammenhængende stykker. Disse stykker indekseres og hentes derefter efter behov, hvilket sikrer, at de mest relevante dele af et dokument anvendes til prompt-augmentering.
Kontekstvindue-overvejelser
Hvert LLM fungerer inden for et kontekstvindue, der essentiellement er den maksimale mængde information, det kan overveje på én gang. Hvis eksterne datakilder giver information, der overstiger dette vindue, skal det opdeles i mindre stykker, der passer inden for modellens kontekstvindue.
Fordele ved at anvende Retrieval-Augmented Generation
- Forbedret nøjagtighed: Ved at anvende eksterne datakilder kan RAG LLM generere svar, der ikke kun er baseret på dens træningsdata, men også informeret af de mest relevante og opdaterede oplysninger tilgængelige i hentningskorpus.
- Overvindelse af viden-lukker: RAG løser effektivt de indbyggede videnbegrænsninger af LLM, enten det skyldes modellens træningsafkortning eller manglen på domænespecifik data i dens træningskorpus.
- Flxibilitet: RAG kan integreres med forskellige eksterne datakilder, fra interne databasesystemer til offentligt tilgængelige internettet-data. Dette gør det tilpasningsdygtigt til en bred vifte af applikationer og brancher.
- Reduktion af hallucinationer: En af udfordringerne med LLM er muligheden for “hallucinationer” eller generation af faktisk forkert eller fabrikeret information. Ved at give realtidskontekst kan RAG betydeligt reducere chancerne for sådanne output.
- Skalbarhed: En af de primære fordele ved RAG LLM er dens evne til at skale. Ved at separere hentnings- og generationsprocesser kan modellen effektivt håndtere store datamængder, hvilket gør den egnet til virkelige applikationer, hvor data er overflod.
Udfordringer og overvejelser
- Computations-overhead: To-trinsprocessen kan være computations-intensiv, især når der håndteres store datamængder.
- Data-afhængighed: Kvaliteten af de hentede dokumenter har direkte indvirkning på generationskvaliteten. Derfor er det afgørende at have en omfattende og velunderholdt hentningskorpus.
Konklusion
Ved at integrere hentnings- og generationsprocesser tilbyder Retrieval-Augmented Generation en robust løsning på viden-intensivt arbejde, sikrer output, der er både informeret og kontekstligt relevant.
Det virkelige løfte i RAG ligger i dets potentiale for virkelige applikationer. For sektorer som sundhedspleje, hvor tidlige og præcise oplysninger kan være afgørende, tilbyder RAG mulighed for at trække og generere indsigt fra store medicinske litteratur uden besvær. I finansverdenen, hvor markeder udvikler sig fra minut til minut, kan RAG give realtidsdata-drevne indsigt, hvilket hjælper med at træffe informerede beslutninger. Desuden kan forskere og studerende anvende RAG til at gennemsøge store informationslager, hvilket gør litteraturgennemgang og dataanalyse mere effektiv.

















