Skip to content
Service status

Skriv for å søke

Teknisk dokumentasjon · 11 min lesing

OCR-pipeline

Slik gjør Intric et opplastet dokument om til en søkbar indeks: layoutbevisst uttrekking, OCR, bildebeskrivelse, oppsummering, oppdeling i tekstbiter og gjenfinningsverktøyene som bygger på dette.

Når du legger en fil ved en assistent, nøyer ikke Intric seg med å trekke ut teksten og kutte den i biter. Intric behandler dokumentet i flere trinn, slik at assistenten allerede før det første spørsmålet vet hva filen handler om, kan finne et avsnitt både på eksakt ordlyd og på mening, og kan bevege seg gjennom dokumentet side for side. Denne artikkelen beskriver trinnene på et teknisk nivå. Hva dette betyr når du bruker en assistent, kan du lese om i Slik søker Intric i dokumentene dine.

Mange gjenfinningssystemer fungerer på samme måte: De trekker ut råteksten, kutter den i biter med fast lengde, gjør hver bit om til en vektor og limer de nærmeste bitene inn i prompten. Det fungerer for korte spørsmål om korte dokumenter, men kommer til kort med det materialet organisasjoner faktisk jobber med:

  • En skannet side har ingen tekst å trekke ut, og bidrar dermed ikke med noe — uten at noen merker det.
  • Et diagram, et flytskjema eller en infografikk faller bort, selv når svaret står nettopp der.
  • En tabell som deles i to, mister koblingen mellom overskriftsraden og radene under.
  • Spør du om et helt kapittel, får du en håndfull løsrevne fragmenter tilbake.
  • Når dusinvis av filer er lagt ved, går hvert søk mot alle sammen, og svake treff fra irrelevante filer fortrenger den riktige.

Hvert trinn nedenfor løser ett av disse problemene.

Behandlingen starter så snart en fil er lagt ved, og kjører i bakgrunnen som en rekke jobber som avhenger av hverandre:

  1. Uttrekking — Intric leser dokumentet side for side. Sider som trenger det, går gjennom OCR, og figurer går til en bildemodell.
  2. Oppsummering — Intric skriver et kort sammendrag av hele filen.
  3. Oppdeling og indeksering — Intric deler teksten opp i små tekstbiter, merker hver bit med plasseringen i dokumentet og indekserer den for både nøkkelordsøk og semantisk søk.

Oppsummering og indeksering starter begge når uttrekkingen er ferdig, og går side om side. Store PDF-er deler Intric inn i seksjoner, trekker ut innholdet fra dem parallelt og setter dem sammen igjen i riktig rekkefølge.

Slik avgjør Intric hvilke sider som trenger OCR

Section titled “Slik avgjør Intric hvilke sider som trenger OCR”

OCR er tregere og mindre nøyaktig enn å lese et tekstlag som allerede finnes, så Intric bruker det ikke på alt. Intric vurderer hver side for seg og sender en side til OCR bare når det ikke er sikkert at tekstlaget er komplett — for eksempel når:

  • siden ikke har noe tekstlag, som i et skannet dokument
  • den innebygde teksten er forvrengt eller bare dekker en del av det som står på siden
  • siden har bilder som er store nok til å ha eget innhold
  • siden inneholder merknader, eller en tabell uten synlige kantlinjer

Sider med et rent tekstlag leser Intric direkte. Er et dokument delvis digitalt opprettet og delvis skannet, håndterer Intric derfor hver side riktig, i stedet for å behandle hele dokumentet som enten det ene eller det andre.

Uttrekkingen tar vare på de delene av en side som får betydningen sin fra plasseringen:

  • Tabeller blir gjenkjent og bygget opp igjen som strukturerte tabeller, slik at hver verdi forblir knyttet til kolonneoverskriften sin.
  • Skjemafelt — avkryssede bokser og utfylte tekstfelt — blir flettet inn i teksten, så et utfylt skjema også fremstår som utfylt.
  • Sidegrenser blir bevart nøyaktig, og det er dette som senere gjør referanser på sidenivå mulig.

Når en side inneholder en figur — et diagram, en graf, en fotografert tabell, en infografikk — beskjærer Intric figurområdet og sender det til en visuell språkmodell. Modellen gjør figuren om til tekst som beskriver hva den viser:

  • teksten i bildet skriver den av
  • diagrammer beskriver den ut fra delene og hvordan de henger sammen
  • tabeller i bilder gjør den om til strukturerte data
  • grafer beskriver den ut fra aksene og datapunktene
  • fotografier, tegninger som plantegninger og skriftprøver beskriver den ut fra hva de viser, fremfor å nøye seg med bildeteksten

Intric setter beskrivelsen inn der figuren står på siden. Dermed står den i sammenheng med resten av siden og blir indeksert som all annen tekst. Står svaret på et spørsmål bare i et flytskjema, kan assistenten likevel svare ut fra den siden og henvise til den som kilde.

