Whitepaper · modelvalg til regeloverholdelse

Hvad får man ved en stor model — og hvad koster det?

En guide til at vælge og hoste en sprogmodel, der skal svare ud fra jeres eget regelsæt. Bygget på målinger og etableret forskning, ikke løfter.

»Hvor stor en model har vi råd til?« er det forkerte første spørgsmål. Størrelse køber sprog og bredde, men ikke troværdig hentning af jeres regler, og en for stor model bærer sine egne omkostninger. Denne guide går fem skridt fra hvad størrelse egentlig køber, til hvordan I selv kan efterprøve pålideligheden.

Indhold

Vi måler, hvad jeres opgave faktisk kræver, og vælger den mindste model, der klarer det med margin. Hele metoden bag tallet er åben, så I selv kan efterprøve den.

Del 1

»Stor« er tre ting, ikke én

En sprogmodels evner ligger på tre uafhængige akser. Kunder, og en del leverandører, behandler dem som én skala fra lille til stor. Forskellen mellem de tre er hele forskellen mellem et system, der lyder overbevisende, og et, der er til at stole på.

Akse 1

Træningsmængde

→ hvad den ved om verden

Hvor meget og hvor bredt modellen er trænet, bestemmer dens almenviden. Den viden er lagret som en fast, databestemt kapacitet2 og dækker dårligt de sjældne spørgsmål3.

Køber ikke: kendskab til jeres korpus. Modellen har aldrig set jeres håndbog. Det er retrieval'ens opgave at citere jeres regel, ikke størrelsens.

Akse 2

Parametre

→ hvor flydende den skriver

Antallet af parametre bestemmer, hvor velformuleret modellen skriver, og hvor sammensat en opgave den kan holde styr på i ét svar1. En større model tåler også flere konkurrerende krav, før overholdelsen falder.

Køber ikke: bedre hentning. En stor model skriver et overbevisende svar, også når det er forkert.

Akse 3

Arkitektur

→ sikkerhed + korrekt hentning

At modellen henter den rigtige regel, holder sig til den og afstår, når svaret mangler, bygges i laget omkring modellen: scoping (RAG), grounding-tjek og en kalibreret tærskel.

Her ligger garantien. Sikkerheden kommer herfra. En for lille model afstår; den fabrikerer ikke.

Akse 1 og 2 stiger med størrelsen. Akse 3 gør ikke; den bygges, uanset modelstørrelse. Netop dér, hvor almenviden svigter på det sjældne spørgsmål, henter god retrieval svaret bedre end den store models parametriske hukommelse4.

En større model køber bredere verdensviden og smukkere sprog. Bedre hentning af jeres regler køber den ikke. Den garanti kommer fra arkitekturen.

Del 2

Fittet til jeres opgave er en omvendt U

Hvis en større model altid var bedre, var valget nemt. Men fittet til en konkret opgave er en omvendt U: for lille kan ikke anvende reglen, for stor begynder at over-anvende den, og imellem ligger det rigtige valg. Det afgørende tal er hverken størrelsen eller antallet af regler, men C = konkurrerende direktiver pr. tur: hvor mange krav der strides om modellens opmærksomhed i det samme svar.

Brugbar regeloverholdelse mod modelstørrelse
FOR LILLE kan ikke anvende reglen FOR STOR over-afviser · dyr · ikke on-prem DET RIGTIGE VALG mindste model der rydder jeres C MODELSTØRRELSE → BRUGBAR REGELOVERHOLDELSE

Ud over prisen og latenstiden bærer den store model fire målbare omkostninger, som forskningen er tydelig om:

Over-afvisning stiger

Jo mere alignet en model er, jo mere afviser den også lovlige spørgsmål, der blot ligner noget forbudt eller udækket89. For en compliance-assistent bliver det til »det kan jeg ikke hjælpe med« på legitime spørgsmål. Det er den sikre fejltype, for den sender brugeren til et menneske, men den koster stadig brugbarhed.

