Finjustering i 2026: et LoRA- og QLoRA-eksperiment med dokumentationen i centrum

Tilpasning af alle modelparametre kan kræve betydelig regnekraft, datateknisk arbejde og kapacitet til ML-drift. Parametereffektive metoder reducerer dele af denne byrde, men gennemførligheden afhænger stadig af den valgte model, sekvenslængde, hardware, biblioteksversioner, data og accepttest.

Parametereffektive metoder som LoRA og QLoRA reducerer antallet af parametre, der trænes, og kan sænke hukommelseskravene. Resultatet afhænger dog stadig af basemodellen, sekvenslængden, dataene, hyperparametrene, hardwaren og opgaven. Et gennemført træningsjob er ikke det samme som et produktionsklart system.

Det ændrer, hvilke eksperimenter der er økonomisk overkommelige; det beviser ikke, at finjustering er bedre end udformning af prompts eller hentning af data til en bestemt arbejdsbelastning.

Denne artikel beskriver en arbejdsgang til beslutninger og eksperimenter. Leverandørlandskabet blev kontrolleret den 4. august 2026 i OpenAIs meddelelse om udfasning, dokumentationen til Vertex AI-tuning og Hugging Face PEFT.

Når et finjusteringseksperiment er berettiget

Vi dækkede beslutningen kort i Prompts, RAG eller finjustering; her er den længere version.

1. Ensartet format og struktur

Hvis du har brug for output i et meget bestemt format, skal du sammenligne en løsning, der kun bruger prompts, begrænset afkodning og finjustering. Finjustering er ikke automatisk bedre end nogen af referenceløsningerne.

Eksempel: Hvert output skal bestå af præcis fem punkter, der begynder med et udsagnsord og har en bestemt tone. Sammenlign en løsning, der kun bruger prompts, begrænset afkodning, hvor det er relevant, og en finjusteret model på de samme adskilte testeksempler. Der findes ingen generelt overførbar forbedring fra 95 % til 99 % på tværs af opgaver.

En finjusteret kandidat kan reducere behovet for gentagne eksempler eller forbedre overholdelsen i målfordelingen. Mål både semantisk korrekthed og form, fordi en gyldig struktur stadig kan indeholde forkert indhold.

2. Ensartet stil og tone

Hvis en gennemgået promptbaseret reference ikke opfylder fastlagte vurderingskriterier for tone i repræsentative interaktioner, er finjustering én mulig forbedring.

Finjustering på gennemgåede eksempler kan forbedre en måling af, hvor godt tonen rammes, men den nødvendige datamængde og -variation afhænger af arbejdsbelastningen. Tegn en indlæringskurve, og brug blindede menneskelige bedømmelser i stedet for at antage, at virksomhedens tone er indarbejdet i modellen.

3. Specialiseret domæne eller DSL

Hvis dit fagområde har usædvanlig terminologi, et tilpasset DSL eller bestemte mønstre, som basemodellen ikke kender godt:

Eksempel: En virksomhed har sit eget interne forespørgselssprog til data. Basemodellen har aldrig set det før. Eksempler i prompts hjælper, men er ikke tilstrækkelige, fordi modellen stadig laver syntaksfejl.

Et annoteret DSL-korpus kan forbedre andelen af korrekt fortolkede og semantisk korrekte resultater. Mål disse andele mod brug af prompts, grammatisk begrænset generering og hentning af DSL-specifikationen. En fast opskrift med 5.000 eksempler er ikke dokumentation.

4. Mindre model, sammenlignelig kvalitet

En mindre finjusteret model kan undertiden matche en større referencemodel på en snæver måling. Mulige fordele er lavere driftsomkostninger, kortere svartid, lettere selvhosting og mere ensartet adfærd på en afgrænset opgave. Kvantificer dem på præcis den hardware og med den kvantisering, samtidighed og kvalitetsgrænse, du planlægger at bruge.

For en afgrænset arbejdsbelastning med stor volumen skal du beregne, om de målte driftsbesparelser dækker omkostningerne til data, træning, evaluering, idriftsættelse og vedligeholdelse.

5. Adfærdsrelateret sikkerhed

Finjustering kan ændre modellens afvisningsadfærd, men kan også føre til for få eller for mange afvisninger eller forringe andre evner.

