Morten Jansrud

Hva om ChatGPT ikke bare svarte kundene dine via en chatbot, men faktisk snakket med dem på telefonen? Hva om AI kunne tolke pauser, tonefall og avbrytelser, og svare som en rådgiver?

Vi står ved starten av en ny æra for kunstig intelligens. Den neste bølgen handler ikke bare om større modeller eller flere parametere, men om tempo og tilstedeværelse. Sanntids- eller 

-AI gjør det mulig å føre samtaler med maskiner som flyter like naturlig som dialogen mellom to mennesker, samtidig som den utfører oppgaver. 

Du er ikke alene hvis du er skeptisk etter å ha brukt stemmeassistenter som Siri eller Alexa. I mange år har de vært mer frustrerende enn hjelpsomme, og for mange har de blitt et bevis på at stemmestyring ikke fungerer. Men det som skjer nå, er noe helt annet. Den nyeste generasjonen AI-modeller representerer et teknologisk gjennombrudd som fundamentalt endrer hvordan vi utvikler og bruker kunstig intelligens.

Selv om jeg i tittelen hevder at vi kan «glemme chatbots», er det egentlig bare tull. Det gjøres enorme fremskritt på skriftlige språk-modeller, så poenget er ikke å avskrive skriftlige grensesnitt. De vil fortsatt være viktige. Det avgjørende er å gi brukerne friheten til å velge, noen foretrekker å skrive, andre å snakke. Sanntids-AI handler derfor ikke om å erstatte det ene med det andre, men å utvide opplevelsen. Ikke tvinge mennesker inn i et nytt format, men la AI møte dem der det føles mest naturlig, enten det er via tekst eller tale.

I denne artikkelen ser vi på hvordan de nye modellene fungerer, hvorfor det er så stort, og hvordan du selv kan bygge en fungerende implementasjon med OpenAI GPT-Realtime, WebRTC og Azure Functions.

For å skjønne hvorfor sanntids-AI føles så annerledes, må vi først se på hvordan språkmodeller tradisjonelt har fungert. ChatGPT følger et ganske forutsigbart mønster: du skriver inn en melding, modellen tenker, og så kommer svaret. Selv når teksten «strømmes» ut linje for linje, er mesteparten av svaret allerede planlagt før det første ordet vises.

Det er effektivt, men også litt mekanisk. Samtalen går én vei om gangen: du spør, modellen svarer. Du kan ikke hoppe inn midt i en setning, endre tema, eller snakke med stemmen din. Interaksjonen er i bunn og grunn tekst inn – tekst ut.

Sanntidsmodeller snur dette på hodet. I stedet for å vente på tur, deltar modellen i samtalen 

. Du kan snakke naturlig, avbryte, ombestemme deg, og AI-en henger med. Den justerer svarene sine fortløpende, akkurat som et menneske som tenker mens det snakker.

Den store forskjellen ligger i selve infrastrukturen. Der eldre modeller kommuniserer gjennom enkeltstående forespørsler som sendes og mottas over HTTP, bruker sanntidsmodeller en 

 som lar lyd, tekst og handlinger flyte begge veier samtidig.

Fra stemmeassistenter til samtalepartnere

Denne utviklingen handler ikke bare om smartere stemmestyring, den handler om å gjøre avansert AI tilgjengelig for alle. Tidligere krevde sanntids-AI spesialiserte datasystemer og dyp ekspertise. I dag kan hvem som helst komme i gang med noen få API-kall, takket være plattformer fra aktører som OpenAI, Microsoft og Google.

For utviklere betyr dette at man nå kan bygge løsninger som svarer umiddelbart, forstår kontekst, og til og med handler på eget initiativ. Resultatet er applikasjoner som oppleves langt mer naturlige og menneskelige, enten det er i kundeservice, undervisning, kreativitet eller intern produktivitet.

Men det vil ta tid før alt er på plass. Teknologien er fortsatt ny, og både verktøy og arbeidsmetoder må modnes. Likevel er én ting sikkert: selskaper som klarer å omstille seg tidlig og ta teknologien i bruk på en gjennomtenkt måte, vil få et enormt forsprang. De vil ikke bare spare tid og penger – de vil bygge opplevelser konkurrentene vil bruke år på å ta igjen.

Sanntids-AI handler ikke først og fremst om fart. Det handler om 

 om hvor naturlig, sømløs og responsiv teknologien oppleves.

Tenk deg at du ringer kundeservice og får en AI-assistent som faktisk kan hjelpe deg, her og nå. Ingen ventemusikk. Ingen videresending. Du sier:

«Pakken min kom ødelagt. Jeg trenger en ny sendt til en annen adresse, og frakten må krediteres.» AI-en forstår intensjonen, finner ordren, bestiller erstatningen og sender bekreftelsen, alt mens du fortsatt snakker. Ingen venting. Ingen overføring. Bare en naturlig samtale som fikser det du trenger.

Tenk deg et møte der AI-en ikke bare tar notater, men 

«Hvor mye brukte vi på markedsføring i Q4?»
AI-en henter tallene fra regnearket, viser trenden på skjermen og oppsummerer for deltakerne, i sanntid, uten at noen trenger å lete. Etterpå sender den en kort oppsummering med beslutninger og oppfølgingspunkter.

Trening og læring som føles personlig: 

I stedet for å følge ferdige leksjoner, snakker du med en AI som 

. Den hører på uttalen din, justerer vanskelighetsgraden og bygger videre på samtalen fra i går.

