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
|
|
@ -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")
|
||||
```
|
||||
|
||||
---
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue