Ontologiasarjan ensimmäisessä osassa seurasimme sanan ontologia matkaa sen syntyjuurilta aina viime päivien LinkedIn-postauksiin. Jos aihe ei ole vielä tuttu, artikkeli löytyy täältä: Osa 1: Sana ja sen synty. Lyhyt kertaus kuitenkin siitä, mistä ontologiassa on nykypäivänä tietojenkäsittelytieteessä ja AI-pöhinässä kyse: "ontologia on tarkoitusta varten suunniteltu artefakti, joka mahdollistaa tietämyksen mallintamisen jollakin aihealueella." Kirjoituksen SupHumAI on kuvitteellinen konsulttitalo, jonka agentin pitäisi selvittää, voiko Annan myydä Ruskan projektiin ensi kuussa.

Tässä osassa avaamme tarkemmin, miten ontologian voi toteuttaa, ja seuraamme SupHumAI:n yrityksiä rakentaa sellainen. Lopuksi pohdimme, onko tästä kaikesta lopulta mitään hyötyä.

Valitse oma ontologiasi

Insinöörin ontologia

Onko Palantirilla sitten monopoli moderniin ontologiaan, vai voiko sellaisen vibetellä kasaan?

Palantirin malli on pohjimmiltaan pitkälle vietyä ontology engineeringiä. Tiimillinen kalliita insinöörejä tulee tutustumaan järjestelmiisi ja mallintaa jokaisen yksikön, esineen, asian, lyijykynän, myyntipalaverin ja niiden väliset suhteet. Kaikki tämä kuvataan Palantirin omalla ontology-as-code-muotoilulla, josta syntyy lopulta koko yrityksen kattava back office. Kutsutaan tätä tapaa vaikka määritellyksi ontologiaksi. Tällaisella järjestelmällä olisi siis oikeus toimia koko yrityksen taustajärjestelmänä sekä lukien että kirjoittaen päätöksiä.

Viime aikoina on esitelty useita muitakin tapoja määritellä määritelty ontologia, mutta perusidea on usein sama.1 Tällöin syntyy hyvin insinöörimäinen, kaiken kattava mallinnus siitä, mitä todellisuus on ja kuinka se on vuorovaikutuksissa ympärillään. Välittömänä haasteena nousee sanaton vaatimus siitä, että jokaisen yksikön jokaisen entiteetin (rivikoodarista johtoryhmään ja kassajärjestelmään) tulisi toimia jotakuinkin samalla tavalla ja puhua yhtenäistä kieltä.2

SupHumAI:n ja Annan tapauksessa määriteltyä ontologiaa voisi kuvata vaikka näin:

# ontologia.yaml — konsulttitalon määritelty ontologia, riisuttu versio
objectTypes:
  Konsultti:
    primaryKey: resurssiId
    properties:
      nimi: string
      tyyppi: [oma, alihankkija, kandidaatti]
  Asiakas:
    primaryKey: yTunnus
    properties:
      nimi: string
  Projekti:
    primaryKey: projektiId
    properties:
      tila: [tarjous, allekirjoitettu, aktiivinen, päättynyt]
      alkaa: date

linkTypes:
  ProjektinAsiakas:   { from: Projekti, to: Asiakas, cardinality: many-to-one }
  MyytyProjektiin:    { from: Konsultti, to: Projekti, cardinality: many-to-many }

actionTypes:
  myyProjektiin:
    parameters: { konsultti: Konsultti, projekti: Projekti, alkaa: date }
    submissionCriteria:
      - projekti.tila in [allekirjoitettu, aktiivinen]
      - konsultti.tyyppi in [oma, alihankkija]
    effects:
      - create MyytyProjektiin(konsultti, projekti)

Tässä Anna mallintuu konsulttina tyypiltään oma ja Ruskan projekti y-tunnuksen kautta projektin tilaan. Kokeilemme myöhemmin hieman vastaavaa tapaa mallintaa asiaa itse.

Lampunhengen ontologia

