--- title: "Søk i ontologien slår søk i dokumentene" url: "https://hurukan.com/no/blog/sok-i-ontologien" description: "Søk i en haug dokumenter finner tekst som virker relevant. Søk i en modell av virksomheten finner fakta som gjelder nå, sammen med relasjonene deres." --- # Søk i ontologien slår søk i dokumentene 7\. september 2026·3 min lesing·Redaksjonen Ryddige grå arkivhyller med merkede permer i et moderne arkivrom, én perm trukket halvveis ut med en blå fane og en hånd som strekker seg etter den, kort dybdeskarphet En virksomhet kobler en språkmodell til dokumentarkivet sitt: kontrakter, prosedyrer, retningslinjer og møtereferater, mange års opphopning. Dette kalles gjenfinningsforsterket generering, gjerne forkortet RAG: når noen stiller et spørsmål, finner systemet de tekstutdragene som ligner mest på spørsmålet, og gir dem til modellen som grunnlag for svaret. En medarbeider i kundeservice spør hvilke leveringsbetingelser en bestemt kunde har. Systemet finner tre versjoner av kundens kontrakt, et utkast til tillegg som aldri ble signert, og en e-post der noen foreslo andre betingelser. Modellen blander dem til et flytende og selvsikkert svar som ikke stemmer med noen av dem. En annen dag finner den virksomhetens generelle vilkår i stedet for det kundespesifikke tillegget som går foran dem. Årsaken ligger i hvordan dokumentsøk fungerer. Det finner tekst med en betydning som ligner spørsmålet. Det vet ikke hvilken versjon som gjelder, hvilket dokument som er et utkast, hvilken kunde en klausul gjelder for, eller at et tillegg går foran de generelle vilkårene. Det er ikke egenskaper ved tekst. Det er tilstander og relasjoner, og det er nettopp det en modell av virksomheten, en ontologi, finnes for å holde på. ## Der dokumentsøk svikter **Versjoner.** En utgått kontrakt ligner like mye på spørsmålet som den gjeldende, og hentes derfor like gjerne frem. Likhet har ikke noe begrep om «gjeldende». **Relasjoner som går tapt i oppdelingen.** Dokumenter deles opp i biter før de indekseres. En klausul om leveringsbetingelser havner i én bit, siden som navngir kunden i en annen, og koblingen mellom dem er borte. **Spørsmål som egentlig er tellinger.** «Hvor mange åpne reklamasjoner har denne kunden?» står ikke skrevet i noe dokument. Det er en telling over poster, og ingen mengde tekstlikhet vil gi det svaret på en pålitelig måte. **Tilganger som kommer for sent.** Hvis indeksen inneholder dokumenter personen som spør ikke har lov til å se, er det skjørt å filtrere dem bort etter søket, og én feil viser fortrolig tekst til feil person. **Ferskhet.** Indeksen er aldri nyere enn siste gjenoppbygging. Kontrakten som ble signert i morges, ligger ikke der ennå. **Kildehenvisninger som ikke avgjør noe.** Svaret siterer et utdrag, men ingenting forteller leseren om utdraget kommer fra dokumentet som gjelder nå. ## Søk i modellen først, deretter i dokumentene **Start med objektet.** Spørsmålet nevner en kunde. Koble det til kundeobjektet i ontologien, og følg deretter relasjonene: kontraktene som gjelder, tilleggene deres, åpne ordrer, åpne reklamasjoner. Modellen av virksomheten gjør den innsnevringen som likhet ikke klarer. **Søk i dokumenter som er knyttet til poster.** Den gjeldende kontrakten er dokumentet som hører til kontraktsposten med status «gjeldende». Tekstsøket kjører deretter i det dokumentet, ikke i alt virksomheten noen gang har skrevet. **Svar på strukturerte spørsmål med spørringer.** Antall, summer, datoer og statuser hentes fra postene og beregnes, ikke fra utdrag som tilfeldigvis nevner dem. **Bruk tilgangene før søket.** Rettighetene til personen avgjør hvilke objekter som i det hele tatt er synlige. Modellen får aldri resten, og kan derfor ikke lekke det. **Henvis til posten og versjonen.** Svaret lenker til kontraktsposten, versjonen og klausulen, slik at personen kan sjekke det med ett klikk. Dokumentsøk er fortsatt nyttig for kunnskap som faktisk lever i løpende tekst: prosedyrer, håndbøker, opparbeidet erfaring. Selv der fungerer det bedre når hvert dokument er knyttet til objektene det beskriver, slik at søket kan starte på riktig sted. Slik er Hurukan utformet. Hvert dokument er knyttet til sin post, med revisjoner og gjennomganger, slik det er beskrevet under [Prosjekter og dokumenter](https://hurukan.com/no/modules/prosjekter-og-dokumenter). [Ontologi-laget](https://hurukan.com/no/system/ontologi) holder objektene, relasjonene og tilstandene, og [Superintelligens-laget](https://hurukan.com/no/system/superintelligens) er utformet for å forankre modellene sine i den strukturen først, med tilgangene allerede anvendt. Det er under utvikling. Hvor en slik modell kommer fra i utgangspunktet, er temaet i [virksomheten din har allerede en ontologi](https://hurukan.com/no/blog/virksomheten-din-har-allerede-en-ontologi). ## En test du kan gjøre i dag Samle ti spørsmål medarbeiderne dine faktisk stilte denne måneden om kunder, ordrer, leverandører eller kontrakter. Skriv for hvert av dem ned hvor det riktige svaret egentlig ligger: - i ett dokument, - i flere dokumenter som må settes sammen, - i en post, - eller i en telling eller sum over mange poster. Still deretter de samme ti spørsmålene til dokumentsøksystemet du har i dag, om du har et, og kontroller hvert svar mot den faktiske kilden. Noter hvor feil versjon, feil kunde eller en oppdiktet telling dukker opp. Hvis feilene samler seg i alle kategoriene unntatt «ett dokument», har du funnet grensen for dokumentsøk, og det er en grense i utformingen, ikke i modellen. Det større spørsmålet om hvor språkmodeller hjelper og ikke hjelper, tar vi for oss i [der språkmodeller gjør nytte for seg](https://hurukan.com/no/blog/der-sprakmodeller-gjor-nytte-for-seg). - RAG - informasjonssøk - ontologi - kunnskapsforvaltning ## Les videre - [Én identitet for mennesker og agenter: hvem får gjøre hva](https://hurukan.com/no/blog/en-identitet-for-mennesker-og-agenter) - [Nåtilstand og register: to minner i et operativsystem for virksomheten](https://hurukan.com/no/blog/naatilstand-og-registeret-to-minner)