Vad är RAG? Så fungerar det med företagets dokument

RAG kan hitta avsnitt i företagets dokument och skapa svar med källhänvisningar, men det är varken modellträning, en sanningsmaskin eller en ersättning för behörighetskontroll.

På måndagsmorgonen frågar personalchefen den interna assistenten hur länge uppgifter om kandidater ska sparas och får ett övertygande svar med en länk till företagets policy; det enda problemet är att den hittade versionen upphörde att gälla för åtta månader sedan. Vad är RAG med företagets dokument i praktiken? Ett sådant system kan tekniskt ha gjort allt som begärdes: hittat ett semantiskt liknande avsnitt, lagt det i modellens kontext och skrivit ett välformulerat svar; det har ändå inte kontrollerat om filen är den senast godkända versionen, ifall versionsstatusen inte är tillförlitligt angiven i indexet.

Förkortningen RAG står för retrieval-augmented generation, alltså generering där hämtad extern kontext läggs till när svaret skapas; det innebär inte att företagets dokument lärs in i modellens vikter och är inte heller ett separat ”intelligenslager” som automatiskt vet vilket dokument som är sant. Det liknar snarare ett bibliotek med en mycket snabb bibliotekarie och en skicklig redaktör, där bibliotekarien kan hämta fel volym men redaktören ändå skriver ett övertygande stycke; den ursprungliga RAG-studien skiljer uttryckligen modellens parametriska minne från en externt hämtad, icke-parametrisk källa.

Den praktiska nyttan är betydande om gränserna anges ärligt: systemet kan söka fram relevanta avsnitt i en förvaltad dokumentsamling, sätta samman dem till en kontext som passar frågan och skapa ett utkast med en kontrollerbar källhänvisning. Ansvarsgränsen måste också vara synlig för användaren: gränssnittet får inte ge intrycket att en befintlig källa innebär ett juridiskt godkännande, och det ska vara lika enkelt att rapportera fel och oklarheter som att ställa en fråga. Systemet kan inte laga bristfällig dokumentation, garantera faktisk korrekthet, införa behörigheter på egen hand eller ersätta ett deterministiskt arbetsflöde och mänskligt godkännande där ett fel medför juridisk, ekonomisk, säkerhetsmässig eller människorättslig risk; den gränsen avgör både arkitekturen och vad som är meningsfullt att mäta i piloten.

Varför en gammal policy kan hämtas som den aktuella

Incidenten med den gamla policyn börjar inte i språkmodellen utan i dokumentförvaltningen: på den gemensamma disken ligger ”Personuppgifter_final.docx”, ”Personuppgifter_final2.docx” och en godkänd PDF, men ingen av filerna har ett enhetligt ikraftträdandedatum, en status eller en identifierare för den version som ersatts. Indexet ser tre innehållsmässigt liknande kandidater, och den semantiska sökningen kan ranka det gamla dokumentet högt eftersom dess formulering stämmer bättre överens med frågan; modellen ser inte organisationens mötesbeslut om beslutet saknas i data, och filnamnet ”final” är ingen förvaltningsmekanism.

Konsekvenserna är lömska eftersom svaret kan se bättre ut än ett vanligt sökresultat: det är kort, grammatiskt korrekt, hänvisar till ett verkligt dokument och skapar därför en känsla av att kontrollen redan är gjord. Källänken visar bara att en viss fil har visats eller kopplats till svaret; den visar ännu inte att varje påstående följer av det citerade avsnittet, att avsnittet inte har lyfts ur en undantagsbestämmelse eller att dokumentet har rätt att vara auktoritativt. NIST:s GenAI-profil betraktar inte ett sådant trovärdigt utseende som tillräcklig riskkontroll utan betonar styrning under systemets hela livscykel.

