Taulukot, joita ei ollut olemassa

Luku 2 — Taulukot, joita ei ollut olemassa

Mekaanisen yrityksen teknikko Koillis-Italiasta kertoi sen meille espresson ääressä, sillä venetsialaisten tyynellä rauhallisuudella, joka ennakoi katastrofia: "Chatbottimme tiesi kaiken moottorista. Paitsi moottorin tiedot." Sitten hän selitti. Heidän sisäinen tekoälyavustajansa osasi kuvailla tuotevalikoimia, käyttöyhteyksiä, brändin historiaa ja kilpailuetuja. Ihmeellistä narratiivisesti. Mutta kun asiakas kysyi CMP50L-mallin nimellisvääntömomenttia — eli teknistä tietoa, jonka vuoksi ihmiset avaavat luettelon, numeroa, jolla moottori ostetaan — chatbot vastasi epämääräisesti, joskus uskottavasti, joskus ei. Viisi kuukautta kehitystyötä, yhä hämmentyneempi toiminnanjohtaja, eikä kukaan tiennyt miksi.

Diagnoosi tuli sattumalta, melkein tylsistymisen vuoksi, kun tarkastin tietokantaa käsin loputtoman kokouksen jälkeen. PDF-luettelossa oli 342 teknistä taulukkoa. Tietokantaan niistä oli päätynyt nolla. Ei kourallinen: nolla. Yhtään ei. Koodi, joka poimi taulukot PDF-tiedostoista, tallensi tiedot kenttiin nimeltä columns ja data, kun taas koodi, joka myöhemmin indeksoi ne, odotti kenttiä nimeltä headers ja rows. Noudattamaton "synonyymi". Sisäinen sopimus, joka oli unohtunut refaktoroinnissa. Tuloksena, viiden hiljaisen kuukauden ajan: koko luettelon numeerinen älykkyys – parit, tehot, halkaisijat, painot, tilauskoodit, syöttöjännitteet – oli valunut hanasta, mutta ei koskaan kaatunut lasiin. Kolmesataakaksikymmentäkaksi taulukkoa, jotka katosivat yksi kerrallaan liturgisessa hiljaisuudessa.

Tämä on sellainen vika, joka ei huuda. Se ei aiheuta poikkeuksia, kaada mitään, eikä näy missään lokeissa. Yksinkertaisesti osa maailmaa lakkaa olemasta järjestelmäsi kannalta, eikä kukaan huomaa sitä, kunnes käyttäjä – yleensä vihainen käyttäjä – esittää tarpeeksi sitkeitä kysymyksiä paljastaakseen kuilun. Ja se on oire paljon suuremmasta ongelmasta kuin kenttien nimet: yleiset RAG-kehykset on optimoitu nykyiselle tekstille – artikkeleille, verkkosivuille, kaunokirjallisuuden kappaleille – ja ne käsittelevät taulukoita toisen luokan kansalaisina, jos käsittelevät niitä ollenkaan. Mutta italialaiset yritysdokumentit ovat usein taulukoita. Tekniset luettelot, hinnastot, tuotetiedot, käyttöturvallisuustiedotteet, tilausilmoitukset: arvokkain osa näiden asiakirjojen lukijalle on taulukkomuotoinen. Se, joka hajoaa ensimmäisenä, eikä kukaan huomaa sitä.

Oppitunti ei ole "ole tarkkana kenttien nimien kanssa". Se on hankalampaa: vakavassa RAG-järjestelmässä jokainen sisällön tyyppi – taulukot, kuvat, alfanumeeriset koodit, kappaleiden otsikot, alaviitteet – tarvitsee oman, suunnitellun ja testatun käsittelyn. Ja toimivuuden testaus ei ole "chatbot vastaa triviaaleihin kysymyksiin" – niihin vastaavat jopa vialliset järjestelmät, koska aineistoa on tarpeeksi, jotta voidaan rakentaa jotain uskottavaa. Todellinen testi on "chatbot vastaa kysymyksiin, jotka pakottavat sen koskettamaan jokaista putkilinjan osaa". Tarkkoja, numeerisia, todennettavia kysymyksiä. Kysymyksiä, joihin on yksi oikea vastaus, ja jos järjestelmä tekee virheen, tiedät sen heti.

Jos et tee tätä testiä, et tiedä, toimiiko RAG-järjestelmäsi. Tiedät vain, ettei se valita. Ja "ei valita" on hyvin alhainen laatukriteeri järjestelmälle, jota ihmiset käyttävät päätösten tekemiseen.