Lokal LLM/GenAI behandling

Mange organisationer har forsøgt at køre lokale LLM-modeller på eget lukket netværk, men med skuffende resultater eller direkte fiasko. Typiske fejl er intuitive, men uheldige: man vælger en enkelt, stor model eller én generel pipeline og forventer, at den kan klare alle typer data og opgaver. Resultatet bliver uforudsigeligt output, langsom fejlsøgning og projekter, der aldrig kommer i drift. Vi præsenterer her en række nedslagspunkter, som typisk kan vende fiasko til succes og gøre lokale modeller brugbare i praksis.

Først: hvorfor overveje lokale modeller? Cloud-baserede løsninger tilbyder skalerbarhed og hurtig innovation, men medfører velkendte risici: øget eksponering af følsomme data, uklarheder i behandlingsansvar, regulatorisk kompleksitet og udfordringer med audit og sporbarhed. Selv med kryptering, kontrakter og "livrem og seler"-tilgange kan man ikke altid opnå den kontrol og synlighed, som mange organisationer har brug for. Lokale LLM’er er derfor ikke nødvendigvis et kompromis, men et bevidst arkitekturvalg der prioriterer kontrol, forudsigelighed og sikkerhed.

Arkitekturmæssigt er der tre overordnede rammer: udelukkende cloud, udelukkende lokal (on-prem/edge) og hybride løsninger. Når data er følsomme, omfattende eller latency-kritiske, fører fjernbehandling både til sikkerhedsrisici og driftsmæssige udfordringer. Derfor er grundreglen: flyt behandlingen tættere på data. Det betyder at størstedelen af præ- og hovedbehandlingen bør ske lokalt, mens cloud kun bruges til ikke-følsomme aggregater, tunge træningsjob eller oversummering hvor risikoen er acceptabel.

En hybrid tilgang som mønster: hold rådata og de fleste analyser inden for organisationens netværk, eksporter kun metadata, anonymiserede resultater eller kompakte summeringer til skyen. Det begrænser dataeksfiltration, reducerer regulatorisk kompleksitet og bevarer lav latency for kritiske funktioner. Samtidig giver det mulighed for at bruge cloud til periodiske opgaver, backups eller modelopdateringer uden at undergrave governance.

En afgørende myte at aflive er: større modeller er altid bedre. Store modeller kan ofte abstrahere og generalisere på et direkte brugbart niveau. De kan improvisere struktur og løsningsstrategi, men det gør dem mindre forudsigelige. Mindre modeller leverer derimod, hvis de promtes rigtigt, en lidt højrere grad af stabilitet og ensartethed, men kun hvis data og instrukser passer til deres formåen og er forkuseret ind på formålet. Derfor er systemdesign og instruktionskvalitet ofte vigtigere end blot modelstørrelse, hvis du skal arbejde lokalt. 

Hovedprincippet vi anbefaler er: nedbrydning af behandlingsgrundlaget. Små modeller sjældent lykkes, hvis de præsenteres for brede og ustrukturerede datasæt. Fragmentering — at opdele data i små, konsistente enheder — er en forudsætning for stabil kvalitet. Hvor en stor model kan acceptere et helt dokument og selv strukturere arbejdet, vil en lille model typisk fejle, hvis ikke input er præcist afgrænset.

Hvordan ser fragmentering ud i praksis? Eksempler: ved udtræk fra fagsystemer eller ESDH bør data opdeles i enkelte dokumentafsnit, individuelle transaktioner, enkelte journalnotater eller afgørelsesdele. For en sag i et ESDH-system kan det betyde at journalnotat, metadata, bilag og afgørelsestekst håndteres som separate enheder. For økonomiske systemer bør hver post eller transaktion være en selvstændig enhed. Den afgørende pointe er, at opdelingen bør ske automatisk og konsekvent allerede ved datakilden — ikke ad hoc i analyselaget.

Når vi går fra data til behandling, ændrer modeladfærden sig. Store modeller er mere tilbøjelige til selv at tilpasse struktur og finde løsninger uden detaljerede instrukser. Små modeller følger derimod instrukser bogstaveligt og korrigerer sjældent sig selv. Det gør dem forudsigelige — men kun hvis instruktionerne er klare og eksemplerne konsistente.

Derfor er et varieret instruktionssæt nødvendigt. I stedet for én generel prompt bør man arbejde med flere specialiserede instrukser målrettet konkrete fragmenttyper. Hver instruks bør versioneres, testes og dokumenteres. Jo mere entydig og snæver en instruks er, jo mere forudsigeligt og reproducerbart bliver resultatet.

Et konkret eksempel: økonomiske transaktioner. Forestil dig et instruktionsbibliotek opdelt efter valuta, fx én instruks til DKK-transaktioner og én til EUR. Første trin er et letvægts beslutningstrin, hvor en simpel model eller regel vurderer transaktionens valuta og vælger den relevante instruks. Andet trin er den egentlige analyse: udtræk af beløb, kontraktreferencer, modpart, kontoer og validering mod forretningsregler — udført af en model der er instrueret præcist til netop den type transaktion.

Princippet om adskillelse mellem beslutning og behandling er centralt. Små modeller præsterer bedre, når kontekstvalg (hvilken instruks, hvilken model) adskilles fra den komplekse analyse. I stedet for at lade én model både identificere dokumenttype og udføre detaljeret udtræk, lader man et letvægtsvalgtrIN (decision) pege på en specialiseret behandlingsinstruks. Samme mønster fungerer i juridske domæner: først identificeres dokumenttype og fase, derefter køres domænespecifik udtræk/klassifikation.

Arkitekturen er et genbrugeligt mønster: fragmentér data, vælg instruktion, kør specialiseret behandling. Det gælder både talbaserede arbejdsgange og prosatekst: klassifikation, validering, udtræk og vurdering kan bygges som modulære trin. Mønstret er skalerbart — nye fragmenttyper tilføjes ved at implementere nye instrukser og testcases, ikke ved at træne kæmpestore generelle modeller.

Implementeringsmæssigt betyder det konkret: automatiser fragmenteringen ved kilden; opbyg et versioneret bibliotek af instrukser; implementer en letvægts orkestrator som foretager beslutningsvalget og styrer sekvensen af behandlingstrin; log og auditér hvert trin for sporbarhed. Test grundigt med realistiske datasæt og implementer rollback-mekanismer for at sikre forudsigelighed i drift.

Operationelle anbefalinger til at komme i gang: start med dataarkitekturen — identificer kilder og design automatiseret fragmentering. Dernæst definer et instruktionsbibliotek til de mest værdifulde fragmenttyper og test disse iterativt. Indfør en letvægts orkestrator til beslutningsvalg og fejlisolering. Brug cloud kun til opgaver, hvor gevinsten klart opvejer risici: træning af store modeller, ikke-følsom batch-analyse eller globale oversigter.

Afslutningsvis: lokale, mindre LLM’er kan levere forretningskritiske, sikre og forudsigelige resultater — men kun hvis man designer systemet rigtigt. De vigtigste succesfaktorer er: (1) flyt så meget behandling som muligt tæt på data, (2) fragmentér data konsekvent ved kilden, (3) brug målrettede og versionerede instrukser, og (4) adskil beslutningsvalg fra kompleks behandling. Prioritér kontrol, sporbarhed og stabilitet frem for jagten på størst mulig generel intelligens — det er netop denne strategi, der gør lokale modeller brugbare og kan vende mange tidligere fiaskoer til succes.