Githubprojekt samlar över 40 metoder för bättre RAG-system

Ett öppet Githubprojekt har blivit en av de mer omfattande samlingarna av praktiska metoder för RAG, tekniken som låter språkmodeller hämta information från externa källor innan de svarar.

Projektet heter RAG_Techniques och drivs av Nir Diamant. Det samlar notebookbaserade handledningar för utvecklare som vill bygga mer träffsäkra, kontrollerbara och utvärderingsbara RAG-system. På Github har projektet omkring 27 000 stjärnor och över 3 000 forkar.

Vad är RAG?

RAG står för retrieval-augmented generation, på svenska ungefär hämtningsförstärkt textgenerering.

Det betyder att en ai-modell inte bara svarar utifrån sin inlärda kunskap. Den söker först fram relevant information från exempelvis dokument, databaser, webbsidor, filer eller interna kunskapsbaser. Därefter använder modellen det hämtade materialet som grund för svaret.

Målet är att minska hallucinationer, ge mer aktuella svar och göra ai-system användbara på företagens egna data.

Vad är nytt med Githubprojektet RAG_Techniques?

Projektet samlar ett stort antal praktiska RAG-metoder i ett och samma bibliotek. Enligt projektsidan innehåller det 42 notebooks och växer löpande. Bland de senast tillagda delarna finns MemoRAG, end-to-end-utvärdering, Open-RAG-Eval och RAG med JSON.

Det gör projektet till mer än en introduktion. Det fungerar snarare som en verktygslåda för utvecklare som redan har byggt en enkel RAG-lösning och nu vill förbättra träffsäkerhet, snabbhet, transparens och kontroll.

Varför spelar det roll?

Många företag börjar med en enkel RAG-lösning: dela upp dokument i bitar, skapa embeddings, sök fram relevanta textstycken och skicka dem till en språkmodell.

Det fungerar ofta i en demo.

Men i produktion uppstår problem. Systemet hämtar fel dokument. Textbitarna är för stora eller för små. Modellen får för lite sammanhang. Viktiga svar göms i fel del av ett dokument. Resultaten går inte att mäta. Och användaren vet inte varför systemet svarar som det gör.

RAG_Techniques fokuserar på just de problemen.

Vilka grundmetoder ingår?

Projektet börjar med enkla RAG-varianter. Det finns exempel för klassisk RAG, RAG med CSV-filer, RAG med JSON och optimering av chunkstorlek.

Chunking är en central del av RAG. Det handlar om hur dokument delas upp innan de indexeras. För stora textbitar kan ge brus. För små textbitar kan tappa sammanhang. Projektet visar bland annat hur utvecklare kan testa olika chunkstorlekar för att hitta en bättre balans mellan kontext och sökhastighet.

En annan metod är proposition chunking. Där bryts dokument ned i korta, fullständiga och meningsbärande påståenden. En språkmodell används för att skapa faktapåståenden från dokumentbitar, som därefter granskas utifrån noggrannhet, tydlighet, fullständighet och koncision.

Hur förbättras själva sökfrågan?

En stor del av projektet handlar om att göra användarens fråga lättare att matcha mot rätt information.

Under kategorin query enhancement finns metoder som query rewriting, step-back prompting och sub-query decomposition. Det betyder att systemet kan skriva om en fråga, skapa en bredare fråga eller dela upp en komplicerad fråga i flera mindre delfrågor.

Det finns också stöd för HyDE, där systemet skapar hypotetiska frågor eller dokument för att förbättra matchningen mellan användarens fråga och materialet i databasen.

En närliggande metod är HyPE, där hypotetiska frågor skapas redan vid indexeringen. Då behöver systemet inte göra en extra språkmodellkörning vid varje fråga, vilket kan göra sökningen snabbare och billigare. Projektet uppger att metoden kan förbättra precision och återkallning i vissa mätningar.

Hur får modellen bättre sammanhang?

Flera tekniker i projektet handlar om att ge modellen mer relevant kontext.

Contextual chunk headers lägger till dokument- eller sektionsrubriker framför varje textbit innan den bäddas in. Syftet är att varje chunk ska bära med sig mer information om varifrån den kommer.

Relevant segment extraction försöker bygga längre textsegment av flera närliggande chunks när en fråga kräver mer sammanhang än en enskild textbit.

Semantic chunking delar inte dokument efter fast längd, utan efter ämnesgränser och semantiskt sammanhängande avsnitt.

Contextual compression använder en språkmodell för att korta ned hämtat material och behålla det som är relevant för frågan.

Hur blir RAG-sökningen mer träffsäker?

Projektet innehåller flera tekniker för mer avancerad hämtning.

Fusion retrieval kombinerar nyckelordsbaserad sökning med vektorbaserad sökning. Det kan vara viktigt eftersom olika sökmetoder är bra på olika saker. Nyckelord kan fånga exakta termer. Vektorsökning kan fånga semantisk likhet.

Reranking används för att rangordna träffarna efter att de först har hämtats. Projektet beskriver bland annat språkmodellbaserad poängsättning, cross-encoder-modeller och metadataförstärkt rankning.

