Ferdigbygde mot tilpassede maskinlæringsmodeller?

Når er det bedre å bygge enn å kjøpe en ferdigbygd løsning?

Bedrifter kan engasjere seg i ulike tilnærminger til modellutvikling. Fra fullstendig håndterte ML-tjenester til tilpassede modeller. Avhengig av forretningskrav, tilgjengelig ekspertise og planleggingsbegrensninger, må de ta en beslutning: skal de utvikle tilpassede løsninger fra scratch? Eller skal de velge en ferdigbygd tjeneste?

For alle stadier av ML-arbeidsbelastninger, må en beslutning tas om hvordan de ulike puslebrikker skal passe sammen. Fra datainnsamling, forberedelse og visualisering, til feature-engineering, modelltrening og evaluering, spør maskinlæringsingeniører seg selv samme spørsmål: Vil det være en tilpasset implementert løsning, skrevet og utviklet fra scratch? Eller vil det være en ferdigbygd tjeneste?

Men når er bygging bedre enn å kjøpe en ferdigbygd løsning? De viktigste differensierende faktorene mellom de to tilnærmingene er: forbehandlingsinnsats, utviklingshastighet og den nødvendige ekspertisen.

Hva skal du bruke: en ferdigbygd eller en tilpasset maskinlæringsmodell?

Forbehandlingsinnsats

ML-prosjekter møter alle slags utfordringer, men kanskje den største utfordringen er tilgjengeligheten av treningdata. Mangel på treningdata kan stoppe et prosjekt før det ennå har startet. Før et prosjekt ennå har startet, kan det møte betydelige forbehandlingskostnader fra datainnsamling, dataetikettering, rensing og forbehandling. Dette er den velkjente fella hvor mange ML-prosjekter feiler: forbehandling ender opp med å ta 80% av de ressurser som er tildelt, mens få ressurser er igjen for den faktiske modelltreningen og evalueringen.

Ferdigbygde løsninger lettet belastningene og smertene ved forbehandlingsinnsats. De er bygget for å utføre de vanligste operasjonene med bare litt konfigurasjon nødvendig. Det beste med dem er: ferdigbygde løsninger finnes for alle stadier av ML-arbeidsbelastninger.

På den andre siden, krever tilpassede implementeringer vanligvis mer forbehandlingsinnsats. Det betyr ikke at de må forkastes helt: de er fortsatt nødvendige for å finjustere en bestemt ML-fase til de spesifikke problemene som løses. En særlig skitten datasett kan kreve noen spesielle rensingsregler. Samtidig kan en bestemt funksjonssett kreve tilpasset funksjonsutvikling, likeledes kan neurale arkitekturer kreve små justeringer. I dette tilfelle er tilpassede løsninger bygget fra scratch sannsynligvis å dekke alle behov.

Utviklingshastighet

Ferdigbygde løsninger fokuserer på konfigurasjon fremfor implementering. I stedet for å allokere ressurser til å finne ut hva som skal gjøres, vil ML-teamene fokusere på hvordan de ulike puslebrikker skal passe sammen. Denne tilnærmingen gjør det mulig for bedrifter, forskere og ingeniører å raskt implementere prototyper og beviser. I stedet for å finne opp hjulet på nytt, gjør ferdigbygde løsninger det mulig å utnytte eksisterende kunnskap, og dermed spare utviklingstid.

Tilpassede løsninger implementert fra scratch er kjent for å være mye langsommere når det gjelder utviklingshastighet. Dette skyldes deres økte vedlikeholdsbehov: ingeniører må finne ut både hva og hvordan av løsningen. Likedan, jo mer kompleks løsningen er, jo mer tid og ressurser er nødvendig for å sikre dens skalerbarhet og tilgjengelighet mens den er i produksjon. Fra dette perspektivet er tilpassede løsninger og tidinnsats direkte proporsjonale: jo mer kompleks en løsning er, jo mer tid vil den kreve.

Vanligvis, likevel, er sannheten et sted midt imellom: en eksisterende kodebase vil bli refaktorert og tilpasset til prosjektets behov. Slik er tilfelle med den velkjente overføringslæringstilnærmingen til modelltrening.

Ekspertise

Liksom det finnes multiple lag på hvilke maskinlæring utføres, finnes det multiple nivåer av ekspertise på hvilke ML-modeller kan utvikles, fra kodefrie grensesnitt til bygging av modeller fra scratch.

Ferdigbygde løsninger finnes for hvilke svært lite maskinlærings-ekspertise er nødvendig. Ved å bruke intuitive grensesnitt og selv dra-og-slip-tilnærminger, har det blitt ekstremt enkelt for hvem som helst (fra forretningsanalytikere til programvareingeniører) å bygge og distribuere noen former for maskinlæringsmodell. Mens denne enkle tilnærmingen til modellutvikling kan fungere for prototyping-formål, er det usannsynlig å møte kravene til produksjonssystemer.

Ekspertise er fortsatt nødvendig for å konfigurere, sette opp og vedlikeholde ferdigbygde løsninger i produksjon. Workarounds, kode-patcher, kobling til ulike API-grensesnitt og håndtering av distribusjonsproblemer er vanlige oppgaver som kreves for å sikre modellenes ytelse i produksjonsmiljøer.

Tilpassede løsninger er vanligvis implementert på et infrastrukturnivå og det finnes ingen måte å gå rundt det: ekspertise er definitivt nødvendig. Avhengig av bedriftens størrelse og prosjektets mål, kan multidisiplinære team være nødvendige for å vedlikeholde produksjonssystemer. Dataforskere, ML-ingeniører og forretningsanalytikere kommer sammen for å gi mening til inferensresultater og vedlikeholde produksjonsmodeller.

Hva skal du bruke: en ferdigbygd eller en tilpasset maskinlæringsmodell?

En ML-løsning vil bestå av mange enkeltkomponenter og tjenester som må komme sammen som en samlet løsning. Det handler aldri om å gå 100% tilpasset eller 100% ferdigbygd, siden ulike forretningsproblemer krever ulike løsninger. Ofte er ML-baserte løsninger bygget av en blanding av de to: ferdigbygde tjenester for å trekke ut generelle innsikter, kombinert med tilpassede modeller for økt nøyaktighet og modellering av domenespesifikke kunnskaper.

Hemmeligheten er å vite når å implementere tilpassede løsninger fra scratch og hvilke deler av prosjektet kan utnytte fordelene med ferdigbygde tjenester. Dette avhenger sterkt av problemtype, forretningskrav, tilgjengelige data og de overordnede begrensningene i utviklingsmiljøet.

For mer om AI og teknologitrender, se Josh Miramant, CEO av Blue Orange Digitals data-drevne løsninger for forsyningskjede, helsevesen-dokumentautomatisering og mer.

Du kan også like:

Bruk NLP til å klassifisere kommentarer på sosiale medier

Hvordan språkbehandling forbedres gjennom Googles åpne kildekode-BERT-modell