AI-osaaminen punnitaan siinä, mitä hyväksyt valmiiksi

Kirjoitin huhtikuussa 2023 tässä blogissa tekoälystä ja Mooren laista. Määrittelin Mooren lain tietokoneiden suorituskyvyn ja kapasiteetin eksponentiaaliseksi kasvuksi. Lause kuulosti selkeältä. Se oli myös liian lavea.

Gordon Mooren alkuperäinen artikkeli vuodelta 1965 käsitteli integroidun piirin komponenttimäärän kasvua ja komponenttikohtaista kustannusta. Intelin nykyinen tiivistys kuvaa piirillä olevien transistorien määrän kaksinkertaistumista suunnilleen kahdessa vuodessa. Kumpikaan ei ole yleinen lupaus siitä, että jokaisen tietokoneen suorituskyky tai tekoälyn kyvykkyys kasvaisi samaa tahtia.

Ero on olennainen. Muutin rajatun havainnon yleiseksi kehityslaiksi ja annoin lukijalle liian helpon selityksen.

En muista varmasti, käytinkö juuri tämän tekstin tekemisessä tekoälyä. Vastuun kannalta sillä ei lopulta ole suurta merkitystä. Teksti julkaistiin minun nimelläni, joten myös sen rajauksista vastasin minä. Sama vastuu kulkee mukana nykyisessä AI-työssäni.

Ote vuonna 2023 julkaisemastani Mooren lakia käsittelevästä kirjoituksesta.

Sujuva lause tarvitsee perustan

Tekoälyn tuottaman vastauksen varmuus ei itsessään kerro sen paikkansapitävyydestä. Yhdysvaltain standardointi- ja teknologiainstituutti NIST nostaa generatiivisen tekoälyn riskikehyksessään esiin juuri itsevarmasti esitetyn virheellisen sisällön. Siksi myös AI:n vastausta on arvioitava sisällön, ei esitystavan perusteella.

Minusta hankalimpia arvioitavia ovat vastaukset, joissa on paljon oikeaa mutta yksi ratkaiseva rajaus puuttuu. Mooren laki -tekstissäni tuttu käsite teki liian laveasta selityksestä uskottavan.

Linkin lisääminen jälkikäteen ei yksin korjaa tällaista ongelmaa. On katsottava, tukeeko lähde juuri sitä lausetta, jonka yhteyteen se on liitetty. Lukijan ei pitäisi joutua korjaamaan kirjoittajan päättelyä.

AI-osaaminen näkyy siinä, millä perusteella hyväksymme työn valmiiksi.

Yksi epätarkka määritelmä ei tee koko kirjoituksesta arvotonta. Minulle se osoittaa, miksi tarkistaminen kuuluu kirjoittamiseen. Jos sen jättää tekemättä, työ on kesken, vaikka viimeinen piste olisi jo paikallaan.

Valmis täytyy määritellä ennen tilaamista

Rakennan Rovaniemellä Lapland AI Labia ja kokeilen sen kautta käytännössä tekoälyä, agentteja ja automaatioita. ChatGPT ja Codex ovat osa tätä tekemistä. Mitä enemmän tehtäviä pystyn antamaan AI:lle, sitä kiinnostavammaksi muuttuu toinen kysymys: mitä minun pitää edelleen osata arvioida itse?

Tuotosten kirjo ulottuu tekstistä ohjelmamuutoksiin. Esimerkiksi OpenAI kuvaa Codexia ohjelmistotyön agentiksi, jolla voi rakentaa ominaisuuksia ja muokata olemassa olevaa ohjelmistoa. Käyttötarkoituksen kuvaus ei vielä todista yksittäisen työn onnistumista.

Haluan määritellä ennen tehtävän antamista, mitä valmiin tuloksen pitäisi mahdollistaa. Kenen pitää osata toimia ohjeen avulla? Minkä käyttäjän ongelman ohjelmamuutos ratkaisee? Mitä automaatio tekee, jos lähtötieto puuttuu?

