Milloin meidän tulee testata noninferiority hypoteesia?

Milloin meidän tulee testata noninferiority hypoteesia?
Stitch Fix -tiimin artikkelissa ehdotetaan non-inferiority trials -lähestymistavan käyttöä markkinoinnissa ja tuotteiden A/B-testeissä. Tämä lähestymistapa todella pätee, kun testaamme uutta ratkaisua, jonka hyötyjä ei mitata testeillä.

Yksinkertaisin esimerkki on kustannusten vähentäminen. Automatisoimme esimerkiksi ensimmäisen oppitunnin osoittamisen, mutta emme halua merkittävästi vähentää päästä päähän -konversiota. Tai testaamme muutoksia, jotka on suunnattu yhdelle käyttäjäsegmentille, varmistaen samalla, että muiden segmenttien konversiot eivät putoa paljon (kun testaat useita hypoteeseja, älä unohda muutoksia).

Oikean non-inferiority marginaalin valitseminen lisää lisähaasteita testin suunnitteluvaiheessa. Kysymystä Δ:n valitsemisesta ei käsitellä kovin hyvin artikkelissa. Vaikuttaa siltä, ​​että tämä valinta ei ole täysin läpinäkyvä myöskään kliinisissä tutkimuksissa. Arvostelu lääketieteelliset julkaisut non-alempiarvoisuudesta kertovat, että vain puolet julkaisuista perustelee rajan valinnan, ja usein nämä perustelut ovat moniselitteisiä tai epätarkkoja.

Joka tapauksessa tämä lähestymistapa vaikuttaa mielenkiintoiselta, koska... pienentämällä vaadittua otoskokoa se voi nopeuttaa testausta ja siten päätöksentekonopeutta. — Daria Mukhina, Skyeng-mobiilisovelluksen tuoteanalyytikko.

Stitch Fix -tiimi rakastaa eri asioiden testaamista. Koko teknologiayhteisö rakastaa periaatteessa testaamista. Kumpi sivuston versio houkuttelee enemmän käyttäjiä - A vai B? Ansaitseeko suositusmallin versio A enemmän rahaa kuin versio B? Hypoteesien testaamiseen käytämme lähes aina tilaston peruskurssin yksinkertaisinta lähestymistapaa:

Milloin meidän tulee testata noninferiority hypoteesia?

Vaikka käytämme termiä harvoin, tätä testausmuotoa kutsutaan "ylihypoteesitestaukseksi". Tällä lähestymistavalla oletamme, että näiden kahden vaihtoehdon välillä ei ole eroa. Pysymme tässä ajatuksessa ja hylkäämme sen vain, jos tiedot ovat tarpeeksi vakuuttavia tehdäkseen niin – toisin sanoen se osoittaa, että yksi vaihtoehdoista (A tai B) on parempi kuin toinen.

Paremmuushypoteesin testaaminen sopii useisiin ongelmiin. Julkaisemme suositusmallin version B vain, jos se on selvästi parempi kuin jo käytössä oleva versio A. Mutta joissain tapauksissa tämä lähestymistapa ei toimi niin hyvin. Katsotaanpa muutamia esimerkkejä.

1) Käytämme kolmannen osapuolen palvelua, joka auttaa tunnistamaan väärennetyt pankkikortit. Löysimme toisen palvelun, joka maksaa huomattavasti vähemmän. Jos halvempi palvelu toimii yhtä hyvin kuin tällä hetkellä käytössämme, valitsemme sen. Sen ei tarvitse olla parempi kuin käyttämäsi palvelu.

2) Haluamme luopua tietolähteestä A ja korvaa se tietolähteellä B. Voimme viivyttää A:n hylkäämistä, jos B tuottaa erittäin huonoja tuloksia, mutta A:n käyttöä ei voida jatkaa.

3) Haluaisimme siirtyä mallintavasta lähestymistavastaA:n B:n lähestymistapa ei siksi, että odotamme B:ltä parempia tuloksia, vaan siksi, että se antaa meille enemmän toiminnallista joustavuutta. Meillä ei ole mitään syytä uskoa, että B olisi huonompi, mutta emme tee muutosta, jos näin on.

4) Olemme tehneet useita laadullisia muutoksia verkkosivuston suunnitteluun (versio B) ja uskomme, että tämä versio on parempi kuin versio A. Emme odota muutoksia konversioon tai mihinkään tärkeimmistä suoritusindikaattoreista, joiden perusteella arvioimme verkkosivustoa. Mutta uskomme, että parametreissa on etuja, jotka ovat joko mitattavissa tai teknologiamme ei riitä mittaamiseen.