«Jeg vil øve på italiensk på kafé i Roma.»
«Greit – la oss bestille kaffe sammen. Vil du ha cappuccino eller espresso?»
Læringen skjer i øyeblikket, med ekte samtale og kontinuerlig tilpasning.

Du beskriver en idé, og AI-en visualiserer den mens du snakker.

«Prøv en varmere stemning, med lavere lys og mykere kontraster.»
AI-en oppdaterer designet, foreslår variasjoner og fortsetter dialogen.
Det føles ikke som å bruke et verktøy – det føles som å samarbeide med en kollega som forstår deg.

Hos Snøkam har vi utviklet flere slike sanntidsløsninger. I det neste avsnittet tar vi deg med inn i den tekniske implementasjonen av én konkret opplevelse: en stemmeassistent som hjelper ansatte med å opprette arrangementer like raskt som de kan beskrive behovet.

Alt dette kan høres magisk ut, en AI som forstår deg mens du snakker, utfører oppgaver underveis, og holder samtalen flytende uten forsinkelser. Men bak opplevelsen ligger en arkitektur som er overraskende tilgjengelig, så lenge man setter de riktige byggesteinene sammen.

Det handler ikke om eksperimentell forskning eller proprietær magi, men om å kombinere tilgjengelige verktøy som WebRTC, OpenAI GPT-Realtime og et enkelt endepunkt.

For å illustrere hvordan komponentene spiller sammen i praksis, viser diagrammet nedenfor hele flyten, fra brukerens nettleser til OpenAI-modellen som driver samtalen.


Brukeren åpner en webapp som gir tilgang til mikrofonen og starter samtalen. Herfra sendes en forespørsel til backend for å hente en sikker, midlertidig tilgangsnøkkel.


Backend håndterer sikkerheten. Den bruker en lagret API-nøkkel for å opprette en ny sesjon hos OpenAI, og mottar en 


Denne midlertidige nøkkelen er gyldig i kun 60 sekunder og sikrer at frontend kan koble seg direkte til OpenAI – uten å eksponere API-nøkkelen.


Med nøkkelen i hånd oppretter frontend en WebRTC-tilkobling til OpenAI GPT-Realtime. Over denne forbindelsen strømmer: 

 i begge retninger (du snakker, AI svarer)

 via en separat kanal (AI kan utføre handlinger, sende meldinger osv.)

Selv om kommunikasjonen mellom bruker og AI i stor grad går direkte, er det backend som gir oss kontrollen vi trenger. Den oppretter sikre sesjoner, konfigurerer hvordan assistenten skal oppføre seg, og sørger for at API-nøkler aldri eksponeres. På denne måten kan vi gi frontend den friheten som sanntid krever, uten å gå på kompromiss med sikkerheten.

Backend genererer såkalte ephemeral tokens, midlertidige tilgangsnøkler som bare varer i et minutt, og som brukes til å etablere en direkte forbindelse mellom nettleseren og GPT-Realtime. På den måten kan vi la frontend kommunisere direkte med AI-en, men fortsatt holde all autentisering og sesjonsstyring på serversiden.

I tillegg har vi valgt en struktur der selve "personligheten" til assistenten, altså instruksjonene den følger, og hvilke verktøy den har tilgang til defineres i backend som en enkel JSON-konfigurasjon. Alt som trengs er å opprette en ny agent-definisjon og la frontend be om riktig agent når samtalen starter.

Her er hvordan vi implementerer dette i en Azure Function:

Funksjonen tar imot en forespørsel med et agent-navn (vi kommer tilbake til hva det betyr), henter den sikre API-nøkkelen fra miljøvariabler, og oppretter en sesjon hos OpenAI. Responsen inneholder den ephemeral tokenen som returneres til frontend. Legg merke til at API-nøkkelen aldri forlater serveren. Den brukes kun til å autentisere forespørselen til OpenAI.

En annen viktig del av arkitekturen er hvordan vi håndterer variasjon. I praksis ønsker vi ikke én universell AI-assistent, men flere, hver med sitt formål, sin personlighet og sine verktøy. F.eks én som hjelper med å booke møterom. Én som oppretter arrangementer.

I stedet for å skrive ny kode hver gang vi skal lage en ny assistent, har vi valgt en agent-basert tilnærming. Hver agent defineres som en enkel JSON-konfigurasjon i backend. Der beskriver vi hvordan AI-en skal opptre, hvilke verktøy den har tilgang til, og hvilke instruksjoner den følger.

Når frontend starter en samtale, sendes et agentnavn med i forespørselen. For eksempel "create-event". Backend slår da opp riktig definisjon, og bruker den til å opprette sesjonen hos OpenAI. På den måten kan vi endre hvordan AI-en oppfører seg, hva den sier, og hva den kan gjøre, uten å gjøre endringer i frontend-koden.

Et eksempel: agenten «create-event» er satt opp til å hjelpe ansatte med å fylle ut skjemae. Den har tilgang til to funksjoner: én for å oppdatere skjemafelter, og én for å sende inn skjemaet. Når AI-en bestemmer seg for å bruke et av disse verktøyene, sendes det som en JSON-melding over WebRTC-forbindelsen til frontend, som tolker det og utfører handlingen.

Denne strukturen gjør det enkelt å legge til nye assistenter etter behov – uten å endre resten av systemet. Vi kan tilpasse både oppførsel, stemme og funksjonalitet ved å justere én konfigurasjonsfil. Det betyr at vi raskt kan eksperimentere, utvikle og utvide, uten tung implementasjon i bunn.