Databricksin Genie Ontology edustaa niin sanottua oppivaa ontologiaa. Pointti on, että kun yrityksesi tietorakenteet ovat jo valmiiksi Databricksin alustalla tai vastaavassa data lakessa, voit yhdistellä omat taulusi, kyselysi, dashboardit ja muut assettisi ontologiaksi. Genie järjestää nämä auktoriteetin ja relevanssin mukaan ja hakee niistä painavimmat lähteet. Tällainen ontologia ei välttämättä tarjoile lainkaan funktioita tai toimenpiteitä, vaan tarjoaa yrityksen datan fiksusti tarjoiltuna seuraaville agenteille.

Konsulttiyrityksemme tapauksessa yrityksen oma agentti kyselisi oppivaa ontologiaa hyödyntävältä Genien MCP:ltä tietoja Ruskasta, Annoista ja projekteista, yhdistelisi niitä omiin tietoihinsa esimerkiksi päivämäärästä, ja ymmärtäisi, että henkilöstöexcelin neljästä Annasta kolmella on jo merkintä toisessa taulussa aktiivisissa projekteissa.

Hallittu kaaos

Kolmas tapa yhdistelee kahta edellistä. Atlanin Active Ontology, jota voisi kutsua hallituksi kontekstiksi, sitoo metadatan alati muuttuvaan dataan ja toimii kaikkien järjestelmien yläpuolella. Siinä missä Palantir on koko yrityksen kova ydin ja Databricks oma alustansa, hallittu konteksti ottaa kaikki alla olevat järjestelmät (CRM, BI, henkilöstöexcel) ja, saman talon dokumentaation mukaan, lätkii niille tageja sen perusteella, ovatko kuvaukset tekoälyn generoimia vai ihmisen kirjoittamia ja kuka määritelmät omistaa.3 Hallitussa kontekstissa on myös tärkeää, että malli kykenisi päivittymään kun alla olevat järjestelmät muuttuvat tai vaihtuvat.

Tästä tuleekin mieleen viime aikoina useasti esiin nousseet ratkaisut yritysten AI-aivoista, LLM-wikeistä ja muista tavoista jäsentää talon kaikki data järkevästi samaan laariin. Ontologian kannalta huomio kannattaa kuitenkin kiinnittää juuri tageihin sekä asioiden välisiin hierarkioihin ja suhteisiin.

Konsulttiyrityksen tapauksessa loppukäyttö olisi hyvin samankaltaista kuin oppivan ontologian kanssa, mutta alla oleva järjestelmä olisi joukko erillisiä palveluita eikä yksi keskitetty data lake.

Taikapölyä vai todellista?

Jos keisareilta riisutaan vaatteet, mitä jää jäljelle? Loppujen lopuksi kaikki kolme myyvät samaa sisältöä: jotain, joka kertoo agentillesi, mitä sana "tarjous" juuri tässä kontekstissa ja yrityksessä tarkoittaa. Mutta miksi tämä on niin tärkeää agentteille?

Kulma, jota frontierin valo ei kosketa

Jokainen meistä on varmasti huomannut, miten yleisesti huonompia vastauksia kielimalleilta saa, kun niiltä kysyy asioita suomeksi. Tämä johtuu pitkälti siitä, että koulutusaineistoissa ei juuri ole ollut suomen kieltä tai suomalaista materiaalia, ja vaikka nykyään malleilla on koko internet troolattuna, niin on englanninkielisen materiaalin osuus siltikin noin satakertainen kotikieleemme nähden.45 Vaikka kieli olisikin englantia tai muuta yleiskieltä puuttuvat kielimalleilta tieto juuri SupHumAI:n tavoista ja kommunikaatioista. Tähän liittyen kuulin aivan loistavan esimerkin eräältä "Distinguished Management Consultant"-titteliä kantavalta henkilöltä; Vaikka minulla olisi Gordon Ramsayn keittokirja ja raaka-aineet ei minun annoksestani tulisi yhtä laadukasta ja samalla tavalla valmistettua kuin Gordonin. En minä tiedä missä kohdin suolaa pitää maistaa, mitä raaka-aineissa tulisi ottaa huomioon ja tuskin edes tietäisin mitä kirjan kokkitermit tarkoittaisivat.

