Tuote- ja datavalmiuden kehikko, jolla arvioit suositusten arvon, vastuullisen mittaamisen ja luotettavan tuotantokäytön edellytykset.
Aloita käyttäjän valinnasta, jota suosituksen pitää parantaa
Suosittelujärjestelmä on hyödyllinen, kun se auttaa ihmistä valitsemaan olennaisen vaihtoehtojen joukosta, jota on muuten vaikea hahmottaa. Ensimmäinen kysymys ei ole algoritmi. Kysy, kenen päätös paranee, missä hetkessä ja mitä hyvä tulos tarkoittaa käyttäjälle sekä organisaatiolle.
Rajaa päätöspinta tarkasti: järjestetty etusivu, seuraava paras toimenpide, liittyvä sisältö, haun uudelleenjärjestys tai ilmoitus. Jokaisella pinnalla on omat viiveen, selitettävyyden, monipuolisuuden ja tuoreuden vaatimukset. “Personoidaan palvelu” on liian laaja tavoite suunniteltavaksi tai arvioitavaksi. Rajattu pinta mahdollistaa vertailun järkevään perusratkaisuun.
Suojaa käyttäjän toimijuus. Päätä, miten käyttäjä voi ymmärtää, ohittaa tai ohjata suosituksia ja mitä valintoja ei pidä automatisoida tai personoida. Vaikutuksiltaan merkittävissä tilanteissa relevanssi ei yksin riitä, vaan oikeudenmukaisuus, yksityisyys, saavutettavuus ja väärän suosituksen hinta vaikuttavat tuotepäätökseen.
Kirjaa myös nimenomainen ei-tavoite. Järjestelmä voi tukea löytämistä päättelemättä arkaluonteista ominaisuutta, parantaa tehtävän valmistumista maksimoimatta palvelussa vietettyä aikaa tai auttaa ammattilaista korvaamatta hänen harkintaansa. Ei-tavoite estää myöhempää mittaripainetta muuttamasta järjestelmän tarkoitusta huomaamatta. Katselmoi rajaus aina, kun käyttötilanne, käyttäjäryhmä tai datalähde muuttuu. Kerro rajaus myös analytiikka- ja markkinointitiimeille, jotta rinnakkaiset kokeet eivät vahingossa ohita samaa periaatetta. Tallenna hyväksytty versio yhteiseen tuotedokumentaatioon.
Osoita, että data kuvaa päätöstilannetta
Suositteludata yhdistää yleensä käyttäjän tai tilanteen, suositeltavat kohteet ja vuorovaikutukset. Datan olemassaolo ei tarkoita soveltuvuutta. Vuorovaikutus voi kuvata näkyvyyttä mieltymyksen sijaan: klikkaus voi johtua näkyvästä sijoittelusta ja klikkaamatta jääminen siitä, ettei kohdetta nähty. Historia sisältää myös aiemman valikoiman, säännöt ja käyttöliittymäpäätökset.
Tee datakartta, joka kuvaa jokaiselle piirteelle ja tavoitteelle käyttötarkoituksen, lähteen, omistajan, käsittelyperusteen, päivitystiheyden, säilytyksen, laatutarkistukset ja tunnetut vinoumat. Mittaa valikoiman kattavuus ja vuorovaikutusten harvuus. Päätä, miten uusi käyttäjä ja uusi kohde saavat hyödyllisen tuloksen ennen historiatietoa. Kylmäkäynnistys on tuotevaatimus, ei mallitiimin reunatapaus.
Tutki suositeltavien kohteiden data yhtä tarkasti kuin käyttäjädata. Puuttuvat luokat, epäyhtenäiset metatiedot ja viivästynyt saatavuus voivat tehdä hyvästä kohteesta näkymättömän. Sovi valikoiman laatuehdot ja korjausprosessi sitä tuottavien tai ylläpitävien tiimien kanssa. Malli ei pysty luotettavasti korvaamaan hallitsematonta valikoimaa.
Minimoi data sen sijaan, että keräät kaikki mahdolliset signaalit. Arkaluonteiset tai niitä korvaavat piirteet voivat luoda riskejä, vaikka ne parantaisivat testimittaria. Arvioi, saadaanko sama arvo vähemmällä henkilötiedolla, lyhyemmällä säilytyksellä tai koosteilla. Dokumentoi, mitä malli ei saa päätellä tai optimoida.
- Käyttäjillä tai tilanteilla, kohteilla ja vuorovaikutuksilla on selkeät omistajat.
- Näkyvyysvinouma, puuttuva data ja aiempien sääntöjen vaikutus tunnetaan.
- Uuden käyttäjän ja kohteen toiminta suunnitellaan erikseen.
- Datan käytöllä on määritetty tarkoitus, käsittelyperuste ja säilytysaika.
- Arkaluonteiset piirteet ja mahdolliset sijaismuuttujat arvioidaan riskien kannalta.
Määritä arvo ja suojarajat eri mittareina
Yhden sitoutumismittarin optimointi voi tuottaa tarkan mutta hyödyttömän järjestelmän. Määritä ensisijainen tuotetulos, kuten onnistunut sisällön löytyminen tai tehtävän eteneminen, sekä suojarajat monipuolisuudelle, kattavuudelle, uutuudelle, käyttäjän hallinnalle, palautteille, viiveelle ja liiketoimintasäännöille. Kirjaa aikajänne, sillä välitön klikkaus voi heikentää pitkäaikaista tyytyväisyyttä.
Offline-arviointi testaa, miten malli järjestää historiasta erotetun aineiston. Se on nopea ja toistettava, mutta ei todista syy-yhteyttä elävässä palvelussa. Verkkokoe mittaa toimintaa oikeassa tilanteessa, mutta vaatii turvallisen koesuunnitelman, riittävän liikenteen ja ennalta sovitut keskeytysehdot. Laadullinen tutkimus selittää, miksi ihmiset hyväksyvät, ohittavat tai epäilevät suosituksia.
Yhdistä kaikki kolme näyttömuotoa. Vertaa yksinkertaisiin perustasoihin, kuten suosituimpiin, uusimpiin, toimituksellisiin sääntöihin tai personoimattomaan järjestykseen. Monimutkaisemman mallin pitää ansaita operointikustannuksensa merkittävällä parannuksella suojarajoja rikkomatta.
Tarkastele ryhmiä ennen keskiarvon hyväksymistä. Uudet ja palaavat käyttäjät, harvat ja aktiiviset kategoriat tai eri laiteympäristöt voivat kokea järjestyksen eri tavoin. Valitse ryhmät tuoteriskin perusteella, ei siksi, että jatkuva tulosten pilkkominen tuottaisi lopulta mieluisan luvun. Kirjaa myös ne ryhmät, joille näyttö ei vielä riitä.
Suunnittele suosittelupalvelu, ei muistikirjaa
Malli tuottaa arvoa vasta, kun ympäröivä palvelu pystyy tuomaan tuoreet ehdokkaat, soveltamaan säännöt, vastaamaan käyttöliittymän viivebudjetissa ja palautumaan häiriöstä. Määritä ehdokkaiden muodostus, järjestäminen, suodatus, varatoiminta, välimuisti ja selitysvastuut. Päätä, mitkä säännöt säilyvät deterministisinä mallin ulkopuolella.
Rakenna jäljitettävyys näytetystä suosituksesta sen tuottaneeseen malliversioon, piirredataversioon, ehdokasjoukkoon ja sääntösuodattimiin. Valvo syötedatan muutosta, valikoiman muutoksia, pistejakaumaa, kattavuutta, viivettä ja tuotetuloksia. Havainnoinnin pitää erottaa mallivirhe vanhentuneesta datasta, rikkoutuneesta piirrejärjestelmästä ja käyttöliittymäintegraatiosta.
Suunnittele heikennetty toiminta ennen julkaisua. Kun piirteet viivästyvät, mallipalvelu ei vastaa tai turvaraja ylittyy, tarjoa testattu perustaso tyhjän tai arvaamattoman kokemuksen sijaan. Nimeä operointivastuu ja määritä häiriönhallinta, palautus sekä mallin käytöstä poisto.
Hallitse koulutus ja julkaisu erillisinä vaiheina. Onnistunut putkiajo ei saa automaattisesti tehdä mallista tuotannon päätöksentekijää. Vaadi arviointinäyttö, versioitu hyväksyntä ja riskiin sopiva asteittainen käyttöönotto. Säilytä edellinen malli ja perustaso, kunnes palautuminen on testattu oikeassa palvelupolussa.
Toteuta rajattu pilotti, joka vastaa päätökseen
Hyödyllinen pilotti ei ole tuotantoalustan pienoismalli. Se on edullisin koe, joka ratkaisee suurimman epävarmuuden. Jos riski on datan kattavuus, tee data-auditointi ja perustaso. Jos riski on käyttäjän luottamus, prototypoi selitykset ja hallintakeinot käyttäjien kanssa. Jos riski on verkkopalvelun arvo, integroi yksi pinta hallittuun kokeeseen ja turvalliseen varatoimintaan.
Päätä ennen aloitusta mahdolliset lopputulokset: laajenna, muuta tai lopeta. Anna kullekin näyttökynnykset ja suojarajat. Säilytä koemäärittely, dataikkunat, koodi, malliaineistot ja tulokset katselmoitavina. Älä esitä offline-tarkkuuden parannusta tuotannon liiketoimintatapauksena.
Kokenut data scientist voi nopeuttaa ongelman rajaamista, arvioinnin suunnittelua ja siirtymää Python- tai SQL-analyysistä hallittuun pilvipalveluun. Organisaatio tarvitsee silti tuote-, data-, kehitys-, laki- ja operointiomistajat. Suositusten laatu on monialainen tuotevastuu, ei lopussa luovutettava malli.
Sisällytä liiketoimintatapaukseen lopettamisvaihtoehto. Jos perustaso toimii riittävän hyvin, datariski säilyy suurena tai käyttäjätutkimus torjuu kokemuksen, lopettaminen voi olla vastuullinen tulos. Pilotti on tuottanut arvoa, kun se mahdollistaa hyvän päätöksen, vaikka päätös olisi olla laajentamatta koneoppimista.
Seitsemän päätöstä valmiusportilla
Vastaa kysymyksiin ennen sitoutumista täyteen suosittelualustaan. Kielteinen vastaus voi johtaa selvitystyöhön tai yksinkertaisempaan tuoteratkaisuun. Sitä ei pidä piilottaa mallikehityksen työarvioon.
- Mikä käyttäjän valinta ja tuotepinta paranee?
- Mikä yksinkertainen perustaso järjestelmän pitää voittaa?
- Kuvaako käytettävä data mieltymystä eikä vain näkyvyyttä?
- Miten kylmäkäynnistys, yksityisyys ja arkaluonteiset sijaismuuttujat käsitellään?
- Mitkä arvomittari ja suojarajat ratkaisevat onnistumisen?
- Voidaanko jokainen suositus havaita, selittää ja korvata turvallisesti perustasolla?
- Kuka omistaa tuotteen, datan, malliriskin ja tuotanto-operaation julkaisun jälkeen?