Ikke mere trofast i RAG

Selv de største modeller hallucinerer mod den tekst, de får udleveret121314. Flere parametre løser ikke grounding-problemet.

Kan være mindre sandfærdig

I visse tilfælde gengiver de største modeller udbredte misforståelser mere overbevisende og er dermed mindre sandfærdige5. Effekten er ofte U-formet og ingen lov6.

Sykofanti

Mere alignede modeller har tendens til at give brugeren ret og overtage brugerens ramme frem for at korrigere den7. Det er problematisk, når svaret burde være nej.

Den hyppigste misforståelse: »store modeller ved bedre, hvornår de tager fejl«

Det passer for rå, fortrænede modeller11. Men den alignment-træning, der gør en model hjælpsom, forringer typisk kalibreringen igen og gør den overmodig10. Kalibrering er en effekt af hvordan modellen er efterbehandlet, ikke af hvor mange parametre den har. Derfor måler og kalibrerer vi den pr. model, sprog og korpus.

Del 3

Hvor skal modellen køre?

Der er ikke ét rigtigt sted at hoste en compliance-assistent. Det afhænger af, hvor databevidst og jurisdiktions-følsom jeres organisation er. Herunder rister vi mulighederne op med fordele og ulemper, så I kan træffe valget på et oplyst grundlag. Leverandørerne er nævnt for at vise landskabet, ikke som anbefalinger.

To akser der forveksles

Oprindelse

Hvem har lavet modellens vægte. EU-oprindelse (EuroLLM, Mistral) styrker en »rent europæisk«-fortælling; amerikansk eller kinesisk oprindelse (Llama, Qwen, GLM) kan stadig hostes i EU.

Hosting

Hvor og af hvem modellen kører. Det er hosting, ikke vægtenes oprindelse, der afgør, hvor persondata fysisk ligger. GDPR følger hosting og data.

MulighedDatalokationJurisdiktion / ejerAmerikansk lov-eksponeringGPU & prisDrift-byrde
Egen hardware / on-premeget serverrumJeres egne lokalerJeres egen — fuld kontrolIngenI anskaffer GPU selv (capex)Høj
EU-ejet cloudHetzner · Scaleway · OVHcloudEU-datacenterEU-selskabIngenGod; ofte billig (Hetzner)Middel
US-hyperscaler, EU-regionAWS · Azure · Google CloudEU-region (data i EU)Amerikansk moderselskabJa — CLOUD Act / FISAStørst udbud + managedLav
Managed EU-inferenceScaleway · Mistral-APIEUEU-selskabIngenBetal pr. kald; ingen GPU-driftLav

Egen hardware / on-prem

selv-hostet · eget serverrum eller egen GPU

Fordele

  • Data forlader aldrig huset — stærkeste suverænitet og revisions-forsvarlighed.
  • Ingen tredjepart, ingen udenlandsk lov-eksponering.

Ulemper

  • Høj startinvestering i GPU-hardware, som I selv skal skaffe.
  • Hele driften ligger hos jer, og det er svært at skalere efter behov.

Passer typisk til: stærkt regulerede eller meget databevidste organisationer med egen it-drift.

EU-ejet cloud

Hetzner (DE) · Scaleway (FR) · OVHcloud (FR)

Fordele

  • EU-datacenter og EU-ejerskab, uden amerikansk moder og uden CLOUD Act-eksponering.
  • Ren europæisk fortælling, som mange offentlige og databevidste kunder foretrækker.
  • Ofte konkurrencedygtig eller lav pris.

Ulemper

  • GPU-udbuddet er ikke altid så bredt som hos hyperscalerne.
  • I drifter stadig selve modellen.

Passer typisk til: kommuner og databevidste virksomheder, der vil holde alt i EU uden on-prem-byrden.

US-hyperscaler i EU-region

AWS · Microsoft Azure · Google Cloud

