Mikä tekee organisaation tiedon­hausta luotettavan

01Demon ongelma

Useimmat tietämysavustajat noudattavat samaa mallia, jota kutsutaan nimellä retrieval-augmented generation (avautuu ulkoiselle sivustolle) (RAG): ensin haetaan kysymykseen sopivat tekstikohdat, sitten kielimalli kirjoittaa vastauksen niiden pohjalta. Viidenkymmenen huolella valitun asiakirjan kansiossa tämä toimii vakuuttavasti viikossa.

Tuotannossa tilanne on toinen. Edessä on kahdenkymmenen vuoden verkkolevyt, wikit, tiketit, sopimukset ja ohjeet, joista moni on päällekkäinen, vanhentunut tai luottamuksellinen. Siinä ympäristössä avustaja epäonnistuu kahdella tavalla. Se antaa väärän vastauksen, ja ihmiset lakkaavat käyttämästä sitä. Tai, mikä on pahempaa, se antaa väärän vastauksen varmalla äänellä, ja ihmiset toimivat sen mukaan.

Luotettava tiedonhaku riippuu siis vähemmän mallista ja enemmän sitä ympäröivän järjestelmän viidestä ominaisuudesta. Jokaisen voi suunnitella ja, mikä tärkeintä, testata.

02Käyttöoikeudet: hae vain se, mitä käyttäjä saa lukea

Sääntö on yksinkertainen: avustaja ei saa koskaan näyttää kenellekään tekstikohtaa, jota hän ei voisi avata lähdejärjestelmässä. Ratkaisevaa on, missä sääntö pannaan täytäntöön. Jos tekstikohta päätyy mallille, oleta, että se voi näkyä vastauksessa. Käyttöoikeudet on siksi sovellettava ennen vastauksen tuottamista, hakuvaiheessa ja kysyjän omilla oikeuksilla.

OWASP luettelee kielimallisovellusten pääriskeihin sekä arkaluonteisten tietojen paljastumisen (avautuu ulkoiselle sivustolle) että vektori- ja upotusheikkoudet (avautuu ulkoiselle sivustolle), mukaan lukien tietovuodot käyttöoikeusrajojen yli. Käytännössä tästä seuraa neljä vaatimusta.

• Tallenna jokaisen lähdeasiakirjan käyttöoikeudet indeksiin jokaisen tekstikappaleen yhteyteen. Ota ne lähdejärjestelmästä, älä määrittele niitä uudelleen käsin.
• Suodata näillä oikeuksilla kyselyhetkellä kirjautuneen käyttäjän identiteetin perusteella, ennen tulosten järjestämistä ja vastauksen tuottamista.
• Synkronoi oikeuksien muutokset vähintään yhtä nopeasti kuin sisällön muutokset, ja sovi, kuinka nopeasti poistetun oikeuden on tultava voimaan.
• Testaa todellisilla rooleilla. ”Löytääkö kesätyöntekijä palkkataulukot?” kuuluu testijoukkoon, ei häiriön jälkeiseen selvitykseen.

03Lähteet: viittaukset, jotka ihminen voi tarkistaa

Jokaisen vastauksen väitteen pitää osoittaa tekstikohtaan, josta se on peräisin: asiakirjan nimi, versio tai päiväys, omistaja ja linkki, joka avautuu oikeasta kohdasta. Näytä itse tekstikohta, ei vain asiakirjan nimeä, jotta lukija näkee sekunneissa, tukeeko viittaus lausetta.

Suunnittele vastausmuoto niin, että tukematon teksti erottuu. Jos mikään haettu tekstikohta ei tue lausetta, järjestelmän pitää jättää se pois tai merkitä se. Tarkista tämä automaattisesti: vertaa jokaista viitattua tekstikohtaa väitteeseen, jota sen on määrä tukea, ja ota tuloksista otos ihmisen tarkastettavaksi. Viittaukset, jotka ovat olemassa mutta eivät tue väitettä, ovat yleinen ja huomaamaton virhe.

04Ajantasaisuus ja auktoriteetti

Organisaation tiedolla on versioita. Vanha ja uusi matkustusohje vastaavat molemmat kysymykseen ”saanko varata bisnesluokan?”, ja ne antavat eri vastauksen. Indeksoi metatiedot, jotka erottavat ne toisistaan: voimaantulopäivä, tila (luonnos, hyväksytty, korvattu) ja omistaja. Nosta voimassa olevat, hyväksytyt asiakirjat ensimmäisiksi, jätä korvatut pois, ellei käyttäjä kysy historiaa, ja näytä päiväys jokaisessa viittauksessa.