Eksempel: Hvis et kundevendt system aldrig må angive forældede priser, skal reglen håndhæves i godkendelsen af værktøjer og valideringen af output. En adfærdsbaseret finjustering kan evalueres som et ekstra lag, men kan ikke gøre forbuddet robust alene.

6. Gentagne eksempler i prompts

Hvis gentagne eksempler optager en væsentlig del af konteksten eller omkostningerne, skal du sammenligne caching af prompts, hentning af kun relevante eksempler og finjustering. En kortere prompt til en finjusteret model er kun nyttig, hvis opgave- og sikkerhedskvaliteten på det adskilte testsæt forbliver acceptabel, og de samlede livscyklusomkostninger falder.

Når finjustering taber

Lige så vigtigt er det at vide, hvornår man ikke skal finjustere.

1. Viden der ændrer sig

Finjusterede modeller er øjebliksbilleder. Ved dynamisk viden som aktuelle begivenheder, kontospecifikke data eller politikker skal autoritative fakta opbevares i styret datahentning eller værktøjer. Finjustering kan påvirke, hvordan modellen bruger den leverede dokumentation, men giver ikke en aktuel og sporbar autoritativ datakilde.

2. Du har ikke nok data

Finjustering kræver repræsentative data, men der findes ikke et universelt minimumsantal. Træn på gradvist større delmængder, og afbild ydeevne på det adskilte testsæt, sikkerhed og varians. Stop med at tilføje data, når indlæringskurven flader ud, eller når manglende dækning af bestemte udsnit, ikke den rå datamængde, er den begrænsende faktor.

3. Basemodellen forbedres hurtigere end du kan holde følge

Basemodeller og driftsmiljøer ændrer sig. En finjusteret model kan miste sin fordel eller ikke længere blive understøttet. Sammenlign den derfor regelmæssigt med en aktuel, fastlåst referencemodel i stedet for at antage, at den ene kandidat vinder.

Uden en klar vedligeholdelsesplan bliver finjustering til teknisk gæld.

4. Du har ikke udført arbejdet med prompts og RAG

Finjustering uden en reference for prompts og datahentning gør det umuligt at fastslå årsagen til resultatet. Byg først disse referencer, så sammenligningen omfatter både kvalitet og samlede driftsomkostninger.

Byg den relevante reference for prompts, begrænset output, datahentning eller værktøjer før finjustering, så resultatet kan tilskrives den rigtige ændring.

5. Du har ingen evalueringer

Finjustering uden evaluering på adskilte testdata kan ikke fastslå, om den hjalp, gjorde skade eller blot overtilpassede de eksempler, der blev undersøgt under udviklingen.

Byg evalueringerne først. Finjuster derefter.

Markedet for finjustering i 2026

Et hurtigt kort over hvad der er tilgængeligt:

Administrerede tjenester

Tilgængeligheden af administrerede tjenester afhænger af leverandør og konto (status bekræftet 2026-08-04):

• OpenAI udfaser selvbetjent finjustering. Nye organisationer kan ikke oprette træningsjob. Inaktive organisationer er omfattet af den dokumenterede 60-dagesregel, og de resterende aktive kunder mister muligheden for at oprette nye job den 2027-01-06 ifølge den officielle meddelelse om udfasning. Eksisterende finjusterede modeller kan kun bruges til inferens, indtil den underliggende basemodel udfases.
• Finjustering i Google Vertex AI. Tilbyder stadig finjustering af Gemini-familien.

Andre administrerede leverandører kan understøtte finjustering, men kontrollér deres aktuelle modelliste, databehandling, muligheder for eksport og leverandørskifte, priser, regionale tilgængelighed og kontokrav i den officielle dokumentation, før de føjes til et beslutningsgrundlag.

For en ny, langsigtet træningspipeline skal du sammenligne de resterende administrerede tjenester med en løsning baseret på modeller med åbne vægte og medregne omkostningerne ved et leverandørskifte. Én leverandørs udfasning beviser ikke, at alle proprietære finjusteringstjenester er på retur.

Beregn omkostningerne ud fra leverandørens aktuelle priser på træning og inferens samt antallet af træningstokens, epoker og kontrolpunkter og den forventede driftsvolumen. Gem den daterede beregning.

