Spring til indhold
← Tilbage til bloggen
Teknologi 19. maj 2026 · 7 min læsning

Finjustering af åbne modeller på dine egne data

Når prompt engineering ikke er nok: hvordan man specialiserer en åben model på dit domæne – privat.

Finjustering af åbne modeller på dine egne data

Store sprogmodeller ankommer forudtrænede på enorme mængder af det offentlige internet. Den bredde gør dem imponerende generelle – men generelle er ikke det samme som eksperter. Når din virksomhed har brug for en model, der forstår din interne taksonomi, skriver i din husstil eller ræsonnerer om proprietære processer, åbner tre tilpasningsstier sig: prompt engineering, retrieval-augmented generation (RAG) og finjustering. Hver har sin plads, og at vælge den rigtige – eller den rigtige kombination – kan gøre forskellen mellem en prototype og et produktionssystem. Privonis hjælper europæiske organisationer med at navigere det valg og udføre det helt inden for deres egen infrastruktur.

Tre veje til domænetilpasning

Prompt engineering koster intet ud over prøve-og-fejl, men det støder på en hård mur: du kan kun passe så meget kontekst i et vindue, og modellen mangler måske simpelthen den domæneviden, du har brug for. RAG omgår kontekstgrænsen ved at hente relevante chunks fra en vidensbase ved forespørgselstidspunktet og overlevere dem til modellen. Det er kraftfuldt og overraskende billigt, men retrieval-kvalitet begrænser svar-kvalitet – hvis det rigtige chunk ikke findes, kan modellen ikke ræsonnere om det.

Diagram der sammenligner prompt engineering-, RAG- og finjusterings-workflows
Retrieval-augmented generation tilføjer et søgetrin inden inferens; finjustering bager viden ind i vægtene.

Finjustering tager en anden tilgang: det opdaterer modellens vægte på dit kuraterede datasæt, så domæneviden bliver iboende. Resultatet er en model, der svarer ud fra internaliseret ekspertise frem for hentede uddrag. Den klarer sig typisk bedre til stil-sensitive opgaver, strukturerede output og latenstidskritiske pipelines, hvor du ikke har råd til et ekstra retrieval-tur-retur. Ulempen er omkostning – både GPU-tid og dataforberedelse – så det er værd at nå efter, når de to andre metoder er plafonerede.

Hvornår finjustering er det rigtige valg

  • Dine output skal følge et præcist format (kliniske noter, juridiske klausuler, struktureret JSON), som prompt-skabeloner ikke pålideligt kan håndhæve.
  • Modellen mangler konsekvent domænevokabular, akronymer eller produktnavne, der aldrig optrådte i dens forudtrænede korpus.
  • Latenstidskrav udelukker et retrieval-hop ved hver forespørgsel.
  • Du vil komprimere en kompleks, multi-shot prompt til nul-shot-adfærd for omkostninger og hastighed.
  • Du destillerer en større model ind i en mindre, billigere til edge- eller on-premise-implementering.

LoRA og QLoRA: finjustering uden et datacenters budget

Fuld finjustering opdaterer hvert vægt i modellen, hvilket er uoverkommeligt dyrt for modeller med titusindvis af milliarder parametre. Low-rank adaptation (LoRA) omgår dette ved at injicere små trænbare matricer i opmærksomhedslagene, mens de originale vægte fastholdes. Antallet af trænbare parametre falder med en faktor på 100 eller mere, alligevel matcher eller overgår den resulterende model fuld finjusterings-kvalitet på de fleste opgaver. QLoRA tilføjer kvantisering til blandingen – den fastholdte basismodel indlæses i 4-bit præcision, hvilket slasker GPU-hukommelseskravene så dramatisk, at en 70-milliards-parameter model kan finjusteres på en enkelt A100.

Illustration af GPU-hukommelsesbesparelser fra QLoRA sammenlignet med fuld finjustering
QLoRA reducerer peak GPU-hukommelse med op til 75 %, hvilket gør finjustering tilgængelig på en enkelt high-end GPU.
Med QLoRA kan et team, der ejer én A100, finjustere en state-of-the-art åben model på en eftermiddag – ingen cloud-konto, ingen data der forlader bygningen.

Dataforberedelse: det afgørende trin

Modelkvalitet er begrænset af datakvalitet. Inden en træningskørsel samarbejder Privonis med klienter om at kurere et overvåget datasæt af input-output-par, der repræsenterer den nøjagtige adfærd, de ønsker. Typiske kilder inkluderer: gennemgåede kundeinteraktioner, korrigerede modeloutput, ekspertannoterede dokumenter og syntetiske data genereret af en stærkere lærermodel og derefter filtreret. Volumen betyder mindre end mangfoldighed og korrekthed – tusinde omhyggeligt gennemgåede eksempler overgår ofte ti tusinde støjende. Datarensningspipelines håndterer deduplikering, længdebeskæring og formatnormalisering inden træning begynder.

Evaluering: at vide, hvornår du er færdig

Finjustering uden streng evaluering er optimering i mørket. Et tilbageholdt evalueringssæt – aldrig set under træning – måler, om modellen har generaliseret eller blot memoreret. Målinger afhænger af opgaven: eksakt match og F1 for ekstraktionsopgaver, ROUGE til opsummering, menneskelige præferencevurderinger til åben generering. Privonis kører automatiserede evalueringer efter hvert checkpoint og markerer katastrofal glemme – tilfælde, hvor modellen vinder domænefærdigheder, men mister generel ræsonnering – ved at inkludere en standardbenchmark-prøve i hvert evalueringssæt.

Vægtene er dine

Dette er det punkt, der ofte går tabt i diskussioner om cloud-hosted finjusterings-API'er: når du finjusterer via en tredjeparts tjeneste, kan de resulterende vægte være låst til den udbyder. Med Privonis er basismodellen open-weight, træningskørslen sker på hardware, du kontrollerer, og LoRA-adapteren eller det fusionerede checkpoint er dit at beholde, versionere og implementere, hvor du vil. Det betyder ingen vendor lock-in, intet pr.-token-gebyr på en model, du betalte for at træne, og ingen risiko for at udbyderen gentræner på dine data. For europæiske virksomheder, der håndterer følsomme oplysninger, er det at beholde vægtene ikke en nice-to-have – det er et styringskrav.

Lad os tale om dit AI-projekt

Book et opkald