Fordele

  • Bredeste GPU-udbud og fuldt managed inference — laveste drift-byrde.
  • Data kan holdes i en EU-region, og der findes voksende »sovereign«-tilbud.

Ulemper

  • Moderselskabet er omfattet af amerikansk lov (CLOUD Act, FISA 702), der i princippet kan kræve udlevering, også for data i en EU-region.
  • Kræver et gyldigt overførselsgrundlag (Data Privacy Framework / standardkontrakt) for at være GDPR-forsvarligt.
  • Mange offentlige myndigheder fravælger det af hensyn til suverænitet, selv når det formelt er lovligt.

Passer typisk til: kommercielle virksomheder uden skarpt suverænitetskrav, der prioriterer kapacitet og lav drift.

Managed EU-inference (API)

Scaleway Generative APIs · Mistral La Plateforme

Fordele

  • Ingen GPU-drift — I betaler pr. kald og kommer hurtigt i gang.
  • EU-udbyder betyder EU-jurisdiktion uden amerikansk lov-eksponering.

Ulemper

  • Mindre modeludvalg; I er bundet til udbyderens katalog.
  • Løbende pris pr. kald kan overstige egen drift ved meget høj last.

Passer typisk til: mindre opsætninger og piloter, der vil i gang hurtigt og holde alt i EU.

Hosting-valget ændrer ikke modellens pålidelighed

Hvor modellen kører, afgør jurisdiktion, pris og drift, men ikke om den henter jeres regel korrekt eller afstår, når svaret mangler. Den pålidelighed er en egenskab ved arkitekturen og måles pr. model, sprog og korpus, uanset hvilken af de fire muligheder I vælger.

Bemærk: teknisk oversigt, ikke juridisk rådgivning. Lovligheden af en given overførsel eller udbyder bekræftes af jeres egen databeskyttelses-/juridiske funktion.

Del 4

Hvad vejer tungest hos jer?

Guiden herunder omsætter de tre foregående dele til ét opslag: find det hensyn, der vejer tungest hos jer, så følger et konkret udgangspunkt for model og hosting. Vi bekræfter det altid ved måling på jeres eget regelsæt; guiden peger, den beslutter ikke.

Hvis dette vejer tungest

Suverænitet og reviderbarhed

Ofte hvor I er en offentlig myndighed, arbejder under god forvaltningsskik, eller kan blive bedt om at gøre rede for en afgørelse over for et tilsyn.

Så peger det mod den mindst mulige model, hostet on-prem eller i en EU-ejet cloud, hvor reviderbarhed vejer tungere end den sidste procent dækning.

Målingen giver jer et fuldt spor pr. tur (beslutning, kilde og grounding), så en afgørelse kan gøres rede for over for et tilsyn. Dansk måles separat, og systemet henviser til en sagsbehandler frem for at træffe en automatisk afgørelse.

Hvis dette vejer tungest

Dokumenterbar databeskyttelse

Ofte hvor I behandler persondata, vil kunne vise, at den bliver i EU, og hellere vil se belæg end løfter.

Så peger det mod en mellemstor model, der klarer jeres C med margin, hostet i en EU-ejet cloud eller på managed EU-inference.

Målingen giver jer fabrication-modstand og afståelses-rater målt pr. sprog, dokumentation for at data bliver i EU, og belæg for at modellen afstår ved dækningshuller frem for at opdigte, klar til jeres egen egenkontrol under art. 15 og 9.

Hvis dette vejer tungest

Brugbarhed, hastighed og pris

Ofte hvor I først og fremmest vil have det til at virke, holde drift-byrden nede, og hvor hosting-stedet er mindre vigtigt, så længe det er lovligt.

Så peger det mod en størrelse valgt til at maksimere dækning på jeres C, hostet dér hvor det er nemmest og billigst, også en US-hyperscaler i EU-region, hvis persondata-eksponeringen er lav.