Multi-faceted filtering lägger till filter för exempelvis datum, källa, författare, dokumenttyp, relevanspoäng och innehållskrav. Det kan också användas för att minska dubbletter och skapa större variation i träffarna.

Vad är Graph RAG?

Graph RAG är en mer avancerad RAG-arkitektur där systemet inte bara söker i textstycken, utan också använder relationer mellan begrepp, personer, platser, händelser eller dokument.

I RAG_Techniques finns flera varianter: Graph RAG med Langchain, Microsoft GraphRAG och Graph RAG med Milvus. Projektet beskriver bland annat hur relationstripplar kan lagras separat från textpassager och sedan kombineras med vektorsökning och reranking.

Det är särskilt användbart vid frågor som kräver flera steg, till exempel när svaret beror på samband mellan olika dokument eller delar av en kunskapsbas.

Vad är Self-RAG och Corrective RAG?

Self-RAG är en metod där systemet själv avgör om det behöver hämta information, hur relevant den hämtade informationen är och hur den ska användas i svaret. Projektet beskriver en process med retrieval-beslut, dokumenthämtning, relevansbedömning, svarsgenerering, stödgranskning och nyttobedömning.

Corrective RAG, ofta kallat CRAG, går ett steg längre. Det utvärderar om den hämtade informationen är tillräckligt relevant och kan vid behov skriva om sökfrågan, förfina kunskapen eller använda webbsökning som kompletterande källa.

Båda metoderna handlar om samma sak: att RAG-systemet inte blint ska lita på den första sökningen.

Vad är Agentic RAG?

Agentic RAG innebär att en ai-agent får en mer aktiv roll i sök- och svarskedjan.

I projektet finns en handledning för agentisk RAG med Contextual AI. Den beskrivs som en pipeline för finansiell dokumentanalys med frågeomformulering, dokumenttolkning, reranking och modeller som är byggda för mer grundade svar.

Det finns också en särskild avancerad teknik för en kontrollerbar agent för komplexa RAG-uppgifter. Den använder en deterministisk graf som agentens ”hjärna” och innehåller steg som frågeanonymisering, planering, uppgiftsdelning, adaptiv informationshämtning, omplanering och svarsverifiering.

Det är en tydlig signal om vart RAG-utvecklingen rör sig: från enkel dokumentsökning till mer styrda arbetsflöden där en agent planerar, hämtar, granskar och verifierar.

Hur utvärderas RAG-system?

RAG_Techniques innehåller flera metoder för utvärdering. Bland annat finns exempel med DeepEval, GroUSE, End-to-End RAG Evaluation och Open-RAG-Eval.

DeepEval används för testfall som mäter korrekthet, trohet mot källmaterialet och kontextuell relevans. Open-RAG-Eval visar utvärdering med öppna metoder för bland annat citationer och hallucinationsdetektion.

Det här är avgörande i produktion. Ett RAG-system som inte mäts blir svårt att förbättra. Och ett system som inte kan visa om svaret faktiskt bygger på rätt källor blir svårt att lita på.

Vem har nytta av RAG_Techniques?

Projektet riktar sig främst till utvecklare, ai-ingenjörer, data scientists, tekniska produktteam och forskare som vill bygga eller förbättra RAG-system.

Det är särskilt relevant för företag som vill använda språkmodeller på interna dokument, kunddata, supportärenden, avtal, policydokument, forskningsrapporter, produktmanualer eller finansiella dokument.

För nybörjare finns enklare exempel. För mer avancerade team finns tekniker för reranking, Graph RAG, agentisk RAG, minnesförstärkt retrieval och utvärdering.

Hur kommer man i gång?

Projektets egen startguide är enkel: klona Githubförvaret, gå till den teknik du vill testa och följ implementeringsguiden i respektive katalog.

Kommandot som anges är:

git clone https://github.com/NirDiamant/RAG_Techniques.gitcd all_rag_techniques/technique-name

Därefter väljer utvecklaren den notebook eller det körbara script som motsvarar den teknik som ska testas.

Vilken metod bör man börja med?

För de flesta team är rätt ordning denna:

Börja med enkel RAG. Testa därefter chunkstorlek och semantisk chunking. Lägg sedan till query rewriting och reranking. När systemet fungerar hjälpligt bör nästa steg vara utvärdering. Först därefter är det rimligt att gå vidare till Graph RAG, Self-RAG, Corrective RAG eller agentisk RAG.

Det är frestande att börja med den mest avancerade arkitekturen. Men RAG-problem är ofta enklare än så i början. Många förbättringar kommer från bättre uppdelning av dokument, bättre frågor, bättre rankning och bättre mätning.

Vilka är riskerna?

RAG löser inte automatiskt problemet med hallucinationer. Ett dåligt RAG-system kan fortfarande hämta fel källor, missa viktig kontext eller låta modellen dra slutsatser som materialet inte stödjer.

Avancerade tekniker kan också göra systemet mer komplext, dyrare och svårare att felsöka. Mer retrieval är inte alltid bättre. Fler agenter är inte alltid bättre. Fler steg kan ge bättre svar, men också fler felkällor.

Därför är utvärdering, källspårning och tydliga begränsningar lika viktiga som själva retrievaltekniken.