Miksi toistettavuus on tärkeämpää kuin demot
Toinen ajokerta on totuus
Ensimmäinen ajokerta sai aplodit. Malli löysi kohdan, kojelauta syttyi, vastaus viittasi oikeaan asiakirjaan, ja huone rentoutui täsmälleen sillä tavalla kuin huoneet rentoutuvat, kun budjettirivi on juuri tullut helpommaksi puolustaa. Tiimi oli harjoitellut huolellisesti. Data oli riittävän puhdasta, kysymykset järkeviä, verkko käyttäytyi, toimittajan kannettava ei ollut päättänyt muuttua pieneksi patteriksi, eikä kukaan kysynyt siitä yhdestä reunatapauksesta, joka oli siististi siirretty myöhempään vaiheeseen. Se oli hyvä demo. Hyvät demot ovat hyödyllisiä. Ne osoittavat mahdollisuuksia. Ne antavat ihmisille yhteisen asian, josta keskustella. Ne tekevät abstraktista kyvykkyydestä näkyvän.
Sitten tuli toinen ajokerta. Sama käyttötapaus, mutta nyt viime viikon datalla, eri käyttäjällä, lähdeasiakirjalla, jossa oli outo taulukko, päivityksellä, joka ei ollut ehtinyt kehotteeseen, ja esimiehellä, joka seurasi, koska tulos muokkaisi todellista päätöstä. Vastaus oli edelleen sujuva. Se ei ollut ongelma. Ongelma oli, ettei kukaan osannut sanoa, oliko se sama vastaus samoista syistä vai eri vastaus samassa sävyssä. Demo oli osoittanut, että järjestelmä pystyi suoriutumaan. Se ei ollut osoittanut, että organisaatio pystyisi toistamaan suorituksen.
Tässä vakava tekoälytyö muuttaa luonnettaan. Demo kysyy, pystymmekö saamaan sen toimimaan kerran. Operatiivinen toiminta kysyy, pystymmekö saamaan sen toimimaan uudelleen, selittämään, miksi se toimi, tietämään, milloin se ei toiminut, ja säilyttämään todisteet, kun joku kysyy kuuden kuukauden kuluttua. Toistettavuus ei ole innovaation vastakohta. Se on se osa innovaatiota, joka selviää kosketuksesta palkanmaksun, lain, turvallisuuden, asiakkaiden, kansalaisten, tilintarkastajien, väsyneen henkilöstön ja oikean datan hiljaisen vihamielisyyden kanssa.
Useimmat tekoälyn operatiivisen toiminnan epäonnistumiset eivät saavu elokuvallisena romahduksena. Ne saapuvat pieninä eroina, joita kukaan ei pysty toistamaan. Hakutulos muuttuu. Kehotepäivitys korjaa yhden tapauksen ja heikentää toista. Mallipäivitys siirtää päätösrajaa. Lähdesyöte pudottaa kentän. Ihmisen tekemä ohitus kirjataan yhteen järjestelmään, mutta ei toiseen. Organisaatiolla on edelleen toimiva järjestelmä teatterillisessa mielessä. Sillä ei ole enää järjestelmää, joka pystyisi kertomaan saman tarinan kahdesti.
Demo piilottaa tylsän sopimuksen
Demolle saa olla valikoiva. Sillä on tarina, alku, tyydyttävä klikkaus ja yleensä esimerkkidatasetti, joka on harottu kuin lapsi ennen koulukuvia. Se ei ole huijaamista. Se on viestintää. Ongelmat alkavat, kun organisaatio luulee viestintää käyttösopimukseksi. Demo ei määrittele lähdetietojen tuoreutta, versiorajoja, varapolkuja, ihmisen tarkistusoikeuksia, virheilmoitusten kieltä, säilytysaikoja tai tarkkaa ehtoa, jolla järjestelmän on kieltäydyttävä vastaamasta. Nämä yksityiskohdat ovat usein aivan ruudun ulkopuolella, vanhanaikaisen näköisinä, odottamassa että saavat laskuttaa kaikkia myöhemmin.
Toistettavuus tekee sopimuksesta näkyvän. Se kysyy, mikä syöte on se syöte, ei lähin kopio. Se kysyy, minkä sääntöversion mukaan vastaus rajattiin, ei sitä, mikä käytäntösivu näytti tutulta. Se kysyy, onko hakujärjestys vakaa, käsitelläänkö tasapelit deterministisesti, onko kehotteet versioitu, voidaanko malliparametrit nimetä, tallennetaanko työkalujen kutsut, voiko käyttäjä toistaa tapauksen ja muuttaako ohitus työnkulkua vai vain koristaako lokia. Nämä eivät ole filosofisia kysymyksiä. Ne ovat luotettavan työn taustajohdotus.
Vaikeinta on, että toistettavuus tuntuu aluksi hitaammalta. Tiimi, joka jahtaa demoa, voi kulkea nopeinta reittiä puutarhan läpi. Tiimi, joka rakentaa toistettavuutta, joutuu laskemaan kivetyksen, merkitsemään portit ja päättämään, kuka omistaa varaston avaimen. Tämä voi näyttää byrokraattiselta niistä, jotka näkevät vain ensimmäisen viikon. Kolmannen häiriön kohdalla se alkaa näyttää armolliselta.
AI-järjestelmät lisäävät tämän armollisuuden tarvetta, koska ne tuovat mukanaan hyväksyttävää vaihtelua. Kielimalleja voidaan otantaa. Haulla voi nousta esiin läheisiä ehdokkaita. Ihmisen harkinta voi erota. Dokumentit voivat olla monitulkintaisia. Toistettava järjestelmä ei teeskentele, että maailma olisi kaikilta osin deterministinen. Se erottaa sallitun vaihtelun hallitsemattomasta vaihtelusta. Se sanoo, että tämä kenttä saa vaihdella, koska käyttäjä kysyy luonnollisella kielellä, mutta tämä lähdejoukko ei saa vaihdella ilman kirjattua korpusmuutosta. Tämä yhteenvedon sanamuoto voi erota, mutta kelpoisuusperuste ei saa. Tämä pistemäärä voi muuttua mallipäivityksen jälkeen, mutta päivityksen on oltava jäljitettävissä.
Sama syöte ei ole yksinkertainen ilmaus
Ihmiset sanovat sama syöte kuin ilmaus olisi itsestään selvä. Oikeissa järjestelmissä se on harvoin itsestään selvää. Näkyvä käyttäjän kysymys on vain yksi osa. Varsinainen syöte voi sisältää haettuja dokumentteja, piilotettuja ohjeita, järjestelmäkehotteita, työkalujen skeemoja, käytäntösääntöjä, käyttäjäroolin, ajan, lokalen, käyttöoikeudet, välimuistissa olevat tietueet, ominaisuusliput, malliversion, upotusindeksin, kynnysasetukset ja hiljaisen oletuksen, että eilinen tietovaraston päivitys onnistui. Sama syöte voi muuttua yllättävän täydeksi huoneeksi.
Siksi toistettavuus alkaa syötteen identiteetistä. Järjestelmän pitäisi tietää, mitkä tietueet olivat saatavilla, mitkä tietueet valittiin, mitä korpusversiota haettiin, mitä kehotepohjaa käytettiin, mitä käytäntöjoukkoa sovellettiin, mikä malli suoritettiin, mitkä työkalut olivat sallittuja ja mikä ihmisrooli hyväksyi tuloksen. Jos se kuulostaa paljolta, se johtuu siitä, että päätöspolku oli jo valmiiksi suuri. Ainoa kysymys on, myöntääkö organisaatio sen.
Erolla on eniten merkitystä, kun tuloksista kiistellään. Jos asiakas kysyy, miksi korvausvaatimus hylättiin, sairaala kysyy, miksi riskilippu ilmestyi, pankki kysyy, miksi tapaus eteni, tai julkinen virasto kysyy, miksi kansalainen sai tietyn ohjeen, organisaatio ei voi vastata pelkällä näkyvällä kysymyksellä. Se tarvitsee toimintaympäristön. Ilman sitä häiriön selvittämisestä tulee kohtelias istunto, jossa kaikki kutsuvat esiin lokit, muistin ja kuvakaappaukset ja teeskentelevät, että tämä on menetelmä.
Syötteen identiteetti suojaa myös tiimejä aiheettomalta syytökseltä. Jos tulos muuttui, koska lähdeasiakirja muuttui, kyse on sisältöongelmasta. Jos se muuttui, koska indeksi rakennettiin uudelleen eri parametreilla, kyse on hakemisongelmasta. Jos se muuttui, koska mallia päivitettiin, kyse on käyttöönotto-ongelmasta. Jos se muuttui, koska käyttäjä käytti eri työnkulkua, kyse on prosessiongelmasta. Kaikkien näiden kutsuminen mallin käyttäytymiseksi on kätevää ja väärin, vahva yhdistelmä organisaatioissa, joissa kalenterit ovat täynnä.
Toistettavuus ei tarkoita kaiken jäädyttämistä
On olemassa laiska vastaväite, jonka mukaan toistettavuus tappaa sopeutumisen. Se ei tapa sitä. Se tappaa mysteerin. Toistettava toiminta voi silti parantaa malleja, muuttaa kehotteita, päivittää sääntöjä, siivota dataa, lisätä lähteitä, virittää kynnysarvoja ja suunnitella työnkulkuja uudelleen. Ero on siinä, että muutoksista tulee nimettyjä tapahtumia sään sijaan. Kun tulos liikkuu, tiimi voi kysyä, mikä hallittu muutos sai sen liikkumaan. Näin parantamisesta tulee oppimista eikä taikauskoa julkaisutiedotteen kera.
Parhaat toimintatiimit kohtelevat muutoksia kokeiluina, joilla on rajat. Ne pitävät perustapaukset. Ne ajavat varjoevaluaatioita. Ne vertaavat vanhoja ja uusia hakutuotoksia. Ne tarkistavat suuren vaikutuksen esimerkit ennen käyttöönottoa. Ne kirjaavat, kuka hyväksyi muutoksen ja miksi. Ne määrittelevät palautusehdot ennen käynnistyspuhelua, eivät silloin kun tukikanava hehkuu. Tämä ei ole teatraalista varovaisuutta. Näin tiimit liikkuvat nopeammin, kun ensimmäisellä järjestelmällä on merkitystä.
On myös moraalinen ulottuvuus, vaikka se on parempi ilmaista suoraan. Jos järjestelmä vaikuttaa rahaan, työhön, hoivaan, prioriteetteihin, täytäntöönpanoon tai pääsyyn, siitä kärsivät ansaitsevat enemmän kuin esityksen. He ansaitsevat prosessin, joka osaa selittää itsensä. Toistettavuus luo edellytyksen sille selitykselle. Katoavaa temppua ei voi auditoida. Sitä voi vain taputtaa tai valittaa.
Hyvä toistettavuus erottaa siksi vakaan joustavasta. Vakaita ovat tallenteet siitä, mitä tapahtui, versiotunnisteet, arviointijoukko, lähdeperimä, säännön omistaja, hyväksyntäpolku ja kieltäytymisehdot. Joustavia ovat tekniikat, joilla parannetaan näiden rajojen sisällä. Taito on tietää, kumpi on kumpi. Monet organisaatiot kääntävät ne toisin päin. Ne jäädyttävät prosessin, koska kukaan ei luota järjestelmään, ja sallivat sitten piilotetut tekniset muutokset, koska kukaan ei näe niitä. Se on hallintaa verhokaihtimen takaa.
Arviointijoukko on työmuisti
Jokainen kypsä toiminta tarvitsee pienen joukon tapauksia, joita se ei suostu unohtamaan. Ei synteettistä vertailuaineistoa, joka on valittu siksi, että se näyttää vaikuttavalta raportissa, vaan elävä arviointijoukko, joka on koottu niistä hankalista tapauksista, jotka opettivat tiimille jotakin. Asiakirja, jossa päivämäärät ovat ristiriidassa. Asiakaspyyntö, joka yhdistää kaksi käytäntöä. Lasku, jossa taulukon erottelu melkein toimii. Sairauskertomus, jossa on moniselitteisiä lyhenteitä. Hankintatapaus, jossa oikeusperusta merkitsee enemmän kuin ilmeinen vastaus. Näistä tapauksista tulee organisaation muisti.
Toistettava järjestelmä ajaa nämä tapaukset, kun jokin muuttuu. Tavoitteena ei ole palvoa vanhoja tulosteita. Joskus vanha tulos oli väärä. Tavoitteena on ymmärtää liikettä. Paransiko uusi versio tapausta oikeasta syystä. Rikkoiko se hauraan mutta tärkeän toiminnon. Tuliko siitä varmempi samalla kun se menetti todisteita. Valitsiko se eri lähteen. Tuottiko se saman johtopäätöksen heikomman polun kautta. Vakavassa työssä polku merkitsee, koska sama vastaus väärästä syystä ei ole sama vastaus.
Tässä monet demovetoiset ohjelmat menettävät hallinnan. Ne mittaavat käyttäjätyytyväisyyttä, viivettä ja laajaa tarkkuutta, mutta ne eivät pidä kipeitä tapauksia lähellä. Tuloksena on järjestelmä, joka voi näyttää kokonaisuutena paremmalta, mutta joka huononee merkityksellisillä reunamilla. Keskiarvot ovat hyödyllisiä. Reunat ovat sitä, missä valitus saapuu liitteiden kanssa.
Arviointijoukon pitäisi sisältää myös kieltäytymistapaukset. Järjestelmä, joka vastaa aina, ei ole hyödyllinen. Se on tarpeeton. Toistettavuus edellyttää, että järjestelmä kieltäytyy johdonmukaisesti, kun lähteet puuttuvat, toimivaltaa ei ole, luottamus on liian heikko, käyttäjä kysyy roolinsa ulkopuolelta tai tehtävä edellyttää ihmisen päätöstä. Kieltäytymiskäyttäytyminen on osa laatua. Selkeä ei on usein arvokkaampi kuin viehättävä ehkä, joka on puettu varmuudeksi.
Ihmisen arvioinnin on oltava myös toistettavaa
Toistettavuus ei ole vain koneiden ominaisuus. Myös ihmisen vaiheiden on oltava toistettavia. Jos yksi arvioija kohtelee mallin tulosta luonnoksena, toinen päätöksenä ja kolmas ärsyttävänä kollegana, työnkulku ajautuu riippumatta siitä, kuinka vakaa malli on. Organisaation on määriteltävä, mitä arviointi tarkoittaa. Varmistaako ihminen lähteet, tarkistaako hän käytännön, otantaako hän todisteita, hyväksyykö hän, muokkaako hän kieltä vai omistaako hän johtopäätöksen. Jokainen verbi luo erilaisen velvollisuuden.
Käyttäjät tarvitsevat käyttöliittymiä, jotka tukevat näitä velvollisuuksia. Jos heidän on varmistettava lähteet, lähteiden on oltava näkyvissä. Jos heidän on tarkistettava käytäntö, sääntöperustan on oltava tuloksen lähellä. Jos heidän on ohitettava tulos, ohituspolun on oltava normaali, ei piilotettu painikkeen taakse, joka tuntuu maanpetoksen tunnustamiselta. Jos heidän on selitettävä päätös myöhemmin, järjestelmän on säilytettävä se, mitä he näkivät silloin. Muuten ihmisen valvonnasta tulee koristeellinen ilmaus, johon on liitetty työntekijätunnus.
Myös koulutus merkitsee, mutta ei sellainen, joka opettaa ihmisiä ihailemaan järjestelmää. Hyödyllinen koulutus näyttää rajat. Se antaa arvioijille esimerkkejä vahvoista tuloksista, heikoista tuloksista, puuttuvista todisteista, vanhentuneista lähteistä, prompt injection -hyökkäyksistä, käytäntöristiriidoista ja tapauksista, joissa malli pitäisi ohittaa tyynin mielin. Se kertoo ihmisille, mitkä erimielisyydet ovat odotettuja. Se kertoo heille, että hyvät ohitukset ovat osa valvontajärjestelmää. Jos jokainen ohitus käsitellään käyttöönoton epäonnistumisena, ihmiset oppivat lakkaamaan huomaamasta. Ihmiset ovat sopeutuvaisia, joskus kiusallisella tavalla.
Menettelyn kirjaamisessa on kuivaa lohtua. Ei siksi, että asiakirjat olisivat taikaa. Ne eivät ole, kuten jokainen jaetun aseman kohdannut tietää. Lohtu tulee siitä, että organisaatio pakotetaan valitsemaan. Toistettava ihmisen vaihe sanoo, että tämän roolin on tehtävä tämä tarkistus näiden todisteiden perusteella tässä määräajassa, ja näin tapahtuu, kun tarkistus epäonnistuu. Yhtäkkiä valvonnalla on luuranko.
Satunnaisuus tarvitsee kotiosoitteen
Joihinkin tekoälyjärjestelmiin satunnaisuus kuuluu suunnitellusti. Otanta voi tuottaa parempaa kieltä. Haku voi tutkia vaihtoehtoja. Agentit voivat kokeilla erilaisia työkalujen käyttöpolkuja. Ihmisen palaute voi muuttaa toimintaa ajan myötä. Mikään tästä ei ole itsessään huonoa. Toiminnallinen virhe on antaa satunnaisuuden elää kaikkialla eikä missään. Jos vaihtelu on hyödyllistä, sano, missä se on sallittua. Jos se on riskialtista, rajaa se. Jos sitä esiintyy, tallenna siitä riittävästi, jotta sen ymmärtää. Satunnaisuus ilman osoitetta on tapa, jolla tiimit päätyvät etsimään vikaa sumukoneesta.
Käytännön keinoja on olemassa. Käytä deterministisiä asetuksia, kun tulos on seurauksiltaan merkittävä ja tehtävä on rajattu. Kiinnitä versiot ja mallipohjat. Säilytä aineistojen tilannekuvat. Kirjaa hakuehdokkaat. Erota luova luonnostelu päätöksenteon tuesta. Vaihtelevan tuotetun tekstin kohdalla arvioi väitteitä ja lähteitä pintamuotoilun sijaan. Agenttipohjaisissa työnkuluissa tallenna työkalusuunnitelmat, työkalujen tulokset ja kieltäytymispolut. Mallipäivitysten yhteydessä tee rinnakkaisvertailut ennen kuin liikenne siirtyy. Mikään tästä ei poista epävarmuutta. Se antaa epävarmuudelle paikan pöydän ääressä ja estää sitä harhailemasta kattolaattojen välissä.
Toistettavuus muuttaa myös häiriöistä puhumisen tapaa. Sen sijaan, että sanotaan tekoälyn antaneen huonon vastauksen, tiimi voi sanoa, että vastaus käytti aineiston tilannekuvaa 18, käytäntökokonaisuutta 12, malliversiota 4, kehotesapluunaa 31, haettuja asiakirjoja A, C ja F, ohitti asiakirjan B käyttöoikeusrajoituksen vuoksi, ja rooli X hyväksyi sen ilman nostoa. Tämä lause on vähemmän jännittävä kuin järjestelmä villiintyi. Se on myös hyödyllisempi, mikä on toistuva pettymys draamankaipuisille ihmisille.
Kun järjestelmä ei pysty tuottamaan tuota lausetta, organisaatio ei käytä tekoälyä. Se vahtii tekoälyä. Se katselee, reagoi, lohduttaa ja toivoo, että seuraava vuoro sujuu paremmin. Se voi olla hyväksyttävää prototyypille. Se ei ole hyväksyttävää työlle, josta ihmiset ovat riippuvaisia.
Hankinnan virhe
Toistettavuus pitää myös ostaa, ei vain rakentaa. Monet hankintaprosessit palkitsevat edelleen parhaan demonstraation. Järjestelmä, joka näyttää sujuvalta, vastaa nopeasti ja antaa johdolle miellyttävän modernin olon, kerää pisteitä. Järjestelmä, joka selittää todisteiden säilytyksen, vientimuodon, regressiotestauksen, deterministisen haun, malliversion kiinnittämisen, roolipohjaisen tarkastuksen ja peruutuskäytännön, voi kuulostaa vähemmän jännittävältä. Näin organisaatiot ostavat tulevia kokouksia.
Hyvät hankintakysymykset ovat suorasukaisia. Voimmeko toistaa tapauksen. Voimmeko viedä todistepolun. Voimmeko kiinnittää tai nimetä jokaisen mallin ja kehotteen, joka vaikuttaa vastaukseen. Voiko haun toistaa indeksin uudelleenrakennuksen jälkeen. Voimmeko verrata nykyistä toimintaa lähtötilanteeseen, joka on määritetty ennen päivityksen hyväksymistä. Voiko ihmisen tekemiä ohituksia analysoida rankaisematta hyödyllisestä harkinnasta. Voimmeko lähteä mukaanottamalla omat tietomme. Voimmeko kertoa tilintarkastajalle, mitä tapahtui, ilman että avaamme tukipyynnön ja sytytämme kynttilän.
Nämä kysymykset eivät edellytä vihamielisyyttä toimittajia kohtaan. Ne edellyttävät aikuisuutta. Hyvän toimittajan pitäisi pystyä kertomaan, mitkä osat ovat toistettavia, mitkä osat ovat todennäköisyyksiin perustuvia, mitkä todisteet ovat saatavilla, mitkä eivät, ja mitä ostajan on hoidettava itse. Ostaja, joka ei osaa esittää näitä kysymyksiä, saa lopulta vastaukset tuotannossa, jossa vastaukset ovat kalliimpia ja saapuvat kuulokkeet päässä.
Sama hankintalogiikka pätee sisäisesti. Alustatiimien ei pitäisi myydä demoa operaatioille ilman toistettavuussopimusta. Datatiimien ei pitäisi luovuttaa lähteitä ilman alkuperäketjua. Mallitiimien ei pitäisi julkaista parannuksia ilman lähtötilannevertailuja. Hallintotiimien ei pitäisi hyväksyä periaatteita testaamatta tietoja. Kaikki haluavat julkaisun. Toistettavuus on sitä kurinalaisuutta, jolla välitetään julkaisun jälkeisestä tiistaista.
Toistettavuus on ystävällisyyttä tuleville tiimeille
Toistettavuudesta välittämiseen on inhimillinen syy, joka näkyy harvoin strategiaesityksissä. Se on ystävällisempää. Se on ystävällisempää operaattoreille, joiden ei pitäisi joutua arvailemaan, miksi järjestelmä muuttui. Se on ystävällisempää insinööreille, joiden ei pitäisi joutua rekonstruoimaan häiriöitä kojelaudan murusista. Se on ystävällisempää esihenkilöille, joiden on tehtävä päätöksiä tarkastelun alla. Se on ystävällisempää asiakkaille, kansalaisille, potilaille ja kollegoille, jotka ansaitsevat vastauksia, joita ei improvisoida jälkikäteen. Toistettava järjestelmä vähentää sitä institutionaalista teeskentelyn määrää, jota viikosta selviytyminen vaatii.
Toistettavuus myös helpottaa rehellisyyttä. Kun todisteet ovat saatavilla, tiimit voivat sanoa, että malli epäonnistui tässä, data oli vanhentunutta tuossa, käytäntö oli epäselvä, tarkistajalla oli riittämättömästi asiayhteyttä tai lähde puuttui. Ilman todisteita jokainen myönnytys tuntuu riskialttiilta, koska kukaan ei tiedä, mihin syyllisyys kohdistuu. Niinpä ihmiset pehmentävät kieltään, viivyttävät päätöksiä ja luovat sen paksun sumun, jota kutsutaan linjaukseksi. Todisteet eivät tee organisaatioista rohkeita, mutta ne alentavat täsmällisyyden hintaa.
Yllätyksiä tulee silti olemaan. Toistettavuus ei ole loitsu todellisuutta vastaan. Uudet tapaukset rikkovat oletuksia. Käyttäjät kysyvät outoja kysymyksiä. Dokumentteja saapuu muotoilulla, joka näyttää sovitulta sähkökatkoksen aikana. Mallit paranevat yhteen suuntaan ja taantuvat toiseen. Tarkoitus ei ole poistaa yllätyksiä. Tarkoitus on tehdä yllätyksistä valaisevia tartunnan sijaan.
Siksi toistettavuus on tärkeämpää kuin demonstraatiot. Demonstraatiot luovat uskoa siihen, että kyvykkyys on olemassa. Toistettavuus luo kyvyn luottaa siihen. Ensimmäinen on hyödyllinen keskustelun aloittamiseen. Jälkimmäinen on välttämätön työn tekemiseen. Kun tekoälyjärjestelmästä tulee osa instituutiota, kysymys lakkaa olemasta se, voiko se tehdä vaikutuksen huoneessa. Kysymykseksi tulee, voiko se tuottaa, säilyttää ja selittää työnsä tavallisena päivänä, tavallisen paineen alla, tavallisten ihmisten kanssa mukana. Tavallisina päivinä vakavat järjestelmät ansaitsevat paikkansa.