Hoppa till innehåll
Service status

Skriv för att söka

Teknisk dokumentation · 11 min läsning

OCR-pipeline

Så gör Intric om ett uppladdat dokument till ett sökbart index: layoutmedveten extrahering, OCR, bildbeskrivning, sammanfattning, segmentering och de sökverktyg som bygger på indexet.

När du kopplar en fil till en assistent nöjer sig Intric inte med att plocka ut texten och klippa den i bitar. Intric bearbetar dokumentet i flera steg, så att assistenten redan när den första frågan kommer vet vad filen handlar om, kan hitta ett avsnitt på exakt ordalydelse eller på betydelse och kan röra sig genom dokumentet sida för sida. Den här artikeln beskriver stegen på en teknisk nivå. Vad det innebär när du använder en assistent kan du läsa om i Så här söker Intric i dina dokument.

Många system för informationshämtning fungerar på samma sätt: de extraherar råtexten, delar upp den i bitar med fast längd, gör om varje bit till en vektor och klistrar in de närmaste bitarna i prompten. Det fungerar för korta frågor om korta dokument. Men med det material som organisationer faktiskt arbetar med håller det inte:

  • En skannad sida har ingen text att extrahera och bidrar därför inte med något, utan att någon märker det.
  • Ett diagram, ett flödesschema eller en infografik faller bort, även när svaret finns just där.
  • En tabell som hamnar i två bitar tappar kopplingen mellan rubrikraden och raderna under.
  • Den som frågar om ett helt kapitel får tillbaka en handfull lösryckta fragment.
  • När dussintals filer är kopplade till assistenten går varje sökning mot allihop, och svaga träffar från ovidkommande filer tränger undan den rätta.

Vart och ett av stegen nedan finns till för att lösa ett av de här problemen.

Bearbetningen startar så fort du kopplar en fil till assistenten och pågår i bakgrunden, som en serie jobb som är beroende av varandra:

  1. Extrahering — Intric läser dokumentet sida för sida. Sidor som behöver det går igenom OCR, och figurer går vidare till en visionsmodell.
  2. Sammanfattning — Intric skriver en kort sammanfattning av hela filen.
  3. Segmentering och indexering — Intric delar upp texten i små segment (chunks), märker vart och ett med dess position i dokumentet och indexerar dem för både nyckelordssökning och semantisk sökning.

Sammanfattningen och indexeringen startar båda när extraheringen är klar, och de pågår parallellt. Stora PDF-filer delar Intric upp i sektioner, extraherar dem parallellt och fogar sedan ihop dem i rätt ordning.

Så avgör Intric vilka sidor som behöver OCR

Section titled “Så avgör Intric vilka sidor som behöver OCR”

OCR är långsammare och mindre exakt än att läsa ett textlager som redan finns, så Intric använder inte OCR på allt. Intric bedömer varje sida för sig och skickar den till OCR bara när det inte går att lita på att textlagret är komplett. Det gäller till exempel när:

  • sidan saknar textlager, som i ett skannat dokument
  • den inbäddade texten är trasig eller bara täcker en del av det som står på sidan
  • sidan innehåller bilder som är stora nog att ha eget innehåll
  • sidan har annoteringar eller en tabell utan synliga linjer

Sidor med ett rent textlager läser Intric direkt. Ett dokument som är delvis digitalt från början och delvis skannat hanterar Intric därför rätt, sida för sida, i stället för att behandla hela dokumentet som antingen det ena eller det andra.

Vid extraheringen behåller Intric de delar av sidan vars betydelse hänger på var de står:

  • Tabeller känner Intric igen och återskapar som strukturerade tabeller, så att varje värde stannar under sin kolumnrubrik.
  • Formulärfält — ikryssade kryssrutor och ifyllda textfält — blir en del av texten, så att ett ifyllt formulär också framstår som ifyllt.
  • Sidgränser behåller Intric exakt, och det är det som senare gör referenser på sidnivå möjliga.

När en sida innehåller en figur — ett schema, ett diagram, en fotograferad tabell, en infografik — klipper Intric ut figuren och skickar den till en visionsspråkmodell, alltså en språkmodell som kan tolka bilder. Modellen skriver en textbeskrivning av vad figuren visar:

  • text i bilden skriver modellen av ordagrant
  • i scheman beskriver modellen delarna och hur de hänger ihop
  • tabeller i bilder gör modellen om till strukturerade data
  • diagram beskriver modellen utifrån axlar och datapunkter
  • foton, ritningar som planritningar och typsnittsprover beskriver modellen utifrån vad de föreställer, i stället för att bara återge bildtexten

Intric lägger in beskrivningen där figuren sitter på sidan, så att den hamnar i sitt sammanhang, och indexerar den som all annan text. Då kan assistenten besvara en fråga vars svar bara finns i ett flödesschema, och hänvisa till just den sidan.

Figurbeskrivningen är valfri. I en installation där ingen visionsmodell är konfigurerad fungerar extraheringen ändå, men bara för text.

Typ Så läser Intric filen
PDF Hela pipelinen ovan, inklusive OCR och figurbeskrivning
Word, PowerPoint Intric extraherar text och struktur direkt
Ren text, Markdown, HTML, RTF, JSON och liknande format Intric läser innehållet som text
Excel, CSV En egen väg — se Kalkylblad

Intric skriver en kort sammanfattning av varje fil utifrån ett representativt utdrag av innehållet.

Det är sammanfattningarna som gör att en assistent kan välja vilken fil den ska leta i innan den söker. När assistenten har få filer får modellen alla sammanfattningar direkt från början. Har assistenten många filer kan modellen bläddra i fillistan och köra en översiktssökning i alla filer för att hitta kandidater. Oavsett vilket snävar modellen först in urvalet, i stället för att söka i femtio dokument på en gång och sålla bland svaga träffar från samtliga. Det ger färre felträffar och håller den kontext som modellen arbetar med liten.

Intric delar upp den extraherade texten i segment på upp till ungefär 300 tokens. Varje delning hamnar vid den mest naturliga gräns som finns: i första hand mellan stycken, sedan mellan rader, sedan mellan meningar och bara i sista hand mellan ord. I en PDF går ett segment aldrig över en sidgräns, och Intric håller ihop en tabell eller ett annat extraherat element när det får plats.

Ingen överlappning, men en tydlig position

Section titled “Ingen överlappning, men en tydlig position”

Många system upprepar 10–20 % av varje segment i början av nästa, så att en mening som hamnar på en gräns ändå finns hel i minst ett segment. Det gör indexet större och fyller prompten med samma text två gånger.

Intrics segment överlappar inte. I stället har varje segment uppgift om var det hör hemma:

  • sidnummer — den sida i originaldokumentet som segmentet kommer från
  • segmentindex — segmentets plats i dokumentets följd av segment

Eftersom positionen är uttrycklig kan assistenten direkt be om “nästa segment” eller “allt på sidan 66”. Assistenten hämtar alltså det omgivande sammanhanget när den behöver det, i stället för att varje segment bär på det i förväg.

Intric indexerar varje segment två gånger: för nyckelordssökning och som en vektor (embedding) för semantisk sökning. Varje installation har sin egen konfigurerade embedding-modell, och varje kunskapsindex är knutet till den embedding-modell som skapade det.

Intric delar medvetet inte upp kalkylblad och CSV-filer i segment och skapar inga embeddings för dem. Att klippa sönder en tabell i textfragment och jämföra dem som vektorer förstör just det som gör den till en tabell: ur några rader som ser likadana ut går det inte att räkna fram ett medelvärde eller ett filtrerat antal.

I stället får assistenten strukturen för varje blad — kolumnrubrikerna, några exempelrader och antalet rader — och besvarar frågor genom att skriva och köra kod mot den faktiska datan i en isolerad sandlåda. En fråga som “hur många ärenden avslutades i mars” besvarar assistenten genom att räkna ut det, inte genom att gissa utifrån fragment. Kalkylblad får ändå en sammanfattning, så att assistenten kan välja dem bland andra filer.

Sökning: så använder assistenten indexet

Section titled “Sökning: så använder assistenten indexet”

När du ställer en fråga kör assistenten inte en enda förutbestämd sökning. Assistenten har ett antal sökverktyg och avgör utifrån frågan vilka den ska använda och i vilken ordning.

Verktyg Vad det gör
Hybridsökning Söker i en fil på nyckelord och betydelse samtidigt. Modellen bestämmer viktningen för varje sökning, från ren nyckelordsmatchning till ren semantisk matchning.
Navigerande läsning Hämtar segment utifrån exakt sidnummer eller segmentindex, så att modellen kan läsa framåt eller bakåt från en punkt den har hittat.
Fullständig läsning Läser en hel fil, för uppgifter som kräver hela dokumentet.
Översiktssökning Söker i alla assistentens filer för att se vilka som är relevanta.

Hybridsökningen tar en vikt mellan 0 och 1. Vid 0 är det ren nyckelordsmatchning (BM25), vid 1 ren semantisk likhet, och allt däremellan blandar de två. Modellen väljer vikten för varje sökning:

  • ett ärendenummer, en hänvisning till en artikel eller ett personnamn kräver en låg vikt, så att den exakta formuleringen vinner
  • en begreppslig fråga kräver en hög vikt, så att “hälsoeffekter av oregelbundna arbetstider” kan matcha en fråga om nattarbete
  • de flesta frågor hamnar någonstans mittemellan

