Tekniske detaljer

Detaljerte spesifikasjoner og arkitektur for Snakki

🤖 KI-modeller og leverandører

Primær KI-motor

Google Gemini 2.0 Flash

Tilgang via: OpenRouter

Modell-ID: google/gemini-2.0-flash-001

Reserve-system

GPT-4o Mini

Tilgang via: OpenAI

Modell-ID: gpt-4o-mini

Spesialiserte KI-tjenester

Bildegenerering

Google Gemini Imagen

Lager bilder basert på tekstbeskrivelser.

Maksimalt 3 bilder per bruker per dag.

Tegneseriekonvertering

Replicate Flux Kontext Pro

Konverterer bilder til en tegneseriestil.

Tilpasset for en barnevennlig stil.

Innholdsvalidering

Mistral 7B Instruct

Validerer bildeforespørsler.

Oversetter til engelsk for generering.

Bildesikkerhet

Google Gemini 2.5 Flash Lite

Validerer opplastede bilder.

Sikrer at innholdet er barnevennlig.

Valg av modeller og deres egenskaper

Google Gemini 2.0 Flash: Dette er vår hovedmodell, valgt for sin sterke ytelse på norsk, gode evne til å følge sikkerhetsinstruksjoner og kostnadseffektivitet.

GPT-4o Mini: Vår reservemodell, som har lignende egenskaper som hovedmodellen, med høy stabilitet og forutsigbarhet.

Bildegenerering: Gemini brukes for tekstbasert bildegenerering og har strenge sikkerhetsfiltre for å sikre barnevennlig innhold.

Tegneseriekonvertering: Flux-modellen er spesialisert på å gjøre bilder mer barnevennlige og tegneserieaktige.

Bildesikkerhet: Alle bilder som lastes opp, valideres automatisk av Gemini 2.5 Flash Lite for å sikre at innholdet er egnet for barn.

Failover-logikk

Systemet prøver automatisk den primære modellen først. Ved feil eller utilgjengelighet, skjer en automatisk overgang til reservemodellen uten at brukeren merker det. Bildegenerering og tegneseriekonvertering har ingen reserve, da dette er spesialiserte tjenester.

⚙️ KI-parametre og konfigurasjon

Temperatur

0.8

Balanserer kreativitet og konsistens i KI-svarene.

Maks antall tokens

2048

Angir maksimal lengde på KI-svar i tokens.

Frekvensstraff

0

Kontrollerer repetisjon av ord og uttrykk.

Tilstedeværelsesstraff

0

Oppmuntrer til å introdusere nye emner i samtalen.

🏗️ Teknisk arkitektur

Backend-arkitektur

  • Språk: PHP 8+
  • Webserver: Apache/Nginx med mod_rewrite
  • Konfigurasjon: JSON-basert med miljøvariabler
  • API-struktur: RESTful POST-endepunkt
  • Datakommunikasjon: JSON for forespørsler og svar

Frontend-arkitektur

  • Rammeverk: Ren JavaScript (ingen eksterne avhengigheter)
  • Styling: CSS3 med tilpassede CSS-egenskaper (variabler)
  • Responsivt design: CSS Grid og Flexbox
  • PWA-støtte: Web manifest og service worker
  • Mørk modus: Tilpassede CSS-egenskaper med localStorage

Dataflyt

Systemets dataflyt-arkitektur

Steg 1: Brukerens melding sendes fra nettleseren til API-endepunktet.

Steg 2: API-en validerer meldingen og videresender den til den valgte KI-leverandøren.

Steg 3: KI-leverandøren behandler forespørselen og returnerer et svar.

Steg 4: API-en validerer svaret og sender det tilbake til nettleseren.

Parallelt: Samtalehistorikk lagres lokalt i nettleseren, mens antall forespørsler (rate limit) spores på serveren.

Sikkerhetshensyn i arkitekturen

CORS-headere: Kun godkjente domener kan gjøre API-kall.

Inputvalidering: Alle brukerdata valideres og renses.

Ratebegrensning: En kombinasjon av IP, fingeravtrykk og enhets-ID brukes.

Tidsavbruddshåndtering: 30 sekunders totalt tidsavbrudd, 10 sekunders tilkoblings-tidsavbrudd.

🤖 KI-basert deteksjon av aktuelle hendelser

Utfordringen med dagsaktuelle spørsmål

