Kunnskapsbasen

Kunnskapsbasen for én kjøring

Hva må være på plass før systemet kan lete etter besparelser i et konkret prosjekt — og hvordan setter man det sammen?

Gjennomgangen følger ett eksempel hele veien: en fylkeskommunal veglysportefølje som vurderer å bytte ut 2 500 gamle lyspunkter med LED.

Bestilling hva skal vurderes Kunnskapsbase konteksten Kjøring forslag + kontroll Dom fagperson dommen gjør basen klokere til neste gang

Premisset

Systemet navigerer. Det søker ikke.

Kunnskapsbasen er ikke en søkbar dokumentbunke. Den er en liten, kuratert samling som leses ved å følge lenker: systemet starter i innholdsfortegnelsen, følger lenkene derfra, og leser hver fil det når — helt, eller ikke i det hele tatt.

kunnskapsbasen Innholds- fortegnelse Anleggsbeskrivelse Tiltaksnotat Metodenotat notat uten lenke — finnes ikke nabobase følges aldri
Alt som lenkes leses i sin helhet. Det som ikke lenkes, eksisterer ikke.

Én ting holdes alltid utenfor den løpende lesingen: tidligere ekspertdommer. De hentes for seg, koblet til det konkrete tiltaket de handler om, og legges foran når systemet skal forme sin hypotese.

Kategoriene

Fire lag, som skiller seg på hva de følger

inne i kunnskapsbasen — varig Prosjektlaget følger anlegget · prosjekteier og drift Faglaget følger fagområdet · fagmiljøet Erfaringslaget følger organisasjonen over tid · fagekspertene Kjøringslaget følger denne ene bestillingen ved siden av — lagres aldri

Prosjektlaget følger anlegget: hva det består av, hvilke tall det har, hvilke rammer som gjelder. Faglaget følger fagområdet, og er i praksis det samme på tvers av prosjekter i samme fag. Erfaringslaget er de tidligere dommene, og det er dette laget som gjør systemet klokere fra kjøring til kjøring.

Det er én kunnskapsbase per prosjekt. Kjøringslaget ligger utenfor — det er en instruks for én kjøring, ikke kunnskap. En portefølje er flere baser.

Avgjørelsene

Fjorten spørsmål til fagpersonen

Hvert spørsmål avgjør én konkret del av basen. De fire første avgjør om kjøringen i det hele tatt kan starte.

Spørsmål 1–4 uten svar: ingen kjøring Spørsmål 5–14 former kvaliteten på det som kommer ut
  1. Hvilket prosjekt eller anlegg gjelder det, og hva skal det hete?
  2. Hvilke kostnadslinjer kan tiltakene komme til å treffe — og har vi faktiske tall for dem?
  3. Hvilket tiltak er «det ene» vi regner på?
  4. Hvilke harde rammer gjelder — hva kan ikke fravikes?
  5. Hva er allerede gjennomført på anlegget?
  6. Hvilke tiltakstyper er typiske for denne prosjekttypen?
  7. Hvilke tilnærminger ønsker vi vurdert?
  8. Hvordan skal effekten måles i etterkant?
  9. Hva finnes av litteratur om avviket mellom modellert og faktisk effekt?
  10. Finnes det tidligere erfaring vi kan starte med?
  11. Skal kjøringen avgrenses til én kostnadsakse?
  12. Skal noen datakilder leses maskinelt, eller er alt håndkuratert?
  13. Hvilke eksterne systemer må agentene kunne spørre underveis — og nøyaktig hva skal de få lov til å kalle?
  14. Hvem avgir dommen etterpå?

Historikken

«Hva er gjort før?» er to ulike spørsmål

Begge må besvares, og de havner på hvert sitt sted i basen. Blandes de, blir svaret feil på en måte som er vanskelig å oppdage.