Kaikissa näissä tapauksissa paremmuustutkimus ei ole sopivin ratkaisu. Mutta useimmat asiantuntijat tällaisissa tilanteissa käyttävät sitä oletuksena. Suoritamme kokeen huolellisesti määrittääksemme vaikutuksen koon oikein. Jos olisi totta, että versiot A ja B toimivat hyvin samalla tavalla, on mahdollista, että emme hylkäisi nollahypoteesia. Päättelemmekö, että A ja B toimivat periaatteessa samalla tavalla? Ei! Nollahypoteesin hylkäämättä jättäminen ja nollahypoteesin hyväksyminen eivät ole sama asia.

Otoskokolaskelmat (jotka tietysti olette tehneet) tehdään tyypillisesti tiukemmat rajat tyypin I virheelle (nollahypoteesin hylkäämisen todennäköisyys, jota usein kutsutaan alfaksi) kuin tyypin II virheelle (hylkäämisen epäonnistumisen todennäköisyys). nollahypoteesi, sillä edellytyksellä, että nollahypoteesi on väärä, jota kutsutaan usein beetaksi). Alfan tyypillinen arvo on 0,05, kun taas betan tyypillinen arvo on 0,20, mikä vastaa tilastollista potenssia 0,80. Tämä tarkoittaa, että on 20 %:n todennäköisyys, että jäämme paitsi teholaskelmissamme määrittämämme suuren todellisen vaikutuksen, mikä on varsin vakava tiedonpuute. Tarkastellaanpa esimerkkinä seuraavia hypoteeseja:

Milloin meidän tulee testata noninferiority hypoteesia?

H0: reppuni EI ole huoneessani (3)
H1: reppuni on huoneessani (4)

Jos etsin huonettani ja löysin reppuni, hienoa, voin hylätä nollahypoteesin. Mutta jos katselin ympärilleni huoneessa enkä löytänyt reppuani (kuva 1), mikä johtopäätös minun pitäisi tehdä? Olenko varma, ettei se ole siellä? Katsoinko tarpeeksi lujasti? Entä jos etsin vain 80 % huoneesta? Johtopäätös, että reppu ei todellakaan ole huoneessa, olisi hätiköity päätös. Ei ihme, että emme voi "hyväksyä nollahypoteesia".
Milloin meidän tulee testata noninferiority hypoteesia?
Alue, jota etsimme
Emme löytäneet reppua – pitäisikö meidän hyväksyä nollahypoteesi?

Kuva 1: Haku 80 % huoneesta on suunnilleen sama kuin etsiminen 80 % teholla. Jos et löydä reppua tutkittuasi 80 % huoneesta, voitko päätellä, ettei sitä ole siellä?

Mitä datatieteilijän pitäisi tehdä tässä tilanteessa? Voit lisätä tutkimuksen tehoa huomattavasti, mutta silloin tarvitset paljon suuremman otoskoon ja tulos on silti epätyydyttävä.

Onneksi tällaisia ​​ongelmia on tutkittu pitkään kliinisen tutkimuksen maailmassa. Lääke B on halvempi kuin lääke A; Lääke B:n odotetaan aiheuttavan vähemmän sivuvaikutuksia kuin lääke A; Lääke B on helpompi kuljettaa, koska sitä ei tarvitse jäähdyttää, mutta lääke A kyllä. Testataan hypoteesia ei-alempiarvoisuudesta. Tämä osoittaa, että versio B on yhtä hyvä kuin versio A – ainakin jonkin ennalta määritellyn ei-alempiarvoisen marginaalin Δ sisällä. Puhumme lisää tämän rajan asettamisesta hieman myöhemmin. Mutta nyt oletetaan, että tämä on pienin käytännössä merkityksellinen ero (kliinisissä kokeissa tätä kutsutaan yleensä kliiniseksi merkitykseksi).

Non-alempiarvoisuushypoteesit kääntävät kaiken päälaelleen:

Milloin meidän tulee testata noninferiority hypoteesia?

Nyt sen sijaan, että oletamme, että eroa ei ole, oletamme, että versio B on huonompi kuin versio A, ja pysymme tässä oletuksessa, kunnes osoitamme, että näin ei ole. Juuri tällä hetkellä on järkevää käyttää yksipuolista hypoteesitestausta! Käytännössä tämä voidaan tehdä rakentamalla luottamusväli ja määrittämällä, onko intervalli todella suurempi kuin Δ (kuva 2).
Milloin meidän tulee testata noninferiority hypoteesia?

Valitse Δ

Kuinka valita oikea Δ? Δ-valintaprosessi sisältää tilastollisen perustelun ja sisällön arvioinnin. Kliinisen tutkimuksen maailmassa on olemassa sääntelyohjeita, jotka määräävät, että delta-arvon tulee edustaa pienintä kliinisesti merkittävää eroa – eroa, joka muuttaa käytännössä. Tässä lainaus eurooppalaisista ohjeista testataksesi itsesi: ”Jos ero on valittu oikein, luottamusväli, joka on kokonaan –∆:n ja 0…n välillä, riittää silti osoittamaan, ettei se ole huonompi. Jos tämä tulos ei vaikuta hyväksyttävältä, se tarkoittaa, että ∆ ei ole valittu oikein.