KI-modeller har en "kunnskapsgrense" og kan ikke svare på dagsaktuelle spørsmål uten tilgang til oppdatert informasjon fra internett.

KI-basert deteksjon

KI-modellen bestemmer selv når online-informasjon er nødvendig:

Implementering

To-trinns prosess for dagsaktuelle spørsmål

Trinn 1 - Evaluering: Spørsmålet sendes først til standard KI-modell, som vurderer om oppdatert informasjon er nødvendig.

Trinn 2A - Standard svar: Hvis spørsmålet kan besvares med eksisterende kunnskap, returneres svaret direkte.

Trinn 2B - Online-søk: Hvis fersk informasjon er nødvendig, aktiveres OpenRouters online-funksjon, som søker på internett og returnerer et oppdatert svar.

Feilhåndtering: Ved problemer med online-søk, informeres brukeren om at oppdatert informasjon ikke er tilgjengelig.

Implementeringslogikk

Beslutningsprosessen

Systemet bruker en intelligent beslutningslogikk for å avgjøre når online-søk er nødvendig:

  • Markør-deteksjon: KI-modellen returnerer en spesiell markør når den identifiserer behov for oppdatert informasjon.
  • Automatisk omruting: Ved deteksjon av markøren, rutes spørsmålet automatisk til online-modellen.
  • Modellformat: Online-versjonen aktiveres ved å legge til ':online' suffiks til modellnavnet.
  • Resultatflagging: Svaret merkes med en indikator som viser at fersk informasjon ble hentet.
  • Reserve-strategi: Ved feil returneres en brukervennlig melding om at oppdatert informasjon ikke er tilgjengelig.

Fordeler

  • Kontekstforståelse: KI forstår intensjonen bak spørsmålet.
  • Smartere deteksjon: Skiller mellom stabile fakta og endelige posisjoner.
  • Fleksibel: Forstår nye måter å spørre på uten kodeoppdateringer.
  • Norsk-optimalisert: Bedre forståelse av norske uttrykk og kultur.
  • Selvlærende: Blir automatisk bedre med nye KI-modeller.

OpenRouter :online funksjonalitet

OpenRouter tilbyr ":online" suffikset som gir KI-modeller tilgang til sanntids-søkemotordata:

  • Modellformat: google/gemini-2.0-flash-001:online
  • Tilgang: Kun via OpenRouter (ikke OpenAI).
  • Kostnad: Litt høyere enn vanlige modeller.
  • Responstid: Noe tregere på grunn av web-søk.

Kostnadshensyn og optimalisering

KI-ens selvstendige vurdering av behov for online-søk reduserer unødvendige og dyre API-kall:

  • Token-besparelse: Når [ONLINE_NEEDED] detekteres, genereres ikke et komplett svar fra den første modellen.
  • Selektiv bruk: Omtrent 10% av spørsmålene krever online-tilgang, noe som betyr at kun 10% betaler premium.
  • Bedre responstid: Kortere første respons når online-tilgang er nødvendig.
  • Feilhåndtering: Tydelig melding hvis online-tjenesten er nede.

Kostnadsoptimalisering:

  • KI-deteksjon: Mindre enn 5% falske positive + token-besparelse når online-tilgang er nødvendig.
  • Selektiv bruk: Omtrent 10% av spørsmålene krever online-tilgang, noe som betyr at kun 10% betaler premium.
  • Effektiv kostnadskontroll for håndtering av aktuelle hendelser.

Visuell indikator

Når online-søk brukes, viser grensesnittet et ✨ "Aktuell info"-merke som informerer brukeren om at svaret er basert på fersk data fra internett.

🔒 Hybrid system for ratebegrensning

Hybrid system

Systemet kombinerer flere faktorer for robust ratebegrensning:

Enhetsfingeravtrykk

Genererer et unikt fingeravtrykk basert på stabile nettleseregenskaper:

  • User Agent-streng
  • Språkinnstillinger (language, languages)
  • Tidssone og lokale innstillinger
  • Maskinvareinformasjon (platform, hardwareConcurrency, maxTouchPoints)
  • Nettleserfunksjoner (cookieEnabled, doNotTrack)
  • WebGL-leverandør/gjengiverinformasjon

Fingeravtrykk-algoritme

