“RAG is dead.”
Det är mantrat just nu. Claude har 1 miljon tokens kontext. Gemini har 2 miljoner. Varför bry sig om retrieval när du kan stoppa in hela kunskapsbasen i en enda prompt?
Jag förstår argumentet. Men efter att ha byggt AI-system för IoT och industri ett tag är min bild en annan — RAG är inte dött, det har bara växt upp. Och för den som bygger produkter på riktigt har det aldrig varit mer relevant.
För om du tittar på vad som faktiskt landat de senaste månaderna är RAG inte bara levande – det är inbyggt överallt:
Så frågan borde inte vara “är RAG dött?” utan snarare: om RAG redan finns inbyggt i allt, varför skulle jag bygga eget?
Det är en rimlig fråga. Och för många användningsfall är svaret: det behöver du inte. Men det finns en hel kategori av situationer där de inbyggda lösningarna inte räcker. Det är det jag vill prata om.
Låt oss vara ärliga. Om du är en konsult som vill ställa frågor mot dina egna dokument, en liten startup som vill ge sitt team tillgång till intern kunskap, eller en utvecklare som prototypar – då är Claude Cowork eller GPT Projects helt utmärkt. Du laddar upp filer, ställer frågor, och får bra svar. Inga servrar, ingen infrastruktur, ingen vektordatabas att underhålla.
Det är RAG. Det är bara att någon annan har byggt det åt dig.
Men det finns scenarier där “ladda upp till molntjänst” inte fungerar:
1. Automatiserad kundsupport i produktion. Det här är kanske det vanligaste fallet där “ladda upp till Cowork” kollapsar direkt. Du bygger ett supportsystem åt ett företag. Systemet ska klassificera och besvara inkommande ärenden baserat på företagets dokumentation, produktdata och ärendehistorik. Du kan inte ge varje supportagent en Claude Cowork-licens och be dem ladda upp filer för hand. Du behöver ett system som kör på företagets server, hanterar hundratals förfrågningar parallellt och integreras direkt i deras befintliga ärendehantering (Zendesk, Freshdesk, Jira Service Management – vad de nu kör).
Ta ett konkret exempel: ett supportklassificeringssystem för en IoT-produkt. Inkommande ärenden ska automatiskt kategoriseras – anslutningsproblem, firmware-bugg, hårdvarufel, integrationsfråga – och dirigeras till rätt team. RAG-principen, att hämta relevanta träningsexempel dynamiskt per kategori vid inferenstid, gör två saker: den ger modellen färska exempel från företagets egna lösta ärenden (inte en frusen fine-tune), och den gör hela systemet containeriserbart med Docker och driftbart lokalt hos kunden, utan beroende av externa API:er. Lägg till agentic execution och modellen kan även slå upp kundens enhets-ID i CRM, kolla firmware-version i enhetsdatabasen och föreslå ett svar baserat på faktisk data – inte gissningar.
Det är det som gör RAG för support så kraftfullt: det är inte “FAQ-bot version 2”. Det är en agent med kontrollerad tillgång till era riktiga system.
2. Datasekretesskrav. GDPR, NIS2, branschspecifika regler. Ett sjöfartsföretag som vill analysera sin bränsleförbrukning vill inte skicka 12 månaders driftsdata till OpenAIs API. Ett tillverkningsföretag vill inte att produktionsloggar hamnar i molnet. Dataminimeringsprincipen kräver att du bara hämtar det som behövs för just den frågan – och att datan aldrig lämnar infrastrukturen.
3. Kostnad i skala. 1 miljon tokens i kontexten per fråga kostar pengar. Om du har 500 supportärenden om dagen och varje fråga kräver 100k tokens kontext, adderar det snabbt. RAG – att hämta bara de 2 000 mest relevanta tokens – är inte bara säkrare utan dramatiskt billigare per förfrågan.
4. Strukturerad data och numerisk precision. Samma logik som för support gäller när datan är strukturerad – tidsserier, relationsdatabaser, hundratals miljoner rader. Det ryms inte i något kontextfönster. Verktyg som Claude Code kan köra SQL och Python mot din data, men Claude Code är ett utvecklarverktyg: det kräver en teknisk användare, lokal miljö och kostar per session. Om du bygger en produkt där icke-tekniska operatörer ska kunna ställa frågor på naturligt språk och få verifierade svar behöver du ett eget system med kontrollerade verktygsanrop och förutsägbar kostnad.
5. Verifierbarhet. I säkerhetskritiska miljöer räcker det inte att modellen förmodligen har rätt. Du behöver en audit trail – exakt vilken fråga som kördes, vilken data som hämtades, vilken kod som genererade resultatet. RAG med agentic execution ger dig det. En LLM som sväljer all data och spottar ut ett svar gör det inte.
Den klassiska RAG:en – embedda dokument, hämta chunks, skicka till LLM – har sina begränsningar. Den klarar text bra men faller kort vid strukturerad data, tidsserier och beräkningar.
Det är där Agentic RAG kommer in. Istället för att bara hämta textbitar ger du LLM:en verktyg:
Agenten tar emot en naturlig språkfråga, väljer rätt verktyg, kör deterministisk kod, och returnerar ett svar baserat på exekverat resultat – inte genererad text. Hela kedjan är reviderbar.
Det här är en välbeprövad approach – en nyligen publicerad studie i Sensors (MDPI) visar till exempel hur Agentic RAG kan ge naturligt språkåtkomst till strukturerad sensordata, med ~90% faktakorrekthet för Claude 3.7 och 99,7% för open source-modellen Qwen 72B på enkla frågor. Det betyder att self-hosted RAG med öppna modeller redan är en gångbar väg för företag som inte kan – eller inte vill – skicka sin data till externa API:er.
En sak som förändrats är vem som faktiskt kan bygga ett RAG-system. LangChain, LlamaIndex och liknande bibliotek har funnits i flera år och fungerat bra – för utvecklare. Tröskeln var att du behövde skriva kod och förstå tekniken. Idag är det dramatiskt mer tillgängligt: managed vektordatabaser, no-code-pipelines i n8n, och ramverk som abstraherar bort det mesta av boilerplaten. En utvecklare kan fortfarande välja bland de mogna biblioteken:
Och på infrastruktursidan: Qdrant, Weaviate, Pinecone, pgvector – vektordatabaser som du kan driftsätta lokalt eller i molnet på minuter. Kombinera det med Docker och du har ett produktionsklart RAG-system som körs var du vill.
Poängen: tröskeln för att bygga eget har sjunkit dramatiskt. Det som för ett år sedan krävde veckors uppsättning gör du nu på en eftermiddag.
En enkel tumregel:
| Situation | Rekommendation |
|---|---|
| Enskild användare, egna dokument | Claude Cowork / GPT Projects |
| Litet team, intern kunskapsbas | n8n-pipeline eller Paperclip |
| Automatiserad kundsupport i produktion | Egenbyggd RAG + agentic tools |
| Sekretess- eller regulatoriska krav | Egenbyggd RAG, self-hosted |
| Strukturerad data / numerisk analys | Agentic RAG med kodexekvering |
| Kostnadskänslig skala (100+ frågor/dag) | Egenbyggd RAG |
Den gamla RAG:en – manuellt chunkade dokument i en vektordatabas som enda retrieval-mekanism – den är på väg att bli en commoditized feature. Och det är bra. Det betyder att fler får tillgång till tekniken utan att behöva bygga den själva.
Men för den som bygger produkter, sätter upp system på kunders servrar, hanterar känslig data i skala, eller behöver numerisk precision och audit trail? Där är RAG mer relevant än någonsin. Det handlar bara inte om att hämta dokument längre. Det handlar om att ge AI-agenter kontrollerad, verifierbar tillgång till data och verktyg.
RAG är inte dött. Det har bara vuxit upp.
Automatiserad kundsupport, AI-system mot känslig data, eller naturligt språk mot strukturerade IoT-mätningar? Det är precis den typen av projekt vi på Vildly tar oss an. Hör av er så berättar vi mer om hur vi skulle angripa just ert problem.
Vidare läsning och tittande: