AWS fremlægger et praktisk blueprint for intelligent dokumentbehandling: Amazon Bedrock Data Automation (BDA) som udtræksmotor, Strands Agent på Amazon Bedrock AgentCore Runtime som koordinator og Amazon Bedrock Knowledge Base som fælles kontekstlag. Ambitionen er at ende med struktureret, valideret indhold – ikke bare tekststrenge. Det gennemgås i AWS’ blogindlæg From PDFs to insights (kilde 1861).
Problemet er velkendt: virksomheder bader i dokumenter – fakturaer, kontrakter, skadesager, journaler. Klassisk OCR hiver tekst ud, men mister relationer og betydning. Det skaber manuelt eftertjek og flaskehalse. Begge pointer fremgår direkte af AWS’ tekst (1861).
Hvad BDA faktisk gør
Ifølge AWS er BDA en samlet API til multimodalt input på tværs af dokumenter, billeder, video og lyd. Pipeline-trinene omfatter dokumentklassifikation, udtræk, normalisering og validering samt confidence-scorer til vurdering af kvalitet (1861). AWS forklarer ikke offentligt, hvordan scorerne kalibreres i praksis.
Når et dokument sendes ind, kan BDA splitte langs logiske grænser, klassificere sektioner og matche dem med behandlings-blueprints for routing. AWS dokumenterer også kapacitetsgrænser: op til 3.000 sider og 500 MB pr. API-kald samt bred formatunderstøttelse (1861). Tallene står ordret i kilden.
Roller i arkitekturen
I den viste arkitektur styrer Strands Agent (på Bedrock AgentCore Runtime) specialiserede trin og værktøjer. Bedrock Knowledge Base tilfører tværdokument-kontekst, så information kan sættes i relation på tværs af filer (kilder 1861, 1864). Pointen er fordelingen: indtag, udtræk og validering i BDA; orkestrering i agenten; tværgående kontekst i knowledge-laget.
Der findes et offentligt sample-repo, “Intelligent Document Processing with Bedrock Agents”, som demonstrerer mønsteret i praksis. Det er eksempelmateriale – ikke en driftsgaranti (1864).
Et kort walkthrough
En faktura-PDF med bilag lander i S3. BDA modtager via én API, splitter hoveddokument og bilag, klassificerer og udtrækker felter og tabeller. Normalisering og validering kører, og felterne får confidence-scorer.
Agenten ruter efter score: stærke felter går direkte til ERP, tvivlsomme i review-kø. Knowledge Base muliggør tjek mod tidligere dokumenter fra samme leverandør. Outputtet er struktureret data med audit-spor. Kort og brugbart.
Hvad “kontekst” betyder her
I AWS’ materiale dækker kontekst to spor: forståelse af dokumentstruktur og relationer i selve filen, samt mulighed for at trække viden på tværs via en knowledge base med semantisk søgning og indlæsning (1861). Det kan give mere pålideligt udtræk af fx felter og tabeller – men er ikke et løfte om perfekt tolkning af komplekse diagrammer eller blandede sprog. Eget testmateriale er nødvendigt.
Praktisk gør mange det sådan: talfelter og konti kræver højere confidence end fritekst. Fx kan beløb og IBAN kræve meget høj score før automatik, mens beskrivelser må gå i review ved lavere score. Det reducerer dyre fejlposteringer.
Praktik og drift
Blueprintet ser rent ud. I drift opstår kanterne: batching kontra near-realtime, timeouts på store uploads, og hvor grænserne for confidence udløser automatik kontra menneske. Uden klare politikker ender for mange sager i manuelt eftertjek.
Integration kræver forbindelser til ERP, CRM og DMS. Mellemled (API-gateway eller integrationstjeneste) bør kunne håndtere op til 500 MB, understøtte chunking og flow-control, så køer ikke vælter – ellers eksploderer omkostninger og ventetid uden man opdager det.
Metrikker der betyder noget
Et PoC skal måle få, skarpe ting:
- End-to-end latenstid pr. dokument og pr. batch (fx 50, 200, 1.000 dokumenter)
- Udtræksnøjagtighed pr. felt, især tabeller og beløb
- False positives i entitetsgenkendelse og routing
- Andel der kan automatiseres ved valgte confidence-grænser
- Tid sparet i menneskelig kontrol pr. dokumenttype
Uden disse tal er ROI og en holdbar review-kø svære at designe.
Governance og sporbarhed
Der er nogle faste greb, som gør forskellen mellem demo og drift:
- Audit-logging af rå input, normaliseret output og tilhørende confidence-værdier
- Versionering af prompts, pipelines og modelvalg for reproducerbarhed
- Automatisk nedlukning eller fallback til manuel rute, hvis kvaliteten falder under en tærskel
- Review-kø designet fra dag ét, ikke som en eftertanke
- Dataresidency og adgangsstyring dokumenteret pr. integration, inkl. kryptering og roller
Regulering spiller også ind. I mange EU-miljøer kræver afgørende beslutninger stadig menneske-i-løkken og dokumentation for proces og kvalitet. Det er et driftsvalg for at reducere risiko – ikke kun et teknisk spørgsmål.
Begrænsninger og ubesvarede spørgsmål
Kilden deler ikke priser, latenstid eller SLA-krav. Der er heller ikke metode til kalibrering af confidence-scorer eller uafhængige benchmarks af nøjagtighed og throughput (1861). Det må indhentes og testes, før større udrulning.
Svære layouts, komplekse tabeller og sjældne dokumenttyper er stadig åbne felter. Det kræver egne tests med jeres data for at finde fejltyper og sætte de rigtige grænser og fallback.
Modelvalg og alternativer
AWS’ blog nævner ikke specifikke vision-language-modeller. Som perspektiv findes åbne VLM’er som Zyphras Zamba2‑VL i størrelser 1,2B, 2,7B og 7B parametre med hybrid SSM–Transformer-rygrad og mål om lavere latenstid ved konkurrencedygtig nøjagtighed (1863). Om det passer til fakturaer, kontrakter eller journaler må afgøres af benchmarks på egne datasæt.
Hold første iteration simpel: så få modeller og værktøjer som muligt, mål, og skift kun hvis tallene ikke holder.
Tre beslutningspunkter før udrulning
Inden skalering bør tre ting være på plads:
- PoC-scope og KPI’er: inkluder de dokumenttyper, der presser systemet, inkl. lange PDF’er, billeder med grafer og blandede sprog
- Metrikker: end-to-end-latenstid, udtræksnøjagtighed, false positives og tid sparet i kontrol
- Governance og fallback: klare tærskler for automatik kontra review, audit-spor og en plan for degrade-mode
Ellers vokser kompleksiteten, mens sagsbehandlingstiden står stille.
Kilder og verifikation
Hovedfakta om BDA’s pipeline, kapacitetsgrænser og arkitektur fremgår af AWS’ blogindlæg (1861). Sample-implementeringen og agent-mønstret kan ses i GitHub-repoet (1864). Perspektivet på VLM-alternativer stammer fra MarkTechPosts dækning af Zamba2‑VL (1863). Oplysninger om pris, latenstid, SLA og score-kalibrering er ikke i kilderne og må afklares særskilt.
Bundlinjen
Blueprintet samler byggestenene: BDA til multimodalt udtræk med normalisering, validering og confidence, agentisk koordinering af flowet og en knowledge base til tværgående kontekst. Solid base – men drift kræver målinger, review-køer og stram governance. Den reelle forskel viser sig først, når egne dokumenter løber igennem, og tallene ligger på bordet.