Frontend-applikasjonen er bygget i React, og vi har samlet kompleksiteten i en gjenbrukbar hook som håndterer alt som trengs for å snakke med GPT-Realtime: tilgang til mikrofon, oppsett av WebRTC-forbindelse, sending av lyd, mottak av svar og oppfølging av eventuelle handlinger. Alt dette skjer i løpet av sekunder, og for brukeren fremstår det hele som én enkel opplevelse, trykk på en knapp, og samtalen er i gang.

Det som skjer under panseret, er at vi først henter en ephemeral token fra backend. Med denne nøkkelen etablerer vi en WebRTC-tilkobling til OpenAI, som gjør det mulig å strømme lyd i begge retninger og sende meldinger over en separat data channel. På denne kanalen mottar frontend signaler fra AI-en. For eksempel når den ønsker å oppdatere et skjemafelt, sende inn et skjema, eller gi visuell tilbakemelding i UI-et.

For å gjøre det så enkelt som mulig å integrere denne funksjonaliteten i ulike deler av appen, er samtaleopplevelsen kapslet inn i én komponent. Den kan settes inn hvor som helst, med ulike agenter og ulike funksjonskall, uten å måtte skrive logikken på nytt. Det betyr at vi kan ha én AI-assistent i et skjema, en annen i et dashbord, og en tredje i en chatboble, der alle er bygget på samme arkitektur, men med ulik personlighet og rolle.

For å vise en litt morsom demo av hvordan teknologien kan brukes, har vi laget noe mer ambisiøst enn en chatbot: et interaktivt 

 der hver karakter er en egen AI-agent med sin egen personlighet, sitt eget alibi, og sine egne observasjoner fra kvelden.

Scenariet er enkelt: Det har skjedd et drap på Snøkam-kontoret. Du må snakke med de ansatte (AI-agenter), stille spørsmål, følge opp svar, og til slutt peke ut morderen. Det som gjør det interessant er at hver samtale er unik. AI-en improviserer detaljer, reagerer på hvordan du stiller spørsmål, og kan til og med bli defensiv hvis du presser for hardt.

Teknisk sett bruker vi samme arkitektur som beskrevet over. Hver karakter er definert som en egen agent med instruksjoner som beskriver deres personlighet og hva de vet. For eksempel har én agent instruksjoner om at hen var i møterommet klokken 21:30 og hørte rare lyder fra kjøkkenet. En annen var hjemme hele kvelden. En tredje vet noe, men vil ikke si det med en gang. AI-en holder seg konsistent til disse instruksjonene mens den improviserer dialogen.

Det interessante er ikke bare at spillet fungerer, men 

 det føles. Fordi kommunikasjonen skjer i sanntid med naturlig stemme, blir interaksjonen langt mer engasjerende enn et tekstbasert avhørsspill ville vært. Du kan avbryte hvis du får en idé, du kan utforske tankeganger spontant, og du kan registrere nyanser i hvordan karakterene svarer. Det er nærmere en samtale med et menneske enn med en maskin.

. Hvis du løser mysteriet før 31. oktober, kan du vinne 5 000 kroner. Men det egentlige premiet er å oppleve hvor langt sanntids-AI har kommet, og kanskje få noen ideer til hva du selv kan bygge med teknologien.

Sanntids-AI representerer et paradigmeskifte i hvordan vi samhandler med kunstig intelligens. Vi går fra å 

 med den i sanntid, naturlig og intuitivt.

Hvis du skal ta med deg noe fra denne artikkelen, er det at sanntids-AI representerer noe fundamentalt annet enn bare "raskere chat". 

Sanntids-AI er fortsatt i en tidlig fase, og vi ser allerede konturene av neste generasjon. Multimodale modeller som kan se, høre og forstå kontekst samtidig er på vei. Responstiden vil fortsette å synke under 100 millisekunder. Støtten for flere språk og dialekter blir stadig bedre. Integrasjon med AR og VR vil åpne for helt nye typer opplevelser der AI blir en naturlig del av omgivelsene rundt oss.

Den kanskje mest interessante utviklingen er bedre personalisering over tid. I dag starter hver samtale på nytt. Fremtidige systemer vil kunne bygge opp en forståelse av deg og dine preferanser, samtidig som de opprettholder den umiddelbarheten som gjør sanntids-AI så kraftfull.

Hos Snøkam fortsetter vi å eksperimentere med AI, både internt og ute hos kundene våre. Vi har noen ideer til bruksområder vi ikke har sett andre gjøre ennå. Hvis du jobber med noe lignende, eller bare er nysgjerrig på hvordan vi har løst enkelte utfordringer teknisk, ta gjerne kontakt. Vi deler gjerne erfaringer.


Som AI Tech Lead i Storebrand bygger Morten AI-drevne kundeopplevelser som gjør en reell forskjell når de trenger det, på den måten de foretrekker. 

 hvis du vil diskutere et konkret prosjekt.

Hva om ChatGPT ikke bare svarte kundene dine via en chatbot, men faktisk snakket med dem på telefon? Hva om AI kunne tolke pauser, tonefall og avbrytelser, og svare som en rådgiver?

React er et verktøy vi bruker for å bygge moderne nettsider som føles raske og levende. Det hjelper oss å sette sammen små deler av et design til hele løsninger – litt som byggeklosser.
Vi bruker React fordi det gjør det enklere å lage brukervennlige og fleksible nettsider som er lette å videreutvikle når behovene endrer seg.

Frontend

