CI/CD og strukturert ekstraksjon

En subtil, men svært ofte testet regel: I CI skal kode gjennomgås i en ISOLERT økt, separat fra økten som genererte den.

Hvorfor? Den genererende økten beholder sin egen tankegang og er tilbøyelig til å forsvare arbeidet sitt — selvgjennomgang i samme økt er et typisk anti-mønster. En ny, uavhengig instans har ingen tilknytning til utdataene og utfordrer dem på en ærlig måte.

Dette gjenspeiler regelen fra uttrekkingsverdenen om at gjennomgang av en uavhengig/ny instans er bedre enn selvgjennomgang i samme økt. Forfatteren vil ikke argumentere mot sine egne konklusjoner; en uhildet gjennomgår vil gjøre det.

En CI-gjennomgår som roper «ulv» uten grunn, blir ignorert. Målet i scenario 5 er å minimere falske positiver, slik at utviklerne stoler på kontrollen.

Det som gjør forskjellen, er eksplisitte kriterier, ikke vage oppfordringer. «Vær mer presis» endrer ingenting. «Flagg en kommentar KUN når den motsier koden» gir modellen en tydelig og testbar grense.

Ved nye kjøringer bør du ikke ta alt opp til ny vurdering: ta med de tidligere resultatene og rapporter bare nye eller fortsatt uløste problemer. Slik holdes signalet rent gjennom flere iterasjoner.

En klassisk distraktor: «bruk Batch API for å kutte CI-kostnadene med 50 %». Det er feil for en kontroll før fletting.

Message Batches er 50 % billigere og har et tidsvindu på opptil 24 timer, men de har INGEN SLA for responstid og STØTTER IKKE flertrinns verktøykall. En blokkerende og tidssensitiv kontroll (som en PR-kontroll) kan ikke vente ubestemt lenge.

• Bruk Batch til arbeid som ikke blokkerer: rapporter over natten, store revisjoner og nattlige uttrekk.
• IKKE bruk Batch til kontroller før fletting, blokkerende kontroller eller interaktive kontroller.

For batch-jobber knytter custom_id hver forespørsel til resultatet, og du sender bare inn feilene på nytt.

Nå til scenario 6. For å trekke ut data på en pålitelig måte bør du ikke be om JSON i prosa og håpe på det beste. Bruk tool_use med et JSON Schema: Dette eliminerer syntaksfeil og håndhever obligatoriske felt.

Sett tool_choice til "any" for å garantere at modellen kaller et verktøy (det vil si produserer strukturert utdata) i stedet for fri tekst. Bruk {"type":"tool","name":"X"} for å tvinge frem ett bestemt uttrekksverktøy.

Den mest testede skjemaregelen er: Merk et felt som obligatorisk KUN hvis det alltid finnes i kilden.

Hvis du krever et felt som kan mangle, har modellen ingen lovlig måte å oppfylle skjemaet på, bortsett fra å fabrikere en verdi. Du har byttet ut et manglende felt med en hallusinert verdi — noe som er langt verre i en datapipeline.

For valgfrie eller åpne verdier bør du foretrekke en enum med verdien «other» samt et fritekstfelt for detaljer. Da forblir utdataene strukturerte, samtidig som de kan utvides med tilfeller du ikke hadde spesifisert.

Et skjema begrenser formen, ikke riktigheten. Pakk inn uttrekkingen i en valideringssløyfe (validering i Pydantic-stil er det kanoniske mønsteret).

Når valideringen mislykkes, bruker du retry-with-feedback: Send modellen tre ting samlet — originaldokumentet, den feilaktige utdataen den produserte, og den nøyaktige valideringsfeilen. Dette er presist nok til å rette format-, struktur- og regnefeil.

En viktig grense: nytt forsøk retter FORMATfeil. Det hjelper IKKE når informasjonen ganske enkelt MANGLER i kilden — å spørre et dokument på nytt etter data det aldri inneholdt, inviterer bare til et fabrikert svar.

Hvordan oppdager du en feilaktig tallverdi som skjemaet uten videre godtok? Bygg kontrollen inn i selve uttrekkingen.

Mønsteret er å trekke ut både calculated_total (summen av linjeelementene) og stated_total (tallet som står på dokumentet). Sammenlign dem deretter i koden.

Hvis de avviker, har du oppdaget et avvik på en deterministisk måte — enten en dokumentfeil eller en uttrekksfeil — og kan flagge, prøve på nytt eller eskalere. Ett tall kan lyve ubemerket; to tall avslører løgnen.

Uttrekking uten proveniens kan ikke revideres. For hver uttrekkede påstand bør du beholde en kobling mellom påstand og kilde: kildedokumentets navn eller URL, det underbyggende sitatet og publiseringsdatoen.

Når to kilder oppgir motstridende tall, må du ikke velge ett av dem vilkårlig — annoter konflikten. Ofte er det datoene som løser den tilsynelatende motsetningen (det ene tallet er ganske enkelt nyere).

Presenter også innholdet etter innholdstype: tabeller for økonomiske data, prosa for fortellinger og lister for tekniske funn. Proveniens kombinert med riktig presentasjon gjør utdataene pålitelige nok til automatisering.

Før De lar en uttrekkingspipeline kjøre uten tilsyn, må De validere den på en ærlig måte. En overskrift som «97 % nøyaktighet» kan skjule svak ytelse på én bestemt dokumenttype eller ett bestemt felt.

Den disiplinerte fremgangsmåten:

• Stratifisert tilfeldig utvalg på tvers av dokumenttyper – ikke et bekvemmelighetsutvalg.
• Konfidens på feltnivå, kalibrert mot et merket valideringssett, før automatisering.

Metrikker som bare aggregerer resultater, er et kjent anti-mønster. Et gjennomsnitt på 97 % med 40 % nøyaktighet på skatteskjemaer er en produksjonshendelse som bare venter på å inntreffe.

Viktige læringspunkter for CI/CD og strukturert uttrekking:

• Hodeløs kjøring: -p / --print + --output-format json for ikke-interaktive og analyserbare pipeline-kjøringer.
• Isolert gjennomgang er bedre enn egengjennomgang i samme økt; eksplisitte kriterier minimerer falske positiver; ved nye kjøringer rapporteres bare nye eller uløste problemer.
• Batch-API = 50 % billigere, ingen SLA for ventetid, ingen verktøy i flere samtaler – for nattlige jobber, ALDRI blokkerende kontroller.
• Strukturert resultat: tool_use + JSON Schema; tool_choice:"any" garanterer et strukturert kall.
• Påkrevd bare hvis det alltid finnes – å kreve et fraværende felt tvinger frem fabrikering; bruk enum + «other» + detalj for utvidbarhet.
• Ny kjøring med tilbakemelding (originaldokument + feil resultat + nøyaktig feil) korrigerer FORMAT-feil, ikke FRAVÆRENDE data.
• Selvkorrigering med beregnede kontra oppgitte totaler; behold proveniens (kilde, sitat, dato) og kommenter konflikter.
• Valider med stratifisert utvalg + konfidens på feltnivå – aggregert nøyaktighet skjuler svake punkter.