Lösningen är publiceringsstatus, versionskedjor och prioritetsregler, inte en längre prompt: i indexet behöver varje dokument en ägare, start- och slutdatum för giltighet, status, uppgift om ersatt dokument, avdelning, sekretessklass och granskningsfrist. Hämtningsfiltret ska som standard utesluta utkast och versioner som inte längre gäller. Om källor står i konflikt ska systemet visa konflikten och avstå från att låtsas ge ett enda säkert svar, medan den ansvariga ägaren får i uppgift att ordna dokumentsamlingen. RAG kan synliggöra kaos, men det kan inte förvandla kaos till en policy.

I den situationen ska svarsgränssnittet inte bara visa dokumentets namn utan även version, giltighetsstatus, avsnitt och en varning om konflikten; loggen ska spara vilka kandidater som hittades och varför en av dem valdes, så att felet kan återskapas efter att indexet ändrats. Om systemet senare börjar ge ett annat svar måste teamet kunna avgöra om dokumentet, segmenteringen, sökkonfigurationen eller modellen ändrades; utan sådan spårbarhet blir en kvalitetsincident en gissning om ”AI-beteende” i stället för ett systemfel som går att rätta.

Vad är RAG och hur fungerar det med företagsdokument?

RAG-flödet börjar med datainläsning, inte med chattfönstret: filer hämtas från angivna lagringsplatser, text, tabeller och tillgänglig struktur extraheras, medan skannade dokument kräver optisk teckenigenkänning, OCR. Därefter delas innehållet upp i meningsfulla avsnitt, och för varje avsnitt sparas en länk till dokumentet, sidan, sektionen och styrande metadata. Microsoft beskriver segmentering som ett val som påverkar sökningens användbarhet: ett alltför litet avsnitt tappar tankegången, ett alltför stort för in mycket brus, och en blind delning vid ett bestämt antal tecken kan skära rakt igenom en tabell eller ett undantagsvillkor.

Under indexeringen får avsnitten en representation som lämpar sig för sökning, vanligen genom att nyckelordssökning kombineras med semantisk jämförelse baserad på numeriska vektorer. När användaren ställer en fråga kan systemet omvandla den till flera sökfrågor, tillämpa filter för avdelning, datum och åtkomst, hämta kandidater och rangordna om dem. Först därefter hamnar de valda avsnitten i modellens kontextfönster tillsammans med uppgiften att svara utifrån tillgängliga belägg, ange källor och säga till när beläggen inte räcker. I det läget lärs ingenting in ”för alltid”; kontexten gäller den enskilda begäran.

Det sista steget är genereringen, där en förtränad språkmodell omvandlar avsnitten till ett begripligt svar; därför kan den också parafrasera klumpigt, förena källor som inte hör ihop eller lägga till en trovärdig detalj ur sina allmänna kunskaper. Resultatet måste bevara kopplingen mellan avsnitt och påstående, inte bara visa en dekorativ källista längst ned i svaret. Om frågan kräver en handling, till exempel att ändra ett pris i CRM-systemet, ska modellen inte få utföra den fritt: en strukturerad verktygsbegäran kontrolleras av applikationskoden, behörigheterna och ett godkännandesteg. Hämtningen hjälper till att hitta belägg; den ger ingen rätt att agera.

I praktiken fungerar hybridhämtning bra: en exakt produktkod eller ett policynummer söks som nyckelord, medan frågans innebörd söks semantiskt; därefter väljer en omrangordning de avsnitt som bäst besvarar hela frågan. Den ordningen måste testas med verkliga förkortningar, felstavade koder, böjningsformer och flerspråkiga dokument, eftersom demonstrationsfrågan oftast är alltför ren. Om det avsnitt som behövs inte finns bland kandidaterna kan den genererande modellen inte trolla fram det med vältalighet, så sökfelet måste åtgärdas innan prompten formuleras om.

För vilka dokumentbehov passar RAG?

