Verstaspäiväkirja on jatkuva sarja siitä, miten työkalut oikeasti syntyvät — omissa ja asiakkaiden projekteissa, ideasta erehdyksen kautta iteraatioon.
Sama ilmiö toistuu organisaatiosta toiseen: dokumentteja on paljon, mutta tieto on hukassa. Virallisia ohjeita, epävirallisia muistiinpanoja, koulutusmateriaalia, vanhoja versioita samasta asiasta, sähköpostiin haudattuja päätöksiä — kaikki eri paikoissa, eri muodoissa. Kukaan ei ole ihan varma, mikä on uusin ja mikä pätee. Kun joku kysyy „miten tämä nykyään tehdään?”, vastaus on liian usein „kysy Juholta” — ja jos Juho on lomalla, tieto on käytännössä poissa.
Se ei ole vain pienten yhdistysten ongelma. Sama toistuu pk-yrityksissä ja isoissakin taloissa. Dokumentaatiota on kertynyt vuosia, mutta kukaan ei ole ehtinyt jäsentää sitä — eikä hakukenttä auta, jos et tiedä millä sanalla etsiä.
Tämä päiväkirja kertoo työkalusta, jonka rakensin tähän ongelmaan työssä, jota teen vapaaehtoisessa pelastuspalvelussa: yleisratkaisusta, jota eri yhdistykset voivat käyttää SAR-toiminnan kehyksessä. Sen ydinajatus on suoraan siirrettävissä mihin tahansa organisaatioon, joka hukkuu omiin dokumentteihinsa.
Kun dokumentaatiolla ei ole prosessia
SAR-toiminnassa dokumentaatio elää kahdella tasolla. On laajempi toimintakokonaisuus omine ohjeineen ja standardeineen, ja on yksittäisten yhdistysten oma dokumentaatio: koulutusmateriaalit, harjoitusmuistiot, paikalliset käytännöt. Molemmat vaihtelevat, molempien hallinta on hajanaista, ja käytänteitä sekä prosesseja puuttuu sieltä täältä. Yksi yhdistys tekee asian yhdellä tavalla, toinen toisella, ja „virallinen” ohje saattaa olla kahden vuoden takaa.
Tuttua? Juuri näin on niissä pk-yrityksissä, joissa laatukäsikirja on yhdellä levyllä, oikeat toimintatavat toisella, ja se todellinen tieto siitä miksi jokin tehdään tietyllä tavalla asuu muutaman konkarin päässä.
Halusin työkalun, joka vastaisi kahteen kysymykseen, joihin tavallinen kansiohaku ei taivu: „miten tämä käytäntö on kehittynyt ajan myötä?” ja „toiminko varmasti uusimman tiedon mukaan?” — ja tekisi sen sekä virallisista että epävirallisista dokumenteista, koska totuus asuu usein juuri niiden välissä.
Miksi RAG eikä hakukenttä
Tavallinen haku etsii sanoja. Jos etsit „etsintäkuvion muutos” etkä dokumentissa lue täsmälleen niin, et löydä mitään — vaikka dokumentti käsittelisi juuri sitä eri sanoin. Ihminen ei muista, millä termillä kolmen vuoden takainen muistio kirjoitettiin.
Ratkaisu on RAG — retrieval-augmented generation. Idea on kaksiosainen: ensin haetaan merkityksen perusteella ne dokumenttien palaset, jotka oikeasti liittyvät kysymykseesi, ja sitten kielimalli muotoilee niistä vastauksen, joka viittaa lähteisiinsä. Se ei ole chatbotti, joka keksii — se on hakukone, joka ymmärtää mitä tarkoitat, ja perustelee vastauksensa oikeilla dokumenteilla.
Juuri tämä sopii dokumenttikaaokseen: et tarvitse oikeaa hakusanaa, tarvitset oikean kysymyksen.
Obsidian-vault: tieto pysyy tekstinä ja omissa käsissä
Rakensin tietovaraston Obsidian-vaulttiin. Valinta ei ole kosmeettinen. Obsidian tallentaa kaiken tavallisena markdown-tekstinä paikalliseen kansioon — ei tietokantaan, ei pilveen, ei suljettuun formaattiin. Se tarkoittaa kolmea asiaa, jotka ovat tämän projektin kannalta ratkaisevia: tieto on luettavaa ilman erityisohjelmaa, se on kannettavaa (kansio on kansio), ja se on omissa käsissä. Jos työkalu joskus vaihtuu, tieto ei ole panttivankina.
Obsidianin toinen vahvuus on linkitys: dokumentit voivat viitata toisiinsa, ja niistä muodostuu verkosto. Tästä tuli myöhemmin koko työkalun selkäranka.
Vektorit ja haku: merkitys, ei sanat
Jotta merkityspohjainen haku toimii, dokumentit pitää muuttaa vektoreiksi — numeroiksi, jotka kuvaavat tekstin merkitystä niin, että samaa tarkoittavat palaset ovat lähellä toisiaan riippumatta sanavalinnoista. Tämä on RAG:n sydän, ja se tehdään paikallisella embedding-mallilla: teksti pilkotaan sopivan kokoisiin palasiin, jokainen palanen vektoroidaan, ja kysymys vektoroidaan samalla tavalla. Haku on sitten yksinkertaisesti „mitkä palaset ovat lähimpänä tätä kysymystä”.
Kuulostaa suoraviivaiselta. Pilkkomisen koko osoittautui yhdeksi hankalimmista päätöksistä — siitä lisää hetken päästä.
Tekoäly ristiviittaajana: Jarvisin perintö
Tässä kohtaa työkalu muuttui hakukoneesta muistiksi. Kun palaset olivat vektoreina, laitoin tekoälyn lukemaan ne läpi ja kansoittamaan vaultin ristiviittauksilla: se tunnistaa, että tämä harjoitusmuistio käsittelee samaa käytäntöä kuin tuo virallinen ohje, ja linkittää ne toisiinsa. Vähitellen hajanaisesta dokumenttikasasta kasvaa verkosto, jossa saman aiheen eri versiot, ajankohdat ja näkökulmat ovat kytkettyinä.
Kuka tahansa „second brain” -maailmaa seurannut tunnistaa periaatteen: tämä nojaa samaan ideaan kuin ne kuuluisat Obsidian + AI -„Jarvis”-projektit, joissa henkilökohtaisesta muistista rakennetaan haettava, itseään linkittävä tietovarasto. Ero on käyttötarkoituksessa — tässä ei jäsennetä yhden ihmisen muistiinpanoja vaan organisaation yhteistä tietoa, ja tietoturva on osa suunnittelua alusta asti.
Missä kompastuin
Kolme asiaa opetti nöyryyttä.
Pilkkomisen koko. Liian isot palaset toivat hakuun mukaan epäolennaista; liian pienet katkaisivat ajatuksen kesken ja tekoäly vastasi puolikkaan tiedon varassa. Oikea koko löytyi vasta kokeilemalla, ja se riippui dokumenttityypistä — tiivis ohje ja rönsyilevä muistio kaipaavat eri kohtelun.
Perustelu pakolliseksi. Ensimmäinen versio antoi sujuvia vastauksia, jotka kuulostivat oikeilta. Mutta ilman lähdeviittausta sujuva vastaus on vaarallinen: et tiedä, lukiko malli sen dokumentista vai keksikö sen. Pakotin jokaisen vastauksen viittaamaan siihen dokumenttiin, josta se on peräisin. Jos lähdettä ei ole, ei ole vastaustakaan.
Virallisen ja epävirallisen painotus. Totuus asuu usein epävirallisissa dokumenteissa — siellä kerrotaan miten asia oikeasti tehdään. Mutta ristiriidan tullessa uusimman virallisen ohjeen pitää voittaa. Työkalun piti osata erottaa nämä ja kertoa käyttäjälle, kummasta on kyse. Tämä ei ollut tekninen vaan tiedon hallinnan ongelma — ja juuri se, mikä puuttui alun perin.
Paikallinen tekoäly ei ole vain tekninen valinta. Se on päätös siitä, kenen palvelimella organisaatiosi tieto lepää.
Miksi paikallinen: data pysyy talon sisällä
Tässä on koko jutun ydin. RAG ja kielimalli voidaan ajaa pilvipalvelussa tai omalla koneella. Kun ne ajetaan paikallisesti, organisaation dokumentit eivät poistu talosta — ei tekstiä, ei liitteitä, eivät edes hakukyselyt lähde ulkopuoliselle palvelimelle. Koko tietovarasto, vektorit ja mallit pyörivät omalla laitteistolla.
Herkän tiedon kannalta ero on merkittävä. SAR-toiminnassa dokumentit voivat koskea sijainteja, menettelyjä ja tilanteita, joita ei ole tarkoitettu ulkopuolisille. Henkilötiedot ovat aina pannassa — ne eivät kuulu tällaiseen tietovarastoon lainkaan, vaan rajataan pois jo kartoitusvaiheessa. Yrityksessä sama koskee sopimuksia, hinnoittelua ja asiakkaita. Kun tieto ei koskaan lähde koneelta, tietovuodon hyökkäyspinta kutistuu dramaattisesti: ei kolmatta osapuolta, jonka palvelimelle data kertyy, ei epävarmuutta siitä mihin kyselyt tallentuvat, ei riippuvuutta ulkopuolisen palvelun tietoturvatasosta.
Hinta on laskentateho. Paikallinen malli vaatii laitteistolta enemmän kuin selaimeen avattava pilvipalvelu — kunnollisen koneen, mieluiten näytönohjaimen. Se on todellinen kustannus, eikä sitä kannata vähätellä. Tehon voi myös ostaa palveluna, ja monelle organisaatiolle se on järkevin ratkaisu — mutta silloin vastuu tietoturvasta siirtyy palveluntarjoajalle, ja siihen päästään kiinni vain sopimusteknisin keinoin. Se on oma tarinansa, ja siitä kirjoitan sarjan seuraavassa osassa.
Lopputulos: haettava, jäljitettävä, ajantasainen
Valmis työkalu tekee sen, mikä alussa oli mahdotonta. Voit kysyä „miten tämä käytäntö on muuttunut viimeisen kolmen vuoden aikana”, ja saat vastauksen, joka kokoaa yhteen viralliset ohjeet ja epäviralliset muistiot, järjestää ne aikajanaksi ja viittaa jokaiseen lähteeseen. Voit varmistaa, että toimit uusimman tiedon mukaan, näkemättä läpi kymmentä kansiota. Hajanaisesta dokumenttikasasta tuli muisti, jolta voi kysyä — ja joka osaa perustella vastauksensa.
Eikä se unohda, kun konkari jää lomalle.
Sama kaaos, sama ratkaisu — pk-yrityksissä
Rakensin tämän osana työtä, jota teen vapaaehtoisessa pelastuspalvelussa, mutta koko ajan mielessä oli se, kuinka tunnistettava ongelma on. Sama dokumenttikaaos vaivaa yhtä lailla pk-yrityksiä: laatujärjestelmä, jonka kukaan ei löydä; toimintatapa, joka elää kolmen ihmisen muistissa; päätökset, jotka on haudattu sähköpostiin. Ja sama malli — paikallinen RAG, joka pitää tiedon talon sisällä — on niiden ulottuvilla ilman, että dataa tarvitsee luovuttaa kenellekään. Työkalut ovat avoimia, laitteisto on kohtuuhintaista, ja tieto pysyy omana.
Se ei vaadi yritykseltä IT-osastoa. Se vaatii yhden koneen, vähän kärsivällisyyttä pilkkomisen kanssa, ja päätöksen siitä, että oma tieto pysyy omissa käsissä.
Seuraavassa osassa: milloin laskentateho kannattaa ostaa pilvestä — ja mitä tapahtuu tietoturvavastuulle, kun tekee niin. Sopimustekniikka, DPA ja NIS2:n toimitusketjuvastuu tulevat mukaan kuvaan.