Delta ei todellakaan saisi ylittää version A vaikutuskokoa suhteessa todelliseen kontrolliin (plasebo/ei hoitoa), koska tämä saa meidät sanomaan, että versio B on huonompi kuin todellinen kontrolli, mutta samalla osoittaa "ei-alempiarvoisuutta". .” Oletetaan, että kun versio A esiteltiin, se korvattiin versiolla 0 tai ominaisuutta ei ollut ollenkaan (katso kuva 3).

Ylivoimahypoteesin testauksen tulosten perusteella paljastui vaikutuskoko E (eli oletettavasti μ^A−μ^0=E). Nyt A on uusi standardimme, ja haluamme varmistaa, että B on yhtä hyvä kuin A. Toinen tapa kirjoittaa μB−μA≤−Δ (nollahypoteesi) on μB≤μA−Δ. Jos oletetaan, että do on yhtä suuri tai suurempi kuin E, niin μB ≤ μA−E ≤ lumelääke. Nyt näemme, että arviomme μB:lle ylittää täysin arvon μA−E, mikä hylkää täysin nollahypoteesin ja antaa meille mahdollisuuden päätellä, että B on yhtä hyvä kuin A, mutta samalla μB voi olla ≤ μ lumelääkettä, mikä ei ole tapaus mitä tarvitsemme. (Kuva 3).

Milloin meidän tulee testata noninferiority hypoteesia?
Kuva 3. Ei-inferiority marginaalin valinnan riskien havainnointi. Jos raja on liian korkea, voidaan päätellä, että B ei ole huonompi kuin A, mutta samalla ei erota lumelääkkeestä. Emme vaihda lääkettä, joka on selvästi lumelääkettä tehokkaampi (A), lääkkeeseen, joka on yhtä tehokas kuin lumelääke.

α:n valinta

Jatketaan α:n valintaa. Voit käyttää vakioarvoa α = 0,05, mutta tämä ei ole täysin reilua. Kuten esimerkiksi kun ostat jotain verkosta ja käytät useita alennuskoodeja kerralla, vaikka niitä ei pitäisikään yhdistää - kehittäjä teki vain virheen, ja sinä selvisit siitä. Sääntöjen mukaan α:n arvon tulee olla yhtä suuri kuin puolet paremmuushypoteesia testattaessa käytetystä α:n arvosta, eli 0,05 / 2 = 0,025.

Otoskoko

Kuinka arvioida otoskoko? Jos uskot, että todellinen keskimääräinen ero A:n ja B:n välillä on 0, otoskoon laskenta on sama kuin paremmuushypoteesia testattaessa, paitsi että vaihdat efektin koon non-inferiority-marginaalilla, jos käytät α ei huonompi hyötysuhde = 1/2α paremmuus (αei-alempi = 1/2αylempiarvoisuus). Jos sinulla on syytä uskoa, että vaihtoehto B saattaa olla hieman huonompi kuin vaihtoehto A, mutta haluat todistaa, että se on enintään Δ, niin olet onnekas! Tämä itse asiassa pienentää otoksen kokoa, koska on helpompi osoittaa, että B on huonompi kuin A, jos luulet sen olevan hieman huonompi kuin yhtä suuri.

Esimerkki ratkaisulla

Oletetaan, että haluat päivittää versioon B, jos se ei ole enempää kuin 0,1 pistettä huonompi kuin versio A 5-pisteen asiakastyytyväisyysasteikolla... Lähestytään tätä ongelmaa paremmuushypoteesin avulla.

Paremmuushypoteesin testaamiseksi laskemme otoskoon seuraavasti:

Milloin meidän tulee testata noninferiority hypoteesia?

Eli jos sinulla on ryhmässäsi 2103 havaintoa, voit olla 90 % varma, että löydät tehosteen koon 0,10 tai sitä suuremman. Mutta jos 0,10 on sinulle liian korkea, ei ehkä kannata testata paremmuushypoteesia. Varmuuden vuoksi saatat päättää suorittaa tutkimuksen pienemmälle vaikutuskoolle, kuten 0,05. Tässä tapauksessa tarvitset 8407 havaintoa, eli näyte kasvaa lähes 4 kertaa. Mutta entä jos pysyisimme alkuperäisessä otoskokossamme, mutta lisäisimme tehoa 0,99:ään, jotta olisimme turvassa, jos saamme positiivisen tuloksen? Tässä tapauksessa yhden ryhmän n on 3676, mikä on jo parempi, mutta lisää otoskokoa yli 50 %. Ja sen seurauksena emme yksinkertaisesti pysty kumoamaan nollahypoteesia, emmekä saa vastausta kysymykseemme.