De bästa kandidaterna är frågor där svaret redan finns i många förvaltade dokument men tar för lång tid för en människa att leta fram: interna rutiner, produkthandböcker, tekniska instruktioner, kvalitetsdokumentation, förklaringar till avtalsmallar och kunskapsbaser för kundsupport. Här är RAG:s uppgift inte att hitta på ett nytt beslut, utan att hitta rätt avsnitt, kombinera några sinsemellan förenliga delar och skapa ett utkast. En bra fråga är ”i vilken instruktion beskrivs det här felet och vilka kontrollsteg anges där?”, inte ”hur ska företaget agera i varje tänkbar nödsituation?”; ett lager för dokumentundersökning före det mänskliga arbetet är också användbart: projektledaren kan hitta leveransvillkor i avtal, inköparen omnämnanden av krav och serviceteknikern tidigare lösningar för liknande utrustning. I sådana fall ska svaret öppna rätt plats i källan så att användaren kan kontrollera kontexten, och systemet ska logga frågan, de hittade avsnitten och den använda versionen. Det gör RAG till ett verktyg för navigering och utkast, inte en anonym domare vars beslutsväg inte kan återskapas i efterhand.

Dåliga kandidater är uppgifter som saknar ett stabilt dokumentunderlag, kräver exakt aritmetik eller regelverkställighet, eller där ett enda fel automatiskt utlöser en oåterkallelig handling. Löneberäkning, tilldelning av åtkomst, genomförande av betalningar och bevakning av juridiska tidsfrister styrs av kod och kontrollerbara affärsregler; RAG kan hitta en förklaring till rutinen men kan inte ersätta beräkningsmotorn eller behörighetskedjan. Om det verkliga målet är att koppla samman system och flytta data på ett förutsägbart sätt bör du bedöma automatisering av affärsprocesser, inte göra ett förgenererat svar till processens centrala strömbrytare.

Lämpligheten avgörs också av vem som äger ansvaret: varje dokumentsamling behöver en person som godkänner källor, löser konflikter och beslutar om borttagning ur indexet, och varje användningsfall behöver ett team som granskar fel och ändrar testmängden. Om ingen tar på sig det arbetet blir piloten efter några månader en spegel av gamla dokument, trots att själva modellen inte har ändrats. En tekniskt enkel men förvaltad supportguide är därför ett bättre första projekt än att koppla in hela företagets disk på en kväll.

Vad RAG kan göra i det dagliga dokumentarbetet

RAG kan minska den tid en medarbetare lägger på att gissa rätt mapp och sökord, eftersom semantisk sökning kan hitta ett avsnitt även när orden i frågan inte motsvarar dokumentets terminologi. Det kan förena flera förenliga källor i ett svar, förklara en komplicerad instruktion på enklare språk, skapa ett utkast till mejl eller rapport och visa från vilka sidor varje viktigt påstående kommer. OpenAI:s filsökning och Microsofts sökarkitektur är konkreta exempel på verktyg, men produktvalet undanröjer inte behovet av att definiera dokumentstatus, filter och kvalitetskontroller. Systemet kan också avslöja dokumentationsproblem som vanlig mappbläddring döljer: två motstridiga instruktioner hittas för samma fråga, vanliga frågor saknar källa eller en avdelning dominerar resultaten eftersom dess filer är bättre strukturerade. De fallen är värdefulla bara om de inte döljs bakom ett enda välformulerat svar; en saknad källa och en konflikt måste bli mätbara händelser som dokumentägaren ser. Då blir RAG:s kvalitetslogg även en arbetslista för kunskapsförvaltning, inte bara ett diagram över modellens prestanda.

En annan verklig möjlighet är anpassning efter roll och kontext: teknikern får en detaljerad instruktion med koder, medan kundrådgivaren får en kortare förklaring, förutsatt att båda har rätt att se samma källor. Presentationen skiljer sig, inte sanningen, och för varje roll måste samma källstatus och samma förbud mot att hitta på det som saknas gälla. Vårt arbete med AI-lösningar för företag börjar med gränsen för användningsfallet och risken, inte med en demonstration av modellen, eftersom en bra prototyp visar en konkret arbetsnytta med dina dokument och samtidigt visar i vilka frågor systemet måste säga ”jag vet inte”.