Målingen giver jer dækning og over-afvisning målt sammen, så systemet ikke irriterer brugerne med falske afvisninger, og en tærskel kalibreret til jeres smertegrænse.

De færreste vægter kun én ting. Vejer to hensyn lige tungt, bliver valget en afvejning, og den måler vi jer frem til i stedet for at gætte den.

Del 5

Sådan måler vi — hele opskriften bag hvert tal

Et pålidelighedstal er kun værd at stole på, hvis I kan se, hvordan det blev til. Herunder er metoden i kort form; den fulde, følgbare protokol står i bilaget.

Hvad vi måler

Vi tester ikke bare »svarer den rigtigt?«. Vi deler spørgsmålene op i fire typer, der hver afdækker sin egen fejltilstand, for de farlige fejl gemmer sig i, hvad modellen gør, når svaret ikke står i teksten.

SpørgsmålstypeForventetMåler
Dækket spørgsmålsvaret står i en politikSVAR + faktaDækning — kan den svare, når svaret findes?
Ligner udækketsvarbart, men skævt formuleretSVAR + faktaOver-afvisning — afviser den lovlige spørgsmål?
Nabo-emnerelateret politik, svaret ikke i denAFSTÅFabrikation fra en beslægtet-men-utilstrækkelig regel
Helt udækketintet i korpusset dækker emnetAFSTÅFabrikation, når der intet er at gætte ud fra

Hvordan vi gør tallet troværdigt

  1. Nok spørgsmål. Mindst 30–40 pr. type pr. sprog, og hvert tal ledsages altid af sit 95 %-konfidensinterval.
  2. Vi udfordrer vores egne spørgsmål. En stærkere, uafhængig model, blind for vores facit, tjekker om hvert spørgsmål faktisk er svarbart fra den hentede tekst. Er den uenig med vores mærkat, kasseres spørgsmålet og logges, også vores egne håndlavede.
  3. Retrieval-integritet først. Før et spørgsmål tæller, verificerer vi, at søgningen henter den rigtige politik, så vi ikke måler en søgefejl.

Knapperne vi kalibrerer — ingen skjulte standardværdier

CONFIDENCE-tærskel

Hvor usikker modellen må være, før den afstår.

pr. model × korpus

Dæknings-tærskel

Hvor godt søgningen skal ramme, før der er nok at svare ud fra.

pr. korpus

Grounding-strenghed

Hvor forankret svaret skal være i de hentede uddrag.

pr. model

Instrument-tjek før brug

Spredning: mindst 30 procentpoints forskel mellem den letteste og sværeste type på modellen, ellers er testen »masket«. Tjekkes pr. model.
Format-match: vi profilerer i samme svarformat, som vi evaluerer i.
Pr. sprog: en kurve målt på ét sprog overføres ikke til et andet. Hvert sprog måles separat.
Fuld dataprotokol pr. svar: beslutning, begrundelse, kilde, grounding og rådata gemmes, så enhver metrik kan genberegnes ved audit.

Misbrug måles også

Input-laget, der afviser misbrug, måles på to tal, fordi det ene uden det andet er værdiløst: hvor stor en andel af misbrug det fanger (recall), og hvor mange legitime følsomme spørgsmål det fejlagtigt afviser (precision-kontrol). En gate, der afviser alt, scorer perfekt på det første og ubrugeligt på det andet.

Hvorfor vise hele opskriften?

Fordi et pålidelighedstal, I ikke kan efterprøve, ikke er værd at have. Alt herover kan I køre igen på jeres eget regelsæt. De færreste gør det, men muligheden er hele forskellen mellem en påstand og et bevis. Den fulde protokol står i bilaget herunder.

Bilag

Den fulde måle-protokol

Bilaget er den præcise, følgbare udgave af metoden i del 5, som I kan reproducere. Vi publicerer den, fordi værdien ligger i at køre den rigtigt, kalibrere den pr. model, sprog og korpus, og aflevere et dateret bevis, ikke i at holde metoden hemmelig.