Ajatellaan esimerkiksi ohjetta, jonka avulla uuden käyttäjän pitäisi löytää sovelluksesta oikea toiminto. Kieli voi olla moitteetonta, mutta ohje jää käyttökelvottomaksi, jos painikkeen nimi on väärä tai yksi välivaihe puuttuu. Hyväksymiskriteeri olisi silloin, että tehtävä onnistuu ohjetta seuraamalla.

Ohjelmamuutoksessa pyytäisin nähtäväksi, mikä muuttui, miten muutosta kokeiltiin ja mitä jäi tarkistamatta. Pelkkä ilmoitus läpäistyistä testeistä ei vastaa siihen, testattiinko käyttäjän kannalta oikeaa asiaa. Haluan pystyä yhdistämään tarkistuksen alkuperäiseen tehtävään: mitä tämä tulos osoittaa ja mitä se jättää avoimeksi?

Agentin tai automaation kohdalla määrittelisin myös kohdan, jossa työn pitää pysähtyä. Luonnoksen tekeminen, viestin lähettäminen ja muutoksen julkaiseminen tarvitsevat omat hyväksymisperusteensa. Jos olen pyytänyt valmistelua, onnistumista arvioidaan valmistelun laadulla. Pidemmälle eteneminen ei ole automaattisesti parempaa työtä.

Hyväksymiskriteerit voivat olla aivan tavallista suomea: lähde tukee väitettä, ohjeen voi toteuttaa, sovittu toiminto toimii ja keskeneräiset kohdat on kerrottu. Olennaista on, että voin selittää myös toiselle ihmiselle, miksi tulos kelpaa.

Myös hylkäämistä pitäisi harjoitella

Mielestäni AI-koulutuksessa pitäisi harjoitella enemmän tilanteita, joissa vastausta ei hyväksytä. Osallistujalle voisi antaa uskottavan mutta puutteellisen tuotoksen ja pyytää perustelemaan, mikä siinä tarvitsee korjausta. Sen jälkeen korjattu versio pitäisi tarkistaa uudelleen.

Hyvien kehotteiden opettaminen on edelleen tarpeellista. Aloittelija tarvitsee tavan kertoa tehtävä, tausta ja toivottu lopputulos. Mutta jos harjoitus päättyy ensimmäiseen sujuvaan vastaukseen, arvioinnin vaikein vaihe jää harjoittelematta. Kaikkien ei tarvitse ohjelmoida tai rakentaa agentteja osatakseen kysyä, mistä tieto on peräisin.

Euroopan komission AI-lukutaitoa koskevassa ohjeessa korostuvat ihmisten lähtötaso, käyttökonteksti ja järjestelmien riskit. Siksi harjoittelisin oman työn olennaisia kysymyksiä, en yhtä kaikille samanlaista tarkistusrituaalia.

Hyväksyminen ei myöskään saisi tarkoittaa vain nimen laittamista AI:n vastauksen alle. Jos tulosta arvioivalta ihmiseltä puuttuu aika, tarvittava osaaminen tai mahdollisuus pyytää korjausta, hyväksyntä jää helposti muodollisuudeksi. Siksi antaisin arvioijalle myös oikeuden todeta, ettei työ ole vielä valmis.

Oman Mooren laki -tekstini kohdalla hyväksymiskriteeri olisi ollut yksinkertainen: keskeinen käsite on määritelty oikein, eikä siitä johdeta enempää kuin lähde perustelee. Saman vaatimuksen asetan sille, mitä kirjoitan ja rakennan nyt.

Kun seuraava AI:n tuotos näyttää valmiilta, pysähtyisin vielä yhden kysymyksen äärelle:

Mitä tarkistin – ja miksi juuri se riittää tähän käyttöön?

Ehkä juuri siinä alkaa AI-osaamisen vaikeampi osa.