React

.NET er en utviklingsplattform laget av Microsoft som brukes til å bygge alt fra små apper til store, komplekse systemer. Den gir et solid grunnlag for å lage stabile og sikre løsninger som fungerer godt sammen med andre teknologier.
Vi bruker .NET fordi det er raskt, pålitelig og godt egnet for prosjekter som krever høy ytelse og lang levetid.

Backend

.NET

(Large Language Model) er en type kunstig intelligens som kan forstå, generere og jobbe med tekst på en måte som ligner på hvordan mennesker skriver og snakker. Den brukes til alt fra chatboter og automatiserte tekstanalyser til å hjelpe utviklere med å skrive kode.
Hos Snøkam bruker vi LLM-er for å utforske hvordan AI kan gjøre arbeidet vårt smartere og mer effektivt – enten det handler om å automatisere oppgaver, hente ut innsikt fra store mengder informasjon eller bygge helt nye løsninger drevet av språkforståelse.
Store språkmodeller er i rask utvikling og gir oss muligheten til å kombinere teknisk presisjon med kreativitet – slik at vi kan levere mer intuitive og fremtidsrettede digitale tjenester.

Kunstig Intelligens

Glem chatbots – den nyeste AI-modellen fra OpenAI kan snakke med kundene dine

Krystallklart ❄️

Morten Kartevoll

Bak de fleste effektive systemer ligger det et lag av automatisering, og det gjelder også våre interne løsninger i Snøkam. Ett av disse systemene er en løsning for å automatisere innhenting og visualisering av OKR-metrikker.

Men hva er egentlig OKR og hvorfor bruker vi det? OKR (Objectives and Key Results) er et rammeverk for mål- og resultatstyring som hjelper organisasjoner med å sette ambisiøse mål og måle fremdrift gjennom tydelige nøkkelresultater. Metoden skaper fokus, transparens og smidighet, men for å lykkes kreves oppdatert og pålitelig data. Nøkkelordet her er 

da vi raskt så at det tok unødvendig lang tid å oppdatere alle Key Resultene våre manuelt.

For en integrasjonsutvikler kan dette fremstå som en drøm om sømløs datainflytelse, eller et mareritt fylt med fragmenterte API-er, kompleks autentisering og unødvendig webscraping, og ikke minst elendig dokumentasjon. I denne artikkelen ser vi på hvordan automatisering av datainnhenting kan forenkle arbeidet med OKR-er. Men lønner det seg alltid å automatisere slike prosesser? 

Resultatet av vår automatisering kan du se her: 

Dette vil såklart variere utrolig mye etter hvilke system selskapet du jobber i bruker, men vi har ihvertfall over tid koblet oss mot et bredt spekter av systemer:

 - Hvor alle oppgaver gjør har er lagret

Valget av integrasjon styres i stor grad av hvilke Key Results vi måler. Når vi kan gjenbruke eksisterende dataflyt utnytter vi det! For eksempel gjennom NuGet-pakker vi allerede har utviklet, som Sanity-pakken vår. Dette gir oss betydelige tidsbesparelser og reduserer samtidig risikoen for teknisk gjeld. Over tid forventer vi også at antall systemer vi henter data fra vil stabilisere seg, med andre ord vil forhåpentligvis mengde jobb med tanke på selve integrasjonen mot nye systemer konvergere mot et stabilt tall.

En av de viktigste erfaringene våre er hvor varierende API-kvalitet kan være.

: PowerOffice, Salesforce og Jira – veldokumenterte, konsistente, og fleksible API-er som gjør integrasjon og feilhåndtering relativt rett frem.

: Medium og LinkedIn – komplekse tilgangskontroller, fragmentert dokumentasjon og hyppige endringer.

Det var faktisk API-frustrasjonen med Medium som gjorde at vi valgte å bygge vår egen bloggløsning. Da fikk vi også full kontroll på dataflyt, autentisering og struktur. Når du har utviklere som møter opp på mandag og sier «jeg bygde en bloggløsning i helga», blir det lett å kaste dårlige API-er langt, langt bort.

For enklere behov gikk vi like gjerne for 

 en pragmatisk løsning når API-ene bremser mer enn de hjelper.

Fra API-rant til litt mer konkret om OKR oppsettet vårt. Hvilke deler av vårt internsystem innebærer løsningen? I de forrige episodene har vi sett mer på veldig sentrale deler av systemet, mens dette er en mer konkret implementasjon. Under ser du hvilke deler av systemet som blir involvert, pluss det kommer en mer konkret tegning litt senere.

For hver Key Result beregnes status kontinuerlig opp mot mål definert i januar.

Hver oppdatering lagres som et historisk datapunkt, slik at vi kan visualisere progresjon gjennom året.

Persistens skjer i Sanity, via en custom NuGet-klient som gjenbrukes på tvers av prosjekter.

Under er databaseskjemaet vårt representert, hvor en kan se Objectiven som har flere Key Results som inneholder flere data points.

Forklaring/dypere beskrivelse av selve Objectiven

Forklaring/dypere beskrivelse av Key Resulten

 om eksisterende pakker ikke finnes som støtter hva vi gjør

 på toppen av Sanity, slik at hele organisasjonen får innsikt i sanntid (så ofte vi setter frekvensen på CRON jobben). Dette er også tilgjengelig på vår nettside!

Eliminering av manuelt arbeid! Systemet gjør jobben mens vi fokuserer på verdiskaping. Innhenting av data + kalkulering kan ta lengre tid enn en tror.

