Velg KI-drift: kartlegg dataflyten før modellvalget
Et gjennomarbeidet portaleksempel sammenligner dataflyt, logger og driftsoppgaver for en egen modellserver og en administrert skytjeneste.
Velg KI-drift for en konkret arbeidsflyt. En modell på egen server og en administrert modelltjeneste skiller seg i behandling og drift. Hvilket alternativ som passer, blir først tydelig når hele veien fra inndata til lagret resultat er kjent.
Fastsett oppgaven og datagrensen
Et fiktivt programvareselskap vil oppsummere interne notater i prosjektportalen sin. En person får bare lese notater fra prosjektet vedkommende har tilgang til, og kontrollerer utkastet før det lagres. Modellen får ikke i oppgave å sende meldinger eller endre prosjekttilganger.
For eksempelprosjektet P-72 gjelder en intern regel: Ubehandlede kundenotater skal ikke sendes til eksterne behandlingstjenester. Dette er en forutsetning i eksemplet. Den erstatter ikke en vurdering av selskapets faktiske data og krav.
Sammenlign hele dataflyten
Tabellen beskriver planlagte flyter, ikke en testet installasjon. «Egen modellserver» betyr her en server selskapet drifter innenfor det godkjente miljøet. En leid server kan også driftes av selskapet selv; det må avklares særskilt om den kan inngå i det godkjente miljøet. Plasseringen alene beskriver ikke oppgavefordelingen.
Trinn | Egen modellserver | Administrert modelltjeneste |
|---|---|---|
Inndata | Portalen kontrollerer prosjekttilgang og leser det valgte notatet. | Portalen kontrollerer samme tilgang og leser samme notat. |
Notatet går til den interne modelltjenesten. | Notatet ville gått til leverandøren; blokkert av eksempelregelen. | |
Logger | Kontroller portal, proxy og feiltjeneste for tekstkopier. | Avklar også leverandørens behandling og logging. |
Avbrudd | Personen oppsummerer manuelt; ingen eksterne reservekall. | Personen oppsummerer manuelt; ingen overgang til en tjeneste som ikke er vurdert. |
Den planlagte driftsloggen inneholder for eksempel requestId og status, ikke hele notatet eller modellsvaret. Disse egne eksempelattributtene utgjør ikke en fullstendig sikkerhetslogg. Feilhåndtering, eksport til støttepersonell og sikkerhetskopier må også overholde den fastsatte datagrensen.
Undersøk kjøremiljøet som faktisk brukes
Ollamas FAQ skiller for eksempel mellom lokal behandling og skymodeller og beskriver hvordan skyfunksjoner slås av. Det gjelder det aktuelle kjøremiljøet. Et brukergrensesnitt, en utvidelse eller en separat feiltjeneste kan ha flere forbindelser. Navnet på det installerte programmet dokumenterer derfor ikke hele dataflyten.
Undersøk i et godkjent pilotoppsett hvilke mål som brukes, innholdet i loggene som oppstår, og forløpet ved avbrudd. En liste over nettverksmål dokumenterer verken innholdet i krypterte overføringer eller lagringen hos leverandøren. For en ekstern tjeneste trenger du også konkrete opplysninger om behandling og lagring; en generell påstand om skyen er ikke nok.
Vurder drift og egnethet sammen
For en egen modellserver må noen ha ansvar for oppdateringer, tilgang, kapasitet, overvåking og gjenoppretting. Med en modelltjeneste står leverandøren for den avtalte modelldriften; portaltilganger, integrasjon og egne logger er fortsatt teamets oppgaver. Sammenlign først begge med de samme syntetiske inndataene og forventede resultatene. Dette godkjenner ikke behandling av virkelige kundenotater. Kvalitet og ventetider ved den nødvendige belastningen fastsettes i piloten, ikke ut fra plasseringen.
Etter eksempelregelen er det eksterne modellkallet ennå ikke godkjent. Egen server er et alternativ når dataflyt, resultatkvalitet og drift er undersøkt. Uten et ansvarlig driftsteam er heller ikke dette alternativet klart til bruk. En annen dataklasse eller godkjenning av en konkret ekstern dataflyt kan endre beslutningen.
Kilder
Les videre
Alle artikler
KI og automatisering med ASES
KI-assistenter og automatiserte prosesser