Gjennomførte tiltak hva som faktisk er bygget om når, og på hvor mye av anlegget hører i anleggsbeskrivelsen og i kostnadsgrunnlaget Tidligere vurderinger hva fagfolk mente om et forslag og hvor mye som ble realisert hører i erfaringslaget som tidligere dommer to ulike spørsmål — to ulike steder i basen

Gjennomførte tiltak må inn, ellers foreslås de på nytt. Systemet vet ingenting om anlegget utover det basen sier. Er 3 000 av 9 500 lyspunkter allerede byttet til LED, og det ikke står noe sted, vil et forslag om «å bytte til LED» framstå som friskt — og besparelsen det lover er allerede tatt ut. Det er dobbelttelling, og den er usynlig i resultatet.

Kostnadsgrunnlaget må vise dagens situasjon, ikke situasjonen før forrige tiltak. Ellers avstemmes nye forslag mot et forbruk anlegget ikke lenger har.

Tommelfingerregel: alt som endrer hva anlegget er, hører i anleggsbeskrivelsen. Alt som endrer hva vi tror om et tiltak, hører i erfaringslaget.

Tiltakstypene

Hva kan man typisk optimalisere — per prosjekttype?

Fagpersonen trenger ikke finne opp kandidatene fra bunnen. For hver prosjekttype finnes det et ganske stabilt sett av tiltakstyper, og jobben er å avgjøre hvilke som er aktuelle for dette anlegget.

VEG Belysning: LED, dimming, nattreduksjon Dekke: levetid, dekketype, reasfalteringsintervall Vinterdrift: saltstrategi, rodeinndeling Utstyr: tilstandsbasert framfor intervallbasert TUNNEL Belysning: trinnstyring av innkjøringssone, LED Portalskjerming: passiv reduksjon av lyskrav Ventilasjon: behovsstyring på målt luftkvalitet Stengninger: samordning av vedlikehold BRO Inspeksjonsregime: tilstandsbasert Korrosjonsvern: syklus og systemvalg Fuger og lager: utskiftingsstrategi Levetidsforlengelse framfor utskifting
Veg og tunnel er bygget og kjørt som eksempelbaser. Bro-kolonnen er en illustrasjon av formen — den er ikke fagverifisert, og må erstattes av fagmiljøets egen liste.

Det som avgjør om en tiltakstype i det hele tatt kan vurderes, er om den lar seg uttrykke som en kostnadslinje — en mengde ganger en enhetspris. Et tiltak som ikke kan det, kan systemet foreslå, men ikke kontrollere. Da er svaret verdt akkurat like mye som et vanlig godt råd.

Derfor er spørsmål 2 — «har vi faktiske tall for kostnadslinjene?» — det som i praksis avgjør hvilke tiltakstyper som er i spill for et gitt anlegg.

Innholdet

Seks typer tekst, og to sett med tall

Innholdsfortegnelsen er inngangen. Teksten i den er det aller første systemet leser, ordrett, og lenkene bestemmer hva som ellers blir lest. Uten den kan kjøringen ikke starte.

Anleggsbeskrivelsen forteller hva anlegget er, hvilke tall det består av, og hvilket gulv ingen besparelse kan gå under.

Tiltaksnotatene beskriver kandidatene med parametere: modellert besparelse, hva som er usikkert, hva som er utledet. Det er disse forslagene systemet forbedrer, i stedet for å finne opp sine egne fra bunnen.

Metodenotatet forklarer hvordan effekten skal måles, og hvilke metoder som er stengt for akkurat dette anlegget.

Kildenotatet er verifisert litteratur med årstall og opphav, der eget materiale er tydelig skilt fra lånt.

Tidligere dommer er erfaringslaget: en beslutning, en begrunnelse, og hvor stor andel av den modellerte besparelsen som faktisk pleier å bli realisert.

Innholdet

De to tallfilene

Ved siden av teksten ligger to sett med tall, og de har helt ulike jobber.