Gjenbrukbare integrasjoner via NuGet-pakker (kan brukes andre plasser også)

Skalerbart: flere datapunkter kan hentes uten ekstra manuelt overhead.

Som alle andre automatiseringer er det ingenting som er digger enn å slippe å gjøre manuell jobb, men heller bare se automatikken gjøre sin magi

Det er dessverre ikke alt som lar seg automatisere, eller som det ikke er verdt det, spesielt når vi ikke helt vet hvordan vi skal løse en KR. 

Høy initial investeringskostnad, spesielt i oppstartsåret.

Nye OKR-er hvert år innebærer omskriving og tilpasning av integrasjoner.

Ikke alt kan eller bør automatiseres. Nøkkelfaktorene er:

: Har vi pålitelige kilder, eller må vi gjette?

: Måler vi ukentlig, eller kun 2–3 ganger i året?

: Er metrikken klart definert (f.eks. «inntekter per måned») eller vag?

Der faktorer er uklare, er det bedre å vente. Automatisering gir bare verdi hvis datakvalitet og kontekst er på plass. Konkrete eksempler fra våre egne KR-er er:

Trivsel skal måles 3 ganger i året og vi skal følge opp (og jobbe for forbedring) 100 % av innspillene/ulempene som kommer inn

Denne kunne i teorien ganske enkelt blitt målt, men når det bare er snakk om 2-5 målinger er det ikke verdt å automatisere. Når det er sagt er nok en slik trivselsundersøkelse noe vi kommer til å fortsette med i årene fremover så det kunne potensielt gått inn som en annen automatikk. But I digress!

Minst 1000 unike brukere i et nytt Snøkam AI-produkt

Dette er også et eksempel på at vi ikke vet hvor dataen skal komme fra. Hadde vi lansert et spill for eksempel kunne vi hentet dette fra plassen vi lanserte det til, men siden det er litt uvisst, ble denne avventet. Mest sannsynlig kan det hentes fra Google Analytics om vi lanserer det direkte på nettsiden vår, og da er det bra at vi allerede har en kobling mot det API-et slik at vi eventuelt kan få raskt opp dataen om vi skulle ønske det.

For selskaper kan gevinsten i starten være relativt liten sammenlignet med manuelt arbeid (15-30 minutter i uka). Men om OKR-ene blir mer komplekse, frekvensen trenger å være hyppigere, eller det rett og slett tar for lang tid å hente + kalkulere resultatene. øker gevinsten av automatiseringen utrolig mye.

Et datagrunnlag som enkelt kan eksponeres eksternt og internt.

Mulighet til å bruke integrasjoner i andre sammenhenger.


Har du ikke automatisert OKR-ene dine ennå, er det på tide å sette i gang. Det er både lærerikt og gøy. Du får jobbe med mange forskjellige API-er, du oppdager hvor variert "best practice" faktisk er i integrasjonsverdenen, og du bygger en plattform som skalerer med selskapet.

Automatisering handler ikke bare om å spare tid, men om å bygge en datadrevet kultur der innsikt er tilgjengelig, presis og kontinuerlig oppdatert. Det er det som gjør at små beslutninger kan tas raskt, og store beslutninger kan tas på riktig grunnlag.

Bak de fleste effektive systemer ligger det et lag av automatisering, og det gjelder også våre interne løsninger i Snøkam. Ett av disse systemene er en løsning for å automatisere innhenting og visualisering av OKR-metrikker.  For en integrasjonsutvikler kan dette fremstå som en drøm om sømløs datainflytelse, eller et mareritt fylt med fragmenterte API-er, kompleks autentisering og unødvendig webscraping, og ikke minst elendig dokumentasjon. Men lønner det seg alltid å automatisere slike prosesser?

Hjertet av internsystemet, Min side, er proppet fullt med masse forskjellige funksjonaliteter som arrangementer, webshop, lønn, aksjer, goder, økonomi, forsikringsdokumenter, info om ansatte osv, osv. Det vil si, funksjonalitetene eksisterer i sine representative microservice-apper, men Min side knytter disse sammen til et felles sted. Dette er en relativt vanlig arkitektur for større systemer da det tillater appene å kjøre for seg selv også utenfor koblingen til Min side. På denne måten kan vi utnytte det beste av to verdener - samle all funksjonalitet til Snøkam-ansatte på ett sted, samtidig som vi kan eksponere de appene vi ønsker også til personer utenfor Snøkam. Fra venstremenyen i skjermbildet så kan vi se at Min side router til veldig mange ressurser - både interne, men også eksterne. Vi skal titte innom noen av de i denne bloggposten, men mange av de er såpass innholdsrike og spennende at vi skal dedikere helt egne poster til dem.


Episode 2: Min side

C# er et programmeringsspråk utviklet av Microsoft, og brukes til å bygge alt fra små applikasjoner til store og komplekse systemer. Det kombinerer kraften fra tradisjonelle språk med moderne funksjoner som gjør koden ryddig, trygg og enkel å vedlikeholde.
Hos Snøkam bruker vi C# sammen med .NET-plattformen for å lage stabile og sikre løsninger som tåler vekst og endringer over tid. Språket gir oss høy ytelse, god struktur og mange verktøy som gjør utviklingen både effektiv og pålitelig.
Vi velger C# når vi ønsker å bygge robuste løsninger for bedrifter som trenger kvalitet, sikkerhet og langsiktig verdi i sine digitale systemer.