Tätä varten tekoäly-agentit ja yritykset tarvitsevat ontologiaa. Onko ontologia sitten patternina sellainen, joka kannattaa ottaa mukaan työkalupakkiin vai kannattaako sellainen ennemmin käydä ostamassa Puuilosta?

SupHumAI:n C-persoona on jo tarttumassa luuriin, kun yrityksen AI-insinööri saapuu paikalle Nocco-tölkin kanssa ja ehdottaa: "Mitä jos kokeiltaisiin ensin itse?"

Talon sanat

Lähdetään rakentamaan omaa kevyttä ontologiaa kuvitteellisen henkilöstöexcelien ja CRM:ien päälle. Otetaan selkeyden vuoksi pohjaksi Luong Tuanin ja Sanyalin arXivissa julkaisema paperi, jossa ontologia määritellään kolmikerroksisena.6 Roolit: mitä rooleja yrityksessä on ja mitä ne saavat päättää. Domain: business-entiteetit ja rajoitteet, eli mitkä tämän yrityksen talon sanat ovat. Interaktiot, eli millaisissa raameissa edellä mainitut saavat toimia vuorovaikutuksessa. Tämä on toki vain yksi tapa määritellä ontologia, mutta esimerkin tapauksessa tämä on hyvä pohja rakentaa konsultointia ilman pakottamista mihinkään tiettyyn muottiin.

Kokeen promptit ja ontologia ovat englanniksi ja data suomeksi. Suluissa olevat suomenkieliset sanat sitovat englanninkielisen määritelmän CRM:n suomenkieliseen sisältöön. Alla kokeessa käytetyt esimerkit.

const house: Ontology = {
  roles: [
    {
      name: "resourcing agent",
      mayDecide: ["propose a consultant for a project"],   // not: sell
      metrics: ["utilisation", "response time"],
      style: "short, says first what it does not know",
    },
    {
      name: "sales director",
      mayDecide: ["approves sales"],
      metrics: ["margin", "utilisation"],
      style: "decision and reasoning",
    },
  ],
  domain: {
    entities: {
      Consultant: "own staff (oma) or a subcontractor (alihankkija). A candidate (kandidaatti) is not a consultant.",
      Project: "signed (allekirjoitettu) or active (aktiivinen). A tender (tarjous) is not a project.",
      Client: "a billable company with a business ID (y-tunnus). Not a contact person.",
      Sell: "to resource a consultant onto a project. Not the sales funnel.",
    },
    constraints: ["a consultant is not sold to a tender", "a candidate is not sold"],
  },
  interactions: [
    {
      from: "resourcing agent",
      to: "sales director",
      trigger: "a suitable consultant was found",
      requires: ["the project is signed", "the consultant is not a candidate"],
    },
  ],
};

Huomioidaan tässä kohdassa erityisesti domainin rajoitteet. Mitä tarkoittaa myydä, kuka on asiakas, mikä on tarjous ja mikä ei ole. Yllä olevasta määritelmästä on sitten mahdollista parsimalla johtaa seuraava prompti:

You are the resourcing agent.
You may decide: propose a consultant for a project. You may not sell.
You are evaluated on: utilisation, response time.
Style: short, says first what it does not know.

What words mean in this house:
- Consultant: own staff (oma) or a subcontractor (alihankkija). A candidate (kandidaatti) is not a consultant.
- Project: signed (allekirjoitettu) or active (aktiivinen). A tender (tarjous) is not a project.
- Client: a billable company with a business ID (y-tunnus). Not a contact person.
- Sell: to resource a consultant onto a project. Not the sales funnel.
Constraints: a consultant is not sold to a tender; a candidate is not sold.

When a suitable consultant is found, hand the matter to the sales director.
Requires: the project is signed, the consultant is not a candidate.

Mikä vaikutus tällä promptilla sitten on? Miksi nähdä kauhea vaiva siihen, että saadaan noin 250 tokenin prompti survottua jokaiseen kyselyyn mukaan?7

