Utöka en stor språkmodell med hämtningsförhöjd generation och finjustering

Artiklarna i den här serien beskriver de kunskapshämtningsmodeller som LLMs använder för att generera sina svar. Som standard har en stor språkmodell (LLM) endast åtkomst till sina träningsdata. Du kan dock utöka modellen så att den omfattar realtidsdata eller privata data. I den här artikeln beskrivs en av två mekanismer för att utöka en modell.

Den första mekanismen är RAG (Retrieval-Augmented Generation), som är en form av förbearbetning som kombinerar semantisk sökning med kontextuell priming (beskrivs i en annan artikel).

Den andra mekanismen är finjustering, som refererar till processen för vidareutbildning av modellen på en specifik datamängd efter den inledande, breda träningen, med målet att anpassa den för att prestera bättre på uppgifter eller förstå begrepp relaterade till den datamängden. Den här processen hjälper modellen att specialisera sig eller förbättra dess noggrannhet och effektivitet vid hantering av vissa typer av indata eller domäner.

I följande avsnitt beskrivs dessa två mekanismer mer detaljerat.

Förstå RAG

RAG används ofta för att aktivera scenariot "chatta över mina data", där företag som har en stor mängd textinnehåll (interna dokument, dokumentation osv.) och vill använda denna corpus som grund för svar på användarfrågor.

På hög nivå skapar du en databaspost för varje dokument (eller en del av ett dokument som kallas "segment"). Segmentet indexeras på dess inbäddning, en vektor (matris) med tal som representerar fasetter i dokumentet. När en användare skickar en fråga söker du i databasen efter liknande dokument och skickar sedan frågan och dokumenten till LLM för att skapa ett svar.

Kommentar

Termen Hämtningsförhöjd generation (RAG) ackommodativt. Processen för att implementera ett RAG-baserat chattsystem som beskrivs i den här artikeln kan tillämpas oavsett om det finns en önskan att använda externa data som ska användas i en stödjande kapacitet (RAG) eller användas som mittpunkt i svaret (RCG). Den här nyanserade distinktionen behandlas inte i de flesta läsningar relaterade till RAG.

Skapa ett index över vektoriserade dokument

Det första steget för att skapa ett RAG-baserat chattsystem är att skapa ett vektordatalager som innehåller vektorinbäddningen av dokumentet (eller en del av dokumentet). Tänk på följande diagram som beskriver de grundläggande stegen för att skapa ett vektoriserat dokumentindex.

Det här diagrammet representerar en datapipeline som ansvarar för inmatning, bearbetning och hantering av data som används av systemet. Detta omfattar förbearbetning av data som ska lagras i vektordatabasen och säkerställa att data som matas in i LLM är i rätt format.

Hela processen drivs av begreppet inbäddning, vilket är en numerisk representation av data (vanligtvis ord, fraser, meningar eller till och med hela dokument) som fångar in indatas semantiska egenskaper på ett sätt som kan bearbetas av maskininlärningsmodeller.

Om du vill skapa en inbäddning skickar du innehållssegmentet (meningar, stycken eller hela dokument) till Inbäddnings-API:et för Azure OpenAI. Det som returneras från API:et för inbäddning är en vektor. Varje värde i vektorn representerar en viss egenskap (dimension) av innehållet. Dimensioner kan vara ämnesämne, semantisk betydelse, syntax och grammatik, ord- och frasanvändning, kontextuella relationer, stil och ton osv. Tillsammans representerar alla värden i vektorn innehållets dimensionella utrymme. Med andra ord, om du kan tänka dig en 3D-representation av en vektor med tre värden, lever en viss vektor i ett visst område i x-, y-z-planet. Vad händer om du har 1 000 (eller fler) värden? Även om det inte är möjligt för människor att rita ett diagram med 1 000 dimensioner på ett pappersark för att göra det mer förståeligt, har datorer inga problem med att förstå den graden av dimensionsutrymme.

Nästa steg i diagrammet visar lagring av vektorn tillsammans med själva innehållet (eller en pekare till innehållets plats) och andra metadata i en vektordatabas. En vektordatabas är som vilken typ av databas som helst, med två skillnader:

• Vektordatabaser använder en vektor som ett index för att söka efter data.
• Vektordatabaser implementerar en algoritm som kallas cosiné liknande sökning, även kallad närmaste granne, som använder vektorer som bäst matchar sökvillkoren.

Med corpus av dokument som lagras i en vektordatabas kan utvecklare skapa en retrieverkomponent som hämtar dokument som matchar användarens fråga från databasen för att tillhandahålla LLM med vad den behöver för att besvara användarens fråga.

Besvara frågor med dina dokument