I det dagliga arbetet uppstår den största nyttan när människan ser vad systemet har gjort åt henne och vad som återstår att kontrollera. I svarsutkastet kan påståenden med otillräckliga belägg markeras, relaterade dokument föreslås och en felaktig version rapporteras med en enda åtgärd; sådan återkoppling är mer värdefull än en enkel tumikon. Rättelsen måste kopplas till frågan, avsnittet och feltypen så att teamet kan skilja en saknad källa från klumpigt språk eller en felaktig affärsregel och välja rätt åtgärd.

Vad RAG inte kan göra, hur övertygande svaret än låter

RAG kan inte garantera att något är sant, eftersom felet kan uppstå före, under eller efter genereringen: källan kan innehålla en felaktig uppgift, hämtningen kan välja ett irrelevant avsnitt, kontexten kan tappa ett undantag och modellen kan förena korrekta stycken på fel sätt. Ett citat minskar risken för blind tillit endast om användaren kan öppna den exakta platsen och kontrollera att påståendet verkligen följer av den, men en länk till en verklig PDF är ingen kvalitetsstämpel, på samma sätt som en bibliografi i en felaktig rapport inte i sig gör slutsatsen korrekt.

RAG kan inte heller införa behörighetskontroll på egen hand: om söklagret före hämtningen inte filtrerar dokument efter en verifierad användaridentitet och dokumentets behörigheter kan modellen få ett avsnitt som användaren inte får se, och ett senare tillägg i prompten om att ”inte avslöja hemlig information” rättar inte arkitekturfelet. Microsofts riktlinjer för åtkomstkontroll på dokumentnivå förutsätter behörighetsdata och säkerhetsfilter i själva sökvägen; en dold knapp i användargränssnittet är inget skydd om frågan kan anropas på ett annat sätt.

RAG gör inte heller opålitligt innehåll säkert: ett dokument, en webbsida eller ett mejl kan innehålla en instruktion som försöker skriva över systemets beteende — en promptinjektion — och OWASP lyfter fram detta som en separat risk som inte helt löses av ett enkelt förbud i systemprompten. Externt innehåll måste därför behandlas som data, inte som kommandon, verktygsanrop måste vara snävt tillåtna och validerade, och en högriskhandling måste förbli en deterministisk regel med mänskligt godkännande; modellen får föreslå; systemet tilldelar befogenheten.

Listan över gränser måste även omfatta tillgänglighet och verksamhetskontinuitet: om sökindexet inte går att nå ska ett säkert system inte låtsas att det fortfarande har företagets källor, utan tydligt växla till ett feltillstånd eller ett begränsat läge. Annars kan användaren inte skilja ett källbaserat svar från modellens fria improvisation; dessutom behövs gränser för kostnader och antal begäranden, nödstopp och återställning av den föregående konfigurationen. En RAG-produkt är en kedja av flera tjänster, och varje tyst fel kan ändra svarets innebörd även om chattfönstret fortsätter fungera.

Är dokumenten redo? OCR, metadata och versionshantering

Storleken på dokumentmappen är inget mått på beredskap: ett skannat avtal med en sned sida, en tabell utan läsbar rubrik, en PDF med fel textordning eller ett foto med låg kontrast kan se begripligt ut för en människa men i OCR-utdraget förlora en siffra, sambandet mellan kolumner eller en styckegräns. Microsofts beskrivning av OCR-begränsningar kopplar tydligt resultatet till skanningens kvalitet, upplösning, kontrast, belysning, rotation och textens egenskaper. Representativa dokument måste därför kontrolleras efter extraktionen genom att text, tabeller, sidreferenser och viktiga fält jämförs med originalet, i stället för att lita på att filen har ”bearbetats framgångsrikt”.

Metadata ger avsnittet dess organisatoriska kontext: dokumenttyp, organisatorisk enhet, produkt, språk, ägare, godkännare, sekretess, giltighetstid och versionsstatus gör att frågan kan avgränsas innan den semantiska likheten bedöms. Utan metadata jämför sökmotorn meningar men vet inte att lagerinstruktionen bara gäller Litauen eller att en avtalsbilaga har ersatts av en nyare. De viktigaste fälten ska hämtas från ett tillförlitligt system eller kontrolleras av en människa; en genererad gissning om dokumentets status får inte bli det filter som avgör nästa svar.