Azure er Microsoft sin skyplattform, som lar oss bygge, lagre og drifte digitale løsninger uten behov for egne servere. Plattformen gir tilgang til et stort økosystem av tjenester – alt fra databaser, maskinlæring og sikkerhet til automatisering og analyse.
Hos Snøkam bruker vi Azure for å bygge fleksible, trygge og skalerbare løsninger som kan vokse i takt med kundens behov. Skyplattformen gjør det enkelt å kombinere ulike teknologier, automatisere oppgaver og levere stabile systemer med høy ytelse.
Fordi Azure er tett integrert med verktøy mange allerede bruker fra Microsoft, som .NET og Office 365, kan vi utvikle helhetlige løsninger som fungerer sømløst på tvers av både utvikling, drift og brukeropplevelse.

Cloud

Azure

Episode 3: OKR automatisering

Elisabeth Karud

Når man tenker på miljø og teknologi, så er det ofte mulighetene teknologi kan bidra med for å redde miljøet som er i fokus. Men teknologi er faktisk også et 

i miljøsammenheng. Teknologi står for mer utslipp enn hele flyindustrien gjør i dag – og mer utslipp enn enkeltland som Storbritannia. Det er estimert at utslippet fra teknologi kommer til å øke fra rundt 4% av det totalet utslippet i dag til 14% innen 2040!

Innenfor teknologi og miljø er det ofte to begreper som brukes, «Greening by IT» og «Greening of IT». Førstnevnte går på hvordan man kan bruke teknologi til å bidra til bedre løsninger i andre industrier for å minke deres utslipp. Sistnevnte ser på hvordan IT innad kan bli mer energieffektiv. Det er dette denne artikkelen skal fokusere på, og spesielt se på hvordan vi som utviklere kan ta konkrete valg i hverdagen for å bidra til mer miljøvennlig teknologi.

Det har blitt undersøkt hvor energieffektive programmeringsspråk er mot hverandre, og ikke overraskende så er generelt kompilerte språk både mye raskere og energieffektive enn tolket (interpreted) språk – i snitt mer enn dobbelt så effektive. Eksempelvis er C, Rust og C++ helt i toppen med Java hakk i hel, mens Python og Perl ligger i bunn av listen. Kompilerte språk er generelt raskere fordi de konverteres direkte til maskinspråk. I tillegg har flere av de andre språkene funksjonalitet som gjør de tregere under kjøring som C mangler. Eksempler er dynamisk typing, deteksjon av minnelekkasjer og garbarge collection. Det er også verdt å nevne at Python er et såkalt interface språk mot kompilerte språk som C, altså at mange Python pakker er skrevet i kompilerte språk. Som vil si at i praksis vil bruk av disse pakkene totalt bidra til at Python er noe mer effektiv enn det som fremstilles av tabellen.

Se bildet under for fullstendig liste over programmeringsspråkene som ble testet, og hvordan de skårer relativt hverandre. Både energibruk, tid og minne ble analysert, og hvert språk er annotert med c (compiled language), v (virtual language) eller i (interpreted language).

Bildet er hentet fra artikkelen "Energy Efficiency across Programming Languages" av Pereira og co som kan finnes her: 

https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf

Liten disclaimer: Artikkelen er fra 2017, og endringer kan ha skjedd siden dette. Eksempelvis har det kommet mange oppdateringer med Python som har utviklet effektiviteten, med en forbedring på rundt 15% fra Python 3.6 til 3.12. Men det er likevel en stor forskjell opp til C og de kompilerte språkene. Generelt er det er naturlig å anta at kompilerte språk fremdeles er mer effektive enn virtuelle og interpreted språk - selv om rekkefølgen innad i grupperingene kan varierere noe fra 2017 til i dag.

Personlig har jeg jobbet mest med Java de siste fem årene, så jeg har dermed gått litt i dybden på hvordan man kan skrive god og energieffektiv Java-kode. Dette har naturlig nok ført meg til å utforske ulike "best practices" innen Java, som har blitt utviklet nettopp for å øke effeketiviteten i tillegg til å sikre god og standardisert kode. Så hvor mye mer energieffektivt er disse praksisene sammenlignet med alternativer? Dette har faktisk blitt undersøkt i artikkelen "How Green Are Java Best Coding Practices?» av Rocheteau og co. Her skal jeg komme med noen eksempler fra artikkelen.

En etablert praksis er å bruke int som loop counter. Siden float er desimaltall kan looping med float føre til avrundingsfeil og uforutsigbare kjøringer. IDE-er som IntelliJ foreslår automatisk looping med int når man starter å skrive "for". Og heldigvis viser det seg at å bruke int gir en relativ energigevinst på 16.32% sammenlignet med float.

Betingelser inni en loop bør sorteres etter hvor vanlig betingelsene er, med mest vanlige betingelse først. Ifølge artikkelen gir dette en energigevinst på 3%. 

Artikkelen tar ikke for seg alternative praksiser som for eksempel "Guard Clauses" der målet er å gi exceptions og corner cases tidlig utganger i looper. Dette kan gi mindre nøstet logikk og dermed gjøre koden med lesbar og enklere å vedlikeholde. I og med at energigevinsten er såpass liten ved å bruke vanligste betingelse først er det viktig å vurdere om lesbarhet og vedlikeholdbarhet veier tyngre enn energigevinsten.

Literal initialization sammenlignet med intialisering av objekter kan gi en ganske høy energigevinst. For de fleste typer som strings, integer og boolean gir dette en gevinst på rundt 90%! Mens for double og float er det minimalt med gevinst, og det argumenteres i artikkelen at det kan være på grunn av JVM optimalisering i bakgrunnen.

