Slik bygget vi en OCR-pipeline for dokumenter som faktisk fungerer for internasjonal handel

Atlas Verified-teamet
·
15. oktober 2025
·
6 min lesetid
Slik bygget vi en OCR-pipeline for dokumenter som faktisk fungerer for internasjonal handel

Hvis du noen gang har forsøkt å hente strukturerte data fra et konnossement med en generell OCR-tjeneste, kjenner du allerede poenget: det fungerer ikke. I hvert fall ikke pålitelig. Og i internasjonal handelsetterlevelse er «ikke pålitelig» det samme som «ikke i det hele tatt».

Hos Atlas Verify behandler vi tusenvis av handelsdokumenter — konnossementer, økologiske sertifikater, fytosanitære sertifikater, opprinnelsessertifikater, handelsfakturaer, pakkelister og dusinvis av andre. Tidlig evaluerte vi alle større OCR-plattformer på markedet. Alle strøk på samme prøve: gi dem et dokument de ikke er spesifikt trent på, og resultatet spenner fra ufullstendig til farlig feil.

Dette innlegget forklarer hvorfor vi bygget en tilpasset dokumentbehandlingspipeline, hva som gjør handelsdokumenter spesielt vanskelige og utviklingsprinsippene som styrer tilnærmingen vår.

Problemet med dokumentmangfold

De fleste OCR-tjenester er optimalisert for et snevert sett dokumenttyper. Google Document AI er fremragende på fakturaer og kvitteringer. AWS Textract håndterer strukturerte skjemaer godt. Azure Form Recognizer kan trenes på tilpassede maler. Men internasjonal handel genererer et svimlende mangfold av papirarbeid.

Bare i systemet vårt håndterer vi over 35 forskjellige dokumenttyper. Et konnossement ligner ikke et økologisk sertifikat. Et fytosanitært sertifikat fra USDA har nesten ingen strukturell likhet med et utstedt av EU. En ankomstmelding fra ett rederi kan være en strukturert PDF med ryddige tabeller; fra et annet er den en skannet faks med håndskrevne merknader.

Den avgjørende innsikten er at hver dokumenttype har sitt eget skjema — et bestemt sett felter som er viktige for etterlevelsesverifisering. Et konnossement trenger avsender, mottaker, varslingspart, containernumre, fartøynavn, laste- og lossehavner og råvarebeskrivelser. Et økologisk sertifikat trenger sertifiseringsorgan, virksomhetsnavn, NOP-ID, sertifiserte produkter og ikrafttredelsesdatoer.

Generelle OCR-verktøy forstår ikke disse skjemaene. De henter ut tekst. De kan identifisere tabeller. Men de vet ikke at strengen «MEDU4107760» er et containernummer, eller at «NOP ID: 7880315519» er en kritisk identifikator som må verifiseres mot USDA Organic Integrity Database. Uten skjemabevissthet er OCR bare dyr tekstkonvertering.

Hvorfor «godt nok» er farlig

I de fleste programvareanvendelser er en nøyaktighetsgrad på 95% utmerket. I handelsetterlevelse er den en ansvarsrisiko.

Tenk på et containernummer. Standardformatet (ISO 6346) er fire bokstaver etterfulgt av sju sifre, der siste siffer er et kontrollsiffer. Hvis OCR feilleser ett eneste tegn — en «0» blir en «O», en «8» blir en «B» — er containernummeret ugyldig. Etterfølgende systemer som prøver å spore containeren, vil ikke gi resultater, og verifiseringskjeden brytes uten varsel.

Det samme prinsippet gjelder NOP-ID-er, HS-koder, IMO-numre og sertifiseringsdatoer. En feil på ett tegn kan endre betydningen fullstendig. En HS-kode på 0901.11 (kaffe, ikke brent, ikke koffeinfri) sammenlignet med 0901.12 (kaffe, ikke brent, koffeinfri) utløser forskjellige tollsatser, forskjellige regelverkskrav og forskjellige risikoprofiler.

Arkitekturen vår

Dokumentbehandlingspipelinen vår har tre trinn, hvert utformet for å maksimere nøyaktigheten for de spesifikke utfordringene ved handelsdokumentasjon.

Trinn 1: Dokumentklassifisering — Før vi henter ut data, identifiserer vi først hvilken type dokument vi ser på. Denne klassifiseringen bestemmer hvilket uttrekksskjema som skal brukes, hvilke felter som skal finnes og hvordan resultatene skal valideres.

Trinn 2: Skjemabevisst uttrekk — Når dokumentet er klassifisert, bruker vi en typespesifikk uttrekksmodell som vet nøyaktig hvilke felter den skal se etter og hvor de vanligvis står i den dokumenttypen. Dette er grunnleggende forskjellig fra generell OCR, som henter ut alt og overlater tolkningen til brukeren.

Trinn 3: Kryssvalidering — Uttrukne data krysskontrolleres automatisk mot eksterne datakilder. Containernumre valideres mot rederienes API-er. NOP-ID-er kontrolleres mot USDA Organic Integrity Database. Havnekoder verifiseres mot World Port Index. Dette trinnet oppdager både OCR-feil og falske data.

Lærdommer

Etter å ha behandlet titusenvis av handelsdokumenter har flere prinsipper blitt tydelige:

1. Fagspesifikt slår generelt. Hvert forsøk på å bruke en generell OCR-tjeneste krevde så mye etterbehandling at vi brukte mer utviklingstid på å rette resultatene enn vi ville ha brukt på å bygge en tilpasset løsning.

2. Klassifisering er grunnlaget. Feil dokumenttype forplanter seg til hvert etterfølgende trinn. Vi investerer tungt i klassifiseringsnøyaktighet fordi alt nedstrøms avhenger av den.

3. Validering er viktigere enn uttrekk. Å hente ut et containernummer er nyttig. Å bekrefte at det er en virkelig container på et virkelig fartøy i riktig havn, er det som faktisk betyr noe for regelverksetterlevelse.

4. Strukturerte utdata muliggjør automatisering. Målet er ikke å digitalisere dokumenter for menneskelig lesing. Det er å produsere maskinlesbare, strukturerte data som mates direkte inn i automatiserte verifiseringsarbeidsflyter.

Å bygge en pålitelig dokumentbehandlingspipeline for internasjonal handel er virkelig vanskelig. Dokumentene er mangfoldige, nøyaktighetskravene er ekstreme og konsekvensene av feil er betydelige. Men det er også grunnleggende — hver verifiseringsfunksjon vi bygger, avhenger av at vi nøyaktig kan lese og forstå dokumentene som følger varer gjennom globale forsyningskjeder.

Likte du denne artikkelen?

Del den med nettverket ditt