Skip to Main Content
Oracle Autonomous Database
Miksi ONNX-malli on tietokannan sisällä vallankumous?

Jari Kuokka
#Asiantuntijalle #Oracle Database #26AI

Miksi ONNX-malli on tietokannan sisällä vallankumous?

Perinteisesti tekoälysovellukset lähettävät dataa edestakaisin tietokannan ja ulkopuolisten rajapintojen (kuten OpenAI tai Azure) välillä. Tässä mallissa on kuitenkin kolme merkittävää ongelmaa: viive, kustannukset ja tietoturva.

Viimeisimmässä kokeilussamme halusimme haastaa perinteisen tavan rakentaa tekoälyratkaisuja. Yksi teknisesti merkittävimmistä askeleistamme oli ONNX-mallin (Open Neural Network Exchange) tuominen suoraan osaksi Oracle-tietokantaa.

Tavoitteenamme oli testata, kuinka paljon suorituskykyä ja tietosuojaa voidaan parantaa siirtämällä äly suoraan datan luokse sen sijaan, että dataa liikuteltaisiin verkon yli. Samalla kokeilu avasi oven täysin uudelle tavalle hyödyntää tekoälyä osana kriittisiä, reaaliaikaisia liiketoimintaprosesseja ilman riippuvuutta kolmannen osapuolen pilvirajapinnoista.

Hyvästit turhalle dataliikenteelle

Yleensä tekoälysovellukset rakennetaan niin, että dataa lähetetään jatkuvasti edestakaisin tietokannan ja ulkopuolisten rajapintojen (kuten OpenAI:n tai Azuren) välillä. Vaikka tämä on helppo tapa aloittaa, se tuo mukanaan kolme kriittistä haastetta: 

  1. Viive (Latency): Jokainen API-kutsu lisää millisekunteja, jotka kumuloutuvat suurilla datamassoilla. 
  2. Kustannukset: Ulkopuolisten mallien käyttö maksaa jokaiselta tokenilta tai kutsulta. 
  3. Tietoturva: Datan lähettäminen organisaation ulkopuolelle on aina riski, joka vaatii tarkkaa valvontaa.

Oracle 26ai ja ALL_MINILM_L12_V2: Voimalaitos palomuurin sisällä

Latasimme ALL_MINILM_L12_V2 -mallin suoraan Oracle 26ai -tietokantaan, mikä muutti tietokannan perinteisestä säilöstä itsenäiseksi tekoälypalvelimeksi. Tämän arkkitehtuurimuutoksen hyödyt ovat kiistattomat: 

  • Data pysyy kotona: Sensitiivinen tieto, kuten henkilökuvaukset tai liikesalaisuudet, ei poistu yrityksen palomuurin sisältä. Vektorointi tapahtuu siellä, missä data asuu, mikä tekee tietoturvasta sisäänrakennetun ominaisuuden eikä erillistä prosessia. 
  • Huippunopea suorituskyky: Koska malli pyörii suoraan tietokannan muistissa, uusi VECTOR_EMBEDDING-funktio voi käsitellä tuhansia rivejä sekunneissa. Pullonkaulaksi muodostuva verkkoliikenne loistaa poissaolollaan. 
  • Vapaus toimittajalukosta: ONNX on avoin standardi. Emme ole naimisissa yhden tekoälytoimittajan kanssa, vaan voimme vaihtaa mallin lennosta tehokkaampaan versioon. Mikä parasta: SQL-lauseet pysyvät samoina, vaikka "moottori" pellin alla vaihtuisi.
     

Tietokanta on nyt prosessointialusta

Tämä kokeilu osoitti, että tietokannan rooli on muuttumassa pysyvästi. Se ei ole enää pelkkä passiivinen paikka tiedon säilytykselle. Nykyaikainen tietokanta on älykäs prosessointialusta, joka ymmärtää sisältönsä merkityksen reaaliajassa.

 

Arvaapas jäikö tämä kokeiluksi? Meille Apexolla tämä tarkoittaa nyt kykyä rakentaa asiakkaillemme ratkaisuja, jotka ovat paitsi nopeampia ja halvempia, myös tietoturvallisempia kuin perinteiset API-pohjaiset toteutukset. Me täällä jo nykerretään asiakkaalle ratkaisua jossa LLM on lähellä, tehokas ja edullinen.

Mitä seuraavaksi? Sukellus konehuoneen puolelle

Tämä artikkeli raapaisi vasta pintaa siitä, mitä tietokantaan integroitu tekoäly mahdollistaa. Tiedämme kuitenkin, että asiantuntijoita kiinnostaa se, miten "taika" oikeasti tapahtuu. Siksi julkaisemme pian jatko-osan: Hands-on-oppaan ONNX-mallien viemiseen Oracle 23ai  ja 26ai-tietokantoihin.

 

Tulevassa teknisessä artikkelissa avaamme prosessin vaihe vaiheelta, jotta voit itse kokeilla vastaavaa toteutusta. Käymme läpi muun muassa seuraavat osa-alueet:

  • Mallin valmistelu ja tuonti: Miten valmis avoimen lähdekoodin malli muunnetaan ja ladataan tietokannan sisäiseen tallennustilaan.
  • Käyttöoikeuksien hallinta: Mitä rooleja ja oikeuksia tietokantakäyttäjä tarvitsee missäkin, jotta mallien hallinta ja suorittaminen on tietoturvallista.
  • Mallin todentaminen: Kuinka varmistetaan, että ladattu malli on ehjä ja käyttövalmis tietokannan sisällä.
  • SQL-integraatio: Katsomme käytännön esimerkkejä siitä, miten VECTOR_EMBEDDING-funktiota kutsutaan suoraan SQL-kyselyissä ja miten hakutulokset optimoidaan.

Tuleva artikkeli on tarkoitettu arkkitehdeille, kehittäjille ja kaikille, jotka haluavat siirtyä tekoälyhypestä suoraan käytännön toteutukseen. Stay tuned eli “perästä kuuluu sano Peräsmies” 🙂 

Haluatko liittyä postituslistallemme

Anna alle vain sähköpostiosoitteesi ja tiedotamme aina uusista artikkeleistämme.