refactor(examples): replace sector-specific example material with generic, fictitious examples
Reference files, test fixtures, the playground demo project and one design document now use generic, fictitious examples (buildings, energy, water, grants, municipal services). The playground demo (17 fixtures plus the embedded demo state) tells one consistent story: a municipal customer chatbot that pre-screens housing-benefit applications, classified under Annex III point 5(a). The embedded demo copies were edited in place rather than regenerated, because they already carry newer AI Act dates than the fixture files. Legal text is unchanged. Test semantics are unchanged. Four dark-theme onboarding screenshots with outdated placeholder text are removed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
parent
ced0c5f46d
commit
544934dc57
SSH key fingerprint:
SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q
77 changed files with 363 additions and 368 deletions
|
|
@ -648,7 +648,7 @@ Selv om Microsoft Foundry gir mer fleksibilitet, oppveier ikke dette den 60% hø
|
|||
### Kontekst og problemstilling
|
||||
|
||||
**Bakgrunn:**
|
||||
Vi har en kunde-facing chatbot for Direktoratet for digital tjenesteutvikling sitt "Min Side"-portal (brukt av 500k+ innbyggere for å sjekke kjøretøyinfo, bøter, etc.). Chatbot skal svare på vanlige spørsmål og navigere brukere til riktig selvbetjeningsportal. Prototypen er bygget med Azure OpenAI GPT-4 på Standard (pay-as-you-go) deployment.
|
||||
Vi har en kunde-facing chatbot for Direktoratet for digital tjenesteutvikling sitt "Min Side"-portal (brukt av 500k+ innbyggere for å sjekke søknadsstatus, fakturaer, etc.). Chatbot skal svare på vanlige spørsmål og navigere brukere til riktig selvbetjeningsportal. Prototypen er bygget med Azure OpenAI GPT-4 på Standard (pay-as-you-go) deployment.
|
||||
|
||||
**Problem statement:**
|
||||
Bestemme deployment-type for production: Standard (pay-per-token) vs Provisioned Throughput Units (PTU) for forutsigbar ytelse og kostnad.
|
||||
|
|
|
|||
|
|
@ -532,12 +532,12 @@ Start-SPOAccessReview -SiteUrl "https://contoso.sharepoint.com/sites/Finance"
|
|||
|
||||
**Copilot-tilgang basert på dataklassifisering:**
|
||||
```yaml
|
||||
# Security Copilot plugin for vegdata
|
||||
# Security Copilot plugin for registerdata
|
||||
Descriptor:
|
||||
Name: VegdataPlugin
|
||||
Name: RegisterdataPlugin
|
||||
Authorization:
|
||||
Type: AADDelegated
|
||||
EntraScopes: https://vegdata.no/.default
|
||||
EntraScopes: https://register.example/.default
|
||||
DataClassification: Internal
|
||||
RequiredLabels:
|
||||
- Internal
|
||||
|
|
@ -594,24 +594,24 @@ Descriptor:
|
|||
|
||||
### Når anbefale hvilken security pattern?
|
||||
|
||||
**Scenario 1: Offentlig sektor (Direktoratet for digital tjenesteutvikling) trenger M365 Copilot med intern vegdata**
|
||||
**Scenario 1: Offentlig sektor (Direktoratet for digital tjenesteutvikling) trenger M365 Copilot med intern registerdata**
|
||||
|
||||
**Anbefaling:**
|
||||
1. **Zero Trust foundation (E5 + SharePoint Advanced Management):**
|
||||
- Conditional Access: Require MFA + compliant devices
|
||||
- Sensitivity labels på alle vegdata-dokumenter (Internal/Confidential)
|
||||
- DLP policies for å blokkere deling av vegdata eksternt
|
||||
- Oversharing review for alle SharePoint-siter med vegdata
|
||||
- Sensitivity labels på alle registerdata-dokumenter (Internal/Confidential)
|
||||
- DLP policies for å blokkere deling av registerdata eksternt
|
||||
- Oversharing review for alle SharePoint-siter med registerdata
|
||||
|
||||
2. **Connector for vegdata-API:**
|
||||
2. **Connector for registerdata-API:**
|
||||
- Microsoft Graph Connector med ACL basert på Entra groups
|
||||
- AADDelegated authentication (on-behalf-of)
|
||||
- Vegdata forblir i tenant (ikke sendt til tredjeparter)
|
||||
- Registerdata forblir i tenant (ikke sendt til tredjeparter)
|
||||
|
||||
3. **Audit og compliance:**
|
||||
- Microsoft Purview Audit (1 år retention minimum for offentlig sektor)
|
||||
- Regular access reviews (kvartalsvis)
|
||||
- DPIA for Copilot-bruk med vegdata
|
||||
- DPIA for Copilot-bruk med registerdata
|
||||
|
||||
**Kostnad (100 brukere):**
|
||||
- M365 Copilot: 30 000 NOK/måned
|
||||
|
|
|
|||
|
|
@ -346,7 +346,7 @@ Can you tell me what the image depicts?
|
|||
|
||||
| Sektor | Use case | Multimodal pattern |
|
||||
|--------|----------|-------------------|
|
||||
| **Direktoratet** | Skaderegistrering vei/bruer fra drone-bilder | Multi-image damage assessment |
|
||||
| **Kommunal eiendom** | Skaderegistrering av bygg fra drone-bilder | Multi-image damage assessment |
|
||||
| **NAV** | Automatisk dokumentklassifisering (skjema med vedlegg) | OCR + structured extraction |
|
||||
| **Helsedirektoratet** | Visuell analyse av offentlige helsedata (grafer) | ⚠️ IKKE medisinske bilder |
|
||||
| **Kulturminnevern** | Katalogisering av bygninger/artefakter | Product catalog pattern |
|
||||
|
|
|
|||
|
|
@ -437,7 +437,7 @@ A2A er spesielt relevant for offentlig sektor fordi norske myndigheter opererer
|
|||
| Scenario | Aktører | A2A-kobling |
|
||||
|----------|---------|-------------|
|
||||
| Innbygger-henvendelse (NAV + Skatteetaten) | NAV-agent, Skatteetaten-agent | NAV-agent delegerer skatteoppslag via A2A |
|
||||
| Direktoratet for digital tjenesteutvikling + Politiet | Kjøretøy-agent, Trafikk-agent | Felles trafikkanalyse via A2A |
|
||||
| Direktoratet for digital tjenesteutvikling + kommune | Tilskudd-agent, Saksarkiv-agent | Felles saksoppslag via A2A |
|
||||
| Helseforetak på tvers | Sykehus A-agent, Fastlege-agent | Pasienthistorikk-utveksling (med samtykke) |
|
||||
| DigDir-tjenester | eID-agent, Altinn-agent | Autentisert datautveksling |
|
||||
|
||||
|
|
@ -455,7 +455,7 @@ A2A er spesielt relevant for offentlig sektor fordi norske myndigheter opererer
|
|||
|
||||
```json
|
||||
{
|
||||
"name": "Direktoratet Kjøretøy-agent",
|
||||
"name": "Direktoratet Tilskudd-agent",
|
||||
"version": "2.0.0",
|
||||
"capabilities": {
|
||||
"streaming": false,
|
||||
|
|
@ -464,7 +464,7 @@ A2A er spesielt relevant for offentlig sektor fordi norske myndigheter opererer
|
|||
"extensions": {
|
||||
"gdpr": {
|
||||
"personalData": true,
|
||||
"dataCategories": ["kjøretøydata", "eierskap"],
|
||||
"dataCategories": ["søknadsdata", "inntekt"],
|
||||
"retentionDays": 90,
|
||||
"dataLocation": "Norway East",
|
||||
"legalBasis": "offentlig myndighetsutøvelse"
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ For mange organisasjoner er svaret ikke enten-eller, men en hybrid tilnærming d
|
|||
],
|
||||
"knowledge": {
|
||||
"sharepoint_sites": [
|
||||
"https://ddt.sharepoint.com/sites/IT-KB"
|
||||
"https://contoso.sharepoint.com/sites/IT-KB"
|
||||
],
|
||||
"graph_connectors": ["servicenow-connector"]
|
||||
},
|
||||
|
|
|
|||
|
|
@ -286,7 +286,7 @@ Distance 1.0 = Helt ulike prompts
|
|||
| "Hva er hovedstaden i Norge?" | "Hvilken by er Norges hovedstad?" | ~0.05 | Ja |
|
||||
| "Forklar maskinlæring" | "Hva er machine learning?" | ~0.10 | Ja |
|
||||
| "Hvordan søker jeg om byggetillatelse?" | "Prosessen for å få byggetillatelse" | ~0.12 | Ja |
|
||||
| "Hva er veibygging?" | "Hvordan bygger man en bro?" | ~0.25 | Nei |
|
||||
| "Hva er fotosyntese?" | "Hvordan fungerer en solcelle?" | ~0.25 | Nei |
|
||||
| "Fortell om AI" | "Hva er kvantemekanikk?" | ~0.45 | Nei |
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -183,18 +183,18 @@ Unified Catalog tilbyr flere oppdagelsesmekanismer for å finne data:
|
|||
```
|
||||
Eksempler på naturlig språk-søk (preview):
|
||||
|
||||
Søk: "Jeg trenger tre år med trafikkdata fra Direktoratet for digital tjenesteutvikling
|
||||
for å analysere rushtrafikk-mønstre"
|
||||
Resultat: Data products med trafikktelledata, reisehastighetsmålinger
|
||||
Søk: "Jeg trenger tre år med energidata fra Direktoratet for digital tjenesteutvikling
|
||||
for å analysere forbruksmønstre i kontorbygg"
|
||||
Resultat: Data products med timeverdier fra energimålere, temperaturmålinger
|
||||
|
||||
Søk: "Finn sertifiserte kundedata med kundeID, navn og adresse"
|
||||
Resultat: Data products med masterdata for kunder
|
||||
|
||||
Søk: "Vis meg Power BI-rapporter om tilstandsdata for broer"
|
||||
Resultat: Rapporter og underliggende datasett for bro-tilstand
|
||||
Søk: "Vis meg Power BI-rapporter om tilstandsdata for skolebygg"
|
||||
Resultat: Rapporter og underliggende datasett for bygningstilstand
|
||||
|
||||
Søk: "Jeg jobber med prediktiv vedlikehold.
|
||||
Vis sensordata fra veisensorer"
|
||||
Vis sensordata fra ventilasjonsanlegg"
|
||||
Resultat: IoT-sensordata, vedlikeholdshistorikk-datasett
|
||||
```
|
||||
|
||||
|
|
@ -335,25 +335,25 @@ Governance Domain: "AI og Maskinlæring"
|
|||
│ ├── Synonymer: "Model drift", "Concept drift"
|
||||
│ └── Tilknyttede assets: monitoring.drift_metrics
|
||||
|
||||
Governance Domain: "Veiforvaltning"
|
||||
Governance Domain: "Eiendomsforvaltning"
|
||||
├── Glossary Terms
|
||||
│ ├── "AADT"
|
||||
│ │ ├── Definisjon: "Årsdøgntrafikk - gjennomsnittlig daglig trafikk"
|
||||
│ │ ├── Synonym: "Annual Average Daily Traffic"
|
||||
│ │ └── Tilknyttede assets: traffic.aadt_measurements
|
||||
│ ├── "EUI"
|
||||
│ │ ├── Definisjon: "Energiintensitet - årlig energiforbruk per m² oppvarmet areal"
|
||||
│ │ ├── Synonym: "Energy Use Intensity"
|
||||
│ │ └── Tilknyttede assets: energy.eui_measurements
|
||||
│ │
|
||||
│ ├── "ÅDT"
|
||||
│ │ ├── Definisjon: "Døgntrafikk for et enkelt år"
|
||||
│ │ └── Relatert: "AADT"
|
||||
│ ├── "Energiintensitet"
|
||||
│ │ ├── Definisjon: "Energiforbruk per m² for et enkelt år"
|
||||
│ │ └── Relatert: "EUI"
|
||||
│ │
|
||||
│ └── "Tilstandsgrad"
|
||||
│ ├── Definisjon: "Skala 0-5 for tilstandsvurdering av veiobjekter"
|
||||
│ ├── Definisjon: "Skala 0-5 for tilstandsvurdering av bygningsdeler"
|
||||
│ ├── Sub-termer:
|
||||
│ │ ├── "TG0 - Ingen avvik"
|
||||
│ │ ├── "TG1 - Mindre avvik"
|
||||
│ │ ├── "TG2 - Moderate avvik"
|
||||
│ │ └── "TG3 - Alvorlige avvik"
|
||||
│ └── Tilknyttede assets: nvdb.condition_assessments
|
||||
│ └── Tilknyttede assets: asset_register.condition_assessments
|
||||
```
|
||||
|
||||
### Opprette glossary terms programmatisk
|
||||
|
|
@ -394,7 +394,7 @@ ai_terms = [
|
|||
"skal predikere på.",
|
||||
"abbreviation": "TD",
|
||||
"glossary_guid": ai_glossary_guid,
|
||||
"owner": "ml-team@ddt.no",
|
||||
"owner": "ml-team@ddt.example",
|
||||
"regulation": "GDPR Art. 6 - Lovlig behandlingsgrunnlag"
|
||||
},
|
||||
{
|
||||
|
|
@ -402,7 +402,7 @@ ai_terms = [
|
|||
"definition": "Sentralisert repository for beregning, lagring og "
|
||||
"servering av ML-features med punkt-i-tid korrekthet.",
|
||||
"glossary_guid": ai_glossary_guid,
|
||||
"owner": "data-engineering@ddt.no"
|
||||
"owner": "data-engineering@ddt.example"
|
||||
},
|
||||
{
|
||||
"name": "Dataminimering",
|
||||
|
|
@ -531,9 +531,9 @@ def assign_data_owner(purview_endpoint, token, asset_guid, owner_info):
|
|||
|
||||
# Eksempel: Tilordne eierskap for ML-datasett
|
||||
assign_data_owner(endpoint, token, gold_features_guid, {
|
||||
"email": "ml-team@ddt.no",
|
||||
"email": "ml-team@ddt.example",
|
||||
"aad_object_id": "abc-123-def",
|
||||
"expert_email": "data-scientist@ddt.no",
|
||||
"expert_email": "data-scientist@ddt.example",
|
||||
"expert_aad_id": "ghi-456-jkl"
|
||||
})
|
||||
```
|
||||
|
|
@ -560,12 +560,12 @@ Oppsett av Governance Domain for AI-prosjekter:
|
|||
|
||||
4. Opprett data products:
|
||||
- "Customer 360 for Churn" -- Kundedatasett for churn-prediksjon
|
||||
- "Traffic Sensor Features" -- Sensordata for trafikkanalyse
|
||||
- "Bridge Condition ML Set" -- Bro-tilstandsdata for vedlikeholds-ML
|
||||
- "Energy Sensor Features" -- Sensordata for energianalyse
|
||||
- "Building Condition ML Set" -- Bygningstilstandsdata for vedlikeholds-ML
|
||||
|
||||
5. Definer glossary terms:
|
||||
- AI-spesifikke termer (se seksjon over)
|
||||
- Domenespesifikke termer (vei, trafikk, infrastruktur)
|
||||
- Domenespesifikke termer (eiendom, energi, infrastruktur)
|
||||
|
||||
6. Sett OKR-er:
|
||||
- "90% av AI-datasett har dokumentert eierskap innen Q2"
|
||||
|
|
@ -790,9 +790,9 @@ def calculate_discovery_metrics(purview_endpoint, token, domain_id):
|
|||
## For arkitekten
|
||||
|
||||
- **Bruk denne referansen** når brukeren trenger hjelp med å sette opp datakatalogisering, organisere data for AI-prosjekter, eller etablere informasjonsforvaltning med Purview Unified Catalog.
|
||||
- For norsk offentlig sektor: **Governance Domains** mapper naturlig til avdelinger/seksjoner i etaten. Anbefal å opprette domener som speiler organisasjonsstrukturen (f.eks. "AI og Maskinlæring", "Veiforvaltning", "Trafikkstyring").
|
||||
- For norsk offentlig sektor: **Governance Domains** mapper naturlig til avdelinger/seksjoner i etaten. Anbefal å opprette domener som speiler organisasjonsstrukturen (f.eks. "AI og Maskinlæring", "Eiendomsforvaltning", "Energistyring").
|
||||
- **Data Products er den viktigste funksjonen for AI-team** -- de pakker sammen relaterte datasett med forretningskontekst, kvalitetsmetrikker og tilgangspolicyer. Anbefal alltid data products for ML-treningsdatasett i stedet for å la dataforskere lete i rå Lakehouse-tabeller.
|
||||
- **Business Glossary** er undervurdert men kritisk. Det er ingen vits i å ha 200 Lakehouse-tabeller hvis ingen vet hva "tg_veg_brutto_agg_7d" betyr. Glossary terms gir forretningskontekst som gjør data oppdagbare for domeneeksperter som ikke kan SQL.
|
||||
- **Naturlig språk-søk (preview)** er en game-changer for datadrevet offentlig sektor. Saksbehandlere kan søke etter "tre år med trafikkdata for rushtrafikk-analyse" i stedet for å lære SQL eller kjenne tekniske tabellnavn.
|
||||
- **Business Glossary** er undervurdert men kritisk. Det er ingen vits i å ha 200 Lakehouse-tabeller hvis ingen vet hva "tg_bygg_brutto_agg_7d" betyr. Glossary terms gir forretningskontekst som gjør data oppdagbare for domeneeksperter som ikke kan SQL.
|
||||
- **Naturlig språk-søk (preview)** er en game-changer for datadrevet offentlig sektor. Saksbehandlere kan søke etter "tre år med energidata for forbruksanalyse" i stedet for å lære SQL eller kjenne tekniske tabellnavn.
|
||||
- Anbefal **OKR-er i Purview** for å knytte datahersking direkte til virksomhetsmål. Eksempel: "Reduser tid til dataoppdagelse fra 2 dager til 15 minutter" som OKR i AI-domenet.
|
||||
- Kombiner med **microsoft-purview-governance.md** for klassifisering/lineage og **data-versioning-lineage.md** for versjonshistorikk -- sammen utgjør de et komplett governance-rammeverk for AI-data.
|
||||
|
|
|
|||
|
|
@ -38,9 +38,9 @@ Microsoft Fabric implementerer data mesh gjennom domener som logisk grupperer da
|
|||
|
||||
```
|
||||
Organisasjon (Fabric Tenant)
|
||||
+-- Domene: Veidata
|
||||
| +-- Arbeidsomrade: Trafikkmalinger
|
||||
| +-- Arbeidsomrade: Vegstandard
|
||||
+-- Domene: Energidata
|
||||
| +-- Arbeidsomrade: Strommalinger
|
||||
| +-- Arbeidsomrade: Anleggsregister
|
||||
| +-- Arbeidsomrade: Vaerdata
|
||||
+-- Domene: Okonomi
|
||||
| +-- Arbeidsomrade: Budsjett
|
||||
|
|
@ -78,8 +78,8 @@ headers = {
|
|||
|
||||
# Opprett domene
|
||||
domain_payload = {
|
||||
"displayName": "Veidata",
|
||||
"description": "Alle dataprodukter relatert til veiinfrastruktur og trafikk"
|
||||
"displayName": "Energidata",
|
||||
"description": "Alle dataprodukter relatert til energiforbruk og nettanlegg"
|
||||
}
|
||||
|
||||
response = requests.post(
|
||||
|
|
@ -95,15 +95,15 @@ print(f"Domene opprettet: {domain_id}")
|
|||
### Subdomener for finmasket organisering
|
||||
|
||||
```
|
||||
Domene: Veidata
|
||||
+-- Subdomene: Trafikkstrom
|
||||
| +-- Trafikktellepunkter (Lakehouse)
|
||||
| +-- Reisetidsmaalinger (Lakehouse)
|
||||
+-- Subdomene: Veistandard
|
||||
| +-- Dekketilstand (Lakehouse)
|
||||
| +-- Baerevne (Lakehouse)
|
||||
Domene: Energidata
|
||||
+-- Subdomene: Forbruk
|
||||
| +-- Malepunkter (Lakehouse)
|
||||
| +-- Timeverdier (Lakehouse)
|
||||
+-- Subdomene: Anlegg
|
||||
| +-- Anleggstilstand (Lakehouse)
|
||||
| +-- Kapasitet (Lakehouse)
|
||||
+-- Subdomene: Hendelser
|
||||
+-- Ulykker (Lakehouse)
|
||||
+-- Avbrudd (Lakehouse)
|
||||
+-- Vedlikehold (Lakehouse)
|
||||
```
|
||||
|
||||
|
|
@ -132,13 +132,13 @@ Hvert dataprodukt bor oppfylle folgende krav:
|
|||
|
||||
# Lag en versjonert tabell med metadata
|
||||
spark.sql("""
|
||||
CREATE TABLE IF NOT EXISTS lakehouse.default.traffic_product_v2 (
|
||||
CREATE TABLE IF NOT EXISTS lakehouse.default.energy_product_v2 (
|
||||
measurement_id BIGINT,
|
||||
station_id STRING,
|
||||
meter_id STRING,
|
||||
timestamp TIMESTAMP,
|
||||
vehicle_count INT,
|
||||
avg_speed DOUBLE,
|
||||
road_surface_temp DOUBLE,
|
||||
consumption_kwh DOUBLE,
|
||||
peak_kw DOUBLE,
|
||||
outdoor_temp DOUBLE,
|
||||
-- Ny kolonne i v2
|
||||
weather_condition STRING
|
||||
)
|
||||
|
|
@ -146,7 +146,7 @@ spark.sql("""
|
|||
TBLPROPERTIES (
|
||||
'delta.columnMapping.mode' = 'name',
|
||||
'product.version' = '2.0',
|
||||
'product.owner' = 'veidata-teamet',
|
||||
'product.owner' = 'energidata-teamet',
|
||||
'product.sla.freshness' = 'PT15M',
|
||||
'product.sla.availability' = '99.5%'
|
||||
)
|
||||
|
|
@ -156,34 +156,34 @@ spark.sql("""
|
|||
### Datakontrakter
|
||||
|
||||
```yaml
|
||||
# data-contract.yaml - Kontrakt for trafikkdata-produktet
|
||||
# data-contract.yaml - Kontrakt for energidata-produktet
|
||||
product:
|
||||
name: traffic-measurements
|
||||
name: energy-measurements
|
||||
version: "2.0"
|
||||
owner: veidata-teamet
|
||||
domain: veidata
|
||||
subdomain: trafikkstrom
|
||||
owner: energidata-teamet
|
||||
domain: energidata
|
||||
subdomain: forbruk
|
||||
|
||||
schema:
|
||||
type: delta
|
||||
location: onelake://workspace/lakehouse/Tables/traffic_measurements
|
||||
location: onelake://workspace/lakehouse/Tables/energy_measurements
|
||||
columns:
|
||||
- name: measurement_id
|
||||
type: BIGINT
|
||||
nullable: false
|
||||
description: Unik ID for maalingen
|
||||
- name: station_id
|
||||
- name: meter_id
|
||||
type: STRING
|
||||
nullable: false
|
||||
description: Tellepunkt-ID (NVDB-referanse)
|
||||
description: Malepunkt-ID (referanse i anleggsregisteret)
|
||||
- name: timestamp
|
||||
type: TIMESTAMP
|
||||
nullable: false
|
||||
description: Maalingstidspunkt (UTC)
|
||||
- name: vehicle_count
|
||||
type: INT
|
||||
- name: consumption_kwh
|
||||
type: DOUBLE
|
||||
nullable: false
|
||||
description: Antall kjoretoy i perioden
|
||||
description: Forbruk i perioden (kWh)
|
||||
|
||||
quality:
|
||||
freshness: PT15M # Maks 15 minutter gammelt
|
||||
|
|
@ -207,34 +207,34 @@ sla:
|
|||
Shortcuts er den primaere mekanismen for datadeling mellom domener uten a kopiere data:
|
||||
|
||||
```
|
||||
Domene A: Veidata Domene B: AI/ML
|
||||
Domene A: Energidata Domene B: AI/ML
|
||||
+---------------------------+ +---------------------------+
|
||||
| Lakehouse: Trafikk | | Lakehouse: Feature Store |
|
||||
| Lakehouse: Forbruk | | Lakehouse: Feature Store |
|
||||
| Tables/ | | Tables/ |
|
||||
| traffic_measurements |------->| traffic_features (shortcut) |
|
||||
| road_conditions |------->| road_features (shortcut) |
|
||||
| energy_measurements |------->| energy_features (shortcut) |
|
||||
| asset_conditions |------->| asset_features (shortcut) |
|
||||
+---------------------------+ +---------------------------+
|
||||
| |
|
||||
| +---------------------------+
|
||||
| | Lakehouse: Modelltrening |
|
||||
+-------------------------->| raw_traffic (shortcut) |
|
||||
+-------------------------->| raw_energy (shortcut) |
|
||||
+---------------------------+
|
||||
```
|
||||
|
||||
### Opprette cross-domain shortcuts
|
||||
|
||||
```python
|
||||
# Opprett shortcut fra AI/ML-domenet til Veidata-domenet
|
||||
# Opprett shortcut fra AI/ML-domenet til Energidata-domenet
|
||||
import requests
|
||||
|
||||
shortcut_payload = {
|
||||
"name": "traffic_measurements",
|
||||
"name": "energy_measurements",
|
||||
"path": "Tables",
|
||||
"target": {
|
||||
"oneLake": {
|
||||
"workspaceId": "veidata-workspace-id",
|
||||
"itemId": "trafikk-lakehouse-id",
|
||||
"path": "Tables/traffic_measurements"
|
||||
"workspaceId": "energidata-workspace-id",
|
||||
"itemId": "forbruk-lakehouse-id",
|
||||
"path": "Tables/energy_measurements"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -341,10 +341,10 @@ For store organisasjoner med mange domener:
|
|||
**Monster 1: Ett arbeidsomrade per Medallion-lag per domene**
|
||||
|
||||
```
|
||||
Domene: Veidata
|
||||
+-- Workspace: veidata-bronze (Inntak)
|
||||
+-- Workspace: veidata-silver (Transformasjon)
|
||||
+-- Workspace: veidata-gold (Servering)
|
||||
Domene: Energidata
|
||||
+-- Workspace: energidata-bronze (Inntak)
|
||||
+-- Workspace: energidata-silver (Transformasjon)
|
||||
+-- Workspace: energidata-gold (Servering)
|
||||
|
||||
Domene: Okonomi
|
||||
+-- Workspace: okonomi-bronze
|
||||
|
|
@ -355,9 +355,9 @@ Domene: Okonomi
|
|||
**Monster 2: Data mesh med domene-spesifikke dataprodukter**
|
||||
|
||||
```
|
||||
Domene: Veidata
|
||||
+-- Workspace: trafikk-produkt (Bronze -> Gold)
|
||||
+-- Workspace: vegstandard-produkt (Bronze -> Gold)
|
||||
Domene: Energidata
|
||||
+-- Workspace: forbruk-produkt (Bronze -> Gold)
|
||||
+-- Workspace: anlegg-produkt (Bronze -> Gold)
|
||||
+-- Workspace: vaer-produkt (Bronze -> Gold)
|
||||
```
|
||||
|
||||
|
|
@ -369,8 +369,8 @@ For skalering kan default domains automatisk tilordne nye arbeidsomrader:
|
|||
# Sett opp default domain slik at nye arbeidsomrader
|
||||
# automatisk tilordnes riktig domene basert pa hvem som oppretter dem
|
||||
|
||||
# Eksempel: Alle arbeidsomrader opprettet av veidata-teamet
|
||||
# tilordnes automatisk til Veidata-domenet
|
||||
# Eksempel: Alle arbeidsomrader opprettet av energidata-teamet
|
||||
# tilordnes automatisk til Energidata-domenet
|
||||
```
|
||||
|
||||
### Overvaking pa tvers av domener
|
||||
|
|
|
|||
|
|
@ -163,12 +163,12 @@ Fabric Data Factory stotter fire typer avhengigheter mellom aktiviteter:
|
|||
from datetime import timedelta
|
||||
|
||||
pipeline_activities = {
|
||||
"ingest_traffic": {"duration": timedelta(minutes=15), "depends_on": []},
|
||||
"ingest_energy": {"duration": timedelta(minutes=15), "depends_on": []},
|
||||
"ingest_weather": {"duration": timedelta(minutes=10), "depends_on": []},
|
||||
"ingest_road_conditions": {"duration": timedelta(minutes=12), "depends_on": []},
|
||||
"validate_traffic": {"duration": timedelta(minutes=5), "depends_on": ["ingest_traffic"]},
|
||||
"ingest_building_data": {"duration": timedelta(minutes=12), "depends_on": []},
|
||||
"validate_energy": {"duration": timedelta(minutes=5), "depends_on": ["ingest_energy"]},
|
||||
"validate_weather": {"duration": timedelta(minutes=3), "depends_on": ["ingest_weather"]},
|
||||
"join_datasets": {"duration": timedelta(minutes=20), "depends_on": ["validate_traffic", "validate_weather", "ingest_road_conditions"]},
|
||||
"join_datasets": {"duration": timedelta(minutes=20), "depends_on": ["validate_energy", "validate_weather", "ingest_building_data"]},
|
||||
"generate_features": {"duration": timedelta(minutes=30), "depends_on": ["join_datasets"]},
|
||||
"train_model": {"duration": timedelta(minutes=45), "depends_on": ["generate_features"]},
|
||||
"evaluate_model": {"duration": timedelta(minutes=10), "depends_on": ["train_model"]},
|
||||
|
|
@ -202,7 +202,7 @@ def find_critical_path(activities):
|
|||
|
||||
total, paths = find_critical_path(pipeline_activities)
|
||||
print(f"Kritisk sti total tid: {total}")
|
||||
# Kritisk sti: ingest_traffic -> validate_traffic -> join -> features -> train -> evaluate -> deploy
|
||||
# Kritisk sti: ingest_energy -> validate_energy -> join -> features -> train -> evaluate -> deploy
|
||||
# = 15 + 5 + 20 + 30 + 45 + 10 + 5 = 130 minutter
|
||||
```
|
||||
|
||||
|
|
@ -453,7 +453,7 @@ def log_pipeline_metrics(pipeline_name: str, run_id: str, metrics: dict):
|
|||
| SLA-type | Definisjon | Eksempel |
|
||||
|----------|-----------|---------|
|
||||
| **Freshness SLA** | Data skal vaere tilgjengelig innen X tid | "Gaarsdagens data klar for 06:00" |
|
||||
| **Completeness SLA** | Alle forventede data skal vaere med | "100% av tellepunkter representert" |
|
||||
| **Completeness SLA** | Alle forventede data skal vaere med | "100% av maalepunkter representert" |
|
||||
| **Quality SLA** | Data skal oppfylle kvalitetskrav | "< 0.1% feilrater i features" |
|
||||
| **Availability SLA** | Pipeline skal kjore X% av tiden | "99.5% tilgjengelighet" |
|
||||
|
||||
|
|
@ -556,7 +556,7 @@ default_args = {
|
|||
"owner": "ai-team",
|
||||
"depends_on_past": True,
|
||||
"email_on_failure": True,
|
||||
"email": ["ai-team@statens-ddt.no"],
|
||||
"email": ["ai-team@ddt.example"],
|
||||
"retries": 2,
|
||||
"retry_delay": timedelta(minutes=5)
|
||||
}
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@
|
|||
|
||||
Kvaliteten pa treningsdata er den viktigste faktoren for ytelsen til ML-modeller. Effektiv datasampling sikrer at treningsdatasettet er representativt og balansert, mens systematisk datamerking (labeling) gir modellene de korrekte signalene a laere fra. Azure Machine Learning tilbyr en komplett plattform for datamerking med stotte for bade bilde- og tekstdata, inkludert ML-assistert merking som akselererer prosessen vesentlig.
|
||||
|
||||
For norsk offentlig sektor, der data ofte er ubalansert (f.eks. svaert fa svindeltilfeller vs. legitime transaksjoner, eller sjaeldne hendelser i trafikkdata), er stratifisert sampling og aktiv laering spesielt viktig. Riktig sampling reduserer merkebehovet med 50-80%, noe som sparer bade tid og kostnader i prosjekter med stramme budsjetter.
|
||||
For norsk offentlig sektor, der data ofte er ubalansert (f.eks. svaert fa svindeltilfeller vs. legitime transaksjoner, eller sjaeldne hendelser i driftsdata), er stratifisert sampling og aktiv laering spesielt viktig. Riktig sampling reduserer merkebehovet med 50-80%, noe som sparer bade tid og kostnader i prosjekter med stramme budsjetter.
|
||||
|
||||
Denne referansen dekker hele livssyklusen fra datautvalg gjennom merkeprosesser til kvalitetskontroll, med fokus pa teknikker som er relevante for Microsoft AI-stakken og Azure Machine Learning.
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ Denne referansen dekker hele livssyklusen fra datautvalg gjennom merkeprosesser
|
|||
| Scenario | Positiv klasse | Negativ klasse | Ubalanse-ratio |
|
||||
|----------|---------------|----------------|----------------|
|
||||
| Svindeldeteksjon | 0.1% svindel | 99.9% legitim | 1:1000 |
|
||||
| Ulykkesprediksjon | 2% ulykker | 98% normal trafikk | 1:50 |
|
||||
| Reinnleggelsesprediksjon | 2% reinnlagt | 98% ikke reinnlagt | 1:50 |
|
||||
| Dokumentklassifisering | 5% sensitiv | 95% ikke-sensitiv | 1:19 |
|
||||
| Feildeteksjon (IoT) | 0.5% feil | 99.5% normal | 1:200 |
|
||||
|
||||
|
|
@ -112,9 +112,9 @@ def oversample_minority_class(df, label_column, minority_class, target_ratio=0.5
|
|||
# Bruk
|
||||
balanced = oversample_minority_class(
|
||||
df_training,
|
||||
label_column="incident_type",
|
||||
minority_class="accident",
|
||||
target_ratio=0.3 # 30% ulykker i treningsdatasettet
|
||||
label_column="readmission_status",
|
||||
minority_class="readmitted",
|
||||
target_ratio=0.3 # 30% reinnleggelser i treningsdatasettet
|
||||
)
|
||||
```
|
||||
|
||||
|
|
@ -286,18 +286,18 @@ ml_client = MLClient(credential, subscription_id, resource_group, workspace_name
|
|||
|
||||
# Definer merkeprosjekt
|
||||
labeling_job = DataLabelingJob(
|
||||
display_name="traffic-sign-classification",
|
||||
description="Klassifiser trafikkskilt fra vegkamera",
|
||||
display_name="waste-type-classification",
|
||||
description="Klassifiser avfallstyper fra bilder ved gjenvinningsstasjon",
|
||||
labeling_job_type="ImageClassificationMulticlass",
|
||||
data={"uri": "azureml://datastores/images/paths/traffic_signs/"},
|
||||
data={"uri": "azureml://datastores/images/paths/waste_images/"},
|
||||
labels={
|
||||
"classes": [
|
||||
{"name": "speed_limit", "display_name": "Fartsgrense"},
|
||||
{"name": "stop", "display_name": "Stopp"},
|
||||
{"name": "yield", "display_name": "Vikeplikt"},
|
||||
{"name": "no_entry", "display_name": "Innkjoring forbudt"},
|
||||
{"name": "pedestrian", "display_name": "Fotgjenger"},
|
||||
{"name": "construction", "display_name": "Veiarbeid"},
|
||||
{"name": "paper", "display_name": "Papir"},
|
||||
{"name": "plastic", "display_name": "Plast"},
|
||||
{"name": "glass", "display_name": "Glass"},
|
||||
{"name": "metal", "display_name": "Metall"},
|
||||
{"name": "food", "display_name": "Matavfall"},
|
||||
{"name": "hazardous", "display_name": "Farlig avfall"},
|
||||
{"name": "other", "display_name": "Annet"}
|
||||
]
|
||||
},
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@
|
|||
|
||||
Feature stores er et sentralt mønster i moderne MLOps som løser problemet med feature-gjenbruk, konsistens mellom trening og inferens, og operasjonalisering av feature-pipelines. Azure Machine Learning Managed Feature Store og Microsoft Fabric Data Science gir en komplett plattform for å definere, materialisere, dele og overvåke features på tvers av ML-prosjekter.
|
||||
|
||||
For norsk offentlig sektor innebærer feature store-tilnærmingen at data science-team kan dele beregninger på tvers av prosjekter -- for eksempel kan trafikkdata-features brukes både for ulykkesprediksjonsmodeller og køvarslingsmodeller uten redundant feature engineering. Dette reduserer kostnader, forbedrer konsistens og forkorter tid fra eksperimentering til produksjon.
|
||||
For norsk offentlig sektor innebærer feature store-tilnærmingen at data science-team kan dele beregninger på tvers av prosjekter -- for eksempel kan energidata-features brukes både for forbruksprognoser og feildeteksjonsmodeller uten redundant feature engineering. Dette reduserer kostnader, forbedrer konsistens og forkorter tid fra eksperimentering til produksjon.
|
||||
|
||||
Denne referansen dekker feature-definisjon og lagring, point-in-time lookups for trening, feature-oppdateringsstrategier, Data Wrangler for utforskende feature engineering, og overvåking av feature-kvalitet og drift.
|
||||
|
||||
|
|
@ -455,5 +455,5 @@ def calculate_psi(reference, current, buckets=10):
|
|||
- **Bruk denne referansen** når brukeren planlegger ML-infrastruktur, trenger feature-gjenbruk på tvers av prosjekter, eller ønsker å operasjonalisere feature engineering.
|
||||
- Anbefal **Azure ML Managed Feature Store** for organisasjoner med flere ML-team som trenger å dele features. For enkeltprosjekter er **Delta-tabeller i Silver layer** ofte tilstrekkelig.
|
||||
- **Point-in-time lookups er ikke-forhandlingsbart** for tidsserie-features -- uten dette vil modeller lekke fremtidig informasjon og vise urealistisk god ytelse i testing.
|
||||
- For norsk offentlig sektor: Feature stores muliggjør **sentral styring** av beregninger som brukes på tvers av etater -- Direktoratet for digital tjenesteutvikling kan dele trafikkfeatures med andre transportetater via feature store-deling.
|
||||
- For norsk offentlig sektor: Feature stores muliggjør **sentral styring** av beregninger som brukes på tvers av etater -- Direktoratet for digital tjenesteutvikling kan dele energifeatures med andre etater via feature store-deling.
|
||||
- Start med **Data Wrangler** for utforskende feature engineering, deretter formaliser i feature set-spesifikasjoner når features er validert og skal til produksjon.
|
||||
|
|
|
|||
|
|
@ -261,7 +261,7 @@ Governance Domain: "AI og Maskinlæring"
|
|||
│ └── "100% lineage-dekning for ML-pipelines"
|
||||
└── Data Products (kan linkes til glossary terms)
|
||||
├── "Customer 360 Feature Set"
|
||||
└── "Trafikkdata for ML"
|
||||
└── "Energidata for ML"
|
||||
```
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@
|
|||
|
||||
Sanntidsdatastrømming er en fundamental byggestein for AI-applikasjoner som krever umiddelbar respons på hendelser -- fra IoT-sensorer og transaksjoner til brukeratferd og systemmetrikker. Microsoft Fabric Real-Time Intelligence kombinert med Azure Event Hubs og Apache Kafka gir en komplett plattform for inntak, transformasjon og analyse av strømmedata som mater AI-modeller med oppdatert informasjon.
|
||||
|
||||
For norsk offentlig sektor er sanntidsarkitektur særlig relevant for trafikkmonitorering (Direktoratet for digital tjenesteutvikling), helseovervåking, energistyring og beredskapsrespons. Evnen til å oppdage avvik i sanntid og utløse automatiserte handlinger basert på AI-prediksjoner kan redusere responstider dramatisk og forbedre tjenestekvalitet.
|
||||
For norsk offentlig sektor er sanntidsarkitektur særlig relevant for overvåking av vannforsyning (kommunale vannverk), helseovervåking, energistyring og beredskapsrespons. Evnen til å oppdage avvik i sanntid og utløse automatiserte handlinger basert på AI-prediksjoner kan redusere responstider dramatisk og forbedre tjenestekvalitet.
|
||||
|
||||
Denne referansen dekker arkitekturmønstre for å integrere Event Hubs, Kafka og Fabric Eventstream med AI-applikasjoner, inkludert Spark Structured Streaming, KQL Database for tidsserieanalyse, og mønster for hendelsesfiltrering og avledede strømmer.
|
||||
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ simulator = Simulator(model_config=model_config)
|
|||
import wikipedia
|
||||
|
||||
# Hent kildedokument
|
||||
wiki_page = wikipedia.page("Norwegian Public Roads Administration")
|
||||
wiki_page = wikipedia.page("Norway")
|
||||
source_text = wiki_page.summary[:5000]
|
||||
|
||||
# Generer syntetiske spørsmål-svar-par
|
||||
|
|
@ -123,8 +123,8 @@ completion = (
|
|||
|
||||
# Lag prompts for syntetisk datagenerering
|
||||
prompts_df = spark.createDataFrame([
|
||||
("Generer en realistisk kundehenvendelse til Direktoratet for digital tjenesteutvikling om saksbehandling-fornyelse.",),
|
||||
("Generer en syntetisk trafikkrapport for E6 ved Lillehammer med kødata.",),
|
||||
("Generer en realistisk kundehenvendelse til Direktoratet for digital tjenesteutvikling om status på en tilskuddssøknad.",),
|
||||
("Generer en syntetisk avviksrapport fra et kommunalt vannverk med måledata.",),
|
||||
("Generer et eksempel på en byggesøknad til Plan- og bygningsetaten.",),
|
||||
], ["prompt"])
|
||||
|
||||
|
|
@ -145,7 +145,7 @@ client = AzureOpenAI(
|
|||
azure_endpoint="https://<endpoint>.openai.azure.com/"
|
||||
)
|
||||
|
||||
def generate_synthetic_records(template_schema, num_records=100, domain="trafikk"):
|
||||
def generate_synthetic_records(template_schema, num_records=100, domain="vannforsyning"):
|
||||
"""Generer strukturerte syntetiske poster."""
|
||||
records = []
|
||||
for batch_start in range(0, num_records, 10):
|
||||
|
|
@ -168,18 +168,18 @@ def generate_synthetic_records(template_schema, num_records=100, domain="trafikk
|
|||
records.extend(batch["records"])
|
||||
return records
|
||||
|
||||
# Eksempel: Trafikkhendelses-data
|
||||
# Eksempel: Driftshendelses-data (vannforsyning)
|
||||
schema = {
|
||||
"incident_id": "string (UUID)",
|
||||
"road": "string (E6, E18, Rv4, etc.)",
|
||||
"location_km": "float",
|
||||
"incident_type": "string (ulykke, køkjøring, veiarbeid, dyr_i_veien)",
|
||||
"facility": "string (vannverk, pumpestasjon, høydebasseng, etc.)",
|
||||
"network_km": "float",
|
||||
"incident_type": "string (lekkasje, trykkfall, forurensning, pumpestans)",
|
||||
"severity": "int (1-5)",
|
||||
"timestamp": "ISO datetime",
|
||||
"description": "string (norsk tekst, 1-3 setninger)"
|
||||
}
|
||||
|
||||
synthetic_incidents = generate_synthetic_records(schema, num_records=500, domain="trafikk")
|
||||
synthetic_incidents = generate_synthetic_records(schema, num_records=500, domain="vannforsyning")
|
||||
```
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -230,8 +230,8 @@ Video Indexer brukar tre ontologiar for emneinferens:
|
|||
"topics": [
|
||||
{
|
||||
"id": 1,
|
||||
"name": "Vegtrafikk",
|
||||
"referenceId": "Transport/Vegtrafikk",
|
||||
"name": "Energi",
|
||||
"referenceId": "Miljø/Energi",
|
||||
"referenceType": "VideoIndexer",
|
||||
"confidence": 0.89,
|
||||
"language": "nb-NO",
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Integrasjonen av spesialiserte computer vision (CV) modellar med large language
|
|||
|
||||
Azure-plattforma gir eit rikt økosystem for dette: Azure AI Vision for spesialisert bildeanalyse (OCR, objektdeteksjon, multimodal embeddings), Azure OpenAI for GPT-4o og GPT-4.1 sine vision-kapabilitetar, Microsoft Foundry for modellfinetuning og deployment, og Phi-4-multimodal-instruct som ein kostnadseffektiv open-source-modell for edge-scenario. Florence-2-modellen frå Microsoft er eit anna sterkt alternativ for spesialiserte vision-oppgåver.
|
||||
|
||||
For norsk offentleg sektor er denne integrasjonen relevant for byggesaksbehandling (analyse av arkitektteikningar), veginfrastruktur (skadevurdering frå bilete), helsevesen (medisinsk bildeanalyse), og kulturarv (digitalisering og klassifisering av museumsgjenstandar). Nøkkelen er å kombinere rette verktøy for rette oppgåver — bruk spesialiserte CV-modellar for presis ekstraksjon og LLMs for tolking og resonnering.
|
||||
For norsk offentleg sektor er denne integrasjonen relevant for byggesaksbehandling (analyse av arkitektteikningar), eigedomsforvaltning (skadevurdering frå bilete), helsevesen (medisinsk bildeanalyse), og kulturarv (digitalisering og klassifisering av museumsgjenstandar). Nøkkelen er å kombinere rette verktøy for rette oppgåver — bruk spesialiserte CV-modellar for presis ekstraksjon og LLMs for tolking og resonnering.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -65,14 +65,14 @@ training_example = {
|
|||
"messages": [
|
||||
{
|
||||
"role": "system",
|
||||
"content": "Du er ein ekspert på analyse av norske vegskilt."
|
||||
"content": "Du er ein ekspert på identifisering av norske planteartar."
|
||||
},
|
||||
{
|
||||
"role": "user",
|
||||
"content": [
|
||||
{
|
||||
"type": "text",
|
||||
"text": "Identifiser og klassifiser skiltet i biletet."
|
||||
"text": "Identifiser og klassifiser planta i biletet."
|
||||
},
|
||||
{
|
||||
"type": "image_url",
|
||||
|
|
@ -84,8 +84,8 @@ training_example = {
|
|||
},
|
||||
{
|
||||
"role": "assistant",
|
||||
"content": "Skiltet er eit fartsgrenseskilt som viser 80 km/t. "
|
||||
"Type: Forbudsskilt (skilt 362). Tilstand: God."
|
||||
"content": "Planta er hundekjeks (Anthriscus sylvestris). "
|
||||
"Familie: Skjermplantefamilien. Tilstand: Blomstrande."
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -415,7 +415,7 @@ Bruk Phi-4 på edge for rask triagering, send berre komplekse tilfelle til cloud
|
|||
|
||||
### Bruksscenario
|
||||
|
||||
- **Direktoratetet**: Analyse av vegdekkeskade frå inspeksjonsbilete
|
||||
- **Eigedomsforvaltar**: Analyse av fasadeskade frå inspeksjonsbilete
|
||||
- **Kartverket**: Klassifisering av satellittbilete og kartdata
|
||||
- **Kulturminnevern**: Digital katalogisering av kulturminne
|
||||
- **Helsesektoren**: Analyse av røntgen/MR med AI-assistanse (medisinsk produkt-regulering)
|
||||
|
|
@ -449,6 +449,6 @@ Bruk Phi-4 på edge for rask triagering, send berre komplekse tilfelle til cloud
|
|||
|
||||
- **Cascade-mønsteret** (Azure AI Vision først, GPT-4o for komplekse tilfelle) reduserer kostnad med 60-80% — bruk Vision for filtrering/kategorisering og GPT-4o berre for det som krev resonnering
|
||||
- **Vision fine-tuning av GPT-4o** (2024-08-06) gir domene-spesialisering — men Azure filtrerer automatisk ut bilete med personar/ansikt frå treningsdata, noko som avgrensar bruksområdet
|
||||
- **Phi-4-multimodal-instruct** med Student-Teacher fine-tuning frå GPT-4o gir edge-kapabel vision AI — relevant for Direktoratetet sin inspeksjonsinfrastruktur og andre offline-scenario
|
||||
- **Phi-4-multimodal-instruct** med Student-Teacher fine-tuning frå GPT-4o gir edge-kapabel vision AI — relevant for inspeksjon i felt og andre offline-scenario
|
||||
- **Few-shot visual learning** med GPT-4o krev berre 3-5 eksempelbilete for ny klassifiseringsoppgåve — bruk `detail: "low"` på eksempel (85 tokens) og `detail: "high"` på target for å optimalisere kostnad
|
||||
- **Multimodal embeddings** (Azure AI Vision v4.0) støttar 102 språk og muliggjer semantisk bildesøk — bruk for å bygge søkbare bildearkiv i offentleg sektor
|
||||
|
|
|
|||
|
|
@ -330,11 +330,11 @@ def create_public_sector_prompt(context: str, style: str = "informativ") -> str:
|
|||
|
||||
return f"{base_prompts.get(style, base_prompts['informativ'])}{context}"
|
||||
|
||||
# Eksempel: Generer illustrasjon for vegsikkerheit
|
||||
# Eksempel: Generer illustrasjon for brannførebygging
|
||||
prompt = create_public_sector_prompt(
|
||||
"Illustrer konseptet med nullvisjon for trafikksikkerheit. "
|
||||
"Vis ein trygg veg med fotgjengarfelt, sykkelsti og bil "
|
||||
"i ein moderne norsk bysamanheng med fjell i bakgrunnen.",
|
||||
"Illustrer konseptet med brannsikker heim. "
|
||||
"Vis ei stove med røykvarslar, brannslokkingsapparat og merkt nødutgang "
|
||||
"i ein moderne norsk bustad med fjell utanfor vindauget.",
|
||||
style="informativ"
|
||||
)
|
||||
```
|
||||
|
|
|
|||
|
|
@ -329,7 +329,7 @@ async def analyze_image_cached(image_data: bytes, prompt: str, cache_client):
|
|||
|----------|--------------|-----------|
|
||||
| Byggesøknad med teikningar | `high` | Ekstraher mål, material, plassering |
|
||||
| Passfoto-validering | `low` | Grunnleggjande kvalitetssjekk (ansiktsblurring aktiv) |
|
||||
| Vegskilt-inventering | `high` | Klassifisering og tilstandsvurdering |
|
||||
| Inventarregistrering | `high` | Klassifisering og tilstandsvurdering |
|
||||
| Kartanalyse | `high` | Identifiser markerte område, målestokk |
|
||||
| Fakturabehandling | `high` | Kombiner med Document Intelligence |
|
||||
|
||||
|
|
@ -368,5 +368,5 @@ Gje ein strukturert vurdering i JSON-format.
|
|||
- **GPT-4o vision brukar ein to-nivå token-modell:** `low` (flat 85 tokens) vs. `high` (tile-basert, 170 tokens per 512x512 tile + 85 base). Alltid berekn token-kostnad før du designar ein pipeline med mange bilete.
|
||||
- **Ansiktsblurring er automatisk i Azure OpenAI** og kan ikkje deaktiverast for GPT-4o. Dette er ein fordel for norsk personvern, men avgrensar brukstilfelle som ansiktsbasert identifisering.
|
||||
- **Kombiner native vision med Azure Document Intelligence** for strukturert dokumentanalyse. GPT-4o gir generell forståing; Document Intelligence gir presis feltekstraksjon.
|
||||
- **Vision fine-tuning er tilgjengeleg for GPT-4o (2024-08-06)** og kan forbetrast for spesifikke domene som norske byggesøknadar eller vegskilt. Merk at bilete med personar blir filtrert ut.
|
||||
- **Vision fine-tuning er tilgjengeleg for GPT-4o (2024-08-06)** og kan forbetrast for spesifikke domene som norske byggesøknadar eller kartsymbol. Merk at bilete med personar blir filtrert ut.
|
||||
- **For kostnadsoptimalisering, bruk `detail: auto`** som standard og `low` for screeing/klassifisering. Reservar `high` for tilfelle der detaljar er kritiske.
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ client = ImageAnalysisClient(
|
|||
|
||||
# Analyser bilete med alle tilgjengelege features
|
||||
result = client.analyze_from_url(
|
||||
image_url="https://example.com/road-damage.jpg",
|
||||
image_url="https://example.com/facade-damage.jpg",
|
||||
visual_features=[
|
||||
VisualFeatures.CAPTION,
|
||||
VisualFeatures.DENSE_CAPTIONS,
|
||||
|
|
@ -122,12 +122,12 @@ response = client.chat.completions.create(
|
|||
{
|
||||
"role": "system",
|
||||
"content": """Du er ein bildeklassifiseringsekspert for
|
||||
Direktoratet for digital tjenesteutvikling. Klassifiser vegskader i kategoriane:
|
||||
- SPREKK_LANGSGAAANDE
|
||||
- SPREKK_TVERRGAAANDE
|
||||
- HULLROT
|
||||
- SETNINGSSKADE
|
||||
- KANTSKADE
|
||||
Direktoratet for digital tjenesteutvikling. Klassifiser bygningsskader i kategoriane:
|
||||
- SPREKK_I_MUR
|
||||
- FUKTSKADE
|
||||
- AVSKALLING
|
||||
- ROTSKADE
|
||||
- TAKSKADE
|
||||
- INGEN_SKADE
|
||||
Returner JSON med 'kategori', 'alvorlegheit' (1-5),
|
||||
og 'forklaring'."""
|
||||
|
|
@ -135,11 +135,11 @@ response = client.chat.completions.create(
|
|||
{
|
||||
"role": "user",
|
||||
"content": [
|
||||
{"type": "text", "text": "Klassifiser denne vegskaden:"},
|
||||
{"type": "text", "text": "Klassifiser denne bygningsskaden:"},
|
||||
{
|
||||
"type": "image_url",
|
||||
"image_url": {
|
||||
"url": "https://example.com/road-image.jpg",
|
||||
"url": "https://example.com/facade-image.jpg",
|
||||
"detail": "high"
|
||||
}
|
||||
}
|
||||
|
|
@ -172,7 +172,7 @@ ml_client = MLClient(
|
|||
|
||||
# Definer AutoML image classification job
|
||||
job = ImageClassificationJob(
|
||||
experiment_name="road-damage-classification",
|
||||
experiment_name="facade-damage-classification",
|
||||
training_data=training_dataset,
|
||||
validation_data=validation_dataset,
|
||||
target_column_name="label",
|
||||
|
|
@ -203,8 +203,8 @@ client = ContentUnderstandingClient(
|
|||
|
||||
# Analyser bilete med tilpassa schema
|
||||
poller = client.begin_analyze(
|
||||
analyzer_id="custom-road-damage",
|
||||
inputs=[{"url": "https://example.com/road.jpg"}]
|
||||
analyzer_id="custom-facade-damage",
|
||||
inputs=[{"url": "https://example.com/building.jpg"}]
|
||||
)
|
||||
result = poller.result()
|
||||
```
|
||||
|
|
@ -319,7 +319,7 @@ Azure Blob Storage (bileter)
|
|||
|
||||
### Relevante bruksområde
|
||||
|
||||
- **Vegforvaltning**: Automatisk klassifisering av vegskader frå dronefoto
|
||||
- **Eigedomsforvaltning**: Automatisk klassifisering av bygningsskader frå dronefoto
|
||||
- **Byggesak**: Bildeanalyse av byggeprosjekt for samsvar med reguleringsplanar
|
||||
- **Naturovervaking**: Klassifisering av vegetasjon, dyreliv og miljøtilstand
|
||||
- **Kulturarv**: Kategorisering og tilstandsvurdering av kulturminne
|
||||
|
|
@ -335,7 +335,7 @@ Azure Blob Storage (bileter)
|
|||
### Bias-vurdering
|
||||
|
||||
- Florence-modellen er trent på breie datasett, men kan ha geografisk bias
|
||||
- Norske skiltar, vegmerking og infrastruktur kan krevje finjustering
|
||||
- Norske byggeskikkar, materialar og klimaskadar kan krevje finjustering
|
||||
- Anbefaling: Evaluer alltid med norsk-spesifikt testdatasett
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@
|
|||
|
||||
Multimodal prompt engineering er kunsten å skrive effektive instruksjonar som kombinerer tekst og bilete for å utnytte kapabilitetane til vision-enabled modellar som GPT-4o, GPT-4o mini og GPT-4 Turbo with Vision. Desse modellane aksepterer både tekst og bilete som input, og kan utføre oppgåver som bildeanalyse, visuelt resonnement, dokumentforståing og diagramtolking.
|
||||
|
||||
Microsoft sin offisielle rettleiing for image prompt engineering identifiserer seks grunnprinsipp: kontekstuell spesifisitet, oppgåveorienterte prompts, handtering av nekting (refusals), eksempelbruk, oppdeling av komplekse oppgåver, og definering av output-format. Desse prinsippa er like relevante for norsk offentleg sektor, der multimodale modellar kan nyttast til alt frå byggesaksanalyse til kvalitetssikring av veginfrastruktur.
|
||||
Microsoft sin offisielle rettleiing for image prompt engineering identifiserer seks grunnprinsipp: kontekstuell spesifisitet, oppgåveorienterte prompts, handtering av nekting (refusals), eksempelbruk, oppdeling av komplekse oppgåver, og definering av output-format. Desse prinsippa er like relevante for norsk offentleg sektor, der multimodale modellar kan nyttast til alt frå byggesaksanalyse til tilstandsvurdering av offentlege bygg.
|
||||
|
||||
Microsoft Foundry Playground tilbyr eit interaktivt miljø for å eksperimentere med multimodale prompts, og GPT-4o sin image tokenization-mekanisme påverkar både kostnader og ytelse. Forståing av korleis bilete vert konvertert til tokens er kritisk for kostnadsoptimalisering i produksjonssystem.
|
||||
|
||||
|
|
@ -71,13 +71,13 @@ response = client.chat.completions.create(
|
|||
messages=[
|
||||
{
|
||||
"role": "system",
|
||||
"content": """Du er ein vegingeniør-assistent. Analyser
|
||||
biletet av vegkrysset og beskriv:
|
||||
"content": """Du er ein arealplanleggjar-assistent. Analyser
|
||||
biletet av bustadfeltet og beskriv:
|
||||
1. Kva som er i NORD (øvst i biletet)
|
||||
2. Kva som er i SØR (nedst)
|
||||
3. Kva som er i ØST (høgre)
|
||||
4. Kva som er i VEST (venstre)
|
||||
5. Eventuelle trafikkproblem du observerer
|
||||
5. Eventuelle arealkonfliktar du observerer
|
||||
Returner som strukturert JSON."""
|
||||
},
|
||||
{
|
||||
|
|
@ -85,12 +85,12 @@ response = client.chat.completions.create(
|
|||
"content": [
|
||||
{
|
||||
"type": "text",
|
||||
"text": "Analyser dette vegkrysset for trafikkplanlegging:"
|
||||
"text": "Analyser dette bustadfeltet for arealplanlegging:"
|
||||
},
|
||||
{
|
||||
"type": "image_url",
|
||||
"image_url": {
|
||||
"url": "https://example.com/intersection.jpg",
|
||||
"url": "https://example.com/site-plan.jpg",
|
||||
"detail": "high"
|
||||
}
|
||||
}
|
||||
|
|
@ -120,7 +120,7 @@ response = client.chat.completions.create(
|
|||
{
|
||||
"role": "user",
|
||||
"content": [
|
||||
{"type": "text", "text": "Identifiser alle trafikkskilt "
|
||||
{"type": "text", "text": "Identifiser alle nødutgangsskilt "
|
||||
"og deira posisjon i biletet."},
|
||||
{"type": "image_url", "image_url": {"url": image_url}}
|
||||
]
|
||||
|
|
@ -142,14 +142,14 @@ def classify_with_examples(target_image_url: str,
|
|||
Klassifiser med few-shot bilete-eksempel.
|
||||
|
||||
examples = [
|
||||
{"url": "...", "label": "HULLROT", "forklaring": "..."},
|
||||
{"url": "...", "label": "FUKTSKADE", "forklaring": "..."},
|
||||
{"url": "...", "label": "SPREKK", "forklaring": "..."},
|
||||
]
|
||||
"""
|
||||
messages = [
|
||||
{
|
||||
"role": "system",
|
||||
"content": "Du er ein vegskade-klassifiseringsekspert. "
|
||||
"content": "Du er ein bygningsskade-klassifiseringsekspert. "
|
||||
"Bruk dei gitte eksempla som referanse."
|
||||
}
|
||||
]
|
||||
|
|
@ -159,7 +159,7 @@ def classify_with_examples(target_image_url: str,
|
|||
messages.append({
|
||||
"role": "user",
|
||||
"content": [
|
||||
{"type": "text", "text": "Klassifiser denne vegskaden:"},
|
||||
{"type": "text", "text": "Klassifiser denne bygningsskaden:"},
|
||||
{"type": "image_url",
|
||||
"image_url": {"url": ex["url"], "detail": "low"}}
|
||||
]
|
||||
|
|
@ -174,7 +174,7 @@ def classify_with_examples(target_image_url: str,
|
|||
messages.append({
|
||||
"role": "user",
|
||||
"content": [
|
||||
{"type": "text", "text": "Klassifiser denne vegskaden:"},
|
||||
{"type": "text", "text": "Klassifiser denne bygningsskaden:"},
|
||||
{"type": "image_url",
|
||||
"image_url": {"url": target_image_url, "detail": "high"}}
|
||||
]
|
||||
|
|
@ -343,16 +343,16 @@ AVGRENSINGAR:
|
|||
- Ikkje gjett — be om tilleggsinformasjon om nødvendig
|
||||
"""
|
||||
|
||||
# Eksempel: Vegskade-vurdering
|
||||
# Eksempel: Bygningsskade-vurdering
|
||||
system_message = VISUAL_SYSTEM_TEMPLATE.format(
|
||||
rolle="Fagingeniør med 20 års erfaring frå norsk offentleg sektor",
|
||||
kontekst="Årlege fagvise inspeksjonar i Noreg",
|
||||
oppgåve="Vurder vegskade og anbefal vedlikehaldstiltak",
|
||||
oppgåve="Vurder bygningsskade og anbefal vedlikehaldstiltak",
|
||||
steg_for_steg_instruksjonar="""
|
||||
1. Identifiser skadetypen (sprekk, hullrot, setning, kantskade)
|
||||
1. Identifiser skadetypen (sprekk, fuktskade, avskalling, rotskade)
|
||||
2. Vurder alvorlegheit på skala 1-5
|
||||
3. Estimer utbreiing i m2
|
||||
4. Anbefal tiltak (lappearbeid, fresing, full omlegging)
|
||||
4. Anbefal tiltak (flekkreparasjon, utskifting, full rehabilitering)
|
||||
5. Prioriter (akutt, innan 3 mnd, neste sesong)""",
|
||||
format_spesifikasjon="""JSON med felt:
|
||||
{
|
||||
|
|
@ -373,7 +373,7 @@ system_message = VISUAL_SYSTEM_TEMPLATE.format(
|
|||
| Rolle | System message-fokus | Typisk output |
|
||||
|-------|---------------------|---------------|
|
||||
| Byggesak-konsulent | TEK17-samsvar, reguleringsplan | Avviksliste med referanse |
|
||||
| Vegingeniør | Skadeklassifisering, NVDB-kategori | Vedlikehaldsprioritering |
|
||||
| Bygningsingeniør | Skadeklassifisering, bygningsdel | Vedlikehaldsprioritering |
|
||||
| Kulturminne-rådgjevar | Tilstandsvurdering, freding | Tilstandsrapport |
|
||||
| Miljørådgjevar | Artsidentifisering, habitatvurdering | Konsekvensutgreiing |
|
||||
|
||||
|
|
@ -442,14 +442,14 @@ print(f"Estimerte tokens: {tokens}") # 85 + (170 * 6) = 1105
|
|||
|
||||
### Bruksområde for multimodal prompt engineering
|
||||
- **Byggesak**: Visuell vurdering av samsvar med reguleringsplanar
|
||||
- **Vegforvaltning**: Automatisk skadeklassifisering frå dronefoto
|
||||
- **Eigedomsforvaltning**: Automatisk skadeklassifisering frå dronefoto
|
||||
- **Kulturarv**: Tilstandsvurdering av kulturminne frå bilete
|
||||
- **Plan og kart**: Analyse av reguleringsplanar og kartutsnitt
|
||||
- **Miljø**: Artsidentifisering og habitatvurdering
|
||||
|
||||
### Prompt-design for norsk kontekst
|
||||
- Skriv system messages på norsk for domene-spesifikk terminologi
|
||||
- Referer til norske standardar (TEK17, NVDB, NS-EN-standardar)
|
||||
- Referer til norske standardar (TEK17, NS-EN-standardar)
|
||||
- Inkluder norske einskapar (NOK, m2, km/t)
|
||||
- Bruk norske stadnamn og referansar
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Multi-Modal RAG (Retrieval-Augmented Generation) utvidar tradisjonell tekstbaser
|
|||
|
||||
Azure AI Search introduserte multimodal search som preview i mai 2025, noko som gir native støtte for å indeksere, forstå og hente dokument som inneheld både tekst og bilete. Dette eliminerer behovet for separate system for tekst- og bildeprosessering og reduserer kompleksiteten i RAG-arkitekturen vesentleg.
|
||||
|
||||
For norsk offentleg sektor er multi-modal RAG særleg verdifull for scenario som analyse av offentlege dokument med innebygde diagram og tabellar, byggesøknadar med teikningar, vegdokumentasjon med kartutsnitt, og forskingsrapportar med visualiseringar. Informasjon som tidlegare berre var tilgjengeleg som visuelt innhald i PDF-filer kan no søkast i og brukast som grunnlag for AI-assisterte avgjerder.
|
||||
For norsk offentleg sektor er multi-modal RAG særleg verdifull for scenario som analyse av offentlege dokument med innebygde diagram og tabellar, byggesøknadar med teikningar, arealplanar med kartutsnitt, og forskingsrapportar med visualiseringar. Informasjon som tidlegare berre var tilgjengeleg som visuelt innhald i PDF-filer kan no søkast i og brukast som grunnlag for AI-assisterte avgjerder.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -295,10 +295,10 @@ search_client = SearchClient(
|
|||
|
||||
# Hybrid søk: tekst + vektor + semantisk ranking
|
||||
results = search_client.search(
|
||||
search_text="trafikksikkerheit i tunneler",
|
||||
search_text="brannsikring i offentlege bygg",
|
||||
vector_queries=[
|
||||
VectorizableTextQuery(
|
||||
text="trafikksikkerheit i tunneler",
|
||||
text="brannsikring i offentlege bygg",
|
||||
k_nearest_neighbors=10,
|
||||
fields="text_vector,image_vector"
|
||||
)
|
||||
|
|
|
|||
|
|
@ -375,7 +375,7 @@ def estimate_realtime_cost(sessions_per_day, avg_duration_minutes):
|
|||
- **NAV kontaktsenter**: Automatisert talebasert rettleiing for ytingar og søknader
|
||||
- **Kommunale servicesentra**: 24/7 talebasert borgarservice
|
||||
- **Helsevesenet**: Triageringssamtalar med automatisk dokumentasjon
|
||||
- **Direktoratetet**: Talebasert rettleiing for førarkort og køyretøytenester
|
||||
- **Skatteetaten**: Talebasert rettleiing for skattekort og skattemelding
|
||||
|
||||
### Regulatoriske krav
|
||||
|
||||
|
|
|
|||
|
|
@ -93,14 +93,14 @@ For norsk offentleg sektor med spesialisert terminologi:
|
|||
| Tilpasning | Brukstilfelle | Eksempel |
|
||||
|-----------|--------------|---------|
|
||||
| **Phrase list** | Forbetra gjenkjenning av spesifikke ord | Stadnamn, fagtermar |
|
||||
| **Custom model** | Trenar ny modell med eigne data | Vegsektoren, helsesektor |
|
||||
| **Custom model** | Trenar ny modell med eigne data | Energisektoren, helsesektor |
|
||||
| **Display format** | Tilpass visning av gjenkjend tekst | Tal-til-siffer, dato-format |
|
||||
|
||||
```python
|
||||
# Phrase list for forbetra norsk gjenkjenning
|
||||
phrase_list = speechsdk.PhraseListGrammar.from_recognizer(speech_recognizer)
|
||||
phrase_list.addPhrase("Direktoratet for digital tjenesteutvikling")
|
||||
phrase_list.addPhrase("E6 Megården-Mørsvikbotn")
|
||||
phrase_list.addPhrase("Lofotodden nasjonalpark")
|
||||
phrase_list.addPhrase("Utredningsinstruksen")
|
||||
phrase_list.addPhrase("Forvaltningsloven")
|
||||
phrase_list.addPhrase("personvernforordningen")
|
||||
|
|
@ -217,9 +217,9 @@ class AudioPreprocessor:
|
|||
Mikrofon → Audio stream → Azure Speech SDK
|
||||
↓
|
||||
┌── Recognizing event (interim)
|
||||
│ "Eg trur at veg..."
|
||||
│ "Eg trur at helse..."
|
||||
├── Recognized event (final)
|
||||
│ "Eg trur at vegsektoren bør investere meir."
|
||||
│ "Eg trur at helsesektoren bør investere meir."
|
||||
│ Offset: 1800000 ticks
|
||||
│ Duration: 30500000 ticks
|
||||
└── SessionStopped event
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Videoanalyse og -forståing på Azure-plattforma kombinerer Azure AI Video Index
|
|||
|
||||
For norsk offentleg sektor er videoanalyse relevant for fleire bruksområde: analyse av overvakingsvideo for Direktoratet for digital tjenesteutvikling, transkripsjon og søk i offentlege høyringar for Stortinget, tilgjengelegheitsanalyse av offentleg video, og automatisert kvalitetskontroll av opplæringsvideo. Azure Video Indexer støttar norsk tale-til-tekst og kan oversette til 50+ språk.
|
||||
|
||||
Azure AI Video Indexer tilbyr også real-time videoanalyse (preview) via Azure Arc-enabled infrastruktur, som mogleggjer sanntidsanalyse av livevideo ved kanten — relevant for trafikkmonitorering og smart byinfrastruktur.
|
||||
Azure AI Video Indexer tilbyr også real-time videoanalyse (preview) via Azure Arc-enabled infrastruktur, som mogleggjer sanntidsanalyse av livevideo ved kanten — relevant for anleggsovervaking og smart byinfrastruktur.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -343,7 +343,7 @@ Video Indexer ekstraherer rike audio-innsikter:
|
|||
|
||||
### Bruksscenario
|
||||
|
||||
- **Direktoratet for digital tjenesteutvikling**: Trafikkvideoanalyse for hendingsdeteksjon og trafikkflyt
|
||||
- **Direktoratet for digital tjenesteutvikling**: Søkbar indeksering av opplæringsvideoar
|
||||
- **Stortinget**: Søkbar indeksering av høyringar og debattar
|
||||
- **NRK**: Automatisk underteksting og innhaldsklassifisering
|
||||
- **Kommunar**: Analyse av bystyremøte med talar-identifisering
|
||||
|
|
@ -375,7 +375,7 @@ For bruksscenario som krev sanntidsanalyse utan skyavhengigheit:
|
|||
|----------|------------|-------------|
|
||||
| Søkbar videoarkivering | Video Indexer Standard preset | Transkripsjon + nøkkelord + scener |
|
||||
| Detaljert innhaldsanalyse | Video Indexer Advanced + GPT-4o | Full analyse + semantisk forståing |
|
||||
| Sanntids trafikkmonitorering | Video Indexer on Arc | Edge-basert, låg latency |
|
||||
| Sanntids anleggsovervaking | Video Indexer on Arc | Edge-basert, låg latency |
|
||||
| Videotilgjengelegheit | Video Indexer + Azure Speech TTS | Undertekstar + lydbeskrivingar |
|
||||
| Enkel persondeteksjon | Azure AI Vision Spatial Analysis | Lågare kostnad for basisk analyse |
|
||||
| Narrativ videoforståing | Keyframe sampling + GPT-4o | Temporal kontekst + semantikk |
|
||||
|
|
@ -387,5 +387,5 @@ For bruksscenario som krev sanntidsanalyse utan skyavhengigheit:
|
|||
- **Azure AI Video Indexer** gir 30+ innsiktstypar i ein enkelt API — bruk Standard preset for dei fleste bruksscenario, Advanced for full analyse med kledningsdeteksjon og audioeffektar
|
||||
- **Scene → Shot → Keyframe-hierarkiet** er fundamentalt for temporal forståing — scener er semantiske einingar, shots er kamera-einingar, keyframes er representative stillbilete
|
||||
- **GPT-4o keyframe analysis** utfyller Video Indexer for djupare semantisk forståing — send 5-10 keyframes med kontekst for narrativ analyse av videoinnhald
|
||||
- **Real-time Video Indexer on Arc** (preview) mogleggjer edge-basert sanntidsanalyse — relevant for trafikkmonitorering og smart byinfrastruktur i norsk offentleg sektor
|
||||
- **Real-time Video Indexer on Arc** (preview) mogleggjer edge-basert sanntidsanalyse — relevant for anleggsovervaking og smart byinfrastruktur i norsk offentleg sektor
|
||||
- **Audio insights** (emosjonar, nøkkelord, talarar) kombinert med visuelle innsikter gir heilskapleg videoforståing — bruk dette for søkbar arkivering av offentlege høyringar og møte
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ I Azure-stakken implementeres contextual retrieval via en **Custom Web API Skill
|
|||
Original chunk: "Forskningen understreket AI"
|
||||
→ Problematisk: Hvem, når, hvilken AI?
|
||||
|
||||
Contextual chunk: "Fra Direktoratet for digital tjenesteutvikling sin 2025-rapport om autonome
|
||||
Contextual chunk: "Fra Acme Forskningsinstitutt sin 2025-rapport om autonome
|
||||
kjøretøy. Dette avsnittet diskuterer AI-teknologier for selvkjørende biler.
|
||||
Forskningen understreket AI"
|
||||
→ Tydelig: LLM kan nå forstå konteksten
|
||||
|
|
|
|||
|
|
@ -460,7 +460,7 @@ Microsoft Foundry støtter fine-tuning av embedding-modeller via **Custom Models
|
|||
|
||||
```jsonl
|
||||
{"query": "hva er regelverket for kunstig intelligens i norge", "document": "AI-forordningen (EU AI Act) trådte i kraft...", "label": 1}
|
||||
{"query": "azure openai prising", "document": "Direktoratetets budsjett for 2025...", "label": 0}
|
||||
{"query": "azure openai prising", "document": "Direktoratets budsjett for 2025...", "label": 0}
|
||||
```
|
||||
|
||||
**Tips for norsk/skandinavisk:**
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ Tabellen under viser hvordan de fem lagene gjelder konkret for AI-løsninger i o
|
|||
|-----|-------------------|-----------|
|
||||
| **Juridisk** | AI Act compliance, GDPR, Forvaltningsloven § 28 | Dokumentasjon av høyrisiko-klassifisering; DPIA for personopplysninger i treningsdata; begrunnelse for automatiserte vedtak |
|
||||
| **Organisatorisk** | AI-styringsstrukturer, roller, prosesser | AI council som godkjenner nye modeller; ML engineer vs. domain expert roller; modelldrif-respons-prosedyre |
|
||||
| **Semantisk** | Ontologier, embeddings, prompt-standarder | RAG-ontologi for vegsikkerhetsdokumenter; prompt template-bibliotek for saksbehandling; metadata-skjema for syntetiske data |
|
||||
| **Semantisk** | Ontologier, embeddings, prompt-standarder | RAG-ontologi for helsefaglige retningslinjer; prompt template-bibliotek for saksbehandling; metadata-skjema for syntetiske data |
|
||||
| **Teknisk** | API-versjoner, chunking, token-håndtering | Azure OpenAI versjonspinning; 1024-token chunks med 128-token overlap; rate limit retry med exponential backoff |
|
||||
| **Styring** | Responsible AI, modellregister, red teaming | Microsoft AI Standards; Azure ML model catalog; monthly red team exercises; PTU reservasjonsbudsjett |
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Denne filen inneholder sektorspesifikke sjekklister som supplerer den generelle
|
|||
| Nøkkelord i systembeskrivelse | Sektor | Sjekkliste |
|
||||
|------------------------------|--------|------------|
|
||||
| helse, pasient, journal, klinisk, diagnose, legemiddel, sykehus, lege, sykepleier, triage, EPJ | Helse | §1 |
|
||||
| veg, trafikk, transport, kjøretøy, fartøy, bane, jernbane, luftfart, sjøfart, autonomt | Transport | §2 |
|
||||
| trafikk, transport, kjøretøy, fartøy, bane, jernbane, luftfart, sjøfart, autonomt | Transport | §2 |
|
||||
| bank, forsikring, finans, kreditt, verdipapir, betalingsformidling, regnskap, skatt | Finans | §3 |
|
||||
| politi, justis, kriminal, straff, rettsvesen, domstoler, fengsel, etterforskning, PST | Justis | §4 |
|
||||
| skole, utdanning, student, elev, karakter, læring, barnehage, UH-sektor, vurdering | Utdanning | §5 |
|
||||
|
|
@ -89,15 +89,10 @@ Dersom systemet tilhører flere sektorer, kombineres relevante sjekklister. Sekt
|
|||
|
||||
### Regulatorisk rammeverk
|
||||
|
||||
- **Vegtrafikkloven** (1965, med endringer) — Grunnleggende trafikkregulering og ansvar
|
||||
- **Samferdselsloven** — Ramme for offentlig transportregulering
|
||||
- **Jernbaneloven** og **Jernbaneforskriften** — Krav til sikkerhetsstyringssystem (SMS)
|
||||
- **Luftfartsloven** — Norsk implementering av EASA-regelverk
|
||||
- **Sjøloven** med IMO-krav — Maritim autonomi og COLREGS
|
||||
- **Forskrift om ITS (Intelligent Transport Systems)** — EU ITS-direktiv implementert i norsk rett
|
||||
- **NKOM ITS-retningslinjer** — Nasjonal kommunikasjonsmyndighets krav til ITS-kommunikasjon
|
||||
- **Veglova** — Vegmyndighetenes ansvar for statlig og kommunalt vegnett
|
||||
- **Sektorvise faglige håndbøker** — Trafikksikkerhetsvurdering av veg og trafikkanlegg (utgis av relevant vegmyndighet)
|
||||
|
||||
### Sjekkliste transport (18 punkter)
|
||||
|
||||
|
|
@ -105,7 +100,7 @@ Dersom systemet tilhører flere sektorer, kombineres relevante sjekklister. Sekt
|
|||
|---|-----------|-----------------|-------------|
|
||||
| T-01 | Er sikkerhets-integritetsnivå (SIL/ASIL) definert for AI-komponenten i henhold til IEC 61508 eller ISO 26262? | Sikkerhet | Kritisk |
|
||||
| T-02 | Er det gjennomført HAZOP (Hazard and Operability Study) eller tilsvarende systematisk fareanalyse? | Sikkerhet | Kritisk |
|
||||
| T-03 | Er systemets håndtering av "worst-case"-scenarioer (glatt veg, sikt null, kritisk infrastrukturfeil) dokumentert og testet? | Sikkerhet | Kritisk |
|
||||
| T-03 | Er systemets håndtering av "worst-case"-scenarioer (ising, sikt null, kritisk infrastrukturfeil) dokumentert og testet? | Sikkerhet | Kritisk |
|
||||
| T-04 | Er fail-safe-modus definert — dvs. hva systemet gjør ved tap av sensordata, kommunikasjon eller modellkrash? | Robusthet | Kritisk |
|
||||
| T-05 | Er ansvarsfordeling ved AI-relatert ulykke avklart juridisk — mellom system-eier, operatør og individuell bruker? | Juridisk / Ansvarlighet | Kritisk |
|
||||
| T-06 | Er systemet sertifisert eller under sertifiseringsløp hos relevant tilsynsmyndighet (transport-, jernbane-, luftfarts- eller sjøfartstilsyn)? | Regulatorisk | Kritisk |
|
||||
|
|
@ -113,12 +108,12 @@ Dersom systemet tilhører flere sektorer, kombineres relevante sjekklister. Sekt
|
|||
| T-08 | Er det etablert cyberresiliens mot trusler som GPS-spoofing, LiDAR-jamming og V2X-kommunikasjonsangrep? | Sikkerhet / Cyber | Kritisk |
|
||||
| T-09 | Er systemet testet for norske klimaforhold (is, snø, mørketid, lavt solstå) som skaper ODD-avvik (Operational Design Domain)? | Kvalitet / Robusthet | Høy |
|
||||
| T-10 | Er det definert klare geografiske og klimatiske ODD-grenser for systemet med teknisk håndheving? | Sikkerhet | Høy |
|
||||
| T-11 | Er trafikantenes evne til å forstå og forutsi systemets oppførsel testet (human factors-analyse)? | Brukervennlighet / Sikkerhet | Høy |
|
||||
| T-11 | Er operatørers, passasjerers og andre berørtes evne til å forstå og forutsi systemets oppførsel testet (human factors-analyse)? | Brukervennlighet / Sikkerhet | Høy |
|
||||
| T-12 | Er beredskapsplaner for kjede-KPI-svikt dokumentert, inkludert prosedyre for manuell overstyring? | Tilgjengelighet | Høy |
|
||||
| T-13 | Er datainnsamling fra sensorer og kameraer i samsvar med personvernregelverket, inkludert krav til sletting og formålsbegrensning? | Personvern | Høy |
|
||||
| T-14 | Er systemet evaluert mot tilgjengelighetskrav for funksjonshemmede brukere (universell utforming, diskriminerings- og tilgjengelighetsloven)? | Rettferdighet | Middels |
|
||||
| T-15 | Er vedlikeholds- og kalibreringsprosedyrer for AI-avhengige sensorer dokumentert med ansvarsfordeling? | Drift / Kvalitet | Middels |
|
||||
| T-16 | Er det gjennomført sikkerhetsvurdering av tredjeparts datakilder systemet er avhengig av (kart, vær, trafikk)? | Avhengighet / Risiko | Middels |
|
||||
| T-16 | Er det gjennomført sikkerhetsvurdering av tredjeparts datakilder systemet er avhengig av (kart, vær, posisjonsdata)? | Avhengighet / Risiko | Middels |
|
||||
| T-17 | Er overvåkningsinfrastruktur etablert for deteksjon av ODD-brudd i produksjon? | Drift | Middels |
|
||||
| T-18 | Er det gjennomført livsløpsanalyse for sikkerhetskritiske AI-komponenter, inkludert plan for utfasing og erstatning? | Drift | Lav |
|
||||
|
||||
|
|
@ -128,9 +123,9 @@ Dersom systemet tilhører flere sektorer, kombineres relevante sjekklister. Sekt
|
|||
|---------|--------------|------------|-----------|
|
||||
| ODD-brudd ved ekstremt norsk vintervær (vind, is, snø, mørketid) | Høy | Kritisk | Norsk vinter representerer særskilt ODD-utfordring — spesifikk testprotokoll nødvendig |
|
||||
| GPS-spoofing som feil-navigerer autonomt kjøretøy eller drone | Lav | Kritisk | Kjent sårbarhet særlig nær norske grenseområder med elektronisk krigføring |
|
||||
| Juridisk ansvarsvakuum ved AI-relatert ulykke i kompleks trafikksituasjon | Middels | Kritisk | Norsk rettspraksis mangler presedenser — proaktiv avklaring nødvendig |
|
||||
| Juridisk ansvarsvakuum ved AI-relatert ulykke i kompleks operativ situasjon | Middels | Kritisk | Norsk rettspraksis mangler presedenser — proaktiv avklaring nødvendig |
|
||||
| Sensorforringelse uten deteksjon (degraded mode uten varsling) | Middels | Høy | Krever eksplisitt sensor-health-overvåkning i designet |
|
||||
| Cyberangrep mot trafikkstyringsinfrastruktur som påvirker AI-beslutninger | Lav | Høy | Kritisk nasjonal infrastruktur — krever NSM-koordinering |
|
||||
| Cyberangrep mot styringsinfrastruktur (togledelse, flygeledelse, VTS) som påvirker AI-beslutninger | Lav | Høy | Kritisk nasjonal infrastruktur — krever NSM-koordinering |
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ Er AI-systemet oppført i Annex I / Art. 5 (forbudte praksiser)?
|
|||
|
||||
**Norsk kontekst:**
|
||||
- Statnett: AI for lastbalansering i strømnett: Høyrisiko
|
||||
- Direktoratet for digital tjenesteutvikling: AI-styrt trafikksignal: Høyrisiko
|
||||
- Fjernvarmeselskap: AI som styrer trykk og temperatur i fjernvarmenettet med automatisk avstenging: Høyrisiko
|
||||
- Kommune: AI for overvåking av vannkvalitet med automatisk stans: Høyrisiko
|
||||
- Kommune: AI-chatbot for feilmelding på vann: IKKE høyrisiko (ingen sikkerhetskomponent)
|
||||
|
||||
|
|
@ -428,7 +428,7 @@ Den nye forvaltningsloven (vedtatt 3. juni 2025, Prop. 79 L (2024-2025)) innehol
|
|||
| Domstol: AI for juridisk forskning | 8a | Nei | (d) Forberedende | Grensetilfelle — konservativt HØYRISIKO |
|
||||
| UDI: AI-oversettelse av dokumenter | — | Nei | (a) Smal prosedyre | **IKKE HØYRISIKO** |
|
||||
| Kommune: AI for dokumentklassifisering | — | Nei | (a) Smal prosedyre | **IKKE HØYRISIKO** |
|
||||
| Direktoratet for digital tjenesteutvikling: AI-styrt trafikklys | 2a | Nei | Nei (sikkerhetskomponent) | **HØYRISIKO** |
|
||||
| Kommunalt vannverk: AI-styrt trykkregulering i vannforsyningen | 2a | Nei | Nei (sikkerhetskomponent) | **HØYRISIKO** |
|
||||
| Politiet: Prediktiv policing | 6d/6e | Ja | Nei | **HØYRISIKO** |
|
||||
| Universitet: AI-karakter på essay | 3b | Ja | Nei | **HØYRISIKO** |
|
||||
| Universitet: AI stavekontroll på oppgave | — | Nei | (b) Forbedring | **IKKE HØYRISIKO** |
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
- [Oversikt](#oversikt)
|
||||
- [4-stegs systematisk metodikk](#4-stegs-systematisk-metodikk)
|
||||
- [Rolle-bestemmelse: Provider vs. Deployer](#rolle-bestemmelse-provider-vs-deployer)
|
||||
- [Transport-sektoreksempler](#transport-sektoreksempler)
|
||||
- [Sektoreksempler](#sektoreksempler)
|
||||
- [Grensevurderinger](#grensevurderinger)
|
||||
- [Beslutningsflytdiagram](#beslutningsflytdiagram)
|
||||
- [For arkitekten](#for-arkitekten)
|
||||
|
|
@ -182,26 +182,26 @@ Direktoratet for digital tjenesteutvikling eksempel: Kjøper Microsoft Copilot S
|
|||
|
||||
---
|
||||
|
||||
## Transport-sektoreksempler
|
||||
## Sektoreksempler
|
||||
|
||||
### Eksempel 1: FartsPrediksjonsagent (Direktoratet for digital tjenesteutvikling)
|
||||
- Formål: Predikerer trafikkflyt og anbefaler fartsgrenser på variabelt oppsatte skilt
|
||||
### Eksempel 1: Lastprognoseagent (kommunalt energiverk)
|
||||
- Formål: Predikerer varmebehov i fjernvarmenettet og anbefaler justering av turtemperatur
|
||||
- Steg 1: Ingen forbudte praksiser → NEI
|
||||
- Steg 2: Kritisk infrastruktur (Annex III, pkt. 2)? Påvirker trafikksikkerhet → JA, men kun dersom det tar **bindende** beslutninger. Dersom det kun er et beslutningsstøtteverktøy med menneskelig godkjenning → vurder Art. 6(2) unntak
|
||||
- Steg 2: Kritisk infrastruktur (Annex III, pkt. 2)? Påvirker forsyningssikkerhet → JA, men kun dersom det tar **bindende** beslutninger. Dersom det kun er et beslutningsstøtteverktøy med menneskelig godkjenning → vurder Art. 6(2) unntak
|
||||
- Klassifisering: **Minimal risiko** (beslutningsstøtte) eller **Høyrisiko** (autonomt bindende)
|
||||
|
||||
### Eksempel 2: AutomatiskSaksbehandler for saksbehandlingvurdering
|
||||
- Formål: Vurderer automatisk om en søker oppfyller helsekrav for saksbehandling
|
||||
### Eksempel 2: AutomatiskSaksbehandler for tilskuddsvurdering
|
||||
- Formål: Vurderer automatisk om en søker oppfyller vilkårene for tilskudd
|
||||
- Steg 1: NEI til alle forbudte praksiser
|
||||
- Steg 2: Kategori 4 (viktige offentlige tjenester) → JA, tilgang til offentlig tjeneste
|
||||
- Klassifisering: **HØYRISIKO** (Annex III, pkt. 5)
|
||||
- Rolle: Direktoratet for digital tjenesteutvikling = **Deployer**
|
||||
- Krav: FRIA (Art. 27), logging 6 mnd, samsvarsvurdering fra provider
|
||||
|
||||
### Eksempel 3: Trafikkstyringsagent
|
||||
- Formål: Autonom styring av trafikklys i tunneler og på motorveier
|
||||
### Eksempel 3: Vannforsyningsagent
|
||||
- Formål: Autonom styring av pumper og ventiler i et kommunalt vannverk
|
||||
- Steg 1: NEI
|
||||
- Steg 2: Kategori 1 (kritisk infrastruktur) — styring av trafikksystemer → JA
|
||||
- Steg 2: Kategori 1 (kritisk infrastruktur) — styring av vannforsyning → JA
|
||||
- Klassifisering: **HØYRISIKO** (Annex III, pkt. 2)
|
||||
- Særlige krav: Robusthet, menneskelig override (Art. 14), kontinuerlig overvåking
|
||||
|
||||
|
|
@ -282,7 +282,7 @@ Bruk denne filen når brukeren trenger å klassifisere et AI-system under EU AI
|
|||
1. Gå gjennom steg 1-4 systematisk — hopp ikke over steg
|
||||
2. Still vurderingsspørsmålene eksplisitt for brukerens system
|
||||
3. Dokumenter hvert steg i klassifiseringsrapporten (anbefalt vedlegg til FRIA)
|
||||
4. Bruk transport-sektoreksemplene som analogi når Direktoratet for digital tjenesteutvikling er deployer
|
||||
4. Bruk sektoreksemplene som analogi når Direktoratet for digital tjenesteutvikling er deployer
|
||||
5. Flagg grensetilfeller og anbefal konsultasjon med tilsynsmyndighet
|
||||
|
||||
**Kobling til andre KB-filer:**
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Annex IV spesifiserer hvilken teknisk dokumentasjon som kreves. Under følger hv
|
|||
- Overordnet beskrivelse av funksjonalitet
|
||||
|
||||
**Eksempel:**
|
||||
> "VegvAI-Saksbehandler v2.1 er et beslutningsstøttesystem for saksbehandlere i Direktoratet for digital tjenesteutvikling (Annex III, punkt 5a). Systemet analyserer søknader om dispensasjon fra veitrafikklovgivningen og genererer et begrunnet utkast til vedtak. Endelig vedtak fattes alltid av autorisert saksbehandler."
|
||||
> "Tilskuddsassistent v2.1 er et beslutningsstøttesystem for saksbehandlere i Direktoratet for digital tjenesteutvikling (Annex III, punkt 5a). Systemet analyserer søknader om tilskudd og genererer et begrunnet utkast til vedtak. Endelig vedtak fattes alltid av autorisert saksbehandler."
|
||||
|
||||
**Typiske mangler:**
|
||||
- Annex III-kategorien er ikke spesifisert
|
||||
|
|
@ -301,7 +301,7 @@ Er systemet for biometrisk fjernidentifisering?
|
|||
(Frivillig ekstern vurdering kan velges for troverdighet)
|
||||
```
|
||||
|
||||
**For norsk offentlig sektor:** Typiske systemer (saksbehandlingsstøtte, tildeling av ytelser, trafikkoptimalisering) kan bruke intern prosedyre. Det finnes per 2026-02 ingen norske akkrediterte notified bodies for AI Act — EU-baserte må benyttes for ekstern vurdering.
|
||||
**For norsk offentlig sektor:** Typiske systemer (saksbehandlingsstøtte, tildeling av ytelser, styring av vannforsyning) kan bruke intern prosedyre. Det finnes per 2026-02 ingen norske akkrediterte notified bodies for AI Act — EU-baserte må benyttes for ekstern vurdering.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ Identifiser alle grupper som direkte eller indirekte berøres av AI-systemets be
|
|||
|
||||
| Gruppe | Antall berørte (estimat) | Sårbarhet | Kontaktpunkt / representasjon |
|
||||
|--------|--------------------------|-----------|-------------------------------|
|
||||
| [Gruppe 1 — f.eks. "Søkere om førerrett klasse B"] | [Antall/år] | Lav / Middels / Høy | [Interesseorganisasjon, brukerrepresentant] |
|
||||
| [Gruppe 1 — f.eks. "Søkere om bostøtte"] | [Antall/år] | Lav / Middels / Høy | [Interesseorganisasjon, brukerrepresentant] |
|
||||
| [Gruppe 2 — f.eks. "Eldre søkere (over 70 år)"] | [Antall/år] | Høy | [Råd for eldre, brukerombud] |
|
||||
| [Gruppe 3 — f.eks. "Søkere med funksjonsnedsettelse"] | [Antall/år] | Høy | [FFO, brukerombud] |
|
||||
| [Gruppe 4 — f.eks. "Nyankomne innvandrere"] | [Antall/år] | Middels | [NOAS, integreringsorganisasjoner] |
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ Teknisk dokumentasjon skal utarbeides **før** systemet settes på markedet og h
|
|||
### 9 påkrevde elementer med eksempler
|
||||
|
||||
**Element 1: Generell systembeskrivelse**
|
||||
Eksempel: "AutomatiskSaksbehandler v2.1 — AI-system for automatisk vurdering av helsekrav ved søknad om saksbehandling. Deployer: Direktoratet for digital tjenesteutvikling. Provider: [Leverandørnavn]. Tiltenkt formål: Behandling av ulike søknadskategorier."
|
||||
Eksempel: "AutomatiskSaksbehandler v2.1 — AI-system for automatisk vurdering av vilkår ved søknad om tilskudd. Deployer: Direktoratet for digital tjenesteutvikling. Provider: [Leverandørnavn]. Tiltenkt formål: Behandling av ulike søknadskategorier."
|
||||
|
||||
**Element 2: Design-spesifikasjoner og utviklingsprosess**
|
||||
- Systemarkitektur og komponentoversikt
|
||||
|
|
|
|||
|
|
@ -32,16 +32,16 @@ Art. 13(3) spesifiserer hva bruksinstruksjoner for høyrisiko-AI-systemer skal i
|
|||
|
||||
| Nr. | Punkt | Hva som kreves | Eksempel |
|
||||
|-----|-------|----------------|---------|
|
||||
| a | Identitet og kontaktinformasjon | Tilbyderens navn, adresse og kontaktpunkt for henvendelser om systemet | "Levert av Direktoratet for digital tjenesteutvikling, Vegdirektoratet. Kontakt: ai-support@ddt.no" |
|
||||
| b | Systemets egenskaper og ytelse | Nøyaktighetsmetrikker, kjente begrensninger, sannsynlige feilmønstre | "Systemet har 94% presisjon på standardsaker. Sjeldne dispensasjonstyper håndteres dårligere." |
|
||||
| c | Tiltenkt formål | Spesifikk brukskontekst systemet er designet og validert for | "Beslutningsstøtte for saksbehandlere ved søknader om dispensasjon fra veitrafikkloven §X" |
|
||||
| a | Identitet og kontaktinformasjon | Tilbyderens navn, adresse og kontaktpunkt for henvendelser om systemet | "Levert av Direktoratet for digital tjenesteutvikling, avdeling for tilskuddsforvaltning. Kontakt: ai-support@ddt.example" |
|
||||
| b | Systemets egenskaper og ytelse | Nøyaktighetsmetrikker, kjente begrensninger, sannsynlige feilmønstre | "Systemet har 94% presisjon på standardsaker. Sjeldne søknadstyper håndteres dårligere." |
|
||||
| c | Tiltenkt formål | Spesifikk brukskontekst systemet er designet og validert for | "Beslutningsstøtte for saksbehandlere ved søknader om tilskudd etter tilskuddsordningens forskrift §X" |
|
||||
| d | Systemnivå av nøyaktighet | Kvantitative mål, konfidensintervaller, ytelse på ulike undergrupper | "F1-score: 0,915 på valideringsett (500 historiske saker, 2023–2024)" |
|
||||
| e | Forventede brukere | Hvem systemet er designet for (kompetanse, rolle, opplæringskrav) | "Autoriserte saksbehandlere med gjennomført e-læring (DDT-AI-L01, 2 timer)" |
|
||||
| f | Forhåndsbehandlet inndata | Spesifikasjoner for inndata systemet forventer | "Søknadsskjema PDF. Bilder: maks 10 MB, JPEG/PNG. Ikke støttet: håndskrevne dokumenter" |
|
||||
| g | Mål og begrensninger | Hva systemet er designet for å oppnå og kjente begrensninger | "Genererer vedtaksutkast — erstatter ikke juridisk vurdering. Bør ikke brukes alene for saker med > 500 000 NOK konsekvens" |
|
||||
| h | Kjente og forutsigbare bivirkninger | Risikosituasjoner som kan oppstå ved tiltenkt bruk | "Kan overrepresentere avslag for søkere fra bestemte regioner (bias-kartlagt, se vedlegg B)" |
|
||||
| i | Human-in-the-loop | Grad av menneskelig tilsyn som kreves og beskrivelse av mekanismer | "Saksbehandler må aktivt godkjenne hvert vedtaksutkast. Systemet kan ikke sende vedtak automatisk." |
|
||||
| j | Forventede levetid og vedlikehold | Planlagt levetid, oppdateringsfrekvens, prosedyre for å melde feil | "Levetid: 3 år (2026–2029). Kvartalsvis modellgjennomgang. Feilmelding: ai-incident@ddt.no" |
|
||||
| j | Forventede levetid og vedlikehold | Planlagt levetid, oppdateringsfrekvens, prosedyre for å melde feil | "Levetid: 3 år (2026–2029). Kvartalsvis modellgjennomgang. Feilmelding: ai-incident@ddt.example" |
|
||||
| k | Datakvalitetskrav | Egenskaper ved inndata som påvirker ytelsen | "Søknadsdokumenter må være maskinlesbare PDF-er. Skannet tekst (OCR-konvertert) reduserer nøyaktighet med ca. 8%" |
|
||||
|
||||
### Mal for bruksinstruksjon-dokument
|
||||
|
|
@ -188,7 +188,7 @@ Art. 50(4) krever merking av syntetiske bilde-, lyd- og videoopptak av virkelige
|
|||
|
||||
### Mal 1: Borgermøtende chatbot-notis
|
||||
|
||||
**Kontekst:** Offentlig chatbot på nav.no, ddt.no, skatteetaten.no o.l.
|
||||
**Kontekst:** Offentlig chatbot på nav.no, skatteetaten.no o.l.
|
||||
|
||||
**Anbefalt plassering:** Øverst i chat-vinduet, alltid synlig
|
||||
|
||||
|
|
|
|||
|
|
@ -528,13 +528,13 @@ Executive sponsorship tilgjengelig? ──No──> Ikke etabler CoE nå
|
|||
|
||||
**Struktur:** Unified CoE
|
||||
- Core team (3 FTEs): CoE Lead, AI Architect, AI Security Specialist (KI-seksjonen)
|
||||
- Embedded members: En representant fra hver region + Vegdirektoratet IT
|
||||
- Embedded members: En representant fra hver fagavdeling + IT-avdelingen
|
||||
|
||||
**Ansvarsområder:**
|
||||
- Strategi: AI-strategi alignet med "Nasjonal transportplan"
|
||||
- Strategi: AI-strategi alignet med virksomhetens digitaliseringsstrategi
|
||||
- Kompetanse: Opplæring i Power Platform AI for saksbehandlere (Copilot Studio for saksbehandling-chatbot)
|
||||
- Standarder: Governance for bruk av kamera-AI i trafikkovervåkning (GDPR, Politiregisterloven)
|
||||
- Pilots: AI for vegvedlikehold (prediktiv analyse av asfaltslitasje via computer vision)
|
||||
- Standarder: Governance for bruk av AI i tilskuddsforvaltning (GDPR, forvaltningsloven)
|
||||
- Pilots: AI for dokumentklassifisering (automatisk journalføring av innkommende post)
|
||||
|
||||
**Teknologi:**
|
||||
- Microsoft Foundry i Norway East (data residency)
|
||||
|
|
|
|||
|
|
@ -300,7 +300,7 @@ Root Management Group
|
|||
|
||||
### Eksempel: Governance-struktur for norske offentlige etater
|
||||
|
||||
**Kontekst:** Offentlig virksomhet, regulert, flere AI-pilotprosjekter (chatbot, dokument-analyse, prediktive modeller for vegvedlikehold).
|
||||
**Kontekst:** Offentlig virksomhet, regulert, flere AI-pilotprosjekter (chatbot, dokument-analyse, prediktive modeller for saksflyt).
|
||||
|
||||
**Anbefalt struktur:**
|
||||
|
||||
|
|
@ -323,7 +323,7 @@ Root Management Group
|
|||
│ │ │
|
||||
┌───▼───────────▼─┐ ┌───────────▼──────┐
|
||||
│ Platform (IT) │ │ Fagenheter │
|
||||
│ - Azure policy │───│ - Veg-AI team │
|
||||
│ - Azure policy │───│ - Fag-AI team │
|
||||
│ - Landing zones│ │ - Admin-AI team │
|
||||
│ - Monitoring │ │ - HR-AI team │
|
||||
└─────────────────┘ └──────────────────┘
|
||||
|
|
|
|||
|
|
@ -378,8 +378,8 @@ jobs:
|
|||
### Direktoratet for digital tjenesteutvikling-spesifikke vurderinger
|
||||
|
||||
**Use cases med mandatory red teaming:**
|
||||
- AI-systemer som påvirker trafikksikkerhet (autonomous systems, traffic prediction)
|
||||
- Chatbots som håndterer sensitive brukerdata (kjøretøyregistrering, saksbehandlinginformasjon)
|
||||
- AI-systemer som påvirker fysisk sikkerhet (autonomous systems, prediksjon i kritisk infrastruktur)
|
||||
- Chatbots som håndterer sensitive brukerdata (helseopplysninger, saksbehandlinginformasjon)
|
||||
- Decision-support systems for inspeksjon eller enforcement
|
||||
|
||||
**Data sovereignty:**
|
||||
|
|
|
|||
|
|
@ -257,10 +257,10 @@ For privat nettverkstilgang kan en split-brain DNS-tilnaerming brukes:
|
|||
|
||||
```
|
||||
Normaltilstand:
|
||||
aoai-gateway.intern.ddt.no --> APIM Norway East (privat IP)
|
||||
aoai-gateway.intern.ddt.example --> APIM Norway East (privat IP)
|
||||
|
||||
Ved regional utfall:
|
||||
aoai-gateway.intern.ddt.no --> APIM Sweden Central (privat IP)
|
||||
aoai-gateway.intern.ddt.example --> APIM Sweden Central (privat IP)
|
||||
(manuell DNS-endring eller Azure Private DNS zones)
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@
|
|||
|
||||
Azure IoT Hub er Microsofts sentrale PaaS-tjeneste for toveiskommunikasjon mellom IoT-enheter og skyen. Kombinert med Azure Stream Analytics for sanntidsanalyse og Azure Machine Learning for modelltrening og -scoring, danner IoT Hub kjernen i en enhetlig AI-pipeline fra enhet til innsikt.
|
||||
|
||||
For norsk offentlig sektor er denne arkitekturen relevant for scenarioer som smart veginfrastruktur (sanntidsmaling av trafikk og veiforhold), bygg-automatisering (energistyring i offentlige bygninger), miljooverkaking (luft- og vannkvalitet), og prediktiv vedlikehold av kritisk infrastruktur. IoT Hub gir sikker enhetstilkobling, mens Stream Analytics prosesserer data i sanntid, og Azure ML scorer modeller for prediktive innsikter.
|
||||
For norsk offentlig sektor er denne arkitekturen relevant for scenarioer som smart vannforsyning (sanntidsmaling av trykk og lekkasjer), bygg-automatisering (energistyring i offentlige bygninger), miljooverkaking (luft- og vannkvalitet), og prediktiv vedlikehold av kritisk infrastruktur. IoT Hub gir sikker enhetstilkobling, mens Stream Analytics prosesserer data i sanntid, og Azure ML scorer modeller for prediktive innsikter.
|
||||
|
||||
Arkitekturen skalerer fra hundrevis til millioner av enheter, med innebygd stoette for meldingsruting, device twins for konfigurasjonstyring, og enkel integrasjon med Azure-dataplatformen (Fabric, Event Hub, Cosmos DB) for langsiktig analyse.
|
||||
|
||||
|
|
@ -426,7 +426,7 @@ class HybridScalingConfig:
|
|||
|
||||
| Sektor | Use Case | Enheter | AI-modell |
|
||||
|--------|----------|---------|-----------|
|
||||
| Samferdsel | Veisensor-nettverket | ~5 000 | Trafikk-prediksjon, vintervedlikehold |
|
||||
| Vann og avlop | Sensornettverk i ledningsnettet | ~5 000 | Lekkasje-prediksjon, trykkstyring |
|
||||
| Energi | Smart bygg-styring | ~10 000/bygg | Energi-optimalisering |
|
||||
| Miljoe | Luft/vann-kvalitet | ~500 stasjoner | Forurensnings-varsling |
|
||||
| Helse | Utstyrsovervaking | ~1 000/sykehus | Prediktiv vedlikehold |
|
||||
|
|
|
|||
|
|
@ -519,10 +519,10 @@ health_checks:
|
|||
|
||||
| Scenario | Tilkoblingsstatus | Losning |
|
||||
|----------|-------------------|---------|
|
||||
| Tunneler | Frakoblet | Edge-inferens med kamerasystem |
|
||||
| Fjellanlegg og gruver | Frakoblet | Edge-inferens med lokal sensorlogging |
|
||||
| Fartsoyvervaking | Ustabil | Lokal objektdeteksjon |
|
||||
| Trafikkanalyse | Periodisk | Batch-analyse med synk |
|
||||
| Fergedrift | Variabel | Hybrid med sky-fallback |
|
||||
| Havneanalyse | Periodisk | Batch-analyse med synk |
|
||||
| Havvind og offshore | Variabel | Hybrid med sky-fallback |
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@
|
|||
|
||||
Azure IoT Operations er Microsofts edge runtime-plattform for industrielle IoT-scenarier, bygget pa Azure Arc-enabled Kubernetes. Den kombinerer datainnsamling fra sensorer og utstyr med AI-inferens direkte pa edge, noe som muliggjor sanntidsanalyse uten avhengighet av skytilkobling for tidskritiske beslutninger.
|
||||
|
||||
For norsk offentlig sektor er IoT-integrasjon med AI relevant i scenarier som smart infrastruktur (broer, tunneler, veier), miljooverkaking, energistyring i offentlige bygg, og transportlogistikk. Azure IoT Operations gir en standardisert plattform for a samle sensordata, normalisere dem, og kjore AI-modeller lokalt for prediktiv vedlikehold og anomalideteksjon.
|
||||
For norsk offentlig sektor er IoT-integrasjon med AI relevant i scenarier som smart infrastruktur (vannverk, pumpestasjoner, ledningsnett), miljooverkaking, energistyring i offentlige bygg, og transportlogistikk. Azure IoT Operations gir en standardisert plattform for a samle sensordata, normalisere dem, og kjore AI-modeller lokalt for prediktiv vedlikehold og anomalideteksjon.
|
||||
|
||||
Plattformen bygger pa MQTT-protokollen for enhetskommunikasjon, Data Flows for datatransformasjon og kontekstualisering, og Azure Arc for sentralisert administrasjon. AI-modeller kan deployes som containere pa edge-klyngen, med Azure ML for modelltrenings- og oppdateringspipeliner mellom sky og edge.
|
||||
|
||||
|
|
@ -355,7 +355,7 @@ class AIEdgePipeline:
|
|||
|
||||
### Relevante use cases
|
||||
|
||||
- **Direktoratet for digital tjenesteutvikling**: Sanntids verkontrollovervaking med AI-basert analyse av vaerdata, trafikkmonstre og veiforhold fra veistasjonssensorer
|
||||
- **Kommunalt vannverk**: Sanntids overvaking av ledningsnettet med AI-basert analyse av trykk, vannforbruk og lekkasjer fra sensorer i pumpestasjoner
|
||||
- **Kystverket**: Autonome sensorsystemer langs kysten for miljooverkaking og sikkerhet, med begrenset tilkobling
|
||||
- **Energisektoren**: Smart styring av offentlige bygg med prediktiv vedlikeholdsanalyse av HVAC-systemer
|
||||
- **Helsesektoren**: IoT-basert pasientovervaking pa sykehus med lokal AI for tidlig varsling
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ AKS Edge Essentials er Microsofts lettvekts Kubernetes-distribusjon for edge-sce
|
|||
|
||||
For AI-arbeidsbelastninger pa edge muliggjor AKS Edge Essentials deployment av ML-modeller, inferensservere, og AI-pipelines som Kubernetes-pods med GPU-akselerasjon (via GPU-PV). Tilkoblet Azure Arc gir sentralisert administrasjon, GitOps-basert deployment, og integrasjon med Azure ML, Azure Monitor og Azure Policy.
|
||||
|
||||
For norsk offentlig sektor er AKS Edge Essentials relevant for distribuert AI pa lokale stasjoner (veisensorer, helseutstyr, energimalere) der Kubernetes-basert orkestrering gir standardisert deployment og oppdatering av AI-modeller pa tvers av geografisk spredte enheter.
|
||||
For norsk offentlig sektor er AKS Edge Essentials relevant for distribuert AI pa lokale stasjoner (pumpestasjoner, helseutstyr, energimalere) der Kubernetes-basert orkestrering gir standardisert deployment og oppdatering av AI-modeller pa tvers av geografisk spredte enheter.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -383,9 +383,9 @@ spec:
|
|||
|
||||
| Stasjon | Antall | Hardware | AKS Edge-konfig | AI-workload |
|
||||
|---------|--------|----------|-----------------|-------------|
|
||||
| Veisensorer | ~200 | Industrial PC | Single-node K3s | Trafikk-analyse |
|
||||
| Tunnelverkaking | ~50 | Rack-server | Multi-node K8s | Brann/ventilasjon |
|
||||
| Ferjekaier | ~30 | Rugged PC | Single-node K3s | Bildetelling |
|
||||
| Pumpestasjoner | ~200 | Industrial PC | Single-node K3s | Lekkasje-analyse |
|
||||
| Sykehusbygg | ~50 | Rack-server | Multi-node K8s | Brann/ventilasjon |
|
||||
| Gjenvinningsstasjoner | ~30 | Rugged PC | Single-node K3s | Bildetelling |
|
||||
| Ladestajoner | ~500 | IoT gateway | K3s minimal | Energi-prediksjon |
|
||||
|
||||
### Sikkerhets- og administrasjonskrav
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@
|
|||
|
||||
Offline-first AI-applikasjoner er designet for a fungere primaert lokalt og synkronisere med skyen nar tilkobling er tilgjengelig. Dette monsteret snur den tradisjonelle sky-forst-tilnaermingen pa hodet: i stedet for a feile nar nettverket er nede, er applikasjonen designet for a operere uavhengig med lokal AI-inferens og datalagring.
|
||||
|
||||
For norsk offentlig sektor er offline-first sarlig relevant i felt-scenarioer: vegarbeidere som inspiserer infrastruktur i omrader uten dekning, ambulansepersonell som trenger AI-stoette i rurale omrader, beredskapspersonell under krisesituasjoner der kommunikasjonsinfrastruktur kan vaere nede, og maritime inspeksjoner langs kysten.
|
||||
For norsk offentlig sektor er offline-first sarlig relevant i felt-scenarioer: driftspersonell som inspiserer ledningsnett i omrader uten dekning, ambulansepersonell som trenger AI-stoette i rurale omrader, beredskapspersonell under krisesituasjoner der kommunikasjonsinfrastruktur kan vaere nede, og maritime inspeksjoner langs kysten.
|
||||
|
||||
Microsoft tilbyr flere byggeklosser for offline-first AI: ONNX Runtime for lokal inferens, Azure IoT Edge for container-basert edge-prosessering med utvidet offline-stoette, Azure Container Storage for lokal persistens med automatisk sky-synkronisering, og Phi-modeller for lokale SLM-kapabiliteter.
|
||||
|
||||
|
|
@ -405,7 +405,7 @@ class TestOfflineAI:
|
|||
def test_event_persistence_offline(self, event_store):
|
||||
"""Hendelser skal lagres lokalt ved offline"""
|
||||
event = event_store.append_event(
|
||||
"inspection", "bridge-001",
|
||||
"inspection", "pumpestasjon-001",
|
||||
{"status": "ok", "notes": "Ingen synlige skader"}
|
||||
)
|
||||
assert event.synced is False
|
||||
|
|
@ -465,7 +465,7 @@ class TestOfflineAI:
|
|||
|
||||
| Scenario | Etat | Offline-varighet | AI-funksjon |
|
||||
|----------|------|-----------------|-------------|
|
||||
| Vegfinspeksjon | DDT | Timer | Skadeklassifisering |
|
||||
| Ledningsinspeksjon | Kommunalt vannverk | Timer | Skadeklassifisering |
|
||||
| Ambulanse | Helseetaten | Minutter-timer | Triagering |
|
||||
| Beredskap | DSB | Dager | Situasjonsanalyse |
|
||||
| Maritime inspeksjoner | Sjoefartsdir. | Timer-dager | Rapport-generering |
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ Ifoolge GDPR Art. 35 er DPIA pakrevd nar databehandling sannsynligvis medforer h
|
|||
| Trigger | Edge AI-eksempel | DPIA-krav |
|
||||
|---------|-----------------|-----------|
|
||||
| Automatiserte beslutninger | AI-basert triage pa sykehus | Pakrevd |
|
||||
| Systematisk overvaking | Kamerabasert trafikkanalyse | Pakrevd |
|
||||
| Systematisk overvaking | Kamerabasert overvaking av offentlige rom | Pakrevd |
|
||||
| Sensitive data i stor skala | Helsedata-analyse pa lokale servere | Pakrevd |
|
||||
| Ny teknologi | AI-modeller pa edge-enheter | Vurderes |
|
||||
| Saerbare grupper | AI i barnevern/NAV | Pakrevd |
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ Azure AI Language grupperer PII i tre feature-typer (etter input-format og prose
|
|||
| Adresse | `Address` | Storgata 1, 0123 Oslo | ML-basert |
|
||||
| Organisasjon | `Organization` | NAV, Skatteetaten | ML-basert |
|
||||
| EU Passport | `EUPassportNumber` | Norsk pass | Format-validering |
|
||||
| EU Drivers License | `EUDriversLicenseNumber` | Norsk saksbehandling | Format-validering |
|
||||
| EU Drivers License | `EUDriversLicenseNumber` | Dokumentnummer i EU-format | Format-validering |
|
||||
| Bank Account | `InternationalBankingAccountNumber` | IBAN | Format-validering |
|
||||
|
||||
**Viktig:** Azure detekterer norske fødselsnummer under kategorien `NOIdentityNumber`. Du må spesifisere `language: "no"` for optimal deteksjon.
|
||||
|
|
|
|||
|
|
@ -286,7 +286,7 @@ Azure Cost Management aggregerer kostnader per dag, men fakturering skjer måned
|
|||
| Arkitekturmønstre | **Baseline + Domain Expertise** | FinOps Framework + Azure Well-Architected |
|
||||
| Beslutningsveiledning | **Verified** | Cost optimization best practices (Well-Architected) |
|
||||
| Integrasjon med Microsoft-stakken | **Verified** | Official docs (tags, Power BI, Azure Monitor) |
|
||||
| Offentlig sektor (Norge) | **Domain Expertise** | KTG/DDT-kontekst, ikke Microsoft-spesifikk |
|
||||
| Offentlig sektor (Norge) | **Domain Expertise** | Norsk offentlig sektor-kontekst, ikke Microsoft-spesifikk |
|
||||
| For arkitekten | **Baseline + Best Practices** | Syntetisert fra research + field experience |
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -62,9 +62,9 @@ Denne referansen dekker hele arbeidsflyten for Batch API, fra filsammensetning o
|
|||
Batch API bruker JSON Lines-format (`.jsonl`), der hver linje er en selvstendig JSON-objekt:
|
||||
|
||||
```jsonl
|
||||
{"custom_id": "req-001", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o-batch", "messages": [{"role": "system", "content": "Klassifiser henvendelsen som KLAGE, SPORSMAL, eller TILBAKEMELDING."}, {"role": "user", "content": "Jeg er svart misfornoyd med ventetiden pa fornyelse av forerkort."}], "max_tokens": 50}}
|
||||
{"custom_id": "req-002", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o-batch", "messages": [{"role": "system", "content": "Klassifiser henvendelsen som KLAGE, SPORSMAL, eller TILBAKEMELDING."}, {"role": "user", "content": "Hvordan soker jeg om nytt forerkort?"}], "max_tokens": 50}}
|
||||
{"custom_id": "req-003", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o-batch", "messages": [{"role": "system", "content": "Klassifiser henvendelsen som KLAGE, SPORSMAL, eller TILBAKEMELDING."}, {"role": "user", "content": "Fint arbeid med den nye tunnelen i Rogaland!"}], "max_tokens": 50}}
|
||||
{"custom_id": "req-001", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o-batch", "messages": [{"role": "system", "content": "Klassifiser henvendelsen som KLAGE, SPORSMAL, eller TILBAKEMELDING."}, {"role": "user", "content": "Jeg er svart misfornoyd med ventetiden pa behandling av byggesoknaden min."}], "max_tokens": 50}}
|
||||
{"custom_id": "req-002", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o-batch", "messages": [{"role": "system", "content": "Klassifiser henvendelsen som KLAGE, SPORSMAL, eller TILBAKEMELDING."}, {"role": "user", "content": "Hvordan soker jeg om skjenkebevilling?"}], "max_tokens": 50}}
|
||||
{"custom_id": "req-003", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o-batch", "messages": [{"role": "system", "content": "Klassifiser henvendelsen som KLAGE, SPORSMAL, eller TILBAKEMELDING."}, {"role": "user", "content": "Fint arbeid med det nye biblioteket i kommunen!"}], "max_tokens": 50}}
|
||||
```
|
||||
|
||||
**Viktige regler:**
|
||||
|
|
@ -517,7 +517,7 @@ def retry_failed_requests(
|
|||
system_prompt = """Klassifiser henvendelsen. Svar med JSON:
|
||||
{"kategori": "KLAGE|SPORSMAL|TILBAKEMELDING|SOKNAD",
|
||||
"prioritet": "HOY|NORMAL|LAV",
|
||||
"etat": "FORERKORT|KJORETOYREG|VEIPROSJEKT|ANNET"}"""
|
||||
"tjenesteomraade": "BYGGESAK|SKJENKEBEVILLING|TILSKUDD|ANNET"}"""
|
||||
|
||||
batch_file = generate_batch_file(
|
||||
items=henvendelser,
|
||||
|
|
|
|||
|
|
@ -316,7 +316,7 @@ Azure OpenAI prompt caching reduserer latens og kostnad for requests med identis
|
|||
# System prompt som gjenbrukes pa tvers av requests
|
||||
SYSTEM_PROMPT = """Du er en saksbehandlingsassistent for Direktoratet for digital tjenesteutvikling.
|
||||
Du hjelper med a analysere og klassifisere innkommende henvendelser
|
||||
relatert til forerkort, kjoretoysregistrering og veiprosjekter.
|
||||
relatert til byggesaker, skjenkebevillinger og tilskudd.
|
||||
|
||||
Folg disse retningslinjene:
|
||||
1. Klassifiser henvendelsen i riktig kategori
|
||||
|
|
|
|||
|
|
@ -172,11 +172,11 @@ def design_cacheable_prompt(
|
|||
messages, stats = design_cacheable_prompt(
|
||||
system_instructions="""Du er en AI-assistent for saksbehandlere i
|
||||
Direktoratet for digital tjenesteutvikling. Du hjelper med å analysere klager på vedtak om
|
||||
saksbehandling, vurdere om klagen har grunnlag, og foreslå svar.
|
||||
tilskudd, vurdere om klagen har grunnlag, og foreslå svar.
|
||||
|
||||
Regelverk du skal referere til:
|
||||
- Vegtrafikkloven § 24-34
|
||||
- fagforskriften
|
||||
- Tilskuddsordningens forskrift
|
||||
- Reglement for økonomistyring i staten
|
||||
- Forvaltningsloven § 28-36 (klagebehandling)
|
||||
|
||||
Format: Alltid bruk overskrifter, vurder hvert punkt separat,
|
||||
|
|
@ -184,11 +184,11 @@ messages, stats = design_cacheable_prompt(
|
|||
|
||||
few_shot_examples=[
|
||||
{
|
||||
"input": "Klage: Jeg fikk avslag på fornyelse...",
|
||||
"input": "Klage: Jeg fikk avslag på søknad om driftstilskudd...",
|
||||
"output": "## Vurdering\n### Regelverksvurdering..."
|
||||
},
|
||||
{
|
||||
"input": "Klage: Mitt saksbehandling ble inndratt...",
|
||||
"input": "Klage: Tilskuddet mitt ble krevd tilbakebetalt...",
|
||||
"output": "## Vurdering\n### Regelverksvurdering..."
|
||||
}
|
||||
],
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue