En komprimerad fältmanual för Data & More-plattformen: den konceptuella modellen, den heltäckande datapipelinen, hur OCR omvandlar råa dokument till ren text och signaler, hur Profiler klassificerar det den hittar, AI Profiler som driver det tunga arbetet, samt den underliggande teknologistacken.
Sju avsnitt. Vart och ett innehåller den minsta mängd detaljer som fortfarande ger ett sammanhang.
Plattformen körs kontinuerligt, inte enligt ett fast kvartalsmässigt schema. Processen har ett namn, Klassificera, Verifiera, Radera: plattformen klassificerar det som finns i arkivet, dataägaren verifierar resultaten på sina egna villkor, och utfallet är radering (eller arkivering, redigering eller begränsning) som utförs i källsystemet. Källor och undantag är den engångskonfiguration som driver loopen.
Radering sker aldrig automatiskt. Dataägaren granskar varje fynd lokalt och väljer en av tre åtgärder, som registreras i granskningsloggen.
Redigera, dokumentet korrigeras, redigeras eller annoteras i källsystemet.
Arkivera (lagring), posten flyttas till ett arkiv med en definierad bevaranderegel.
Begränsa, posten förblir på plats men flaggas för begränsad åtkomst (hantering av privata uppgifter).
Avsnitt 02Konceptuell modell
Den konceptuella modellen
Varje begäran går in via en TLS-avslutande NGINX-proxy och dirigeras till applikationsnivån: Vue-klienten, huvud-Flask API:et samt IAM-, analys- och LLM-tjänsterna. API:et skickar tidskrävande arbete till en asynkron ryggrad av Celery-workers via RabbitMQ, som även hanterar skannings-, inmatnings- och verkställighetshändelser för Java-nivån. Det tunga arbetet (genomsökning av källor, textextraktion och policytillämpning) körs i den Java-nivån. Under allt detta finns datalagret, med Elasticsearch som det dokumentlager som samtliga tjänster delar.
Förfrågnings- och datasökvägBeständigt lager / utdataDelkomponent inom ett skikt
Avsnitt 03Datapipeline
Från en råkälla till en tillämpad policy
Ett dokument genomgår samma resa varje gång. En källa konfigureras en gång; därefter crawlar plattformen den, extraherar dess text, profilerar den för personuppgifter, kontrollerar den mot klientorganisationens policyer, agerar på utfallet och rapporterar resultatet. Kostnadseffektiva, deterministiska steg körs först; de resurskrävande AI- och tillämpningsstegen körs enbart på det som når dem.
HuvudflödesvägDelat datalager, används i varje stegUtdata till användaren
Avsnitt 04OCR
The OCR pipeline
Sidor rör sig från vänster till höger. MRZ-passet aktiveras endast när ID-detektorn identifierar en sida som ett identitetsdokument; allt annat fortsätter till det utökade OCR-passet. Varje steg genererar annoteringar som nästa steg kan använda som ledtrådar.
HuvuddatavägVillkorlig gren, endast IDBildsignalDokumentannotering
OCRMotivering
Varför dela upp arbetet i lager överhuvudtaget
Ett verkligt dokumentkorpus är heterogent: digitalt skapade PDF:er, skannade brev med en kaffefläck, flerspråkiga avtal och pass med en maskinläsbar zon hamnar alla i samma inkorg. Pipelinen dirigerar varje sida genom enkla, deterministiska pass först och reserverar kostsam djupinlärnings-OCR för de fall som motiverar det. Bildsignaler följer med texten, så att en konsument kan fråga är detta avtal undertecknat eller är denna uppladdning faktiskt ett pass utan att läsa om filen.
Pass 01PDF-läsare
Huvudingången
Två PDF:er som ser identiska ut för en person kan vara helt olika inuti: den ena ett digitalt skapat dokument med ett perfekt textlager, den andra ett mobilfoto som konverterats till PDF vid 72 DPI och roterats fyra grader. Läsaren normaliserar denna asymmetri så att efterföljande OCR aldrig behöver hantera den.
Vad det gör
Rastrerar varje sida till ett standardiserat 300 DPI så att motorer ser konsekventa teckenstorlekar.
Extraherar det inbäddade textlagret när det finns, vilket kortsluter OCR helt för digitalt skapade filer.
Rätar ut, dewarpar och korrigerar orientering, och beskär sedan skannerbäddens kanter.
Delar upp flersidiga dokument till en per-sida-ström som resten av pipeline:n hanterar självständigt.
Unik fördel
Fritext vinner. En digitalt skapad PDF hoppar över OCR – omedelbart, perfekt och felfritt.
Konsekvent indata. Varje efterföljande modell kan utgå från en upprätt bild med rimligt DPI.
En enda källa till sanning. Den bild som renderas här återanvänds av varje efterföljande worker – ingen dubbel rastrering.
Pass 02Tesseract
Den snabba baslinje
Tesseract är arbetshästen: snabb, CPU-vänlig, stöder 100+ språk och levererar strukturerad utdata – ordrutor, radrutor och per-ord-konfidens. För den långa svansen av rena kontorsdokument löser den problemet helt och hållet.
Vad det gör
Kör LSTM-igenkännaren över varje sida och sänder ut hOCR / TSV med ord, rader och rutor.
Bifogar ett per-ord-konfidensvärde som avgör var EasyOCR behöver göra ett andra genomlopp.
Returnerar läsordning och layout, så att stycken rekonstrueras korrekt.
Unik fördel
Hastighet och kostnad. Ren CPU, inget GPU-beroende, skalar horisontellt och håller kostnaderna låga.
Deterministisk. Samma indata, samma utdata: enkelt att testa, cacha och diff:a i CI.
Layoutmedveten. Ordrutor och läsordning är förstaklassiga utdata.
Konfidens är en routningssignal. Regioner med lågt konfidensvärde blir indata till EasyOCR.
Tesseract är avsiktligt det första OCR-genomloppet – tillräckligt bra för de flesta sidor. De kostsamma genomloppen körs bara där det inte räcker till.
Pass 03Kombinerad worker
Signaturer, ansikten och ett beslut
Den kombinerade workern är visionsbanan. Istället för att köra tre jobb som var och ett laddar om sidbilden, allokerar en tensor och värmer upp en modell, kör den tre detektorer över samma minnesbild i ett enda genomlopp – och producerar signaler på dokumentnivå som text ensam inte kan besvara.
Detektor A
Signatur
De flesta kontrakt är endast giltiga när de är motundertecknade. Ett litet CNN söker efter bläckliknande streck som kan tolkas som en handskriven signatur och returnerar rutor samt ett poängvärde.
Omvandlar är detta kontrakt undertecknat till ett booleskt värde.
Ruta plus sidindex låter ett gränssnitt hoppa direkt till den signerade raden.
Den närmaste textraden – det tryckta namnet – kan paras ihop med rutan.
Detektor B
YuNet
YuNet är en liten ansiktsdetektor byggd för att köra i realtid på vanlig hårdvara. Här handlar det inte om ansikten, utan om porträtt som ett dokumentelement.
Ett ansikte i hörnet är ett starkt tecken på ett ID-kort, pass eller körkort.
Ungefär 1 ms per beskärning på CPU, billigt nog för att köra på varje sida.
Förekomsten av ett ansikte kan styra borttagning av känslig information eller särskild hantering.
Detektor C
ID eller inte
En binär klassificerare som läser hela sidan och besvarar en fråga: är detta ett identitetsdokument? Dess uppgift är att avgöra vilka sidor som når MRZ-specialisten.
Undviker att köra MRZ på varje sida – de flesta har ingen.
Använder YuNets ansiktsmatchning och Tesseract's text som egenskaper.
Ett litet huvud över ett litet grundnät: snabbt och enkelt att kalibrera.
Varför kombinerat? Inläsning av bilden, färgkonvertering, storleksändring och uppvärmning av en modell står för den största delen av varje detektors latens. Att köra alla tre över en gemensam bild, en process, en tät loop, eliminerar det overheadet och håller annoteringarna konsistenta sinsemellan, eftersom alla tre såg samma pixlar.
Pass 04MRZ
Passspecialisten
Den maskinläsbara zonen längst ned på ett pass eller ID-kort följer ett strikt ICAO-9303-format: en fast teckenuppsättning (A–Z 0–9 <), fasta positioner och inbyggda kontrollsiffror. En generisk OCR kan läsa den men förvanskrarO/0 eller1/I. Detta pass är skräddarsytt för remsan.
Vad det gör
Körs endast när ID-eller-inte-klassificeraren flaggar sidan, så det slösar aldrig arbete.
Använder en MRZ-anpassad igenkännare och grammatik som bara ger ut giltiga MRZ-tecken.
Verifierarkontrollsiffror– ett förfalskat eller felläst fält fångas upp av aritmetik, inte av gissning.
Unik fördel
Strukturerat, inte fritext. KYC-koden tar emot en typad post, inte en sträng.
Självvaliderande. Kontrollsiffror ger en garanti som generisk OCR inte kan matcha.
Snävt område, hög noggrannhet. Liten teckenuppsättning, fast layout – en specialist vinner med bred marginal.
Pass 05EasyOCR
Den djupinlärningsbaseradesista milen
EasyOCR är en djupinlärningsbaserad OCR – en CRAFT-textdetektor plus en CRNN-igenkännare på PyTorch. Tyngre än Tesseract, men den utmärker sig precis där Tesseract har svårigheter: teckensnitt med låg kontrast eller stiliserade teckensnitt, kursiv eller roterad text, foton av kvitton samt många icke-latinska skriftspråk. Här fungerar den som reservalternativ och som passet för avancerad OCR.
Vad det gör
Läser om de regioner där Tesseract returnerade lågt konfidensvärde – kirurgiskt, inte hela sidan.
Hanterar icke-latinska skriftspråk som en given Tesseract-installation inte är konfigurerad för.
Ger en andra åsikt: överensstämmelse mellan de två motorerna höjer konfidensen markant.
Unik fördel
Robusthet. CNN-igenkänning klarar foton, perspektiv och ovanliga teckensnitt.
Täckning. 80+ språk direkt ur lådan.
Målstyrd. Körs bara där Tesseract inte var säker, så den långsamma vägen förblir liten.
Billigt i första hand, kostsamt bara där det behövs – det är vad som håller pipelinen snabb i genomsnitt utan att förlora den långa svansen.
OCRRouting
Det beslut en sida fattar
OCRÖversikt
Vad varje pass tillför
Pass
Utdata
Kostnad
När det används bäst
PDF-läsare
normaliserade bilder, textlager
mycket låg
digitalt skapade PDF:er
Tesseract
ordrutor + tillförlitlighet
låg · CPU
rena kontorsdokument
Signatur
signerad flagga + rutor
låg
avtal, regelefterlevnad
YuNet
ansiktsrutor, antal
mycket låg
identifiering av porträtt / ID-handlingar
ID-eller-inte
isID, dokumenttyp
låg
dirigering till MRZ
MRZ
maskinläst post + kontrollsiffror
medel
pass, nationella ID-handlingar
EasyOCR
text + tillförlitlighet
hög · GPU-vänlig
stiliserad, brusig, flerspråkig
OCRPrinciper
Vad pipelinen utgår ifrån
Billigt först, kostsamt endast när det motiveras
Varje pass finns till eftersom det föregående inte kan hantera ett specifikt felläge. Tesseract bär huvuddelen av arbetet; EasyOCR anropas enbart för de ord det inte kunde läsa; MRZ endast när sidan verkligen är ett ID-dokument.
Signaler, inte bara text
OCR är nödvändigt men sällan tillräckligt. Den kombinerade arbetaren genererar signaler på dokumentnivå – signerad, porträtt förekommer, identitetsdokument – som affärslogiken nedströms faktiskt behöver.
Specialister slår generalister inom snäva domäner
En MRZ i ett pass är ett litet, strikt format med kontrollsiffror. En specialiserad parser är mer träffsäker, och självvaliderande, på ett sätt som ingen generisk OCR kan vara på samma rad.
Dela på arbetet
Den kombinerade arbetaren finns till eftersom inläsning och förbearbetning av bilden är den tidskrävande delen. Tre detektorer över en bild i minnet reducerar detta overhead och håller annoteringarna konsekventa.
Avsnitt 05Profilerare med klassificering
Profileraren och dess taxonomi
Profilsteget i datapipelinen körs i två parallella lägen. Logisk profil (java_profiler) hanterar regex, språkidentifiering och regelbaserad entitetsextrahering. AI-profil (ai-profiler, spaCy NLP-motorn) hanterar NER, matchning av nyckelfraser och kontroller av dependensgrammatik. Båda skriver sina resultat till samma delade taxonomi nedan.
Resultat organiseras i kategorier på toppnivå, var och en med många posttyper. Kategorier och posttyper styrs av kundspecifika ordlistor som läses in från Elasticsearch, vilket innebär att varje prenumeration kan aktivera, inaktivera eller utöka valfri del av dem. Listan nedan speglar vyn Dokumentklasser i administratörsgränssnittet.
Kategori 01
Integritetsklassificering
Huvuddelen av GDPR-relevant identifiering: identifierare, särskilda kategorier och dokumentklasser vars blotta förekomst är en signal om att en post behöver styrning.
PassHälsoinformationIntyg / TillståndReseinformationPolitisk åsiktArbetsfrånvaroFullmaktFörsäkringsinformationPlatsKriminellt beteendeBrottsregisterVarning till anställdNationellt ID-kortBidragsansökanBetalkortReligiös övertygelseSexuell läggningNationellt ID-nummerTestamentenEtniskt ursprungAnställningsinformationKörkortFackligt medlemskapLön / finansiell informationSkatteinformationHälsokortAvslutande av anställningÖvrigt IDRekryteringUtbildningsinformation
30 posttyper · kundspecifika ordlistor, per språk
Category 02
Kritisk klassificering av säkerhetsinformation
En parallell taxonomi för innehåll som äventyrar organisationen snarare än en enskild person: hemligheter, infrastruktur och säkerhetsoperationer.
Lösenord och hemligheterKällkodInfrastrukturkonfigurationSårbarhetsbedömningLoggfilerSäkerhetsincidenterPlacering av CCTV-kamerorDigitala certifikatSäkerhetskravNätverksåtkomstkontroll
10 posttyper · taggade med organisationstypen SECURITY
Category 03
QA
En arbetsbänkskategori som används av datateamet för att testa och utvärdera nya posttyper innan de befordras till en av de publika taxonomierna. Avstängd som standard för klienter.
Category 04
Taggstädning
Underhållskategori som innehåller utgångna posttyper och sammanslagningspunkter, så att historiska fynd förblir tolkningsbara medan nya skanningar använder den aktuella taxonomin.
Category 05
Specialklassificeringar
Klientspecifika kategorier för posttyper som inte tillhör en global taxonomi. En kund kan utöka denna kategori med sina egna ordlistor.
Per posttyp
Vad en posttyp innehåller
Aktiv, Rapport, Visning, Engångstagning, Söktagg, Tagg i Outlook: klientspecifika inställningar som styr var fyndet visas.
# Dokument: live-räkning av poster som för närvarande bär taggen.
Status, Organisationstyp, Token #: ursprung och validering av posttypen i sig.
Exekveringstid och Exekveringstid för taggning: kostnadstelemetri om hur lång tid posttypen tar att utvärdera per dokument.
Taggning slutförd och Prenumeration uppdaterad: tidsstämplar för den senaste fullständiga genomgången och den senaste ordlistesynkroniseringen.
Namngivna entiteter
Personliga identifierare (från NER)
Vid sidan av de ordlistestyrda kategorierna genererar spaCy NER-linsen identifieringsfynd som inte är konfigurerbara per klient.
PersonFullständigt namnOrganisationPlatsOrt / GPEDatumTidNationalitet / grupp
Avsnitt 06AI Profiler
En AI Profiler djupdykning
Samma detektionskärna (handle_doc) driver både en storskalig bakgrundspipeline och ett realtidsändpunkt. Batcharbete flödar från vänster till höger genom schemaläggaren, en begränsad kö och en pool av spaCy-arbetare; realtidsändpunkten matar in ett enskilt textstycke direkt i kärnan och returnerar JSON.
Hitta känsliga uppgifter, märk dem och lämna tillbaka dem
Profileraren läser dokument som redan är indexerade i Elasticsearch. För varje dokument identifierar den namn, platser och datum, och söker därefter efter språk som avslöjar särskilda kategorier av personuppgifter: hälsa, religion, politik, sexuell läggning, etnicitet, brottshistorik, fackligt medlemskap och anställningsåtgärder. Varje träff märks med en typ, den matchade texten och dess position, och sparas sedan tillbaka på dokumentet – så att efterlevnadsarbetet utgår från fakta snarare än gissningar.
AI ProfilerTvå ingångar
En pipeline och ett ändpunkt
Läge A
Schemalagd pipeline
En bakgrundstråd söker kontinuerligt i Elasticsearch efter dokument som flaggats DS_Status: REQUEST_AI och matar dem till en pool av arbetarprocesser. Det är så här bulkarkiv profileras.
Läge B
REST-ändpunkt
En POST /profile-text rutt profilerar ett enskilt textstycke på begäran och returnerar färgkodade träffar som JSON. En /health rutt rapporterar tillgänglighet.
AI ProfilerBatchpipelinen
Från flaggat dokument till färdig profil
Vid uppstart väntar applikationen på att Elasticsearch-klustret ska bli tillgängligt, varefter schemaläggaren och arbetarpoolen startas. Cykeln nedan upprepas kontinuerligt.
01 Schemaläggaren frågar Elasticsearch. Varje cykel söker den igenom data indexet efter dokument där DS_Status = REQUEST_AI, och bläddrar 50 åt gången med search-after.
02 Varje dokument blir en uppgift. Dokument paketeras som uppgifter och skickas till en delad multiprocessingkö. Om kön fylls pausar schemaläggaren, vilket ger ett naturligt mottryck som håller minnesanvändningen begränsad.
03 Arbetare hämtar uppgifter. En pool av spaCy-arbetarprocesser (2 som standard) hämtar uppgifter parallellt, kör detektionskärnan och slår samman eventuella befintliga märkningar som redan finns på dokumentet.
04 Detektionskärnan körs. Texten screenas, språkroutas och skickas genom upp till tre detektionsalgoritmer. Detta är handle_doc, som beskrivs nedan.
05 Resultat skrivs tillbaka. Fynd dedupliceras och uppdateras i bulk på dokumentet, och statusen sätts tillFINISHED. Även vid fel ändras statusen till FINISHED, så ingenting bearbetas om i oändlighet.
Motrycket på en kö med 1 000 platser håller hela pipeline inom ett fast minnesutrymme, oavsett hur stort arkivet är.
AI ProfilerInuti kärnan
Screena, dirigera och sedan matcha
Innan någon modell körs, handle_doc filtrerar bort arbete som inte ska utföras och väljer sedan rätt verktyg för språket. Först därefter aktiveras matcharna.
Steg 1
Bestäm vad som ska bearbetas
Endast godkända dokumenttyper profileras (doc, docx, pdf, eml, txt med flera). Strukturerade format som json, xml och log hoppas över. Text som är längre än 20 000 tecken flaggas och trunkeras, och innehåll med okänt språk tas bort.
Steg 2
Välj språkstrategi
Om ett språk har grammatiska beroendemönster analyseras hela texten på en gång. Annars delas texten upp i meningar och varje mening analyseras separat, med den flerspråkiga modellen som universell reservlösning.
AI ProfilerDetektionsalgoritmer
Tre perspektiv på samma text
Varje fynd bär en prefixad etikett så att system längre ned i kedjan vet hur det hittades. De tre perspektiven körs över samma mening och deras resultat slås samman.
01 · NER
Namngivna entiteter
spaCy:s statistiska modell identifierar personer, organisationer, platser, datum och tider. Namn med rätt form (två till tre distinkta alfabetiska ord, inga siffror) befordras till fynd av fullständiga namn.
En lemmamedveten frasmatchare söker igenom termer från kundspecifika ordlistor med känsligt ordförråd, så att böjda former fångas snarare än enbart exakta strängar.
etiketter: S_K_<TYPE>
03 · Grammatik
Beroendematchning
Grammatiska mönster bekräftar ett verkligt påstående: en person eller ett tillåtet pronomen är subjektet och ett känsligt nyckelord är objektet. Detta minskar falska positiva träffar genom att kräva kontext, inte bara ett ord.
etiketter: S_S_<TYPE>
AI ProfilerRäckvidd
Byggd för skalbarhet ochräckvidd
15+språkmodeller
3detektionsmetoder
1kködjup för uppgifter
9känsliga kategorier
Dedikerade modeller levereras för engelska, danska, tyska, nederländska, franska, italienska, spanska, svenska, norska, finska, polska, portugisiska, litauiska, kroatiska (som även täcker serbiska, bosniska och montenegrinska) samt ukrainska, med en flerspråkig modell som täcker allt annat och en universell meningsdelning som grund.
Från en konfigurerad postlåda till en tillämpad bevaranderegel följer varje dokument en och samma väg genom en flerspråkig miljö som hålls samman av ett gemensamt datalager. Arkitekturen är mångfaldig by design; källan till sanning är det inte.
~42 tjänster · Python + Java kärna · Elasticsearch i centrum