Tekoäly ei ehkä ole kyvytön – sille on vain rakennettu huono käyttöliittymä

Kun tekoäly epäonnistuu tehtävässä, ensimmäinen johtopäätös on yleensä yksinkertainen: malli ei osaa.

Se voi olla väärä diagnoosi.

Yhä kiinnostavampi tutkimussuunta osoittaa, että tekoälyn havaittu kyvykkyys riippuu paitsi itse mallista myös siitä, millainen ympäristö mallille rakennetaan. Sama malli voi olla yhdessä käyttöliittymässä epäluotettava ja toisessa huomattavasti johdonmukaisempi. Se voi käyttää yhdessä ympäristössä valtavasti tokeneita ja toisessa saavuttaa lähes saman lopputuloksen murto-osalla työvaiheista.

Tällä erolla voi olla yllättävän suuri taloudellinen merkitys.

Kyvykkyys ei sijaitse vain mallissa

Tekoälyjärjestelmistä puhutaan usein aivan kuin kyvykkyys olisi yksi mallin sisäinen ominaisuus: GPT-tyyppinen malli joko osaa ohjelmoida, analysoida dokumentteja tai käyttää työkaluja – tai ei osaa.

Todellisuudessa käyttäjän havaitsema suorituskyky syntyy kokonaisesta järjestelmästä. Yksinkertaistettuna:

havaittu kyvykkyys = malli × konteksti × käyttöliittymä × työkalut × palaute × tarkistusmekanismi.

Jos jokin näistä komponenteista on huono, koko järjestelmä voi näyttää tyhmemmältä kuin sen varsinainen laskennallinen kapasiteetti antaisi olettaa.

Tätä voidaan verrata ihmiseen, joka osaa ratkaista ongelman mutta joutuu käyttämään tehtävään surkeasti suunniteltua ohjelmistoa. Osaamisesta ei ole kadonnut mitään. Osaaminen ei vain muutu luotettavasti toiminnaksi.

Pieni käyttöliittymämuutos voi muuttaa agentin käyttäytymistä

COLM 2026 -konferenssissa julkaistussa tutkimuksessa The Devil Is in the Interface: Evaluating How Tool Architecture Shapes Coding Agent Behavior tutkijat vertasivat erilaisia tapoja antaa ohjelmointiagenteille käytännössä samankaltaiset toimintamahdollisuudet.

Keskeistä oli juuri se, ettei agentille välttämättä annettu uusia kykyjä. Sen sijaan muutettiin tapaa, jolla olemassa olevat kyvyt esitettiin.

Tulokset ovat huomionarvoisia.

• Rakenteiset, pieniin operaatioihin tarkoitetut työkalut paransivat agenttien toistettavuutta verrattuna pelkkään vapaamuotoiseen komentorivikäyttöön.
• Luonnollisen kielen hakurajapinta sai agentit tutkimaan ohjelmistorepositiota laajemmin ja löytämään useampia relevantteja tiedostoja.
• Python-pohjainen toimintarajapinta mahdollisti useiden operaatioiden yhdistämisen samaan vaiheeseen ja vähensi tutkimuksessa sekä työvaiheita että tokenien käyttöä selvästi.

Mallia ei koulutettu uudelleen.

Sen sijaan sille rakennettiin erilainen tapa toimia.

Tämä muuttaa kysymyksen, jota yrityksen kannattaa esittää

Tavallinen kysymys tekoälyprojektissa kuuluu:

Voiko tekoäly tehdä tämän tehtävän?

Parempi kysymys voi olla:

Mikä täsmälleen estää tekoälyä tekemästä tätä tehtävää luotettavasti?

Nämä eivät ole sama kysymys.

Ensimmäinen johtaa helposti uuden mallin, suuremman mallin tai kokonaan ihmistyöhön perustuvan ratkaisun etsimiseen.

Toinen pakottaa paikantamaan varsinaisen häiriön.

Viisi erilaista kyvykkyyshäiriötä

Tekoälyn epäonnistuminen voidaan ajatella diagnostisena ongelmana. Ainakin viisi erilaista mekanismia kannattaa erottaa toisistaan.

1. Varsinainen kyvykkyys puuttuu

Malli ei yksinkertaisesti pysty ratkaisemaan ongelmaa riittävällä tasolla. Tällöin tarvitaan parempi malli, uusi menetelmä tai ihmisen osaamista.

2. Representaatio on väärä

Malli osaisi käsitellä ongelman, mutta sille annettu toimintamuoto on hankala. Se voi joutua muodostamaan monimutkaisia komentorivikomentoja, täyttämään hauraita parametrirakenteita tai muuttamaan yksinkertaisen aikomuksen pitkiksi työkalukutsuiksi.

Tällöin ratkaisu ei välttämättä ole älykkäämpi tekoäly vaan parempi rajapinta.

3. Oikea informaatio hukkuu kontekstiin

Agentilla voi teoriassa olla kaikki tarvitsemansa tieto mutta niin paljon epäolennaista aineistoa, ettei se kohdista huomiotaan oikeaan kohtaan.

Tällöin kyvykkyyttä voidaan parantaa esimerkiksi haulla, suodatuksella, kontekstin järjestämisellä tai sillä, että oikea informaatio tuodaan esiin oikealla hetkellä.

4. Oikeat osavaiheet tehdään väärässä järjestyksessä

Tekoäly voi osata etsiä tietoa, analysoida sitä, kirjoittaa ratkaisun ja tarkistaa tuloksen, mutta järjestelmä ei pakota sitä tekemään näitä vaiheita tarkoituksenmukaisessa järjestyksessä.

Kyse ei silloin ole välttämättä päättelykyvyn puutteesta vaan ohjausrakenteen puutteesta.