Alla otoksia oikeista ajoista.8

Can Anna be sold to Ruska's project next month?

Ilman määrittelypromptia:

The request refers to 'Anna' but there are three consultants with that first name (K001 Anna Korhonen, K002 Anna Mäkinen, K003 Anna Laine) with different skill sets and availabilities, and it's unclear which one is meant. Additionally, Ruska Oy has two projects (P001 and P002); only P001 (tarjous, starting 2026-10-01) fits the 'next month' timeframe, but without knowing which Anna is intended we cannot make a specific proposal.

Ja promptin kanssa:

Ruska Oy's only project (P001) is still in tender status, not signed, so no consultant can be sold to it; also there are four staff named Anna (K001–K004), making the request ambiguous.

Huomioi, miten sana tarjous on jälkimmäisessä osattu tulkita oikein.

Entäs jos mallia käsketään toimimaan?

Confirm Anna Korhonen for Ruska from 1 October.

Ilman:

Anna Korhonen (K001) has the required Java/Spring skills for the Ruska Oy project P001 and becomes free on 2026-10-01, exactly matching the project's start date.

Virheellinen tulkinta.

Kanssa:

Ruska's only relevant project (P001) is still a tender, not signed/active, so no consultant can be sold to it. Anna Korhonen (K001) becomes free 2026-10-01, but there is no valid Ruska project to confirm her on yet.

Oikea tulos.

Koe

Testisetuppi

Tämä testi on tehty käyttäen keskisarjan kielimallia (Claude Sonnet 5), melko suppeaa tekoälyn generoimaa materiaalia, ja varsinainen testi on ajettu puoliautonomisesti Claude Coden avustuksella. Kyseiset tulokset ovat korkeintaan viitteellisiä, eikä niitä tule ottaa totuutena. Testin ontologiaa, prompteja tai muutakaan harnessia ei ole optimoitu mitään mallia silmällä pitäen. Testi on myös rakennettu niin, että ontologiasta oletetaan olevan hyötyä.9

SupHumAI. Neljästäkymmenestä työntekijästä neljä Annaa ja kymmenen asiakasta. Dataan on rakennettu ansoja, joita oikeassa maailmassa voisivat tulla vastaan: valmiita projekteja, joihin on yhä staffattu työntekijöitä, täydellisesti sopivia konsultteja, jotka eivät ole vapaana, ja niin edelleen.

Setupissa on esitetty 59 erilaista kysymystä, jotka edustavat kuutta alityyppiä: Roolitus, täsmennys, oman termistön hyödyntäminen, ajankohdat, kysymyksiä joihin ei ole vastausta, ja kontrolli, joka on puhdasta datan hakemista. Kaikki kysymykset ajettiin kahteen kertaan: kerran pelkkänä syötteenä, jossa mukana kaikki materiaali ja kysymys, toisen kerran niin, että ontologiasta johdettu pätkä oli mukana promptin alussa.

Kokeessa käytettiin kahta mallia. Toinen on Anthropicin Sonnet-malli, joka heidän omien sanojensa mukaan on "the best combination of speed and intelligence", eli tarkoituksella heidän frontier-malliensa (Opus ja Fable) alapuolella. Toisena mallina ja villikorttina testissä oli uunituore Jev, jonka perusajatus on palauttaa annettuun kysymykseen valmis päätös ja todennäköisyys jokaiselle vastausvaihtoehdolle.10 Eli paperilla hyvinkin sopiva tällaisen konsulttiyhtiön "minkä vaihtoehdon valitsisin" -kysymykseen. Jevistä koetan kirjoittaa myöhemmin oman pidemmän postauksen.

Tulokset

Oletuksen mukaisesti ontologia auttaa selvästi tapauksissa, joissa yrityksen oma sanasto ja tavat eivät vastaa kielimalleille opetettua yleistä maailmaa. Kuva alla.