En administreret løsning bør kun komme på kortlisten, hvis leverandørens kontrakt og kontrolforanstaltninger passer til dataene, den nødvendige model og finjusteringsmetode understøttes, og de målte totalomkostninger og risici ved leverandørskifte er lavere end ved egen drift. Betegn ikke al proprietær finjustering som forældet på grund af én leverandørs udfasning.

Selvhostet finjustering

Du stiller GPU’er, kode og infrastruktur til rådighed.

• Modeller med åbne vægte: Modelfamilierne omfatter Llama, Qwen, Mistral, DeepSeek, Phi og Gemma. Licenser og anvendelsesvilkår varierer efter model og version. Gennemgå den konkrete artefakt før træning eller distribution.
• Værktøjer: Hugging Face TRL, Axolotl, Unsloth og LLaMA-Factory er mulige kandidater. Fastlås den valgte version, og kontrollér dens understøttelse af model, tokenizer, kvantisering, distribueret træning og eksport.
• Regnekraft: Behovet afhænger af modelstørrelse, kvantisering, sekvenslængde, batchstrategi, optimeringsalgoritme og distribueret opsætning. Indhent et dateret tilbud, eller mål din egen hardware.

Omkostning: træningstokens ÷ målt gennemløb × hardwarepris plus lagerplads, mislykkede kørsler, evaluering, udviklingsarbejde og faglig gennemgang.

Overvej selvhosting, når den valgte model eller datagrænse kræver et eget miljø, og teamet kan drive træning, artefakter, modelservering, opdateringer og gendannelse. Sammenlign målt udnyttelse og personaleomkostninger. Mange træningskørsler beviser ikke i sig selv, at selvhosting er billigere.

Lette eksperimentmiljøer

Til afgrænsede eksperimenter:

• Unsloth på en understøttet GPU. Kontrollér den aktuelle model- og hardwarematrix, og mål den ledige hukommelseskapacitet.
• MLX på Apple Silicon. Egnet til eksperimenter med understøttede små modeller, når modellen kan rummes i hukommelsen.
• Hostede notebook-miljøer. Brugbare til eksperimenter, men sessionsgrænser, lagerplads, databeskyttelse, tilgængelighed og priser skal kontrolleres før brug.

Dette er mulige eksperimentmiljøer, ikke garantier for, at den valgte model kan køre, eller at træningsforløbet virker.

Den praktiske arbejdsgang

For et team, der bygger en produktionsklar finjustering, er arbejdsgangen:

Trin 1: Valider behovet

Før ethvert dataarbejde skal du validere:

• Har du bygget den enkleste relevante reference med prompts, begrænset output, datahentning eller værktøjer?
• Har du evalueringer, der viser, at den nuværende tilgang er utilstrækkelig?
• Kan du præcist formulere, hvad finjusteringen skal gøre bedre?

Hvis forskellen, referencerne, rettighederne, acceptkriterierne, budgettet og driftsløsningen ikke er defineret, skal du ikke starte træningen endnu.

Trin 2: Byg evalueringer

Et gennemført træningsjob dokumenterer ikke en bedre model uden evaluering på et adskilt testsæt.

• Konstruer et adskilt testsæt med tilstrækkelig statistisk styrke, der dækker måladfærden og kritiske udsnit. Begrund størrelsen ud fra forventede fejlrater og beslutningsrisiko.
• Definer målinger: Hvordan ser succes ud? Overholdelse af format, sammenhæng i tone, nøjagtighed osv.
• Reference: Kør evalueringen på basemodellen, og registrer den nuværende score.

Det er nødvendigt for at afgøre, om finjusteringen hjalp.

Trin 3: Forbered og styr dataene

Dette er arbejdets kerne. Kvaliteten af træningsdataene bestemmer kvaliteten af finjusteringen.

Kilder:

• Eksisterende output af høj kvalitet fra dit team.
• Kuraterede historiske kundeinteraktioner.
• Genererede eksempler (brug en stærk model og omhyggeligt udformede prompts).
• Kundespecifikke data (hvor det er relevant; respekter adgangsrettigheder og personhenførbare oplysninger).

Format:

Typisk format til finjustering af chat:

{
  "messages": [
    {"role": "system", "content": "..."},
    {"role": "user", "content": "..."},
    {"role": "assistant", "content": "..."}
  ]
}

Ét eksempel pr. linje i JSONL.

