Miksi tylsä infrastruktuuri voittaa vakavassa tekoälyssä
Demo, joka näytti tulevaisuudelta lounaaseen asti
Vakuuttavin koskaan näkemäni tekoälydemo epäonnistui jonon takia. Ei mallin, ei promptin, ei vektorihaun, ei sen tyylikkään pienen agenttigraafin, joka sai kaikki huoneessa nojautumaan eteenpäin. Jonon. Aamupäivällä järjestelmä otti vastaan tukisähköposteja, löysi asiaankuuluvat dokumentit, laati vastaukset, merkitsi epävarmuudet ja ohjasi hankalat tapaukset ihmiselle. Se vaikutti rauhalliselta ja melkein epäreilun älykkäältä. Lounaalla tuontityö kaksinkertaistui, alavirran sähköpostijärjestelmä hidastui, uudelleenyritykset kasautuivat toistensa päälle, ja jono alkoi käyttäytyä kuin kohtelias ruuhka, johon oli liitetty laskuja.
Kolmelta iltapäivällä malli oli edelleen kykenevä. Se oli loukkaavin osuus. Älykkyys ei ollut kadonnut. Putkisto oli. Viestit käsiteltiin väärässä järjestyksessä. Jotkin työt yritettiin uudelleen vanhentuneella kontekstilla. Muutama päällekkäinen vastaus odotti hyväksyntää. Hallintapaneeli näytti vihreää, koska hallintapaneeli mittasi mallin päätepistettä, ei työtä. Tapaus ei ollut elokuvallinen. Kukaan ei potkaissut palvelinta. Järjestelmä vain paljasti, että älykäs osa oli asetettu pahvista ja optimismista tehdylle lattialle.
Siksi tylsä infrastruktuuri voittaa vakavassa tekoälyssä. Vakava tekoäly ei ole versio, joka tekee vaikutuksen huoneeseen viideksitoista minuutiksi. Se on versio, joka selviää huonosta syötteestä, viivästyneistä riippuvuuksista, osittaisista häiriöistä, vanhentuneista tunnuksista, ylikuormitetuista indekseistä, ihmisen tarkistusjonoista, kustannuspiikeistä, skeemamuutoksista, alueellisesta viiveestä, auditointipyynnöistä ja maanantaiaamusta. Malli on tärkeä. Tietenkin se on tärkeä. Mutta malli on yksi osa järjestelmää, jonka on siirrettävä työtä ajassa läpi valehtelematta siitä, mitä tapahtui.
Ala haluaa puhua älykkyydestä kuin malli olisi tuote ja kaikki sen ympärillä pelkkää rakennustelinettä. Tuotannossa rakennusteline on usein itse tuote. Identiteetti päättää, kuka saa kysyä. Datasopimukset päättävät, mitä järjestelmä saa tietää. Haku päättää, mikä näyttö päätyy mallille. Jonot päättävät, saapuuko työ palautettavassa järjestyksessä. Lokit päättävät, voidaanko virhe tutkia. Arviointi päättää, onko parannus todellinen. Palautus päättää, tuleeko huonosta julkaisusta tapaus vai alaviite. Mikään näistä ei näytä vaikuttavalta julkaisuvideossa. Se on niiden eduksi.
Tylsä ei tarkoita yksinkertaista
Tylsä infrastruktuuri sekoitetaan usein perusinfrastruktuuriin. Se ei ole sitä. Se on infrastruktuuria, jonka yllätykset on poistettu suunnittelun, toiston ja näytön avulla. Hyvä jono on tylsä, koska siinä on selkeä järjestys, uudelleenyrityskäytäntö, deduplikointi, näkyvyysaikakatkaisu, kuolleiden viestien käsittely ja takapaine. Hyvä skeema on tylsä, koska se on versioitu, testattu, dokumentoitu ja se hylätään, kun se on väärä. Hyvä loki on tylsä, koska se kertoo, mitä tapahtui, tavalla, joka voidaan yhdistää muuhun näyttöön. Tylsä ei tarkoita ajattelun puutetta. Se on ajattelua, joka on jo maksanut vuokransa.
AI-järjestelmät tarvitsevat tätä enemmän kuin tavalliset ohjelmistot, koska ne tuovat epävarmuuden keskelle. Perinteinen palvelu voidaan usein kuvata deterministisinä siirtyminä. AI-komponentti voi palauttaa todennäköisyyksiin perustuvan vastauksen, järjestetyn joukon vaihtoehtoja, tuotettua tekstiä, poimitun kentän, työkalukutsun tai kieltäytymisen. Tämä tulos on sitten vietävä työnkulkuun, joka odottaa tiloja, käyttöoikeuksia, määräaikoja, palvelutasoja ja vastuullisuutta. Jos mallin ympärillä oleva infrastruktuuri on epämääräistä, mallin epävarmuus vuotaa toimintaan. Sitten sitä kutsutaan AI-riskiksi, vaikka suuri osa siitä on itse asiassa putkistoa, jolla on luottamusongelmia.
Tylsä infrastruktuuri antaa todennäköisyyksiin perustuville komponenteille turvallisen muodon. Se tallentaa kehotteet, syötteet, haetun näytön, malliversiot, käytännöt, työkalukutsut, tulokset, ihmisten päätökset ja jälkivaikutukset. Se rajoittaa valtuuksia identiteetin ja laajuuksien avulla. Se käsittelee epäonnistumista tilana, ei yllätyksenä. Se erottaa luonnoksen toiminnasta. Se vaatii näyttöä ennen kuin automaatio koskettaa merkittävää työnkulkua. Se säilyttää riittävästi kontekstia tarkastelua varten. Malli voi silti olla luova, epävarma ja joskus väärässä. Sen ympärillä olevan järjestelmän ei tarvitse improvisoida joka kerta.
Tämä ei ole innovaation vastustamista. Se on se, mikä antaa innovaatiolle mahdollisuuden selviytyä. Nopeimmat tiimit, jotka tunnen, eivät ole niitä, joilla on vähiten prosesseja. He ovat niitä, joiden prosessit elävät hyödyllisissä kiskoissa: paikallisissa testijoukoissa, toistettavissa käyttöönotoissa, selkeässä palautuksessa, tunnetuissa datakontrakteissa, helpossa havaittavuudessa ja tarkastelupoluissa, jotka eivät vaadi komiteaa oikean laskentataulukon löytämiseen. He liikkuvat nopeasti, koska tavalliselle riskille on annettu paikka, johon se voi mennä. Me muut kutsumme sitä tylsäksi vain siksi, että luotettavat asiat eivät esiinny huomion vuoksi.
Malli ei ole käyttöjärjestelmä
On olemassa toistuva fantasia, että kyvykäs malli voi korvata sen ympärillä olevan infrastruktuurin. Anna sille riittävästi kontekstia, niin se reitittää, validoi, päättää, valvoo, selittää, korjaa ja päivittää ehkä myös toimintaohjeet samalla kun keittää teetä. Fantasia on ymmärrettävä, koska mallit ovat joustavia. Joustavuus on viettelevää. Se on myös huono korvike selkeille järjestelmärajoille. Malli voi auttaa valitsemaan reitin. Sen ei pitäisi olla ainoa paikka, jossa reitti on olemassa.
Kun tiimit antavat mallin ottaa vastuulleen infrastruktuurin tehtäviä, ne luovat piilotettuja käytäntöjä. Kehote kertoo, mitä lähteitä suositaan. Kehote kertoo, milloin kieltäytyä. Kehote kertoo, mitä työkalua käyttää. Kehote kertoo, miten puuttuvat kentät käsitellään. Kehote kertoo, mikä lasketaan riskiksi. Osa tästä voi olla hyväksyttävää tutkimiseen. Tuotannossa piilotetusta käytännöstä tulee vaikeasti testattavaa, versioitavaa, auditoitavaa ja haastettavaa. Pitkästä kehotteesta voi tulla perustuslaki, joka on kirjoitettu lautasliinalle ja tallennettu ympäristömuuttujaan. Tämä on eloisa tapa hallita, mutta ei kypsä.
Vakava tekoäly erottaa päättelyn auktoriteetista. Malli voi ehdottaa. Työnkulku päättää, onko ehdotuksessa riittävästi näyttöä, onko käyttäjällä oikeus, onko toimenpide palautettavissa, vaatiiko se ihmisen hyväksynnän ja mahtuuko kustannus budjettiin. Malli voi tiivistää tapauksen. Tapausjärjestelmä päättää, tuleeko tiivistelmästä tietue. Malli voi kutsua työkalua. Työkaluyhdyskäytävä päättää, onko kutsu sallittu. Tämä erottelu ei ole byrokratiaa. Se on tapa, jolla järjestelmä pysyy tarkastettavissa, kun älykkyys on väärässä, puutteellista tai vakuuttavaa.
Mitä kykenevämpi malli, sitä tärkeämmiksi rajat tulevat. Heikko malli epäonnistuu äänekkäästi ja usein. Vahva malli voi epäonnistua hiljaa, uskottavasti ja laajassa mittakaavassa. Se voi kirjoittaa varmaan sävyyn selityksen väärästä lähteestä. Se voi kutsua työkalua moitteettomalla kieliopilla. Se voi silottaa puuttuvan näytön yli tavalla, joka rauhoittaa käyttäjää. Infrastruktuurin on siis oltava itsepäisempi kuin mallin. Sen on vaadittava kuittauksia, tarkistettava käyttöoikeudet, valvottava rajoituksia ja pidettävä kirjaa, vaikka vastaus kuulostaisi järkevältä ja kauniilta.
Datasopimukset voittavat hyvät aikeet
Monet tekoälyonnettomuudet alkavat pienestä yhteensopimattomuudesta. Kenttä, joka oli aiemmin valinnainen, muuttuu pakolliseksi. Aikaleiman aikavyöhyke vaihtuu. Dokumenttijäsennin alkaa tuottaa osioiden tunnisteita eri tavalla. Tilakoodi saa uuden arvon. Kielitunniste puuttuu. Asiakastunniste saapuu tiivistettynä yhdessä virrassa ja selväkielisenä toisessa. Malli vastaanottaa jotakin, joka on riittävän uskottavaa käsiteltäväksi ja riittävän väärää myrkyttääkseen tuloksen. Hyvät aikeet eivät tätä huomaa. Datasopimukset huomaavat.
Datasopimus ei ole suuri filosofinen objekti. Se määrittelee, minkä muotoinen data on, mitkä kentät ovat pakollisia, mitä arvot tarkoittavat, miten versiot muuttuvat, mitkä laatukynnykset pätevät, kuka syötteen omistaa ja mitä tapahtuu, kun sopimusta rikotaan. Tekoälyjärjestelmissä sopimusten tulisi kuvata myös tuoreus, alkuperä, käyttöoikeudet, tunnisteiden merkitys, paloittelukäytäntö, upotusmalli, hakualue ja poistamissäännöt. Sopimus on paikka, jossa data lakkaa olemasta tunnelmaa ja muuttuu sitoumukseksi.
Sopimukset ovat tärkeitä, koska mallit ovat suvaitsevaisia. Ne pystyvät ymmärtämään sekavaa syötettä. Tämä suvaitsevaisuus on hyödyllistä reunalla ja vaarallista rajapinnassa. Jos ihminen lähettää epätavallisen kysymyksen, suvaitsevaisuus auttaa. Jos lähdesyöte muuttaa merkitystään hiljaa, suvaitsevaisuus peittää vian. Järjestelmän tulisi olla tiukka integraatiorajapinnoissa ja joustava päättelykerroksessa. Käänteinen asetelma tuottaa hauraita käyttäjiä ja löyhiä putkistoja, mikä on tehokas tapa kerätä anteeksipyyntöjä.
Sama pätee tulosteeseen. Generoitu vastaus ei riitä. Järjestelmät alavirrassa tarvitsevat jäsenneltyä tilaa: hyväksytty, hylätty, tarkistettava, todisteet puuttuvat, käytäntö esti, työkalu epäonnistui, kustannus ylittyi. Ne tarvitsevat syykoodeja, luottamuslukuja, lähdeviitteitä, malliversioita ja jäljitystunnisteita. Jos tekoälykomponentti tuottaa vain proosaa, jokaisesta alavirran kuluttajasta tulee kirjallisuuskriitikko. Se on epäreilua ohjelmistolle ja yleensä myös kirjallisuudelle.
Lokit eivät ole sivutuote
Vakavassa tekoälyssä lokit eivät ole pakokaasua. Ne ovat osa tuotteen hermostoa. Hyödyllinen loki yhdistää käyttäjän tarkoituksen, käyttöoikeudet, kehotesapluunan, haetut todisteet, malliversion, parametrit, työkalujen kutsut, viiveen, kustannuksen, tulosteen, ihmisen tekemän ohituksen ja alavirran toimenpiteen. Sen ei tarvitse paljastaa salaisuuksia tai henkilötietoja laajasti. Sen on säilytettävä tarpeeksi, jotta aikuisten kysymyksiin voidaan vastata: miksi näin tapahtui, kuka sen salli, mitä se näki, mikä muuttui ja miten estämme sen toistumisen.
Ilman lokeja jokaisesta tekoälytapauksesta tulee henkien manausta. Ihmiset kokoontuvat kuvakaappauksen ympärille. Joku muistaa, että kehote muuttui viime viikolla. Joku toinen sanoo, että indeksi päivitettiin. Kolmas arvelee, että käyttäjällä on saattanut olla eri rooli. Mallin toimittajan tilasivua tutkitaan rituaalisella vakavuudella. Lopulta tiimi kirjoittaa uskottavan tarinan. Uskottavat tarinat toimivat romaaneissa. Operatiivisessa toiminnassa ne ovat vero puuttuvista todisteista.
Lokituksen suunnittelussa on otettava huomioon yksityisyys ja tietoturva, ei lisätä sitä summittaisena tallennuksena. Arkaluonteiset kehotteet saattavat vaatia poistamista tai hajautusarvoja. Jälkien käyttöoikeudet on rajattava. Säilytysajan on vastattava riskiä. Osa tiedoista ei saa koskaan päätyä lokiin. Mutta lokituksesta kieltäytyminen, koska lokitus on riskialtista, on kuin jarruista kieltäytyminen, koska nopeus on vaarallista. Oikea vastaus on hallittu lokitus, ei operatiivinen sokeus.
Hyvät lokit tekevät myös parantamisesta rehellistä. Jos uusi kehote vähentää virheitä käsin valitussa esimerkkijoukossa mutta lisää ihmisen tekemiä ohituksia tuotannossa, järjestelmän pitäisi näyttää se. Jos hakumuutos lyhentää viivettä mutta lisää vanhentuneita viittauksia, järjestelmän pitäisi näyttää se. Jos mallipäivitys leikkaa kustannuksia mutta lisää kieltäytymiä tietyllä kielellä, järjestelmän pitäisi näyttää se. Vakava tekoäly tarvitsee vähemmän voittodioja ja enemmän yhteen kytkettyjä jälkiä.
Arviointi on infrastruktuuria
Arviointia kohdellaan liian usein tutkimustoimintana, joka tapahtuu ennen käyttöönottoa. Vakavassa tekoälyssä se on infrastruktuuria. Se toimii jatkuvasti, liittyy julkaisuihin, ottaa näytteitä tuotannosta, vertailee malliversioita, testaa hakua, mittaa ihmisen tekemiä ohituksia ja seuraa taantumia ryhmissä, kielissä, toimialoilla ja työnkuluissa. Arviointi on järjestelmän muisti siitä, mitä hyvä tarkoittaa. Ilman sitä parantamisesta tulee makuasia, ja maku on taipuvainen yhtymään demon esittäjän näkemykseen.
Arviointiaineisto ei saa olla staattinen palkintovitriini. Sen tulisi sisältää tavallisia tapauksia, vaikeita tapauksia, tuoreita epäonnistumisia, vastakkaisia kehotteita, käytäntörajoja, vähäisten kielten aineistoja, reunatapauksia, vanhentuneita tietueita, monitulkintaisia kysymyksiä ja esimerkkejä, joissa oikea vastaus on kieltäytyminen. Sen tulisi tietää, mikä mittari on merkityksellinen millekin työnkululle. Tiivistäjä, luokittelija, koodiavustaja, luokittelujärjestelmä ja hakupohjainen agentti eivät epäonnistu samalla tavalla. Niiden kohteleminen yhtenä vertailuaineistona tuottaa luvun, ei juurikaan viisautta.
Arviointi vaatii myös tiedonhallintaa. Mistä esimerkit ovat peräisin. Saako niitä käyttää tähän tarkoitukseen. Sisältävätkö ne arkaluonteisia tietoja. Ovatko ne edelleen edustavia. Kuka ne on luokitellut. Miten erimielisyydet käsiteltiin. Mikä on muuttunut viime kuusta. Testiaineisto voi vanhentua tai vinoutua kuten mikä tahansa muu aineisto. Jos arviointikorpusta kohdellaan pyhänä, siitä tulee lopulta vanhojen oletusten muistomerkki. Muistomerkit harvoin havaitsevat tuotannon ajautumisen.
Tärkeintä on, että arviointi liittyy julkaisunhallintaan. Malli, kehote, hakemisto, jäsennin, työkaluyhdyskäytävä tai käytäntömuutos ei saa päätyä tuotantoon vain siksi, että se tuntuu paremmalta. Sen tulisi läpäistä asiaankuuluvat testit, kertoa tunnetut kompromissit ja jättää jälki. Jotkin muutokset kannattaa ottaa käyttöön taantumista huolimatta, koska kustannukset, viive, turvallisuus tai kattavuus paranevat. Se on hyväksyttävää. Vakava insinöörityö ei ole kompromissien puuttumista. Se on kieltäytymistä löytämästä niitä vahingossa.
Kustannusten hallinta on luotettavuutta
Tekoälyn kustannuksista keskustellaan usein talousosastolla vasta, kun arkkitehtuuriin on jo emotionaalisesti sitouduttu. Se on liian myöhäistä. Kustannus on suorituskyvyn ominaisuus. Se vaikuttaa luotettavuuteen, koska kalliit järjestelmät kehittävät outoja käyttäytymismalleja paineen alla. Tiimit poistavat lokituksen käytöstä säästääkseen rahaa. He heikentävät kontekstin laatua. He jättävät arvioinnit väliin. He välttävät uudelleenyrityksiä. He eräajavat työtä liian aggressiivisesti. He antavat jonojen kasvaa. He piilottavat käytön. Kustannus lakkaa olemasta lasku ja muuttuu suunnittelurajoitteeksi, joka teeskentelee olevansa yllätys.
Vakava tekoälyinfrastruktuuri tekee kustannuksista näkyviä samalla tasolla kuin viiveestä ja virheistä. Jokaisella pyynnöllä tulisi olla budjetti. Kalliit työkalujen kutsut tulisi rajata. Haun tulisi välttää puolen kirjaston tuomista vastatakseen kysymykseen yhdestä kappaleesta. Pitkä konteksti tulisi perustella. Eräajoilla tulisi olla kiintiöt ja peruutusmahdollisuus. Agenteilla tulisi olla vaiherajat. Arvioinnin tulisi mitata kustannusta hyväksyttävää tulosta kohti, ei vain kustannusta merkkiä kohti. Merkityksellinen yksikkö on hyödyllinen työ, ei laskennallinen konfetti.
Kustannusrajat suojaavat myös turvallisuutta. Hallitsematon agenttisilmukka ei ole vain kallis. Se voi toistaa toimintoja, lähettää päällekkäisiä viestejä, lukita tietueita tai kuormittaa kolmannen osapuolen järjestelmää. Hakukone, joka indeksoi kaiken, voi paljastaa tietoja käyttötarkoituksensa ulkopuolelle. Tiivistystehtävä, joka ajetaan kaikkien asiakirjojen yli, voi luoda johdettuja tietueita, joilla on uusia säilytysvelvoitteita. Budjettirajat pakottavat suunnittelun selkeyteen. Ne kysyvät, miksi järjestelmä tekee jotakin ja milloin sen tulisi lopettaa. Koneet tarvitsevat tätä apua. Ne eivät ole tunnettuja vapaaehtoisesta maltillisuudesta.
Ei ole häpeällistä optimoida tavallista laitteistoa, pienempiä malleja, välimuistia, eräajoa, esilaskentaa ja paikallista päättelyä varten, kun se on tarkoituksenmukaista. Vakavaa tekoälyä ei mitata sillä, kuinka mahtavalta laitteisto kuulostaa. Sitä mitataan sillä, pystyykö järjestelmä tuottamaan vaaditun laadun kustannusrajoissa, jotka mahdollistavat sen jatkuvan toiminnan. Loistava malli, jota on liian kallista tarkkailla, arvioida ja palauttaa, ei ole tuotantojärjestelmä. Se on apurahahakemus, jossa on API.
Ihmisen tekemä tarkistus ei ole paikka huonolle infrastruktuurille
Ihmisen tekemä tarkistus on tarpeen monissa tekoälyjärjestelmissä, erityisesti silloin, kun päätökset vaikuttavat oikeuksiin, rahaan, terveyteen, turvallisuuteen tai luottamukseen. Mutta tarkistusta käytetään usein kaatopaikkana kaikelle sille, mitä infrastruktuuri ei hoitanut: puuttuville todisteille, epämääräisille käytännöille, heikolle luottamukselle, rikkinäiselle reititykselle, päällekkäisille töille, huonoille merkinnöille ja epäselvälle omistajuudelle. Sitten johtajat sanovat, että ihminen on mukana prosessissa, ikään kuin ihminen olisi taianomainen liuotin. Ihminen on yleensä henkilö, jolla on jono, määräaika ja ergonomialtaan kyseenalainen tuoli.
Tarkistus tarvitsee myös infrastruktuuria. Tarkistajien on nähtävä todisteet, jotka malli näki, todisteet, joita se ei nähnyt, sovelletun käytännön, malliversion, luottamus- ja syykoodit, lähdeasiakirjat, mahdollisuuden korjata strukturoituja kenttiä ja tavan palauttaa korjaukset arviointi- ja koulutusaineistoon. He tarvitsevat työmäärärajoja. He tarvitsevat eskalaation. He tarvitsevat auditointijäljet. He tarvitsevat suojaa automaatioharhalta, jossa sujuva vastaus huomaamatta muuttuu kehotukseksi.
Hyvä tarkistusjärjestelmä erottaa myös epävarmuuden riskistä. Jotkin tapaukset ovat epävarmoja mutta vaikutuksiltaan vähäisiä, ja niihin voidaan vastata varauksin. Jotkin ovat varmoja mutta vaikutuksiltaan suuria, ja ne vaativat silti hyväksynnän. Jotkin ovat heikon luottamuksen takia epävarmoja, koska tietoja puuttuu. Jotkin ovat käytännön estämiä luottamuksesta riippumatta. Jos infrastruktuuri typistää kaiken tämän muotoon kysy ihmiseltä, tarkistajasta tulee järjestelmän jätteenlajittelulaitos. Ihmiset pystyvät siihen jonkin aikaa. Sitten laadusta tulee henkilöstösuunnitelma, jolla on kohtelias nimi.
Tarkoitus ei ole poistaa ihmisiä. Tarkoitus on antaa heille työtä, joka ansaitsee harkintaa. Anna infrastruktuurin hoitaa järjestys, todisteiden paketointi, käytäntötarkistukset, päällekkäisyyksien poisto, määräaikojen seuranta, palautteen kerääminen ja toisto. Anna ihmisten hoitaa kiistelty merkitys, poikkeukset, myötätunto, neuvottelu ja vastuu. Tämä jako on kunnioittavampi ihmistä kohtaan ja turvallisempi järjestelmälle. Se myös vähentää ikiaikaista yritysrituaalia, jossa arkkitehtuuri ratkaistaan henkilöstömäärällä.
Luottamuksen hiljainen arkkitehtuuri
Luottamus tekoälyyn esitetään usein viestintäongelmana. Selitä järjestelmä paremmin. Lisää ilmoitus. Julkaise periaatteet. Tee käyttöliittymästä lämpimämpi. Nämä asiat voivat auttaa, mutta käyttäjät oppivat luottamuksen käyttäytymisen kautta. Muistaako järjestelmä rajansa. Kieltäytyykö se, kun todisteita puuttuu. Näyttääkö se lähteet. Toipuuko se sulavasti. Pysäyttääkö se päällekkäisen työn. Antaako se ihmisten haastaa. Paraneeko se virheiden jälkeen. Nämä ovat infrastruktuurin käyttäytymistä ennen kuin ne ovat brändin käyttäytymistä.
Luottamuksen hiljainen arkkitehtuuri rakentuu vakaista tunnisteista, selkeistä käyttöoikeuksista, yksiselitteisistä tiloista, kestävistä lokitiedoista, testatuista palautuksista, edustavasta arvioinnista, ymmärrettävästä tarkastelusta ja rehellisestä kieltäytymisestä. Käyttäjä ei näe suurinta osaa siitä. Hän tuntee sen, kun järjestelmä ei hukkaa hänen asiaansa, kun valituksella on näyttöä, kun korjaus pysyy voimassa, kun huono julkaisu peruutetaan tai kun vastaus sanoo, ettei se tiedä, sen sijaan että sepittäisi pienen oopperan.
Siksi vakavien tekoälytiimien kannattaisi käyttää enemmän aikaa epäkiitollisten osien kehumiseen. Henkilö, joka sai idempotenssin toimimaan, pelasti tuotteen päällekkäisiltä toimenpiteiltä. Insinööri, joka vaati jäljitystunnuksia, pelasti häiriökatsauksen. Data-asiantuntija, joka esti versioimattoman syötteen, pelasti mallin hiljaiselta valheelta. Operaatioiden vetäjä, joka harjoitteli palautusta, pelasti viikonlopun. Kukaan heistä ei esiinny pääpuheenvuorossa. Tuotanto on heille silti velkaa.
Tylsä infrastruktuuri ei ole kunnianhimon puutetta. Se on kunnianhimoa, joka odottaa tulevansa käytetyksi oikeiden ihmisten toimesta oikeissa organisaatioissa oikeiden rajoitteiden alla. Malli voi säilyä älyllisesti kiinnostavimpana osana. Sen ei pitäisi olla ainoa vakavasti otettava osa. Älykkyys, jota ei voi asettaa jonoon, rajata, tarkkailla, arvioida, selittää ja palauttaa, ei ole valmis vakavaan työhön. Se on valmis demoon, joka on eri ja paljon lyhyempi kausi.
Opetus
Tylsä infrastruktuuri voittaa vakavassa tekoälyssä, koska vakava tekoäly on enimmäkseen lupausten pitämistä sen jälkeen, kun uutuudenviehätys on poistunut huoneesta. Lupaus ei ole, että jokainen vastaus on täydellinen. Lupaus on, että järjestelmä tuntee syötteensä, kunnioittaa rajojaan, säilyttää näytön, ohjaa epävarmuuden, toipuu vioista, hallitsee kustannuksia ja kehittyy kokemuksen myötä. Tuon lupauksen pitävät jonot, skeemat, lokit, sopimukset, identiteetit, arvioinnit, toimintaohjeet ja palautussuunnitelmat.
Älykäs malli on tärkeä. Se on myös vaativa. Se tarvitsee selkeät rajat, tuoreen näytön, rajatut työkalut, kärsivällisen arvioinnin, hallitut kustannukset ja ihmisiä, jotka saavat merkityksellistä työtä eivätkä tähteitä. Anna sille nämä asiat, niin siitä voi tulla hyödyllinen. Kiellä ne siltä, niin organisaatio huomaa ennen pitkää, että älykkyys ilman infrastruktuuria on vain nopeampi tapa luoda työtä operaatioille.
Demo, joka epäonnistui lounaalla, ei epäonnistunut siksi, että tulevaisuus oli mahdoton. Se epäonnistui, koska tulevaisuus oli tasapainotettu jonon varaan, jota kukaan ei ollut kohdellut osana tulevaisuutta. Se on hiljainen opetus. Vakavassa tekoälyssä tylsät osat eivät ole sivurooleissa. Ne ovat itse näyttämö.