Ett RAG-system använder först semantisk sökning för att hitta artiklar som kan vara till hjälp för LLM när du skapar ett svar. Nästa steg är att skicka matchande artiklar tillsammans med användarens ursprungliga uppmaning till LLM för att skriva ett svar.

Tänk på följande diagram som en enkel RAG-implementering (kallas ibland för "naiv RAG").

I diagrammet skickar en användare en fråga. Det första steget är att skapa en inbäddning för användarens uppmaning att hämta tillbaka en vektor. Nästa steg är att söka i vektordatabasen efter de dokument (eller delar av dokument) som är en "närmaste granne"-matchning.

Cosininlikitet är ett mått som används för att avgöra hur lika två vektorer är, vilket i huvudsak utvärderar cosinin i vinkeln mellan dem. En cosininlikitet nära 1 indikerar en hög grad av likhet (liten vinkel), medan en likhet nära -1 indikerar olikhet (vinkel närmar sig 180 grader). Det här måttet är avgörande för uppgifter som dokumentlikhet, där målet är att hitta dokument med liknande innehåll eller betydelse.

"Närmaste granne"-algoritmer fungerar genom att hitta närmaste vektorer (grannar) till en viss punkt i vektorutrymmet. I algoritmen k-nearest neighbors (KNN) refererar "k" till antalet närmaste grannar att överväga. Den här metoden används ofta i klassificering och regression, där algoritmen förutsäger etiketten för en ny datapunkt baserat på majoritetsetiketten för dess "k" närmaste grannar i träningsuppsättningen. KNN- och cosininelikhet används ofta tillsammans i system som rekommendationsmotorer, där målet är att hitta objekt som mest liknar en användares inställningar, som representeras som vektorer i inbäddningsutrymmet.

Du tar det bästa resultatet från sökningen och skickar det matchande innehållet tillsammans med användarens uppmaning att generera ett svar som (förhoppningsvis) informeras genom matchande innehåll.

Utmaningar och överväganden

Implementeringen av ett RAG-system medför sina utmaningar. Datasekretess är av största vikt eftersom systemet måste hantera användardata på ett ansvarsfullt sätt, särskilt vid hämtning och bearbetning av information från externa källor. Beräkningskrav kan också vara betydande eftersom både hämtnings- och generativa processer är resursintensiva. Att säkerställa noggrannheten och relevansen av svar vid hantering av fördomar som finns i data eller modellen är ett annat viktigt övervägande. Utvecklare måste navigera i dessa utmaningar noggrant för att skapa effektiva, etiska och värdefulla RAG-system.

Nästa artikel i den här serien, Building advanced Retrieval-Augmented Generation systems (Skapa avancerade system för hämtningsförhöjd generation) innehåller mer information om hur du skapar data- och slutsatsdragningspipelines för att aktivera ett produktionsklart RAG-system.

Om du vill börja experimentera med att skapa en generativ AI-lösning omedelbart rekommenderar vi att du tar en titt på Kom igång med chatten med ditt eget dataexempel för Python. Det finns även versioner av självstudien i .NET, Java och JavaScript.

Finjustera en modell

Finjustering i samband med en LLM syftar på processen att justera modellens parametrar på en domänspecifik datamängd efter att först ha tränats på en stor, varierad datauppsättning.

LLM:er tränas (förtränade) på en bred datauppsättning, greppar språkstruktur, kontext och en mängd olika kunskaper. I det här steget ingår att lära sig allmänna språkmönster. Finjustering lägger till mer träning till den förtränad modellen baserat på en mindre, specifik datauppsättning. Den här sekundära utbildningsfasen syftar till att anpassa modellen för att prestera bättre på vissa uppgifter eller förstå specifika domäner, vilket förbättrar dess noggrannhet och relevans för dessa specialiserade program. Vid finjustering justeras modellens vikter för att bättre förutsäga eller förstå nyanserna i den här mindre datamängden.

Några saker att tänka på:

• Specialisering: Finjustering skräddarsyr modellen efter specifika uppgifter, till exempel juridisk dokumentanalys, medicinsk texttolkning eller kundtjänstinteraktioner. Detta gör modellen mer effektiv inom dessa områden.
• Effektivitet: Det är mer effektivt att finjustera en förtränad modell för en specifik uppgift än att träna en modell från grunden, eftersom finjustering kräver mindre data och beräkningsresurser.
• Anpassningsbarhet: Finjustering möjliggör anpassning till nya uppgifter eller domäner som inte ingick i de ursprungliga träningsdata, vilket gör LLMs mångsidiga verktyg för olika program.
• Förbättrad prestanda: För uppgifter som skiljer sig från de data som modellen ursprungligen tränades på kan finjustering leda till bättre prestanda eftersom modellen justeras för att förstå det specifika språket, formatet eller terminologin som används i den nya domänen.
• Anpassning: I vissa program kan finjustering hjälpa till att anpassa modellens svar eller förutsägelser så att de passar specifika behov eller inställningar för en användare eller organisation. Finjustering har dock vissa nackdelar och begränsningar. Att förstå dessa kan hjälpa dig att bestämma när du ska välja finjustering jämfört med alternativ som hämtningsförhöjd generation (RAG).
• Datakrav: Finjustering kräver en tillräckligt stor och högkvalitativ datauppsättning som är specifik för måluppgiften eller domänen. Att samla in och kurera den här datamängden kan vara utmanande och resurskrävande.
• Överanpassningsrisk: Det finns en risk för överanpassning, särskilt med en liten datauppsättning. Överanpassning gör att modellen fungerar bra på träningsdata men dåligt på nya, osynliga data, vilket minskar dess generaliserbarhet.
• Kostnad och resurser: Även om det är mindre resurskrävande än att träna från grunden kräver finjustering fortfarande beräkningsresurser, särskilt för stora modeller och datauppsättningar, vilket kan vara oöverkomligt för vissa användare eller projekt.
• Underhåll och uppdatering: Finjusterade modeller kan behöva regelbundna uppdateringar för att förbli effektiva när den domänspecifika informationen ändras över tid. Det här pågående underhållet kräver extra resurser och data.
• Modellavvikelse: Eftersom modellen är finjusterad för specifika uppgifter kan den förlora en del av sin allmänna språkförstålelse och mångsidighet, vilket leder till ett fenomen som kallas modellavvikelse.

Anpassning av en modell med finjustering förklarar hur du finjusterar en modell. På hög nivå tillhandahåller du en JSON-datauppsättning med potentiella frågor och önskade svar. Dokumentationen tyder på att det finns märkbara förbättringar genom att tillhandahålla 50 till 100 fråge-/svarspar, men rätt antal varierar kraftigt i användningsfallet.

Finjustering jämfört med hämtningsförhöjd generering

På ytan kan det verka som om det finns en hel del överlappning mellan finjustering och hämtningsförhöjd generation. Valet mellan finjustering och hämtningsförhöjd generation beror på de specifika kraven för din uppgift, inklusive prestandaförväntningar, resurstillgänglighet och behovet av domänspecifikhet kontra generaliserbarhet.

När du ska föredra finjustering framför hämtningsförhöjd generation:

• Aktivitetsspecifik prestanda – Finjustering är att föredra när höga prestanda för en viss aktivitet är kritisk och det finns tillräckligt med domänspecifika data för att träna modellen effektivt utan betydande överanpassningsrisker.
• Kontroll över data – Om du har proprietära eller högspecialiserade data som skiljer sig avsevärt från de data som basmodellen tränades på kan du med finjustering införliva den här unika kunskapen i modellen.
• Begränsat behov av realtidsuppdateringar – Om uppgiften inte kräver att modellen ständigt uppdateras med den senaste informationen kan finjustering vara effektivare eftersom RAG-modeller vanligtvis behöver åtkomst till uppdaterade externa databaser eller Internet för att hämta senaste data.

När du ska föredra Hämtningsförhöjd generation framför finjustering:

• Dynamiskt eller utvecklande innehåll – RAG passar bättre för uppgifter där det är viktigt att ha den senaste informationen. Eftersom RAG-modeller kan hämta data från externa källor i realtid passar de bättre för program som nyhetsgenerering eller svar på frågor om de senaste händelserna.
• Generalisering över specialisering – Om målet är att upprätthålla starka prestanda i en mängd olika ämnen i stället för att utmärka sig i en smal domän, kan RAG vara att föredra. Den använder externa kunskapsbas, vilket gör att den kan generera svar över olika domäner utan risk för överanpassning till en specifik datauppsättning.
• Resursbegränsningar – För organisationer med begränsade resurser för datainsamling och modellträning kan användning av en RAG-metod erbjuda ett kostnadseffektivt alternativ till finjustering, särskilt om basmodellen redan presterar ganska bra på önskade uppgifter.

Slutliga överväganden som kan påverka dina beslut om programdesign

Här är en kort lista över saker att tänka på och andra lärdomar från den här artikeln som påverkar dina beslut om programdesign:

• Bestäm mellan finjustering och hämtningsförhöjd generering baserat på programmets specifika behov. Finjustering kan ge bättre prestanda för specialiserade uppgifter, medan RAG kan ge flexibilitet och uppdaterat innehåll för dynamiska program.