Den regnede kandidaten hvilke kostnadslinjer tiltaket virker på hvor mye det skal spare hvor stort usikkerhetsbåndet er mangler den: kjøringen nektes Kostnadsgrunnlaget prosjektets faktiske kostnadslinjer mengde og enhetspris per linje fasiten forslaget avstemmes mot mangler det: kjøringen går likevel avstemmes mot
Prosjektnavnet må være identisk på kommandolinjen og i begge tallsettene. Er det ikke det, nektes kjøringen — bevisst, fordi et forslag som blandes mellom to prosjekter er verre enn ingen kjøring.

Den skarpeste mangelen

Uten kostnadsgrunnlag dømmer kontrollen bare mot forslagets egne tall

MED kostnadsgrunnlag Forslag oppdiktet linje Steg 0 avstemming mot ekte tall AVVIST stanser før noe annet regnes UTEN kostnadsgrunnlag Forslag oppdiktet linje Steg 0 hoppes over Øvrige kontroller forslagets egne tall GODKJENT og kjøringen ser helt normal ut

Med kostnadsgrunnlaget på plass avvises to ting: en kostnadskode prosjektet ikke har, og en ekte kode der mengden eller prisen ligger mer enn fem prosent unna det virkelige tallet.

Uten det steget resonnerer hele kontrollen bare om tall forslaget selv oppga. Et forslag som er internt konsistent, men bygget på oppdiktede kostnadslinjer, passerer da hele veien.

Anbefaling: skaff tallene. Kan de ikke skaffes, skriv inn i bestillingen at kjøringen er uforankret — så ingen leser et godkjent-resultat som mer enn det er.

Eksempelet

Hvorfor veglys er et godt eksempel

Kontorbygg Forhåndsberegnet Målt i etterkant avviket kan ses — hvis noen ser etter Veglys uten måler Forhåndsberegnet ingen måling avviket er strukturelt usynlig

I et kontorbygg er avviket mellom modellert og realisert besparelse målbart, men sjelden målt. I norsk veglys er det strengere: mange anlegg mangler måling helt, eller avregnes på estimerte verdier. Uten måledata finnes det ingen etterprøving å sammenligne forhåndsberegningen med.

Realiseringsgraden er altså ikke ukjent fordi ingen har regnet på den — den er strukturelt usynlig. Det gjør domenet til et godt utgangspunkt for læringssløyfa: den eneste kilden til korreksjon er akkumulert ekspertvurdering, og det er nøyaktig det erfaringslaget bærer.

Eksempelet

Spørsmålene, besvart for veglysporteføljen

Anlegget: en fylkeskommunal veglysportefølje på 9 500 lyspunkter langs fylkesveg.

Kostnadslinjen: én eneste — porteføljens årlige energikostnad. Den er regnet som 9 500 punkter à 114 watt, i 4 050 brenntimer i året, altså 4 386 150 kilowattimer, til én krone per kilowattime.

Investeringskostnaden er bevisst utelatt, fordi ingen kilde i materialet gir en pris per lyspunkt. En utledet verdi hører ikke hjemme i et kostnadsgrunnlag.

Tiltaket som regnes på: LED-utskifting av de 2 500 eldste punktene, fra 114 til 70 watt. Det gir en modellert besparelse på 445 500 kroner i året.

Rammene: lystekniske minstekrav som ikke kan fravikes, og at nattslukking ikke kan forutsettes.

Eksempelet

De to tallsettene er skrevet fra samme regnestykke

Ett regnestykke 9 500 punkter · 114 W · 4 050 timer = 4 386 150 kWh à 1 krone Kostnadsgrunnlaget mengde og enhetspris Den regnede kandidaten samme linje · besparelse 445 500
Ikke avstemt i etterkant — skrevet ut fra ett og samme regnestykke.

Femprosent-toleransen er altså lukket ved konstruksjon. Det er den disiplinen som gjør at et avvik senere faktisk betyr noe — hadde tallene vært skrevet inn hver for seg, ville et lite avvik bare vært slurv, ikke et signal.