Alle komponenter kombineres til en streng, som deretter hashes med SHA-256 og forkortes til 32 tegn for anonymisering.

Vedvarende enhets-ID

Genererer og lagrer en unik enhets-ID:

  • Primær lagring: localStorage
  • Reserve lagring: HTTP-cookie (365 dager)
  • Format: dev_[timestamp]_[random]

Kombinert identifikasjonssystem

Logikk for hash-generering

Systemet kombinerer flere identifikatorer for å skape en unik, anonymisert bruker-hash:

  • Primære faktorer: Enhetsfingeravtrykk og enhets-ID brukes som hovedidentifikatorer når tilgjengelig.
  • Sekundær faktor: IP-adresse brukes som tilleggsfaktor for økt sikkerhet.
  • Reserve-mekanisme: Ved manglende enhetsdata brukes IP-adresse som primær identifikator.
  • Hashing: Alle faktorer kombineres og krypteres med SHA-256 for fullstendig anonymisering.
  • Resultat: En unik 64-tegns hash som ikke kan reverseres til original data.

Datastruktur for ratebegrensning

Lagringssystem

Data for ratebegrensning organiseres i en strukturert JSON-fil med to hovedseksjoner:

Brukerbegrensninger:

  • Unik bruker-hash som nøkkel.
  • Dagens dato for automatisk tilbakestilling.
  • Antall meldinger sendt i dag.
  • Anonymiserte identifikatorer for sporing.

IP-statistikk:

  • Samlet antall forespørsler per IP-adresse.
  • Antall unike brukere per IP.
  • Brukes for å oppdage misbruk og fordele kvoter rettferdig.

Automatisk opprydding: Data eldre enn 24 timer slettes automatisk ved neste forespørsel.

Fordeler

  • Mer rettferdig: Søsken på samme IP får egne kvoter.
  • Robust mot omgåelse: Krever endring av flere faktorer.
  • Personvernvennlig: Hasher sensitive data.
  • Gradvis nedgradering: Fungerer selv om enhetsinformasjon mangler.
  • Statistikk: Bedre innsikt i bruksmønstre.

🛡️ Sikkerhet og innholdskontroll

System for innholdssikkerhet

Implementert i content_safety.php med følgende funksjoner:

  • Banneordfiltrering: Regex-basert sjekk av norske banneord.
  • Progressivt varslingssystem: 3 advarsler før økten nullstilles.
  • Likhetsdeteksjon: Oppdager lignende forsøk på omgåelse.
  • Hendelseslogging: Logger sikkerhetshendelser for analyse.

Inputvalidering

  • Meldingslengde: Maksimalt 2000 tegn.
  • Samtalehistorikk: Maksimalt 20 meldinger.
  • Historikk per melding: Maksimalt 5000 tegn.
  • Bildestørrelse: Maksimalt 10MB per opplastet fil.
  • Bildesikkerhet: KI-validering av alle opplastede bilder.
  • JSON-validering av alle innkommende data.

CORS og tilgangskontroll

Domenebegrensninger

Systemet tillater kun API-forespørsler fra forhåndsgodkjente domener:

  • Produksjonsdomener: snakki.no og www.snakki.no (kun HTTPS).
  • Utviklingsmiljø: localhost og 127.0.0.1 på port 8000.
  • Sikkerhet: Alle andre domener blokkeres automatisk.
  • Headere: Strenge CORS-retningslinjer forhindrer cross-site scripting.

👨‍👩‍👧 Foreldresamtykke-system

Aldersbasert tilgangskontroll

Under 13 år

Krever foreldresamtykke via e-post.

Dobbel bekreftelse (double opt-in).

3 måneders gyldighet.

13-16 år

Kan gi eget samtykke.

Foreldre kan trekke tilbake samtykket.

Alders tilpasset innhold.

Teknisk implementering

Samtykkeflyten

  • Token-generering: 64-tegns kryptografisk sikre tokens.
  • E-postverifikasjon: PHPMailer via Gmail SMTP.
  • Prefetch-beskyttelse: Ignorerer HEAD-forespørsler fra e-postklienter.
  • Tidsbegrensning: 24 timer for verifikasjonstokens.
  • Samtykkekoder: 90 dagers gyldighet for deling mellom enheter.
  • Tilbakekalling: Permanent lenke for foreldre til å trekke samtykke.