Mængde: Byg en indlæringskurve ud fra gradvist større, stratificerede delmængder. “Mere” er kun en fordel, når de tilføjede eksempler er korrekte, lovligt anvendelige og repræsentative og dækker en målt mangel.

Kvalitet > kvantitet.

Kvalitet, variation og dækning har betydning uafhængigt af antallet. Gennemgå annoteringerne, og fjern næsten identiske dubletter før træning.

Variation.

Datasættet skal dække hele spændet af forventede input. Hvis du kun træner på lette tilfælde, fejler modellen på de svære. Hvis du kun træner på randtilfælde, overkorrigerer den.

Sikkerheds- og afvisningsdata.

Medtag eksempler på passende afvisninger. Ellers bliver finjusterede modeller ofte mere tilbøjelige til at efterkomme enhver anmodning, hvilket forringer sikkerheden.

Opdeling mellem træning og evaluering.

Behold et udviklingssæt til iteration og et afsluttende testsæt, der er isoleret fra træningen, ændringer i prompts og valget af hyperparametre. Vælg størrelser, der bevarer vigtige udsnit. En procentdel alene kan efterlade sjældne risici utestede.

Trin 4: Kør et fastlåst træningseksperiment

For administrerede tjenester med modeller med åbne vægte (Together, Fireworks og lignende) er forløbet: Upload et JSONL-datasæt med chats, start et LoRA-job mod en navngiven basemodel, og vent på en adapter eller et slutpunkt, der kan sættes i drift. De præcise SDK-felter varierer efter leverandør; følg den aktuelle dokumentation til finjustering.

# Leverandørneutralt administreret forløb; dette er ikke et eksempel på en leverandørs API.
# Verificér først aktuelle felter, understøttede basemodeller, priser og opbevaringstid.
upload valideret JSONL → start LoRA-job → evaluér adskilt testsæt → idriftsæt adapter

Ved selvhosting med Axolotl, som er den løsning, denne artikel anbefaler til nyt arbejde:

base_model: Qwen/Qwen3-8B
load_in_4bit: true

adapter: lora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_modules:
  - q_proj
  - v_proj
  - k_proj
  - o_proj

datasets:
  - path: ./data/train.jsonl
    type: chat_template

num_epochs: 3
micro_batch_size: 2
gradient_accumulation_steps: 4
learning_rate: 0.0002
warmup_steps: 100

output_dir: ./output

Kør: accelerate launch -m axolotl.cli.train config.yaml

Registrér hardware, drivere, containerimagets hashværdi, pakkernes låsefil, datasættets hashværdi, antal tokens, gennemløb, faktisk forløbet tid, kontrolpunkter og omkostninger. Udled ikke køretiden af denne skitse.

Hyperparametre, der skal registreres og varieres bevidst: epoker eller trin, plan for læringsrate, optimeringsalgoritme, effektiv batchstørrelse, sekvenslængde og pakning, adapterens rank/alpha/dropout og målmoduler, præcision/kvantisering, opvarmning, interval for kontrolpunkter/evaluering og seed. Tag udgangspunkt i en vedligeholdt opskrift til den konkrete model og fastlåste biblioteksversion. Profilér en lille kørsel, og variér derefter én hypotese ad gangen mod målingerne på det adskilte testsæt og sikkerhedsmålingerne. Brug ikke de illustrative YAML-værdier som standardværdier.

Trin 5: Evaluer

Kør evalueringssættet på den finjusterede model.

• Blev scoren bedre end basemodellens?
• Hvor meget?
• Blev noget forringet (generelle evner, sikkerhed, randtilfælde)?

Klassificér dokumentationen uden at gætte på årsagen: ændringen i målopgaven med konfidens og varians, enhver forringelse i kritiske udsnit, ændringer i kalibrering og sikkerhed, driftsomkostninger og svartid samt uenighed mellem bedømmere. En forringelse kan skyldes data, optimering, formatering, lækage fra evalueringen eller tilfældig varians. Undersøg det med kontrollerede kørsler, før du foreskriver flere data eller andre hyperparametre.

Trin 6: Skygge-, kanarie- og tilbagerulningstest

Før fuld idriftsættelse skal du A/B-teste:

• Start i skyggetilstand, hvor det er praktisk, og vælg derefter kanariegruppens størrelse ud fra skadeomfang, trafik, statistisk styrke og tilbagerulningshastighed.
• Sammenlign målinger: kvalitetsscorer, brugerfeedback og signaler fra efterfølgende systemer.