Bruk av primitive sammenlignet med wrappers

Bruk av int og float sammenlignet med deres wrappers gir en energigevinst på 69%. Men her er det være verdt å nevne at Java autoboxer primitive til wrappers i collections, som tar mer energi enn å bruke wrappers i collections i utgangspunktet.

Det er andre miljøvennlige valg man kan gjøre som utvikler som ikke er Java spesifikt. Eksempler er lazy loading, caching og effektivisering av datastrukturer.

 går ut på å laste data når det trengs – i motsetning til eager loading som laster hele ressursen på en gang. Lazy loading kan bidra til bedre ytelse og dermed lavere energibruk i systemet som helhet.

av data som brukes ofte eller som er uendret over lang tid kan både gjøre opplevelsen bedre for brukeren av systemet, i tillegg til å redusere energibruken.

tar mye ressurser og dermed energibruk. Lagrer applikasjonen din unødvendig data, eller på unødvendig presist format? Data som ikke gir mening med mer enn to desimaler trenger ikke 16 desimaler – selv om det kan være fristende å lagre «mer enn nok». 

For å konkludere er det altså noe vi kan gjøre som utviklere for å ta miljøbevisste valg. Valg av energieffektive programmeringsspråk, effektiv minnehåndtering og ressursbruk er med å redusere den totale energikostnaden. I tillegg viser det seg at "best practices" i Java er mer energieffektive enn alternative implementasjoner. Dette gir Java-utviklere enda et konkret insentiv til å følge beste praksiser – et valg som forbedrer både koden og kloden.

https://www.redhat.com/en/resources/greener-java-applications-detail

https://greensoftware.foundation/articles/10-recommendations-for-green-software-development

https://www.suso.academy/en/2023/03/13/green-coding-the-5-most-important-basics-for-sustainable-software-development-with-code-examples/

https://www.green-coding.io/case-studies/energy-efficiency-python/

Energy Efficiency across Programming Languages" av Pereira og co: 

"How Green Are Java Best Coding Practices?" av Rocheteau og co: 

https://www.scitepress.org/papers/2014/48083/48083.pdf

Når man tenker på miljø og teknologi, så er det ofte mulighetene teknologi kan bidra med for å redde miljøet som er i fokus. Men teknologi er faktisk også et *problem* i miljøsammenheng. Teknologi står for mer utslipp enn hele flytindustrien gjør i dag – og mer utslipp enn enkeltland som Storbritannia. Det er også estimert at utslippet fra teknologi kommer til å øke fra rundt 3% i dag til 14% innen 2040!

Java er et av verdens mest brukte programmeringsspråk, kjent for å være stabilt, sikkert og allsidig. Det brukes til alt fra store bedriftsløsninger til mobilapper og nettsystemer.
Hos Snøkam bruker vi Java når vi bygger systemer som skal være robuste, skalerbare og enkle å vedlikeholde over tid. Språket har eksistert lenge, og det store økosystemet av verktøy og rammeverk gjør det mulig å utvikle alt fra komplekse API-er til avanserte integrasjoner på en effektiv måte.
Vi velger Java i prosjekter der kvalitet, ytelse og lang levetid er viktig — og hvor vi ønsker en løsning som enkelt kan vokse med kundens behov.

Java

Hva betyr grønn teknologi, og hva kan vi som utviklere bidra med?

Arvid Mildner

Kanskje du har hørt om DeepSeek V3 og tenkt: 

, men så kommer den umiddelbare bekymringen – 

jeg kan jo ikke bruke det til noe sensitivt eller firmainformasjon, det kjører sikkert på en eller annen kinesisk server et sted!

 Men hva om jeg fortalte deg at det ikke trenger å være sånn?

Du kan faktisk få en opplevelse som ligner på ChatGPT eller DeepSeek, men fullstendig selvhostet – enten på din egen virtuelle maskin eller rett på egen maskin. Her er et skjermbilde av hvordan det ser ut når alt er satt opp.


Hvis du kun vil kjøre dette lokalt, trenger du ikke noe av dette. Da trenger du kun Docker installert på maskinen, som beskrevet senere i artikkelen. Hvis du vil kjøre tjenesten slik at andre folk kan bruke den, gjør vi noen antakelser først.

Du har en (virtuell) Linux-maskin med en offentlig IP-adresse

Du har tilgang til internett fra denne maskinen

Maskinen er tilgjengelig på port 80 og 443

Du kan SSH'e inn på maskinen under konfigurasjonen

Det sier seg selv at jo kraftigere maskin du har tilgang til (eller kan installere on-prem), jo bedre og kraftigere modeller kan du kjøre. I vårt eksempel bruker vi en Azure VM 

 maskin uten GPU-støtte (fordi du må be pent til Azure Support for å få GPU, og vi trenger egentlig ikke det for denne demoen).

Merk også at selv om vi bruker en maskin som koster 300 dollar i måneden, er dette rimelig tregt (2 minutter for denne spørringen). Da skjønner man også at det ikke er bare-bare å kjøre disse svære modellene.

La oss installere de teknologier vi trenger

, som er en åpen kildekode "runner" for LLM-er og veldig enkel å bruke, og 

