Forside › eDiscovery teknisk · Gennemgået oktober 2026 · Af John Nielsen
En søgeterm er ikke et ord, men en instruktion til en bestemt søgemotor. Samme term kan give vidt forskellige resultater i forskellige værktøjer, fordi de deler tekst op i ord på forskellig måde, understøtter forskellige operatorer og behandler bøjninger, sammensatte ord og specialtegn forskelligt. På dansk er især sammensatte ord og æ, ø og å kilder til både oversete dokumenter og falske hits.
Hvordan ledelse og HR vælger søgeordene i en intern undersøgelse, er beskrevet på bevissikring-digitalt.dk: → Søgeord i en intern undersøgelse. Aftaler med modparten er beskrevet på digital-bevissikring.dk: → Søgeord og afgrænsning. Her handler det om den tekniske oversættelse af ordene til søgninger.
Sådan søger en søgemotor
De fleste eDiscovery-værktøjer søger i et indeks, ikke i selve filerne. Ved indeksering deles teksten op i tokens, typisk ord adskilt af mellemrum og tegnsætning. Søgningen sammenligner termerne med tokens. Tre forhold afgør resultatet:
- Tokenisering. Hvordan bindestreger, punktummer, snabel-a og tal behandles. “IT-afdeling” kan blive ét token, to tokens eller begge dele.
- Normalisering. Om store og små bogstaver og diakritiske tegn udlignes.
- Stopord. Om almindelige ord som “og” og “i” er udeladt af indekset og derfor ikke kan søges på.
Indstillingerne er ofte faste i værktøjet og ikke synlige for brugeren. Test dem, før søgninger aftales.
Operatorer
Boolske operatorer
AND, OR og NOT kombinerer termer. Parenteser styrer rækkefølgen. Uden parenteser kan “kontrakt OR aftale AND leverandør” tolkes på to måder afhængigt af operatorernes prioritet i værktøjet. Skriv altid parenteser.
NOT er farlig i eDiscovery, fordi den udelukker hele dokumenter. En mail, der indeholder både det relevante emne og et udelukket ord, forsvinder.
Fraser
Anførselstegn søger efter ord i præcis rækkefølge. Fraser er præcise, men sårbare over for bøjning, linjeskift og tegnsætning midt i frasen. “Fortrolig aftale” finder ikke “fortrolige aftaler”.
Nærhed
Nærhedssøgning finder ord inden for et bestemt antal ord fra hinanden. Syntaksen varierer: w/5, NEAR/5, NEAR(5) eller “ord1 ord2″~5. Nogle værktøjer tæller ord i begge retninger, andre kun fremad. I Microsoft Purview eDiscovery bruges KQL-syntaksen ord1 NEAR(n) ord2, hvor n er det højeste antal ord mellem de to søgeord. Angives intet tal, er standardafstanden 8 ord. → Microsoft Purview eDiscovery
Nærhed er ofte bedre end fraser, fordi den tåler bøjninger og indskudte ord, men den fungerer kun med tokens, som indekset faktisk indeholder.
Wildcards og trunkering
Stjerne (*) erstatter typisk nul eller flere tegn, og spørgsmålstegn (?) ét tegn. Typiske begrænsninger:
- Mange indeks understøtter kun wildcard i slutningen af et ord (suffix), ikke i begyndelsen.
- Nogle værktøjer kræver et minimum antal tegn før stjernen.
- Wildcards inde i fraser eller nærhedssøgninger understøttes ikke altid.
- Korte stammer giver meget store resultater. “kon*” rammer konkurrent, konto, kontrakt og konference.
Udvid derfor wildcards til en liste over de faktiske ord i indekset, hvis værktøjet kan vise det, og vurder hvert ord.
Danske bøjningsformer
Dansk har bøjning i køn, tal og bestemthed: aftale, aftalen, aftaler, aftalerne. Verber bøjes i tid: sende, sendte, sendt. Trunkering med “aftale*” dækker substantivet, men uregelmæssige former som “gå/gik/gået” kræver en liste.
Stemming, hvor værktøjet automatisk reducerer ord til en stamme, findes i nogle værktøjer, men ikke altid for dansk, og resultatet kan være uforudsigeligt. Hvis stemming bruges, skal det dokumenteres, hvilket sprog og hvilken algoritme der er brugt.
Sammensatte ord
Sammensatte ord er dansk søgnings største problem. “Kontrakt” findes ikke i et indeks, der har “lejekontrakt”, “kontraktudkast” og “ansættelseskontrakt” som selvstændige tokens:
- “kontrakt*” finder “kontraktudkast”, men ikke “lejekontrakt”.
- “*kontrakt” (leading wildcard) finder “lejekontrakt”, men understøttes ikke altid og kan være langsom.
- En liste over relevante sammensætninger er ofte den eneste sikre løsning.
Ordlister fra indekset er det bedste værktøj til at finde sammensætninger, som ingen havde tænkt på.
Æ, ø og å
Tre forhold giver problemer:
- Alternative stavemåder. Mails og filnavne skrevet uden danske tegn bruger ae, oe og aa. Navnet “Søren” kan optræde som “Soeren” eller “Soren”.
- Normalisering. Nogle indeks udligner diakritiske tegn, så “ø” og “o” behandles ens. Det giver flere hits, også falske.
- Kodningsfejl. Forkert tegnsætkodning kan gøre “ø” til to mærkelige tegn. Sådanne tokens findes ikke med almindelig søgning.
Søg derfor efter varianterne eksplicit, og test, om indekset udligner tegnene. Kodningsfejl afsløres bedst ved at søge efter de typiske fejltegn. Fejl i tegnkodningen opstår typisk under processing. → Behandling af data (processing)
Andre tekniske faldgruber
- Navne og mailadresser. “jens.hansen@firma.dk” kan være ét token eller flere. Søg både på adressen og på navnedelene.
- Tal og beløb. “1.000.000”, “1000000” og “1 mio.” er forskellige tokens.
- Feltsøgning. Søgning i emne, afsender eller filnavn kræver feltsyntaks. En fritekstsøgning dækker ikke nødvendigvis metadata.
- Ikke-søgbare filer. Billeder og scannede dokumenter uden OCR rammes aldrig. → OCR og ikke-søgbare filer
Fra ordliste til søgestreng: et eksempel på metoden
Antag, at spørgsmålet er, om en medarbejder har drøftet en bestemt kunde og et tilbud med en konkurrent. Den naive søgning er ét ord: kundens navn. Den tekniske oversættelse sker i flere trin:
- Varianter af navnet. Fulde firmanavn, forkortelser, interne kælenavne, domænenavn og stavemåder uden danske tegn.
- Emneord med bøjninger. “tilbud” med trunkering, suppleret med sammensætninger fra indeksets ordliste, fx “tilbudsliste” og “pristilbud”.
- Kombination med nærhed. Navnevarianter inden for et passende antal ord fra emneordene i stedet for AND i hele dokumentet, som rammer lange nyhedsbreve og mailtråde.
- Afgrænsning. Periode og personer som filtre, ikke som søgetermer, så de kan ændres uden at ændre selve søgningen.
Hvert trin gemmes som en selvstændig søgning, så det kan ses, hvor mange hits hver del bidrager med. Det gør det lettere at justere en enkelt del uden at miste overblikket, og det gør søgningen forståelig for en modpart.
Mails og vedhæftninger
Søgninger kan køres på element- eller familieniveau. Rammer en term en vedhæftning, skal det besluttes, om hele familien, dvs. mailen og alle vedhæftninger, kommer med. Det er en indstilling i værktøjet og en aftale mellem parterne, ikke en teknisk selvfølge. Citeret tekst i svar og videresendelser betyder desuden, at samme term kan ramme mange mails i samme tråd.
Test før brug
Kør hver term isoleret, og se på antal hits og et udsnit af resultaterne. Termer med mange hits er ofte for brede. Termer uden hits kan være stavet forkert eller syntaktisk ugyldige uden fejlmeddelelse. Testen dokumenteres i en søgetermrapport. → Søgetermrapport og hitlister
Dokumentation
Angiv for hver søgning den præcise syntaks, værktøj og version, indeksets indstillinger for tokenisering og normalisering, om stemming er brugt, og hvilke datakilder og perioder søgningen dækker. Det gør det muligt for modparten at genskabe søgningen eller forstå, hvorfor resultaterne afviger fra egne.
Kilder og versioner
- Microsoft Learn: Keyword queries and search conditions for eDiscovery
- Microsoft Learn: Keyword Query Language (KQL) syntax reference
- ISO/IEC 27050-1: Electronic discovery, overview and concepts
Senest gennemgået: oktober 2026.
Næste skridt
Del af: eDiscovery teknisk
Læs også: Deduplikering: global, pr. person og near-duplicates · Søgetermrapport og hitlister: test og justering af søgninger
→ eDiscovery teknisk · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
