Esimerkki ei ole määritys

"Tee tästä samanlainen."

Se on luultavasti yleisin ohje, jonka kielimallille annetaan. Mukaan liitetään viime kerran tiedosto: Edellinen raportti, edellinen tuontilista, edellinen tarjous. Malli saa esimerkin ja tekee siitä parhaan arvauksensa.

Ansa on siinä, mitä esimerkki ei kerro. Se näyttää, mitä viime kerralla tehtiin. Se ei näytä, mikä oli pakollista, mikä vapaaehtoista ja mikä meni läpi vahingossa. Tiedostossa nämä kolme näyttävät täsmälleen samalta, joten malli kohtelee niitä samalla tavalla.

Kaksi ansaa, jotka eivät olisi näkyneet virheilmoituksena

Rakensin tuotetietojen massatuontia. Tiedoston rakenne oli päätelty edellisen kampanjan viennistä, joka oli mennyt läpi ilman ongelmia. Se tuntui riittävältä perustelulta. Ennen ajoa luin kuitenkin tuontityökalun oman määrityksen sitä vasten, mitä olin esimerkistä päätellyt.

Kaksi kohtaa oli eri mieltä kanssani.

• Tunnistesarake ei saa olla tyhjä. Työkalun oma ohje sanoo, että tyhjä tunniste tarkoittaa uutta tuotetta. Yksi tuote vie tiedostossa jopa 13 riviä, koska variantit ja kuvat jatkuvat omille riveilleen. Jos tunniste olisi puuttunut jatkoriveiltä, yksi tuote olisi hajonnut kolmeksitoista vajaaksi tuotteeksi.
• Uuden tuotteen luominen vaatii otsikkokentän. Edellisessä viennissä tuotteet olivat jo olemassa, joten kenttä näytti esimerkissä valinnaiselta. Nyt jokainen tuote oli uusi. Aiemmissa tuonneissa rivejä oli kaatunut juuri tähän, mikä ei näkynyt siitä tiedostosta, josta rakenteen kopioin.

Mitä se muutti

Kumpikaan ei olisi antanut virheilmoitusta. Ensimmäinen olisi tuottanut moninkertaisen määrän puolivalmiita tuotteita, toinen olisi pudottanut rivejä hiljaa pois. Sellaista jälkeä ei korjata ajamalla uudelleen, vaan käsin rivi riviltä sen jälkeen, kun joku huomaa kaupan näyttävän väärältä.

Korjaus ennen ajoa oli kahden säännön kirjoittaminen. Kirjoitin ne kontekstitiedostoon, en keskusteluun, koska ne pätevät riippumatta siitä, kuka tiedoston seuraavan kerran ajaa. Keskustelu katoaa, tiedosto jää.

Mitä tästä kannattaa ottaa

Kontekstissa kannattaa erottaa kaksi roolia, jotka menevät helposti sekaisin. Esimerkki kertoo muodon: Miltä hyvä lopputulos näyttää. Määritys kertoo säännöt: Mikä on pakollista ja mikä hajoaa, jos se puuttuu. Edellisen kerran tiedosto on lähes aina ensimmäinen, ja sitä käytetään kuin se olisi toinen.

Konkreettinen asia tälle viikolle: Ota se tiedosto, jonka liität useimmin mukaan, ja kirjoita sen alkuun yksi rivi siitä, mihin se on auktoriteetti. Esimerkiksi niin, että tämä on malli muodosta, ei määritys sisällöstä. Jos rakenteessa on jotain pakollista, se etsitään järjestelmän omasta ohjeesta eikä päätellä edellisestä ajosta.

Tämä on se työ, joka tekee tekoälyn käyttöönotosta luotettavaa. Ei isompi malli, vaan se, että malli tietää kumpaa tiedostoa sen pitää uskoa.