En kondenseret felthåndbog for Data & More-platformen: den konceptuelle model, den komplette datapipeline, hvordan OCR omdanner rå dokumenter til ren tekst og signaler, hvordan Profileren klassificerer det, den finder, AI Profileren der driver det tunge arbejde, og teknologistakken underneden.
Syv afsnit. Hvert med den mindste mængde detaljer, der stadig giver mening.
Platformen kører kontinuerligt og ikke efter et fast kvartalsmæssigt skema. Processen har et navn,Klassificer, Verificer, Slet: platformen klassificerer det, der ligger i arkivet, dataejeren verificerer fundene på egne præmisser, og resultatet er sletning (eller arkivering, redigering eller begrænsning) udført i kildesystemet. Kilder og undtagelser er den éngangs-konfiguration, der fodrer løkken.
Klassificer – platformens opgaveVerificer – dataejerens opgaveSlet – det løbende mål
Hvor dataene kommer fra
Tilsluttede kilder
Hver kilde er forbundet via én af platformens indtagelseskonnektorer. Cyklussen starter her og skriver også fundene tilbage hertil.
Sletning er aldrig automatisk. Dataejeren gennemgår hvert fund lokalt og vælger én af tre handlinger, som registreres i revisionsloggen.
Rediger, dokumentet korrigeres, redigeres eller annoteres i kildesystemet.
Arkivering (opbevaring), posten flyttes til et arkiv med en defineret opbevaringsregel.
Begræns, posten bliver på sin plads, men markeres til begrænset adgang (håndtering af persondata).
Afsnit 02Konceptuel model
Den konceptuellemodel
Alle anmodninger indgår via én TLS-terminerende NGINX-proxy og dirigeres til applikationslaget: Vue-klienten, den primære Flask API samt IAM-, analytics- og LLM-tjenesterne. API'en overlader tidskrævende arbejde til en asynkron rygrad af Celery-workers over RabbitMQ, som også håndterer scan-, indtagelses- og håndhævelsesevent for Java-laget. Det tunge arbejde (crawling af kilder, udtrækning af tekst, håndhævelse af politik) kører i dette Java-lag. Under det hele befinder datalaget sig, med Elasticsearch som det dokumentlager, alle tjenester deler.
Anmodnings- og datastiVedvarende lager / outputUnderkomponent inden for et lag
Afsnit 03Datapipeline
Fra en rå kilde til en håndhævet politik
Et dokument gennemgår den samme proces hver gang. En kilde konfigureres én gang; herefter crawler platformen den, udtrækker teksten, profilerer den for personoplysninger, kontrollerer den op imod lejerens politikker, handler på grundlag af afgørelsen og rapporterer resultatet. Billige, deterministiske trin udføres først; de dyre AI- og håndhævelsestrin udføres kun på det, der når frem til dem.
Primær pipeline-stiDelt lager, der berøres på hvert trinOutput til brugeren
Afsnit 04OCR
The OCR pipeline
Sider bevæger sig fra venstre mod højre. MRZ-passet aktiveres kun, når ID-eller-ej-detektoren fastslår, at en side er et identitetsdokument; alt andet fortsætter til det omfattende OCR-pas. Hvert trin udsender annotationer, som det næste trin kan anvende som vejledning.
Primær datastiBetinget forgrening, kun IDBilledsignalDokumentannotering
OCRRationale
Hvorfor opdele arbejdet overhovedet
Et reelt dokumentkorpus er heterogent: digitalt oprettede PDF'er, scannede breve med en kaffeplet, flersprogede kontrakter og pas med en maskinlæsbar zone lander alle i den samme indbakke. Pipelinen sender hver side gennem billige, deterministiske pas først og forbeholder dyr deep learning-OCR til de tilfælde, der berettiger det. Billedsignaler følger med teksten, så en forbruger kan spørge er denne kontrakt underskrevet eller er dette upload faktisk et pas uden at skulle genindlæse filen.
Pas 01PDF-læser
Den forreste dør
To PDF'er, der ser identiske ud for et menneske, kan være vidt forskellige indeni: den ene et digitalt oprettet eksport med et perfekt tekstlag, den anden et telefonfoto fladtrykt til PDF ved 72 DPI og roteret fire grader. Læseren normaliserer denne asymmetri, så den efterfølgende OCR aldrig behøver at forholde sig til den.
Hvad det gør
Rasteriserer hver side til en standard på 300 DPI, så tekstgenkendelsesmotorerne ser ensartede tegnstørrelser.
Udtrækker det indlejrede tekstlag når det er til stede, hvilket helt omgår OCR for digitalt fødte filer.
Retter skævheder, forvrængninger og orientering, og beskærer derefter scannerbordets kanter.
Opdeler flersidede dokumenter i en side-for-side-strøm, som resten af pipeline'en håndterer uafhængigt.
Unik fordel
Fri tekst vinder. En digitalt født PDF springer OCR over – øjeblikkeligt, perfekt og fejlfrit.
Konsistent input. Alle efterfølgende modeller kan antage et oprejst billede med fornuftig DPI.
Én sandhedskilde. Det billede, der renderes her, genbruges af alle efterfølgende arbejdsprocesser – ingen dobbelt rasterisering.
Pass 02Tesseract
Det hurtige udgangspunkt
Tesseract er arbejdshesten: hurtig, CPU-venlig, 100+ sprog og struktureret output – ordfelter, linjefelter og pr.-ords konfidens. For den brede mængde af rene kontordokumenter løser den opgaven fuldstændigt.
Hvad det gør
Kører LSTM-genkendelsesmodellen over hver side og udsender hOCR / TSV med ord, linjer og felter.
Tilknytter en pr.-ords konfidens score, der afgør, hvor EasyOCR har behov for et ekstra gennemløb.
Returnerer læserækkefølge og layout, så afsnit rekonstrueres korrekt.
Unik fordel
Hastighed og omkostninger. Ren CPU, ingen GPU-afhængighed, skalerer horisontalt og forbliver omkostningseffektivt.
Deterministisk. Samme input, samme output: nemt at teste, cache og sammenligne i CI.
Layoutbevidst. Ordfelter og læserækkefølge er førsteklasses output.
Konfidens er et rutesignal. Områder med lav konfidens bliver input til EasyOCR.
Tesseract er bevidst det første OCR-gennemløb – godt nok til de fleste sider. De ressourcekrævende gennemløb køres kun, hvor det ikke slår til.
Pass 03Kombineret arbejdsproces
Underskrifter, ansigter og én beslutning
Den kombinerede arbejdsproces er den visuelle behandlingsbane. I stedet for at køre tre separate opgaver, der hver genindlæser sidebilledet, allokerer en tensor og opvarmer en model, kører den tre detektorer over det samme billede i hukommelsen i ét gennemløb og producerer signaler på dokumentniveau, som tekst alene ikke kan besvare.
Detektor A
Underskrift
De fleste kontrakter er først gyldige, når de er modunderskrevet. En lille CNN scanner efter blækagtige streger, der aflæses som en håndskreven underskrift, og returnerer felter samt en score.
Gør er denne kontrakt underskrevet til en boolsk værdi.
Felt samt sideindeks giver en brugergrænseflade mulighed for at hoppe direkte til den underskrevne linje.
Den nærmeste tekstlinje – det trykte navn – kan sammenkædes med feltet.
Detektor B
YuNet
YuNet er en kompakt ansigtsdetektor bygget til at køre i realtid på standard hardware. Her handler det ikke om ansigter, men om portrætter som et dokumentkendetegn.
Et ansigt i hjørnet er et stærkt tegn på et ID-kort, pas eller kørekort.
Cirka 1 ms pr. beskæring på CPU – billigt nok til at køre på hver side.
Tilstedeværelsen af et ansigt kan udløse redigering eller særlig håndtering.
Detektor C
ID eller ej
En binær klassifikator, der læser hele siden og besvarer ét spørgsmål: er dette et identitetsdokument? Dens opgave er at afgøre, hvilke sider der sendes videre til MRZ-specialisten.
Undgår at køre MRZ på hver side – de fleste har ingen.
Anvender YuNets ansigtsfund og Tesseract's tekst som funktioner.
Et lille hoved over en lille backbone: hurtig og nem at kalibrere.
Hvorfor kombineret? Indlæsning af billedet, farvekonvertering, skalering og opvarmning af en model udgør størstedelen af enhver detektors latenstid. Ved at køre alle tre over ét fælles billede, én proces, én tæt løkke, reduceres denne overhead, og annotationerne forbliver indbyrdes konsistente, fordi alle tre så de samme pixels.
Pass 04MRZ
Pas-specialisten
Den maskinlæsbare zone nederst på et pas eller ID-kort følger et strengt ICAO-9303-format: et fast tegnsæt (A–Z 0–9 <), faste positioner og indbyggede kontrolcifre. En generisk OCR vil læse den, men forvanskeO/0 eller 1/I. Dette pass er specialbygget til strimlen.
Hvad den gør
Kører kun, når ID-eller-ej-klassifikatoren markerer siden, så der aldrig spildes arbejde.
Anvender en MRZ-tilpasset genkender og grammatik, der kun udsender gyldige MRZ-tegn.
Verificerer kontrolcifre– et forfalsket eller fejllæst felt opdages via aritmetik, ikke ved gætteri.
Unik fordel
Struktureret, ikke fritekst. KYC-kode modtager en struktureret post, ikke en tekststreng.
Selvvaliderende. Kontrolcifre giver en garanti, som generisk OCR ikke kan matche.
Snævert domæne, høj præcision. Lille tegnsæt, fast layout – en specialist vinder med stor margin.
Pass 05EasyOCR
Den deep-learning-baserede sidste mil
EasyOCR er en deep-learning-baseret OCR – en CRAFT-tekstdetektor kombineret med en CRNN-genkender på PyTorch. Tungere end Tesseract, men den brillerer præcis der, hvor Tesseract kæmper: lav kontrast eller stiliserede skrifttyper, buet eller roteret tekst, fotos af kvitteringer og mange ikke-latinske skriftsystemer. Her fungerer den som fallback og som det avancerede OCR-pass.
Hvad den gør
Genlæser de områder, hvor Tesseract returnerede lav tillid – målrettet, ikke hele siden.
Håndterer ikke-latinske skriftsystemer, som en given Tesseract-installation ikke er konfigureret til.
Leverer en second opinion: overensstemmelse mellem de to motorer øger tilliden markant.
Unik fordel
Robusthed. CNN-genkendelse håndterer fotos, perspektiv og usædvanlige skrifttyper.
Dækning. 80+ sprog ud af boksen.
Målrettet. Kører kun, hvor Tesseract ikke var sikker, så den langsomme sti forbliver minimal.
Billigt først, dyrt kun hvor det er nødvendigt – det er det, der holder pipelinen hurtig i gennemsnit uden at miste den lange hale.
OCRRouting
Den beslutning en side træffer
OCROverblik
Hvad hvert trin tilføjer
Trin
Output
Omkostning
Hvor det fungerer bedst
PDF-læser
normaliserede billeder, tekstlag
meget lav
digitalt oprettede PDF'er
Tesseract
ordkasser + konfidensværdi
lav · CPU
rene kontordokumenter
Signatur
signeret-flag + kasser
lav
kontrakter, compliance
YuNet
ansigtsrammer, antal
meget lav
identificering af portrætter / legitimationsdokumenter
ID-or-not
isID, dokumenttype
lav
videresendt til MRZ
MRZ
typeinddelt post + kontrolcifre
medium
pas, nationale id-kort
EasyOCR
tekst + konfidensværdi
høj · GPU-venlig
stiliseret, støjfyldt, flersproget
OCRPrincipper
Hvad pipelinen bygger på
Billigt først, dyrt kun når det er berettiget
Hvert trin eksisterer, fordi det foregående ikke kan håndtere en bestemt fejltype. Tesseract håndterer størstedelen; EasyOCR aktiveres kun for de ord, det ikke kunne læse; MRZ kun når siden reelt er et legitimationsdokument.
Signaler, ikke blot tekst
OCR er nødvendigt, men sjældent tilstrækkeligt. Den kombinerede worker udsender signaler på dokumentniveau – signeret, portræt til stede, identitetsdokument – som den efterfølgende forretningslogik reelt har brug for.
Specialister slår generalister inden for snævre domæner
En MRZ i et pas er et lille, strengt format med kontrolcifre. En specialiseret parser er mere præcis og selvvaliderende på en måde, ingen generisk OCR kan matche på den samme stribe.
Del arbejdet
Den kombinerede worker eksisterer, fordi indlæsning og forbehandling af billedet er den langsomme del. Tre detektorer over ét in-memory-billede reducerer denne overhead og sikrer, at annotationerne er konsistente.
Afsnit 05Profiler med klassificering
Profileren og dens taksonomi
Profile-stadiet i datapipelinen kører i to parallelle tilstande. Logisk profil (java_profiler) håndterer regex, sprogdetektering og regelbaseret entitetsudtrækning. AI-profil (ai-profiler, spaCy NLP-motoren) håndterer NER, matchning af nøglesætninger og afhængighedsgrammatiske kontroller. Begge skriver deres resultater ind i den samme fælles taksonomi nedenfor.
Resultater er organiseret i overordnede kategorier, der hver indeholder mange posttyper. Kategorier og posttyper styres af kundespecifikke ordbøger indlæst fra Elasticsearch, så hvert abonnement kan aktivere, deaktivere eller udvide dem efter behov. Listen nedenfor afspejler visningen Dokumentklasser i admin-brugergrænsefladen.
Kategori 01
Fortrolighedsklassificering
Størstedelen af GDPR-relevant detektering: identifikatorer, særlige kategorier og dokumentklasser, hvis blotte tilstedeværelse er et signal om, at en post kræver governance.
PasHelbredsoplysningerCertifikater / TilladelserRejseoplysningerPolitisk orienteringArbejdsfraværFuldmagtForsikringsoplysningerLokationKriminel adfærdStraffeattestAdvarsel til medarbejderNationalt id-kortTilskudsansøgningBetalingskortReligiøs orienteringSeksuel orienteringNationalt id-nummerTestamenterEtnisk oprindelseBeskæftigelsesoplysningerKørekortFagforeningsmedlemskabLøn / finansielle oplysningerSkatteoplysningerSundhedskortAfskedigelse af medarbejderDiverse IDRekrutteringUddannelsesoplysninger
En parallel taksonomi for indhold, der bringer organisationen i fare frem for en enkeltperson: hemmeligheder, infrastruktur og sikkerhedsoperationer.
Adgangskoder og hemmelighederKildekodeInfrastrukturkonfigurationSårbarhedsvurderingLogfilerSikkerhedshændelserPlaceringer af CCTV-kameraerDigitale certifikaterSikkerhedskravNetværksadgangskontrol
10 entry types · tagged with SECURITY org type
Category 03
QA
En arbejdsbordskategori, der anvendes af datateamet til at opstille og afprøve nye entry types, inden de overføres til en af de offentlige taksonomier. Deaktiveret som standard for lejere.
Category 04
Oprydning af tags
Vedligeholdelseskategori, der indeholder udgåede entry types og flettemål, så historiske fund forbliver fortolkelige, mens nye scanninger anvender den aktuelle taksonomi.
Category 05
Særlige klassifikationer
Lejerspecifikke kategorier for entry types, der ikke tilhører en global taksonomi. En kunde kan udvide denne kategori med egne ordbøger.
Pr. entry type
Hvad en entry type indeholder
Aktiv, Rapport, Visning, Engangstagning, Søgetag, Tag i Outlook: pr.-lejer-indstillinger, der styrer, hvor fundet vises.
# Dokumenter: aktuelt antal poster, der i øjeblikket bærer tagget.
Status, Org Type, Token #: oprindelse og validering af entry type'en selv.
Udførelsestid og Udførelsestid for tagning: omkostningstelemetri over, hvor lang tid entry type'en bruger på at evaluere pr. dokument.
Tagning afsluttet og Abonnement opdateret: tidsstempler for det seneste fulde gennemløb og den seneste ordbogsopdatering.
Navngivne entiteter
Personlige identifikatorer (fra NER)
Ved siden af de ordbogsdrevne kategorier udsender spaCy NER-linsen identifikatorfund, der ikke kan konfigureres pr. lejer.
PersonFuldt navnOrganisationPlaceringSted / GPEDatoTidspunktNationalitet / gruppe
Afsnit 06AI Profiler
En grundigAI Profiler gennemgang
Den samme detektionskerne (handle_doc) driver både en højvolumen-baggrundspipeline og et live-anmodningsendpoint. Batcharbejde flyder fra venstre mod højre gennem scheduleren, en afgrænset kø og en pulje af spaCy-arbejdsprocesser; realtime-endpointet sender et enkelt stykke tekst direkte ind i kernen og returnerer JSON.
Find de følsomme data, mærk dem og lever demtilbage
Profileren læser dokumenter, der allerede er indekseret i Elasticsearch. For hvert dokument detekterer den navne, steder og datoer og søger derefter efter sprogbrug, der afslører særlige kategorier af personoplysninger: helbred, religion, politik, seksuel orientering, etnicitet, kriminel baggrund, fagforeningsmedlemskab og ansættelsesforhold. Hvert match mærkes med en type, den matchede tekst og dens position og gemmes derefter tilbage på dokumentet, så compliance-arbejdet tager udgangspunkt i kendsgerninger frem for gætværk.
AI ProfilerTo indgangsveje
En pipeline og etendpoint
Tilstand A
Planlagt pipeline
En baggrundstråd forespørger løbende Elasticsearch for dokumenter, der er markeretDS_Status: REQUEST_AI og sender dem videre til en pulje af arbejdsprocesser. Dette er den måde, større arkiver profileres på.
Tilstand B
REST-endpoint
EnPOST /profile-text -rute profilerer et enkelt stykke tekst efter behov og returnerer farvekodede matches som JSON. En/health -rute rapporterer driftstatus.
AI ProfilerBatch-pipelinen
Fra markeret dokument til færdigtprofil
Ved opstart venter applikationen på, at Elasticsearch-clusteret bliver tilgængeligt, og starter derefter scheduleren og arbejdsprocespuljen. Nedenstående cyklus gentages i det uendelige.
01 Scheduler forespørger Elasticsearch. I hver cyklus gennemsøger dendata -indekset for dokumenter, hvorDS_Status = REQUEST_AI, med 50 ad gangen ved hjælp af search-after.
02 Hvert dokument bliver til en opgave. Dokumenter pakkes som opgaver og skubbes ind i en delt multiprocessing-kø. Hvis køen fyldes, sætter scheduleren sig på pause, hvilket giver naturligt modtryk, så hukommelsesforbruget holdes inden for grænserne.
03 Arbejdsprocesser henter opgaver. En pulje af spaCy-arbejdsprocesser (2 som standard) henter opgaver parallelt, kører detektionskernen og fletter eventuelle eksisterende mærker, der allerede er på dokumentet.
04 Detektionskernen kører. Teksten screenes, sprogrutes og sendes gennem op til tre detektionsalgoritmer. Dette erhandle_doc, udvidet nedenfor.
05 Resultater skrevet tilbage. Fund deduplikeres og opdateres samlet på dokumentet, og statussen sættes tilFINISHED. Selv ved fejl skifter status til FINISHED, så intet genbehandles i det uendelige.
Modtryk på en 1000 enheder dyb kø holder hele pipeline'en inden for en fast hukommelsesramme, uanset hvor stort arkivet er.
AI ProfilerInde i kernen
Filtrer, rut, og match
Før nogen model køres, handle_doc filtrerer arbejde fra, som ikke bør udføres, og vælger derefter det rette værktøj til sproget. Først herefter aktiveres matcherne.
Trin 1
Afgør hvad der skal behandles
Kun godkendte dokumenttyper profileres (doc, docx, pdf, eml, txt og flere). Strukturerede formater som json, xml og log springes over. Tekst længere end 20.000 tegn markeres og afkortes, og indhold på ukendte sprog udelades.
Trin 2
Vælg sprogstrategi
Hvis et sprog har grammatiske afhængighedsmønstre, analyseres hele teksten på én gang. Ellers opdeles teksten i sætninger, og hver sætning analyseres enkeltvis, med den flersprogede model som universel reserve.
AI ProfilerDetektionsalgoritmer
Tre vinkler på den samme tekst
Hvert fund bærer et præfikset label, så efterfølgende systemer ved, hvordan det blev fundet. De tre vinkler køres over den samme sætning, og deres resultater sammenflettes.
01 · NER
Navngivne entiteter
spaCy's statistiske model identificerer personer, organisationer, steder, datoer og tidspunkter. Navne med den rette form (to til tre særskilte alfabetiske ord, ingen cifre) forfremmes til fulde navnefund.
En lemma-bevidst sætningmatcher scanner efter termer fra kundespecifikke ordbøger over følsomt vokabular, så den registrerer bøjede former frem for kun eksakte strenge.
labels: S_K_<TYPE>
03 · Grammatik
Afhængighedsgenkendelse
Grammatiske mønstre bekræfter et reelt udsagn: en person eller et tilladt pronomen er subjektet, og et følsomt nøgleord er objektet. Dette reducerer falske positive ved at kræve kontekst, ikke blot et ord.
labels: S_S_<TYPE>
AI ProfilerRækkevidde
Bygget til skalering ogrækkevidde
15+sprogmodeller
3detektionsmetoder
1kopgavekødybde
9følsomme kategorier
Dedikerede modeller leveres til engelsk, dansk, tysk, nederlandsk, fransk, italiensk, spansk, svensk, norsk, finsk, polsk, portugisisk, litauisk, kroatisk (der også dækker serbisk, bosnisk og montenegrinsk) og ukrainsk, med en flersproget model der dækker alt andet og en universel sætningsopdeler i bunden.
Fra en konfigureret postkasse til en håndhævet opbevaringsregel følger hvert dokument én sti gennem et flersproget miljø holdt sammen af et enkelt fælles lager. Arkitekturen er mangfoldig af design; kilden til sandhed er den ikke.
~42 tjenester · Python + Java kerne · Elasticsearch i centrum