Beskrivelsen av figurer er valgfri. På en installasjon uten konfigurert bildemodell fungerer uttrekkingen fortsatt, men bare for tekst.

Type Behandling
PDF Hele pipelinen over, inkludert OCR og figurbeskrivelse
Word, PowerPoint Tekst og struktur trekkes ut direkte
Ren tekst, Markdown, HTML, RTF, JSON og lignende formater Leses som tekst
Excel, CSV En egen vei — se Regneark

Intric skriver et kort sammendrag av hver fil ut fra et representativt utdrag av innholdet.

Det er sammendragene som lar en assistent velge hvilken fil den skal lete i før den søker. Har assistenten få filer, får modellen alle sammendragene fra start. Har den mange, kan modellen bla gjennom fillisten og kjøre et oppdagelsessøk på tvers av alle filene for å finne kandidater. Uansett snevrer modellen inn feltet først, i stedet for å søke i femti dokumenter samtidig og sortere seg gjennom svake treff fra alle sammen. Det gir færre falske treff og holder arbeidskonteksten liten.

Intric deler den uttrukkede teksten i tekstbiter på inntil rundt 300 tokens. Delingen skjer ved den mest naturlige grensen som finnes: først mellom avsnitt, deretter mellom linjer, så mellom setninger, og bare som siste utvei mellom ord. I en PDF krysser en tekstbit aldri en sidegrense, og en tabell eller et annet uttrukket element holdes samlet så lenge det får plass.

Mange systemer gjentar 10–20 % av hver tekstbit i starten av den neste, slik at en setning som blir kuttet ved en grense, overlever i minst én av bitene. Det gjør indeksen større og fyller prompten med den samme teksten to ganger.

Tekstbitene i Intric overlapper ikke. I stedet registrerer hver tekstbit hvor den hører hjemme:

  • sidenummer — siden i originaldokumentet som tekstbiten kommer fra
  • løpenummer — plassen tekstbiten har i rekkefølgen av tekstbiter i dokumentet

Fordi plasseringen er eksplisitt, kan assistenten be direkte om «neste tekstbit» eller «alt på side 66». Sammenhengen er noe assistenten henter når den trenger den, ikke noe som koster plass i hver eneste tekstbit.

Intric indekserer hver tekstbit to ganger: én gang for nøkkelordsøk og én gang som en embeddingvektor for semantisk søk. Hver installasjon har sin egen konfigurerte embeddingmodell, og hver kunnskapsindeks er knyttet til den embeddingmodellen som laget den.

Regneark og CSV-filer deler Intric med vilje ikke opp i tekstbiter, og lager heller ingen embeddinger av dem. Å kutte en tabell i tekstfragmenter og sammenligne dem som vektorer ødelegger det som gjør den til en tabell: Et gjennomsnitt eller en filtrert telling lar seg ikke regne ut fra noen få rader som ligner hverandre.

Assistenten får i stedet strukturen til hvert ark — kolonneoverskriftene, noen eksempelrader og antall rader — og svarer på spørsmål ved å skrive og kjøre kode mot de faktiske dataene i en isolert sandkasse. Et spørsmål som «hvor mange saker ble avsluttet i mars» besvarer assistenten ved å regne det ut, ikke ved å gjette ut fra fragmenter. Regneark får likevel et sammendrag, slik at assistenten kan velge dem blant de andre filene.

Gjenfinning: slik bruker assistenten indeksen

Section titled “Gjenfinning: slik bruker assistenten indeksen”

Når et spørsmål kommer, kjører ikke assistenten ett fast søk. Den har et sett med gjenfinningsverktøy og avgjør selv hvilke den skal bruke, og i hvilken rekkefølge, ut fra spørsmålet.

Verktøy Hva det gjør
Hybridsøk Søker i én fil på nøkkelord og mening samtidig. Modellen bestemmer balansen for hvert søk, fra rent nøkkelordsøk til rent semantisk søk.
Navigerende lesing Henter tekstbiter etter nøyaktig sidenummer eller løpenummer, slik at modellen kan lese fremover eller bakover fra et punkt den har funnet.
Full lesing Leser en hel fil, til oppgaver som krever hele dokumentet.
Oppdagelsessøk Søker på tvers av alle filene til en assistent for å finne ut hvilke som er relevante.

Hybridsøket tar en vekt mellom 0 og 1. Ved 0 er det rent nøkkelordsøk (BM25), ved 1 ren semantisk likhet, og alt imellom blander de to. Modellen velger vekten for hvert søk:

  • et saksnummer, en artikkelhenvisning eller et personnavn krever lav vekt, slik at den eksakte teksten vinner
  • et begrepsmessig spørsmål krever høy vekt, slik at «helseeffekter av uregelmessige arbeidstider» kan matche et spørsmål om nattskift
  • de fleste spørsmål havner et sted imellom