Træf først beslutningen, når den på forhånd fastlagte stikprøvestørrelse og observationsperiode er opfyldt: Udvid, juster eller rul tilbage.

Trin 7: Sæt i drift med mulighed for tilbagerulning

For administrerede slutpunkter med modeller med åbne vægte: Ret trafikken mod den finjusterede model eller det adapter-id, som leverandøren returnerer.

Ved selvhosting: Vælg en inferensmotor, der udtrykkeligt understøtter den fastlåste basemodel og adapterformatet. Kontrollér dens sikkerhedsvejledning, og mål indlæsning, frigivelse, samtidighed, tilbagerulning og basemodellens/adapterens identitet. vLLM er én kandidat, ikke en universel standard.

Trin 8: Løbende overvågning

Finjusteringen er i produktion. Overvåg:

• Kvalitetsmålinger (onlineevalueringer, brugerfeedback).
• Drift over tid.
• Om forbedringer af basemodellen har lukket forskellen (evaluér regelmæssigt mod den nyeste basemodel).

Trin 9: Hændelsesudløst vedligeholdelse

En finjustering er ikke noget, man sætter i drift én gang og derefter glemmer.

• Basemodellen opdateres: Finjuster regelmæssigt på den nye basemodel.
• Datafordelingen ændrer sig: Opdater træningsdataene, så de afspejler aktuelle mønstre.
• Evalueringspakken udvides: Validér igen, når der kommer nye testtilfælde.

Evaluér igen ved ændringer i datafordelingen, politikken eller basemodellen, nye fejlklynger eller en planlagt aktualitetskontrol. Træn kun igen, hvis den nye kandidat slår den idriftsatte version og klarer alle kontroller for forringelser.

Et gennemarbejdet eksempel

Dette er en modelleret forsøgsplan, ikke en gennemført kørsel: Finjustering af tonen i kundesupport. Axolotl-fragmentet er en indledende hypotese og skal afstemmes med det aktuelle Axolotl-skema og den valgte models modelkort før udførelse.

Problemet: En SaaS-virksomhed har en tydelig, venlig og letforståelig tone i sin kundekommunikation. Prompts rammer den uensartet. Teamet ønsker en pålidelig gengivelse af tonen i al AI-understøttet kommunikation.

Dataplanen: Historiske supporteksempler med afklarede rettigheder, gennemgået databeskyttelse, dokumenteret oprindelse, fjernede dubletter, repræsentative udsnit, bedømmernes etiketter og et adskilt testsæt. Bestem antallet ud fra dækning og en indlæringskurve, ikke ud fra denne artikel.

Tilgangen, der skal testes: LoRA på en kompatibel basemodel med åbne vægte, hvor den indledende rank og antallet af epoker hentes fra en vedligeholdt opskrift. Kør først et lille profileringsjob. Estimér først derefter hardware, samlet køretid og omkostninger. Modeldriften måles separat via en kompatibel inferensserver eller en administreret host.

Hvordan resultatet bedømmes (beslut dette før træning): Lad flere kvalificerede indholdsbedømmere blindt vurdere basemodellens og den finjusterede models udkast på et adskilt udsnit. Definer acceptmargenen og håndteringen af uenighed mellem bedømmerne på forhånd, og bedøm også faktuel korrekthed, opgaveløsning, politikoverholdelse og sikkerhed. Hvis forskellen er uklar, skal du undersøge statistisk styrke, vurderingskriteriernes pålidelighed, datadækning og træningsadfærd; antag ikke én bestemt årsag.

Vedligeholdelse: Evaluér igen, når fordelingen af supportsager, virksomhedens retningslinjer, basemodellen eller fejlregistret ændrer sig. Mål arbejdet pr. cyklus i stedet for at love et bestemt antal dage.

Vi angiver bevidst ikke præcise før- og efterprocenter her: De ville være tal fra vores scenarie, ikke dit, og scorer for toneoverensstemmelse kan ikke overføres mellem datasæt. Når vi offentliggør vores egen målte kørsel, følger evalueringssættet og bedømmelsesprotokollen med.