5. Virhettä ei korjata, vaikka tekoäly osaisi korjata sen

Monissa tehtävissä ensimmäinen yritys ei ole ratkaiseva. Ratkaisevaa on se, mitä tapahtuu virheen jälkeen.

Jos järjestelmä pystyy kertomaan agentille esimerkiksi, että tiedosto ei käänny, laskelma ei täsmää tai tietty sääntö rikkoutui, malli voi usein tehdä uuden yrityksen.

Tällöin halpa deterministinen tarkistin voi olla arvokkaampi kuin kallis mallipäivitys.

Halpa ihminen voi olla osa tekoälyn arkkitehtuuria

Tästä seuraa vielä kiinnostavampi mahdollisuus.

Kaikkia tekoälyn vaikeita osatehtäviä ei tarvitse ratkaista tekoälyllä.

Jos pitkässä työnkulussa on yksi vaihe, jossa tekoäly tekee systemaattisesti helposti havaittavan virheen, voi olla taloudellisesti järkevämpää antaa juuri tämä vaihe ihmiselle.

Ajatellaan esimerkiksi prosessia, jossa tekoäly tekee 95 prosenttia työstä oikein. Viimeinen viisi prosenttia voi vaatia ihmisen 30 sekunnin tarkistuksen.

Silloin vaihtoehdot eivät ole:

• 100 prosenttia ihmistyötä tai
• 100 prosenttia tekoälytyötä.

Todellinen optimointiongelma on:

missä kohdassa järjestelmää ihmisen sekunti tuottaa eniten lisäluotettavuutta?

Tämä tekee halvan mikrotyön suunnittelusta mahdollisesti merkittävän osan agenttitaloutta.

Tässä voi olla markkina: AI capability arbitrage

Yritysten kannalta kiinnostavin mahdollisuus ei ehkä ole uuden yleiskäyttöisen tekoälymallin rakentaminen.

Paljon kevyempi liiketoimintamalli voisi perustua siihen, että etsitään tehtäviä, joissa nykyinen tekoäly näyttää lähes mutta ei aivan käyttökelpoiselta.

Tätä voisi kutsua AI capability arbitrageksi.

Menetelmä olisi yksinkertainen.

1. Etsi kallis ihmisen tekemä tehtävä.
2. Anna nykyisen tekoälyn yrittää tehdä se.
3. Älä kysy vain, onnistuiko tehtävä.
4. Luokittele tarkasti, missä vaiheessa epäonnistuminen tapahtui.
5. Testaa halvin mahdollinen interventio.

Interventio voi olla esimerkiksi:

• parempi työkalukuvaus,
• yksi uusi käyttöliittymäelementti,
• luonnollisen kielen hakutoiminto,
• deterministinen tarkistusohjelma,
• koodilla toteutettava välivaihe,
• paremmin rajattu konteksti,
• toinen itsenäinen tekoälyyritys tai
• 30 sekunnin ihmistarkistus.

Jos esimerkiksi 100 euron ihmistyö voidaan tällä tavalla muuttaa 5 euron tekoälylaskennaksi ja 1 euron ihmistarkistukseksi, taloudellinen arvo ei synny siitä, että olisi rakennettu älykkäämpi malli.

Arvo syntyy työn paremmasta arkkitehtuurista.

Käyttöliittymäsuunnittelu ei siis ole kosmetiikkaa

Perinteisesti käyttöliittymä suunnitellaan ihmiselle. Sen pitäisi tehdä ohjelmiston käyttö helpoksi, ymmärrettäväksi ja virheitä ehkäiseväksi.

Agenttien aikakaudella käyttöliittymällä on toinenkin käyttäjä: tekoäly.

Tämä käyttäjä tekee erilaisia virheitä kuin ihminen. Se voi olla erinomainen ohjelmoija mutta huono muodostamaan tietyn komentorivikomennon. Se voi ymmärtää ongelman mutta eksyä liian suureen työkaluvalikoimaan. Se voi löytää oikean ratkaisun yhdessä ajossa ja epäonnistua seuraavassa lähes identtisessä tilanteessa.

Siksi tulevaisuuden ohjelmistosuunnittelussa ei ehkä riitä kysymys:

Miten ihminen käyttää tätä järjestelmää?

Pitää kysyä myös:

Millainen ympäristö saa tekoälyn käyttämään olemassa olevia kykyjään mahdollisimman luotettavasti?

Yrittäjän kannalta kiinnostavin alue on melkein toimiva tekoäly

Täysin mahdoton tekoälytehtävä ei välttämättä ole hyvä liiketoimintamahdollisuus. Siihen tarvitaan ehkä vuosien perustutkimusta.

Täysin ratkaistu tekoälytehtävä ei sekään välttämättä ole hyvä mahdollisuus. Kaikki muutkin voivat automatisoida sen.

Taloudellisesti kiinnostavin alue voi sijaita niiden välissä:

tekoäly osaa melkein kaiken tarvittavan, mutta yksi pieni kitka estää kaupallisesti käyttökelpoisen lopputuloksen.

Jos kitkan poistaminen maksaa vähän mutta sen poistama ihmistyö maksaa paljon, syntyy poikkeuksellisen kiinnostava vipuvaikutus.

Silloin kilpailuetu ei välttämättä ole parempi tekoäly.

Se voi olla parempi käyttöliittymä, parempi työnkulku, parempi tarkistin tai juuri oikeaan kohtaan sijoitettu ihminen.

---

Flutterby Ninja Consulting
Etsimme ongelmia, joissa vaikealta näyttävä tietotyö voidaan sieventää paremmaksi järjestelmäksi.