Det er navigerende lesing som gjør at en assistent kan håndtere en forespørsel som «oppsummer kapittel 8»:

  1. Et hybridsøk etter «Kapittel 8» finner tekstbiten der kapittelet begynner, på side 65.
  2. Modellen leser sidenummeret fra plasseringen til den tekstbiten.
  3. Den henter de neste sidene i rekkefølge — 66, 67, 68 — til den kommer til overskriften for kapittel 9.
  4. Den oppsummerer hele kapittelet, med referanser til sidene den har lest.

Ett enkelt søk ville bare gitt åpningsavsnittet i kapittelet og noen spredte passasjer. Ved å lese fremover får modellen med seg alt som står imellom.

Å lese en fil i sin helhet er nyttig for korte dokumenter og for oppgaver som å sammenligne to avtaler, men en svært stor fil ville oversvømt konteksten. For indekserte filer er full lesing begrenset til 60 000 tegn. Er filen større, avviser verktøyet forespørselen og ber modellen bruke hybridsøk eller navigerende lesing i stedet, slik at modellen må snevre inn søket fremfor å lese alt.

Hvorfor ikke bare bruke et stort kontekstvindu

Section titled “Hvorfor ikke bare bruke et stort kontekstvindu”

Modeller med svært store kontekstvinduer kan i prinsippet ta inn en hel dokumentsamling på én gang. I praksis sprer oppmerksomheten seg for tynt over hundretusenvis av tokens: Modellen overser avsnitt i midten og glemmer føringer som kom tidlig. Når modellen henter en liten mengde svært relevant tekst og utvider den bevisst ved behov, holder den arbeidsmaterialet kort og innholdsrikt. Samtidig kan hver bit spores tilbake til der den kom fra.

Hver tekstbit assistenten henter, har med seg fil og sidenummer, og assistenten må oppgi kildene den har brukt. I svaret vises hver referanse som en nummerert kildehenvisning. For en PDF åpner kildehenvisningen originaldokumentet i en visningsrute ved siden av samtalen, på siden det henvises til. Andre filtyper åpner seg i en forhåndsvisning.

Referansene peker på siden, ikke på et markert avsnitt, og de peker inn i filen du lastet opp. Derfor får du de mest nyttige referansene når du laster opp originaldokumentet og ikke en eksportert eller konvertert kopi.

Filer som er lagt ved en assistent, og filer du laster opp direkte i en samtale, går hver sin vei.

Lagt ved assistenten Lastet opp i en samtale
Uttrekking Hele pipelinen, inkludert OCR Hele pipelinen for PDF-er, inkludert OCR; andre filer leses som tekst
Oppsummert og indeksert Ja Nei
Slik brukes filen Assistenten søker i den med gjenfinningsverktøyene Den uttrukkede teksten går rett til modellen
Varighet Så lenge filen er lagt ved Bare i den samtalen
Skala Store bibliotek, mange filer Begrenset av kontekstvinduet til modellen
Passer best til Håndbøker, regelverkssamlinger, arkiver Enkeltstående gjennomganger og sammenligninger

Gjenfinningsverktøyene virker bare på vedlagte filer. En fil du laster opp i en samtale, leser assistenten i sin helhet, så den er begrenset av kontekstvinduet til modellen du bruker. Se Vedlegg.

Mens en fil er under behandling, viser den statusen sin i kunnskapsinnstillingene til assistenten: Venter…, deretter Analyserer… med en fremdriftslinje, og til slutt Ferdig. Statusen oppdaterer seg fortløpende, uten at du må laste siden på nytt. Hvis behandlingen mislykkes, viser filen Mislyktes og knappen Prøv igjen, som kjører behandlingen på nytt.

Pipelinen prøver på nytt på egen hånd før den rapporterer en feil, og forsøker å reparere ødelagte PDF-er før den gir opp. Assistenten ser fortsatt en fil som ikke er ferdig behandlet, men bare som et kort utdrag, og kan ikke søke i den før indekseringen er ferdig.

Grense Verdi
Fil lagt ved en assistent 100 MB
PDF behandlet med OCR 3 000 sider
Fil lastet opp i en samtale 25 MB
Filer per spørsmål i en samtale 20

Intric avviser en PDF over sidegrensen allerede ved opplasting, med en feilmelding som oppgir sidetallet og grensen.

Hvert trinn kjører inne i Intric-plattformen eller på et modellendepunkt som installasjonen velger:

  • OCR og layoutanalyse kjører i selve plattformen, uten at noen ekstern tjeneste er involvert.
  • Figurbeskrivelse, oppsummering og embedding kaller hver for seg et modellendepunkt som konfigureres separat for hver installasjon.

På en on-prem-installasjon kan hvert av disse peke på en modell som kjører på din egen infrastruktur, slik at et dokument kan behandles fra opplasting til indeks uten å forlate miljøet ditt. Pipelinen er avhengig av en jobbkø og en søkeindeks som er en del av dagens installasjoner. En eldre on-prem-installasjon som ennå ikke kjører disse, bruker den tidligere kunnskapsbehandlingen til den blir oppgradert. Hvordan dokumentdata flyter mellom Intric og embeddingmodellen i skytjenesten, kan du lese om i Dataflyt for Kunnskap.