Ett valg er verdt å merke seg: besparelsen måles mot hele porteføljens energikostnad, ikke mot forbruket til de 2 500 punktene alene. Målt mot bare de berørte punktene ville det riktige forslaget blitt avvist som urealistisk stort.

Eksempelet

Erfaringen: godkjent, med korreksjon

Modellert 445 500 kr/år Forventet faktisk 360 855 kr/år avvik 81 % av modellert

Regnestykket er teknisk riktig ut fra parameterne, men brenntimene er et nasjonalt tabellanslag — ikke en målt kurve for dette anlegget. Og siden anlegget mangler måler, kan avviket aldri oppdages i drift.

Ærlig om grunnlaget: de 81 prosentene er lånt fra amerikansk programlitteratur, ikke fra norsk måling — og det står uttrykkelig i dommen. Det finnes ingen norsk etterprøving for veglys. I drift erstattes en slik startdom av ekte menneskelige vurderinger.

Eksterne systemer

Hvilke fagsystemer må gjøres tilgjengelige — og når?

Spørsmålet har to helt ulike svar, avhengig av når systemet skal spørres. Blandes de, bygges feil integrasjon.

FØR kjøringen henting av kildedokumenter Fagsystem Basen blir innhold med opphavsmerking kan leses og korrigeres før kjøring null nettverk under selve kjøringen UNDER kjøringen oppslag mens forslaget formes Agent Tjeneste blir verktøy agenten kan kalle krever uttrykkelig liste over tillatte kall alt som kan kontaktes navngis på forhånd to ulike integrasjoner — velg etter når svaret trengs

Trengs svaret bare én gang, og er det ferskt nok? Hent det på forhånd. Da blir det et dokument i basen, med opphav og dato, som fagpersonen kan lese og korrigere før kjøringen starter. Selve kjøringen gjør da ingen nettverkskall i det hele tatt.

Må agenten kunne slå opp underveis — for eksempel en pris eller en anleggsstatus den ikke kan vite på forhånd — da må systemet gjøres tilgjengelig som et verktøy under kjøringen. Det koster mer, og krever tre ting: en uttrykkelig liste over hvilke kall som er tillatt, at alt som kan kontaktes navngis før første kall, og at tørrkjøringen ikke åpner noe som helst.

Utgangspunktet er ingen integrasjon. Uten konfigurasjon gjøres null nettverkskall. Det er ikke en begrensning man jobber seg rundt — det er det som gjør at man kan si nøyaktig hva en kjøring har rørt.

Kjøreklar

Sjekken før man kjører

Det finnes ingen egen «valider basen»-knapp. Det nærmeste er en tørrkjøring: systemet går hele veien fram til det første kallet mot språkmodellen, og stopper der.

Base åpnes Alt kontrolleres navn, tak, tilgang stopp Første modellkall Resten skjer ikke — koster ingenting

Det beviser at basen åpner, at den regnede kandidaten finnes og bærer riktig prosjektnavn, at bestillingen er gyldig, at modellene er oppløst, at takene er satt, og at ingen ekstern tjeneste vil bli kontaktet.

Det beviser ikke at lenkene når alle dokumentene — en brutt lenke hoppes stille over — og heller ikke at innholdet er godt.

Tørrkjøringen er billig nok til å kjøres hver gang basen endres.

Sløyfa

Etter kjøringen blir basen én versjon klokere

Kjøring Artefakt forslag, tall, kontrollens dom Fagperson skriver dommen Innboks leses før neste hypotese Løftes inn i basen hvis godkjent for varig bruk

Neste kjøring leser innboksen før den former sin hypotese. Dommen påvirker altså det neste forslaget, ikke bare arkivet.

Rollefordelingen er ufravikelig: systemet leser innboksen, mennesket skriver den. En kjøring lagrer aldri sin egen vurdering tilbake som kunnskap. Uten den regelen ville systemet lært av seg selv.

Forventningen

Hva dette koster, og hva det ikke lover

Inventar Skjelett Første erfaringsfrø Iterasjon samlet: én til to uker