Även uppdateringen är en del av produkten, inte ett engångsarbete vid importen: det måste vara känt hur snabbt en godkänd ändring når indexet, hur ett återkallat avsnitt tas bort, vad som händer när filadressen ändras och om systemet vid ett fel fortsätter att visa den gamla versionen. Microsofts riktlinjer för index skiljer inkrementella uppdateringar från omindexering, så varje källa behöver en dokumenterad metod för synkronisering och felkontroll. Före ett RAG-projekt är det värt att ordna ett enda auktoritativt dokumentflöde; annars påskyndar den snabba hämtningen bara följderna av en oklar förvaltning.

Före den första indexeringen är ett urval för dokumentberedskap användbart: välj olika filtyper, åldrar, språk, tabeller, skanningar och åtkomstklasser och kontrollera sedan för varje dokument den extraherade texten, avsnittsgränserna, metadata och källänken. Felandelen ska inte omvandlas till ett enda genomsnitt, eftersom priset för ett borttappat kommatecken i en instruktion skiljer sig från priset för ett borttappat belopp i ett avtal. Urvalet ger grund för att avgöra vilka format som kan godtas automatiskt, vilka som behöver mänsklig kontroll och vilka som tills vidare inte ska indexeras; det arbetet ger ofta större kvalitetsökning än valet av en annan språkmodell.

Behörigheter, integritet och val av driftmiljö

En säker arkitektur börjar med identiteten: vem frågar, vilken organisation och avdelning tillhör personen, vilka dokumentklasser får personen se och kontrolleras de rättigheterna vid varje hämtningsbegäran? Behörighetsfiltret måste köras innan avsnitten når modellens kontext, medan loggarna ska undvika onödig kopiering av fullständiga frågor, svar och känsliga avsnitt. Även gränsfall måste testas — en medarbetare byter roll, ett dokument begränsas, åtkomst återkallas eller en kund försöker hitta en annan kunds innehåll; att ”chatten kräver inloggning” är inte ett tillräckligt acceptanskriterium.

Frågan ”hamnar mina data i modellträningen?” saknar ett ärligt universellt svar om inte leverantör, produkt, konto och inställningar namnges. OpenAI:s material om företagsprodukter och API anger att data i de berörda företagsprodukterna som standard inte används för modellträning, medan dokumentationen om API-datakontroller separat beskriver lagring, övervakning av missbruk och undantag för olika slutpunkter. Anthropic skiljer också mellan behandling i kommersiella produkter, uttryckligt samtycke till förbättring och lagringsvillkor. I avtalet och den tekniska planen ska därför den konkreta tjänsten kontrolleras, i stället för att man litar på uttrycket ”API för företag”.

Drift i en EU-region eller i den egna infrastrukturen kan bidra till att uppfylla vissa krav på dataplacering, kontroll eller integration, men bevisar inte i sig att lösningen följer GDPR eller är säker. Ändamål och rättslig grund för behandlingen, dataminimering, lagringstider, underbiträden, radering, incidentprocess och åtkomstrevision måste fortfarande fastställas; GDPR:s principer gäller hela kedjan, inte bara landet där modellservern står. Ibland är det rätta beslutet att inte alls ta med vissa dokument i RAG eller att före indexeringen ta bort fält som inte behövs för svaret.

Hotmodellen ska inte bara pröva en nyfiken medarbetare, utan också felaktig gruppsynkronisering, en delad länk, administratörsrollen, en sparad cache och ett dokument med en skadlig instruktion. Testanvändarna ska täcka varje roll och förbjuden kombination av roller genom att fråga direkt, med synonymer och med en indirekt begäran om sammanställning. Resultatet får varken visa ett avsnitt, dokumentets namn eller en hemlig detalj som kan härledas ur svaret. Efter en behörighetsändring ska testet upprepas, eftersom gårdagens säkra filter kan ligga kvar i cachen; de här kontrollerna är acceptanskriterier, inte dekorationer i en senare säkerhetsgranskning.