Det är navigerande läsning som gör att en assistent klarar en begäran som “sammanfatta kapitel 8”:

  1. En hybridsökning efter “Kapitel 8” hittar segmentet där kapitlet börjar, på sidan 65.
  2. Modellen läser av sidnumret från segmentets position.
  3. Modellen hämtar sidorna som följer i tur och ordning — 66, 67, 68 — tills den når rubriken för kapitel 9.
  4. Modellen sammanfattar hela kapitlet, med hänvisningar till de sidor den har läst.

En enda sökning hade gett tillbaka kapitlets inledande stycke och några utspridda avsnitt. Genom att läsa framåt får modellen med allt däremellan.

Att läsa en hel fil är användbart för korta dokument och för uppgifter som att jämföra två avtal, men en mycket stor fil skulle svämma över kontexten. För indexerade filer är en fullständig läsning begränsad till 60 000 tecken. Är filen större säger verktyget nej och uppmanar modellen att använda hybridsökning eller navigerande läsning i stället. Modellen måste alltså ringa in det den behöver i stället för att läsa allt.

Varför inte bara ett stort kontextfönster

Section titled “Varför inte bara ett stort kontextfönster”

Modeller med mycket stora kontextfönster kan i princip ta in en hel dokumentsamling på en gång. I praktiken tunnas uppmärksamheten ut över hundratusentals tokens: modellen förbiser avsnitt i mitten och glömmer villkor som kom tidigt i texten. När Intric hämtar en liten mängd mycket relevant text och vidgar urvalet medvetet vid behov, blir det modellen arbetar med kort och koncentrerat. Varje del går dessutom att spåra till sitt ursprung.

Varje segment som assistenten hämtar har med sig fil och sidnummer, och assistenten måste hänvisa till de källor den har använt. I svaret är varje referens en numrerad källhänvisning. För en PDF öppnar källhänvisningen originaldokumentet i en visare bredvid konversationen, på den sida som hänvisningen gäller. Andra filtyper visar Intric i en förhandsvisning.

Referenserna pekar på sidan, inte på ett markerat avsnitt, och de pekar in i filen du laddade upp. Därför får du de mest användbara referenserna när du laddar upp originaldokumentet och inte en exporterad eller konverterad kopia.

Filer som är kopplade till en assistent och filer som du laddar upp direkt i en konversation går olika vägar.

Kopplad till assistenten Uppladdad i en konversation
Extrahering Hela pipelinen, inklusive OCR Hela pipelinen för PDF-filer, inklusive OCR; övriga filer läser Intric som text
Sammanfattad och indexerad Ja Nej
Användning Assistenten söker i den med sökverktygen Modellen får den extraherade texten direkt
Finns kvar Så länge den är kopplad till assistenten I den konversationen
Omfattning Stora bibliotek, många filer Modellens kontextfönster sätter gränsen
Passar bäst för Handböcker, policysamlingar, arkiv Tillfälliga granskningar och jämförelser

Sökverktygen fungerar bara på kopplade filer. En fil som du laddar upp i en konversation läser modellen i sin helhet, så kontextfönstret i den modell du använder sätter gränsen. Se Bilagor.

Medan Intric bearbetar en fil visar filen sin status i assistentens kunskapsinställningar: Väntar…, sedan Analyserar… med en förloppsindikator och till sist Klar. Statusen ändras live, utan att du behöver ladda om sidan. Om bearbetningen misslyckas visar filen Misslyckades och knappen Försök igen, som kör bearbetningen på nytt.

Pipelinen gör själv nya försök innan den rapporterar ett fel, och försöker reparera skadade PDF-filer innan den ger upp. En fil som inte är färdigbearbetad syns ändå för assistenten, men bara som ett kort utdrag, och assistenten kan inte söka i den förrän indexeringen är klar.

Gräns Värde
Fil som är kopplad till en assistent 100 MB
PDF-fil som går igenom OCR 3 000 sidor
Fil uppladdad i en konversation 25 MB
Filer per fråga i en konversation 20

Intric avvisar en PDF som överskrider sidgränsen redan vid uppladdningen, med ett felmeddelande som anger dokumentets sidantal och gränsen.

Alla steg sker inuti Intric-plattformen eller mot en modellslutpunkt som installationen själv väljer:

  • OCR och layoutanalys sker i själva plattformen, utan någon extern tjänst inblandad.
  • Figurbeskrivning, sammanfattning och embedding anropar var för sig en modellslutpunkt som varje installation konfigurerar separat.

I en on-prem-installation kan var och en av dessa peka på en modell i den egna infrastrukturen, så att ett dokument kan gå hela vägen från uppladdning till index utan att lämna den egna miljön. Pipelinen är beroende av en jobbkö och ett sökindex som ingår i dagens installationer. En äldre on-prem-installation som ännu inte kör dem använder den tidigare kunskapsbearbetningen fram till en uppgradering. Hur dokumentdata rör sig mellan Intric och embedding-modellen i molntjänsten kan du läsa om i Dataflöden för kunskap.