Entä jos testaamme sen sijaan noninferiority hypoteesia?

Milloin meidän tulee testata noninferiority hypoteesia?

Otoskoko lasketaan käyttämällä samaa kaavaa nimittäjää lukuun ottamatta.
Erot paremmuushypoteesin testaamiseen käytetystä kaavasta ovat seuraavat:

— Z1−α/2 korvataan Z1−α:lla, mutta jos teet kaiken sääntöjen mukaan, korvaat α = 0,05 arvolla α = 0,025, eli se on sama luku (1,96)

— (μB−μA) näkyy nimittäjässä

— θ (efektin koko) korvataan Δ:llä (ei-alempi marginaali)

Jos oletetaan, että µB = µA, niin (µB − µA) = 0 ja otoskoon laskelma noninferiority-marginaalille on juuri se, mitä saisimme, jos laskettaisiin paremmuus efektin koolle 0,1, hienoa! Voimme tehdä samankokoisen tutkimuksen erilaisilla hypoteeseilla ja erilaisella lähestymistavalla johtopäätöksiin, ja saamme vastauksen kysymykseen, johon todella haluamme vastata.

Oletetaan nyt, että emme itse asiassa ajattele, että µB = µA ja
Mielestämme µB on hieman huonompi, ehkä 0,01 yksikköä. Tämä kasvattaa nimittäjäämme ja pienentää ryhmäkohtaisen otoskoon 1737 XNUMX:ään.

Mitä tapahtuu, jos versio B on todella parempi kuin versio A? Hylkäämme nollahypoteesin, jonka mukaan B on huonompi kuin A enemmän kuin Δ, ja hyväksymme vaihtoehtoisen hypoteesin, että B, jos huonompi, ei ole huonompi kuin A Δ:llä ja voi olla parempi. Yritä laittaa tämä johtopäätös poikkitoiminnalliseen esitykseen ja katso mitä tapahtuu (vakavasti, kokeile sitä). Tulevaisuuteen katsovassa tilanteessa kukaan ei halua tyytyä "enintään Δ huonompaan ja ehkä parempaan".

Tässä tapauksessa voimme suorittaa tutkimuksen, jota kutsutaan hyvin lyhyesti "hypoteesin testaamiseksi, että yksi vaihtoehdoista on parempi tai huonompi kuin toinen". Se käyttää kahta hypoteesisarjaa:

Ensimmäinen sarja (sama kuin ei-alempiarvoisuushypoteesin testaus):

Milloin meidän tulee testata noninferiority hypoteesia?

Toinen sarja (sama kuin paremmuushypoteesia testattaessa):

Milloin meidän tulee testata noninferiority hypoteesia?

Testaamme toista hypoteesia vain, jos ensimmäinen hylätään. Kun testaamme peräkkäin, säilytämme tyypin I kokonaisvirhesuhteen (α). Käytännössä tämä voidaan saavuttaa luomalla 95 %:n luottamusväli keskiarvojen väliselle erolle ja testaamalla, onko koko intervalli suurempi kuin -A. Jos väli ei ylitä -Δ, emme voi hylätä nolla-arvoa ja lopettaa. Jos koko väli on todellakin suurempi kuin −Δ, jatkamme ja katsomme sisältääkö väli 0.

On olemassa toinen tutkimustyyppi, jota emme ole keskustelleet - vastaavuustutkimukset.

Tämäntyyppiset tutkimukset voidaan korvata ei-alempiarvoisuustutkimuksilla ja päinvastoin, mutta niillä on itse asiassa tärkeä ero. Ei-alempiarvoisuuskokeella pyritään osoittamaan, että vaihtoehto B on vähintään yhtä hyvä kuin A. Ekvivalenssikokeella pyritään osoittamaan, että vaihtoehto B on vähintään yhtä hyvä kuin A. Vaihtoehto A on yhtä hyvä kuin B, mikä on vaikeampaa. Pohjimmiltaan yritämme määrittää, onko koko keskiarvoeron luottamusväli -Δ ja Δ välillä. Tällaiset tutkimukset vaativat suuremman otoskoon ja niitä tehdään harvemmin. Joten kun seuraavan kerran suoritat tutkimuksen, jossa päätavoitteesi on varmistaa, että uusi versio ei ole huonompi, älä tyydy "nollahypoteesin hylkäämisen epäonnistumiseen". Jos haluat testata todella tärkeän hypoteesin, harkitse erilaisia ​​vaihtoehtoja.

Lähde: will.com

Lisää kommentti