Så mäter du hämtning, källförankring och korrekthet

Ett enda mått på ”träffsäkerhet” för ett RAG-system är som ett enda genomsnittsbetyg för ett sjukhus: siffran kan se bra ut medan en kritisk felklass förblir osynlig. Först mäts hämtningen separat — om det avsnitt som behövs fanns bland ett bestämt antal topprankade resultat och om onödiga avsnitt trängde undan det. Därefter mäts kontextens relevans för frågan, svarets stöd i de givna avsnitten, den faktiska korrektheten mot ett godkänt facit, varje källhänvisnings koppling till det konkreta påståendet och systemets förmåga att avstå från att svara när en källa saknas eller källor står i konflikt.

Microsofts dokumentation om RAG-utvärderare delar upp dessa dimensioner, och forskningsarbetet ARES skiljer på liknande sätt mellan kontextens relevans, svarets förankring och svarets relevans. I den praktiska testmängden behöver varje verklig fråga därför inte bara ”rätt svar”, utan även obligatorisk källa, tillåtna formuleringar, förbjudna påståenden, roll, dokumentversion och förväntat beteende när beläggen inte räcker. En del exempel byggs av vanliga frågor, andra av kostsamma undantag och avsiktliga fällor.

Acceptanströskeln ska fastställas för varje dimension och riskklass innan resultaten visas, annars väljer teamet efter demonstrationen det mått som ser bäst ut. Pilotens mätningar måste också bevara felens fördelning per dokumenttyp, avdelning, språk och frågetyp, eftersom det sammanlagda genomsnittet kan dölja att handböcker fungerar bra men avtalstabeller dåligt. En automatisk modellutvärderare hjälper till att skala upp kontrollen, men ett urval måste granskas av människor och kritiska svar jämföras med en auktoritativ källa, inte med en annan modells övertygelse.

Efter lanseringen ska samma dimensioner mätas med ett kontrollerat urval från produktionen och integritetsskyddande loggar. En ändring i dokumentkorpusen, segmenteringsalgoritmen, embeddingmodellen, omrangordningen eller den genererande modellen kan förbättra en grupp frågor och försämra en annan, så varje version behöver ett regressionstest och en jämförbar baslinje med oförändrade utvärderingsregler för hela testmängden. En varning ska inte bara utlösas när det övergripande måttet sjunker, utan också när ett kritiskt fel uppstår, exempelvis ett obehörigt avsnitt eller ett påhittat svar där systemet förväntades avstå.

RAG, sökning, lång kontext, finjustering och agenter

Vanlig fulltextsökning är bättre när användaren känner till det exakta namnet, koden eller frasen och behöver dokumentet, inte ett sammanställt svar; den är billigare, mer förutsägbar och lättare att granska. Semantisk sökning hjälper vid synonymer och otydliga frågor, men generering bör bara läggas till där sammanfattningen ger verkligt värde. RAG är inte nödvändigt för varje söktjänst i företaget: ibland är rätt produkt en bra söksida med filter, förhandsvisning av avsnitt och versionsstatus, eftersom användaren själv drar slutsatsen från hela dokumentet.

Att lägga in hela dokumentet i ett långt kontextfönster kan vara enkelt för ett litet, stabilt material, men i en stor korpus ökar kostnaden, bruset och risken för att ett viktigt stycke försvinner bland oviktigt innehåll. Ytterligare modellanpassning, fine-tuning, kan i sin tur befästa format, stil eller beteende för en viss uppgift, men är inte ett praktiskt sätt att lagra priser, policyer och instruktioner som ändras ofta, eftersom uppdatering och citering av källan blir mindre transparent. RAG gör det möjligt att ändra dokumentsamlingen oberoende av träningen av modellens vikter, men flexibiliteten kräver i gengäld förvaltning av index, versioner och hämtningskvalitet.