Sådan ser en testbar plan for finjustering ud. Et vellykket produktionsresultat kræver de manglende kørselsartefakter, kontrolforanstaltninger for idriftsættelse og en målt sammenligning.

Almindelige fejlmønstre

Et par mønstre:

Fejl 1: Overtilpasning. Træningsmålingerne forbedres, mens målingerne på adskilte data eller input med ændret fordeling forringes. Undersøg lækage, dubletter, kapacitet, antal trin, regularisering og dækning af udsnit. Løsningen afhænger af eksperimentet.

Fejl 2: Katastrofal glemsel. Intensiv træning på snævre opgaver forringer de generelle evner. Modellen bliver god til din opgave, men dårligere til andre. Løsning: Sænk læringsraten, brug færre epoker, eller medtag varierede data uden for opgaven.

Fejl 3: Uoverensstemmelse i dataformatet. Træningsdataene er formateret anderledes end den måde, modellen bruges på i produktion. Finjusteringen lærer den forkerte fordeling. Løsning: Sørg for, at formaterne til træning og inferens stemmer præcist overens.

Fejl 4: Utilstrækkelig evalueringsdækning. Evalueringssættet er let, mens produktionen er svær. Finjusteringen scorer godt i evalueringerne, men fejler hos rigtige brugere. Løsning: Medtag svære tilfælde i evalueringerne.

Fejl 5: Kaos i hyperparametrene. Hyperparametrene justeres uden metode. Resultatet bliver nogle gange bedre, andre gange værre, og der opbygges ingen viden. Løsning: Ændr én ting ad gangen, evaluér, og lær.

Fejl 6: Manglende vedligeholdelse. Den idriftsatte adapter evalueres ikke igen efter ændringer i basemodel, modeldrift, data, politik eller arbejdsbelastning. Løsning: Udløs en sammenligning, og træn kun igen, når en ny kandidat klarer kontrolkravene.

Fejl 7: Utilstrækkeligt fokus på sikkerhed. Finjustering kan ændre afvisninger og anden sikkerhedsadfærd i begge retninger. Evaluér for få afvisninger, for mange afvisninger, forsøg på at omgå sikkerhedsregler (jailbreaks) og udsnit med legitim brug. Træningseksempler erstatter ikke deterministiske kontrolforanstaltninger.

Fejl 8: Finjustering efter den forkerte måling. Træningen får modellen til at optimere efter en bestemt måling, men den faktiske brugerværdi er en anden. Løsning: Vælg målinger, der afspejler brugerværdien, ikke kun stedfortrædende mål, som er lette at måle.

Eksperimentskabeloner, ikke kopierede opskrifter

Brug disse som sammenligningsdesign. Vælg model, datamængde, adapterkonfiguration og optimeringsværdier ud fra fastlåst dokumentation til modellen og biblioteket samt profilering og indlæringskurver.

Det strategiske spørgsmål

Ud over det praktiske er finjustering et strategisk spørgsmål:

• Vil vi investere langsigtet i denne kapacitet eller bruge de mest avancerede modeller til alt?
• Er vi villige til at vedligeholde en finjustering på ubestemt tid?
• Er kvalitetsgevinsten den vedvarende kompleksitet værd?

Træf beslutningen ud fra den målte gevinst, begrænsninger i modeldrift og styring samt den løbende vedligeholdelsesbyrde. Den rigtige portefølje kan indeholde ingen finjusteringer, én smal adapter eller flere modeller med hver sin ansvarlige ejer. Denne artikel indeholder ikke undersøgelsesdata, der understøtter et universelt antal.

Sæt selektivt i drift, og vedligehold bevidst

Parametereffektive metoder gør flere tilpasningseksperimenter teknisk mulige for små teams. Tidsplanen og produktionsomkostningerne afhænger fortsat af arbejdsbelastningen og skal omfatte data, evaluering, modeldrift, styring og vedligeholdelse, ikke kun regnekraft til træning.

»AI er ikke god nok« er ikke et træningsmål. Navngiv den fejlslagne opgave og det relevante udsnit, byg den relevante reference, afklar datarettighederne, fastlæg acceptkrav og kontrolpunkter for forringelser, og test derefter, om finjustering tilfører værdi. Varige gevinster kan kun dokumenteres med gentagne målinger på adskilte testdata samt dokumentation for sikkerhed, modeldrift og vedligeholdelse af det idriftsatte system.