Konstruktion for et nyt regelsæt

  1. Korpus: kundens regelsæt, uændret. Segmentér i enheder.
  2. Seed-spørgsmål pr. enhed, i alle relevante sprog med ét per fejltilstand.
  3. Maskin-tjekbare kernefakta (regex over svaret) for de svarbare typer, så korrekthed scores uden en subjektiv dommer.
  4. Ingen teach-to-test: eval-spørgsmål deler ikke indhold med nogen trænings-/installationsdata.

Selvbetjening — auto-genereret målsæt fra vilkårligt korpus

Målsættet kan genereres automatisk fra et uploadet regelsæt. De auto-genererede spørgsmål går gennem præcis samme adversarielle kontrol som de håndbyggede, og drop-raten rapporteres. Uploadet indhold behandles som data, aldrig som instrukser: indirekte prompt-injection screenes og flages, før noget deployes.

Re-validering og rapportering

Målsættet gen-bygges og gen-valideres, når korpus eller regler ændres, ved nyt sprog, eller ved model-skift (løbende risikostyring, art. 9), og versioneres som al anden data. Hver rate ledsages af antal + 95 %-CI og en note om, at spørgsmålstyperne er adversarielle diagnostik-arme, ikke repræsentativ trafik, og begge nævnere angives.

Forskningsgrundlag

  1. Kaplan, J., et al. (2020). Scaling Laws for Neural Language Models. doi:10.48550/arxiv.2001.08361
  2. Allen-Zhu, Z., & Li, Y. (2024). Physics of Language Models: Part 3.3, Knowledge Capacity Scaling Laws. doi:10.48550/arxiv.2404.05405
  3. Kandpal, N., et al. (2023). Large Language Models Struggle to Learn Long-Tail Knowledge. doi:10.48550/arxiv.2211.08411
  4. Mallen, A., et al. (2023). When Not to Trust Language Models. ACL 2023. doi:10.18653/v1/2023.acl-long.546
  5. Lin, S., Hilton, J., & Evans, O. (2022). TruthfulQA. ACL 2022. doi:10.18653/v1/2022.acl-long.229
  6. McKenzie, I. R., et al. (2023). Inverse Scaling: When Bigger Isn't Better. doi:10.48550/arxiv.2306.09479
  7. Sharma, M., et al. (2023). Towards Understanding Sycophancy in Language Models. doi:10.48550/arxiv.2310.13548
  8. Cui, J., et al. (2024). OR-Bench: An Over-Refusal Benchmark. doi:10.48550/arxiv.2405.20947
  9. Röttger, P., et al. (2024). XSTest. NAACL 2024. doi:10.18653/v1/2024.naacl-long.301
  10. Tian, K., et al. (2023). Just Ask for Calibration. EMNLP 2023. doi:10.18653/v1/2023.emnlp-main.330
  11. Kadavath, S., et al. (2022). Language Models (Mostly) Know What They Know. doi:10.48550/arxiv.2207.05221
  12. Niu, C., et al. (2024). RAGTruth. ACL 2024. doi:10.18653/v1/2024.acl-long.585
  13. Chen, J., et al. (2024). Benchmarking LLMs in Retrieval-Augmented Generation (RGB). AAAI 38(16). doi:10.1609/aaai.v38i16.29728
  14. Ming, Y., et al. (2024). FaithEval. ICLR 2025. doi:10.48550/arxiv.2410.03727

Ansvarsfraskrivelse: teknisk vejledning og måling, ikke juridisk rådgivning. Tallene understøtter deklaration under forordning (EU) 2024/1689 art. 15 (nøjagtighed/robusthed) og art. 9 (løbende risikostyring); den juridiske klassificering bekræftes af jeres egen compliance-funktion. Nævnte leverandører er eksempler, ikke anbefalinger.