Automatisering utför fördefinierade steg, medan en AI-agent kan välja verktyg och nästa steg; den friheten kräver därför strängare gränser för befogenheter, validering och stopp. RAG kan ge agenten information men inte rättigheter: om modellen hittar semesterpolicyn får den fortfarande inte själv godkänna ledighet eller ändra lönesystemet. Ett strukturerat funktionsanrop är bara ett förslag till applikationen, som kontrollerar schema, identitet, tillåten åtgärd, belopp eller andra gränser samt det mänskliga godkännande som krävs; teknikjämförelsen börjar med processens risk, inte med viljan att använda det modernaste namnet.

Valet kan formuleras som ett enkelt test: om du behöver hitta och öppna en fil börjar du med sökning; om några föränderliga källor ska sammanställas med hänvisningar bedömer du RAG; om ett stabilt format eller klassificeringsbeteende ska följas kan modellanpassning vara möjlig; om en förutsägbar följd av handlingar ska utföras bygger du automatisering. En agent läggs till bara när valet av nästa steg inte kan programmeras säkert och nyttan uppväger den extra risken. Metoderna kan kombineras, men varje lager måste ha sin egen uppgift, sitt eget mått och sin egen stoppgräns, annars försvinner orsaken till felet bakom ordet ”AI”.

Så bygger du en avgränsad pilot med verkliga frågor

En pilot börjar med en dokumentsamling, en användargrupp och en beslutsgräns, till exempel handböcker för teknisk support där systemet bara hittar källor och skapar ett svarsutkast. Före utvecklingen samlar teamet verkliga frågor från sökloggar, mejl och medarbetarintervjuer, lägger till rätt källor och tar med avsiktligt obesvarbara, föråldrade, motstridiga och obehöriga fall. För varje fall fastställs vad som räknas som godtagbart: rätt avsnitt har hittats, påståendet stöds av källan, citatet leder till rätt plats, svaret är faktiskt korrekt och systemet hittar inte på det som saknas.

Trösklarna fastställs före demonstrationen och delas upp efter risk: för en vanlig informationsfråga kan ett rättningsbart utkast accepteras, men en fråga om personuppgifter, avtal, säkerhet eller betalning kräver strängare kontroll och mänskligt godkännande. I piloten mäts också svarstid, kostnad per begäran, åtkomstfiltrens funktion, fördröjningen när indexet uppdateras och hur ofta en medarbetare öppnar källan eller rättar svaret. Om systemet bara förbättrar demonstrationsexemplen men inte klarar en tidigare undanhållen testmängd har produktresultatet inte bevisats; teamet har bevisat att det kan förbereda en demonstration.

Våra AI-lösningar för företag börjar på 3 500 € och tar vanligtvis 3–8 veckor, medan en fungerande pilot med dina egna data kan levereras på 2–3 veckor; siffrorna beskriver tjänstens startpris och allmänna tidsplan, inte ett fast erbjudande för en okänd omfattning. När piloten avslutas ska resultatet inte bara vara ett chattfönster, utan även en versionshanterad dokumentkorpus, testfrågor, separata kvalitetsmått, en fellogg, åtkomstkontroller och ett beslut om vad lösningen inte får göra. Krav på senare integrationer bör fastställas lika tydligt som i andra digitala projekt, enligt principen i artikeln om 10 vanliga misstag när företag beställer en webbplats: acceptanskriterier och ägare ska bestämmas före ett fullständigt införande, inte efter den första imponerande skärmen.

Piloten fortsätter bara om den når de på förhand fastställda trösklarna på en osedd del av testmängden, hanterar obehöriga och obesvarbara frågor säkert och ger mätbar nytta i människans arbete. Om hämtningen systematiskt inte hittar rätt källa rättas först dokumenten, metadata och indexet; om källan är rätt men genereringen förvränger den ändras kontexten, prompten eller modellen. Om felet bara uppstår i högriskbeslut lämnas besluten till ett deterministiskt system och en människa. En stoppad pilot är inget misslyckande — den är ett billigt bevis för att RAG:s gränser är viktigare än demonstrationseffekten i just den processen.