, som er et chat-grensesnitt – en åpen kildekode frontend for å snakke med LLM-er. Fra dokumentasjonen til OpenWebUI ser vi at det faktisk finnes et Docker-image som kapsler inn både Ollama og OpenWebUI, noe som gjør installasjonen trivielt enkel. Før vi kan gjøre det, må vi installere Docker først:
Slik gjør du det på Ubuntu 24.04 LTS (som vi bruker i dette inlegget), men flere installasjonsinstruksjoner finner du 


Nå kan vi kjøre Ollama+OpenWebUI Docker-imaget slik:


Hvis du ikke er kjent med Docker, kan du tenke på denne kommandoen som å starte et lettvekts, isolert virtuelt miljø (kalt en container) på maskinen din. Inni denne containeren kjører Ollama og OpenWebUI som om de var installert direkte på systemet ditt—men de er pent pakket inn og atskilt fra ditt hovedmiljø. Containeren lytter på port 8080, noe som er viktig senere når vi skal konfigurere Nginx til å peke til denne containeren. Hvis du kjører Docker lokalt på maskinen din, bør du nå kunne besøke 

 og logge deg inn. Hvis du gjør dette på en VM, feks på Azure, må vi nå gjøre den sikkert tilgjengelig over internett.

. Du må selvfølgelig bytte dette ut med et domene som du selv kontrollerer. Merk også at vi ikke har serveren oppe nå, da VM-en vi bruker i praksis er altfor svak til å faktisk kjøre noen brukbare modeller og kun ble brukt som en demo.

 for å håndtere TLS-sertifikater (slik at vi får den fine "grønne låsen" på nettstedet vårt)

 som og konfigurerer noen grunnleggende innstillinger for å peke til OpenWebUI.

Nginx-konfigurasjonen er ikke 100 % ferdig ennå og fungerer mer som en plassholder, men den vil bli fullført etter at vi har installert sertifikatene og konfigurert serveren til å håndtere TLS med certbot sitt nginx-plugin.
Nginx må konfigureres til å videresende innkommende trafikk til OpenWebUI-tjenesten som kjører i bakgrunnen.

For å sikre sikker kommunikasjon må vi også konfigurere Nginx til å lytte på portene 80 (HTTP) og 443 (HTTPS). I tillegg må vi generere TLS-sertifikater for å verifisere eierskapet til domenet 

 og etablere tillit med klienter som besøker siden. Hele denne prosessen håndteres med Certbot i kombinasjon med 

Certbot forenkler prosessen med å få og fornye TLS-sertifikater. For å begynne må vi generere en sertifikatforespørsel, hvor vi spesifiserer at vi vil bevise domenets eierskap via DNS. Siden vi kontrollerer DNS-serveren og kan redigere oppføringene for 

, kan vi legge til de nødvendige TXT-records for verifisering. Dette gjøres som regel ved at du logger deg inn der du har kjøpt domenet, og finner frem til et sted hvor du kan legge til DNS-poster.

Kjør følgende kommando for å starte sertifikatforespørselen:


Etter det, vil du få en prompt som forteller deg hva du skal gjøre.


Certbot vil be deg om å legge til en spesifikk TXT-record i DNS-konfigurasjonen din under subdomenet 

. Denne posten fungerer som bevis på at du kontrollerer domenet. Når TXT-recorden er lagt til og har blitt propagert, vil Certbot automatisk verifisere den og utstede sertifikatet fra Let's Encrypt.

Etter å ha mottatt sertifikatet, konfigurer DNS-serveren din til å legge til en 

, som peker til den offentlige IP-adressen til din virtuelle maskin.

Som et siste steg kan vi nå bruke Certbot sin nginx-integrasjon for automatisk å oppdatere nginx-konfigurasjonen slik at den hanterar TLS riktig. Dette gjøres med den enkle kommandoen


Denne kommandoen konfigurerer nå nginx-serveren slik at vi får ønsket oppførsel:


Med disse stegene fullført er din selvhostede versjon av applikasjonen fullt funksjonell og sikret med HTTPS. Selv om vi stoler på at Azure ivaretar sikkerheten og ikke sender dataene våre fra VM-en til USA, kan disse stegene også utføres på en lokal Linux-server eller en hjemmeserver for fullstendig isolasjon og kontroll. Dette sikrer at ingen eksterne skyleverandører har tilgang til ditt miljø. Merk at den første brukeren som logger inn på OpenWebUI etter installasjonen blir administrator, så sørg for at du er den første som oppretter en konto. Merk også at sertifikatet fra Let's Encrypt utløper etter 3 måneder, så det må fornyes. Dette kan automatiseres, men er utenfor omfanget av dette blogginnlegget.

Er dette oppsettet egentlig nyttig? Vel, hvis du har en kraftig maskin on-prem som ikke blir brukt, kan du kjøre denne koden på den, eller bruke enda kraftigere modeller med flere vekter, som 

I denne bloggposten skal vi se hvordan du kan få satt opp en egen server med Deepseek installert som du kan bruka - helt sikkert og isolert!

Backend

Våre utviklere med erfaring i backend

Backend i våre prosjekter

Automatisert utbetaling av lønn i Bitcoin

Vedlikehold på kraftsystemet hos Statnett

Dette skriver vi om backend

Glem chatbots – den nyeste AI-modellen fra OpenAI kan snakke med kundene dine

Episode 3: OKR automatisering

Hva betyr grønn teknologi, og hva kan vi som utviklere bidra med?

Hvordan du kan kjøre LLMs som Deepseek selv med OpenWebUI og Ollama

Trekk i spaken, fyr av en request: Bygg en partyspake i Rust

Vi du vite mer om hvordan vi bruker backend i Snøkam?