Datalagring for samtykke

  • consent_records.json: Aktive samtykker (utløper etter 3 måneder).
  • pending_verifications.json: Ventende e-postverifikasjoner (utløper etter 24 timer).
  • revoke_tokens.json: Tilbakekallingstokens (utløper etter 3 måneder).
  • consent_codes.json: Delbare koder (utløper etter 90 dager).
  • emails_sent/: E-postarkiv med kun metadata (lagres i 1 år).

💾 Datalagring og personvern

Lokal lagring (brukerens enhet)

  • localStorage: Samtalehistorikk, brukerinnstillinger, enhets-ID, samtykkedata.
  • sessionStorage: Midlertidige data under økten.
  • Cookies: Kun enhets-ID som reserve (lagres i 365 dager).

Server-side lagring

  • rate_limits.json: Anonymiserte hash-verdier for ratebegrensning (lagres i 24 timer).
  • consent/*.json: Samtykkedata og tokens (varierende utløpstid).
  • logs/: Anonymiserte sikkerhetshendelser og feilsøkingsinformasjon.
  • images/: Genererte bilder med anonymiserte filnavn.
  • Ingen samtaler: Chatmeldinger lagres aldri på serveren.

GDPR-samsvar

Systemet følger prinsippene om dataminimering og formålsbegrensning:

  • Kun nødvendige data for tjenesteutførelse samles inn.
  • Automatisk sletting etter definerte tidsperioder.
  • Fullstendig anonymisering av identifikatorer.
  • Brukerkontrollert sletting av lokale data.
  • Transparent informasjon om all databehandling.

📊 Overvåking og logging

Feillogging

  • PHP error_log() for feil på server-siden.
  • Konsollogging i frontend for feilsøking.
  • Feil ved ratebegrensning logges med IP-adresse.
  • Hendelser knyttet til innholdssikkerhet logges med kontekst.

Ytelsesovervåking

  • API-responstider måles i frontend.
  • Tidsavbruddshåndtering med en grense på 30 sekunder.
  • Failover-statistikk ved leverandørproblemer.

Kapasitetsplanlegging

Med 100 meldinger per bruker per dag:

  • 500 aktive brukere: Omtrent 25 000 API-kall per dag.
  • Estimert kostnad: 15 000-25 000 NOK per måned.
  • Høyest belastning: Skoletid 14:00-17:00 på hverdager.

🔧 Utplassering og drift

Miljøkrav

  • PHP: Versjon 8.0 eller nyere.
  • Utvidelser: curl, json, openssl.
  • Filrettigheter: Skrivetilgang til rate_limits.json.
  • HTTPS: Påkrevd for produksjon.

Konfigurasjon

Nødvendige miljøvariabler

Følgende konfigurasjonsverdier må settes før systemet kan startes:

  • OPENAI_API_KEY: Autentiseringsnøkkel for OpenAI-tjenester.
  • OPENROUTER_API_KEY: Autentiseringsnøkkel for OpenRouter-tjenester.
  • RATE_LIMIT_PER_DAY: Maksimalt antall meldinger per bruker per dag (standard: 50).
  • REPLICATE_API_TOKEN: For bildekonvertering til tegneseriestil.
  • GEMINI_API_KEY: For bildegenerering fra tekstbeskrivelser.

Sikkerhet: Nøkler lagres i .env-fil som aldri legges til versjonskontroll.

Sjekkliste for utplassering

  • ✅ Miljøvariabler konfigurert.
  • ✅ rate_limits.json opprettet med skrivetilgang.
  • ✅ HTTPS aktivert.
  • ✅ CORS-headere konfigurert korrekt.
  • ✅ Feillogging aktivert.
  • ✅ Reserve-rutiner etablert.

📬 Kontakt for teknisk støtte

For utviklere og teknisk interesserte

Har du tekniske spørsmål om implementeringen? Eller ideer og innspill til videre utvikling?

E-post: post@datasor.no

Emnefelt: "Teknisk henvendelse - [ditt emne]"

Åpen kildekode og samarbeid

Mulige fordeler med en tilnærming basert på åpen kildekode:

  • Økt transparens og tillit.
  • Muliggjør bidrag fra fellesskapet.
  • Akselererer utviklingen av sikre KI-verktøy for barn.
  • Deler kunnskap om norsk KI-implementering.
← Tilbake til foreldresiden