Päätä aihekohtaisesti, mikä lähde on määräävä. Henkilöstöohje tulee henkilöstöportaalista, ei sähköpostista, jossa lainataan viime vuoden versiota. Sovi jokaiselle lähteelle päivitysrytmi, asiatietojen lähes reaaliaikaisesta päivityksestä wikin päivittäiseen indeksointiin, ja seuraa sitä. Vanhentunut indeksi tuottaa vastauksia, jotka näyttävät oikeilta mutta eivät ole.

Esimerkiksi valtion virastossa ohjehaun on erotettava voimassa oleva ohje kumotusta ja näytettävä, mihin lakiin tai päätökseen ohje perustuu. Elintarvike- tai elektroniikkatehtaan kunnossapidossa sama koskee huolto-ohjeita: väärä versio voi johtaa väärään työvaiheeseen.

05Rehelliset aukot: ”En löytänyt tähän lähdettä”

Usein arvokkain vastaus on rehellinen aukko. Kielimallit voivat tuottaa sujuvia väitteitä, joita mikään ei tue. NIST kutsuu tätä generatiivisen tekoälyn profiilissaan konfabulaatioksi (avautuu ulkoiselle sivustolle). Haettuihin tekstikohtiin perustuminen vähentää ilmiötä mutta ei poista sitä. OWASP käsittelee seurausta, eli sitä, että ihmiset toimivat virheellisen tuotoksen perusteella, omana riskinään nimellä misinformation (avautuu ulkoiselle sivustolle).

Aseta osuvuusraja, jonka alittuessa järjestelmä kertoo, ettei luotettavaa lähdettä löytynyt, ja ehdottaa, keneltä kannattaa kysyä. Kun kysymys koskee ohjeita, oikeuksia tai velvollisuuksia, älä anna mallin täyttää aukkoja yleistiedolla. Seuraa sitten vastaamatta jääneiden kysymysten osuutta aiheittain. Ensimmäisinä kuukausina tämä lista on usein koko hankkeen hyödyllisin tulos: se näyttää sisällön omistajille tarkalleen, mistä dokumentaatio puuttuu.

06Viiden ominaisuuden taustalla oleva arkkitehtuuri

Mikään tästä ei vaadi eksoottista teknologiaa. Se vaatii, että käyttöoikeudet, metatiedot ja tarkistukset ovat putken ensisijaisia osia eivätkä demon jälkeen lisättyjä ominaisuuksia.

Henkilötiedot vaativat erityistä huomiota. Asiakirjaindeksi on edelleen niissä olevien henkilötietojen käsittelyä, joten tietosuoja-asetuksen käyttötarkoitussidonnaisuuden ja tietojen minimoinnin (avautuu ulkoiselle sivustolle) periaatteet (5 artikla) koskevat sitä. Suomessa asetusta täydentää tietosuojalaki (1050/2018), ja valvojana toimii tietosuojavaltuutettu. Jätä pois lähteet, joita käyttötapaus ei tarvitse, varmista, että lähdejärjestelmässä tehdyt poistot ulottuvat indeksiin, ja ota indeksi mukaan, kun vastaat tiedonsaantipyyntöön.

07Mitattu laatu ennen käyttöönottoa ja sen jälkeen

Luotettavuutta ei voi arvioida kokeilemalla muutamaa kysymystä palaverissa. Sovi laatukriteerit sisällön omistajien kanssa ja mittaa jokainen kerros erikseen, jotta tiedät, mistä ongelma korjataan.

Kokoa testijoukko todellisista kysymyksistä: hakulokeista, tukipyynnöistä ja kysymyksistä, joita uudet työntekijät esittävät. Muutama sata kysymystä, joiden vastauksista sisällön omistajat ovat sopineet, on käytännöllinen alku. Aja koko joukko jokaisen muutoksen yhteydessä, oli kyse uudesta mallista, uudesta tavasta pilkkoa tekstiä tai uudesta lähteestä. Laatu heikkenee huomaamatta, kun sisältö muuttuu, ja vain kiinteä testijoukko tekee muutoksen näkyväksi.

08Miltä luotettavuus näyttää käyttäjälle

Käyttäjälle kaikki tämä tiivistyy muutamaan havaittavaan asiaan. Avustaja vastaa vain asiakirjoista, joita käyttäjä saa lukea. Jokaisella väitteellä on viittaus, jonka voi avata. Lähteen ajantasaisuus näkyy. Avustaja sanoo suoraan, kun luotettavaa vastausta ei ole. Ja käyttäjä tietää, että laatua mitataan, koska hän voi ilmoittaa väärästä vastauksesta ja nähdä sen korjattuna.

Tekoälyn tuotos voi silti olla väärä, ja jotkin kysymykset kuuluvat ihmiselle eivätkä haulle. Kun tähän varaudutaan avoimesti, se ei ole järjestelmän heikkous. Juuri se saa ihmiset luottamaan siihen kaikessa muussa.