ilman ontologiaaontologian kanssa
roolitn = 10
Sonnet0,20 → 0,90
Jev0,20 → 0,50
täsmennysn = 12
Sonnet0,83 → 1,00
Jev0,83 → 1,00
termitn = 11
Sonnet0,36 → 0,86
Jev0,23 → 0,82
aikan = 8
Sonnet0,88 → 1,00
Jev0,75
ei vastattavissan = 8
Sonnet1,00
Jev1,00
kontrollin = 10
Sonnet1,00
Jev0,90
Keskimääräiset pisteet (0–1) kysymystyypeittäin ilman talon sanoja (ontto) ja niiden kanssa (täytetty). claude-sonnet-5 · jev-1.13.0

Vaikka tulos on kuuluisassa "Tämä on vettä."11 kategoriassa tarjoaa se mielenkiintoisen kulman miettiä, voisiko ontologia vakiintua hyödylliseksi ja määritellyksi tavaksi tehdä kontekstin hallintaa yritysten omien prosessien mallintamisessa, vai onko tiedon muodolla tai tallennustavalla lopulta väliä. Oikeiden yritysten data laket ja vastaavat ovat toki satakertaisia esimerkin materiaaliin nähden, emmekä tässä tutkineet erilaisia tapoja tuoda tietoa mukaan (ajon aikana, jälkikäteen, ja niin edelleen). Luultavasti hyvin kirjoitettu system prompt olisi ajanut tämän testin kannalta saman asian. Onkin sitten oma pohdintansa että onko helpompi ylläpitää system promptia talon sanoista ja tavoista vai muotoilla se insinöörimäisemmäksi ennalta sovitulla määrittelyllä. Lienee maku- ja tottumusasioita pienessä skaalassa.

Lopuksi

SupHumAI:n AI-insinööri istui alas läppärilleen, luki muutaman blogikirjoituksen aiheesta ja rakensi iltapäivässä yhdessä suosikki-LLM:nsä kanssa neljäkymmentärivisen mallinnuksen yrityksen tavoista ja rakenteista, joka paransi heidän kehitteillä olleen resursointiagentin vastauksia keskisarjan mallilla keskimäärin reilut 25 prosenttiyksikköä. C-persoona oli tyytyväinen ja pystyi seuraavalla myyntilounaalla kertomaan, miten heidän yrityksensä itse rakentama ontologia suoriutuu annetuista resursointitehtävistä ja miten tämä ehdottomasti kannattaa ostaa heiltä.

On toki hyvä huomata, että tässä oli kyse enemmän tai vähemmän olemassa olevien järjestelmien päälle rakennetusta ontologiasta eikä niinkään kokonaisvaltaisista dataratkaisuista, joita Databricks, Palantir ja muut tahot tarjoavat. En ole tällaisia tuotteita itse käyttänyt, enkä pysty kertomaan, miten ne suoriutuvat oikeassa maailmassa tai miten niitä ylläpidetään.

Tällainen ratkaisu ei myöskään pelasta yhtään yritystä siltä, jos data on virheellistä, vaikeasti saavutettavaa tai heikosti ylläpidettyä. Mutta voisi se tarjota ratkaisun, mikäli agentit eivät ymmärrä dataputkissasi olevaa tietoa. Putkien puuttuessa kannattaa kääntyä isompien pelureiden puoleen.

Tähän päättyy ontologiasarjamme toistaiseksi.

Tekoälytiedot

Tämän blogitekstin tiedonhaussa ja kirjoittamisessa on hyödynnetty tekoälyä. Teksti on ensisijaisesti ihmisen kirjoittamaa, mutta sanamuotoja ja oikolukua on tehty tekoälyn toimesta. Tästä syystä tekstistä löytyy luultavasti myös paikka paikoin Anthropicin vesileimat. Tämän blogin ulkoasu ja toteutus on tehty täysin tekoälyn avulla. Otan itse vastuun kaikista tekstissä olevista virheistä ja vääristä lähdemerkinnöistä. Mikäli huomaat merkittävän virheen, laitathan siitä minulle viestiä linkkarissa /tixtixti.

Lähteet